⟦51c42ebf0⟧

TextFile

incopg=set 150 disc2
incopg=typeset time.yes
*se$* $pl ,40,210,,20$
$pn 0,0$$lw 160$ $ld 12$
$sb @,6$
$ps0$
$nl$
H.C.Ørsted Institute
$pn 5,1$
$nl$
Computer Department
$nl$
Universitets parken 5
$nl$
DK-2100 København Ø
$nl$$nl22$
$ct$
Designmæssige overvejelser og
indkøringserfaringer med et 'inkrementalsave'-system.
$nl3$
$ct$
Viggo Nis Kørst.
$nl10$
$qr$
ORCB version 1.0
$rh 1,INKREMENTALSAVESYSTEM$
$ps0$
$rj$$nl$
_«bs»I_«bs»N_«bs»D_«bs»H_«bs»O_«bs»L_«bs»D_«bs»S_«bs»F_«bs»O_«bs»R_«bs»T_«bs»E_«bs»G_«bs»N_«bs»E_«bs»L_«bs»S_«bs»E_«bs».
$nl$
$nl$$nl$
1.INDLEDNING...............................3
$nl$$nl$
2.FORMÅLET MED SYSTEMET....................4
$nl$$nl$
3.BESKRIVELSE AF SYSTEMETS VIRKEMÅDE.......6
$nl$
3.1.Beskrivelse af INCLOAD.................6
$nl$
3.2.Beskrivelse af INCSAVE.................7
$nl$
3.3.Beskrivelse af INITSAVECAT.............8
$nl$
3.4.Beskrivelse af INITMTPOOL..............8
$nl$
3.5.Beskrivelse af INITTEMPCAT.............8
$nl$
3.6.Beskrivelse af LISTMTPOOL..............8
$nl$
3.7.Beskrivelse af LOOKSAVE................8
$nl$
3.8.Beskrivelse af UPDMTPOOL...............8
$nl$$nl$
4.FORSKELLIGE KOPIERINGSMETODER............9
$nl$$nl$
5.ORGANISERINGSMÅDER AF KATALOGET.........13
$nl$
5.1.Beskrivelse af indholdet af kataloget.13
$nl$
5.2.Overvejelser om katalogform...........14
$nl$$nl$
6.ANDRE DESIGNMÆSSIGE OVERVEJELSER........21
$nl$$nl$
7.INDKØRINGSERFARINGER....................24
$nl$
7.1.Krav om korrekt dato..................24
$nl$
7.2.Forskellige magnetbåndsformater.......25
$nl$
7.3.Problemer på Geodætisk Institut.......26
$nl$
7.4.Fejl i standardprogrammel fra RC......27
$nl$
7.5.Benyttelse af LOAD....................28
$nl$
7.6.Samlet indtryk af indkørinserfaringer.28
$nl$$nl$
$nl$$nl$
Bilag 1 Incsaveman.
$ps0$
_«bs»1_«bs»._«bs»I_«bs»N_«bs»D_«bs»L_«bs»E_«bs»D_«bs»N_«bs»I_«bs»N_«bs»G_«bs».
$nl$
$np$
Denne opgaves baggrund er, at jeg har udviklet et såkaldt 'inkrementalsave'system
til en RC8000 datamat.
Ved et 'inkrementalsave'system forstås et system, der foretager sikkerhedskopiering
af filer fra plade- og tromlelagre.
Denne sikkerhedskopiering foregår ud fra bestemt kopieringstrategi, og
det er udformningen af kopieringsstrategien,
der har givet navnet 'inkremental'savesystem.
I forbindelse med udviklingen og indkøringen af
systemmet,
går opgaven ud på at beskrive, hvilke designmæssige
overvejelser, der er foretaget i forbindelse med konstruktionen.
Derudover går opgaven ud på at beskrive, hvilke erfaringer, der er opnået
under indkøringsfasen.
$nl$$np$
Opgaven vil først indeholder en beskrivelse af formålet med
systemet (Afsnit 2).
Derefter beskrives, hvordan det fungerer, og hvad det består af (Afsnit 3).
Det kan virke ejendommelig at medtage en beskrivelse af systemets virkemåde,
inden en diskusion af design. Dette skyldes, at de designmæssige overvejelser
primært drejer sig om organisationen af forskellige hjælpefiler.

Disse overvejelser har således
ikke indflydelse på hovedprincipperne i
systemets virkemåde.
$nl$$np$
Afsnit 4 beskriver, hvilke metoder, hvorpå
man kan kopiere filer fra plade- og tromlelagre op på magnetbånd.
Afsnit 5 beskriver, hvordan et katalog over kopierede filer
kan organiseres, og giver en begrundelse for, hvorfor og hvordan det er blevet organiseret
på den måde ved mit system.
Andre væsentlige designmæssige overvejelser vil blive foretaget og
begrundet i afsnit 6. Til sidst vil rapporten indeholde en beskrivelse af,
hvilke erfaringer,
der er opnået i forbindelse med indkøringen af
systemet (afsnit 7).
$nl$$np$
I tilknytning til opgavens sidste afsnit om afprøvningen, kan det
nævnes, at systemet er blevet udviklet på H.C.Ørsteds Institutets EDB-afdeling.
Det har her været benyttet i ca. 3 måneder. Derudover er det installeret
på Geodætisk Institut.
$nl$$np$
Da systemet er udviklet på H.C.Ø. er en
del designmæssige overvejelser foretaget i forbindelse med kendskabet
til de datamængder, som findes der. Dette vil fremkomme ret tydeligt
i rapporten, og det har vist sig, at de på Geodæstisk institut har
væsentlig større datamængder. Dette bevirker, at en del af implementeringsstrategien
er mindre hensigtmæssig.
$ps0$
_«bs»2_«bs»._«bs»F_«bs»O_«bs»R_«bs»M_«bs»Å_«bs»L_«bs»E_«bs»T__«bs»M_«bs»E_«bs»D__«bs»S_«bs»Y_«bs»S_«bs»T_«bs»E_«bs»M_«bs»E_«bs»T_«bs».
$nl$$np$
Dette afsnit beskriver, hvad systemet skal bruges til, og hvilke
krav,
der blev stillet, da udviklingen af systemet påbegyndtes.
$nl$$np$
Formålet med systemet er at give en så stor sikkerhed som mulig
for, at filer kan genetableres ved såvel brugerfejl som systemfejl.
Hvis en bruger f.eks. sletter en fil ved en fejltagelse, skal denne fil kunne
genetableres.
Det vil sige, at ud fra en rimelig kopieringsstrategi skal
dele af plade- og tromlelageret overføres til magnetbånd. Denne kopiering
kan foregå ved forskellige strategier, og afsnit 4
indeholder en beskrivelse af strategier, der kunne tænkes anvendt.
$nl$$np$
Ved en rimelig kopieringsstrategi forstås en kopiering, hvor kun de
filer medtages, der er absolut nødvendige. At det er nødvendigt at medtage en fil,
når en kopiering foretages, kan skyldes, at filen er blevet modificeret,
således at den nyeste version af filen ikke findes på et magnetbånd.
Udover dette findes et andet væsentligt kriterium for at kunne
vurdere om en kopieringsstrategi er rimelig. Hvis
f.eks.
en hel plade skal genetableres efter en systemfejl, skal antallet af bånd,
der skal benyttes ved genetablering af informationen på denne plade, være så
lille som mulig.
$nl$$np$
Der leveres fra RC's side som standard et
system, der kan kopiere filer fra baggrundslageret op på magnetbånd.
Dette kan kun foretage såkaldte 'totalsave' af baggrundslagre.
Det vil sige, at hele plade- eller tromlelagre kopieres op på magnetbånd.
At dette system ikke kan anvendes skyldes, at det tidsmæssigt vil
tage for lang tid, og at antallet af magnetbånd, der benyttes til dette,
vil være uforholdsmæssig stort.
En anden stor ulempe ved systemet er, at ved en totalkopiering af pladelagre
eller lignende vil udskrifterne af kopierede filer ikke være ordnet i nogen
speciel rækkefølge.
$nl$$np$
Ved konstruktionen af 'inkrementalsave'systemet blev besluttet,
at programmet, der skal benyttes til genetablering af filer fra magnetbånd,
skulle være RC's standard program LOAD (se ref 1).
Denne beslutning har stor betydning, idet man herved binder sig til et bestemt
magnetbåndformat.

