⟦ce775bd4c⟧

TextFile

H.C.Ørsted Institute
Computer Department
Universitets parken 5
DK-2100 København Ø

Designmæssige overvejelser og
indkøringserfaringer med et 'inkrementalsave'-system.

Viggo Nis Kørst.

ORCB version 1.0

INKREMENTALSAVESYSTEM 2

____________________\rINDHOLDSFORTEGNELSE.

1.INDLEDNING...............................3

2.FORMÅLET MED SYSTEMET....................4

3.BESKRIVELSE AF SYSTEMETS VIRKEMÅDE.......6
3.1.Beskrivelse af INCLOAD.................6
3.2.Beskrivelse af INCSAVE.................7
3.3.Beskrivelse af INITSAVECAT.............8
3.4.Beskrivelse af INITMTPOOL..............8
3.5.Beskrivelse af INITTEMPCAT.............8
3.6.Beskrivelse af LISTMTPOOL..............8
3.7.Beskrivelse af LOOKSAVE................8
3.8.Beskrivelse af UPDMTPOOL...............8

4.FORSKELLIGE KOPIERINGSMETODER............9

5.ORGANISERINGSMÅDER AF KATALOGET.........13
5.1.Beskrivelse af indholdet af kataloget.13
5.2.Overvejelser om katalogform...........14

6.ANDRE DESIGNMÆSSIGE OVERVEJELSER........21

7.INDKØRINGSERFARINGER....................24
7.1.Krav om korrekt dato..................24
7.2.Forskellige magnetbåndsformater.......25
7.3.Problemer på Geodætisk Institut.......26
7.4.Fejl i standardprogrammel fra RC......27
7.5.Benyttelse af LOAD....................28
7.6.Samlet indtryk af indkørinserfaringer.28

Bilag 1 Incsaveman.
\f

INKREMENTALSAVESYSTEM 3

_____________\r1.INDLEDNING.

Denne opgaves baggrund er, at jeg har udviklet et såkaldt
'inkrementalsave'system til en RC8000 datamat. Ved et 'in-
krementalsave'system forstås et system, der foretager sikker-
hedskopiering af filer fra plade- og tromlelagre. Denne sikker-
hedskopiering 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

________________________\r2.FORMÅLET MED SYSTEMET.

Dette afsnit beskriver, hvad systemet skal bruges til, og
hvilke krav, der blev stillet, da udviklingen af systemet
påbegyndtes.

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 bes-
luttet, 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 den information, der er nødvendig for at kunne identificere
en fil. Derudover skal der findes oplysninger om, på hvilke
\f

INKREMENTALSAVESYSTEM 5

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 givet navn. Or-
ganisationen 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.

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 administrere, 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
daglige kopieringer). Ved denne metode vil en fil overleve på
magnetbånd så længe som muligt med de anvendte bånd.
\f

INKREMENTALSAVESYSTEM 6

____________________________________\r3.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å.

_____________________________________r:\rSystemet består af følgende programme

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.

_______________________________________________________________\rDen 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.

___________________________\r3.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
\f

INKREMENTALSAVESYSTEM 7

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.

___________________________\r3.2.Beskrivelse af INCSAVE.

Som nævnt ovenfor er INCSAVE det program, der foretager
selve kopieringen af filer fra plade- og tromlelagre. Program-
met 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åndene.

Efter at selve kopieringen af filerne fra plade- og
tromlelageret til bånd er færdigt, bliver et tredie hjæl-
pekatalog (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.

INKREMENTALSAVESYSTEM 8

_______________________________\r3.3.Beskrivelse af INITSAVECAT.

Programmet anvendes til at initialisere hjælpefilen SAVE-
CAT. Det er nødvendigt at initialisere den, idet programmet
INCSAVE forudsætter et helt specielt format. Programmet kaldes
normalt kun ved installeringen af systemet.

______________________________\r3.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.

_______________________________\r3.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.

______________________________\r3.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.

____________________________\r3.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.

_____________________________\r3.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.

INKREMENTALSAVESYSTEM 9

________________________________\r4.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 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)

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:
\f

INKREMENTALSAVESYSTEM 10

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
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 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 totalkopie-
ringsbånd benyttes og derudover skal samtlige dagligkopierings-
bånd, der er brugt siden sidste totalkopiering, anvendes til
genetableringen.

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 sikker-
hed. 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. De vil normalt blive gemt i op til et
halvt år.

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
\f

