Tuesday, January 26, 2016

Magnetic Tape Drives

The primary storage/processing medium on most early computers was the magnetic tape. These were ½” wide pieces of mylar with a magnetic recording surface. They were either 1200’ or 2400’ long. Densities ranged from 200 characters/inch (i.e 200 bpi linearly but with multiple recording channels across the ½” for each bit in a character) to 556 cpi, then 800 cpi, 1600 cpi, and finally 6250 cpi. At 200 cpi you could store roughly 5M in a 2400’ reel. But you could also physically inspect the tape with a low-power magnifying glass and see the individual spots of magnetic recording. At the highest density the capacity was about 140M.

Inter-Record Gaps

But one could not store data continuously the entire length of the tape. Data was stored in records with an IRG (Inter-Record Gap) in between. Because the tape drives had a vacuum tube to hold tape on either side of the read/write head, the tape drive could go from a full-stop to over 100 inches/second in only 1.5 milliseconds. But that still meant that you had to allow about .6” of tape in between records for the unit to go from full speed to a complete stop and then back up again to full speed.

This meant that if you were storing card images (80 characters/bytes) on an 800 cpi tape, then the data would only occupy .1” but each IRG would be .6” so you would be wasting 85% of the tape with the IRGs. So one would have to choose an appropriate “blocking” factor to minimize the IRG “losses”. For example, if you were to block 10 80-byte records, then you would have a full inch of data for each .6” of IRG. But it also meant that you would have to increasing the blocking factor as the tape density got larger. However, this would have an impact on the amount of main memory required to hold each block (see discussion under CPU and Memory).

Reliability

Some of the early tapes were not as reliable as the later ones. If the tape drive could not read a block of data, it would back up and try reading again. After a few tries, the drive would just give up and skip that block (and all the data it contained).

When I began working at Air Products, they had put together a standard solution for this problem. Each program that produced a tape would keep track of the number of records they wrote and at the end of the tape would print a special record that contained the count. Later programs which read that tape would compare the number of records that they had process with the count at the end and would halt with an error message if the two counts did not match. As tape technology became better, the number of errors dropped to zero and this practice was eventually discontinued, but it took a long time before all the programs were changed.

Tape Transmission
As I mentioned at the beginning, I worked at Uniroyal’s Eastern Management Information Center. It was located in Naugatuck, CT. There was also a Western Management Information Center outside of Detroit, MI. Sometimes we needed to get information from one center to the other. Sending tapes by mail/courier was too slow and costly, so we had a tape-to-tape transfer system when needed. So we had a Mohawk Data Sciences machine that could read a tape at one end and transfer the contents over a phone link to an identical machine at the other end.

In order to do this transfer, the data had to be put on a tape at only 200 bpi and the transmission speed was only 200 baud (i.e. an inch of tape a second). Also, there was no take-up reel on the machine, so as the tape unwound through the read/write head it just unwound into a slot where it went back and forth into a pile inside the bottom of the machine. At the end of the transmission it would rewind it onto the original reel. Not very elegant, but it worked and was relatively cheap.

Using Multiple Tapes

Most programs were limited to using at most four tape-drives at once. A large computer could run four simultaneous programs and would have 16 tape drives with four assigned to each of the simultaneous programs. During my first year after graduation (in early 1972), we had a programmer who wanted to use even more. The company had accumulated a sales tape for each month of the prior year, twelve tapes in all. And they wished to have an annual sales tape with information about each customer with a bucket for total sales for each month of the year. That meant that they wanted to do a logical merge of the twelve tapes into one.

But not every customer bought something in every month. So this programmer (I remember his name and much about him, but I won’t repeat it here) tried to write a program that could account for all the different possibilities (only sales in month 1, only sales in month 2, … sales in only months 1 and 2, only sales in months 1 and 3, … sales in months 1-11 but none in month 12, …). If you do the calculations there are 1023 different combinations! His program was very long and very complicated.

The problem was that in order to run a test the operators had to basically idle down the entire machine, manually reassign thirteen (12 input tapes, one output tape) of the sixteen tape drives to his program, and then run the test. Inevitably the program would read just a few records from each of the 12 input tapes, run into a logic problem and then crash. Then the operators would have to reassign all the tape drives back to the other partitions and start a new program in each of them. They grew to HATE this program and would only allow him to test it every couple of days.

After several weeks of failures, the company also grew frustrated with his lack of progress – he had been hired at a significant salary as they wanted a very talented programmer – so they fired him and sent him packing. They then assigned the project to a very junior programmer who immediately recognized that a 12-way merge was much too complicated, so he wrote a two-way merge (a pretty standard program) and ran it 11 times (once with just January and February, once with March plus the result of the first run, …) No special processing, never used more than three tape drives at once, and he was done by the end of the week!


No comments:

Post a Comment