Magnetbånd

Magnetbånd med 7 spor og op til 20 Mbyte data

Magnetbånd var et vigtigt medie for lagring af data i de tidlige computersystemer helt tilbage fra 1951. De blev et alternativ til hulstrimler og tromlelager på grund af deres kapacitet. De første bånd havde 7 spor svarende til en tidlig konvention om at et maskinord var på et multiplum af 6 bits og tegnsæt før ASCII også var 6 bit. Det sidste spor var en paritetsbit. Senere kom der 9-spors bånd svarende til standardiseringen af en byte på 8 bit. I begyndelsen blev åbne spoler brugt. Det blev til kassetter i forskellige størrelser for at beskytte båndene og gøre håndtering lettere.

Brug af bånd til registre

Idag bruges magnetbånd udelukkende til langtidslagring af store datasæt, men i EDB'ens barndom blev de også brugt som databaser eller registre ifølge sprogbrug dengang. Mediet er selvfølgelig for langsomt til interaktiv brug. CPR var oprindeligt lagret på bånd.

Datafiltrering

Hvis man skulle lave et udtræk skrev man et program, som læste båndet fra starten og frem, og derefter skrev de ønskede poster til et andet bånd eller ud på printeren. Programmet kunne skrives i ethvert sprog, men COBOL og RPG er specifikt designet til magnetbånd.

Sortering med bånd

Hvis man skulle sortere datasættet på bånd kunne man også dette. Det krævede mindst 3 båndstationer og helst flere. Man satte båndet med datasættet i station 1, tomme bånd i alle de andre. Algoritmen var merge-sort eller Quicksort.

I tilfælde af en merge-sort med fire båndstationer ser sekvensen således ud:

1. Først skrives to halvdele af masterbåndet ud på båndstationer 3 og 4. Hvis man ikke ved hvor mange poster man har, skifter man mellem stationer for hver post. Det garanterer halvdelen på hvert bånd.
2. Masterbåndet på station 1 skiftes nu ud med et tomt, hvis det skal bruges igen.
3. Derefter spoles båndene på 3 og 4 tilbage og der indlæses én post fra hver station.
4. Posten med laveste sortering skrives på station 1, derefter den anden - også på station 1.
5. Der indlæses én post fra hver station. Samme operation, men på båndstation 2.
6. Dette gentages indtil alle poster er læst fra 3 og 4.
7. Båndstationerne 1 og 2 indeholder nu poster der er sorteret parvis, men parrene ligger usorteret på båndene.
8. Alle bånd spoles tilbage. Nu læses fra 1 og 2, og skrives til 3 og 4. Resultatet bliver sæt på fire poster, som er sorteret internt.
9. Dette gentages, hvor sættene vokser til 8, 16, 32, 64 poster indtil alle poster er sorteret i ét stort sæt.

Der en mange muligheder for optimering. Hvis f.eks. båndstationerne kan læse/skrive baglæns kan man undgå at bruge tid på tilbagespoling. Hvis man har RAM nok kan man sortere nogen af posterne i hukommelsen inden man skriver til bånd, m.m.

Transaktionsopdatering

Den sidste type af database operationer er opdatering med transaktionsfil. Et eksempel kunne være at en filial har modtaget ordrer på varer fra kunder. Disse er blevet opsamlet på bånd og sendt med intern levering til hovedkontoret. Her skal det bruges til at opdatere lagerbeholdningen og debitere kundens konto. Posterne på båndet skal først sorteres fra at være i kronologisk orden til at være sorteret på varenummer. Det producerer et nyt bånd, som kan opdatere båndet med lagerregisteret ved at samkøre båndene. Fra de to bånd læses én post ad gangen startende med transaktionsbåndet. Hvis der på båndet står at der er givet bestilling på to stk. af varenummer 1458 læses lagerregisterbåndet indtil varenummer 1458 kommer frem. Lagerbeholdningen nedskrives med 2 stk. Derefter læses flere poster fra transaktionsbåndet for varenummer 1458. Hvis den næste transaktion er for et nyt varenummer skrives den opdaterede post ud på det nye master bånd og der læses fra lagerregisterbåndet indtil det nye varenummer kommer frem. Normalt ville der også blive fremstillet et fejlbånd, hvis f.eks. der ikke er nok stk. af en vare på lager.

