Jeg fikk en liten smak av programmering mens jeg var på førstegangstjenesten, og ble umiddelbart hektet.
Før jeg dro i militæret, hadde jeg så vidt startet på realfagsstudiet på Universitetet i Oslo, og bestått eksamen i grunnkursene i matematikk: FO 1-2 og Ma0.
Våren 1971 var jeg tilbake på Universitetet og tok mitt første kurs innen databehandlingen: DB0, et begynnerkurs i FORTRAN programmering.
Programmeringen skjedde med hullkort.
Slik fungerer et hullkort
Du skrev først programmet ditt på kladdepapir. Når du syntes det så bra ut, gikk du til puncherommet og stilte deg i kø for å vente på en ledig punchemaskin.
Punchemaskinene så ut som en diger skrivemaskin, og når du brukte tastaturet på den, lagde den hull i hullkortene.
Et hullkort er en papplate med 80 kolonner og 12 rader, og ble brukt som et binært lagringsmedium. Fravær av et hull representerer tallet «0», mens et hull representerer tallet «1».
Hullkombinasjonen i én kolonne representerer ett tegn, og ett hullkort representerer én linje i programmet ditt.
Registrerte du et feil tegn, måtte du kaste hele hullkortet, det var ikke mulig å tette igjen hullene. Punsjemaskinen printet også det du registrerte øverst på hullkortet, slik at du kunne lese hva du hadde punchet.
Operatør kjørte programmet
Når du var ferdig med å punche programmet ditt, hadde du en hel kortbunke.
Trengte du noe inputdata, punchet du disse på egne hullkort som du la bak programmet. Til slutt punchet du noen styrekort som du la først i bunken, og et end-of-file kort som du la helt bakerst i bunken.
Så puttet du hele kortbunken din i en eske merket «Til kjøring», sammen med programmer fra andre studenter. To ganger om dagen kom en operatør og hentet esken, tok den med til maskinrommet og sendte hullkortene gjennom kortleseren.
Neste gang han kom tilbake, la han hullkortene i en eske merket «Fra kjøring». I tillegg hadde han med utskriftene fra kjøringene på store «listing»-ark.
Debugging på hullkort
Ved første forsøk hadde du gjerne noen punche-feil; du hadde eksempelvis skrevet en feil bokstav. Da måtte du skrive hele dette kortet på nytt, og legge det inn på riktig plass i stedet for kortet som hadde feil.
«Det tok gjerne minst en uke å få kjørt gjennom et program.»
Når du hadde fått rettet alle punchefeilene, hadde du gjerne noen syntaks-feil. Du hadde skrevet noe som ikke var tillatt i programmeringsspråket, og kompilatoren ga deg feilmelding. Feilen måtte rettes ved å bytte ut de kortene som hadde feil.
Deretter hadde du muligens run-time feil, noe gikk galt under selve kjøringen. Dette kunne eksempelvis være at programmet ikke fant input-data.
Men til slutt fikk du endelig belønningen; programmet kjørte feilfritt og du fikk se resultatene fra kjøringen.
Det tok gjerne minst en uke å få kjørt gjennom et program. Og det ble ganske hektisk når fristen for godkjenning av obligatoriske oppgaver nærmet seg. Da brukte du lang tid på korrekturlesningen for å sikre at du ikke mistet en kjøring på grunn av en dum punchefeil.
Klippekort fra T-banen
En student hadde, sannsynligvis for moro skyld, lagt et klippekort fra T-banen inn blant hullkortene. På de tider klippet betjeningen på T-banen hull i klippekortene, så man kan jo si at dette også var en slags hullkort.
Men klippekortet var mindre og tykkere enn et hullkort, og det ble fullt crash på kortleseren. Mange kort i flere bunker ble krøllet og kunne ikke leses.
Eierne av disse bunkene mistet denne kjøringen og måtte rekonstruere programmet sitt.
Slik koda Per-Arne (70) på 70-tallet
Esken falt i gulvet
En gang hadde operatøren vært uheldig, og mistet hele esken i gulvet på vei til kortleseren. Hullkortene fra diverse jobber havnet hulter til bulter, og ble levert tilbake i en stor haug.
Jeg var etter forholdene relativt heldig, da jeg akkurat da brukte et sjeldent programmeringsspråk som ingen av de andre brukte. Derfor var det enkelt å identifisere hvilke kort som var mine. Men jeg fikk jobben med å sortere dem i riktig rekkefølge.
De øvrige måtte gi opp å sortere ut sine egne hullkort. De ble nødt til å punche alle kortene på nytt, i heldigste fall hadde de en utskrift fra tidligere kjøring som hjelp.
Slå av printen på punche-maskinen
En av opplysningene vi måtte oppgi på første styrekort, var max CPU-tid jobben kunne bruke. Vi studenter skulle sette denne til 1 (ett minutt), mer enn dette fikk ikke vi lov å bruke, og operatøren sjekket dette før han kjørte jobbene våre.
Ett minutt skulle være tilstrekkelig ved god programmering av alle obligatoriske oppgaver, men vi mislikte denne begrensningen som avbrøt dårlig programmerte jobber uten annen informasjon enn at jobben brukte for lang tid.
«Etterpå brukte vi en svart kulepenn til å skrive tallet 1 på den ledige plassen.»
Så fant vi et smutthull: Operatøren sjekket kun hva printen på kortet viste, ikke hvilke hull som var punchet. Og det var en bryter på punchemaskinen som kunne slå av printen.
Vi slo derfor av printen når denne parameteren skulle oppgis, punchet 9, og så slo vi på printen igjen. Etterpå brukte vi en svart kulepenn til å skrive tallet 1 på den ledige plassen.
Styrekort på punche-maskinen
Det var mulig å forenkle punche-abeidet noe ved å bruke et styrekort.
Dette var et hullkort du først punchet med noen styrekoder, før du festet det på en trommel i punchemaskin. Når du punchet de vanlige hullkortene, roterte trommelen i takt med din posisjon på hullkortet og kodene ble lest.
Slik hacka vi i Norge på 90-tallet
Du kunne eksempelvis legge inn koder for å:
- Ved nytt hullkort, hopp automatisk til posisjon 7 (praktisk ved FORTRAN-programmering)
- Ved nytt hullkort, hopp automatisk til posisjon 8 (praktisk ved COBOL-programmering)
- Etter posisjon 72, last inn neste hullkort (de 8 siste posisjonene på hullkortet var kun til kommentarer, og ble ikke lest som programkode)
- Kopier alt innhold fra foregående hullkort (aktuelt når kortene var brukt mange ganger, var blitt slitne og kunne forårsake crash i kortleseren)
Det var en egen bryter for å slå aktiveringen av styrekort av eller på.
Når vi ble veteraner, brukte vi styrekort for å ha moro med ferskingene:
Vi la inn et styrekort som automatisk kopierte alt innhold fra forrige hullkort, for deretter å laste inn et nytt hullkort og fortsette kopieringen på dette. Og det kortet som skulle kopieres, hadde vi klargjort med hull i alle posisjoner.
«Et forferdelig leven, nærmest som en mitraljøse.»
Etter at punchemaskinen var gjort klar, slo vi av hovedbryteren. Når offeret kom og slo på hovedbryteren, startet spetakkelet. Alle kolonnene på et kort ble perforert, neste kort ble lastet ned og det ble også perforert. Et forferdelig leven, nærmest som en mitraljøse.
Det stakkars offeret fikk slått av hovedbryteren og så seg forskremt omkring. Vi veteraner brast i latter, så offeret skjønte at vi drev gjøn med ham. Vi ba om unnskyldning, og viste ham hvordan styrekortene fungerte.
Punche-dame
Den gang var "punche-dame" en egen yrkestittel.
Diablo-utvikleren:
- Kult at koden lever videre!
Større bedrifter hadde ansatt punche-damer for å registrere opplysninger som skulle leses inn i datamaskinen. En parallell til datidens sekretærer, som mottok håndskrevne notater fra funksjonærene og skrev disse på skrivemaskin.
En bedrift jeg jobbet for, hadde punche-damer som skulle registrere lønnsinformasjon. Den faste månedslønna til medarbeiderne var grei, men alle avvik fra det ordinære måtte registreres, herunder overtid og variable tillegg, som det var mye av.
Rutinen var at mellomlederne leverte lister med alle avvikene tre dager før månedslønna skulle utbetales. Det ble tre heftige dager med mye overtid for punche-damene.
Men deretter var det 3,5 uke med svært lite å gjøre, da slo de i hjel tiden med strikking.
Livet som norsk COBOL-utvikler på 80- og 90-tallet
Per-Arne (70) om timeslang kompilering, ukeslang debugging og år 2000-problemet.