Slashdot Mirror
What Does It Take To Keep a Classic IBM 1401 Mainframe Alive? (ieee.org)
"Think your vintage computer hardware is old?" writes long-time Slashdot reader corrosive_nf. "Ken Shirriff, Robert Garne, and their associates probably have you beat.
"The IBM 1401 was introduced in 1959, and these guys are keeping one alive in a computer museum... [T]he volunteers have to go digging through historical archives and do some detective work to figure out solutions to pretty much anything!" Many things that we take for granted are done very differently in old computers. For instance, the IBM 1401 uses 6-bit characters, not bytes. It used decimal memory addressing, not binary. It's also interesting how much people could accomplish with limited resources, running a Fortran compiler on the 1401 with just 8K of memory. Finally, working on the 1401 has given them a deeper understanding of how computers really work. It's not a black box; you can see the individual transistors that are performing operations and each ferrite core that stores a bit.
"It's a way of keeping history alive," says one of the volunteers at Silicon Valley's Computer History museum. "For museum visitors, seeing the IBM 1401 in operation gives them a feeling for what computers were like in the 1960s, the full experience of punching data onto cards and then seeing and hearing the system processing cards....
"So far, things are breaking slowly enough that we can keep up, so it's more of a challenge than an annoyance."
"The IBM 1401 was introduced in 1959, and these guys are keeping one alive in a computer museum... [T]he volunteers have to go digging through historical archives and do some detective work to figure out solutions to pretty much anything!" Many things that we take for granted are done very differently in old computers. For instance, the IBM 1401 uses 6-bit characters, not bytes. It used decimal memory addressing, not binary. It's also interesting how much people could accomplish with limited resources, running a Fortran compiler on the 1401 with just 8K of memory. Finally, working on the 1401 has given them a deeper understanding of how computers really work. It's not a black box; you can see the individual transistors that are performing operations and each ferrite core that stores a bit.
"It's a way of keeping history alive," says one of the volunteers at Silicon Valley's Computer History museum. "For museum visitors, seeing the IBM 1401 in operation gives them a feeling for what computers were like in the 1960s, the full experience of punching data onto cards and then seeing and hearing the system processing cards....
"So far, things are breaking slowly enough that we can keep up, so it's more of a challenge than an annoyance."
The first computer I ever used was a 1401 (at Rice University in 1963). As an undergrad, I only got computer time early in the morning (0700hrs), and usually had to turn the thing on, then wait 30min for it to warm up.
It was punched-card input and punched-card output; only grad students could use the console typewriter (a real flailing-arm typewriter, not a Selectric).
But I taught it to do my engineering homework (FORTRAN; not even FORTRAN II). I graduated with a masters in ME, but I was an aerospace programmer for 46 years. Never did a lick of engineering.
My first job (before I graduated) was as a computer operator trainee, working for IBM at the Manned Spacecraft Center in Houston, in the Real Time Computing Complex, 1st floor of bldg 30, Mission Control. That room had 5 IBM 7094 mod II machines, to do the real computations, and 2 IBM 1460 machines (1401 big brother) to process the input and output magnetic tapes for the 7094s, so my 1401 experience paid off.
One day I was about to be late for work, for an important test. I ran into the building, down the hall, and turned the corner to the right, and ran smack into someone running around the same corner in the opposite direction. I knocked him down. I reached my hand out to help him up, about to apologize profusely, when I realized it was Gus Grissom. Being a computer operator, working on a very cold floor, we all wore Hush Puppy shoes (thick foam soles; insulators). He was wearing leather-soled brogans, so he went down. As I helped him up, I said, "Ohmygod, I've broken government property. Sorry; I'm late for a test." He replied, "Me, too! You do good, OK?" Four years later, he burned to death in the Apollo fire :(.
I went on to work in Flight Software for the Viking Program Mars lander, and to install a computer at Cape Canaveral Air Force Station, on the occasion of shuttle Discovery's maiden launch. It was stupendous.
So, thank you lowly 1401 for giving me a jump-start to a wonderful career.
They just defined bytes to be 6 bits. Bytes haven't always been 8 bits. Historically some machines used 9-bit bytes or 36-bit bytes.
In 1963, I joined the (now long-gone) first "service bureau" in the Country, C-E-I-R, strategically positioned in Arlington, VA, within walking distance of the Pentagon...their first major client. Our "Computer Center" had one IBM 709 (a big boxy group of racks, and 12 tape drives...disk drives hadn't yet been invented...and an adjacent IBM 1401.
To make the costly (then $800/hour) 709 more efficient, all written programs (in "assembly code" unique to the computer model, or FORTRAN, if you were lucky) were manually typed, line by line into "punch card" decks that were read and copied on the 1401 to magnetic tape reels, the reels than tagged with the project name, then carried to the other end of the room to be loaded from magnetic tape reels into IBM 709 memory for execution.
During that execution, the tape drives would whirl and the programs and starting data copied to the 709's memory. Memory capacity was, in today's terms, "vanishing small" but the program performed it's computations and produced results. It could be minutes, hours, or even (occasionally) days in duration. Then, the output of the program would be written to tape(s), and returned to the 1401 for printing of results. (One was always suspicious of quick results, because it inevitably meant that the program had a fatal "Bug" in it, which had to be diagnosed and repaired.) I've witnessed piles of printed outputs from some programs that stood taller than any person in the Center. Then, we'd likely find some gibberish in those piles of papers, necessitating finding and fixing the errant instructions on the original punched cards...and the process would be repeated until the results were deemed "bug free."
These were the fastest and sleekest way to produce meaningful results of the day. Of course, all those military projects were "Classified," so programmers and computer operators all had to have quite high-level security clearances...largely because the projects were all related to military strategy and/or predictions of likely outcomes of warfare under varying conditions. It also meant there was no sharing of programming techniques or skills outside the computer center or the clients' premises.
Then we got a magical new product: The faster, sleeker, more powerful IBM 7090, and more reliable upgrades.
But, for all that, it was an exciting time to be engaged in the design, development and coding of new mathematical algorithms (e.g., "Linear Programming", that could yield reports that shaped major decision-making in corporations and government agencies.
The cadre of programmers at C-E-I-R* even created the first (to my knowledge) shareware. It was called "CELIB"
(C-E-I-R Library, sometimes "CLIB"). It collected all the basic tools the programmer on an IBM 1401 needed to use, including stock tools for writing punched card data to tape, printing data from tape to the IBM 1402 printer, or even conducting Sorting of data in one order (e.g., by title) to another (e.g., by date). We all carried our "deck" and it's sparse manual around from project to project. It was published via IBM's SHARE project, where tools like these were made freely available to peers. On my first trip to Australia, I was amazed to see, 12 years after CELIB had been shared, that it was still in use, and had been adopted by a University in Sydney as their common convention for all IBM 1401 programmers, and was taught to students as an example of good coding style and practice.
Smaller, simpler projects (.e.g., inventory management for a chain of retail stores) were programmed for the IBM 1401, with it's arcane idea of variable-length words (an arbitrary number of adjacent 6-bit characters, marked off from one another by the "word mark", a special bit that separated groups of bits into meaningful characters. We did everything from help customers decide how a perishable product (like fruits and vegetables) should be priced to the consumer, to figuring out how many submarines the Pentagon should plan to buy in the next decade...and
This story brings back fond memories for me. In my first term of "data processing" we did our work on an IBM 1401 (circa 1982). The teacher was an old IBM guy who brought it to the school. As the story says, 6 bit "bytes" with a parity bit and a checkmark bit. You had to write your code to bootstrap your program in. The "OS" consisted of loading your card deck in the reader and punching the start button. It would read the first card into memory from address 0 to 79 then start executing at address 0. After that you were on your own. Output was to a card punch (address 100-179) or the 1403 printer (address 200-331). The rest of the total of 4K of memory we had was available for use. The word length was defined by the checkmark bit. You could put in two thousand digit numbers and add or subtract them. It was humorous sometimes when someone would make a programing error during the printing part of their program and get in a fast loop of page feeds. The 1403 printer could shoot the paper to the ceiling when it was feeding the paper that fast and the best solution was to put your foot on the top of the box of paper to rip the paper and stop the feed.
The last program we wrote was a fairly complex inventory problem. The 1401 only did add and subtract and the input data had one item that needed multiplying by a large number in the 200,000 range. You could tell when we ran the program who had written multiply routines in their programs and who just wrote a loop to do that many additions. The multiply routines would finish in a second or two but the add loops took over a minute to complete. I had great fun running and programming that thing.
An Arduino, a bunch of amber colored LEDs, and pre-recorded BEEEP BOOP Star Trek sounds.
Imagine a beowulf cluster of these!
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.