Someone asked the question about what good are reading tapes NL. There are 
valid reasons and these go back to the early years before diskettes, etc, when 
people wanted to tansfer data. Early, early on the universal mode of transfer 
was 7-track tape, BCD, Even-parity with no labels. People have heard about 
2400 foot reels or even 3600 foot reels, but back then 300 & 600 foot mini-
reels were prized. Along came 9-track 800 and even 1600 along with the 
capability to do ASCII formats with even ASCII labels. 

Other computer makers offered some capability of making IBM SL or AL labels. 
Some worked and some did not. So what I told everyone was "no labels" for I 
would only have to bypass them anyway most of the time.  Interesting enough 
the IRS in the early years created a whole system of "SUL" (user Labels) which 
was really challenging. 

Besides the NL was preferred early on because most tape libraries ran with all 
SL tapes internally. When outside data came in the applications person coded 
NL and if OPS mounted accidently a SL tape to read, it would kick it down. 
This was preferred to having the code BLP.  The use of BLP was tightly 
controlled for early security reasons. 

One offshoot of NL, SL, etc, was the writing of the many existing utilities to 
handle tape copying, dumping, and securing. One utility which came out was a 
program to read down all the data, jump over all the tapemarks to find the real 
end of data, and then write binary zeros out to the end of reel. A few times I 
got data tapes from corporations, jumped all the tapemarks and read 
meaningful sensitive corporate data beyond the logical end.  The other 
directive was always to degauss the tape and relabel it for use. But then 
SYSPROG's sometime took shortcuts. 

I do not miss the old days at all. 

Jim     

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to