Derefter gentages operationen for kunderegisteret.

Illustraton fra SAMBA manualen

DASK fik fire magnetbåndstationer allerede 1-2 år efter starten. Det gjorde det muligt at udføre administrativ databehandling. Der blev udviklet programmer til manipulation af data på magnetbånd, og her iblandt først og fremmest sortering. Til GIER kunne de også leveres. Der blev yderligere udviklet et program ved navn "System til Administration af MagnetBånd i Algol" - SAMBA.

Brug af bånd til backup

Når man havde oprettet et nyt masterbånd af sit kunderegister efter opdatering med dagens transaktioner ville det være skødesløst ikke at checke det kunne læses fejlfrit og samtidig lave en kopi af det. Derved opstod backup-kopierne. En ny problemstilling opstod da harddiske blev introduceret. Det blev nødvendigt at sikre dataene i tilfælde af fejl. Det var normalt for dyrt at kopiere til en identisk harddisk. Istedet blev der udviklet programmer til backup til magnetbånd. Alle computerproducenter med egenudviklet operativsystem havde dem. Der var ingen standardisering. Backupbånd skulle læses ind på den samme maskintype, som de var skrevet på.

Nogle af disse programmer eksisterer stadigvæk i Linux og BSD-varianterne af UNIX, da udviklerne pligtopfyldende har genskabt hvert eneste program og alle funktioner i UNIX siden halvfjerdserne. Programmerne er tar - Tape ARchive, (r)dump og cpio - CoPy IN/OUT. Rdump antager for eksempel at et bånd er 1600 BPI og har en længde på 2300 feet.

Man tog typisk en fuld backup dagligt. Åbne spolebånd skal spoles helt tilbage førend man kunne afmontere dem og der blev brugt et bånd hver dag, som blev genbrugt efter en periode svarende til hvor længe man ønsker at kunne gå tilbage i tid for at hente en ældre udgave af en fil. Det kunne jo være, at man ikke opdagede filen var korrupt førend en uge senere.

Efterhånden som diskene blev større opstod der et behov for at bruge mindre tid på backup og ideen om inkremental backup blev født. Princippet er at man kun tager backup af de filer, som er ændret siden sidste backup. Det kunne implementeres på forskellige måder. Programmet cpio fødes med en liste over filer der skal arkiveres. Operatøren kan dermed bare levere en liste over de ændrede filer. Rdump har flere niveauer af inkremental backup indbygget. Tar, som er det oprindelige backupprogram på UNIX fik først den mulighed meget sent da GNU projektet reimplementerede programmet.

Magnetbåndshåndtering

OBS ! De fleste af efterfølgende oplysninger er gældende tape og tapehåndtering både tidligere (spolebånd) end IBM 3420 og senere f.eks. med IBM 3480 kassettebånd.

Tapeinitiering og labels (IBM Standard Label)

For at det ene bånd kunne skelnes fra det andet, og dermed de data der lå på det, baseres identiteten på en Standard Label.

Se layout for IBM Standard Label: Fil:IBM 3420 tape label.pdf

• VOL1 (volume label) identificerer selve mediet, HDR1 og HDR2 (header) identificerer de data der bliver skrevet på båndet.
• VOL1 bliver skabt på en hel dugfrisk tape ved kørsel af et lille standard utility-program: PGM=IEHINITT, som bruges til ’at døbe’ alle nye bånd. Volume-betegnelsen er i en IBM Standard Label på max 6 karakterer: Cifre, bogstaver eller en blanding.
• HDR1 og HDR2 udfyldes når data første gang skrives på båndet, og benyttes efterfølgende når data igen skal læses, f.eks. af et andet program.
• HRD1 og HDR2 indeholder f.eks. navnet på datasættet samt opbygningen af datasættet i records, blokke mv., oplysninger det får fra de JCL-kontrolkort der anvendes kombineret med oplysninger fra selve programmet. (JCL = Job Control Language).

