Archive for June 3rd, 2007

This blog is now available as a Kindle book – click here


On May 1, 1959,  I took my first job as a computer programmer working for the United States Naval Supply Center, Oakland. After one month’s training, we were thrown on our own and started programming a system that was very advanced for its time, being the first completely transistorized commercially available computer. The computer which we were to program was a Philco Transac 2000 model 210, which was not built for about the first year. (The Computer History Museum has a model 212, a considerable improvement over ours.)  We had to do our debugging at a space satellite company on San Antonio Road in Los Altos – a pretty long commute for a single test run.

Our configuration consisted of the CPU, 8-K words of memory and 8 tape drives. Off line there was a universal buffer controller to which was attached a card reader, a card punch, a printer, and a tape drive. All I/O was done via tape. Input was from punched cards, which were read by very fast card reader and written to tape via the universal buffer controller.  Printing was done by taking a print tape prepared by the computer, attaching it to the universal buffer controller, which would then do tape to print.

A computer word was 48 bits, which comprised two instructions of 24 bits or 8 6-bit binary coded decimal characters or 48 bits of binary data. The only I/O to the computer was the aforementioned eight tape drives, and the Flexowriter console, which also had a paper tape punch and reader.

The Ampex tape drives were a principal source of trouble.  Tape was written in fixed blocks of 128 words, which had to be pre-edited by the manufacturer. The tapes themselves were 2400 foot reels of 1 inch wide one mil mylar. The beginning of a block of one hundred twenty-eight words was designated by an “S-1” mark in the inter-block gap.    An “S-2” mark designated the end of the block. Frequently these marks were either damaged or illegible to the machine or mis-read because of skewing of the very flimsy tape. If the S-1 was missed the tape would advance until one was found, causing the loss of one or more blocks of data. If the S-2 was missed, the I/O controller kept reading until one was found, with the later data supplanting the earlier, having the effect of losing all but the block prior to the S-2.

It was a very serious problem because an insurmountable read or write error could cause a lengthy batch run to fail and have to be rerun from the very beginning (card to tape, etc). On more than one occasion we were late in preparing invoices when the morning shift of warehousemen arrived which not only degraded our service but was costly as well. We made an effort to make our system more resilient by being able to identify the lost block, avoiding any data running over from one block to the next (which limited variable length records to a block or less in size) and so on. We started by setting aside the last two words of each block for a hash total and a sequential block number (I believe this idea originated with Bruce Johnson). We then programmed our I/O handler in our home-grown operating system to generate the hash totals and block numbers in the write process and to read and check them, log errors and do what we could to keep the run from failing (notify the application, etc.) in the read process.

This worked pretty well as far as it went but the errors were so frequent and some applications not able to deal with omitted data that it remained a major headache. We discovered that a very large percentage of the errors were caused by skewing. Normal processing was one block at a time. This meant the tape had to brought up to its considerable speed in a very short time (the inter-block gaps were quite small) which was done by having an electro-mechanical actuator drop a “pinch-roller” onto the tape, passing one block of the tape over the read-write head and then braking it just as suddenly as it was started. With an inch wide, one mil mylar tape, it was no wonder there was frequent skewing.

At the hardware level I/O was initiated with the computer issuing a TIO instruction which transferred the I/O commands to the I/O controller which then executed them. For tape, the command was a composite meaning “skip so many blocks and read so many blocks” with total number of blocks limited to fifteen. The standard was skip zero, read (or write) one. In a multi-block order the pinch-roller would be dropped at the beginning of the first block and the braking would only occur at the end of the last block read. We decided to see if issuing a skip some, read one would get the tape rolling in a smooth straight path and overcome the skewing (I think this idea originated with Henrik Roos). The tapes were capable of reverse reading, backing up a designated number of blocks (skip) and reading backwards. Having the block numbers on the tape allowed us go back 13 blocks (say) check that we were at the block thirteen before the next one wanted and then issuing a skip 12, read 1 command. I used to liken this to Ty Cobb sliding into second base. This worked in a surprising number of instances, considerably reducing the number of reruns.

There were some eight installations of the Transac 2000, the Philco satellite maker subsidiary in Los Altos, GE’s Atomic Products Equipment Division (GE APED) in San Jose and the Israeli Army among them. (All but the Israelis leased their machines; the Israelis bought theirs. When I asked the Philco salesman, Bill Tietz, why the Israeli bought theirs, he replied, “We insisted on it.” “You insisted on it? Where do you get off insisting on it?” “Well you know with Nasser next door and all …” I stuck my finger in the middle of his Countess Mara tie, he was something of a fop, and said “You’d better hope that Nasser tries something – then you can sell the Israelis another computer for their Cairo branch office!” More prophetic than I could have imagined.) They were all having the same tape troubles. When word got out about our “solution” we got several inquiries.

One morning (in 1961 or 2, I think) I was called into the military boss’, Cdr Ed Kocher’s, office. There was a man there in an unfamiliar uniform, grey, with a little vertical collar, piping around all the edges and frog closures – it looked like a West Point Cadet’s outfit. “Roger, this is Colonel So-and-So from the Israeli army. He wants to question you about our handling of block errors.” I spent about an hour with him. He hastened to tell me he was not technical so I tried to make things as clear as I could. He asked more and more detailed questions as the explanation progressed. He had a mind like a steel trap – if I said something that appeared inconsistent with something I had said earlier (largely due to frequent analogizing), he called me on it. It started to become a rather unpleasant experience.

Eight years, to the day, May 1, 1967, after I started at NSCO, I started a new job with Pacific Gas and Electric on lower Market Street in San Francisco. A month later, Monday, June 5, 1967, the Six Day War erupted. I started trying to remember the Israeli Colonel’s name, wondered what happened to him, whether he was still in the army and the like. For the next one or two mornings, I would search my memory while riding the Sacramento Street bus to work. On Wednesday or Thursday, it came to me: “Rabin! That was his name – Rabin, Yitzhak Rabin.” When I got off the bus on Market Street there he was, on the front page of the Chronicle in the newspaper rack.

In 1974 or 75 one of my group at the University of California, Berl Hartman, resigned to go to Israel, where her husband, a molecular biologist, had been granted a research grant by Tel Aviv University. I offered to write her a letter of introduction to my pal, Prime Minister Yitzhak Rabin. She declined my offer – I wonder why.


Read Full Post »