|
DataMuseum.dkPresents historical artifacts from the history of: RC4000/8000/9000 |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about RC4000/8000/9000 Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 153600 (0x25800)
Types: TextFile
Names: »incsaveopg«
└─⟦00964e8f7⟧ Bits:30007478 RC8000 Dump tape fra HCØ.
└─⟦b2ec5d50f⟧
└─⟦this⟧ »incsaveopg«
\f
H.C.Ørsted Institute
Computer Department
Universitets parken 5
DK-2100 København Ø
Designmæssige overvejelser og
indkøringserfaringer med et 'inkrementalsave'system.
Afleveret af:
_____________
Viggo Nis Kørst
\f
2
INDHOLDSFORTEGNELSE.
____________________
1.INDLEDNING..............................
2.FORMÅLET MED SYSTEMET...................
3.BESKRIVELSE AF SYSTEMETS VIRKEMÅDE......
3.1.Beskrivelse af INCLOAD................
3.2.Beskrivelse af INCSAVE................
3.3.Beskrivelse af INITSAVECAT............
3.4.Beskrivelse af INITMTPOOL.............
3.5.Beskrivelse af INITTEMPCAT............
3.6.Beskrivelse af LISTMTPOOL.............
3.7.Beskrivelse af LOOKSAVE...............
3.8.Beskrivelse af UPDMTPOOL..............
4.FORSKELLIGE KOPIERINGSMETODER...........
5.ORGANISERINGSMÅDER AF KATALOGET.........
5.1.Beskrivelse af indholdet af kataloget.
5.2.Overvejelser om katalogform...........
6.ANDRE DESIGNMÆSSIGE OVERVEJELSER........
7.INDKØRINGSERFARINGER....................
7.1.Krav om korrekt dato..................
7.2.Forskellige magnetbåndsformater.......
7.3.Problemer på Geodætisk Institut.......
7.4.Fejl i standardprogrammel fra RC......
7.5.Benyttelse af LOAD....................
7.6.Samlet indtryk af indkørinserfaringer.
Bilag 1 Incsaveman.
\f
INKREMENTALSAVESYSTEM 3
1.INDLEDNING.
_____________
Denne opgaves baggrund er, at jeg har udviklet et 'inkremen-
talsave'system til en RC8000 datamat. Ved et 'inkremental-
save'system forstås et system, der foretager sikkerhedskopie-
ring af filer fra plade- og tromlelagre. Denne sikkerhed-
skopiering foregår ud fra bestemt kopieringstrategi, og det er
udformningen af kopieringsstrategien, der har givet navnet
'inkremental'savesystem. I forbindelse med udviklingen og ind-
kø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.
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 over-
vejelser primært drejer sig om organisationen af forskellige
hjælpefiler. Disse overvejelser har således ikke indflydelse på
hovedprincipperne i systemets virkemåde.
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 or-
ganiseres, 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).
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.
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.
\f
INKREMENTALSAVESYSTEM 4
2.FORMÅLET MED SYSTEMET.
________________________
Dette afsnit vil beskrive, hvad systemet skal bruges til, og
hvilke krav, der blev gjort, da udviklingen af systemet
påbegyndes.
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.
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.
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å magnet-
bånd. At dette system ikke kan anvendes skyldes, at det
tidsmæssigt vil tage for lang tid, og at antallet af magnet-
bå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.
Ved konstruktionen af 'inkrementalsave'systemet blev beslut-
tet, 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.
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 indehol-
de information, der er nødvendig for at kunne identificere en
fil. Derudover skal der findes oplysninger om, på hvilke bånd
en fil findes. Til kataloget skal der konstrueres et program,
som kan slå op i det, og f.eks. finde en fil med et givent
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
\f
INKREMENTALSAVESYSTEM 5
mulighed for hurtigt at kunne finde ud af, på hvilket magnet-
bå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.
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 genetab-
leret, men brugeren ikke helt kan huske navnet på filen, kun
måske de to eller tre første bogstaver i filens navn.
'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 baggrund-
slageret og andre bruges til delvis kopiering. Systemet skal
således administrerer, hvilke bånd der skal benyttes til de
forskellige kopieringer. Denne administration skal foregå efter
følgende principper:
Ved en totalkopiering skal det ældste bånd, der før er blevet
benyttet til en sådan kopiering benyttes.(Ækvivalent for dagli-
ge kopieringer) Ved denne metode vil en fil overleve på
magnetbånd så længe som muligt med de anvendte bånd.
\f
INKREMENTALSAVESYSTEM 6
3.BESKRIVELSE AF SYSTEMET VIRKEMÅDE.
____________________________________
Dette afsnit vil give en kort beskrivelse af de i systemet
indgående programmer. Ud fra dette vil hovedprincipperne for
systemets virkemåde fremgå.
Systemet består af følgende programmer:
_______________________________________
INCLOAD
INCSAVE
INITSAVECAT
INITMTPOOL
INITTEMPCAT
LISTMTPOOL
LOOKSAVE
UPDMTPOOL
Af disse programmer er INCSAVE det største og langt det
vigtigste. Programmet foretager selve kopieringen af filer fra
plade- og tromlelagre.
Den normale benyttelse af systemet vil være på følgende måde:
______________________________________________________________
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 kopie-
ringsbånd.
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 program-
merne kaldes o.l. henvises til manualen over 'inkremental-
save'systemet, der findes vedlagt som bilag 1.
3.1.Beskrivelse af INCLOAD.
___________________________
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 genetablere de filer fra
et magnetbånd, der ikke allerede findes på baggrundslageret.
\f
INKREMENTALSAVESYSTEM 7
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.
Programmet er ligeledes ændret så en del andre uhensigtsmæs-
sigheder i RC's LOAD er fjernet. Det vil dog ikke være rimeligt
at medtage disse ændringer her, idet de er ret detailjerede.
3.2.Beskrivelse af INCSAVE.
___________________________
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:
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:
1.Totalkopiering. Her kopieres samtlige filer, der findes på
plade- og tromlelageret.
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 daglig-
kopiering foregår på den ovenfor beskrevne måde, findes i
afsnit 4.
Filerne, som skal kopieres, findes og udskrives i hjæl-
pekataloget TEMPCAT. Dette hjælpekatalog (TEMPCAT) bliver sor-
teret i alfabetisk orden. Sorteringen foregår ved et standard-
program fra RC (mdsortproc). Efter sorteringen kopieres filerne
i alfabetisk orden op på et magnetbånd.
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åndet.
Efter at selve kopieringen af filerne fra plade- og trom-
lelageret til bånd er færdigt bliver et tredie hjælpekatalog
(SAVECAT) ændret. Kataloget indeholder information om filer,
der findes på bånd.
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.
3.3.Beskrivelse af INITSAVECAT.
_______________________________
Programmet anvendes til at initialisere hjælpefilen SAVECAT.
\f
INKREMENTALSAVESYSTEM 8
Det er nødvendigt at initialisere den, idet programmet INCSAVE
forudsætter et helt specielt format. Programmet kaldes normalt
kun ved installeringen af systemet.
3.4.Beskrivesle af INITMTPOOL.
______________________________
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ødven-
digt at angive, hvormange bånd der skal benyttes til de to
former for kopiering.
3.5.Beskrivelse af INITTEMPCAT.
_______________________________
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.
3.6.Beskrivelse af LISTMTPOOL.
______________________________
Programmet benyttes til at udskrive informationen i MT-
POOL'en. At skulle bruge programmet kan skyldes, at man f.eks.
ønsker at indsætte flere bånd i MTPOOL'en.
3.7.Beskrivelse af LOOKSAVE.
____________________________
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.
3.8.Beskrivelse af UPDMTPOOL.
_____________________________
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 anven-
des til at indsætte nye bånd i MTPOOL'en.
\f
INKREMENTALSAVESYSTEM 9
4.FORSKELLIGE KOPIERINGSMETODER.
________________________________
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.
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:
1.En fil skal findes sålænge som muligt på et magnetbånd.
2.Ved genetablering af filer f.eks. ved en system fejl skal så
få magnetbånd som muligt benyttes til genetablering.
3.Så få bånd som muligt skal benyttes, når en kopiering
foretages.
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.
1.Med fast tidsmellemrum at fortage en totalkopiering af
baggrundslageret.
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 syste-
met. 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. 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 total-
kopiering på 8 bånd.
2.Med et fast tidsinterval at kopiere hele baggrundslageret og
derudover med et fast kortere tidsinterval at kopiere de filer,
der ændres.
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 total-
kopiering foretages næste dag kun en kopiering af de filer, der
er ændret siden totalkopieringen.
Ved denne strategi kræves naturligvis, at det er muligt at
se, om en fil er ændret siden en bestemt dato. Antallet af
\f
INKREMENTALSAVESYSTEM 10
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.
En ret stor ulempe ved metoden er, at hvis en bruger opretter
og sletter en fil mellem to kopieringer vil en fil 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 genetab-
leringen.
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 totalkopierings-
bånd.
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.
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.
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.
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.
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.
Af de foreslåede 3 strategier har jeg valgt, at implementere
strategi 3 og lade denne strategi være standard. Dette skyldes
\f
INKREMENTALSAVESYSTEM 11
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.
For at illustrere, hvorlænge filer overlever ved 'inkremen-
talsave'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 total-
kopiering. 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.
\f
INKREMENTALSAVESYSTEM 12
5.ORGANISERINGSMÅDER AF KATALOGET.
__________________________________
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.
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.
5.1.Beskrivelse af indholdet af kataloget.
__________________________________________
For det første skal kataloget indeholde den information der
er nødvendig for at kunne identificere en fil. Disse ting er
følgende:
( 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.)
1.ord permkey + (område eller indgang)
2.ord nedre base
3.ord øvre base
4.ord - 7.ord navnet på filen.
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.
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.
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 positio-
nen 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.
At der kan spares tid skyldes, at en magnetbåndstation
\f
INKREMENTALSAVESYSTEM 13
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.
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.
5.2.Overvejelser om katalogform.
________________________________
Dette afsnit vil beskrive, hvilke former for katalogor-
ganisation, 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.
1.En form for indekssekventiel organisering.
____________________________________________
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:
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.
\f
INKREMENTALSAVESYSTEM 14
Filnavnet eksempelvis ALGOL
ALGOL
!
!
------------------------------------------
! !
! Adresserne på filer begyndende med a !
! !
-------------------------------------------
! ! !
! ! !
! ! !
------------- ------------- -------------
! ! ! ! ! !
!Tabel med ! !Tabel med ! . . . !Tabel med !
! aa ! ! ab ! ! aå !
! ! ! ! ! !
------------- ------------- -------------
! ! . . . ! ! . . . ! ! ...
! ! ! ! ! !
! ! ! ! ! !
---------------------------------------------------
! !
! !
! Record for hver fil !
! !
! !
---------------------------------------------------
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.
Der vil imidlertid også være en del ulemper ved denne
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. Hvorimod filer der når det bånd der
benyttes ved kopieringen benyttes derved fjernes fra båndet og
derved ikke længere eksisterer på et bånd hørende til 'in-
krementalsave'systemet, skal de fjernes fra kataloget.
Denne opdatering af kataloget kan være ret vanskelig, idet
hele kataloget skal omorganiseres. Ved initialiseringen af
kataloget vil det sikkert også være vanskeligt at angive, hvor
stor de indekstabeller skal være.(Det er ikke på forhånd muligt
at sige, hvormange filer der begynder med forskellige bog-
staver.)
\f
INKREMENTALSAVESYSTEM 15
2.Organisering ved et hashkatalog.
__________________________________
Ved denne organiseringsform kan man ved en passende hashfunk-
tion indsætte filerne i kataloget svarende til den pågældende
hashværdi. Antallet af hashindgange skal ved denne organise-
ringsform 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.
Fordelen ved denne form for organisering er, at det er
rimeligt nemt at indsætte og slette indgange i kataloget.
Derudover er det endvidere særdeles hurtigt at slå op i
kataloget.
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.
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. 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.
Nedenstående figur angiver, hvordan hashkataloget kommer til at
se ud.
\f
INKREMENTALSAVESYSTEM 16
--------------------------------
! filer der har hashværdi 0 !
! !
--------------------------------
! ledig plads !
! !
--------------------------------
! filer der har hashværdi 1 !
! !
--------------------------------
! ledig plads !
! !
--------------------------------
! !
! . !
! . !
! . !
! !
! !
--------------------------------
! filer med hashværdi n !
! !
--------------------------------
! ledig plads !
! !
--------------------------------
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 filind-
gange, der er hashes ind til denne indgang. Dette er også til
for at bedre at kunne klare overløb.
Når man vil slå op i kataloget gøres dette efter følgende
principper: Først findes hashværdien til pågældende fil. Deref-
ter indlæses det segment, som svarer til denne hashværdi. På
dette segment står, hvormange filer der maksimalt skal gennem-
løbes for at finde den pågældende fil. Segmentet gennemløbes
nu, idet det ved læsning af hver record først undersøges om
filen overhovedet hører til denne hashindgang. Derved kan den
ønskede fil findes. Antallet af filindgange der skal gennem-
søges før den ønskede fil findes afhænger af fyldningsgraden af
kataloget, som maksimalt er sat til 80 %.
Som konklussion 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, at det
godt kunne opveje de ulemper der var. Endvidere kan siges, at
andre eksisterende kataloger over filer på RC8000, så som
hovedkataloget, hvori samtlige filer findes, ligeledes er
organiseret som et hashkatalog. Da RC har eksisteret på
markedet i en del år betragtede jeg det som om at fra deres
side mente at organisre et katalog på denne størrelse ville
\f
INKREMENTALSAVESYSTEM 17
være særdeles rimeligt.
\f
INKREMENTALSAVESYSTEM 18
6.ANDRE DESIGNMÆSSIGE OVERVEJELSER.
___________________________________
Dette afsnit vil beskrive de designmæssige overvejelser, der
endnu ikke har været diskuteret.
Udover det katalog over filer, som er beskrevet i forrige
afsnit findes til systemet 2 andre hjælpefiler. Ved or-
ganisationen 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ærlig store vil det også være urimeligt at gøre store
overvejelser om, hvordan de skal organiseres.
Den ene fil benyttes til at administrerer de magnetiske bånd,
der benyttes af systemet. Den kaldes i systemet MTPOOL.
Indholdet er følgende:
1.ord båndnr
2.ord-5.ord båndnavn
6.ord angivelse af om båndet benyttes til totalkopiering eller
dagligkopiering. Derudover angives om det er det sidst benyt-
tede bånd.
7.ord Dato for sidste benyttelse.
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.
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ørin-
gen af systemet.(afsnit 6)
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:
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 monterer.
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.
\f
INKREMENTALSAVESYSTEM 19
Udover at administrerer 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 magnetiske
bånd, hvorpå filen findes.
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.
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.
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.
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:
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 lange
beregninger der kan vare særdeles længe op til et døgn eller
lignende.
\f
INKREMENTALSAVESYSTEM 20
Hvis man i stedet sørgede for at være sikker på at læse filen
og derved reserverede til 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.
Dette problem undgås ved ikke at kopierer 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 tildfælde næsten aldrig vil forekomme. Dette er desværre
ikke rigtigt, idet f.eks.på Geodætisk Institut, hvor en daglig-
kopiering indeholder ca.250 filer sker dette for omkring 30
filer. Altså problemet kommer særdeles hyppigt.
\f
INKREMENTALSAVESYSTEM 21
7.INDKØRINGSERFARINGER.
_______________________
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.
7.1.Krav om korrekt dato.
_________________________
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.
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 situa-
tioner, 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.
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.
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 initiali-
seret 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.
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
\f
INKREMENTALSAVESYSTEM 22
fra igår, i de til systemet hørende hjælpefiler. Begge metoder
er efter min mening ikke gode.
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 sinde 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.
7.2.Forskellige magnetbåndsformater.
____________________________________
Den i dette afsnit beskrevne indkørtingserfaring er en, det
ville være vanskeligt at forudsætte ved udviklingen af syste-
met.
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 standard-
program 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ørrel-
se, 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
instellation. 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.
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 forud-
sattes 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.
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 pakketæthed på 7 segmenter pr blok.
Imidlertid viste det sig muligt at udvide pakketætheden til 8
segmenter. Derefter kunne kopieringsprogrammet, der anvendes
(INCSAVE) naturligvis ikke overføre fra bånd med en pakketæthed
på 7 segmenter til en pakketæthed på 8 segmenter. Dette
bevirkede, at under indkøringsfasen var det faktisk nødvendigt
at ændre de procedure, der kopierede filer op på bånd særdeles
radikalt.
Dette problem er medtaget her, idet det viser, at ved et
grundigt forstudium af design kan væsentlige ting ikke blive
medtaget.
7.3.Problemer på Geodætisk Institut.
____________________________________
Da systemet blev konstrueret, var det med kendskab til de
\f
INKREMENTALSAVESYSTEM 23
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.
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.
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.
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ødt op til
omkring 7 til 8 bånd dagen inden der foretages en total-
kopiering. Ved denne kopiering vil således skulle anvendes
omkring 14-15 bånd.
Ved Geodætisk Institut vil man således ikke overføre filer
fra forrige kopiering men kun kopiere de filer der ændres.
Naturligvis kan dette lade sig gøre ved det beskrevne system
idet man således blot kalder systemet på en anden måde end
standardmåden. Imidlertid er de ulemper der er beskrevet i
afsnit 4 tilstede, men risikoen for at man er meget uheldig
menes på Geodæstisk Institut at være forholdsvis lille. Til
dette kan opsumeres, at hvis en stor systemfejl opstår og man
er nød til at genetablere et helt pladelager. Hvis dette sker
midt i mellem to totalkopieringer, så vil det kræve, at man
"loader" det bånd fra sidste totalekopiering. Dernæst skal de
bånd der er benyttet til samtlige dagligekopieringer siden
sidste totalekopieringer anvendes. I alt kan dette maksimalt
være 36 bånd.
Til dette argument siges på Geodætisk Institut at chancen for
en så stor system fejl er ganske lille.
7.4.Fejl i standardprogrammel fra RC.
_____________________________________
Ved konstruktionen af systemet blev en del fejl i standard-
progammel fra RC opdaget. Af disse fejl kan en nævnes her.
Denne fejl er sikkert ikke ualmindelig.
\f
INKREMENTALSAVESYSTEM 24
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 sortere 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års-
dagens 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.
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 ejendommelig de fejl der viser
sig ved en sytemafprøvning kan være.
7.5.Benyttelse af LOAD.
_______________________
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 der ved
dette program findes ting, der er mindre hensigtsmæssige,
således at systemet ved den sluttelige udformning kom til at
indholde en modificeret udgave af LOAD ( INCLOAD ).
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.
En mangel ved LOAD er, at det burde være muligt at få en
liste over de filer der genetableres, uden at disse genetab-
leres 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.
7.6.Samlet indtryk af indkøringserfaringer.
___________________________________________
Ved udviklingen af et system, der benyttes af mange forskel-
lige 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.
\f
INKREMENTALSAVESYSTEM 25
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.
\f
INKREMENTALSAVESYSTEM 26
\f
▶EOF◀