INKREMENTALSAVESYSTEM 11

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 implemen-
tere 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 strate-
gien 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.

På Geodætisk Institut bliver kopieringsstrategi 2 benyttet
på følgende måde:

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.

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
\f

INKREMENTALSAVESYSTEM 12

dag). Ialt benyttes således omkring 96(total kopieringsbånd) +
40 (dagligkopieringsbånd) = 136 bånd.
\f

INKREMENTALSAVESYSTEM 13

__________________________________\r5.ORGANISERINGSMÅDER AF KATALOGET.

Dette afsnit vil indeholde en diskusion af, hvordan katalo-
get 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.

__________________________________________\r5.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-
\f

INKREMENTALSAVESYSTEM 14

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

________________________________\r5.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.

____________________________________________\r1.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 15

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.

Efter at en anden organisationsform var blevet valgt, blev
jeg opmærksom på, at der fra RC's side leveres et standard-
system til indekssekventielle filer. Dette vil formentlig kunne
benyttes med fordel.

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

INKREMENTALSAVESYSTEM 16

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.

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 bog-
staver.)
\f

INKREMENTALSAVESYSTEM 17

__________________________________\r2.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.

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.

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 (se nedenståen-
de). 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 18

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

Hver filindgang indeholder udover den i afsnit 5.1. besk-
revne 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.

Når man vil slå op i kataloget gøres dette efter følgende
principper: En hashindgang har eksempelvis følgende udseende.

INKREMENTALSAVESYSTEM 19

Hashindgang p --------------------
! antal filerecord.!
! på denne hashind-!
! gang !
--------------------
! hashværdi p !
! filrecord !
--------------------
! hashværdi q !
! filrecord !
--------------------
! hashværdi p !
! filrecord !
--------------------
! . !
! . !
! . !
--------------------
! evt. ledig plads !
! !
! !
! !
--------------------

En fil findes nu efter følgende princip:

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;

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
\f

INKREMENTALSAVESYSTEM 20

benytter er i øvrigt også den jeg har valgt.

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

INKREMENTALSAVESYSTEM 21

_____________________________________\r6.ANDRE DESSIGN MÆ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ærligt 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 7)

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
\f

INKREMENTALSAVESYSTEM 22

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.

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 magnet-
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 system-
filer 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
\f

INKREMENTALSAVESYSTEM 23

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 lang-
varige beregninger der kan vare flere døgn.

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.

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 daglig-
kopiering indeholder ca.250 filer sker dette for omkring 30
filer. Altså problemet kommer særdeles hyppigt.
\f

INKREMENTALSAVESYSTEM 24

_______________________\r7.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.

_________________________\r7.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.
\f

INKREMENTALSAVESYSTEM 25

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.

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.

____________________________________\r7.2.Forskellige magnetbåndsformater.

Den i dette afsnit beskrevne indkøringserfaring 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
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.

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 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 segmen-
ter. Dette bevirkede, at under indkøringsfasen var det faktisk
nødvendigt at ændre de procedurer, der kopierede filer op på
\f

INKREMENTALSAVESYSTEM 26

bånd særdeles radikalt.

Dette problem er medtaget her, idet det viser, at selv ved
et grundigt forstudium af design kan væsentlige ting blive
udeladt.

____________________________________\r7.3.Problemer på Geodætisk Institut.

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.

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

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 til-
stede, men risikoen for at man er meget uheldig menes på
Geodætisk Institut at være meget lille. Til dette kan op-
sumeres, 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
\f

INKREMENTALSAVESYSTEM 27

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(mak-
simalt 20). (Der foretages 10 dagligkopieringer mellem to
totalkopieringer, og hver dagligkopiering fylder ca. 2 bånd.)

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

_____________________________________\r7.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.

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å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
\f

INKREMENTALSAVESYSTEM 28

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.

_______________________\r7.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 dette program er mindre hensigtsmæssigt, således at systemet
ved den sluttelige udformning kom til at indholde en modifice-
ret 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.

___________________________________________\r7.6.Samlet indtryk af indkøringserfaringer.

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.

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 29

▶EOF◀

DataMuseum.dk

RC4000/8000/9000

⟦ce775bd4c⟧ TextFile

Derivation

TextFile