Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote in news:viodfp$fp5p$2@dont- email.me:
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
True! I loved the feel of the DECwriter LA-36 II keyboard. The spacebar was
below the other keys, in the center where it should be, and no modifier keys on that row.
I can remember when Radio Shack sold ICs (Integrated Circuits) and building my first computer from components, like baton switches.
David LaRue wrote this post while blinking in Morse code:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote in news:viodfp$fp5p$2@dont-
email.me:
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
True! I loved the feel of the DECwriter LA-36 II keyboard. The spacebar was
below the other keys, in the center where it should be, and no modifier keys
on that row.
I had forgotten about the DECwriter!
Chris Ahlstrom <OFeem1987@teleworm.us> writes:
David LaRue wrote this post while blinking in Morse code:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote in news:viodfp$fp5p$2@dont-
email.me:
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
True! I loved the feel of the DECwriter LA-36 II keyboard. The
spacebar was below the other keys, in the center where it should be,
and no modifier keys on that row.
I had forgotten about the DECwriter!
I'll never forget when our ASR-33 was replaced with an LA-120. Three
times faster, and full-width greenbar.
scott@slp53.sl.home (Scott Lurndal) wrote in news:7H44P.55775$A9x9.24066@fx13.iad:( Cuts )
Chris Ahlstrom <OFeem1987@teleworm.us> writes:
David LaRue wrote this post while blinking in Morse code:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote in news:viodfp$fp5p$2@dont- >>>> email.me:
/| I may be demented \|\|
David LaRue wrote:( cuts )
scott@slp53.sl.home (Scott Lurndal) wrote in
news:7H44P.55775$A9x9.24066@fx13.iad:
/| I may be demented \|\|
Freddy1X wrote:
David LaRue wrote:( cuts )
scott@slp53.sl.home (Scott Lurndal) wrote in
news:7H44P.55775$A9x9.24066@fx13.iad:
The clicks and buzzes of your floppy drives as they trundled along.( 8" of cource )
Freddy,
also getting floppy....
Freddy1X wrote:
David LaRue wrote:( cuts )
scott@slp53.sl.home (Scott Lurndal) wrote in
news:7H44P.55775$A9x9.24066@fx13.iad:
The clicks and buzzes of your floppy drives as they trundled along.( 8" of cource )
On 2024-12-05 15:07, Freddy1X wrote:
Freddy1X wrote:
David LaRue wrote:( cuts )
scott@slp53.sl.home (Scott Lurndal) wrote in
news:7H44P.55775$A9x9.24066@fx13.iad:
The clicks and buzzes of your floppy drives as they trundled along.( 8" of >> cource )
The clicks and buzzes of the hard disk step motor on my PC.
On 2024-12-05 15:07, Freddy1X wrote:
Freddy1X wrote:
David LaRue wrote:( cuts )
scott@slp53.sl.home (Scott Lurndal) wrote in
news:7H44P.55775$A9x9.24066@fx13.iad:
The clicks and buzzes of your floppy drives as they trundled along.( 8" of >> cource )
The clicks and buzzes of the hard disk step motor on my PC.
"Carlos E.R." <robin_listas@es.invalid> writes:
On 2024-12-05 15:07, Freddy1X wrote:
Freddy1X wrote:
David LaRue wrote:( cuts )
scott@slp53.sl.home (Scott Lurndal) wrote in
news:7H44P.55775$A9x9.24066@fx13.iad:
The clicks and buzzes of your floppy drives as they trundled along.( 8" of >>> cource )
The clicks and buzzes of the hard disk step motor on my PC.
Seek tests on the mainframe 3350 lookalikes, or the
air compressor kicking in on the Burroughs 5N Head-per-Track drives.
scott@slp53.sl.home (Scott Lurndal) writes:
"Carlos E.R." <robin_listas@es.invalid> writes:
On 2024-12-05 15:07, Freddy1X wrote:
Freddy1X wrote:
David LaRue wrote:( cuts )
scott@slp53.sl.home (Scott Lurndal) wrote in
news:7H44P.55775$A9x9.24066@fx13.iad:
The clicks and buzzes of your floppy drives as they trundled along.( 8" of >>>> cource )
The clicks and buzzes of the hard disk step motor on my PC.
Seek tests on the mainframe 3350 lookalikes, or the
air compressor kicking in on the Burroughs 5N Head-per-Track drives.
The first systems I worked on used multiple tape drives.
But then I escaped to an IBM 1440 installation. The platters were about
20 inches across. The installation I was at did not pay for the direct
seek feature, so every arm movement started with the arm
retracting then it moved to the cylinder desired.
The clicks and buzzes of your floppy drives as they trundled along.( 8"
of cource )
The first systems I worked on used multiple tape drives.
Burroughs had a number of early drives (Drum, HPT, etc) before
my time. They had a 3330 clone (called 235) and the 3350
lookalikes (called 677) actually came from Memorex (which Burroughs
acquired at some point).
The clicks and buzzes of the hard disk step motor on my PC.
On Thu, 05 Dec 2024 16:11:12 -0500, Rich Alderson wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
Burroughs had a number of early drives (Drum, HPT, etc) before my time.
They had a 3330 clone (called 235) and the 3350 lookalikes (called
677) actually came from Memorex (which Burroughs acquired at some
point).
The Memorex 677 was the 3330-11 clone, also used in the DEC RP06. I've
actually done a head alignment on one of those (and remember, I'm a
software/
admin guy).
On Thu, 05 Dec 2024 14:51:24 -0500, Dan Espen wrote:
The first systems I worked on used multiple tape drives.
Remember how computers used to be portrayed in movies and TV, well into
the 1980s, with banks of multiple tape drives where the reels would go start-stop-start-stop?
At one site someone
decided to try assigning the compile work files to tape instead of disk.
That slowed down compiles considerably but it was the first time I got
to see a program that read tape files forward and backward.
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
I talk about punch cards and paper tape. Sometimes I ask if they have
seen old sci-fi films with the big tape wheels going around in the background, and say I used to work with those.
/| I may be demented \|\|
Trog Woolley wrote:
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
I talk about punch cards and paper tape. Sometimes I ask if they have
seen old sci-fi films with the big tape wheels going around in the
background, and say I used to work with those.
Were those tape drives anything like the Lost in Space ones that had bubble heads and flex duct arms with clamp manipulators on the ends?
After all, there MUST have been SOME basis for the drives shown on the TV show.
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Thu, 05 Dec 2024 14:51:24 -0500, Dan Espen wrote:
The first systems I worked on used multiple tape drives.
Remember how computers used to be portrayed in movies and TV, well into
the 1980s, with banks of multiple tape drives where the reels would go
start-stop-start-stop?
Yep. Tapes spinning and sometimes cards being read.
After I worked at my first system with disk drives I tried to avoid
using tapes but they were around for many years. At one site someone
decided to try assigning the compile work files to tape instead of disk.
That slowed down compiles considerably but it was the first time I got
to see a program that read tape files forward and backward.
On 2024-12-06 14:27, Freddy1X wrote:
Trog Woolley wrote:
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
I talk about punch cards and paper tape. Sometimes I ask if they have
seen old sci-fi films with the big tape wheels going around in the
background, and say I used to work with those.
Were those tape drives anything like the Lost in Space ones that had bubble >> heads and flex duct arms with clamp manipulators on the ends?
After all, there MUST have been SOME basis for the drives shown on the TV
show.
<https://en.wikipedia.org/wiki/Lost_in_Space>
Computers and tape drives were often depicted in various episodes using
the Burroughs 205 commercial products.
→ ><https://en.wikipedia.org/wiki/Burroughs_Corporation#References_in_popular_culture>
References in popular culture
Burroughs B205 hardware has appeared as props in many Hollywood
television and film productions from the late 1950s. For example, a B205 >console was often shown in the television series Batman as the Bat
Computer; also as the flight computer in Lost in Space. B205 tape drives >were often seen in series such as The Time Tunnel and Voyage to the
Bottom of the Sea.[19][20] Burroughs equipment was also featured in the >movie The Angry Red Planet.
7- and 9-track tape drives. We had one system with a string of 16
tape drives that was used to test the sort utility. The programmer
who wrote the utility leveraged the read-backwards capability of
the tape units to speed up the sort process.
On Thu, 05 Dec 2024 23:49:11 -0500, Dan Espen wrote:
At one site someone
decided to try assigning the compile work files to tape instead of disk.
That slowed down compiles considerably but it was the first time I got
to see a program that read tape files forward and backward.
Oh yes. There was an actual sort algorithm, called “merge sort”, that depended on reading/writing the records on multiple tape drives at once -- the more the merrier. Bidirectionality was important to avoid wasting time waiting for the whole tape to rewind. But you had to remember that the
order of the records was now reversed.
On Thu, 5 Dec 2024 22:51:43 -0000 (UTC), I wrote:
I can remember when mice still had balls.
I suppose I could have said “wheels”, but, you know, going for maximum fnarr-fnarr and all that ...
I can remember when you could either get a colour monitor, or a monitor
that showed text you could read.
(Excluding expensive high-end workstation stuff, of course.)
On 2024-12-05 23:53, Lawrence D'Oliveiro wrote:
I can remember when you could either get a colour monitor, or a monitor
that showed text you could read.
(Excluding expensive high-end workstation stuff, of course.)
I remember when computers used a TV for display, on an empty channel.
"Carlos E.R." <robin_listas@es.invalid> wrote in news:31o92lxcuk.ln2 @Telcontar.valinor:
On 2024-12-05 23:53, Lawrence D'Oliveiro wrote:
I can remember when you could either get a colour monitor, or a monitor
that showed text you could read.
(Excluding expensive high-end workstation stuff, of course.)
I remember when computers used a TV for display, on an empty channel.
My roommate at college and I both had large Apple }{+ systems with the TV monitors. The resulting braodcasts on different 3/4 channels allowed us to see each others screens from across the room. Both of us weren't allowed to use our computers during the schools football games because our computer transmissions bled onto the Color TV down the hall in the Rec Room where the house was watching the game.
According to Scott Lurndal <slp53@pacbell.net>:
7- and 9-track tape drives. We had one system with a string of 16
tape drives that was used to test the sort utility. The programmer
who wrote the utility leveraged the read-backwards capability of
the tape units to speed up the sort process.
That was a standard trick that sort programs used, but to pick a nit, it sped up
the merge process, not the sort process. When a file was too big to sort in memory, which was pretty much always in those days, first it read the input(s)
in batches that it sorted in memory and wrote out sorted "runs" of records alternately to the intermediate output devices. (The runs could be larger than
memory using a trick we'll save for the advanced seminar.) Then it merged the runs from one group of intermediate devices to another into ever larger runs until it ended up with one big sorted run.
Originally they rewound the intermediate tapes after each merge phase but someone, more likely several someones, realized they could just read the tapes
backward and reverse the sort comparisons, producing runs in reverse order that
could be read backward in the next phase, producing forward order runs. There was about a 50% chance that the final run would end up reversed, requiring one
more pass to read it backwards and write out a forward version, but the time saved not rewinding made it worthwhile. Or I suppose it could realize that it had written one run onto each of the intermediate tapes so the next merge would
be the last, and if needed rewind and merge forward for the last pass.
There was a lot of really clever programming in sort programs. Most were sort generators that precompiled the sort comparison rules into a machine code comparison routine that it could call during the sort passes rather than interpreting the rules on the fly.
On 2024-12-06 14:27, Freddy1X wrote:
Trog Woolley wrote:
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
I talk about punch cards and paper tape. Sometimes I ask if they have
seen old sci-fi films with the big tape wheels going around in the
background, and say I used to work with those.
Were those tape drives anything like the Lost in Space ones that had
bubble heads and flex duct arms with clamp manipulators on the ends?
After all, there MUST have been SOME basis for the drives shown on the TV
show.
/| I may be demented \|\|
Computers and tape drives were often depicted in various episodes using
the Burroughs 205 commercial products.
In my data structures class, one assignment was to write a tape
sort.
I can remember when mice still had balls.
Dan Espen <dan1espen@gmail.com> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Thu, 05 Dec 2024 14:51:24 -0500, Dan Espen wrote:
The first systems I worked on used multiple tape drives.
Remember how computers used to be portrayed in movies and TV, well into >>> the 1980s, with banks of multiple tape drives where the reels would go
start-stop-start-stop?
Yep. Tapes spinning and sometimes cards being read.
After I worked at my first system with disk drives I tried to avoid
using tapes but they were around for many years. At one site someone
decided to try assigning the compile work files to tape instead of disk.
That slowed down compiles considerably but it was the first time I got
to see a program that read tape files forward and backward.
There were a lot of neat things done with tape. Tape sorts were fun, too.
On Thu, 05 Dec 2024 16:11:12 -0500, Rich Alderson wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
Burroughs had a number of early drives (Drum, HPT, etc) before my time. >>>> They had a 3330 clone (called 235) and the 3350 lookalikes (called
677) actually came from Memorex (which Burroughs acquired at some
point).
The Memorex 677 was the 3330-11 clone, also used in the DEC RP06. I've
actually done a head alignment on one of those (and remember, I'm a
software/ admin guy).
The IBM 3330-11 had two stacked drives for each unit in the
string. The 3350 is a washing machine style drive.
https://commons.wikimedia.org/wiki/File:IBM_magnetic_disk_drives_3330%2B3333.png
The burrough equivalent was the 225 and later 235 disk subsystems.
The Burroughs/Memorex 677 was a washing machine-style top-loader
single drive.
$ wget https://mrxhist.org/docs/MRX%2019820607%20OEM%20Drives%20EN.pdf
" Rounding out the Memorex
display will be its M o d e l 677
removable-pack 14-inch drive.
The M o d e l 677 is a 300-Mbyte
drive with an SMD interface and
an average access time of 28 mil-
liseconds. OEM-quantity price
is said to be less than $10,000."
The pictures of the RP06 match the 677 style, not the 3330 dual stacked subsystem.
Not sure what you mean by "washing machine style", here.
I can remember when you could either get a colour monitor, or a monitor
that showed text you could read.
(Excluding expensive high-end workstation stuff, of course.)
scott@slp53.sl.home (Scott Lurndal) writes:
Burroughs had a number of early drives (Drum, HPT, etc) before
my time. They had a 3330 clone (called 235) and the 3350
lookalikes (called 677) actually came from Memorex (which Burroughs
acquired at some point).
The Memorex 677 was the 3330-11 clone, also used in the DEC RP06. I've actually done a head alignment on one of those (and remember, I'm a software/ admin guy).
On Thu, 05 Dec 2024 23:49:11 -0500, Dan Espen wrote:
At one site someone
decided to try assigning the compile work files to tape instead of disk.
That slowed down compiles considerably but it was the first time I got
to see a program that read tape files forward and backward.
Oh yes. There was an actual sort algorithm, called “merge sort”, that depended on reading/writing the records on multiple tape drives at once -- the more the merrier. Bidirectionality was important to avoid wasting time waiting for the whole tape to rewind. But you had to remember that the
order of the records was now reversed.
On Wed, 4 Dec 2024 02:06:49 -0000 (UTC), Lawrence D'Oliveiro wrote:
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
If my memory serves me right it was 64 KB.
On Thu, 05 Dec 2024 14:51:24 -0500, Dan Espen wrote:
The first systems I worked on used multiple tape drives.
Remember how computers used to be portrayed in movies and TV, well into
the 1980s, with banks of multiple tape drives where the reels would go start-stop-start-stop?
The central computer facility where I worked had I think only one tape drive, used only for backup. By that time they were “streaming” drives, which meant, if you fed them fast enough (which you could, since the disks were big enough and fast enough), they could run flat out, with no start- stop-start-stop. So I never saw that in the flesh, so to speak.
Freddy1X wrote:
David LaRue wrote:( cuts )
scott@slp53.sl.home (Scott Lurndal) wrote in
news:7H44P.55775$A9x9.24066@fx13.iad:
The clicks and buzzes of your floppy drives as they trundled along.( 8" of cource )
scott@slp53.sl.home (Scott Lurndal) wrote in news:7H44P.55775$A9x9.24066@fx13.iad:
Chris Ahlstrom <OFeem1987@teleworm.us> writes:
David LaRue wrote this post while blinking in Morse code:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote in news:viodfp$fp5p$2@dont- >>>> email.me:
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer >>>>> modifier keys on computer keyboards.
True! I loved the feel of the DECwriter LA-36 II keyboard. The
spacebar was below the other keys, in the center where it should be,
and no modifier keys on that row.
I had forgotten about the DECwriter!
I'll never forget when our ASR-33 was replaced with an LA-120. Three
times faster, and full-width greenbar.
For those of us who used dial-in connections, whistle the Break Command.
All together now!
It was quite a good merge: the drive light stayed on continuously with no flickering. The company was still using it a decade later, having ported
it to better operating systems.
I once came up with a wonderfully perverted use of the "read backward" command. I had a tape that was written with a block size of 9600 bytes, while the drives available to me could handle a block size of 8192 bytes
at the most. I wrote a program that would read a partial block
(ignoring length errors), followed by a read backward to get the
remaining bytes. Since this left you back at the start of the block,
you'd have to then issue a forward space command to skip over the block.
Lather, rinse, repeat. The drive sounded as if it was about to
explode, but it did successfully read the tape.
I programmed Univac gear, and one night while working in a 90/30 shop I popped the back cover off an RP06 on an 11/70 sharing the same room.
Imagine my surprise when I saw an ISS / Sperry Univac plate inside.
NO CARRIER
On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
I can remember when you could either get a colour monitor, or a monitor
that showed text you could read.
CGA vs. MDA (or Hercules if you wanted to do really beautiful
monochrome).
(Excluding expensive high-end workstation stuff, of course.)
That was a totally different world.
On Thu, 5 Dec 2024 22:51:43 -0000 (UTC), I wrote:
I can remember when mice still had balls.
I suppose I could have said “wheels”, but, you know, going for maximum fnarr-fnarr and all that ...
On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 05 Dec 2024 14:51:24 -0500, Dan Espen wrote:
The first systems I worked on used multiple tape drives.
Remember how computers used to be portrayed in movies and TV, well into
the 1980s, with banks of multiple tape drives where the reels would go
start-stop-start-stop?
The central computer facility where I worked had I think only one tape
drive, used only for backup. By that time they were “streaming” drives, >> which meant, if you fed them fast enough (which you could, since the disks >> were big enough and fast enough), they could run flat out, with no start-
stop-start-stop. So I never saw that in the flesh, so to speak.
But if you couldn't feed them data fast enough, they'd revert to start/stop >mode. A 100-ips streaming drive would run at 12.5 ips in start/stop mode - >much slower than conventional start/stop drives, which were available in >speeds from 25 to 200 ips, depending on how deep your pockets were.
I was testing a double-buffered load algorithm, that loaded from 9-track
to disk. I found a bug when loading from a 200ips 6250bpi drive to
one of the supported disk drives - that old drive was actually slower than the tape drive which caused the algo to overwrite the disk buffer while
it was being written. Added the missing wait for the disk write to complete before starting the tape read and all was good.
On Sat, 07 Dec 2024 02:30:48 GMT, Charlie Gibbs wrote:
I once came up with a wonderfully perverted use of the "read backward"
command. I had a tape that was written with a block size of 9600 bytes,
while the drives available to me could handle a block size of 8192 bytes
at the most. I wrote a program that would read a partial block
(ignoring length errors), followed by a read backward to get the
remaining bytes. Since this left you back at the start of the block,
you'd have to then issue a forward space command to skip over the block.
Lather, rinse, repeat. The drive sounded as if it was about to
explode, but it did successfully read the tape.
I’m trying to imagine what that sounded like, and I just can’t ...
On Sat, 07 Dec 2024 02:30:54 GMT, Charlie Gibbs wrote:
NO CARRIER
I can remember when a common Usenet meme† was to cut off a posting and end with “NO CARRIER” as a joke indication that the Men In Black had just broken in and spirited you away before you could reveal something That The World Was Not Ready To Know ...
†Only we didn’t (yet) call them memes in those days.
On 2024-12-07, Scott Lurndal <scott@slp53.sl.home> wrote:
I was testing a double-buffered load algorithm, that loaded from 9-track
to disk. I found a bug when loading from a 200ips 6250bpi drive to
one of the supported disk drives - that old drive was actually slower than >> the tape drive which caused the algo to overwrite the disk buffer while
it was being written. Added the missing wait for the disk write to complete
before starting the tape read and all was good.
I never did get to use 6250-bpi drives, or ones that ran at 200 ips.
I did find it interesting that such drives could boast transfer rates
faster than those of the disk drives of the day. That just didn't
seem right somehow.
Don't let your dog off leash! Oh no, he's headed for the road...
NO TERRIER
Dunno about drives (I don't know where ISS came from), but CDC made lots
of disk packs for various drives.
If you have a head crash, the only safe action is to immediately
quarantine both the drive and the pack where it happened. Some
operators weren't too bright, though; they'd move the crashed pack from
drive to drive, then try other packs. A few shops were completely wiped
out that way.
As much as people (especially Univac) liked to bad-mouth CDC packs,
it was just the first mount that you had to worry about. If the pack
mounted once, it would work forever.
I never did get to use 6250-bpi drives, or ones that ran at 200 ips. I
did find it interesting that such drives could boast transfer rates
faster than those of the disk drives of the day. That just didn't seem
right somehow.
On 2024-12-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 07 Dec 2024 02:30:48 GMT, Charlie Gibbs wrote:
I once came up with a wonderfully perverted use of the "read
backward" command. I had a tape that was written with a block size
of 9600 bytes, while the drives available to me could handle a
block size of 8192 bytes at the most. I wrote a program that would
read a partial block (ignoring length errors), followed by a read
backward to get the remaining bytes. Since this left you back at
the start of the block, you'd have to then issue a forward space
command to skip over the block. Lather, rinse, repeat. The drive
sounded as if it was about to explode, but it did successfully
read the tape.
I’m trying to imagine what that sounded like, and I just can’t ...
The UNISERVO VI-C tape drives I was using were noisy at the best of
times. In normal operation the vacuum pump shrieked like a jet engine.
I seem to recall that the drive was making a lot of hissing noises as
the tape shuttled back and forth under the heads, and the reel motors
were working like mad to keep the vacuum columns half full. I got the
tape copied, but it was a Timex torture test.
Head-movement latency probably explains that.
There was an earlier technology, called “magnetic drums”, where each track
had its own head. I remember a paper from a collection from a conference
on OS design, saying that, if you want to implement paging, don’t use disks, use drums. (The date “1973” comes to mind, but I’m pretty sure drums were obsolete by then.)
I think disks won out for cost/benefit reasons (and being more compact).
And then economies of scale led to them being improved more and more.
On Sat, 07 Dec 2024 19:34:42 GMT, Charlie Gibbs wrote:
I never did get to use 6250-bpi drives, or ones that ran at 200 ips. I
did find it interesting that such drives could boast transfer rates
faster than those of the disk drives of the day. That just didn't seem
right somehow.
Head-movement latency probably explains that.
There was an earlier technology, called “magnetic drums”, where each track
had its own head.
On 2024-12-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 07 Dec 2024 02:30:54 GMT, Charlie Gibbs wrote:
NO CARRIER
I can remember when a common Usenet meme† was to cut off a posting and
end with “NO CARRIER” as a joke indication that the Men In Black had
just broken in and spirited you away before you could reveal something
That The World Was Not Ready To Know ...
†Only we didn’t (yet) call them memes in those days.
Don't let your dog off leash! Oh no, he's headed for the road...
NO TERRIER
On September 15, 1965, I settled down at home in front of our Hallicrafters black and white television set to watch the premier
episode of Lost in Space. The tension is building as we are introduced
to the Robinson family and we fear for their lives as we discover the diabolical intentions of Dr. Smith. As the camera pans around the spacecraft, three Burroughs 205 consoles come into view controlling the Jupiter 2. Can you say, "Rolling on the Floor, Laughing Out Loud?"
→ <http://starringthecomputer.com/computer.php?c=45#73>
{there are some photos, of the consoles}
On 2024-12-05, Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
(Never went down the rabbit hole of trying to get the O-I to produce
musical effects on the radio.)
When I was a callow lad on a data centre tour, I saw an IBM 1620 demo
that did this. Later, in my first real job, I wrote a similar program
for the Univac 9300. A cow orker would often react to an unreasonable
change request by complaining, "What do they want us to do, make the
machine sing Old MacDonald?" Once I got the program working (which I
had done on the q.t.), I hid a transistor radio inside the machine near
the backplane, called him over to the machine, and ran the program,
which of course played Old MacDonald. The results were gratifying.
I wrote the program to read tune specifications from a card deck
so I could make it play anything.
The stuttery static on my radio as it attempted to reproduce the e-m
emanations from my Osborne I?
(Never went down the rabbit hole of trying to get the O-I to produce
musical effects on the radio.)
On Sat, 07 Dec 2024 19:34:42 GMT, Charlie Gibbs wrote:
I never did get to use 6250-bpi drives, or ones that ran at 200 ips. I
did find it interesting that such drives could boast transfer rates
faster than those of the disk drives of the day. That just didn't seem
right somehow.
Head-movement latency probably explains that.
There was an earlier technology, called “magnetic drums”, where each track
had its own head. I remember a paper from a collection from a conference
on OS design, saying that, if you want to implement paging, don’t use disks, use drums. (The date “1973” comes to mind, but I’m pretty sure drums were obsolete by then.)
I think disks won out for cost/benefit reasons (and being more compact).
And then economies of scale led to them being improved more and more.
On 2024-12-05, Freddy1X <freddy1X@indyX.netX> wrote:
Freddy1X wrote:
David LaRue wrote:( cuts )
scott@slp53.sl.home (Scott Lurndal) wrote in
news:7H44P.55775$A9x9.24066@fx13.iad:
The clicks and buzzes of your floppy drives as they trundled along.( 8" of >> cource )
I once saw an IBM 1130 in action. Nice sounds from its disk drive too.
On Sat, 07 Dec 2024 19:34:44 GMT, Charlie Gibbs wrote:
On 2024-12-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 07 Dec 2024 02:30:48 GMT, Charlie Gibbs wrote:
I once came up with a wonderfully perverted use of the "read
backward" command. I had a tape that was written with a block size
of 9600 bytes, while the drives available to me could handle a
block size of 8192 bytes at the most. I wrote a program that would
read a partial block (ignoring length errors), followed by a read
backward to get the remaining bytes. Since this left you back at
the start of the block, you'd have to then issue a forward space
command to skip over the block. Lather, rinse, repeat. The drive
sounded as if it was about to explode, but it did successfully
read the tape.
I’m trying to imagine what that sounded like, and I just can’t ...
The UNISERVO VI-C tape drives I was using were noisy at the best of
times. In normal operation the vacuum pump shrieked like a jet engine.
I seem to recall that the drive was making a lot of hissing noises as
the tape shuttled back and forth under the heads, and the reel motors
were working like mad to keep the vacuum columns half full. I got the
tape copied, but it was a Timex torture test.
Nothing like a chainsaw, then?
I mention that because I tried once, out of curiosity, to find out what track 1 on a CD-ROM sounded like on an audio CD player. It sounded like a chainsaw was cutting my speakers in half. I stopped it pretty quickly.
On Sat, 07 Dec 2024 19:34:42 GMT, Charlie Gibbs wrote:
I never did get to use 6250-bpi drives, or ones that ran at 200 ips. I
did find it interesting that such drives could boast transfer rates
faster than those of the disk drives of the day. That just didn't seem
right somehow.
Head-movement latency probably explains that.
There was an earlier technology, called “magnetic drums”, where each track
had its own head. I remember a paper from a collection from a conference
on OS design, saying that, if you want to implement paging, don’t use disks, use drums. (The date “1973” comes to mind, but I’m pretty sure drums were obsolete by then.)
I think disks won out for cost/benefit reasons (and being more compact).
And then economies of scale led to them being improved more and more.
... and a reel or two of
tape was easier to carry to another installation than a disk pack.
The sounds generated by the tape drive were mechanical, not electronic.
I did once hear a late-model tape drive being tested by the CEs - it was writing short blocks fast enough to create low-frequency tones.
I would love to have had some time alone with it - I'd have written a
program that would make it sing.
It was a good decade later that I learned about the "Tempest" security concern.
I suppose that Burroughs lent out their stuff for free in return for the implicit endorsement tht these are the computers of the future.
On Fri, 6 Dec 2024 15:07:46 +0100, Carlos E.R. wrote:
Computers and tape drives were often depicted in various episodes using
the Burroughs 205 commercial products.
Actually, the company making them was originally Electrodata, until they
were acquired by Burroughs. You only see these comparatively small
tabletop boxes with the control panels, though I think the actual
computers were bigger than that.
The most famous one is likely the IBM AN/FSQ-7, built for the multi- billion-dollar Air Force SAGE system, that was supposed to provide warning
of the approach of Soviet nuclear bombers. The entire system was commissioned, operated for about ten years, and then retired and
dismantled, without once being used in anger. (And some suggested it would never have worked anyway.)
But movie/TV art directors looking for techy/computery bits at bargain
prices bought loads of the components, and you could spot them in a great many productions for years afterwards.
On Sun, 8 Dec 2024 03:36:51 -0000 (UTC), Lars Poulsen wrote:
I suppose that Burroughs lent out their stuff for free in return for the
implicit endorsement tht these are the computers of the future.
No, I think by that time this was already old, decommissioned gear, with
the blinkenlights rewired for show purposes.
I once saw an IBM 1130 in action. Nice sounds from its disk drive too.
IIRC, that was the IBM 2311 disk drive.
There was an earlier technology, called “magnetic drums”, where each track
had its own head.
Which was followed by head-per-track disk. Burroughs had several models >culminating with the 5N storage subsystem. Single platter, vertically >mounted, pneumatically loaded heads on both sides of the platter.
On Sat, 07 Dec 2024 19:34:45 GMT, Charlie Gibbs wrote:
On 2024-12-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 07 Dec 2024 02:30:54 GMT, Charlie Gibbs wrote:
NO CARRIER
I can remember when a common Usenet meme† was to cut off a posting and >> end with “NO CARRIER” as a joke indication that the Men In Black had >> just broken in and spirited you away before you could reveal something
That The World Was Not Ready To Know ...
†Only we didn’t (yet) call them memes in those days.
Don't let your dog off leash! Oh no, he's headed for the road...
NO TERRIER
“PHP!? I refuse to work with such a crap language--”
NO CAREER
According to Lars Poulsen <lars@cleo.beagle-ears.com>:
I once saw an IBM 1130 in action. Nice sounds from its disk drive too.
IIRC, that was the IBM 2311 disk drive.
Probably not. The 1130 had a built in 2310 single platter drive. As
one of the many comprimises to make the 1130 cheap, the heads were
moved by a stepper motor that buzzed as it moved the head back and
forth slowly across the disk. You could add up to two more 2310s
or two 2311s, but I never saw an 1130 with 2311 drives.
According to the manual, the 2311 looked to the CPU like 3 or 5
single platter disks, depending on the model. I think the 1316
disk packs were physically the same as were used on S/360 but
they were formatted in fixed sized sectors, not CKD.
On Sun, 08 Dec 2024 04:52:16 GMT, Charlie Gibbs wrote:
... and a reel or two of
tape was easier to carry to another installation than a disk pack.
What were the standards for tape formats? There was an official “ANSI D format” (not sure about A, B or C), but as far as I know only DEC supported that.
According to Lars Poulsen <lars@cleo.beagle-ears.com>:
I once saw an IBM 1130 in action. Nice sounds from its disk drive too.
IIRC, that was the IBM 2311 disk drive.
Probably not. The 1130 had a built in 2310 single platter drive. As
one of the many comprimises to make the 1130 cheap, the heads were
moved by a stepper motor that buzzed as it moved the head back and
forth slowly across the disk. You could add up to two more 2310s
or two 2311s, but I never saw an 1130 with 2311 drives.
... the heads were moved by
a stepper motor that buzzed as it moved the head back and forth slowly
across the disk.
On 2024-12-06 21:11, Lawrence D'Oliveiro wrote:
But movie/TV art directors looking for techy/computery bits at bargain
prices bought loads of the components, and you could spot them in a
great many productions for years afterwards.
Hard to imagine moving robots with tape drives, though. Even back then, methinks.
On 06 Dec 2024 18:48:24 -0500, Rich Alderson wrote:
Not sure what you mean by "washing machine style", here.
Removable drive, I presume. They were all top-loaders.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Removable drive, I presume. They were all top-loaders.
The 3350/RP07 was NOT a top-loader.
On 2024-12-08, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 08 Dec 2024 04:52:16 GMT, Charlie Gibbs wrote:
... and a reel or two of
tape was easier to carry to another installation than a disk pack.
What were the standards for tape formats? There was an official “ANSI D >> format” (not sure about A, B or C), but as far as I know only DEC
supported that.
The machines I worked on were IBM 360 clones, so they had their own set
of formats. All data was coded using EBCDIC, not ASCII. A standard
labeled tape had the following format:
VOL1 label (80 bytes, contained volume ID, etc.)
HDR1 label (80 bytes, contained file name, etc.)
HDR2 label (80 bytes, optional, not used that often)
Tape mark
First file's data blocks
Tape mark
HDR1 label for second file, if presentTape mark
Second file's data blocks, if present
Tape mark
Tape mark (Two consecutive tape marks indicated the end of all data.)
On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
I can remember when you could either get a colour monitor, or a monitor
that showed text you could read.
CGA vs. MDA (or Hercules if you wanted to do really beautiful monochrome). The other drawback to CGA was that it was _slow_. The word processor
package we used (Samna Word III, IIRC) ran slowly enough that a good
typist could stay a word ahead of the display.
The CGA in my first computer, an Amstrad PC 1512 DD, was fast,
certainly much faster than what you describe.
According to Charlie Gibbs <cgibbs@kltpzyxm.invalid>:
VOL1 label (80 bytes, contained volume ID, etc.)
HDR1 label (80 bytes, contained file name, etc.)
HDR2 label (80 bytes, optional, not used that often)
Tape mark
First file's data blocks
Tape mark
I'm reasonably sure there was a label group at the end of the file:
EOF1 label (80 bytes, like HDR1)
EOF2 label (80 bytes, optional)
Tape mark
If the file was too big for one tape, there was EOV1 and EOV2 at the end
of all but the last tape instead of EOF1 and EOF2.
For all the gory details, see Appendix E:
https://bitsavers.org/pdf/ibm/360/os/R01-08/C28-6541-1_Control_Program_Services_Apr66.pdf
I can remember when friendly error messages were a new thing.
I remember encountering LOGO on an Apple II. When it hit an I/O error on
the floppy, instead of the usual message about an “I/O error”, it said “I’m having trouble reading the disk”.
It was like a breath of fresh air.
You had to be there, I guess ...
When I was a callow lad on a data centre tour, I saw an IBM 1620 demo
that did this. Later, in my first real job, I wrote a similar program
for the Univac 9300. A cow orker would often react to an unreasonable
change request by complaining, "What do they want us to do, make the
machine sing Old MacDonald?" Once I got the program working (which I
had done on the q.t.), I hid a transistor radio inside the machine near
the backplane, called him over to the machine, and ran the program,
which of course played Old MacDonald. The results were gratifying.
I wrote the program to read tune specifications from a card deck
so I could make it play anything.
On Sat, 07 Dec 2024 19:34:44 GMT, Charlie Gibbs wrote:
The UNISERVO VI-C tape drives I was using were noisy at the best of
times. In normal operation the vacuum pump shrieked like a jet engine.
I seem to recall that the drive was making a lot of hissing noises as
the tape shuttled back and forth under the heads, and the reel motors
were working like mad to keep the vacuum columns half full. I got the
tape copied, but it was a Timex torture test.
Nothing like a chainsaw, then?
I mention that because I tried once, out of curiosity, to find out
what track 1 on a CD-ROM sounded like on an audio CD player. It
sounded like a chainsaw was cutting my speakers in half. I stopped
it pretty quickly.
The original? IBM PC mouse had a single ball. A colleague wrote a
procedure for de-fluffing the 2 tracker wheels to ensure smooth
operation. It was a masterpiece of innuendo.
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
The original? IBM PC mouse had a single ball. A colleague wrote a
procedure for de-fluffing the 2 tracker wheels to ensure smooth
operation. It was a masterpiece of innuendo.
Fluff? My ball meeses acquired lumpy scum on the wheels, requiring
use of a dental pick and a magnification lamp to clean up. Tedious, irritating procedure.
Scott Lurndal <scott@slp53.sl.home> wrote:em
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Sat, 07 Dec 2024 19:34:42 GMT, Charlie Gibbs wrote:
=20
I never did get to use 6250-bpi drives, or ones that ran at 200 ips. I >>> did find it interesting that such drives could boast transfer rates
faster than those of the disk drives of the day. That just didn't se=
=9D, where each track=20right somehow.=20
Head-movement latency probably explains that.
=20
There was an earlier technology, called =E2=80=9Cmagnetic drums=E2=80=
You startled me - the only Bryant this UK poster knows of was partnered=20had its own head.=20=20
Which was followed by head-per-track disk. Burroughs had several models culminating with the 5N storage subsystem. Single platter, vertically mounted, pneumatically loaded heads on both sides of the platter.
=20
No seek time component in the access time. Used for the MCP and
for high-speed access to temporary files. One of our production
machines had a string of those and they were used until 1991
(in part due to performance, in part due to the need to test
backward compatibility with newer MCPs).
=20
Same as the RAD on the XDS Sigma systems. Manufactured by Bryant, I
believe.
=20
On Sun, 8 Dec 2024 19:54:22 -0700
Peter Flass <peter_flass@yahoo.com> wrote:
Scott Lurndal <scott@slp53.sl.home> wrote:You startled me - the only Bryant this UK poster knows of was partnered
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Sat, 07 Dec 2024 19:34:42 GMT, Charlie Gibbs wrote:
I never did get to use 6250-bpi drives, or ones that ran at 200 ips. I >>>>> did find it interesting that such drives could boast transfer rates
faster than those of the disk drives of the day. That just didn't seem >>>>> right somehow.
Head-movement latency probably explains that.
There was an earlier technology, called “magnetic drumsâ€, where each track
had its own head.
Which was followed by head-per-track disk. Burroughs had several models >>> culminating with the 5N storage subsystem. Single platter, vertically
mounted, pneumatically loaded heads on both sides of the platter.
No seek time component in the access time. Used for the MCP and
for high-speed access to temporary files. One of our production
machines had a string of those and they were used until 1991
(in part due to performance, in part due to the need to test
backward compatibility with newer MCPs).
Same as the RAD on the XDS Sigma systems. Manufactured by Bryant, I
believe.
with a Mr May to make matches.
https://en.wikipedia.org/wiki/Bryant_%26_May
In article <6afh2lx6o4.ln2@Telcontar.valinor>, robin_listas@es.invalid (Carlos E.R.) wrote:
The CGA in my first computer, an Amstrad PC 1512 DD, was fast,
certainly much faster than what you describe.
The original IBM PC always had its video card in expansion slots. The PC
1512 was considerably faster (8MHz 8086 vs 4.77MHz 8088) and I think the
CGA circuitry was part of the motherboard, allowing it to run at CPU
speed.
I can remember when mice still had balls.
According to Scott Lurndal <slp53@pacbell.net>:
There was an earlier technology, called “magnetic drums”, where each track
had its own head.
Which was followed by head-per-track disk. Burroughs had several models >>culminating with the 5N storage subsystem. Single platter, vertically >>mounted, pneumatically loaded heads on both sides of the platter.
Drum storage is remarkably old, invented in Austria in 1932. I believe it was >adapted from grinding drums which had already been developed to spin at high >speed with very tight tolerances.
They were used for main storage in some computers in the 1950s including the >Electrodata 205, which has come up in other discussion here, and the very >popular (for the time) IBM 650.
... an appendix in this one says how DOS used them:
My ball meeses acquired lumpy scum on the wheels, requiring use
of a dental pick and a magnification lamp to clean up. Tedious,
irritating procedure.
On 2024-12-05 23:51, Lawrence D'Oliveiro wrote:
I can remember when mice still had balls.
Now that I think, my first mouse had a steel ball covered in rubber. It
came with my Amstrad PC, I think.
I think the rubber covering had a tiny hole.
And that rubber will degrade eventually and kill the mouse.
On Sat, 07 Dec 2024 19:34:45 GMT, Charlie Gibbs wrote:
=20
Don't let your dog off leash! Oh no, he's headed for the road...=20
=20
NO TERRIER =20
That=E2=80=99s terrible.
=20
It=E2=80=99s worthy of some of the postings on Bluesky.
On 08 Dec 2024 19:21:03 -0400
Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
"Kerr-Mudd, John" <admin@127.0.0.1> writes:I was trying (too hard) for an euphemism; it was dead skin, dried coffee, crumbs etc. I, of course, used the standard office utility tool - the
The original? IBM PC mouse had a single ball. A colleague wrote a
procedure for de-fluffing the 2 tracker wheels to ensure smooth
operation. It was a masterpiece of innuendo.
Fluff? My ball meeses acquired lumpy scum on the wheels, requiring
use of a dental pick and a magnification lamp to clean up. Tedious,
irritating procedure.
unbent paperclip.
Rich Alderson <news@alderson.users.panix.com> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On 06 Dec 2024 18:48:24 -0500, Rich Alderson wrote:
Not sure what you mean by "washing machine style", here.
Removable drive, I presume. They were all top-loaders.
The 3350/RP07 was NOT a top-loader. It was a Winchester.
Sealed HDA, but still a top loader.
On Mon, 9 Dec 2024 03:42:28 -0000 (UTC), John Levine wrote:
... an appendix in this one says how DOS used them:
That’s another way to say how old you are: how many operating systems can you think of that were named “DOS”, that, say, predate Apple DOS?
(i.e. way before Microsoft pre-empted the term ...)
On 12/9/24 13:50, Lawrence D'Oliveiro wrote:
On Mon, 9 Dec 2024 03:42:28 -0000 (UTC), John Levine wrote:
... an appendix in this one says how DOS used them:
That’s another way to say how old you are: how many operating systems
can you think of that were named “DOS”, that, say, predate Apple DOS?
(i.e. way before Microsoft pre-empted the term ...)
IBM System 360 DOS
Peter Flass <peter_flass@yahoo.com> writes:
Rich Alderson <news@alderson.users.panix.com> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On 06 Dec 2024 18:48:24 -0500, Rich Alderson wrote:
Not sure what you mean by "washing machine style", here.
Removable drive, I presume. They were all top-loaders.
The 3350/RP07 was NOT a top-loader. It was a Winchester.
Sealed HDA, but still a top loader.
We clearly have different definitions of "top loader".
Winchester drives do not have removable media, so there is nothing
loaded into the drive, whether from the top or any other direction.
To me, "top loader" implies loadable media, like the IBM 1311, 2311,
3330, and 3330-11, and similar CDC and Memorex drives.
The IBM 3340 was the original "Winchester" drive. Its code name was interited by a number of successors which had non-removable media -
but the original 3340 had a removable data module consisting of disks,
heads, and arms; the entire module was lowered into the drive from the
top. The photo here:
https://www.computerhistory.org/revolution/memory-storage/8/259/1043
shows a string of IBM 3340 drives with a data module sitting on top
of one of them. The top and front panels were hinged and swung up
to allow a data module to be loaded or unloaded.
Subsequent "Winchester" drives (e.g. 3350 and 3370) had non-removable
data modules, but the 3340 - the father of them all - was the last of
the top-loaders.
On 2024-12-05, Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
The stuttery static on my radio as it attempted to reproduce the e-m
emanations from my Osborne I?
(Never went down the rabbit hole of trying to get the O-I to produce
musical effects on the radio.)
This was about a decade and a half before we really worried about EMC (Electromagnetic Compatibility). RF interference was rampant, but out of computers and into them.
When we set up the regional academic computer center at Copenhagen
University (RECKU) at the Niels Bohr Institute on Blegdamsvej, our shiny
new Univac 1106 would not run. Some investigation revealed that this was because of a Medium Wave AM transmitter for the Danish Broadcasting
service was located a couple of blocks away, The "cure" was to wallpaper
the computer room with a layer of (grounded) copper foil. (1971?)
It was a good decade later that I learned about the "Tempest" security concern. And just a couple of years after that, that these concerns came
into the office world with PCs, and PCB designers learned how to lay out motherboards so that they would be "EMC clean".
On 2024-12-05, Carlos E.R. <robin_listas@es.invalid> wrote:
On 2024-12-05 15:07, Freddy1X wrote:
Freddy1X wrote:
David LaRue wrote:( cuts )
scott@slp53.sl.home (Scott Lurndal) wrote in
news:7H44P.55775$A9x9.24066@fx13.iad:
The clicks and buzzes of your floppy drives as they trundled along.( 8" of >>> cource )
The clicks and buzzes of the hard disk step motor on my PC.
https://www.youtube.com/watch?v=kCCXRerqaJI
Or just type "floppy drive music" into YouTube's search bar.
On Sun, 8 Dec 2024 18:38:55 -0000 (UTC), John Levine wrote:
... the heads were moved by
a stepper motor that buzzed as it moved the head back and forth slowly
across the disk.
Another way to say how old you are: you remember the noise a floppy drive made when it hit an I/O error. One of the first things the OS driver would
do to try to recover was ensure the head was on the right track, and then
try the I/O again. But, to keep costs down, the drive hardware didn’t actually keep track of which track it was on. So you fed in enough step pulses to ensure the head was all the way back to the rest position,
before stepping back to the position you thought you were on.
Since the head was more than likely already somewhere in the middle of all the tracks, there would be leftover step pulses that did nothing more than just bang the head against the stop. This bang-bang-bang was typically
fast enough to sound like a buzzing. So if you heard this, you knew there
was trouble.
On Mon, 9 Dec 2024 23:09:13 -0500, geodandw wrote:
On 12/9/24 13:50, Lawrence D'Oliveiro wrote:
On Mon, 9 Dec 2024 03:42:28 -0000 (UTC), John Levine wrote:
... an appendix in this one says how DOS used them:
That's another way to say how old you are: how many operating systems
can you think of that were named "DOS", that, say, predate Apple DOS?
(i.e. way before Microsoft pre-empted the term ...)
IBM System 360 DOS
Was that the first?
This was back when disks were new, and computer OSes typically took input
on punched cards or paper tape, and output to same or to printers, with
some use of magnetic tape drives. So operating systems which added support for these newfangled disk things were distinguished as "disk operating systems".
When the System/360 was announced, there was going to be a single operating >system for all of the models, OS/360.
That ran into the well known issues covered in Brooks. As stopgaps, IBM >quickly produced smaller operating systems (Basic OS, Tape OS, Disk OS) and an >even more primitive card only run time system (Basic Programming Support). >These were abbreviated BOS, TOS, DOS, and BPS.
They were distinguished from each other, but ALL WERE BRAND NEW. There was no >particular history that had to be distinguished for disk operating systems, >just the presence of disks.
That ran into the well known issues covered in Brooks. As stopgaps, IBM RA>>quickly produced smaller operating systems (Basic OS, Tape OS, Disk OS) and an
even more primitive card only run time system (Basic Programming Support). RA>>These were abbreviated BOS, TOS, DOS, and BPS.
They were distinguished from each other, but ALL WERE BRAND NEW. There was no
particular history that had to be distinguished for disk operating systems, RA>>just the presence of disks.
I think you're both basically right. DOS and TOS were largely the same except
that TOS ran from tape, and DOS needed a disk with tapes optional. DOS and TOS
needed 16K of core (it was all core at the time) while BOS only needed 8K but
also needed a disk. I presume there was no tape version of BOS because BOS had
to load tiny overlays which would have been impractical from tape.
On 2024-12-11, John Levine <johnl@taugh.com> wrote:
I think you're both basically right. DOS and TOS were largely the same except
that TOS ran from tape, and DOS needed a disk with tapes optional. DOS and TOS
needed 16K of core (it was all core at the time) while BOS only needed 8K but
also needed a disk. I presume there was no tape version of BOS because BOS had
to load tiny overlays which would have been impractical from tape.
I assume that the initial coding was supported by cross-compilers and >assemblers running on either 1401/1440 or 7090 IBSYS/IBJOB?
Was there an emulator also, and which of these environments was the
primary development support?
How early were the system call data structures defined, and were they
the same for the early "shortcut" systems?
(Some of this may be reflected in differences between DOS/360 and OS/360 >structures such as DCBs - who here has used both? And do we have anyone
who was there during this phase?)
How early were the system call data structures defined, and were they
the same for the early "shortcut" systems?
(Some of this may be reflected in differences between DOS/360 and OS/360 structures such as DCBs - who here has used both? And do we have anyone
who was there during this phase?)
geodandw <geodandw@gmail.com> wrote:
On 12/9/24 13:50, Lawrence D'Oliveiro wrote:
On Mon, 9 Dec 2024 03:42:28 -0000 (UTC), John Levine wrote:
... an appendix in this one says how DOS used them:
That’s another way to say how old you are: how many operating systems can
you think of that were named “DOS”, that, say, predate Apple DOS?
(i.e. way before Microsoft pre-empted the term ...)
IBM System 360 DOS
That was the one true DOS, but everyone had a “dos”. I know DG had one.
Lars Poulsen <lars@cleo.beagle-ears.com> wrote:
According to Rich Alderson <news@alderson.users.panix.com>:
That ran into the well known issues covered in Brooks. As stopgaps, IBM >>>> quickly produced smaller operating systems (Basic OS, Tape OS, Disk OS) and an
even more primitive card only run time system (Basic Programming Support). >>>> These were abbreviated BOS, TOS, DOS, and BPS.
They were distinguished from each other, but ALL WERE BRAND NEW. There was no
particular history that had to be distinguished for disk operating systems,
just the presence of disks.
On 2024-12-11, John Levine <johnl@taugh.com> wrote:
I think you're both basically right. DOS and TOS were largely the same except
that TOS ran from tape, and DOS needed a disk with tapes optional. DOS and TOS
needed 16K of core (it was all core at the time) while BOS only needed 8K but
also needed a disk. I presume there was no tape version of BOS because BOS had
to load tiny overlays which would have been impractical from tape.
I assume that the initial coding was supported by cross-compilers and
assemblers running on either 1401/1440 or 7090 IBSYS/IBJOB?
Was there an emulator also, and which of these environments was the
primary development support?
How early were the system call data structures defined, and were they
the same for the early "shortcut" systems?
(Some of this may be reflected in differences between DOS/360 and OS/360
structures such as DCBs - who here has used both? And do we have anyone
who was there during this phase?)
DOS has DTFs. There’s basically no resemblance between OS and DOS except that the JCL begins with //.
I didn't work on actual IBM systems - and I'll gladly defer to anyone
who shows up with actual experience - but I did a lot of work on Univac's low-end IBM workalikes (9200, 9300, and 9400, which roughly correspond
to the 360 models 20, 30, and 40), for what it's worth.
DOS has DTFs. There’s basically no resemblance between OS and DOS except >> that the JCL begins with //.
So no level of binary compatibility?
All the compilers etc required an active porting effort?
On Sat, 07 Dec 2024 02:30:54 GMT, Charlie Gibbs wrote:
NO CARRIER
I can remember when a common Usenet meme† was to cut off a posting and end with “NO CARRIER” as a joke indication that the Men In Black had just broken in and spirited you away before you could reveal something That The World Was Not Ready To Know ...
†Only we didn’t (yet) call them memes in those days.
I dunno I'd be into somewhere that gets regularly covered by Southern CaliforniaI don't consider anyplace that regularly gets covered by snow inhabitable.Oddly enough, I feel much the same way about Southern California.
On 2024-12-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 07 Dec 2024 02:30:54 GMT, Charlie Gibbs wrote:
NO CARRIER
I can remember when a common Usenet meme† was to cut off a posting and
end with “NO CARRIER” as a joke indication that the Men In Black had
just broken in and spirited you away before you could reveal something
That The World Was Not Ready To Know ...
†Only we didn’t (yet) call them memes in those days.
We're facing an enemy fleet at sea!
NO CARRIER
some of the MIT CTSS people went to the 5th flr and did multics (which
begat unix) and others went to the IBM science center on the 4th flr
that modified 360/40 adding virtual memory and did CP40/CMS (with some
amount of CTSS history in both Unix and CMS), CP40/CMS morphs into
CP67/CMS when 360/67 standard with virtual memory becomaes availabe
... along with 64kbytes of os/360 simulation code (so they could run
os/360 assembler, compilers and execution). Later when decision was made
to add virtual memory to all 370s, CP67/CMS morphs into VM370/CMS.
I had taken two credit hr intro to fortran/comuters (univ. had 709 ibsys tape->tape with 1401 unit record front-end) and at the end of semester
was hired to rewrite 1401 MPIO (709 unit record front end) for 360/30
os/360 (360/30 with 1401 emulation replaced 1401 temporarily pending
arrival of 360/67 for tss/360, as way of getting some 360 experience).
Univ. shutdown datacenter on weekends and I would have the whole place
to myself (although 48hrs w/o sleep made monday classes hard).
I was given a bunch of hardware&software manuals and got to design and implement ...
I was given a bunch of hardware&software manuals and got to design and implement my own monitor, device drivers, interrupt handlers, error
recovery, storage management, etc and within a few weeks had a 2000 card assembler program (place BPS loader on front with os/360 assembled txt
deck behind) that could do concurrent card->tape and
tape->printer/punch. I then modified with assembler option that either generated the stand-alone monitor or an OS/360 (system services)
version. The stand alone version took 30mins to assemble, the OS/360
version took an hour to assemble (each DCB macro took 5-6mins).
I would compare (card->)tapes generated by (360/30) emulated 1401 MPIO
and generated by my 360 rewritten MPIO. 709->tape could be intermixed
printer and punch output and punch output could be intermixed BCD and "binary" (two 6-bit "bytes" in one 12row column).
Within a year of taking intro class, the 360/67 arrives and I was hired fulltime responsible of OS/360 (tss/360 didn't come to production so ran
as 360/65 with os/360). Student Fortran had run in under second on 709,
but initially with os/360 ran over a minute. I install HASP and cut the
time in half.
I then start redoing OS/360 STAGE2 SYSGEN to carefully
place datasets and PDS members to optimizing arm seek and multi-track
search, cutting another 2/3rds to 12.9secs ... never got better than 709 until I install univ. of waterloo WATFOR.
....
According to Lars Poulsen <lars@cleo.beagle-ears.com>:
DOS has DTFs. There’s basically no resemblance between OS and DOS except >>> that the JCL begins with //.
So no level of binary compatibility?
The compiler object formats and subroutine calling sequences were the
same so you could share code that didn't make system calls, although
the load module formats were different. You'd have to relink them,
but you'd have to relink them anyway with the OS dependent parts of
the programs.
All the compilers etc required an active porting effort?
Yes, although I would think the I/O sections of most compilers are a
small amount of the overall code. It was probably more work dealing
with the overlay structures > to make them fit into the tiny memories.
They had to squeeze pretty hard to get a Fortran compiler into a 16K
machine of which only 10K was available to the compiler.
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
Hi Lynn,
Over the years I have been reading these snippets from your long and
amazing carreer, and I think it is time you edited them into a book, in chronological order, and with some footnotes and pictures. I would buy
it, and I can't be the only one. I have started such a memoir myself,
just for my family, and although I am nowhere near complete yet (it
currently stops just before I met my present wife) I have shared it with
my brothers, my daughter and a couple of my wife's siblings. I have
found the time spent writing very rewarding.
This is where I would have hoped that the shared roots could haveSo no level of binary compatibility? ...
allowed the I/O SVCs to have some compatibility, and maybe share the
layout of the userland supporting structures.
But maybe the IBM I/O architecture means that the Unix low level >open/read/write/rewind/close layer relates differently to source layers?
On Wed, 11 Dec 2024 11:43:54 -0700, Peter Flass wrote:
geodandw <geodandw@gmail.com> wrote:
IBM System 360 DOS
That was the one true DOS, but everyone had a "dos". I know DG had one.
Just looking through the file names on Bitsavers, I saw DEC had a DOS for the PDP-15, and a DOS/BATCH for the PDP-11.
Am Wed, 4 Dec 2024 02:06:49 -0000 (UTC) schrieb Lawrence D'Oliveiro <ldo@nz.invalid>:
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
I didn't remember the spacebar length on the IBM 26 cardpunch or on an
IBM 2260 terminal, but I do remember that I didn't like those keyboards, compared to the electric typewriter I learned ten finger typewriting on.
The IBM 2260 <https://en.wikipedia.org/wiki/IBM_2260> didn't have what
later was called n-key rollover. Instead, it had something similar to
what is called "kugelsperre" in German, a somewhat overengineered
mechanical interlock, where pushing one key down blocked all other keys mechanically.
On 12 Dec 2024 07:13:16 GMT, Niklas Karlsson wrote:
On 2024-12-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 07 Dec 2024 02:30:54 GMT, Charlie Gibbs wrote:
NO CARRIER
I can remember when a common Usenet meme† was to cut off a posting and >>> end with “NO CARRIER” as a joke indication that the Men In Black had >>> just broken in and spirited you away before you could reveal something
That The World Was Not Ready To Know ...
†Only we didn’t (yet) call them memes in those days.
We're facing an enemy fleet at sea!
NO CARRIER
How about this version:
We’re facing an enemy fleet at sea!
Quick! Launch the fighter pla--
NO CARRIER
But I think Multics was Honeywell ...
Application programs had
to deal with details of the physical I/O devices like tracks and
cylinders and blocking multiple logical records into physical ones.
The IBM 2260 <https://en.wikipedia.org/wiki/IBM_2260> didn't have what
later was called n-key rollover. Instead, it had something similar to
what is called "kugelsperre" in German, a somewhat overengineered
mechanical interlock, where pushing one key down blocked all other keys mechanically.
DOS/360 dates to 1965. The DG and DEC operating sytems are several years later.
The hardware was originally from GE, which later sold its entire computer business (along with Multics) to Honeywell.
The machine was a GE 635 with extra special paging hardware to accommodate Multics’ advanced memory-management requirements. This enhanced machine was dubbed the “GE 645”.
On Thu, 12 Dec 2024 19:53:23 -0000 (UTC), John Levine wrote:
Application programs had
to deal with details of the physical I/O devices like tracks and
cylinders and blocking multiple logical records into physical ones.
One of the breakthroughs with Unix is that it moved all these headaches
into the OS kernel.
On 2024-12-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
The machine was a GE 635 with extra special paging hardware to
accommodate Multics’ advanced memory-management requirements. This
enhanced machine was dubbed the “GE 645”.
So similar technology as the GE 635 dial-in BASIC time-sharing system commercially deployed in service bureaus at the time. Seems very
ambitious to modify it with all the segmentation and security stuff that underpinned Multics. I would have thought that needed much faster
hardware.
On Thu, 12 Dec 2024 19:53:23 -0000 (UTC), John Levine wrote:
Application programs had
to deal with details of the physical I/O devices like tracks and
cylinders and blocking multiple logical records into physical ones.
One of the breakthroughs with Unix is that it moved all these headaches
into the OS kernel.
In IBM DOS systems the DTF macro generated the channel program. In OS
systems the channel program was built dynamically at OPEN time. This
allowed the user program to do a lot of fiddling with the DCB before
opening the dataset.
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
On Thu, 12 Dec 2024 19:53:23 -0000 (UTC), John Levine wrote:
Application programs had to deal with details of the physical I/O
devices like tracks and cylinders and blocking multiple logical
records into physical ones.
One of the breakthroughs with Unix is that it moved all these headaches
into the OS kernel.
Unix had the good fortune to be a few years later, when it was apparent
to everyone that disks all had fixed size power of two blocks and CKD
was a mistake.
But it was hardly a breakthrough. Multics totally abstracted I/O away
by moving it into the pager. You mapped in a segment, any disk action
was a side effect.
In Multics, “files” actually WERE unstructured streams of bytes.
On Thu, 12 Dec 2024 16:08:06 -0700, Peter Flass wrote:
In IBM DOS systems the DTF macro generated the channel program. In OS
systems the channel program was built dynamically at OPEN time. This
allowed the user program to do a lot of fiddling with the DCB before
opening the dataset.
I’m sure it was possible to implement your own version of the operation of the DTF macro that did all the work at run time.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 11 Dec 2024 11:43:54 -0700, Peter Flass wrote:
geodandw <geodandw@gmail.com> wrote:
IBM System 360 DOS
That was the one true DOS, but everyone had a "dos". I know DG had
one.
Just looking through the file names on Bitsavers, I saw DEC had a DOS
for the PDP-15, and a DOS/BATCH for the PDP-11.
DOS/360 dates to 1965. The DG and DEC operating sytems are several
years later.
Scott Lurndal <scott@slp53.sl.home> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:In Multics, “files” actually WERE unstructured streams of bytes.
On Thu, 12 Dec 2024 19:53:23 -0000 (UTC), John Levine wrote:
Application programs had to deal with details of the physical I/O
devices like tracks and cylinders and blocking multiple logical
records into physical ones.
One of the breakthroughs with Unix is that it moved all these
headaches into the OS kernel.
Burroughs had all those "headaches" in the MCP from the start. Long
before Unix. It was hardly a breakthrough 15 years later. Burroughs
also had avrec from the start, where if a new tape came on line and a
program was waiting for a tape with that label, it would be
automatically assigned to the waiting application. No operator
intervention required.
The idea of the OS treating a file as an unstructured stream of bytes,
now that's a unix innovation.
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
On Thu, 12 Dec 2024 19:53:23 -0000 (UTC), John Levine wrote:
Application programs had to deal with details of the physical I/O
devices like tracks and cylinders and blocking multiple logical
records into physical ones.
One of the breakthroughs with Unix is that it moved all these headaches >>into the OS kernel.
Unix had the good fortune to be a few years later, when it was apparent
to everyone that disks all had fixed size power of two blocks and CKD
was a mistake.
But it was hardly a breakthrough. Multics totally abstracted I/O away
by moving it into the pager. You mapped in a segment, any disk action
was a side effect.
Drum storage is remarkably old, invented in Austria in 1932. I believe it was >adapted from grinding drums which had already been developed to spin at high >speed with very tight tolerances.
On Wed, 18 Dec 2024 01:17:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
I can remember when CPUs needed coprocessors just to do floating point.
Ah, the 8087... Then there was the i486SX, the cheap version of the >i486DX. Intel said they disabled the FPU but the industry rumor said they >were really the fallout of DX processors where the FPU failed in testing.
I can remember when CPUs needed coprocessors just to do floating point.
According to rbowman <bowman@montana.com>:
On Wed, 18 Dec 2024 01:17:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
I can remember when CPUs needed coprocessors just to do floating point.
Ah, the 8087... Then there was the i486SX, the cheap version of the
i486DX. Intel said they disabled the FPU but the industry rumor said they >> were really the fallout of DX processors where the FPU failed in testing.
Well, they did have to disable the broken FPU so it wouldn't give wrong answers.
On Wed, 18 Dec 2024 01:17:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
I can remember when CPUs needed coprocessors just to do floating point.
Ah, the 8087... Then there was the i486SX, the cheap version of the i486DX. Intel said they disabled the FPU but the industry rumor said they were really the fallout of DX processors where the FPU failed in testing.
I can remember when CPUs needed coprocessors just to do floating point.
On 2024-12-18 02:17, Lawrence D'Oliveiro wrote:
I can remember when CPUs needed coprocessors just to do floating point.
They could do the floating point in software, automatically, if the >coprocesor was missing.
At least some compilers and runtimes did this.
On 2024-12-18, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
I can remember when CPUs needed coprocessors just to do floating point.
Including minis and mainframes.
https://en.wikipedia.org/wiki/Floating_Point_Systems
It was quite slow -- on 360/30 a floating multiply took about a
millisecond, divide two milliseconds, and I don't mean microseconds.
On Wed, 18 Dec 2024 18:34:10 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:
It was quite slow -- on 360/30 a floating multiply took about a
millisecond, divide two milliseconds, and I don't mean microseconds.
Sweet baby Jesus o_O I suppose, with IBM's bread & butter being in business/accounting applications (historically leery of floating-point arithmetic) it might not've been a crippling shortcoming, but that's
still mind-boggling...
On 2024-12-18 02:17, Lawrence D'Oliveiro wrote:
I can remember when CPUs needed coprocessors just to do floating point.
They could do the floating point in software, automatically, if the coprocesor was missing.
At least some compilers and runtimes did this.
According to Carlos E.R. <robin_listas@es.invalid>:
On 2024-12-18 02:17, Lawrence D'Oliveiro wrote:
I can remember when CPUs needed coprocessors just to do floating point.
They could do the floating point in software, automatically, if the
coprocesor was missing.
At least some compilers and runtimes did this.
It was only sort of automatic since on an 8086 or 8088, if there was no 8087 the floating point instructions were no-ops. The usual approach was for each operation to call a library which used the real instruction if present or simulated it. One clever approach was to generate 8087 instructions but
with the first byte changed so it was an INT instruction. If there was
an 8087 the trap routine patched the instruction to ESC (what the 8087
used) and restarted it, otherwise simulated it. That meant that if you
had an 8087 it ran at close to full speed with the trap only in the first time through a loop.
Needless to say this only worked on machines that ran in real mode
where user programs could catch traps, but in that era, that would
have included most PCs.
On Wed, 18 Dec 2024 18:34:10 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:
It was quite slow -- on 360/30 a floating multiply took about a
millisecond, divide two milliseconds, and I don't mean microseconds.
Sweet baby Jesus o_O I suppose, with IBM's bread & butter being in >business/accounting applications (historically leery of floating-point >arithmetic) it might not've been a crippling shortcoming, but that's
still mind-boggling...
I heard of 32K RAM chips which were actually 64K chips with a bad
cell. The manufacturer disabled half the chip and at least managed
to sell what was left. Kind of clever, actually.
John Levine <johnl@taugh.com> wrote:
It was quite slow -- on 360/30 a floating multiply took about a millisecond, divide two milliseconds, and I don't mean
microseconds.
Sweet baby Jesus o_O I suppose, with IBM's bread & butter being in business/accounting applications (historically leery of
floating-point arithmetic) it might not've been a crippling
shortcoming, but that's still mind-boggling...
This machine was less powerful than a Commodore 64. The memory had a 2 microsecond access cycle (i.e., 0.5MHz) and the options for its size
were 8KB, 16KB, 32KB, and 64KB. There was a later upgrade to 96KB.
The actual processor was 8-bit, providing the System/360 instruction
set via microcode emulation.
On 2024-12-18, rbowman <bowman@montana.com> wrote:
On Wed, 18 Dec 2024 01:17:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
I can remember when CPUs needed coprocessors just to do floating point.
Ah, the 8087... Then there was the i486SX, the cheap version of the
i486DX. Intel said they disabled the FPU but the industry rumor said they >> were really the fallout of DX processors where the FPU failed in testing.
I heard of 32K RAM chips which were actually 64K chips with a bad cell.
The manufacturer disabled half the chip and at least managed to sell
what was left. Kind of clever, actually.
On 2024-12-18, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
I can remember when CPUs needed coprocessors just to do floating point.
Including minis and mainframes.
https://en.wikipedia.org/wiki/Floating_Point_Systems
FPS made floating array processors that were worth it only if you had
a lot of arithmetic to do and good enough programmers to write code
for their rather tricky architecture.
[...]Floating point was standard and build into the processorI can remember when CPUs needed coprocessors just to do floating point.
like all other instructions on the burroughs mainframes;
Sweet baby Jesus o_O I suppose, with IBM's bread & butter being in business/accounting applications (historically leery of floating-point arithmetic) it might not've been a crippling shortcoming, but that's
still mind-boggling...
According to John Ames <commodorejohn@gmail.com>:
On Wed, 18 Dec 2024 18:34:10 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:
It was quite slow -- on 360/30 a floating multiply took about a
millisecond, divide two milliseconds, and I don't mean microseconds.
Sweet baby Jesus o_O I suppose, with IBM's bread & butter being in >>business/accounting applications (historically leery of floating-point >>arithmetic) it might not've been a crippling shortcoming, but that's
still mind-boggling...
The /30 was mostly programmed in assembler and RPG and was a replacement for an
electromechanical accounting machine or maybe an earlier 1401 computer. You could
attach a really good card reader/punch and printer, and usually one disk drive
or maybe a tape drive or two.
I suppose floating point might be useful if someone had a small Fortran program
they occasionaly ran to collect statistics or something. If it only ran once a
month, so what if it had to run overnight, cheaper than renting another computer.
The decimal instructions were also optional but everyone got them since RPG needed them. The later /22 was a repackaged /30 where decimal instructions were
included.
On the /50 and up floating point was standard and it was reasonably fast. The /91 had the first out-of-order arithmetic unit to make arithmetic really fast,
at the cost of imprecise interrupts if there was an overflow or underflow which
meant that you couldn't be sure which instructions had completed and which hadn't. We got a fair amount of useful work done on a /91 anyway.
The 30s I worked with were COBOL/ASM.
Multiple tapes and disks.
I worked in one place that ATTEMPTED to use RPG. The project failed.
RPG on the 360 line just didn't cut it. It was too hard to program
around. RPG II on the Sys/34 was a better deal.
On 2024-12-19, Dan Espen <dan1espen@gmail.com> wrote:
The 30s I worked with were COBOL/ASM.
Multiple tapes and disks.
I worked in one place that ATTEMPTED to use RPG. The project failed.
RPG on the 360 line just didn't cut it. It was too hard to program
around. RPG II on the Sys/34 was a better deal.
It probably depends on what you were using it for. I started off
in a shop that used RPG when it could and assembly language otherwise.
We got a lot of good work done in RPG.
I think the problem was that IBM forgot what RPG stood for.
On Wed, 18 Dec 2024 10:43:32 -0800, John Ames wrote:
On Wed, 18 Dec 2024 18:34:10 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:
It was quite slow -- on 360/30 a floating multiply took about a
millisecond, divide two milliseconds, and I don't mean microseconds.
Sweet baby Jesus o_O I suppose, with IBM's bread & butter being in
business/accounting applications (historically leery of floating-point
arithmetic) it might not've been a crippling shortcoming, but that's
still mind-boggling...
Remember the whole point of the “System 360” branding: it was to cover the
full circle of computing applications -- all 360 of it. Including scientific applications.
In article <20241218104332.000072d5@gmail.com>, commodorejohn@gmail.com
(John Ames) wrote:
John Levine <johnl@taugh.com> wrote:
It was quite slow -- on 360/30 a floating multiply took about a
millisecond, divide two milliseconds, and I don't mean
microseconds.
Sweet baby Jesus o_O I suppose, with IBM's bread & butter being in
business/accounting applications (historically leery of
floating-point arithmetic) it might not've been a crippling
shortcoming, but that's still mind-boggling...
This machine was less powerful than a Commodore 64. The memory had a 2 microsecond access cycle (i.e., 0.5MHz) and the options for its size were 8KB, 16KB, 32KB, and 64KB. There was a later upgrade to 96KB. The actual processor was 8-bit, providing the System/360 instruction set via
microcode emulation.
<https://en.wikipedia.org/wiki/IBM_System/360_Model_30>
John
John Levine <johnl@taugh.com> wrote:
According to Rich Alderson <news@alderson.users.panix.com>:
When the System/360 was announced, there was going to be a single operating >>> system for all of the models, OS/360.
That ran into the well known issues covered in Brooks. As stopgaps, IBM >>> quickly produced smaller operating systems (Basic OS, Tape OS, Disk OS) and an
even more primitive card only run time system (Basic Programming Support). >>> These were abbreviated BOS, TOS, DOS, and BPS.
They were distinguished from each other, but ALL WERE BRAND NEW. There was no
particular history that had to be distinguished for disk operating systems, >>> just the presence of disks.
I think you're both basically right. DOS and TOS were largely the same except
that TOS ran from tape, and DOS needed a disk with tapes optional. DOS and TOS
needed 16K of core (it was all core at the time) while BOS only needed 8K but
also needed a disk. I presume there was no tape version of BOS because BOS had
to load tiny overlays which would have been impractical from tape.
The code for BOS is online. I was surprised to see how it worked.
The code for BOS is online. I was surprised to see how it worked.
On Wed, 18 Dec 2024 18:34:10 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:
It was quite slow -- on 360/30 a floating multiply took about a
millisecond, divide two milliseconds, and I don't mean microseconds.
Sweet baby Jesus o_O I suppose, with IBM's bread & butter being in business/accounting applications (historically leery of floating-point arithmetic) it might not've been a crippling shortcoming, but that's
still mind-boggling...
Actually, 360/30 Functional characteristics claims that it was
faster: 460 microseconds for FP multiply long (64-bit) and
199 microseconds for FP multiply short (32-bits).
AFAICS 360/30 hardware had similar basice performance characteristics
as 4.7 MHz 8088 in IBM PC (but multiplication speed depends on >multiplication-specific support), that is faster than ZX Spectrum,
but not that much.
I can remember the fashion for naming products “XP”:
* Windows XP
* Office XP
* Athlon XP
What the heck did “XP” stand for, anyway?
On 12/19/24 20:11, Lawrence D'Oliveiro wrote:
I can remember the fashion for naming products “XP”:
* Windows XP
* Office XP
* Athlon XP
What the heck did “XP” stand for, anyway?
eXtended Performance maybe?
Here’s one I came up with:Editing your xfree86 file wrong would fry your monitor.
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
https://www.youtube.com/watch?v=rD6y7aOS0NA
Some things from the '60s are best forgotten.
On 2024-12-04, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Here’s one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
Editing your xfree86 file wrong would fry your monitor.
On 2024-12-19, Dan Espen <dan1espen@gmail.com> wrote:
The 30s I worked with were COBOL/ASM.
Multiple tapes and disks.
I worked in one place that ATTEMPTED to use RPG. The project failed.
RPG on the 360 line just didn't cut it. It was too hard to program
around. RPG II on the Sys/34 was a better deal.
It probably depends on what you were using it for. I started off
in a shop that used RPG when it could and assembly language otherwise.
We got a lot of good work done in RPG.
I think the problem was that IBM forgot what RPG stood for.
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
On 2024-12-19, Dan Espen <dan1espen@gmail.com> wrote:
The 30s I worked with were COBOL/ASM.
Multiple tapes and disks.
I worked in one place that ATTEMPTED to use RPG. The project failed.
RPG on the 360 line just didn't cut it. It was too hard to program
around. RPG II on the Sys/34 was a better deal.
It probably depends on what you were using it for. I started off
in a shop that used RPG when it could and assembly language otherwise.
We got a lot of good work done in RPG.
I guess so, as long as your users would accept what RPG wanted to do you
were okay. Anything out of the ordinary got complicated fast. We had
some issue with the MR (matching record) logic that we just couldn't get around.
In RPG II there was a CHAIN instruction that let's you avoid the MR stuff.
I think the problem was that IBM forgot what RPG stood for.
With RPG II they forgot what it stood for in a good way.
Amdahl had won the battle to make ACS, 360 compatible ... folklore
was that it was canceled because there was concern that it would
advance technology too fast and would loose control of market ...
In the midst of this environment in 1968, the ACS project
experienced a dramatic change of direction. The original
architecture had been designed for the perceived performance
and floating-point-precision needs of customers such as the
national labs, much like the CDC 6600.
On 2024-12-20, Dan Espen <dan1espen@gmail.com> wrote:
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
On 2024-12-19, Dan Espen <dan1espen@gmail.com> wrote:
The 30s I worked with were COBOL/ASM.
Multiple tapes and disks.
I worked in one place that ATTEMPTED to use RPG. The project failed. >>>> RPG on the 360 line just didn't cut it. It was too hard to program
around. RPG II on the Sys/34 was a better deal.
It probably depends on what you were using it for. I started off
in a shop that used RPG when it could and assembly language otherwise.
We got a lot of good work done in RPG.
I guess so, as long as your users would accept what RPG wanted to do you
were okay. Anything out of the ordinary got complicated fast. We had
some issue with the MR (matching record) logic that we just couldn't get
around.
Matching record logic was a bit funky. But once I wrapped my head
around it, I learned subtleties of record matching that serve me well
to this day, regardless of language.
My major gripe was with first page processing, which IMHO RPG got
totally wrong. The idea of a dummy output cycle to print headings
on the first page is misguided. In our shop we had to go through
at least a couple of detail cycles to read the run date and customer
name records to print in the page headings. I worked out a way,
using regular indicators, to make things work correctly - I never
touched 1P, and managed to disable that dummy heading output cycle.
I was lucky enough to have a mentor who showed me the proper way to
check whether to print headings: wait until you have something to
print. That way you don't wind up with spurious pages at the front
or back of the report that consist of headings only.
In RPG II there was a CHAIN instruction that let's you avoid the MR stuff.
Ah, look things up in an ISAM file. Yes, that worked well.
I think the problem was that IBM forgot what RPG stood for.
With RPG II they forgot what it stood for in a good way.
I had to port a couple of 3000-line interactive programs from
an IBM System/34 to the Univac equivalent of CICS. That was
Not Fun, and left me with an aversion to using RPG for anything
other than report programs.
Wouldn't the national labs have found the rounding behaviour of 360 hexadecimal floating-point a problem?
In article <875xngbp6t.fsf@localhost>, lynn@garlic.com (Lynn Wheeler)
wrote:
Amdahl had won the battle to make ACS, 360 compatible ... folklore
was that it was canceled because there was concern that it would
advance technology too fast and would loose control of market ...
In the midst of this environment in 1968, the ACS project
experienced a dramatic change of direction. The original
architecture had been designed for the perceived performance
and floating-point-precision needs of customers such as the
national labs, much like the CDC 6600.
Wouldn't the national labs have found the rounding behaviour of 360 >hexadecimal floating-point a problem?
On Fri, 20 Dec 2024 22:06:46 GMT, Charlie Gibbs wrote:
I had to port a couple of 3000-line interactive programs from an IBM
System/34 to the Univac equivalent of CICS. That was Not Fun, and left
me with an aversion to using RPG for anything other than report
programs.
I never used RPG but I might have welcomed it.
https://www.computerwoche.de/article/2866494/neues-dateiprogramm-fuer- system-123-benutzer.html
I can't even find a page in English but the IBM 5120 came with BRADS II.
It was programmed in BASIC, thankfully, since a toggle allowed you to use the APL ROM instead. Business software was not my domain but the company decided if I had free time I could write an inventory control system for
the shiny new 5120.
Note: the 5100, 5110, and 5120 had absolutely nothing to do with the 5150.
Wouldn't the national labs have found the rounding behaviour of 360 >>hexadecimal floating-point a problem?
Everyone did but IBM had a lot of mathematicians who provided libraries
that got good answers using wobbly 360 floaring point.
The 6600 floating point had 48 bits of fraction, or 96 in double precision.
The 360 long format floating point had 14 hex digits which was about 54 bits (4x16-2, since the high two bits were typically zero) and extended floating point had 28 digits or about 110 bits. That should have been enough to get results as good as CDC's.
According to Waldek Hebisch <antispam@fricas.org>:
Actually, 360/30 Functional characteristics claims that it was
faster: 460 microseconds for FP multiply long (64-bit) and
199 microseconds for FP multiply short (32-bits).
It depended whether you had the 1.5us or 2us memory. I don't know
why the 2us times are so much longer.
AFAICS 360/30 hardware had similar basice performance characteristics
as 4.7 MHz 8088 in IBM PC (but multiplication speed depends on >>multiplication-specific support), that is faster than ZX Spectrum,
but not that much.
You definitely didn't buy a 360/30 as a compute engine, but for something
to do business processing and reports and sorting, it was quite adqequate.
On Mon, 23 Dec 2024 00:33:11 -0000 (UTC), Waldek Hebisch wrote:After some 58 years, about the only thing I remember about that course
One can discuss why customers bought IBM machines, but I think some
bought 360/30 for numeric work. It certainly was significant
improvement over 1620.
RPI bought, or was possibly gifted by IBM, a 360/30. I don't know if the administration used it for business but it was used for the FORTRAN IV programming course which were definitely numeric.
After some 58 years, about the only thing I remember about that course
at RPI was a sign someone put on the card deck input bins for submitting batch jobs to tell you how to orient your punched cards: TOPLEFUP,
meaning "top left, face up".
I have seen a few analyses around 1970 basically saying that
compute power was cheapest in machines of 360/65 class
and that user whos load was too light to properly utilize
such machine should use servce bureaus or remote access.
But market surveys showed that smaller machines were in demand,
apparently customer wanted "own" machine even if they could only
afford un underpowerd one.
After some 58 years, about the only thing I remember about that course
at RPI was a sign someone put on the card deck input bins for submitting batch jobs to tell you how to orient your punched cards: TOPLEFUP,
meaning "top left, face up".
On Sun, 22 Dec 2024 19:06:44 -0700, Don_from_AZ wrote:
After some 58 years, about the only thing I remember about that course
at RPI was a sign someone put on the card deck input bins for submitting
batch jobs to tell you how to orient your punched cards: TOPLEFUP,
meaning "top left, face up".
Wasn’t there a specially-shaped opening so the cards would only sit properly in one orientation?
This is why one corner was cut off the cards.
On Mon, 23 Dec 2024 03:18:01 GMT, Charlie Gibbs wrote:
What
was needed was I/O capability, so a small machine with a low-power CPU
was fine as long as its printer could grind out 600 lines per minute all
day long.
Preferably in a soundproof room a long ways away.
On Sun, 22 Dec 2024 19:06:44 -0700, Don_from_AZ wrote:
After some 58 years, about the only thing I remember about that course
at RPI was a sign someone put on the card deck input bins for submitting
batch jobs to tell you how to orient your punched cards: TOPLEFUP,
meaning "top left, face up".
Wasn’t there a specially-shaped opening so the cards would only sit >properly in one orientation?
This is why one corner was cut off the cards.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 12 Dec 2024 23:01:08 -0000 (UTC), John Levine wrote:I think later they developed multi-segment files.
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
On Thu, 12 Dec 2024 19:53:23 -0000 (UTC), John Levine wrote:
Application programs had to deal with details of the physical I/O
devices like tracks and cylinders and blocking multiple logical
records into physical ones.
One of the breakthroughs with Unix is that it moved all these
headaches into the OS kernel.
Unix had the good fortune to be a few years later, when it was
apparent to everyone that disks all had fixed size power of two blocks
and CKD was a mistake.
But it was hardly a breakthrough. Multics totally abstracted I/O away
by moving it into the pager. You mapped in a segment, any disk action
was a side effect.
Yeah, but that imposed a limit on file size.
But referring back to compute power, this wasn't as big an issue
as it might seem. Many small business applications consisted of
adding up columns of numbers; not much CPU power was needed. What
was needed was I/O capability, so a small machine with a low-power
CPU was fine as long as its printer could grind out 600 lines per
minute all day long.
On 2024-12-23 06:39, rbowman wrote:
On Mon, 23 Dec 2024 03:18:01 GMT, Charlie Gibbs wrote:
WhatPreferably in a soundproof room a long ways away.
was needed was I/O capability, so a small machine with a low-power CPU
was fine as long as its printer could grind out 600 lines per minute all >>> day long.
Would those printers cut the paper between jobs?
Sure, it’s possible to do anything, but not something the average user would do. Anyway, you’d use EXCP to run your own channel program. (I think DOS had EXCP, but at least it had the equivalent.)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 12 Dec 2024 16:08:06 -0700, Peter Flass wrote:
In IBM DOS systems the DTF macro generated the channel program. In OS
systems the channel program was built dynamically at OPEN time. This
allowed the user program to do a lot of fiddling with the DCB before
opening the dataset.
I’m sure it was possible to implement your own version of the operation of
the DTF macro that did all the work at run time.
Sure, it’s possible to do anything, but not something the average user would do. Anyway, you’d use EXCP to run your own channel program. (I think DOS had EXCP, but at least it had the equivalent.)
On 2024-12-23 06:39, rbowman wrote:
On Mon, 23 Dec 2024 03:18:01 GMT, Charlie Gibbs wrote:
What
was needed was I/O capability, so a small machine with a low-power CPU
was fine as long as its printer could grind out 600 lines per minute all >>> day long.
Preferably in a soundproof room a long ways away.
Would those printers cut the paper between jobs?
Sweet baby Jesus o_O I suppose, with IBM's bread & butter being in
business/accounting applications (historically leery of floating-point
arithmetic) it might not've been a crippling shortcoming, but that's
still mind-boggling...
No one would buy a /30 to do scientific computing. I’m wondering if adding >the feature din’t just enable microcode, but required actually adding the >microcode. I know on the /30 the microcode was on mylar cards the size of
an “IBM card” with holes punched it them. I once watched a CE install a >microcode patch by punching the card on a keypunch.
Would those printers cut the paper between jobs?
IBM printers didn't have any paper cutting capability.
There were standalone machines to pull out the carbon from multipart
paper and bursters to break apart sheets for things like invoices.
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
On 2024-12-23, Carlos E.R. <robin_listas@es.invalid> wrote:
On 2024-12-23 06:39, rbowman wrote:
On Mon, 23 Dec 2024 03:18:01 GMT, Charlie Gibbs wrote:
What
was needed was I/O capability, so a small machine with a low-power CPU >>>>> was fine as long as its printer could grind out 600 lines per minute all >>>>> day long.
Preferably in a soundproof room a long ways away.
Would those printers cut the paper between jobs?
If you had one of those early laser printers ($250K each), they
could cut pages, collate, and do all sorts of magic. The rest of
us had impact printers that printed on continuous forms. There
were perforations between each page so they could be easily
separated, either by hand or with a burster that did several
pages per second automatically. Then you would put the reports
into binders if you wanted, although some people just left the
continuous form as is. For those who wanted multiple copies,
you'd print on multi-part forms which were a sandwich of
alternating plain paper and carbon paper. There was a decollator
that would separate the copies from the carbon paper; throw out the
carbon paper and run the copies through the burster. If you were a
receipent of one of these reports, you know you were at the bottom
of the totem pole if your copy was printed on the last sheet of a
6-part form - the quality decreased with each successive copy, as the
impact from the printer was dampened by successive layers of paper
and the impression left by the type slugs became more blurry.
What this meant in practice was that the “line” employees who had to constantly use these reports got the worst copy, and the suits, who likely never looked at them, got the best.
On 2024-12-23, Carlos E.R. <robin_listas@es.invalid> wrote:
On 2024-12-23 06:39, rbowman wrote:
On Mon, 23 Dec 2024 03:18:01 GMT, Charlie Gibbs wrote:
What
was needed was I/O capability, so a small machine with a low-power CPU >>>> was fine as long as its printer could grind out 600 lines per minute all >>>> day long.
Preferably in a soundproof room a long ways away.
Would those printers cut the paper between jobs?
If you had one of those early laser printers ($250K each), they
could cut pages, collate, and do all sorts of magic. The rest of
us had impact printers that printed on continuous forms. There
were perforations between each page so they could be easily
separated, either by hand or with a burster that did several
pages per second automatically.
Then you would put the reports
into binders if you wanted, although some people just left the
continuous form as is. For those who wanted multiple copies,
you'd print on multi-part forms which were a sandwich of
alternating plain paper and carbon paper.
There was a decollator
that would separate the copies from the carbon paper; throw out the
carbon paper and run the copies through the burster. If you were a
receipent of one of these reports, you know you were at the bottom
of the totem pole if your copy was printed on the last sheet of a
6-part form - the quality decreased with each successive copy, as the
impact from the printer was dampened by successive layers of paper
and the impression left by the type slugs became more blurry.
On 2024-12-23, Peter Flass <peter_flass@yahoo.com> wrote:
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
On 2024-12-23, Carlos E.R. <robin_listas@es.invalid> wrote:
On 2024-12-23 06:39, rbowman wrote:
On Mon, 23 Dec 2024 03:18:01 GMT, Charlie Gibbs wrote:
What
was needed was I/O capability, so a small machine with a low-power CPU >>>>>> was fine as long as its printer could grind out 600 lines per minute all >>>>>> day long.
Preferably in a soundproof room a long ways away.
Would those printers cut the paper between jobs?
If you had one of those early laser printers ($250K each), they
could cut pages, collate, and do all sorts of magic. The rest of
us had impact printers that printed on continuous forms. There
were perforations between each page so they could be easily
separated, either by hand or with a burster that did several
pages per second automatically. Then you would put the reports
into binders if you wanted, although some people just left the
continuous form as is. For those who wanted multiple copies,
you'd print on multi-part forms which were a sandwich of
alternating plain paper and carbon paper. There was a decollator
that would separate the copies from the carbon paper; throw out the
carbon paper and run the copies through the burster. If you were a
receipent of one of these reports, you know you were at the bottom
of the totem pole if your copy was printed on the last sheet of a
6-part form - the quality decreased with each successive copy, as the
impact from the printer was dampened by successive layers of paper
and the impression left by the type slugs became more blurry.
What this meant in practice was that the “line” employees who had to
constantly use these reports got the worst copy, and the suits, who likely >> never looked at them, got the best.
'Twas ever thus. When a PPOE got a new phone system, the boss got
the fancy multi-line "Super Set", while his secretary had to make
do with a simple 2500 set. That was fortunately changed before long.
When we put the first personal computers on people's desks, the
managers got the fancy powerful machines, we techs got a medium
model, while our poor data entry clerk had to spend all day
squinting at the small screen that came with the cheapest model.
She really got treated like dirt. Several times she stormed out
of the office in tears. One day she never came back.
There were standalone machines to pull out the carbon from multipart
paper and bursters to break apart sheets for things like invoices.
If you had one of those early laser printers ($250K each), they could
cut pages, collate, and do all sorts of magic.
When we put the first personal computers on people's desks, the managers
got the fancy powerful machines, we techs got a medium model, while our
poor data entry clerk had to spend all day squinting at the small screen
that came with the cheapest model.
She really got treated like dirt. Several times she stormed out of the office in tears. One day she never came back.
On Mon, 23 Dec 2024 12:12:07 -0500, Dan Espen wrote:
There were standalone machines to pull out the carbon from multipart
paper and bursters to break apart sheets for things like invoices.
Some people complained that the new generation of fast, quiet, non-impact printers could no longer print carbon copies.
They didn’t realize that now they didn’t need to: they could just print the same page multiple times, with copies on different-coloured paper if
they wanted, and still get the print job done faster than on the old,
slow, noisy impact printers.
Don_from_AZ wrote to alt.folklore.computers <=-
After some 58 years, about the only thing I remember about that course
at RPI was a sign someone put on the card deck input bins for
submitting batch jobs to tell you how to orient your punched cards: TOPLEFUP, meaning "top left, face up".
rbowman wrote to alt.folklore.computers <=-
Preferably in a soundproof room a long ways away.
Carlos E.R. wrote to alt.folklore.computers <=-
Would those printers cut the paper between jobs?
On 2024-12-23 23:41, Lawrence D'Oliveiro wrote:
On Mon, 23 Dec 2024 12:12:07 -0500, Dan Espen wrote:
There were standalone machines to pull out the carbon from multipart
paper and bursters to break apart sheets for things like invoices.
Some people complained that the new generation of fast, quiet,
non-impact printers could no longer print carbon copies.
They didn’t realize that now they didn’t need to: they could just print >> the same page multiple times, with copies on different-coloured paper
if they wanted, and still get the print job done faster than on the
old, slow, noisy impact printers.
Banks still use impact printers and do carbon copies. It is something
legal related. Besides, those printers can be made to take preprinted
forms, and even booklets.
By 1979 the 6600 was nearly ten years old. I think it was made with
discrete transistors.
The printer can also print something different on each copy, something
not so easy to do with carbon or NCR paper.
On Mon, 23 Dec 2024 22:26:54 +0100, Carlos E.R. wrote:
I have not experienced this. Programmers tended to get good machines,
simply because the compiling could take half an hour in the bad machine,
and you had somebody twiddling fingers for most part of the day. I also
got decent displays. But once they hired two engineers to design
something on autocad, and they had very good computers with big
displays. I was envious.
You're lucky. As our clients started using two or more monitors we would
get bugs about positioning errors. I can remember having to walk to
another area to commandeer a machine that had dual monitors.
It got better over the years and we started getting Dells rather than something IT built for whatever was cheap on NewEgg. The programmers
tended to run Linux. If you asked for a new machine you would get a wiped hand-me-down. That wasn't all that bad as they would run Linux perfectly
fine and since IT didn't want to know anything about Linux you could
install the distro of your choice and provision it to suit.
On Mon, 23 Dec 2024 22:46:09 -0000 (UTC), Lawrence D'Oliveiro wrote:
On Mon, 23 Dec 2024 21:13:04 GMT, Charlie Gibbs wrote:
When we put the first personal computers on people's desks, the
managers got the fancy powerful machines, we techs got a medium model,
while our poor data entry clerk had to spend all day squinting at the
small screen that came with the cheapest model.
She really got treated like dirt. Several times she stormed out of the
office in tears. One day she never came back.
Just to compound the irony, wasn’t it the prevailing culture in those
days that managers never touched keyboards? Typing was something their
underlings did.
My brother was quite a bit older than I and that was the case. Engineers engineered, secretaries typed. In high school college entrance kids took Latin and spherical trig. The business and shop kids took Spanish and
typing. I still can't touch type although I've evolved a fairly efficient
two or three finger style,
On 2024-12-23 19:20, Charlie Gibbs wrote:
Then you would put the reports
into binders if you wanted, although some people just left the
continuous form as is. For those who wanted multiple copies,
you'd print on multi-part forms which were a sandwich of
alternating plain paper and carbon paper.
Or paper impregnated in the back with a chemical that results in print
on the next page, without having to remove a carbon sheet. I don't know
how modern is this, I just saw it at a bank this week.
To: Don_from_AZ
Don_from_AZ wrote to alt.folklore.computers <=-
After some 58 years, about the only thing I remember about that course at RPI was a sign someone put on the card deck input bins for
submitting batch jobs to tell you how to orient your punched cards: TOPLEFUP, meaning "top left, face up".
I thought the old saying was "face down, nine-edge first"?
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 24 Dec 2024 00:02:10 +0100, Carlos E.R. wrote:
On 2024-12-23 23:41, Lawrence D'Oliveiro wrote:
On Mon, 23 Dec 2024 12:12:07 -0500, Dan Espen wrote:
There were standalone machines to pull out the carbon from multipart >>>>> paper and bursters to break apart sheets for things like invoices.
Some people complained that the new generation of fast, quiet,
non-impact printers could no longer print carbon copies.
They didn’t realize that now they didn’t need to: they could just print
the same page multiple times, with copies on different-coloured paper
if they wanted, and still get the print job done faster than on the
old, slow, noisy impact printers.
Banks still use impact printers and do carbon copies. It is something
legal related. Besides, those printers can be made to take preprinted
forms, and even booklets.
Again, something else unnecessary, when the printer itself can print the
“preprinted” part along with the rest of the page. Not sure what “legal”
requirements have to do with anything, unless somebody is personally
witnessing and attesting to every page coming of the printer ...
Advanced printers include collation and binding functions. Most of those
are of the non-impact kind now anyway.
The printer can also print something different on each copy, something not
so easy to do with carbon or NCR paper.
On Tue, 24 Dec 2024, rbowman wrote:
On Mon, 23 Dec 2024 22:26:54 +0100, Carlos E.R. wrote:
I have not experienced this. Programmers tended to get good machines,
simply because the compiling could take half an hour in the bad machine, >>> and you had somebody twiddling fingers for most part of the day. I also
got decent displays. But once they hired two engineers to design
something on autocad, and they had very good computers with big
displays. I was envious.
You're lucky. As our clients started using two or more monitors we would
get bugs about positioning errors. I can remember having to walk to
another area to commandeer a machine that had dual monitors.
It got better over the years and we started getting Dells rather than
something IT built for whatever was cheap on NewEgg. The programmers
tended to run Linux. If you asked for a new machine you would get a wiped
hand-me-down. That wasn't all that bad as they would run Linux perfectly
fine and since IT didn't want to know anything about Linux you could
install the distro of your choice and provision it to suit.
Reminds me of the local IT of a school I teach in. A course required
linux and GNS3, and it was agreed that the school should prepare the students laptops.
When my teacher started the course, all students had windows laptops.
Upon some research it turned out that they'd forgotten. So the manager
asked their local IT to fix it, and she said "what's this linux? no one serious is using it, I've worked in IT for 20 years and serious people
use windows".
It was explained to her that this is in fact not always the case outside
of that school, and she then had to spend the night watching youtube
videos on how to install linux on a laptop.
To her credit, she kind of did solve it in the end! =)
On 2024-12-23, Carlos E.R. <robin_listas@es.invalid> wrote:
On 2024-12-23 19:20, Charlie Gibbs wrote:
Then you would put the reports
into binders if you wanted, although some people just left the
continuous form as is. For those who wanted multiple copies,
you'd print on multi-part forms which were a sandwich of
alternating plain paper and carbon paper.
Or paper impregnated in the back with a chemical that results in print
on the next page, without having to remove a carbon sheet. I don't know
how modern is this, I just saw it at a bank this week.
Wow, I'm surprised it's still around. You're talking about what was
commonly known as NCR paper. The NCR stood for "No Carbon Required".
A quick web search shows that it was patented by National Cash Register
(also known as NCR) in 1953.
The smell was quite, err, distinctive.
As others have pointed out, nowadays laser and inkjet printers are
so fast that it's quicker to just print multiple copies, each of which
is much higher quality than what came out of those old impact printers.
On Mon, 23 Dec 2024 22:46:09 -0000 (UTC), Lawrence D'Oliveiro wrote:
On Mon, 23 Dec 2024 21:13:04 GMT, Charlie Gibbs wrote:
When we put the first personal computers on people's desks, the
managers got the fancy powerful machines, we techs got a medium model,
while our poor data entry clerk had to spend all day squinting at the
small screen that came with the cheapest model.
She really got treated like dirt. Several times she stormed out of
the office in tears. One day she never came back.
Just to compound the irony, wasn’t it the prevailing culture in those
days that managers never touched keyboards? Typing was something their
underlings did.
My brother was quite a bit older than I and that was the case. Engineers engineered, secretaries typed. In high school college entrance kids took Latin and spherical trig. The business and shop kids took Spanish and
typing. I still can't touch type although I've evolved a fairly
efficient two or three finger style,
On Mon, 23 Dec 2024 20:08:10 -0000 (UTC), Lars Poulsen wrote:
"Carlos E.R." <robin_listas@es.invalid> writes:
Would those printers cut the paper between jobs?
On 2024-12-23, Dan Espen <dan1espen@gmail.com> wrote:
IBM printers didn't have any paper cutting capability.
There were standalone machines to pull out the carbon from multipart
paper and bursters to break apart sheets for things like invoices.
Actually, you COULD cut the paper by doing multiple overprints of a line
of -----------------------------
But that would create an instant paper jam!
Yes but overprints brought ASCII art to a new dimension! I wonder how many >man-hours went into printing cats on greenbar?
Peter Flass wrote to alt.folklore.computers <=-
I once
watched a CE install a microcode patch by punching the card on a
keypunch. --
Scheduled the upgrade, scheduled downtime, did a full backup, waited
for the field circus engineer to show up. He arrived, powered down the system, created an ESD-free workspace, pulled a board out of the
computer, MOVED A JUMPER, and put it back. Anticlimactic, to say the
least!
Her attitude is one of the biggest things holding desktop Linux back.
Basically, you have to manually certify that each copy is indeed a
veritable copy.
Desktop Linux is the main thing holding desktop Linux back.
On 2024-12-24 01:39, Peter Flass wrote:
The printer can also print something different on each copy, something
not so easy to do with carbon or NCR paper.
Which is precisely why it has to be carbon copies.
On 2024-12-24 12:25, D wrote:
On Tue, 24 Dec 2024, rbowman wrote:
On Mon, 23 Dec 2024 22:26:54 +0100, Carlos E.R. wrote:
I have not experienced this. Programmers tended to get good machines,
simply because the compiling could take half an hour in the bad machine, >>>> and you had somebody twiddling fingers for most part of the day. I also >>>> got decent displays. But once they hired two engineers to design
something on autocad, and they had very good computers with big
displays. I was envious.
You're lucky. As our clients started using two or more monitors we would >>> get bugs about positioning errors. I can remember having to walk to
another area to commandeer a machine that had dual monitors.
It got better over the years and we started getting Dells rather than
something IT built for whatever was cheap on NewEgg. The programmers
tended to run Linux. If you asked for a new machine you would get a wiped >>> hand-me-down. That wasn't all that bad as they would run Linux perfectly >>> fine and since IT didn't want to know anything about Linux you could
install the distro of your choice and provision it to suit.
Reminds me of the local IT of a school I teach in. A course required linux >> and GNS3, and it was agreed that the school should prepare the students
laptops.
When my teacher started the course, all students had windows laptops. Upon >> some research it turned out that they'd forgotten. So the manager asked
their local IT to fix it, and she said "what's this linux? no one serious >> is using it, I've worked in IT for 20 years and serious people use
windows".
:-DD
It was explained to her that this is in fact not always the case outside of >> that school, and she then had to spend the night watching youtube videos on >> how to install linux on a laptop.
To her credit, she kind of did solve it in the end! =)
I was working at Lucent just before their demise. Bell Labs was part of the company. They invented Unix, you know. I asked to purchase Linux (a SUSE box with CDs). After a month they said it was not in their business list, none of
their providers sold it.
By then I had found the name of the internal server with a download mirror.
D <nospam@example.net> wrote:
On Tue, 24 Dec 2024, rbowman wrote:
On Mon, 23 Dec 2024 22:26:54 +0100, Carlos E.R. wrote:
I have not experienced this. Programmers tended to get good machines,
simply because the compiling could take half an hour in the bad machine, >>>> and you had somebody twiddling fingers for most part of the day. I also >>>> got decent displays. But once they hired two engineers to design
something on autocad, and they had very good computers with big
displays. I was envious.
You're lucky. As our clients started using two or more monitors we would >>> get bugs about positioning errors. I can remember having to walk to
another area to commandeer a machine that had dual monitors.
It got better over the years and we started getting Dells rather than
something IT built for whatever was cheap on NewEgg. The programmers
tended to run Linux. If you asked for a new machine you would get a wiped >>> hand-me-down. That wasn't all that bad as they would run Linux perfectly >>> fine and since IT didn't want to know anything about Linux you could
install the distro of your choice and provision it to suit.
Reminds me of the local IT of a school I teach in. A course required linux >> and GNS3, and it was agreed that the school should prepare the students
laptops.
When my teacher started the course, all students had windows laptops. Upon >> some research it turned out that they'd forgotten. So the manager asked
their local IT to fix it, and she said "what's this linux? no one serious
is using it, I've worked in IT for 20 years and serious people use
windows".
It was explained to her that this is in fact not always the case outside
of that school, and she then had to spend the night watching youtube
videos on how to install linux on a laptop.
To her credit, she kind of did solve it in the end! =)
Her attitude is one of the biggest things holding desktop Linux back.
On Tue, 24 Dec 2024 12:26:01 +0100, D wrote:
Secretaries were also very important for office flings and romances!
That area must not be neglected!
My brother was amused when he transferred to a division that was in the
Utah boondocks. When he met his new secretary she defined the limits of
the relationship. 'I do not make coffee. If you want coffee make it yourself.' In her mind the LDS proscription on 'hot beverages' included preparing them.
On Tue, 24 Dec 2024 12:25:04 +0100, D wrote:
It was explained to her that this is in fact not always the case outside
of that school, and she then had to spend the night watching youtube
videos on how to install linux on a laptop.
To her credit, she kind of did solve it in the end! =)
The current IT head worked for Microsoft for 20 years. Not a chance. He
would probably kick the Linux boxes off the network but the person he
answers to uses Linux. Programming and QA have used Slack for years. He
would dearly love to replace it with Teams but hasn't succeeded so far.
On 24/12/2024 13:50, Peter Flass wrote:
Her attitude is one of the biggest things holding desktop Linux back.
Desktop Linux is the main thing holding desktop Linux back.
On Tue, 24 Dec 2024, moi wrote:
On 24/12/2024 13:50, Peter Flass wrote:
Her attitude is one of the biggest things holding desktop Linux back.
Desktop Linux is the main thing holding desktop Linux back.
This is not correct.
Here's one I came up with:
I can remember when spacebars were longer, because there were fewer
modifier keys on computer keyboards.
On Tue, 24 Dec 2024 00:02:10 +0100, Carlos E.R. wrote:
On 2024-12-23 23:41, Lawrence D'Oliveiro wrote:
On Mon, 23 Dec 2024 12:12:07 -0500, Dan Espen wrote:
There were standalone machines to pull out the carbon from multipart
paper and bursters to break apart sheets for things like invoices.
Some people complained that the new generation of fast, quiet,
non-impact printers could no longer print carbon copies.
They didn’t realize that now they didn’t need to: they could just print >>> the same page multiple times, with copies on different-coloured paper
if they wanted, and still get the print job done faster than on the
old, slow, noisy impact printers.
Banks still use impact printers and do carbon copies. It is something
legal related. Besides, those printers can be made to take preprinted
forms, and even booklets.
Again, something else unnecessary, when the printer itself can print the “preprinted” part along with the rest of the page. Not sure what “legal”
requirements have to do with anything, unless somebody is personally witnessing and attesting to every page coming of the printer ...
Advanced printers include collation and binding functions. Most of those
are of the non-impact kind now anyway.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 24 Dec 2024 00:02:10 +0100, Carlos E.R. wrote:
On 2024-12-23 23:41, Lawrence D'Oliveiro wrote:
On Mon, 23 Dec 2024 12:12:07 -0500, Dan Espen wrote:
There were standalone machines to pull out the carbon from multipart >>>>> paper and bursters to break apart sheets for things like invoices.
Some people complained that the new generation of fast, quiet,
non-impact printers could no longer print carbon copies.
They didn’t realize that now they didn’t need to: they could just print
the same page multiple times, with copies on different-coloured paper
if they wanted, and still get the print job done faster than on the
old, slow, noisy impact printers.
Banks still use impact printers and do carbon copies. It is something
legal related. Besides, those printers can be made to take preprinted
forms, and even booklets.
Again, something else unnecessary, when the printer itself can print the
“preprinted” part along with the rest of the page. Not sure what “legal”
requirements have to do with anything, unless somebody is personally
witnessing and attesting to every page coming of the printer ...
Advanced printers include collation and binding functions. Most of those
are of the non-impact kind now anyway.
I did a billing system and the customer specified forms even though the printer could print the form too. I asked but they wouldn't bite.
Linux doesn't run the programs that desktop users want, most importantly
MS Office. You can claim that Libreoffice is just as good, but it isn't.
Its web browsers are chronically behind the versions for Windows and
Mac.
I did a billing system and the customer specified forms even though the printer could print the form too. I asked but they wouldn't bite.
According to D <nospam@example.net>:
On Tue, 24 Dec 2024, moi wrote:
On 24/12/2024 13:50, Peter Flass wrote:
Her attitude is one of the biggest things holding desktop Linux back.
Desktop Linux is the main thing holding desktop Linux back.
This is not correct.
Linux doesn't run the programs that desktop users want, most importantly
MS Office.
You can claim that Libreoffice is just as good, but it isn't.
Its web browsers are chronically behind the versions for Windows and
Mac.
I switched to a Mac because it runs the programs I need to use to
exchange files with other people, while being Unix underneath. It's not particularly cheap but for me it's worth it.
According to D <nospam@example.net>:
On Tue, 24 Dec 2024, moi wrote:
On 24/12/2024 13:50, Peter Flass wrote:
Her attitude is one of the biggest things holding desktop Linux back.
Desktop Linux is the main thing holding desktop Linux back.
This is not correct.
Linux doesn't run the programs that desktop users want, most importantly MS Office.
You can claim that Libreoffice is just as good, but it isn't.
Its web browsers are chronically behind the versions for Windows and Mac.
I switched to a Mac because it runs the programs I need to use to exchange files
with other people, while being Unix underneath. It's not particularly cheap but
for me it's worth it.
On Tue, 24 Dec 2024 22:02:55 +0100, D wrote:
On Tue, 24 Dec 2024, rbowman wrote:
On Tue, 24 Dec 2024 12:25:04 +0100, D wrote:Wow! Should he succeed, that would be an excellent sign to either retire
It was explained to her that this is in fact not always the case
outside of that school, and she then had to spend the night watching
youtube videos on how to install linux on a laptop.
To her credit, she kind of did solve it in the end! =)
The current IT head worked for Microsoft for 20 years. Not a chance. He
would probably kick the Linux boxes off the network but the person he
answers to uses Linux. Programming and QA have used Slack for years. He
would dearly love to replace it with Teams but hasn't succeeded so far.
or move on to the next job. ;)
Not my problem. My division shut down 1 January and we told existing
clients we'd support them for a year while the found another CAD vendor.
With no new development I only step in to advise the support people or fix
a bug or two. Some have opted for extended support. I'll still stick
around but it's only a couple of hours a week, enough to keep the payroll program from wondering if I'm still alive. I'm more than a decade past the usual retirement age in the US so a 'next job' has no interest.
On Tue, 24 Dec 2024 22:01:04 +0100, D wrote:
Wow, a tough cookie! I never had a secretary, but I remember once in a
place were I worked very, very briefly, the office assistant tried hard
to have sex with me, including the "classic" of not wearing any
underwear and displaying her intimate parts, as well as boasting that
she had had sex with at least 50 men. Needless to say, nothing happened
there. The boast had rather the opposite effect. "To boldly go where
many have gone before"
to quote Waynes World (I think).
Never had that problem. At one point I did get a cubicle mate who was a
woman about the same age as I was. After she hung her Playboy calendar we sorted out that she wasn't interested in men so I didn't have to worry
about offending here by either making or not making a pass.
Management made her take down the calendar but I certainly wasn't the one
who ratted her out.
On 24 Dec 2024 02:46:06 GMT, rbowman wrote:
On Mon, 23 Dec 2024 22:46:09 -0000 (UTC), Lawrence D'Oliveiro wrote:
On Mon, 23 Dec 2024 21:13:04 GMT, Charlie Gibbs wrote:
When we put the first personal computers on people's desks, the
managers got the fancy powerful machines, we techs got a medium model, >>>> while our poor data entry clerk had to spend all day squinting at the
small screen that came with the cheapest model.
She really got treated like dirt. Several times she stormed out of
the office in tears. One day she never came back.
Just to compound the irony, wasn’t it the prevailing culture in those
days that managers never touched keyboards? Typing was something their
underlings did.
My brother was quite a bit older than I and that was the case. Engineers
engineered, secretaries typed. In high school college entrance kids took
Latin and spherical trig. The business and shop kids took Spanish and
typing. I still can't touch type although I've evolved a fairly
efficient two or three finger style,
Took typing in high school, because I wanted to be able
to type faster on computers. 1984 or so.
Fade-out,fade-in -- went to RM "A" school in the USCG, where we had
a typing course that stressed accuracy over speed. They taught
something called (and I kid you not) the "Cortez Peters Rhythmic Method".
We used IBM Selectrics.
This was to prep us for copying Morse code, where we would hear the
morse character and type it without thinking about it. This worked
well for me (a lot easier than scribbling characters), but didn't
work well for lot of other students: we started with 24 in our class,
and 9 graduated, mostly because they couldn't copy Morse.
I almost never type from copy, but when I do, I slow down and use
"the rhythmic method" -- but on a command line, it's all finger
macros. Regular writing just sort of happens, probably a lot like
your two- or three-finger typing, but I use all my fingers.
I just looked: there are typing tutor programs for Linux (of course),
of which gtypist uses ncurses and isn't necessarily for kids...
According to D <nospam@example.net>:
On Tue, 24 Dec 2024, moi wrote:
On 24/12/2024 13:50, Peter Flass wrote:
Her attitude is one of the biggest things holding desktop Linux back.
Desktop Linux is the main thing holding desktop Linux back.
This is not correct.
Linux doesn't run the programs that desktop users want, most importantly MS Office.
You can claim that Libreoffice is just as good, but it isn't.
Its web browsers are chronically behind the versions for Windows and Mac.
I switched to a Mac because it runs the programs I need to use to exchange files
with other people, while being Unix underneath. It's not particularly cheap but
for me it's worth it.
Card readers were pretty flexible in what they read, but the software will only handle one way. We used to have JCL decks with options. we’d take the optional cards, flip them end for end, and punch “//*” in columns 1-3 to make then a JES comment card. When we needed that option we’d flip them back, so the ignored columns 78-80 would now have “*//“
vallor wrote this post while blinking in Morse code:
On 24 Dec 2024 02:46:06 GMT, rbowman wrote:
On Mon, 23 Dec 2024 22:46:09 -0000 (UTC), Lawrence D'Oliveiro wrote:
On Mon, 23 Dec 2024 21:13:04 GMT, Charlie Gibbs wrote:
I just looked: there are typing tutor programs for Linux (of course),
of which gtypist uses ncurses and isn't necessarily for kids...
I started typing in 6th grade, on my mother's little Olivetti. Impressed
the teachers. Wrote a bunch of (crappy) short stories through high school. Took a typing course in high school as well. Got some chuckles out of this exercise:
On 24/12/2024 13:50, Peter Flass wrote:
Her attitude is one of the biggest things holding desktop Linux back.
Desktop Linux is the main thing holding desktop Linux back.
According to D <nospam@example.net>:
On Tue, 24 Dec 2024, moi wrote:
On 24/12/2024 13:50, Peter Flass wrote:
Her attitude is one of the biggest things holding desktop Linux back.
Desktop Linux is the main thing holding desktop Linux back.
This is not correct.
Linux doesn't run the programs that desktop users want, most importantly MS Office. You can claim that Libreoffice is just as good, but it isn't.
Its web browsers are chronically behind the versions for Windows and Mac.
I switched to a Mac because it runs the programs I need to use to exchange files with other people, while being Unix underneath. It's not particularly cheap but for me it's worth it.
On Wed, 25 Dec 2024 13:11:43 -0500, Chris Ahlstrom wrote:
That's why Microsoft moved Edge to the cross-platform Chromium platform.
It must have really grated to realize after all those years of IE and Edge 1.0 Microsoft couldn't develop a decent browser.
On Thu, 26 Dec 2024, rbowman wrote:
On Wed, 25 Dec 2024 13:11:43 -0500, Chris Ahlstrom wrote:
That's why Microsoft moved Edge to the cross-platform Chromium platform.
It must have really grated to realize after all those years of IE and Edge >> 1.0 Microsoft couldn't develop a decent browser.
It is fascinating, that no matter how many intelligent people Microsoft employs, it seems to be ingrained in the company DNA to produce shitty software in house.
We have a Mac Studio in our kitchen. It's Mrs. vallor's, though
I support it. I'm much happier using my Linux workstation.
I can remember when “N-key rollover” was a selling point.
I can remember, not just setting terminal speeds on serial lines, but setting split speeds -- a slower transmit speed for typing input, a faster receive speed for displaying output.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 4 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 58:54:09 |
| Calls: | 65 |
| Files: | 21,500 |
| Messages: | 73,554 |
