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