$nl$$np$
Et af de vigtigste krav til 'inkrementalsave'systemet er,
at det skal kunne foretage en delvis kopiering af pladelageret
f.eks. en kopiering af de filer, der er ændret siden en speciel dato.
Udover dette krav skal der konstrueres et katalog, som
skal indeholde data om kopierede
filer.
Kataloget skal indeholde den information, der er nødvendig for at kunne
identificere en fil. Derudover skal der findes oplysninger om, på hvilke
bånd en fil findes.
$nl$$np$

Til kataloget skal der konstrueres et program, som kan slå op
i det, og f.eks. finde en fil med et givet navn.
Organisationen af kataloget bør være således, at det skal gå rimeligt
hurtigt at slå op i det. Dette skyldes, at
de fleste anvendelser af
systemet er der, hvor en bruger ved en fejl har slettet en af sine filer.
Denne bruger skal have mulighed for hurtigt at kunne finde
ud af, på hvilket magnetbånd den pågældende fil findes
for at kunne genetablere filen.
I tilfælde af,
at filen findes på flere bånd, skal den
ønskede version kunne genetableres.
$nl$$np$
Et yderligere krav til systemet er, at udskrifterne over kopierede filer,
skal være i alfabetisk orden,
da det letter f.eks. en operatør
ved en manuel søgning efter en fil. Dette kan f.eks. forekomme,
hvis en bruger ønsker en fil genetableret, men
brugeren ikke helt kan huske navnet på filen, kun måske
de to eller tre første bogstaver i filens navn.
$nl$$np$
'Inkrementalsave'systemet skal primært benyttes af operatører, som dagligt
skal kalde 'save'rutinen, der kopierer filer op på bånd.
Systemet
skal derfor holde rede på de benyttede magnetbånd. Normalt benyttes
et vist antal bånd til systemet. Nogle af
disse bånd anvendes til totalkopiering af baggrundslageret og andre
bruges til delvis kopiering. Systemet skal således administrere,
hvilke bånd der skal benyttes til de forskellige kopieringer.
Denne administration skal foregå efter følgende principper:
$nl$$np$
Ved en totalkopiering skal det ældste bånd, der før er blevet
benyttet til en sådan kopiering benyttes (ækvivalent for daglige kopieringer).
Ved denne metode
vil en fil overleve på magnetbånd så længe som muligt med de
anvendte bånd.
$ps0$
_«bs»3_«bs»._«bs»B_«bs»E_«bs»S_«bs»K_«bs»R_«bs»I_«bs»V_«bs»E_«bs»L_«bs»S_«bs»E__«bs»A_«bs»F__«bs»S_«bs»Y_«bs»S_«bs»T_«bs»E_«bs»M_«bs»E_«bs»T__«bs»V_«bs»I_«bs»R_«bs»K_«bs»E_«bs»M_«bs»Å_«bs»D_«bs»E_«bs».
$nl$$np$
Dette afsnit vil give en kort beskrivelse af de i systemet indgående
programmer. Ud fra dette vil hovedprincipperne for systemets
virkemåde fremgå.
$nl$$nl$
_«bs»S_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»e_«bs»t__«bs»b_«bs»e_«bs»s_«bs»t_«bs»å_«bs»r__«bs»a_«bs»f__«bs»f_«bs»ø_«bs»l_«bs»g_«bs»e_«bs»n_«bs»d_«bs»e__«bs»p_«bs»r_«bs»o_«bs»g_«bs»r_«bs»a_«bs»m_«bs»m_«bs»er:
$nl$
$sj$
INCLOAD

INCSAVE

INITSAVECAT

INITMTPOOL

INITTEMPCAT

LISTMTPOOL

LOOKSAVE

UPDMTPOOL
$rj$
$nl$$np$
Af disse programmer er INCSAVE det største og langt det vigtigste.
Programmet foretager selve kopieringen af filer
fra plade- og tromlelagre.
$nl$$nl$
_«bs»D_«bs»e_«bs»n__«bs»n_«bs»o_«bs»r_«bs»m_«bs»a_«bs»l_«bs»e__«bs»b_«bs»e_«bs»n_«bs»y_«bs»t_«bs»t_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»s_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»e_«bs»t__«bs»v_«bs»i_«bs»l__«bs»v_«bs»æ_«bs»r_«bs»e__«bs»p_«bs»å__«bs»f_«bs»ø_«bs»l_«bs»g_«bs»e_«bs»n_«bs»d_«bs»e__«bs»m_«bs»å_«bs»d_«bs»e_«bs»:
$nl$$nl$
Systemet startes med, at der foretages en totalkopiering af samtlige
filer, der findes på plade- og tromlelageret. Denne kopieringsform
vil derefter normalt blive foretaget hver 14. dag. Mellem totalkopieringerne
foretages daglig en kopiering, hvor kun det, der er ændret siden sidste
kopiering, medtages.
Derudover medtages filer, der findes på forrige dags kopieringsbånd.
$nl$$np$
Nedenstående vil indeholde et underafsnit for hvert af de indgående
programmer, hvori det kort beskrives hvad de enkelte program udfører.
Til en nøjere beskrivelse af, hvordan programmerne kaldes o.l.
henvises
til manualen over 'inkrementalsave'systemet, der findes vedlagt som
bilag 1.
$nl$$nl$$nl$
_«bs»3_«bs»._«bs»1_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»I_«bs»N_«bs»C_«bs»L_«bs»O_«bs»A_«bs»D_«bs».
$nl$$np$
Dette program er en modificering af standardprogrammet LOAD fra RC.
Det er modificeret så det har en ekstra facilitet, når filer skal
genetableres på plade- eller tromlelageret. Denne ekstra facilitet
går ud på, at man kan nøjes med at genetablere de filer fra et magnetbånd, der
ikke allerede findes på baggrundslageret. Dette bliver brugt ved
f.eks. en systemfejl, hvor kun en del af en plade er slettet, og man
ønsker at genetablere de filer som er forsvundet fra pladen.
$nl$$nl$$nl$
_«bs»3_«bs»._«bs»2_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»I_«bs»N_«bs»C_«bs»S_«bs»A_«bs»V_«bs»E_«bs».
$nl$$np$
Som nævnt ovenfor er INCSAVE det program, der foretager selve kopieringen
af filer fra plade- og tromlelagre. Programmet virker på følgende måde:
$nl$$np$
Det første, der undersøges, er hvilken form for kopiering, som skal foretages.
Dette er specificeret ved kaldet af programmet. Der er to former for
kopieringer:
$nl$
$nl$
1.Totalkopiering. Her kopieres samtlige filer, der findes på plade- og
tromlelageret.
$nl$$nl$
2.Dagligkopiering. Her kopieres de filer, der er ændret siden sidste kopiering
og derudover kopieres de filer, som fandtes på forrige dagligkopiering.
En begrundelse for, at en dagligkopiering foregår på den ovenfor beskrevne
måde, findes i afsnit 4.
$nl$$np$
Filerne, som skal kopieres, findes og udskrives i hjælpekataloget
TEMPCAT.
Dette hjælpekatalog (TEMPCAT) bliver sorteret i alfabetisk orden.
Sorteringen foregår ved et standardprogram fra RC (mdsortproc).
Efter sorteringen kopieres filerne i alfabetisk orden op på
et magnetbånd.
$nl$$np$
Magnetbånd er beskrevet i en anden hjælpefil til programmet (MTPOOL).
Denne fil indeholder en beskrivelse af samtlige bånd, som benyttes til
systemet. Programmet finder i denne fil (MTPOOL) det ældste bånd, der er
brugt til en tilsvarende kopiering.
Dette anvendes til kopieringen. Eventuelt skal der benyttes
mere end et magnetbånd, og her finder programmet på
ækvivalent måde båndene.
$nl$$np$
Efter at selve kopieringen af filerne fra plade- og tromlelageret til
bånd er færdigt, bliver et tredie hjælpekatalog (SAVECAT) ændret.
Kataloget indeholder information om filer, der findes på
bånd.
$nl$$np$
Efter at information om samtlige filer, der blev kopieret, er
indsat i SAVECAT vil de tre hjælpefiler TEMPCAT, MTPOOL og SAVECAT
blive overført til bånd.
$nl$$nl$
$nl$
_«bs»3_«bs»._«bs»3_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»I_«bs»N_«bs»I_«bs»T_«bs»S_«bs»A_«bs»V_«bs»E_«bs»C_«bs»A_«bs»T_«bs».
$nl$$np$
Programmet anvendes til at initialisere hjælpefilen SAVECAT.
Det er nødvendigt at initialisere den, idet programmet INCSAVE forudsætter
et helt specielt format.
Programmet kaldes normalt kun ved installeringen af systemet.
$nl$$nl$$nl$
_«bs»3_«bs»._«bs»4_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»s_«bs»l_«bs»e__«bs»a_«bs»f__«bs»I_«bs»N_«bs»I_«bs»T_«bs»M_«bs»T_«bs»P_«bs»O_«bs»O_«bs»L_«bs».
$nl$$np$
Dette program anvendes til at initialisere filen MTPOOL. Denne fil indeholder
en beskrivelse for samtlige magnetbånd,
der benyttes af systemet. Ved initialiseringen er
det nødvendigt at angive,
hvormange bånd der skal benyttes til de to former for kopiering.
$nl$$nl$$nl$
_«bs»3_«bs»._«bs»5_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»I_«bs»N_«bs»I_«bs»T_«bs»T_«bs»E_«bs»M_«bs»P_«bs»C_«bs»A_«bs»T_«bs».

