Old Computers Exhibit

prostoalex writes "Arthur Lavine was working for Chase Manhattan bank as a principal photographer. Computer Museum runs an exhibit of Arthur Lavine's photographs of old computer and data processing equipment. Fifteen black-and-white photos from the era where computers were still heading for 1.5 ton benchmark."

Comments

Great days these were

[Brother52]

At the age of 6, my dad dad took me to his workplace which looked exactly like on these pictures (IBM 370, I guess). One of the coolest things was reel-to-reel tape drive that actually PLAYED HYMN of our country (Russia)! The sound was very low and was seemingly made by moving the tape fast in very small steps.

By the way, the purpose of my visit was to play a game called "Klings" - some kind of strategy about alien invasion. It was text-based with some ASCII (or EBCDIC ?) art, had a decent plot and very smart AI.

And the raised floor, under which you could run the cables (or breed mice, which they did at dad's work :), shouldn't it be a must for any geek house? ;)

Re:Photography Museum

[ninthwave]

You can also check out the Obsolete Computer Museum

Some stories...

[powerlinekid]

To go along with the pictures... I was wondering if any of our more experienced /.ers have any stories about these machines? I personally have never seen one up close but I'm sure that alot of us younger folks would love to hear about the quirks of these giants. Thanks in advance.

Re:Some stories...

[bob]

They were a pain in the ass. Consider:

• The edit/compile/run cycle could take hours. I worked as a contractor at NASA Goddard in the early 1980s and we still had couriers that would run around from building to building, picking up card decks to run and dropping off the run card decks with their printouts. You actually spent hours sometimes pouring over hex core dumps because that was faster and less expensive than just trying things on a hunch to see if they worked.
• Proper procedure was that you wrote your program out, by hand, on 80-column "coding forms", which were 8.5"x11" paper tablets with green lines and shading and numbers and stuff. There were little boxes where you would print each character to be punched. Theoretically, these were designed so that you could hand them to a keypunch operator, but I never had a job where we could afford this -- you just punched them yourself. You still used the forms, however, because in some cases you'd have to wait in line for a turn at a keypunch. They made cabinets with special drawers to hold punch cards. When someone left a job, the remaining people would bicker over who got his drawers.
• Since persistent, cataloged disk space was so scarce, the more important measure of your space allocation was the number of hanger slots you had in the tape library. You'd get strips with number codes that you would insert in the plastic band around the 9-track reel, and then go hang them in the library (other sites I worked at made you hand them to the tape librarian). You might put a dozen or more files on a tape and then you'd have to remember how many tape marks to skip to get to the one you wanted. Standard labeled tapes were evil.
  Anyway, You'd code the slot number on in the JCL DD statement and when your job was run, the operator would have to scurry over to tape library to pull it off the rack, mount it on the drive, and push the acknowledge button on the console. Before they needed the tape drive again they'd pull your tape and hang it on the "ready rack"; if that tape was called up again they'd have it right there. But if you went over to pick up your tape shortly after your job ran, you'd often have to ask them to "check the ready rack", or, in the case of NASA Goddard, you could often walk over to the console and yank your tape off the ready rack yourself.
• I had one long-running linear least squares job that we could only run on standby. This meant that you'd submit a card deck to a special bin that could take days to empty. Late at night, after all the paying jobs were run, if there was time left in the operator's shift they'd load one of these jobs and let it run, for free, until the morning shift if necessary. This one particular job would crash in random places, and I was weeks pouring over crash dumps, even resorting to my own special little bit map that I'd use to indicate program status and progress at the point it crashed. Nothing did any good, crashes were completely random. A co-worker, more experienced than I, took a look at it, saw that it was mounting a tape and the tape always got put on the same drive. He told me to rubber-band a note on the deck to the operator, telling him to take that tape drive offline before running the job. It ran to completion that night for the first time.
• At a later job, the company I worked for used a timesharing service. We rented a whole disk pack, which seemed kind of extravagant but was in fact cost-effective given their pricing structure. This was a removable pack and it was kept offline most of the time, and was mounted when needed by a job. There were two ways to manage that space. You could simply code the pack's ID into the JCL and then access files through the on-pack catalog, or you could enter the files into the mainframe's master catalog. Generally, I preferred doing the latter, but I think I was about the only customer they had that did, because as I recall it caused all manner of problems for the operators.

BTW, I believe it was NASA's IBM 360/91 that I remember having drum storage for virtual memory storage. A drum was sort of like a disk drive except it was a cylinder with the magnetic material on the outside surface. Some drums, I think, had heads that moved up and down to read separate tracks, but this one had a long row of heads from top to bottom, reading the tracks in parallel. But I could be remembering it wrong. Anyone else remember these?