1 / 29

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

Four decades of magnetic tapes: ( How) (have) they managed to survive(?). W hy has tape survived at all? A t CERN in 1972 (as a visitor ) I used a FORTRAN analysis program The program was on two trays of punched cards

iolani
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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!

  2. Tape has survived, but by a slim margin Revenues, $Bn

  3. 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….

  4. Disk (far) cheaperthan 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.

  5. IBM 350 RAMAC PDP DECtape 1956, 5 Mch, 8 Kch/s IO 1970, 144K 18_ bit words

  6. 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 waseasy to crash this machine by reading an unusual tape via CDC Scope 2.1 and 6/7 RM

  7. 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.

  8. 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

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

  10. 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…….

  11. How to gain reliability and handle more data? • A Boeing engineer’sfamousreplywhenaskedwhathedidwasthathis job was • ‘To simplificate and addlightness’ • For tape handling it’s the same, really: • Fewererrors= better drives and media • Lesswork = Fewerbits of media per GB • Evenlesswork = automation

  12. IBM’s 3850 MSS: a working system!(despitebeing tape, really)

  13. New IBM drives and media The last 200 MB tape • 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…..

  14. 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….

  15. IBM-Haushahnautomation prototype3480 and TA90: no photo! Consideredwere; and Comparex Proved hard to maintain, and wasreplaced by IBM 3495

  16. The IBM 3495 (and 3494) We have a problem! Connected by IBM channel, only 3480 and 3490 drives and media

  17. IBM 3494 • The 3590 Magstar, 10 GB now(but not SCSI)

  18. STK, Redwood, Powderhorns • Things are a little calmer… • SCSI connect, 10/25/50 GB • Potentialcapacity to automate everything

  19. The STK Redwood: 10/25/50 GB • 50 Kg, helical, lots of parts, tricky to keep running

  20. Others, such as DEC DLT robot TL820 Popular and lowcost drive, but roboticssmall, tricky….

  21. So, de we automate everythingnow? • Manual 3480 and 3490 to Redwood • What about the rest (DLTs, Exabytes, …)?

  22. Mass copy to high densitydone • STK 9840 and 9940 now replace Redwood • Drives and media are nowreliable • Down to a tinyoperational staff • Now, canwegetrid of the users? Or ignore them, in a sense? • Diskstilltooexpensive for everything, tape persists • Needs software to hide the tape layer • HPSS, LachmannLegent, ADSM, Eurostore, …. • CASTOR doesthisjob ( but needsrepack….)

  23. CASTOR tape pool….

  24. Not ALL problems have gone!

  25. Dual supplier era, STK and IBM • STK/Sun/Oracle , T10000 and successors • SL8500 library replaces Powderhorn • Tape fasterthandisk! (stillcheapertoo)

  26. Dual supplier era, STK and IBM • IBM TS3500 Library • 3590 successors: • TS1130, TS1140

  27. Nearlytherenow, after 40 years • No operators • High capacity, fast drives • High capacity, quitefastlibraries • 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 disappeartoo? • Diskis a cheap throwawaycommoditynow!

  28. People wereneeded, though, to do this(even if theydidn’t know theywerehelping) 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, VladoBahyl, Jean-FrancoisLachavanne (in no particularorder, and others, whom I may have missed)

More Related