Eksempel ved første skrivning:

//NYTOUT DD DSN=datasættetsnavn,DISP=NEW,DCB=(RECFM=FB,LRECL=800,BLKSIZE=8800) ….

Betydning: RECFM (record format = Fixed blocked, LRECL (logical record length – den programmet arbejder med)=800 bytes, BLKSIZE (block size = 8800 bytes – den båndstationen læser ind i en buffer)

Eksempel ved senere læsning:

//GLDATA DD DSN=datasættetsnavn,DISP=OLD	resten læses fra HRD1 Og HDR2

Andre labeltyper Der findes også andre label-type, f.eks. Non-Standard Label eller NL (No Label). Disse vil typisk komme i brug i forbindelse med dataudveksling mellem IBMN og ikke-IBM systemer. Som så meget andet styres bruges via JCL-kontrol, f.eks.

//INDDATA DD DSN=ligegyldigt,LABEL=(,NL)

Da der ikke er en label hvori man kan aflæse datafilens navn er der heller ingen kontrolmulighed og derfor er navnet ligegyldigt’. Det er helt op til programmmerne at håndtere data, kende deres opbygning osv.

Multi-file volumes vs. Multi-volume files

Muliti-file-volume:

For at udnytte båndets datakapacitet bedst muligt kan man lagre flere (ufhængige) datafiler på samme fysiske magnetbånd. Data adskilles f.eks. af IBM’s Standard Label med en HRD1/HDR2 +EOF (end-of-file) for hvert datafile. Men at lægge flere datafiler ud styres gennem de omtalt JCL-kontrolkort, hvor man med en LABEL=(x,SL) angiver hvilken nummer fil (x) man vil arbejde med på båndet. Det er dog en sjældent anvendt metodik, som kun kan benyttes når man specifikt ved at de ’mange’ datafiler er af nogenlunde konstant størrelse for hver kørsel.

Muliti-volume-file:

Til gengæld kan man let forestile sig datamængder så store at de ikke kan være på en magnetbåndsspole (eller kassette) og derfor skal fortsætte på én eller flere yderligere spoler eller kassetter. Her afsluttes den enkelte spole/kassette med EOV-markering (end-of-volume) – og først på sidste spole/kassette med EOF. For at holde styr på det samlede antal medier med den store datafil lader man operativsystemet katalogisere datafilens navn + information om de anvendte båndnumre – være sig i sekvens eller ’tilfældige’. Også dette styres vii JCL-statements, f.eks. //NYTOUT DD DSN=datasættetsnavn,DISP=(NEW,CATLG) hvorefter systemet selv registrerer de anvendte magnetbånd’s volume-numre fra VOL1 på hvert bånd. Se næste afsnit om åbne og lukkede båndsystemer.

Lukket vs. Åbent båndsystem

I en ’god gammeldags’ opdatering kører databåndene i cyclus, dvs. at de over tid genbruges af samme data eller genskrives med andre data. I eksemplerne forudsætter vi daglige kørsler dvs. en ugentlig cyclus.

Lukket båndsystem

Indledningsvis opretter (initierer) man puljer af magnetbånd i nummer-serier, f.eks. 310000-310009 310 indlån xxx løbenumre, mandag 310010-310019 tirsdag Osv.

320000-320009 320 udlån xx løbenumre mandag 320010-320019 tirsdag Osv.

Med den daglige transaktionsfile overføres data (og opdateres) således fra 310000-serien til 310010-serie hver mandag, fra 310010-serien til 310020-serien hver tirsdag osv. Hvorefter der på ugens sidste dag køres fra 310050-serien tilbage på 3101000-serien – og cyclus er fuldendt. Fordelene ligger i at båndarkivar som skal finde båndene frem til dagens kørsler (vi forudsætter at det er tiden før båndrobotter) samt operatørerne har en slags kontrol med, at det er de rigtige båndnumre der anvendes. Ulemperne er så at den enkelt serie på f.eks. de 10 bånd indenfor nummerrækken ikke nødvendigvis er fulde fra starten. Måske fylder data ikke mere ned 2-3 spoler; resten er tommer og vil måske være det længe (måneder, år). Båndserierne vil fylde op i reoler og arkiver med rigtig mange tomme ubrugte bånd.

Åbent båndsystem

Det åbne båndsystem er baseret på scratch-tapes, altså bånd som med god ret kan overskrives, fordi deres indhold ikke længere er aktuelt. Med reference til afsnittet: Multi-volume-files registreres de anvendte volume-numre i systemet og kan derfor fremhentes som input til næste dags kørsel. Output båndene tages af operatørerne eller båndrobotten blandt frigivne bånd i tilfældig rækkefølge. Med baggrund i de katalogiserede data for den enkelte generation data frigiver systemet automatisk (på lister eller i båndrobottens registreringskataloger) de bånd som ikke mere er aktuelle. I datakataloget er angivet hvor længe pågældende data (og dermed spoler/kassetter) skal gemmes, hvorefter de frigives som scratch-tapes og igen kan overskrives. Forudsætter vi, at data kun fylder 3 bånd kan det se sådan ud: Input-volumes: 136887+886241+974211 Output-volumes (scratch) 541289+666492+301178

Fordele

Effektiv udnyttelse af magnetbåndene, ligesom der ikke reserveres flere enheder end der faktisk er data til.

Ulemper

Ingen visuel (og unødig) kontrol af hvorvidt de korrekte bånd anvendes. Det styrer systemerne selv.

Administration omkring scratch-tapes i et manuelt system med magnetbåndsspoler, men ingen ekstraordinær administration ved brug af båndrobotter. Her sker det helt fuldautomatisk som opdatering i robottens kataloger.

Datablokning

Der er flere fordele ved at blokke data (samle et antal records i én block), dels at det fylder mindre på båndet, hvor der ellers ville være et mellemrum (inter record gap) mellem datarecords – mellemrum der kunne fylde mere end data i den enkelt record - samt en væsentlig forøget hastighed i læsning og skrivning. Der læses altid fra (interblock)gap til (interblock)gap og indholdet overføres til en eller flere buffere i storage. Jo flere data der ligger i bufferne, jo hurtigere kan programmet der skal arbejde med dataindholdet få fat i det, ligesom behovet for at hente data ude på båndet er ’sjældnere’. Tommelfingereglerne er

• korte records samles i store blokke
• records med kort behandlingstid samles i store blokke
• records med lang behandlings kan samles i mindre blokke

Det væsentlige tidselement er båndstationens stop/start tid.

Her en simpel illustration af tidsforbruget og forskellene.

Vi estimerer at START = 3 tidsenheder, læsning af 1 record er = 1 tidsenhed og STOP er = 2 tidsenheder. Ved læsning af f.eks. 20 records vil det se sådan ud:

Ublokket: I alt 120 tidsenheder: 

20 x START = 60 tidsenheder, 20 læsninger = 20 tidsenheder, 20 STOP=40 tidsenheder

Blokket med 10 records/block = 2 blokke: I alt 30 tidsenheder: 

2 x START = 6 tidsenheder, 20 læsninger = 20 tidsenheder, 2 STOP=4 tidsenheder

Billeder

• 
  Magnetbånd med 9 spor og op til 140 Mbyte data
• 
  8 spors amerikansk båndkassette
• 
  QIC bånd blev de facto standard til minidatamater
• 
  Exabyte 8mm tape
• 
  100/200 Gbyte Ultrium Båndkassette