$nl$$np$
Dette program anvendes til at initialisere TEMPCAT. Dette er i princippet kun
nødvendigt, når systemet installeres og man ikke starter med en totalkopiering.
$nl$$nl$$nl$
_«bs»3_«bs»._«bs»6_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»L_«bs»I_«bs»S_«bs»T_«bs»M_«bs»T_«bs»P_«bs»O_«bs»O_«bs»L_«bs».
$nl$$np$
Programmet benyttes til at udskrive informationen i MTPOOL'en.
At skulle bruge programmet kan skyldes, at man f.eks. ønsker at
indsætte flere bånd i MTPOOL'en.
$nl$$nl$$nl$
_«bs»3_«bs»._«bs»7_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»L_«bs»O_«bs»O_«bs»K_«bs»S_«bs»A_«bs»V_«bs»E_«bs».
$nl$$np$
Dette program benyttes til at slå op i filen SAVECAT.
Dvs. det anvendes til at finde de magnetbånd, hvorpå en given fil
findes. Programmet kan ligeledes benyttes til at give en fortegnelse
over samtlige en brugers filer, med angivelse
af på hvilke bånd de enkelte filer
findes.
$nl$$nl$$nl$
_«bs»3_«bs»._«bs»8_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»U_«bs»P_«bs»D_«bs»M_«bs»T_«bs»P_«bs»O_«bs»O_«bs»L_«bs».
$nl$$np$
Programmet anvendes til at opdatere data i MTPOOL'en. Dette
er nødvendigt, hvis et bånd bliver defekt og man vil fjerne
båndbeskrivelsen fra MTPOOL'en.
Derudover kan programmet anvendes til at indsætte nye bånd i MTPOOL'en.
$nl$$nl$$nl$
$ps0$
_«bs»4_«bs»._«bs»F_«bs»O_«bs»R_«bs»S_«bs»K_«bs»E_«bs»L_«bs»L_«bs»I_«bs»G_«bs»E__«bs»K_«bs»O_«bs»P_«bs»I_«bs»E_«bs»R_«bs»I_«bs»N_«bs»G_«bs»S_«bs»M_«bs»E_«bs»T_«bs»O_«bs»D_«bs»E_«bs»R_«bs».
$nl$
$nl$
$np$
Dette afsnit vil indeholde en beskrivelse af, hvilke metoder
hvorpå baggrundslageret kan kopieres til magnetbånd for at skabe
sikkerhed for, at
filer kan genetableres ved såvel brugerfejl som systemfejl.
$nl$$np$
Disse koperingsmetoder afhænger af, hvor store datamængder
der findes ved den instellation, hvor systemet benyttes. Til vurdering
af metodernes brugbarhed benyttes følgende kriterier:
$nl$$nl$
1.En fil skal findes sålænge som muligt på et magnetbånd.
$nl$$nl$
2.Ved genetablering af filer f.eks. ved en system fejl skal
så få magnetbånd som muligt benyttes til genetablering.
$nl$$nl$
3.Så få bånd som muligt skal benyttes, når en kopiering foretages.
$nl$$nl$
$np$
Nedenstående kopieringsstrategier, er dem, der har været
overvejet i forbindelse med konstruktionen af systemet.
For at anskueliggøre, hvormange bånd, som skal benyttes ved de enkelte
metoder, er der her angivet antallet af bånd, der skal bruges henholdsvis på
H.C.Ø. og på Geodætisk institut.
$nl$$nl$
1.Med fast tidsmellemrum at fortage en totalkopiering af baggrundslageret.
$nl$$np$
Denne strategi blev hurtigt forkastet, idet den ikke opfylder kriteriet
om, at så få bånd som muligt skal benyttes. Ved store datamængder skal
urimeligt mange magnetbånd benyttes til systemet.
Hvis en fil skal findes på magnetbånd i f.eks. i 2 måneder, skal der på
H.C.Ø. benyttes 80 bånd. Ved denne beregnning er forudsat, at en totalkopiering
foretages på 20 dage ud af en måneds ca. 30 dage.
At det netop er 20 ud af 30 dage, skyldes at der ca. er 20 arbejdsdage i en
måned.
En totalkopiering på H.C.Ø. fylder 2 bånd.
På Geodætisk Institut
skal der anvendes omkring 320 bånd, idet en totalkopiering her fylder
omkring 8 bånd. En anden grund til, at en sådan kopieringsstrategi er
urimelig er, at det tidsmæssig tager ret lang tid at foretage en totalkopiering
på 8 bånd.(Det vil tage ca.45 min)
$nl$$nl$
2.Med et fast tidsinterval at kopiere hele baggrundslageret og
derudover med et fast kortere tidsinterval at kopiere de filer, der
ændres.
$nl$$np$
Denne strategi kan her beskrives yderligere ved følgende:
Hver 14.dag foretages en total kopiering af pladelageret. Efter en
totalkopiering foretages hver dag en kopiering af de filer, der er
ændret siden sidste kopiering. Dvs. efter en totalkopiering foretages
næste dag kun en kopiering af de filer, der er ændret siden totalkopieringen.
$nl$$np$
Ved denne strategi kræves naturligvis,
at det er muligt at se,
om en fil
er ændret
siden en bestemt dato.
Antallet af bånd, der skal benyttes er på H.C.Ø ( stadig under den forudsætning
at en fil skal findes på bånd i 2 måneder) er 16
bånd. Her er 4 totalkopieringer a 2 bånd, hvilket giver 8 bånd og 8 daglige
kopieringer a 1 bånd ialt 16 bånd.
På Geodætisk institut
vil antallet være 48 bånd.
Her er 4 totalkopieringer a 8 bånd ( ialt 32) plus 8 dagligekopieringer
a 2 bånd (ialt 16), hvilket ialt vil betyde 48 bånd.
$nl$$np$
En ret stor ulempe ved metoden er, at hvis en bruger opretter og sletter
en fil mellem to kopieringer vil
filen aldrig komme med på et totalkopieringsbånd.
En anden ulempe er,
at når f.eks. en hel plade skal genetableres, skal et ret stor
antal bånd benyttes. For det første skal sidste totalkopieringsbånd
benyttes og derudover skal samtlige dagligkopieringsbånd, der er
brugt siden sidste totalkopiering, anvendes til genetableringen.
$nl$
$nl$
3.Med et fast mellemrum at kopiere hele baggrundslageret og
med et fast mindre tidsinterval at kopiere de foretagne ændringer,
men derudover også kopiere de filer, der findes på forrige kopierings
bånd, med mindre dette bånd er et totalkopieringsbånd.
$nl$$np$
Denne kopieringstrategi giver den største
form for sikkerhed. Hvis man opretter en fil mellem to totalkoperinger
vil denne fil ved de 2 før nævnte kopieringer kun komme med på en
total kopiering, hvis filen ikke er slettet inden da.
$nl$$np$
Denne kopieringsstrategi bevirker derfor, at hvis en fil er kommet
op på et dagligkopieringsbånd, vil filen overleve i systemet sålænge,
som det overhovedet er muligt. Dette skyldes, at filen vil komme med op på
et totalkopieringsbånd, og disse gemmes særdeles længe.
De vil normalt blive gemt i op til et halvt år.
$nl$$np$
En anden fordel ved denne kopieringsform er, at når en hel plade eller
tromle skal genetableres efter en system fejl vil antallet af bånd, der
skal monteres være det mindste antal i forhold til de andre nævnte metoder.
Det største antal bånd, der kan tænkes, at man skal "loade" er de bånd,
der er benyttet til sidste totalkopiering og dem, som er benyttet til
sidste daglige kopiering. Ved dette vil indholdet af pladen eller tromlen
være det nyeste, som kan opnås ved systemet.
$nl$$np$
Ved metoden vil antallet af bånd, der skal benyttes på H.C.Ø., være 18 bånd. Dette beregnes
ved at der foretages en totalkopiering hver 14 dag. Denne fylder 2 bånd, og
det vil sige at der på 2 måneder skal benyttes 4 totalkopieringer, hvilket
fylder 8 bånd. Udover disse skal benyttes 10 bånd til dagligkopiering, dvs.
ialt 18 bånd.
$nl$$np$
På geodætisk institut vil antallet af bånd, som skal benyttes til totalkopiering
være 4 gange 8 altså 32 bånd. Til daglige kopieringer skal maksimalt benyttes
4 bånd, hvilket giver 40 bånd, og dermed vil metoden ialt skulle benytte
72 bånd.

