Compiler-gruppen: Teknisk perfektionisme kontra nytte - 4

Generelt havde gruppen en uvilje mod at beskæftige sig med administrativ databehandling, selvom det nok var den største indtægtskilde for RC. En del af gruppen havde tidligt med succes brugt Algol-principperne til at lave en Cobol-compiler til Siemens, men ingen ville høre tale om at vi skulle have Cobol til egne maskiner. Man hævdede, vistnok især Naur, at Algol udmærket kunne bruges også til administrativ databehandling.

RC's servicecentre havde i lang tid udviklet administrative systemer som man kørte for kunder på servicebasis. Karakteristisk nok ved jeg dårligt om de blev skrevet i Algol eller assembler, og compiler-gruppen gjorde sig mig bekendt aldrig den anstrengelse at sætte sig ind i hvad servicecentrenes behov kunne være. Når vi en gang imellem så lidt af et program fra servicecentrene, sad vi og godtede os over deres primitive programmeringsstil, fx kontrol af om et varenummer var tastet rigtigt:

<div class="geshifilter"><pre class="text geshifilter-text" style="font-family:monospace;">if c=20 or c=25 or c=32 or c=34 then . . .</pre></div>

Næ, var man rigtig datalog, så lavede man en tabel over alle tegn, der straks kunne give tegnets type.

<div class="geshifilter"><pre class="text geshifilter-text" style="font-family:monospace;">if type[c] = forbogstav then . . .</pre></div>

Nyttig løsning

Her havde vi en enkel, robust og nyttig løsning. Vi glemte ganske vist hvor enormt besværligt det var at opbygge sådan en tabel, hvilket Algol ikke gav støtte til. Det var sådanne detaljer vi kiggede på - ikke på de store behov for at håndtere fx record-strukturer og databaser.

Et af servicecentrene var baseret på en CDC 1604, som jeg selv arbejdede på et par år inden jeg kom i compiler-gruppen. Maskinen var anskaffet fordi Gier ikke kunne levere den nødvendige kapacitet til administrative opgaver. Planen havde været at bruge CDC's Algol til opgaverne, men compileren var ubrugelig, og man endte med at bruge Fortran, som var langt mere egnet. Cobol var stadig et fy-ord. Hvordan havde man dog kunnet forestille sig at Gier kunne løse de opgaver som Stat og Kommuner havde?

På et sent tidspunkt begyndte Paul Lindgreen, der kom fra compiler-gruppen, sammen med Bjørn Ørding Thomsen at udvikle bedre Algol-baserede værktøjer til administrative systemer. Jeg ved ikke i hvor høj grad de fik succes, men de fik i hvert fald ikke moralsk støtte fra resten af compiler-gruppen.

Når vi nu hævdede at Algol var egnet til administrative systemer, hvad gjorde vi så for at håndtere variable af typen text? Denne datatype findes ikke i Algol, men det er den allervigtigste type data i administrative systemer. I Cobol findes der grundlæggende ikke andre typer.

Vi gjorde stort set ingenting! Der fandtes ikke engang typen char, men der var da en procedure der kunne indlæse et tegn og lagre det som et heltal, og en anden der kunne udskrive et heltal som et tegn. Ellers var tekster kun tekstkonstanter; sådan nogle man fx brugte til at skrive overskrifter på matematiske tabeller.

Og hvorfor havde vores Algol ingen tekstvariable? Dels fordi det ikke var en del af Algol 60 standarden, som Naur havde været dybt involveret i, men nok lige så meget fordi vi ikke kunne finde en enkel og robust måde at håndtere det på. Vores maskiner var bygget til talbehandling. I GIER kunne man adressere et ord som var på ca. 40 bit, i RC 4000 et ord på 24 bit.

I administrative anvendelser er tekster det der fylder mest i lageret, og lagerplads var et evigt problem, både i centrallageret og på disken. Man var derfor nødt til at pakke flere tegn sammen i ét ord, men så kunne man ikke behandle en tekst som et array af tegn. Eller rettere sagt, man kunne godt, men det ville ikke være en enkel og robust løsning. Vores Algol tilbød ikke engang standardprocedurer til at pakke tegn ind og ud, sådan som det fra tidernes morgen har været muligt i C. Det var noget folk selv måtte programmere.

Renhed frem for nytte

I dag kan jeg tydeligt se mønstret i hvad vi gjorde. Vi elskede at finde "rene" løsninger, enkle og robuste. Kunne vi ikke det, opgav vi at løse problemet, selv hvis nytten ville være stor. Vi overlod løsningen til vores brugere, de der programmerede anvendelserne som vi levede af. Og vi kunne endda finde på at se hånligt på deres "snavsede" løsninger på de problemer som vi selv havde opgivet.

