Compiler-gruppen: Teknisk perfektionisme kontra nytte - 3

Som bekendt var RC ikke nogen økonomisk succes, og firmaet måtte have livredning adskillige gange. På RC trivedes adskillige konspirationsteorier om IBM's infiltrering af staten, regeringens svigt af dansk forskning, osv. Det har Per V. Klüver skrevet indsigtsfuldt om i IEEE Annals of the History of Computing (Vol. 21, No. 2, 1999).

Jeg var jo bare en stor dreng og var ikke blandet direkte ind i alt dette, men hørte om det. Det var jo uforståeligt, for vi - især compiler-gruppen - var jo fantastiske, og ingen i verden kunne lære os noget. Så hvorfor blev vi svigtet?

Først meget sent begyndte det at dæmre for mig at RC måske ikke havde de rigtige produkter. Compiler-gruppen sad i sit elfenbenstårn og forstod ikke hvad brugere og kunder havde brug for. Og selv om Bech havde endda meget store visioner om samfundsomspændende databehandling, formåede ingen at styre de kreative kræfter i den retning. Hans signaler til compiler-gruppen var at vi bare skulle lave noget genialt, så skulle han nok finde nogen der kunne sælge det.

En af de første gange det dæmrede for mig var i begyndelsen af 1970. En potentiel amerikansk kunde havde henvendt sig fordi han var interesseret i at købe RC 4000, som han på mange måder syntes om - ikke mindst på grund af prisen. Der var dog en ting han savnede - et indeks-sekventielt filsystem. Sådan et havde vi ikke. Brinch Hansens dominerende indflydelse på RC 4000 havde fortonet sig, og Bech indkaldte derfor Naur, Jørn og mig selv til et møde med kunden.

Han satte mødet i gang og overlod os til os selv. Hverken Jørn eller Naur havde erfaringer med et indeks-sekventielt filsystem, mens jeg dog nogenlunde vidste hvad det gik ud på, fordi jeg havde opbygget et kursus i administrative systemer som et led i den nye datalogi-uddannelse på Københavns Universitet og derfor havde læst litteraturen.

Kunden forklarede kort hvad sådan et filsystem gik ud på og hvorfor han havde brug for det. Til læserens orientering er ideen at man lagrer alle records i en fil ordnet efter deres sorteringsnøgle. Man anbringer huller passende steder så det ofte er muligt at skubbe nye records ind det rigtige sted, uden at skulle skubbe alle efterfølgende records. Det svarer til at man på et bibliotek ikke stiller bøgerne tæt på hylderne, men lader der være lidt tom plads sidst på hver hylde.

For hurtigt at kunne finde en bestemt record, har man et indeks der giver sorteringsnøglen for første record i hver af filens hovedafsnit (cylindre på disken). I starten af hver cylinder er der også et indeks der peger på den første record i hvert segment af cylinderen. På den måde kan computeren ved én flytning af diskhovederne til den rigtige cylinder og to læsninger af et disksegment, få fat i den rette record selvom filen er umådelig lang.

Problemet kommer når man indsætter en record og der ikke er et tilstrækkeligt stort hul i nærheden. Så kan man fx placere den overskydende record sammen med andre overskydende records et helt andet sted. Men nu kan man ikke længere være sikker på at man kan finde recorden med kun én hovedflytning. Når filen bruges i lang tid, kan det blive så rodet at man må få computeren til at omstrukturere det hele.

Nå, hvordan reagerede guruerne på det? Naur så først opgivende ud over denne amatøragtige fremgangsmåde. Med slet skjult arrogance spurgte han kunden om han havde overvejet at bruge rekursive procedurer i stedet.

Denne akademiske disciplin var kunden ikke bekendt med, og inden det blev alt for pinligt, greb jeg ind og forklarede at rekursive procedurer af flere grunde var totalt uegnede til denne problematik, og at kundens ønske var vigtigt for de fleste administrative systemer. Jeg antydede også at vi ville overveje at lave et sådant filsystem.

Senere var Naur stadig afvisende, mens Jørn efter mange overvejelser tog udfordringen op og endte med at lave et nydeligt og veldokumenteret system.

Hvorfor var der sådan en modvilje mod at implementere en velkendt løsning, der var uhyre nyttig i disk-baserede, administrative systemer? Der var selvfølgelig noget not-invented-here over modstanden, men det stak dybere. Husk på vores uskrevne idealer: enkelt, robust og nyttigt. Dette var i høj grad nyttigt, men ikke enkelt. Det værste var at det slet ikke var robust.

Ordet robust var ikke så præcist defineret, men vi mente noget med at ingen fejl eller uventede situationer måtte få systemet til at gå ned. Intuitivt gik vi videre og mente at det heller ikke måtte forringe systemets hastighed. Der måtte heller ikke være modstrid mellem hurtighed og pladsbesparelse. Kunne vi ikke opnå begge dele var det en afvejning som vi ikke turde lave. Et indeks-sekventielt filsystem krævede sådan en afvejning, og tilmed ville det gradvis blive langsommere og langsommere - uacceptabelt for purister som os.

Et lidt tidligere eksempel er compiler-gruppens arbejde med at lave en mere generel håndtering af input/output enheder til RC 4000, så det hele ikke skulle bygges ind i operativsystemet, inklusive strategier for at bruge multiple buffere og håndtere tekniske fejl på disse sårbare enheder. Sådanne strategier var hverken enkle eller robuste. Det skulle derfor være muligt for programmøren at styre det selv.

Inspireret af Naurs beretninger om Dijkstras arbejde med samarbejdende parallelle processer, designede vi en avanceret mekanisme i Algol til håndtering af parallelle processer. De blev kaldt zoner efter vores daværende russiske gæsts forslag. Zoner kunne man også bruge til at behandle magnetbånd, mv. - hvis man ellers var dygtig nok.

Kort tid efter at denne løsning var annonceret rundt om på RC, mødte min gamle chef, Finn Larsen, op hos os. Han og hans gruppe programmerede administrative anvendelser og han havde med bekymring set vores forslag. Det kan godt være at I har løst et problem for jer selv, men I har gjort det meget sværere for os der skal bruge det, sagde han.

Jeg tror der blev meget tavst i vores gruppe - selv jeg var vist mundlam. Det tog lang tid at fordøje det, for egentlig havde han jo ret. Jeg tror løsningen blev at vi indførte en standardbehandling af input/output enhederne som den "avancerede" programmør kunne koble fra. Men vi løste ikke Finn's egentlige problem, fordi vi ikke forstod det.

3 af 5. Trykt i Dansk Datahistorisk Forenings festskrift, 2005: Regnecentralen - dansk institut for matematikmaskiner. Gengivet med tilladelse af redaktørerne Henning Isaksson og Ole Pedersen.

Søren Lauesens billede

Kommentarer (2)

Log ind eller opret en konto for at skrive kommentarer