$nl$$np$
Af de foreslåede 3 strategier har jeg valgt, at implementere strategi 3 og
lade denne strategi være standard. Dette skyldes bl.a. at man er kendte med strategien på
H.C.Ørsteds Institutet og de datamængder man har her, bevirker at strategien er
nem at benytte.
$nl$$np$
For at illustrere, hvorlænge filer overlever ved 'inkrementalsave'systemet, kan
nævnes at man på H.C.Ørsteds Institutet har planlagt at benytte ca. 48 magnetbånd
til systemet.
Dette bevirker, at af disse 48 vil 10 blive brugt til daglige kopierings
bånd, og således vil man have 38 bånd til totalkopiering. Idet en total
kopiering benytter ca. 2 bånd vil en fil kunne overleve i 19 uger, hvilket
må siges at være tilfredstillende i forhold til det begrænsede antal bånd
der benyttes.
$nl$$np$
På Geodætisk Institut bliver kopieringsstrategi 2 benyttet på følgende
måde:
$nl$$nl$
Et fast antal bånd benyttes til dagligkopieringer. Dette er ca. 40 bånd.
De daglige kopieringer fylder ca. 2 bånd og der foretages en kopiering
hver dag og hver 14 dag foretages en totalkopiering. Dvs. At der skal
benyttes omkring 20 daglige bånd mellem to totalkopieringer. Da man
på Geodætisk Institut ikke overfører filer fra forrige
daglige kopiering, forsøges dette afhjulpet ved at gemme dagligkopieringsbåndene
så længe som muligt. Man benytter således 40 bånd til dagligkopiering,
og efter at de 20 første er brugt foretages en totalkopiering. Efter
denne totalkopiering benyttes så de næste 20 dagligebånd. Ved denne metode
vil en fil overleve ca 1 måned på daglige bånd.
$nl$$np$
Antallet af totalkopieringsbånd svarer til at en fil skal kunne overleve ca.
et halvt år. Da en totalkopiering benytter 8 bånd og denne foretages
ca 12 gange på et halvt år.(hver 14 dag). Ialt benyttes således omkring
96(total kopieringsbånd) + 40 (dagligkopieringsbånd) = 136 bånd.
$ps0$
_«bs»5_«bs»._«bs»O_«bs»R_«bs»G_«bs»A_«bs»N_«bs»I_«bs»S_«bs»E_«bs»R_«bs»I_«bs»N_«bs»G_«bs»S_«bs»M_«bs»Å_«bs»D_«bs»E_«bs»R__«bs»A_«bs»F__«bs»K_«bs»A_«bs»T_«bs»A_«bs»L_«bs»O_«bs»G_«bs»E_«bs»T_«bs».
$nl$$np$
Dette afsnit vil indeholde en diskusion af, hvordan kataloget over
kopierede filer kan se ud. Et
krav til udseendet er, at størrelsen minimeres i forhold til antallet af
indgange i kataloget.
Et andet væsentlig krav til kataloget er, at opslag skal kunne
foretages rimeligt hurtigt.
$nl$$np$
For at beskrive hvilke organiseringsmåder man
kan benytte til kataloget er det ligeledes nødvendigt først at
beskrive, hvilken information, kataloget som minimun skal indeholde.
$nl$$nl$$nl$
_«bs»5_«bs»._«bs»1_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»i_«bs»n_«bs»d_«bs»h_«bs»o_«bs»l_«bs»d_«bs»e_«bs»t__«bs»a_«bs»f__«bs»k_«bs»a_«bs»t_«bs»a_«bs»l_«bs»o_«bs»g_«bs»e_«bs»t_«bs».
$nl$$np$
For det første skal kataloget indeholde den information der
er nødvendig for at kunne identificere en fil. Disse ting er
følgende:
$nl$$nl$
( Det beskrives ikke, hvad
f.eks. nedre base står for, idet dette forstås af en der har
benyttet en RC8000 og systemet er udviklet til en sådan.)
$nl$$nl$
1.ord permkey + (område eller indgang)
$nl$$nl$
2.ord nedre base
$nl$$nl$
3.ord øvre base
$nl$$nl$
4.ord - 7.ord navnet på filen.
$nl$$nl$
Dette er den mindste information, der skal være for hver fil,
der kopieres af systemet. Derudover skal hver enkelt filindgang
i kataloget indeholde data om, på hvilke bånd filen findes.
$nl$$np$
I forbindelse med informationen om på hvilke bånd filen findes, er det
efterstræbt at få denne information til at fylde så lidt som muligt.
Dette er gjort ved, at hvis en fil findes på et bånd, indikeres dette ved,
at en bit er sat i en bittabel. Dette bevirker, at hvis man som på
H.C.Ørsteds Institutet benytter 48 magnetbånd til systemet vil denne
bittabel
indeholde 2 ord, idet et ord på en RC8000 kan indeholde
24 bit.
$nl$$np$
Da der til hele 'inkrementalsave'systemet ikke er udviklet et egentlig "load" program,
her benyttes RC's standard program "load", er al nødvendig information medtaget
i disse ord. Det ville måske være praktisk, hvis man ikke benyttede en bittabel
men f.eks. et ord for hvert bånd.
I dette ord kunne første halvord benyttes til båndnummeret og andet
halvord til positionen på båndet for, der hvor filen eksisterer.
Dette skulle så indbygges i et "load"-program,
idet man herved kan spare tid ved genetablering af enkelte
filer.
$nl$$np$
At der kan spares tid skyldes, at en magnetbåndstation normalt ikke
er særlig hurtig. Hvis man f.eks. skal genetablere en fil som findes på den sidste
trediedel af et magnetbånd, kan den tid det tager at "loade" filen godt være op
mod 15-20 minutter. Dette skyldes at "load"-programmet skal gennemløbe hele
magnetbåndet og læse hver blok for at finde den ønskede fil.
$nl$$np$
Hvis man, når filen skal genetableres, kender det sted på båndet,
hvor filen findes, kan man nøjes med at positionere på magnetbåndstationen, og
dette vil spare tid.
$nl$$nl$$nl$
_«bs»5_«bs»._«bs»2_«bs»._«bs»O_«bs»v_«bs»e_«bs»r_«bs»v_«bs»e_«bs»j_«bs»e_«bs»l_«bs»s_«bs»e_«bs»r__«bs»o_«bs»m__«bs»k_«bs»a_«bs»t_«bs»a_«bs»l_«bs»o_«bs»g_«bs»f_«bs»o_«bs»r_«bs»m_«bs».
$nl$
$np$
Dette afsnit vil beskrive, hvilke former for katalogorganisation, der
har været overvejet.
Der er i dette afsnit beskrevet to former for organisation af
kataloget, og disse er en indekssekventiel ordning og et hashkatalog.
$nl$$nl$
_«bs»1_«bs»._«bs»E_«bs»n__«bs»f_«bs»o_«bs»r_«bs»m__«bs»f_«bs»o_«bs»r__«bs»i_«bs»n_«bs»d_«bs»e_«bs»k_«bs»s_«bs»s_«bs»e_«bs»k_«bs»v_«bs»e_«bs»n_«bs»t_«bs»i_«bs»e_«bs»l__«bs»o_«bs»r_«bs»g_«bs»a_«bs»n_«bs»i_«bs»s_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs».
$nl$$nl$
Kataloget over kopierede filer kan ordnes indekssekventielt efter de første
bogstaver i filens navn. Der bliver ikke problemer med først at skulle sorterer
filerne i alfabetisk orden, idet når filerne kopieres op på bånd, vil
disse allerede være ordnet. Den helt præcise organisering af kataloget
ved hjælp af en indekssekventiel fil kunne nu være på følgende måde:
$nl$$nl$
Hvis en fil starter med a skulle dette angive, at man skal søge filen
i de segmenter, hvor filerne med a findes. På et segment der adresseres
ved a angives, hvor filerne med aa,ab,...,aå findes. Nedenstående figur
illustrerer, hvordan dette tænkes anvendt.
$ps0$
$sj$
Filnavnet eksempelvis ALGOL

