four decades of magnetic tapes: ( how) (have) they managed to survive(?)

Four decades of magnetic tapes:(How) (have) they managed to survive(?)

 • Why has tape survived at all? • At CERN in 1972 (as a visitor ) I used a FORTRAN analysis program

• The program was on two trays of  punched cards 

• Data was then stored in a really modern manner, on 7-track tapes! 

Revenues, $Bn

2008 2009 2010 2011 20120

10

20

30

40

50

60

70

HDDNANDLTO

Tape has survived, but by a slim margin

A 1972 tape (and user?) problem

• A user  of that era , optimistically clutching his card deck, is discussing directly his problem with the IBM operator. 

• Problems and users are closely correlated….

Disk (far) cheaper than tape• Disk storage existed then, but was extremely expensive.  Heads, motor, power, plugs, host

• Users had to keep data on tape, of questionable reliability….. But no motors, power, ….

• At about this  time the main CERN computer centre moved to 513, and the tape  reels moved to the basement. 

• An unfortunate compromise  made this rather inconvenient for the next thirty years: every tape requested had to be carried up a spiral staircase to the drives. 

IBM 350 RAMAC 

1956,  5 Mch, 8 Kch/s IO

PDP DECtape

1970, 144K 18_ bit words

CDC 7600

• Here is CDC’s 7600, the principal resident of the new centre, an extremely advanced machine, which read tapes rather indirectly via a smaller CDC  6400 or 6500 as a ‘front-end’. 

• It was easy to crash this machine by reading an unusual tape via CDC Scope 2.1 and 6/7 RM

CDC engineer and 64 K

• Not much at all was reliable  in 1974: here is a 64 kilobit stack from the CDC 6600 in ‘maintenance’

• No chance whatsoever of 5 or 6 sigma reliability: just 1 was surprising.

• In 1974 I joined ‘DD’, and one of the main problems (apart from questions about PATCHY) was the unreliability of the tape subsystem

• This was compounded by the users themselves, who regularly didn’t know what was on their tapes or how to read them 

• Disk still being surprisingly expensive, tape numbers ballooned until we were ‘archiving’ more than half of them. It would probably be then that Sverre and the other curious folk known as ‘system programmers’ were trying to do the tricky task of adding reliability to the tape systems, where all the data still lurked

• Note the presence of no fewer than 4 staff (one is a senior CDC manager) apparently needed to operate 3 tape drives!

Better drives help

• The self-threading tape reel  had now arrived, as well as 9 tracks, removing the need to remove the tape case (and put it back), reducing work

• Still, no user data resided permanently on disk. 

• The CDC Scope 2.1 operating system was able to stay alive sometimes for a day or more…….

How to gain reliability and handle more data?

• A Boeing engineer’s famous reply  when asked what he did was that his job was

• ‘To simplificate and add lightness’• For tape handling it’s the same, really:– Fewer errors = better drives and media– Less work = Fewer bits of media  per GB– Even less work = automation

IBM’s 3850 MSS: a working system!(despite being tape, really)

New IBM drives and media

• Tape reliability took a big jump forward with the self-enclosed and lightweight IBM 3480 type of cartridge. There were still many drive builders and media suppliers….. 

The last 200 MB tape

Drives go below

• Growing  tape demands led to a need for far more space and many more drives. Eventually most moved to the basement. Here the old IBM and CDC cabling to drives is being removed from the false floor….

IBM-Haushahn automation prototype3480 and TA90: no photo!

Considered were; 

Proved hard to maintain, and was replaced by IBM 3495

and Comparex

The IBM 3495 (and 3494)

Connected by IBM channel, only 3480 and 3490  drives and media

We have a problem!

IBM 3494

• The 3590 Magstar, 10 GB now  (but not SCSI)

STK, Redwood, Powderhorns

• Things are a little calmer…• SCSI connect, 10/25/50 GB• Potential  capacity to automate everything

The STK Redwood: 10/25/50 GB

• 50 Kg, helical, lots of parts, tricky to keep running

Others, such as DEC DLT robot TL820

Popular and low cost drive, but robotics small, tricky….

So, de we automate everything now?

• Manual 3480 and 3490 to Redwood• What about the rest (DLTs, Exabytes, …)?

Mass copy to high density done• STK 9840 and 9940 now replace Redwood• Drives and media are now reliable• Down to a tiny operational staff• Now, can we get rid of the users?  Or ignore  them, in a sense?

– Disk still too expensive for everything, tape persists– Needs software to  hide the tape layer– HPSS, Lachmann Legent, ADSM, Eurostore, ….

• CASTOR does this job ( but needs repack….)

CASTOR tape pool….

Not ALL problems have gone!

Dual supplier era, STK and IBM

• STK/Sun/Oracle , T10000 and successors• SL8500 library replaces Powderhorn• Tape faster than disk! (still cheaper too)

Dual supplier era, STK and IBM

• IBM TS3500 Library• 3590 successors:– TS1130, TS1140

Nearly there now, after 40 years

• No operators• High capacity, fast drives• High capacity, quite fast libraries• No need for users (to know about tape)• Media needs no power, has a long(ish) life• Better data security possible if desired• Can the CERN software disappear too?• Disk is a cheap throwaway commodity now!

People were needed, though, to do this(even if they didn’t know they were helping)

Antonio Maver, Hugo Caçote, Jean-Phillipe Baud, Jean-Damien Durand, Fabien Collin, Ingo Augustin, David Asbury, Eric McIntosh, Jean-Claude Juvet, Ans Oude-Moleman, Ian McLaren, Les Robertson, Tony Cass, Jamie Shiers, Harry Renshall, Tim Bell, Dietrich Wiegandt, Ben Segal, Christian Letertre, Ben Segal, Tony Osborne, Gordon Lee, Linda Whitley, Judith Richards, Jean-Claude Brahier, Bertrand Oppliger, Johannes Gerber, Marcel Würtrich, Jacques Rault, Pasquale Di Cesare, Jean-Michel Thiboud, Alain Bruni, Ed Aden, Hal McIlroy, Dick Replogle, BobWilson, Pete Colton, Vittorio Frigo, Silvano De Gennaro, Jacqueline Gudet, Gildas Auffret, Jean-Claude Bourigault, Klaus Pluntke, Dick Minchin, Lenny Hoejenbos, Vlado Bahyl, Jean-Francois Lachavanne (in no particular order, and others, whom I may have missed)