Hvad med vores højt besungne operativsystem, monitoren til RC 4000? Brinch Hansen gjorde det berømt, og jeg selv var en af hovedmændene bagved. Det stod såmænd ikke bedre til. I lang tid diskuterede vi operativsystemets strategi for lager- og tidsdeling, men kunne selvfølgelig ikke finde en enkel og robust løsning. Jeg foreslog derfor en mekanisme hvor operativsystemet kunne uddelegere ansvaret til underordnede operativsystemer, der så kunne implementere deres egen strategi. Det faldt øjeblikkeligt i god jord og blev det bærende princip. Endnu engang havde vi undgået at løse de egentlige problemer, men givet dem videre til andre.

En anden gruppe blev sat til at lave et sådant underordnet operativsystem, Boss 1, men det mislykkedes. Kort tid efter fik jeg til opgave at forsøge en gang til. Det blev til Boss 2, som tog enormt lang tid at lave. Det viste sig hurtigt at ideen med at kunne lave et underordnet operativsystem nok var god i princippet, men der manglede en masse mekanismer i det overordnede operativsystem, for at det kunne lykkes. Der måtte forhandles en løsning med Brinch og de andre der lavede monitoren, og som nødigt så deres enkle, robuste løsninger saboteret. Det lykkedes i nogen grad.

Og så blev det underordnede operativsystem vel godt? Næ, det lod vi som om, men det var ikke særlig nyttigt til moderne administrative opgaver, hvor data kom ind via terminaler. Vi havde ikke forstået behovene. Jeg kan se i dag, at vi troede at alle brugte computerne til det samme som vi: Man rettede i nogle tekstfiler og fik dem derefter oversat eller behandlet på anden måde. Derfor havde Boss 2 en indbygget kommando-baseret teksteditor der kunne betjene mange brugere samtidig. Når de så skulle have deres tekster behandlet, skete det med en slags batch-behandling, der dog kunne køre nogle få jobs parallelt. Det var bestemt ikke egnet til datidens moderne databehandling og ville ikke have været konkurrencedygtigt.

Hvis vi havde forstået behovet i databehandling, ville vi have opdaget at der ikke var brug for teksteditering, men for udskrift og indtastning via skemaer. Vi kunne så have lavet en mange-bruger editor til det. Den efterfølgende behandling af denne transaktion kunne godt være sket med vores form for batch. Havde vi gjort det, kunne vi have været et par år før IBM's 3270 terminal, som kom midt 1971. Vi kunne have gjort i software, hvad den gjorde i hardware. Den kom til at præge markedet i mange år fremover, og den emuleres stadig på PC og UNIX.

Det kan være lærerigt at se på hvordan en meget succesrig virksomhed som Navision, nu Microsoft Business Solutions, blev skabt. På det tidspunkt da grundlæggerne lavede det første produkt, var der opstået en masse små administrative systemer som konkurrerede indædt om markedet. Navision folkene skaffede sig et eksemplar af hvert af dem og studerede detaljeret deres styrker (og i mindre grad deres svagheder).

Desuden allierede de sig med en revisor der havde god forstand på alle de administrative arbejdsopgaver i virksomheder. Og så byggede de et system der kunne alt det bedste fra de andre, og som effektivt støttede de opgaver som revisoren var ekspert i. De gjorde sig stor umage for at lave systemet rimeligt enkelt og robust, men gik ikke af vejen for at tilføje specielle mekanismer som var særligt nyttige. Kort sagt, de gjorde meget af det som vi også forsøgte i compiler-gruppen, men var mere pragmatiske, og først og fremmest drevet af en indgående forståelse af kundernes behov.

Kunne vi have gjort det anderledes?

Set i bakspejlet burde vi have handlet anderledes, men det ville have krævet en indsigt vi ikke havde. Finn Larsen og Peer Lorentzen fortæller at vi ikke var det eneste elfenbenstårn. RC var fuld af dem, fx flere salgs- og servicecentre.

Hele RC var baseret på den idé at hvis en masse dygtige folk alle sammen gør det de synes er rigtigt, så bliver det samlede resultat godt. Nej, det gør det ikke, for der kommer slet ikke noget samlet resultat, kun en masse isolerede øer, der let kan komme til at bekrige hinanden.

I compiler-gruppens tilfælde skulle ledelsen have gjort det klart for os, at vores kunder både var computer-markedet og servicecentrene. Vi skulle sætte os ind i deres behov og finde på geniale løsninger der støttede disse behov.

4 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 (1)

Log ind eller opret en konto for at skrive kommentarer