ALGOL
!
!
------------------------------------------
! !
! Adresserne på filer begyndende med a !
! !
-------------------------------------------
! ! !
! ! !
! ! !
------------- ------------- -------------
! ! ! ! ! !
!Tabel med ! !Tabel med ! . . . !Tabel med !
! aa ! ! ab ! ! aå !
! ! ! ! ! !
------------- ------------- -------------
! ! . . . ! ! . . . ! ! ...
! ! ! ! ! !
! ! ! ! ! !
---------------------------------------------------
! !
! !
! Record for hver fil !
! !
! !
---------------------------------------------------

$rj$
$nl$$np$
Denne organiseringsform med to indeks i en indekssekventiel fil vil opfylde
de krav, som stilles til kataloget. Det vil være meget hurtigt at
slå op i kataloget. Derudover vil det ikke være vanskeligt at indsætte
filer i kataloget. Dette skyldes, at filerne allerede er ordnet i alfabetisk
orden,
når de kopieres op på bånd.
$nl$$np$
Efter at en anden organisationsform var blevet valgt, blev jeg opmærksom på,
at der fra RC's side leveres et standardsystem til indekssekventielle filer.
Dette vil formentlig kunne benyttes med fordel.
$nl$$np$
Der vil imidlertid også være en del ulemper ved en indekssekventiel
organiseringsform. Når en kopiering af filer foretages ved hjælp af
INCSAVE skal en del filer indsættes og fjernes fra kataloget. Filer,
der kopieres op på bånd for første gang ved systemet, skal indsættes.
Filer, der findes på det bånd, der benyttes til den forestående kopiering,
vil blive fjernet fra dette bånd, idet det overskrives med nye filer.
Dette kan bevirke, at filen skal fjernes fra kataloget.
$nl$$np$
Denne opdatering af kataloget kan være ret vanskelig, idet hele kataloget
skal omorganiseres, hvis der ikke er plads i kataloget til at indsætte nye
filer. Ved initialiseringen af kataloget vil det sikkert også være vanskeligt
at angive, hvor store indekstabellerne skal være. (Det er ike på forhånd
muligt at sige, hvormange filer der begynder med forskellige bogstaver.)
$ps0$
_«bs»2_«bs»._«bs»O_«bs»r_«bs»g_«bs»a_«bs»n_«bs»i_«bs»s_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»v_«bs»e_«bs»d__«bs»e_«bs»t__«bs»h_«bs»a_«bs»s_«bs»h_«bs»k_«bs»a_«bs»t_«bs»a_«bs»l_«bs»o_«bs»g_«bs».
$nl$
Ved denne organiseringsform kan man ved en passende hashfunktion
indsætte filerne i kataloget svarende til den pågældende hashværdi.
Antallet af hashindgange skal ved denne organiseringsform være
bestemt af, hvormange filer der ialt gemmes af systemet. For
at hashtabellen skal være rimeligt organiseret, er det hensigtmæssigt
at se på, hvordan pladelageret er opbygget. En "disc" hørende til
en RC8000 er organiseret på en sådan måde, at den består af et antal
segmenter, hvor hvert segment indeholder 512 halvord. En hashindgang
skal så svare til et segment. Ved denne organiseringsform ville
man kunne have 25 filindgange på hver hashindgang,
idet hver filindgang fylder 20 halvord.
$nl$$np$
Ved at organisere kataloget som et hashkatalog vil det gå hurtigt at
slå op i kataloget. Derudover vil det være nemt at indsætte og fjerne filer.
$nl$$np$
Ulemperne ved denne organiseringsform er, at når et nyt bånd benyttes
skal bitten i bittabellen svarende til dette bånd fjernes fra samtlige
bånd i kataloget. Ved dette bliver man så nød til at gennemløbe hele
hashkataloget for at fjerne bitten.
Da det her bliver nødvendigt at gennemlæse hele hashkataloget er spørgsmålet
om det overhovedet er hurtigere at benytte denne organisationsform i forhold
til den før beskrevne.
Hvis man ved den indekssekvetentielle anvendte en god omordningsstrategi ved
omorganiseringen af kataloget ville dette måske være ligeså hurtigt og nemt.
$nl$$np$
En anden ulempe er, at det ved et hashkatalog er nødvendigt at
have hashværdien gemt for hver indgang i kataloget.
Denne hashværdi skal benyttes, når overløb forekommer
(se nedenstående). Derudover
er det svært, når man starter systemet at vide, hvorstort det
er nødvendigt at hashkataloget skal være. Man bliver derfor
nød til at lave en rutine, der kan omorganisere hashkataloget, når
fyldningsgraden bliver over en vis procent.
Det kan her nævnes, at ved dette system blev det valgt at benytte sig
af et hashkatalog, og nedenstående vil derfor indeholde en grundig beskrivelse
af, hvordan kataloget er organiseret.
$nl$$nl$

Nedenstående figur angiver, hvordan hashkataloget kommer til at se ud.
$ps0$
$sj$
segmno 0. --------------------------------
! filer der har hashværdi 0 !
! !
--------------------------------
! ledig plads !
! !
segmno 1. --------------------------------
! filer der har hashværdi 1 !
! !
--------------------------------
! ledig plads !
! !
--------------------------------
! !
! . !
! . !
! . !
! !
! !
segmno n. --------------------------------
! filer med hashværdi n !
! !
--------------------------------
! ledig plads !
! !
--------------------------------
$rj$
$nl$$np$
Hver filindgang indeholder udover den i afsnit 5.1. beskrevne information
en hashværdi. Dette benyttes ved overløb. En anden ting som kataloget
indeholder udover filindgange er, at det første ord for hver hashindgang
indeholder antallet af filindgange, der er hashes ind til denne indgang.
Dette er også til for at bedre at kunne klare overløb.
$nl$$np$
Når man vil slå op i kataloget gøres dette efter følgende principper:
En hashindgang har eksempelvis følgende udseende.
$ps0$$sj$
Hashindgang p --------------------
! antal filerecord.!
! på denne hashind-!
! gang !
--------------------
! hashværdi p !
! filrecord !
--------------------
! hashværdi q !
! filrecord !
--------------------
! hashværdi p !
! filrecord !
--------------------
! . !
! . !
! . !
--------------------
! evt. ledig plads !
! !
! !
! !
--------------------
$rj$$nl2$
En fil findes nu efter følgende princip:
$nl3$
$sj$
Beregnhashværdi for filen;
i:=1;
found:=false;
while not found and i<=antalrecords do
begin
læs filrecord;
if hashværdi <> filenshashværdi then
læs filrecord;
if filrecord == den søgte fil then found:=true;
i:=i+1
end;
$rj$$nl3$
$np$
Som konklusion på dette afsnit kan nævnes, at den sidste organisationsform
blev valgt. Dette skyldes, at de fordele der er ved at lave kataloget ved
et hashkatalog efter min mening var så store i forhold til en indekssekventiel
ordning. Endvidere findes der kataloger som f.eks. hovedkataloget, som er
organiseret ved et hashkatalog. Hashfunktionen som RC benytter er i øvrigt
også den jeg har valgt.
$nl$$np$
For at undgå problemer med størrelsen af kataloget, har jeg endvidere
konstrueret en rutine, der automatisk omorganiserer hashkataloget ved en
fyldningsgrad på 80 % eller derover.
$ps0$
_«bs»6_«bs»._«bs»A_«bs»N_«bs»D_«bs»R_«bs»E__«bs»D_«bs»E_«bs»S_«bs»S_«bs»I_«bs»G_«bs»N__«bs»M_«bs»Æ_«bs»S_«bs»S_«bs»I_«bs»G_«bs»E__«bs»O_«bs»V_«bs»E_«bs»R_«bs»V_«bs»E_«bs»J_«bs»E_«bs»L_«bs»S_«bs»E_«bs»R_«bs».
$nl$$np$
Dette afsnit vil beskrive de designmæssige overvejelser, der endnu ikke
har været diskuteret.
$nl$$np$
Udover det katalog over filer, som er beskrevet i forrige afsnit, findes
til systemet 2 andre hjælpefiler. Ved organisationen af disse har
der ikke været så store overvejelser om organiseringen.
Dette skyldes, at indholdet af filerne er fastlagt på forhånd, dvs.
at den information som filerne skal indeholde er fast, og man kan ikke
reducere på det. Da filerne ikke er særligt store vil det også være
urimeligt at gøre store overvejelser om, hvordan de skal organiseres.
$nl$$np$
Den ene fil benyttes til at administrerer de magnetiske bånd, der
benyttes af systemet. Den kaldes i systemet MTPOOL. Indholdet
er følgende:
$nl$$nl$
1.ord båndnr
$nl$
$nl$
2.ord-5.ord båndnavn
$nl$$nl$
6.ord angivelse af om båndet benyttes til totalkopiering eller
dagligkopiering. Derudover angives om det er det sidst benyttede
bånd.
$nl$$nl$
7.ord Dato for sidste benyttelse.
$nl$$nl$$nl$$np$
Hele MTPOOL'en er nu organiseret således at for hvert bånd der
benyttes af systemet findes en record med det ovenstående indhold.
Det første ord i MTPOOL'en indeholder så antallet af bånd i MTPOOL'en.
$nl$$np$
Den eneste ting som måske kan anses for ikke at være nødvendig
ved denne information, er den ekstra information
der er i ord nr.6. Her kunne angivelsen om sidste benyttelse være
udgået, idet dette også angives ved datoen. Grunden til at informationen
er medtaget vil komme i erfaringer med indkøringen af systemet.(afsnit 7)
$nl$$np$
Det vil nok være på sin plads her at angive, hvornår og hvordan
MTPOOL'en benyttes af systemet.
For det første benyttes MTPOOL'en til at finde de bånd der skal benyttes
ved en kopiering. Når selve kopieringsporgrammet kaldes sker kort
følgende:
$nl$$np$
Det undersøges om kopieringen er en totalkopiering eller om det er en
dagligkopiering. I begge tilfælde findes i MTPOOL'en hvilke bånd der skal
monteres og der udskrives en meddelse på konsolen til operatøren om
hvilke bånd han skal montere. Normalt vil dette være to bånd, dog
vil det, hvis der er tale om en dagligkopiering lige efter en totalkopiering
kun være tale om et bånd.
$nl$$np$
Udover at administrere hvilke bånd der skal benyttes til kopieringer benyttes
MTPOOL'en, når en bruger ønsker at finde de bånd, hvorpå en af hans filer findes.
Dette gøres ved at kalde et program der kan slå op, i det hashkatalog der
er beskrevet i afsnit 4. Her vil findes en eller flere bit svarende til
pågældende bånd som filen findes på. De bit, der er angivet i bittabellen,
svarer til nummeret på det magnetbånd, hvorpå filen findes.
$nl$$nl$$np$
Den anden fil der benyttes af systemet er en fil der indeholder information
om hvilke filer, der findes på et bånd. Når en almindelig dagligkopiering
af indholdet af plade- og tromlelageret foretages, findes de filer, der skal
op på bånd. Disse filer skrives ned i området TEMPCAT. Hvis en overføring
fra forrige dagligbånd skal foretages vil det TEMPCAT, der er konstrueret
idag blive flettet sammen med det TEMPCAT der er oprettet igår.
Når kopieringen er færdig vil TEMPCAT således indeholde alle de filer der
findes på pågældende benyttede bånd.
$nl$$np$
Dette område TEMPCAT indeholder den normale information der findes
i kataloget for filer svarende til MAINCAT, dvs 17 ord.
Hvad disse ord indeholder vil jeg ikke nærmere komme ind på i denne opgave,
idet det ikke er relevant i forbindelse med opgaven.
$nl$$np$
Når samtlige filer er kopieret op på magnetbånd svarende til den form for
kopiering der foretages, vil de tre systemfiler SAVECAT,MTPOOL og TEMPCAT
blive overført sidst på båndet. Det kan her anføres, at det ville være rimeligt
først på et magnetbånd at skrive, hvilke filer båndet indeholder. Ved dette kunne
operatøren "loade" dette område, og derved se om filerne findes på pågældende
bånd.
$nl$$np$
Dette er ikke gjort af følgende grund. Da en kopiering normalt foretages mens
andre brugere benytter maskinen vil man ikke kunne skrive et nøjagtigt
katalog over, hvad et bånd indeholder, før man har skrevet hele båndet.
Dette skyldes følgende:
$nl$$nl$
Hvis der f.eks. findes en fil ved navn "vkpascal" og denne fil er ændret
siden sidste kopiering, hvilket betyder at den skal op på båndet. Ved overførsel
til båndet viser det sig, at når filen skal overføres, er en bruger ved at
skrive i pågældende fil og 'inkrementalsave'systemet kan derfor ikke læse
fra pågældende fil, hvilket vil sige, at filen ikke kan kopieres på
bånd.
Til dette problem kunne man anføre, at hvis dette skete kunne inkrementalsystemet
vente til den pågældende bruger var færdig med at skrive på pågældende fil
og derefter kopierer filen.
Denne løsning ville nok være hensigtmæssig på en instellation, som
f.eks. det regionale edb-center, da brugere normalt ikke skriver på
deres filer særlig længe af gangen.
Imidlertid vil dette være mindre hensigtsmæssig på H.C.Ørsteds institutet.
Dette skyldes at man her typisk foretager langvarige beregninger der kan vare
flere døgn.
$nl$$np$
Hvis man i stedet sørgede for at være sikker på at
læse filen og derved reserverede filen kan
man risikere, at under læsningen af filen skal brugerprogrammet
bruge pågældende fil. Ved dette vil brugerprogrammet
afslutte med at udskrive en fejludskift.
Dette ville være ret uheldigt hvis det f.eks. havde brugt 23 timer og kun manglede
nogle få timer.
$nl$$np$
Dette problem undgås ved ikke at kopiere en sådan fil, og derved
kan kataloget over, hvad båndet indeholder først skrives sidst på båndet.
For en ukyndig ville man måske indvende at dette tilfælde næsten aldrig
vil forekomme.
Dette er desværre ikke rigtigt, idet f.eks.på Geodætisk Institut,
hvor en dagligkopiering indeholder ca.250 filer sker dette for omkring
30 filer. Altså problemet kommer særdeles hyppigt.
$ps0$
_«bs»7_«bs»._«bs»I_«bs»N_«bs»D_«bs»K_«bs»Ø_«bs»R_«bs»I_«bs»N_«bs»G_«bs»S_«bs»E_«bs»R_«bs»F_«bs»A_«bs»R_«bs»I_«bs»N_«bs»G_«bs»E_«bs»R_«bs».
$nl$$np$
Nedenstående afsnit vil beskrive, hvilke erfaringer,
der er opnået, i forbindelse med indkøringen af systemet. Det
vil således fremgå, hvilke designmæssige overvejelser, der var
rimelige, og hvilke der var mindre hensigtsmæssige.
$nl$$nl$
_«bs»7_«bs»._«bs»1_«bs»._«bs»K_«bs»r_«bs»a_«bs»v__«bs»o_«bs»m__«bs»k_«bs»o_«bs»r_«bs»r_«bs»e_«bs»k_«bs»t__«bs»d_«bs»a_«bs»t_«bs»o_«bs».
$nl$$np$
Hele det udviklede system bygger på, at den dato, der findes i maskinen,
er korrekt. Ved en forkert dato vil følgende ske. For det første
vil det ikke kunne lade sig gøre, at kopiere de filer der er ændret siden
en speciel dato. Dette har i det mindste ikke den rigtige betydning, hvis
datoen ikke er korrekt.
$nl$$np$
Udover at de filer der kopieres kan være de forkerte, forekommer en anden ret
stor uhengsigtmæssighed. Da systemet selv holder rede på,
hvilke magnetbånd, som skal benyttes til de forskellige kopieringer ved
at finde det ældste bånd der er benyttet til en kopiering, vil der
opstå ejendommelige situationer, hvis datoen ikke er korrekt.
Dette skyldes, at båndene derved ikke bliver benyttet i en cyklisk
rækkefølge som det er meningen.
Derudover vil overføringsbåndet, der benyttes, være det forkerte.
$nl$$np$
Man kan indvende til konstruktionen af et sikkerhedssystem som
dette, at man formentlig altid vil have den korrekte dato. Imidlertid har
det vist sig ikke at være rigtigt. Ved årsskifte og månedskifte
vil man være udsat for, at en operatør om morgenen
indsætter en forkert dato i systemet. Når dette er sket, vil der helt
automatisk opstå problemer i forbindelse med anvendelsen af
systemet.
$nl$$np$
Om disse betragtninger kunne påpege, om det ikke var muligt at
systemet foretager en undersøgelse af om datoen
er korrekt. Dette er imidlertid ikke altid muligt. Det er muligt
at undersøge om den dato som maskinen er initialiseret med
er mindre end den største dato, der er benyttet i systemet. Ved dette
test kan man undgå en hel del problemer, men alle problemer
vil ikke undgås, idet en for stor dato ikke ville kontroleres.
Dette skyldes, at maskinen ikke kører hele døgnet og blive slukket om
natten. Hvis man f.eks. idag har den 12.2.81 og maskinen næste dag
initialiseres den 13.2.82 vil dette ikke kunne testes om dette er korrekt.
Ved benyttelse af denne dato vil systemet opføre sig pænt denne dag, men
næste dag vil der opstå problemer, hvis datoen igen bliver initialiseret
korrekt. I dette tilfælde, hvis man konstruerede det ovenfor beskrevne test,
vil man konstatere, at datoen
er forkert, idet den
er mindre end datoen fra igår.
$nl$$np$
Spørgsmålet, der rejser sig her, er så, om man ønsker at den kopiering
der blev fortaget igår skal kasseres og man idag foretager den korrekte,
eller om man vil lade kopieringen være og idag foretage en ny kopiering
idet man blot retter datoen fra igår, i de til systemet hørende hjælpefiler.
Begge metoder er efter min mening ikke gode.
$nl$$np$
Det er derfor besluttet i MTPOOL'en at indikere, hvilket bånd
der er det sidst benyttede. En kopiering vil foretages, sådan at
filer ændret siden datoen svarende til dette bånd vil blive kopieret.
Hvis denne dato er for stor så ingen filer skal kopieres, vil en operatør
manuelt kunne ændre pågældende dato ved et kald af UPDMTPOOL.
$nl$$nl$
_«bs»7_«bs»._«bs»2_«bs»._«bs»F_«bs»o_«bs»r_«bs»s_«bs»k_«bs»e_«bs»l_«bs»l_«bs»i_«bs»g_«bs»e__«bs»m_«bs»a_«bs»g_«bs»n_«bs»e_«bs»t_«bs»b_«bs»å_«bs»n_«bs»d_«bs»s_«bs»f_«bs»o_«bs»r_«bs»m_«bs»a_«bs»t_«bs»e_«bs»r_«bs».
$nl$$np$
Den i dette afsnit beskrevne indkøringserfaring er en,
det ville være vanskeligt at forudsætte ved udviklingen af systemet.
$nl$$np$
Den går ud på følgende: Ved konstruktionen af systemet var det en forudsætning,
at programmet der skulle anvendes til at genetabere filer fra magnetbånd
skulle være RC's standardprogram LOAD. Dette program forudsætter naturligvis
en specielt format af magnetbåndet. Imidlertid findes ved anvendelsen af
magnet,bånd noget der kaldes blokstørrelse. Denne blokstørrelse, som har
forbindelse med hvor tæt filerne pakkes på magnetbåndet, er normalt
fast defineret, når programmet kaldes. Den maksimale blokstørrelse, der
kan anvendes, er ligeledes afhængig af den hard-ware som anvendes ved
den pågældende installation. På H.C.Ø er det muligt maksimalt
at have en blokstørrelse på 8 segmenter. Dette betyder, at båndet fysisk
opdeles i blokke, som maksimalt kan indeholde 8 segmenter.
$nl$$np$
Ved den kopieringsstrategi som er forudsætningen for dette system, kan
det forekomme at filer skal overføres fra et magnetbånd til et andet.
Ved konstruktionen af systemet forudsattes at hvis dette forekom
ville det være nødvendigt at have en fast blokstørrelse på sådan to bånd,
hvor en overførsel skulle ske.
$nl$$np$
Dette har vist sig mindre hensigtsmæssigt.
På H.C.Ø. var det sådan, at da systemet blev indført, kunne den
hard-ware, der benyttedes, kun klare en blokstørrelse på 7 segmenter pr
blok. Imidlertid viste det sig muligt at udvide blokstørrelsen til 8
segmenter. Derefter kunne kopieringsprogrammet, der
anvendes (INCSAVE) naturligvis ikke overføre fra bånd med en blokstørrelse
på 7 segmenter til en blokstørrelse på 8 segmenter. Dette bevirkede, at
under indkøringsfasen var det faktisk nødvendigt at ændre de
procedurer, der kopierede filer op på bånd særdeles radikalt.
$nl$$np$
Dette problem er medtaget her, idet det viser, at selv ved et grundigt
forstudium af design kan væsentlige ting blive udeladt.
$nl$$nl$
_«bs»7_«bs»._«bs»3_«bs»._«bs»P_«bs»r_«bs»o_«bs»b_«bs»l_«bs»e_«bs»m_«bs»e_«bs»r__«bs»p_«bs»å__«bs»G_«bs»e_«bs»o_«bs»d_«bs»æ_«bs»t_«bs»i_«bs»s_«bs»k__«bs»I_«bs»n_«bs»s_«bs»t_«bs»i_«bs»t_«bs»u_«bs»t_«bs».
$nl$$np$
Da systemet blev konstrueret, var det med kendskab til de datamængder
der findes på H.C.Ø. Imidlertid er de datamængder der findes på Geodætisk
Institut væsentlig meget større. Dette bevirkede, at en del af
systemet var mindre hensigtmæssigt, da det skulle installeres der.
Dette viser, at selv med samme maskine RC8000 er det alligevel ret vanskeligt
at flytte programmer fra et anlæg til et andet. Det nedenstående afsnit vil
uddybe dette.
$nl$$np$
På H.C.Ø er antallet af filer ikke større end at en totalkopiering af
samtlige filer fra plade- og tromlelagre maksimalt vil fylde 2 bånd.
Den samme koperingsform vil på Geodæstisk Institut fylde minimalt 8 bånd.
Dette skyldes,
at man på Geodætisk Institut har få filer, der indeholder
særdeles mange data.
$nl$$np$
Da man på Geodætisk Institut har et lille antal filer, men disse filer
fylder særdeles meget, har det bevirket, at den til mit system valgte
kopieringsstrategi ikke er hensigtsmæssig at gennemføre der.
Dette skyldes, at ved dagligkopiering med overførsel af filer vil der
skulle benyttes for mange bånd og det vil simpelthen give et for stort
arbejdspres på operatører.
$nl$$np$
Det ovenståendede kan uddybes her ved følgende. Hvis en totalkopiering
foretages en fredag, vil den daglige kopiering der foretages mandag
fylde omkring 2 bånd. Om tirsdagen vil en dagligkopiering
formentlig fylde 3 bånd. Det vil sige at operatøren skal montere 5 bånd.
Både de bånd fra om mandagen og dem til om tirsdagen skal benyttes. Antallet
af bånd en dagligkopiering behøver vil således forøges støt op til omkring
7 til 8 bånd dagen inden der foretages en totalkopiering. Ved denne kopiering
vil således skulle anvendes omkring 14-15 bånd.
$nl$$np$
Ved Geodætisk Institut vil man således ikke overføre filer fra forrige kopiering
men kun kopiere de filer der ændres. Dette kan gøres ved et specielt kald
af programmet. En parameter std skal sættes til sand. Imidlertid er de
ulemper, der er beskrevet i afsnit 4 under kopieringsstrategi 2 tilstede,
men risikoen for at man er meget uheldig menes på Geodætisk Institut at
være meget lille. Til dette kan opsumeres, at hvis en systemfejl opstår
og man er nødt til at genetablere et helt pladelager, vil dette kræve,
at man i det maksimalt uheldige tilfælde skal "loade" 28 bånd. Dette svarer
til antallet af bånd som sidste totalkopiering fyldte(8 bånd), og samtlige
dagligkopieringbånd brugt indtil fejlen opstod(maksimalt 20). (Der foretages
10 dagligkopieringer mellem to totalkopieringer, og hver dagligkopiering
fylder ca. 2 bånd.)
$nl$$np$
Til dette argument siges på Geodætisk Institut, at chancen for en så stor
systemfejl er ganske lille. Man kunne på Geodætisk Institut benytte en
helt fjerde kopieringsstrategi, som dog kun kunne benyttes der, og som
kræver en del ændringer ved dette system. Kopieringsstrategien forudsætter
kendskab til datamængderne på Geodætisk Institut. Der findes her et lille
antal datafiler, som fylder særdeles meget. Disse kunne udelades fra den
daglige kopiering. Den kopieringsstrategi man kunne tænke sig går så ud på,
at man kun kopierer tekstfiler indeholdende programmer, og ved denne
kopiering benytter samme kopieringsstrategi som på H. C. Ø. Man kunne så en
gang imellem kopiere de store datafiler ved manuelt at overføre dem til bånd.
$nl$$nl$
_«bs»7_«bs»._«bs»4_«bs»._«bs»F_«bs»e_«bs»j_«bs»l__«bs»i__«bs»s_«bs»t_«bs»a_«bs»n_«bs»d_«bs»a_«bs»r_«bs»d_«bs»p_«bs»r_«bs»o_«bs»g_«bs»r_«bs»a_«bs»m_«bs»m_«bs»e_«bs»l__«bs»f_«bs»r_«bs»a__«bs»R_«bs»C_«bs».
$nl$$np$
Ved konstruktionen af systemet blev en del fejl i standardprogammel
fra RC opdaget. Af disse fejl kan en nævnes her. Denne fejl er
sikkert ikke ualmindelig.
$nl$$np$
De filer, der kopieres op på bånd, skal være i alfabetisk orden. Til at
sortere disse filer benyttes et standard program nemlig 'mdsortproc'. Dette
program har vist sig at være særdeles hurtigt men indeholder en fejl.
Når filerne skal sorteres gøres dette i alfabetisk orden som første kriterium.
Imidlertid findes normalt altid en del filer med samme navn, og når dette
optræder sorteres efter det der betegnes den nedre base. Dette er et heltal
og det er normalt for samtlige systemfiler det største negative tal
der kan repræsenteres i maksinen ( -8388607 ).
Mdsortproc benytter en del forskellige sorteringsrutiner og en af disse
sorterer ikke rigtig hvis det største negative tal mødes.
Man kan derver
risikerer, at en fil kopieres mere end en gang
på magnetbånd. Dette skyldes, at når en dagligkopiering foretages
og man skal overføre filer fra forrige bånd vil programmet INCSAVE flette
to kataloger sammen. Disse er det katalog der indeholder samtlige filer
fra gårsdagens kopiering, og de filer, der findes på den kopiering der
foretages idag. Ved denne fletning bliver der flettet rigtigt, idet jeg
var bekendt med problemet ved konstruktionen af systemet. Det er således
ved denne fletning muligt at en fil der findes på det 'forkerte' sted
i den ene fil vil komme med i det katalog der er resultatet af fletningen
mere end en gang.
$nl$$np$
Denne ting er selvfølgelig ikke af så stor betydning men den har bevirket
at indkøringen af systemet har taget en del mere tid. Ligeledes viser
den, hvor besværlige de fejl der viser sig ved en systemafprøvning kan være.
$nl$$nl$
_«bs»7_«bs»._«bs»5_«bs»._«bs»B_«bs»e_«bs»n_«bs»y_«bs»t_«bs»t_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»L_«bs»O_«bs»A_«bs»D_«bs».
$nl$$np$
Som beskrevet i afsnit 2 var det en forudsætning, da systemet blev konstrueret
at genetableringen af filer skal foregå ved RC's standardprogram LOAD.
Det viste sig imidlertid, at dette program er
mindre hensigtsmæssigt, således at systemet ved den sluttelige udformning
kom til at indholde en modificeret udgave af LOAD ( INCLOAD ).
$nl$$np$
De uhensigtmæssigeheder der var er at det ikke er muligt at specificere
at man kun vil genetablere de filer som ikke findes på 'discen' i forvejen.
$nl$$np$
En mangel ved LOAD er, at det burde være muligt at få en liste
over de filer der genetableres, uden at disse genetableres ved et
bestemt kald. Dette kan benyttes, hvis f.eks. samtlige et projekts
filer skal genetableres, men man ikke helt er sikker på om
der ikke findes nogle andre filer, som derved genetableres.
$nl$$nl$
_«bs»7_«bs»._«bs»6_«bs»._«bs»S_«bs»a_«bs»m_«bs»l_«bs»e_«bs»t__«bs»i_«bs»n_«bs»d_«bs»t_«bs»r_«bs»y_«bs»k__«bs»a_«bs»f__«bs»i_«bs»n_«bs»d_«bs»k_«bs»ø_«bs»r_«bs»i_«bs»n_«bs»g_«bs»s_«bs»e_«bs»r_«bs»f_«bs»a_«bs»r_«bs»i_«bs»n_«bs»g_«bs»e_«bs»r_«bs».
$nl$$np$
Ved udviklingen af et system, der benyttes af mange forskellige personer vil ting
opstå, som er svære at forudse. derudover er det ved et sikkerhedssystem
meget uhensigtsmæssigt at fejl opstår, når systemet er taget i brug.
Afprøvningen af et sådant system bør være særdeles grundigt.
$nl$$np$
Efter dette system blev taget i brug, forekom en del fejl, som
bevirkede at filer ikke kunne genetableres. Heldigvis er det
ikke sket så ofte, men det vil formentlig også være vanskeligt at afprøve
systemet så grundigt, at det helt kan undgås. Det er egentlig
først efter ca. 3-4 måneder brug på H.C.Ø. og 1 måned på Geodætisk Institut,
at jeg tør påstå at systemet er uden større fejl.
$ps0$
$ef$
▶EOF◀

DataMuseum.dk

RC4000/8000/9000

⟦51c42ebf0⟧ TextFile

Derivation

TextFile