Som programmerare 1966-1982

Programmerare 1966-1982

Stockholms Spårvägar 1966-1970

På trafikavdelningen 1966, några månader innan jag fyllde trettio, annonserade bolaget efter anställda som var intresserade av att byta arbetsuppgifter och ville bli programmerare. Det lät kul att pröva på något nytt. Det handlade väl om att koppla kablar? Jag hade hade hört talas om kablar och matematikmaskiner, som jag felaktigt trodde var samma sak som datamaskiner. Många idag tror lika fel, kanske på grund av att datorerna utvecklades från matematikmaskinerna.

Förresten kände jag till en del rent teoretisk om datamaskiner. Min fru hade börjat en utbildning som skulle leda till programmerarjobb. Jag sökte jobbet. En del i uttagningen var att genomgå en test anpassat för programmeraryrket. Testen bestod bland annat av talserier och hade stora likheter med det test som jag tidigare gjort vi den militära mönstringer.

1401
Maskinvaran
Maskinen hade i orginalutförande ett RAM-minne typ ferritkärnminne på en kilobytes. Men hos
spårvägen hade man kompletterat den med ett extraminne på 15K,så vi hade hela 16KB att arbeta i.
För in och utmatning fanns främst hålkortsläsare, hålkortsstans och en radskrivare typ 1403.
Denna sistnämnda hade stor kapacitet och användes långt in på 70-talet. Datorn hade också
fyra för den tiden snabba bandstationer. Operatörsutrustningen bestod av tangentbord och
skrivare. Den liknade mest en elektrisk skrivmaskin.

Programvaran
Maskinens programmeringsspråk heter autokoder. Program framställdes genom assemblering.
Det gick till så att man först laddade in översättningsprogrammet genom att lägga det i
kortläsaren och sedan trycka på LOAD-knappen. Därefter tryckte man på en annan
knapp för att läsa in den stansade källprogramkortbunten som då översattes till en ny
hålkortsbunt med ett laddbart program i maskinkod. I stället för operativsystem fanns det ett
särskilt avsnitt i programmet som skötte in och utmatning, IOCS, Input Output Control System.
Efter assembleringen var det bara att testa hålkortsbunten genom att ladda in den och testa
med testdata på hålkort för att den vägen åstadkomma en driftklart program. Ordet program har
många betydelser. Jag ser det helst i en betydelse som också innefattar dessa sextiotalsprogram.

Introduktionen
Utbildningen till programmerare började med en snabbutbildning i hur man sorterar hålkort. All
databehandling hos IBM byggde på dessa små pappskivor. Men det fanns också magnetband.
Den månadslånga utbildning hos IBM på Ankdammsgatan i Solna hette IBM 1401 kort och band.
Samma kurs gick förresten författaren J M Coezee i London ungefär sex år tidigare. Det
han beskriver i sin bok “Ungdomsår” stämmer väl med mina erfarenheter.

Efter utbildningen kom jag till gruppen för programunderhåll. Den sysslade främst med
att ändra i gamla program. Jag fick dock främst bygga nya. Nedan följer en beskrivning av
några programmerigsuppdrag, som jag minns dem.

Göra färdigt
Min första uppgift blev att skriva färdigt ett nästan färdigt program. Jag fick en genomgång av
uppgiften, hålkortsbunten och programlistan men fattade ingenting förrän jag vaknade till nästa
arbetsdag. Då förstod jag att lösningen var att bortse från allt som hade gjorts efter att
avsikten med programmet presenterats och börja om från början.

Statistik
Ett program för att ta fram ett antal listor i olika utseenden och olika sorteringsordning gjorde
man normalt så här. Först sorterades hålkorten i en hålkortsorterare. Sedan lästes kortbunten in
och första listan skrevs ut. Sedan sorterades hålkorten i en hålkortsorterare i en ny ordning,
kortbunten lästes in och andra listan skrevs ut. Så fortsatte man tills alla listor skrivits ut
medan den dyrbara maskinen stod still och operatörerna sprang (nästan) mellan datamaskin och
sorteringsmaskin. Det fanns ingen hårddisk att sortera på och alternativet bandsortering med
programmet “sort7” var sämre. Då måste man ju byta program mellan sorteringar och listningar,
vilket medförde ett ännu mer tidsödande operatörsarbete.

Jag fick i uppdrag att göra ett program som gjorde sorteringen i RAM-minnet.

Först konstruerade jag en sorteringsmetod. Senare fick jag genom datalitteraturen veta att den
använts tidigare och kallades “byta grannar”. Nästa problem var att hålla ner storleken på en
handfull utskriftsrutiner och på denna sorteringsrutin så att alltihop rymdes tillsammans
med IOCS-en inom 16 KB. Det gick bra om man begränsade antalet möjliga hålkort till fyrahundra.
Antalet kort översteg ytterst sällan tvåhundra. Programmet var alltså användbart men det gamla
måste finnas kvar för att klara extrema situationer.

När programmet var klart och skulle köras i produktion för första gången uppstod ett nytt problem.
Maskinoperatörerna var ju vana vid att kortläsare, radskrivare eller bandstationer hela tiden var igång när
ett program kördes. När korten lästes in till detta program uppstod det en kort tystnad då maskinen
sorterade i minnet. Tystnaden var dock tyvärr tillräckligt lång för att operatörerna skulle uppleva
det som feltypen loop och bryta körningen.

Så småningom förstod de att en dator kan arbeta tyst. En av dessa operatörer, Gunnar Sjöberg,
blev så småningom teknikchef på L-data och anställde mig där som chef för
 systemprogrammeringsgruppen.

Om en liknande situation kan man läsa i Hannes Alfvéns bok “Sagan om den stora datamaskinen”.

Spoolsystem?
Listor skrevs normalt ut från ett bearbetande program som ofta samtidigt läste hålkort och
magnetband. I detta fall var bearbetningstiden kanske två timmar medan listan som sådan kanske
kunde skrivas ut på femton minuter. På den här tiden förekom det listor med möjlighet till
kalkerpapperskopior. Men behövdes de fler kopior än den möjligheten gav måste man normalt köra
om hela körningen. Därför fick jag snabba upp framtagning av de återstående listorna med att
samtidigt med printningen skapa samma lista på ett magnetband. Den listan kunde sedan enkelt
kopieras från bandet till radskrivaren. Därigenom sparades ungefär en timmes maskintid.

Patchning
Ett program som fanns långt innan jag började arbeta med autokoderprogrammering var det
som skrev ut tidtabeller för hållplatsstolpar. Programmet används än i dag men på en annan
plattform. Det fungerade för alla linjer utom en, en busslinje med varannantimmestrafik. I stället
för att ändra programmet byggdes det som entimmastrafik. Sedan gick jag in i den laddbara
hålkortsbunten och ändrade utskriften av de klockslag som inte skulle vara med och ändrade en
en kopiering till en NOP, no operation. Sånt kallas patchning och görs än i dag men nu i
laddmoduler på hårddisken.

Avtalsändringar
De viktigaste programmeringsjobben gällde förstås stöd till företagets verksamhet. Programändringar
i samband med nya löneavtal var alltid brådskande. Förhandlare tänker sällan på att deras
kompromisser och innovationer skall gå att räkna ut och betalas ut. Som jag minns var vi ganska
många som samlades nere i datorhallen när ett löneavtal var klart för att arbeta med hålkortsbuntar.
För övrigt kallades datorhallen ännu på den tiden för “tabben”. Detta på grund av att den en gång i
tiden dominerats av en föregångare till datamaskinen, tabulatorn.

360-30
Planering, utbildning och organisation
Frågan var bara hur länge vi skulle fortsätta att arbeta med denna tio år gamla maskintyp.
Vi började förbereda för övergång till en av de mindre modellerna i IBM senaste maskinserie, S360.
Företaget behövde någonting att växa i.

Under väntetiden gick vi ett antal kurser hos IBM. Vi började med en lokal kurs, alltså en som
gick i Spårvägens egna lokaler, och handlade om utrymmesberäkning på skivminne, sådant som idag
kallas hårddisk. Den hölls internt av vår stödresurs från IBM, Lars Jerndal.

Efter denna kurs blev det klart jag skulle bli närmast ansvarig för maskinbytet med stöd av Lars J.
Min uppgift blev att anpassa operativsystemet till spårvägens IT-miljö.

För att klara det jobbet fick jag gå IBM-kurser i operativsystem, assemblerprogrammering och det som
då kallades för serviceprogram. Alla på systemavdelningen fick också gå en internutbildning i det
högnivåspråk som systemchefen valt, PL/I. Den kursen hölls av en IBM-expert som hette Björn
 Magnerud.

Jag skulle arbeta på det så kallade metodkontoret som tidigare hade haft hand om
programmeringsrådgivning. Just för den detaljen utsågs en nyanställd mycket duktig
programmerare utbildad på Stocholm Stads Handelsskola. Han fick uppdraget att arbeta med
programmeringsteknik men blev kvar i systemutvecklingsgruppen.

Metodkontorets chef var en barnledig kvinna som inte förväntades återkomma i befattningen.

Alltså bestod metodkontoret av en enda medarbetare, jag, som också fick sköta en del av de
administrativa uppgifter som en gruppchef normalt utförde.

Sammanfattningsvis hade jag fått en kul och utmanande arbetsuppgift.

Maskinbytet 1968
Den nya maskinen installerades bredvid den gamla. Det fanns gott om plats för denna så kallade
stordator. Så stora var inte de mindre modellerna. Jag installerade operativsystemet,
den mindre modellen, DOS/360. Detta var klart på ett par dagar. Sedan följde en besvärligare
uppgift, att installera en 1401-emulator. Alla bolagets applikationssystem var skrivna i
autocoder för 1401-system. Emulatorn var ett program som emot 1401-programmen uppträdde som
om det var en 1401-maskin. Kanske skulle man kunna använda sjuttiotalsterminologi och kalla det
för en virtuell maskin. Skillnaden mot senare tiders virtuella maskiner var att det bara gick att
köra en emulering i taget, i varje fall i denna dator. När emulatorprogrammet var installerat
och testat, var det bara att flytta över all produktion.

Ungefär två veckor efter att den nya maskinen lyfts in lyftes 1401-maskinen ut. Enligt
systemchefen Lars A Källén var det världsrekordtid. Detta upplevde jag då som överdrift.
Det hade ju varit så mycket strul med emulartorn.

Nu efter alla år förstår jag att det egentligen gick ovanligt bra och att det alltid uppstår
installationsproblem med en del programvara i 360-370-390-miljöerna.

Spårvagnsunderhåll
Ett program som var tungarbetat för operatörerna var ett som höll ordning på hjulpar och deras
underhåll. Registret innehöll alla hjulpars kondition och till vilken spårvagn de var kopplade
eller om de vid det tillfället inte var monterade. Underhållet registrerades i ett stort
autucoderprogram med programmerade stopp för sortering av hålkort. Dessutom fanns det fel i
registret som man måste rätta manuellt. Min uppgift blev att skriva om programmet så att
det ändrade i registret när fel påträffades och så att bearbetningarna snabbades upp.

Min lösningen blev att skriva sju små snabba program som skulle köras efter varann med åtta
sorteringar på skivminnet i mellanliggande steg.

En uppdragsgivare, även en mycket datakunnig sådan, kan ofta beställa ett program i tron att det
är bästa lösningen får självklart inte hindra en uppdragstagare att hitta en bättre lösning.
De programmerare som bara hackar kod utan att förstå syftet med koden är inga bra programmerare.

Det nya systemet gick betydligt snabbare än det gamla programmet.Tekniken kallades satsvis
 bearbetning.

Librarian
Vi arbetade för övrigt vidare med 1401-system och hålkort. Efter en tid fick vi kontakt med en
produkt som hette Librarian som i Sverige på den tiden representerades av Christer Jäderlund.
Librariansystemet innebar hos oss att vi kunde läsa in alla källprogram på skivminne och sköta
programunderhållet därifrån. Man kunde till och med söka efter en teckensträng på allt som fanns
lagrat på Librariandatabasen. En gång gjorde vi det. Det tog ungefär sex timmar att hitta programmen.
Processorer och hårddiskar är ju betydligt snabbare idag.

Körbara program, eller laddmoduler som de kallades, i maskinkod men byggda med hjälp av 360-assembler
eller PL/I låg alltid på de särskilda diskutrymmen som operativsystemet anvisade. Däremot var ju
laddmodulerna för 1401 från början vanliga datafiler som DOS/360 såg det. Men det gick bra att
lägga data från dessa hålkortsbuntar med laddprogram från 1401-systemet på Librarian.
1401-emulatorn gick på så sätt att köra utan pappkorten. Detta som låter självklart idag var ett
stort tekniskt framsteg på 1960-talet.

GRASP
Från början kördes utskrifter från programmen rad för rad på 1403-skrivaren. Men en representant
från ett företag som hette Cybernetics, Lars Laurén, sålde och installerade en produkt som gjorde
att utskrifterna från programmet skickades till ett utrymme som programmet GRASP tömde
kontinuerligt så att skrivaren kunde skriva ikapp när inga skrivrader skickades. Blev däremot
utrymmet fullt reglerades det automatiskt genom att programmet minskade farten.

Metodkontoret
Metodkontoret hette i förkortningsspråk OSM. Detta stod för Organisationsavdelningen >
Systemsektionen >Metodkontoret. Inom systemsektionen fanns systemutveckling, programunderhåll
och metod. Produktionen leddes av Hans Cederberg och hörde till en annan avdelning. Så småningom
tillfördes OSM resurs i form av en chef med matematikutbildning på universitetsnivå. Han tog
hand om en del rutinuppgifter så att jag fick mer tid till att anpassa operativsystemet till
verksamheten. Nu började folk i spårvägsbolaget tro att jag också var matematiker. Jag hade
ju en matematiker som chef och var expert på “matematikmaskiner”.

Kanske var jag matematiker. I så fall kanske jag inte heller var den enda matematikern med
“icke fullt godkänd” i matematik i slutbetyget från gymnasiet.

Dataföreningen
Eftersom jag arbetade nära produktionen deltog jag 1969 tillsammans med Hans Cederberg och Gunnar
Sjöberg i en konferens kring organisation av driften i dataföreningens regi. Denna gång hölls
konferensen i Foresta på Lidingö i samband med Dataföreningens årsmöte.

Oljekonsumenterna 1970-1982

Motiven
Det var trivsamt på Stockholms Spårvägar eller Storstockholms Lokaltrafik, SL, som det fick heta
efter ett antal politiska turer. Jag hade tre barn. Lönen var klart bättre än jag haft som
spårvagnskonduktör och bättre än tjänstemän utan universitetsutbildning på SL normalt hade.
Men jag förstod att det betalades bättre på andra företag. Oljekonsumenternas förbund annonserade
1970 efter en operativsystemspecialist. Konsumentkooperation var någonting som tilltalade mig.
Jag sökte och blev antagen.

Det enda tveksamheten att anställa mig var, enligt vad jag fick veta efteråt, att OK tyckte att min
lön inte tydde på att jag verkligen kunde vara systemprogrammerare. Men det redde ut sig. Min
referens, Sixten Björndahl, förklarade att principen för lönesättning på SL var
“en gång spårvagnskonduktör, alltid spårvagnskonduktör”.

Lars A Källén konstaterade bara när jag sade upp mig att då fick han väl försöka få tag på någon
civilingenjör. På sjuttiotalet trodde man mycket på KTH.

Utbildning och konferenser
Arbetet som systemprogrammerare krävde breda kunskaper. Kanske är det fel att formulera behovet
så.Kanske det krävdes djupa kunskaper inom många områden.

Källén på SL hade en gång rekommenderat mig att satsa på datorkommunikation. På OK hade vi ett
kommunikationssystem i huset och kom ganska snart att öppna en förbindelse till Scanraff i Lysekil.
Jag behövde och fick utbildning hos IBM i programmering både inom det äldsta kommuniktionssystemet
TCAM, Telecommunication Acess method och VTAM, Virtual Telecommunication Access Method. Detta
senare utvecklades till SNA, System Network Architechture som ännu i slutet av nittonhundratalet
existerade parallellt med TCP/IP. Den bästa och mest övergripande kursen i ämnet datakommunikation
var den som jag gick hos STF Ingenjörsutbildning.

Men viktigare än kurser var det vi systeprogrammerare lärde av varandra. Sådant främjades genom
regelbunda träffar inom användarföreningar som till exempel IBM Nordic Guide. Där deltog jag
under OK-tiden i CICS Guide och Teknikchefs Guide.

Det fanns också en användarförening kring Librarian. I den var min tidigare chef i
programunderhållsgruppen på Spårvägen, N O Eriksson, den drivande personen.

Applikationssystemen
Medlemsregistret
När jag kom till OK hade företaget påbörjat arbetet med att förenkla registerhanteringen.
Tidigare hade registergruppen arbetat med tunga pärmar. Nu installerades terminaler med bildskärm
och tangentbord. De var kopplade till datamaskinen med modem för kommunikation på korta avstånd.

Gruppen fanns på samma våningsplan som datamaskinen, systemutvecklingsgruppen och vi som med
dagens terminologi skulle kallats tekniker. Detta att vi alla satt i samma kontorslandskap innebar
många fördelar. Systemfolket kunde få tips om vad på skärmen som var svårläst och kunde
ändra direkt, vi som planerade ändringar i maskinvaran kunde direkt rådgöra med användarna.
Det var i början bara registergruppen som var direktkopplade till datorn. De ville helst ha Alfaskop
för att gult och brunt var mindre tröttande för ögonen än färgerna i IBM´s modell.

Val av skivminne däremot kunde vi teknikansvariga diskutera med datoroperatörerna som på den
tiden bland annat hade att byta skivpackar. Registret var stort, över hundra megabyte. Det
blev så många packar att skivstationerna fyllde ett normaltstort rum. Datorn liksom alla dessa
skivminnen stod i särskilda rum. Det besparade oss människor buller samtidigt som företaget slapp
hålla oss anställda med den behagliga temperatur som maskinerna krävde. För övrigt köpte vi
skivminnen från Memorex som kanske var något billigare än IBM´s och hade finesser som underlättade
systemprogrammerarens arbete. Man kunde se var på skivminnet som läsning eller skrivning pågick.
Bra bland annat i samband med uppdatering 1401-emulatorn underlättade detta felsökningen.
Också på OK fanns 1401-system i drift. Här hade man haft skivminne till 1401-maskinen.

Min slutsats av lokalresonemanget är att det är bättre att systemutvecklare, systemprogrammerare
och tekniker sitter i samma kontorslandskap är att till exempel teknikerna finns i Rumänien,
systemutvecklarna i Indien och användarna i Kalix.

SILOF
Statistik- Inköp-Lager-Order-Fakturering var ett system som skulle underlätta kontorsrutinerna
på OK. Det köptes in från ett på den tiden stort konsultföretag som hette Datema. Vår datachef,
John Silverbrant var så långt jag vet den som var närmast ansvarig för beslutet. Men jag kan ha
fel.Ofta tas ju sådana här beslut alltför högt upp i organisationerna och ofta utan tillräckligt
samråd med teknikkunniga. Min närmaste chef hette Bo Skoglund. Han ansvarade för programmering
och hade tidigare installerat operativsystem och dessutom själv byggt OK´s bokföringssystem.
Vad jag minns var han inte positiv till SILOF-lösningen. Men när John Silverbrant hastigt avled
blev Bo Skoglund chef för all datorverksamhet inom OK-förbundet. Även om jag då fick en annan
gruppchef, Sune Wallgren, hade jag hela tiden mycket nära samarbete med Bosse. Det var en kul
och lärorik tid som följde. Det blev många kurser på IBM eftersom mitt jobb krävde att jag skulle
kunna mycket om all programvara på företaget. Jag fick också deltaga i verksamheter inom
användarföreningar. Jag fick till exempel delta i en resa i till Sicobmässan i Paris.
Resan anordnades av Svenska Dataföreningen.

PLS
Ett annat stort utvecklingsprojekt som genomfördes var det PenningLösa Systemet. Tanken var att
undvika rån på bensinstationerna genom att flera, helst alla OK-medlemmar har betalkort och
därigenom minska tillgången på kontanter i pumpar och kassor. Det betydde mycket för
datoriseringen som sådan och gav mycket arbete åt avdelningen.

Den maskinella inläsningen av köpnotor i den stora konstiga optiska läsaren klarade
bara att läsa av ungefär nio tiondelar av köpnotorna. Så en tid var nästan alla men inte jag
på dataavdelningen engagerade i manuell registrering av köpnotor. Jag hade istället desto
mera att göra med systemprogrammen till den nya maskinvaran.

Systemprogram
DOS/360
På OK användes samma operativsystem som på Spårvägen. Jag kom snabbt in i arbetet och fick
huvudansvaret för underhåll och utveckling av detta. Vi var två i gruppen, jag och en ung man
som utbildats till sjökapten. Han var mycket entusiastisk för att arbeta maskinnära och
tillbringade många timmar i veckan utöver ordinarie arbetstid på jobbet. Sådant var vanligt på den
tiden. Själv hade jag en familj som gjorde att jag så långt det var möjligt undvek
övertidsarbete. Tyvärr drabbades sjökaptenen av en hjärntumör som gjorde att jag under en tid
blev ensam systemprogrammerare.

På OK användes Cobol som programmeringsspråk. Det var inte på den tiden lika generellt
användbart som PL/I. Därför fick jag utföra en del programmering också i assembler. Cobol
hade jag ingen utbildning i. Det gick ändå ganska lätt att använda med hjälp av handböckerna,
som i den miljö jag har arbetat i alltid kallas manualer.

Beträffande maskinens kapacitet är det ett annat sätt att se på det när användare arbetar direkt
mot maskinen via terminaler än i en miljö där enbart satsvis bearbetning bedrivs. När svarstiderna
blev för långa blev det därför dags att byta till en kraftfullare datamaskin.

Direkt efter en sådan uppgradering blev svarstiderna för terminalanvändarna ännu sämre samtidigt
som de satsvisa bearbetningarna snabbades upp. En lösning på detta problem hade varit att flytta
dessa till en annan tid på dygnet. Detta hade inte varit populärt hos hos operatörerna eller hos
andra anställda och kunder som väntade på sina listor.

Lösningen blev en annan. DOS var ju ett operativsystem som var byggt för mindre system. Alla
operativsystemanrop, så kallade SVC, supervisorcall, använde ett gemensamt utrymme. Detta skedde
vid varje läsning och skrivning på magnetband. När terminalhanteringsstemet behövde göra ett
operativsystemarop var därför i regel detta gemensamma utrymme i regel upptaget. Lösningen blev
att jag med hjälp av ett ingrepp i operativsystemet fick bromsa hastigheten på bandstationerna.
Hastigheten blev trots det något bättre än före maskinbytet medan terminalsytemet blev betydligt
snabbare. Men de tekniskt kunniga tyckte förstås att detta var att stympa maskinen.

Också på OK fanns GRASP. Här hanterades det manuellt av operatörerna och kontrollerade inte bara
radskrivaren utan också kortläsaren. Operatörernas ambition var av tradition ofta att snabba upp
de satsvisa bearbetningarna så mycket som möjligt. Därför fanns det de som överutnyttjade GRASP
och därigenom störde terminalbearbetningarna. Det bromsade också de satsvisa bearbetningarna.

Detta är en första illustration till en arbetsuppgift för en systemprogrammerare som kallas
tuning och som sedan blev en väsentlig del i mitt arbete. Denna gång bestod tuningarbetet
i att instruera operatörerna hur de skulle hantera GRASP.

Faster
Faster hette det IBM-system som OK använde för att hantera det onlinesystem som byggts för
medlemsregistret. En av mina första uppgifter på OK var att uppgradera detta system.

OS/MFT
SILOF-systemet var baserat på ett transaktionshanteringssystem som hette Customer Information
Control System. Det fanns ännu inte tillgängligt för DOS. Det skulle det bli något år senare.
Men OK hade inte tid att vänta utan beslutade att byta plattform eller operativsystem som det
kallades då i början på nittonhundrasjuttiotalet. Det nya operativsystemet hette OS/MFT. Jag gick
en del intressanta kurser i ämnet. Samtidigt påbörjades installationen på ett antal skivpackar.
Vi lämnande in packar och program för körningen i en lucka på IBMs datacentral på Ladugårdgärde.
Körningsdokumentationen angav klart att det var en tidsödande körning. Ändå fick vi i början
tillbaka materialet med felbeskrivningen LOOP. Det stansades ju inga hålkort och skrevs inga
magnetband. Ingen radskrivare skulle rassla förrän efter någon timme. Då hade operatörerna för
länge sedan stoppat “loopen”. Skivminnet jobbade ju lika tyst som hårddiskarna på en PC. Nästa
steg var daglig test på plats i OKs datahall. De utfördes som timslånga körningar vid lunchtid
då registergruppen hade lunchpaus. Sedan när systemet var klart att köras i produktion lade vi in
ett DOS-pass vid lunch i stället för att köra och ändra program som inte var klara för MFT.
Också denna gång hade vi problem med gamla 1401-program. Emulatorn för MFT hade många
brister som måste rättas till. 1401-emulatorn liksom nästan alla andra program vi inte skrev
själva kom från maskinleverantören IBM. Nästan all programvara var gratisprogramvara på den
tiden. Programmerare från olika företag bytte gärna programfiler med varandra. Då gällde den
idag kriminella åsikten att goda råd är gratis.

CICS
Transaktionshanteraren liknade till strukturen det då mest avancerade operativsystemet från IBM,
OS/MVT. Operativsystemutbildningen inför bytet hade avsett MVT så jag kände igen mycket från den
utbildningen när jag gick de kurser som behövdes för att installera, underhålla och tuna
programpaketet. CICS skulle ju ganska snart bli tillgängligt också för DOS. CICS gick kring
millenieskiftet också att använda i ett annat operativsystem från 1960-talet som heter
Unix och därigenom också i Linus Torvalds gratisoperativsystem Linux.

En transaktionshanterare presenterar data med hjälp av mallar som ibland bara visar data, ibland används
för att ändra och lägga till data i databasen. Dessa mallar programmerade vi själva på OK. När det
gäller Silofsystemet gjordes förstås mycket av programmeringen av Datema. Själva databasen hanterades
av Datema- och OK-skrivna program. Redan då fanns ett databashanteringssystem som hette IMS.Till
detta hörde en annan transaktionshanterare. Men som CICS-installation fick vi hantera databasen
utan något färdigt system genom att använde accessmetoden och dataorganisationsmetoden ISAM,
Index Sequential Access Method. CICS-systemet var av version 0, utgåva 0 och uppdateringsnivå 0.
Det kallades därför trippelnollan.

Librarian Online
Librariansystemet byggdes på med en onlinedel. Detta effektiviserade programmeringsarbetet väsentligt.
Från början stansades vanligtvis program på hålkort som lästes in i Librariandatabasen. Men ändringar
i källkoden, kompileringar som motsvarade assembleringar och översatte Cobolprogrammens källkod
till maskinkod och testmaterial kunde framställas direkt i Librarian av programmeraren. Denne
skickade sin test direkt till maskinen och kunde också läsa testresultatet direkt på sin bidskärm.

Virtualiseringen
Först i början av sjuttiotalet lanserade IBM virtuell minnesteknik. Den hade sedan länge använts
på andra plattformar. En av pionjärerna på området var för övrigt författaren J M Coetzee. Han
hade arbetat i ett virtualiseringsprojekt på Cambridge University i England med en dator som hette
Atlas. Tanken bakom virtualiseringen var att programmen kunde arbeta i ett större minne än
RAM-minnet. Detta åstadskoms genom att en kombination av RAM-minne och skivminne tillsammans
skapade ett arbetsminne som var större men något långsammare än ett lika stort reelt minne. För att
uttnyttja denna möjlighet krävdes en ny maskintyp som IBM kallade S/370. Det krävdes också ett
operativsystem som stödde den virtuella tekniken. OK valde OS/VS1 det som mest liknade MFT.
Men virtualiseringen möjliggjorde inte bara virtuellt minne, inom operativsystemet. De fanns
också någonting som hette VM, Virutual Machine. Detta innebar att vi i samma fysiska maskin
kunde ha fler virtuella. I OKs fall skulle vi kunna köra produktion som vanligt, ha en maskin
för test av nya system och en för test av operativsystem. För att hantera VM krävdes en virtuell
maskin där ett icke virtuellt operativsystem, CMS skulle köras. Detta var från början ett system
byggt på något av de universitet som heter Cambridge. CMS stod från början för Cambridge
Monitoring System och var det verktyg som användes för underhåll av VM.

I datalitteraturen benämns ofta VM/CMS, eller VM som operativsystem. Detta är inte korrekt.
VM är ett system för att dela upp en maskin i ett antal virtuella maskiner.

För OKs del var inte VM lönsamt. Vi skaffade i stället en IBM-kompatibel dator från ett företag
som hette NAS, National Advanced Systems.

MVS
I och med att produktionsvolymerna ökade byttes maskinerna nästan årligen mot kraftfullare
modeller. Detta följde i stort sett Moores lag som säger att kapaciteten ökar med trettio
procent årligen. Det blev dags att byta till en modell med två processorer. Den tekniken
krävde att vi bytte ut operativsystemet mot det mest avancerade inom IBM-området, MVS.
Därigenom fick vi också tillgång till hjälpmedel som förenklade såväl systemutvecklingen
som operativsystemunderhållet.

TSO/ISPF
Med hjälpav TSO, Time Sharing Option, och ISPF kunde till exempel programmerare starta kompileringar
och tester på ett enklare sätt än vad som var möjligt med Librarian Online. ISPF innehöll bland
1900-talets bästa editor.

SDSF
Genom SDSF kunde man följa nästan allt som hände i maskin. Programmerarna kunde till exempel analysera
sina tester medan de utfördes, driftpersonal kunde styra om resurer och systemprogrammerarna fick en
värdefull inblick i hur jobb och transaktionshanterare fungerade tillsammans.

RACF
Möjligheten för ett antal tidsdelningsanvändare att skapa nya filer och ge dem vilket namn som helst
innebar också en ny typ av risk för systemets funktion. Namn och adress till alla filer registrerades
i kataloger som mycket liknade WWW’s system. Om alltför många byggde egna index på högsta nivån
kunde hela OK’s system få allvarliga problem. Den centrala filkatalogen skulle upphöra att fungera.
Risken för att göra egna högsta kvalificerare av okunskap eller illvilja var sannolikt liten.
Den stora felkällan var sannolikt rena skrivfel.

Vi behövde ett behörighetssystem. Hilding Landén från IBM gav oss snabb hjälp. Snabbheten var dock
ganska motvillig. I princip skall ju alla företagets resurser skyddas av ett sånt här system.
Men vi skulle sannolikt fått en allvarlig systemkrasch om vi avvaktat med RACF-installtionen tills
vi hunnit med en så kallad seriös genomgång av systemets resurser i behov av skydd. Vi skyddade i
stället bara den centrala filkatalogen. Jag måste göra mig till någon slags Superuser á la Unix.
Två ordspråk till mitt försvar för detta: “nöden har ingen lag” och “medan gräset växer dör kon”.

Som programmerare
Det fanns det något som kallades specialprogrammering i min arbetsbeskrivning. Det
innebar assemblerprogrammering och annat som krävde speciella kunskaper.

Dynamisk länkning
På MFT-tiden, då operativsystemet saknade virtuell minnesteknik, var det ibland problem med
att få arbetsminnet att räcka till. Vi förstod att det skulle vara bra om delar av programmet som
bara användes under en del av bearbetningstiden kunde läggas in i minnet när det behövdes och
plockas ut igen när det inte behövdes längre. En sådan metod skulle också ha den fördelen att
det skulle gå att kompilera om underprogram utan att sedan behöva länka samman dem med
huvudprogrammet. Det underlättade programadministrationen. De olika delarna kallades moduler,
även om de samtidigt var fullständiga program som gjorde anrop respektive anropades av
andra program.

Nu fann det tyvärr i varje fall inte i början på 1970-talet någon färdig funktion för detta
i Cobol. Därför konstruerade jag ett program i assembler som Cobolprogrammet kunde anropa.
Detta fick skicka med namnet på det program som skulle laddas in dynamiskt. Jag presenterade
det på ett möte med systemgruppen. Detta var mer än ett tekniskt hälpmedel. Det var ett sätt
att introducera modulprogrammering.

Omkring tjugofem år senare var jag med och installerade ett nytt faktureringssystem hos Telia.
Systemet var inköpt hos ett amerikanskt företag som hette AMS. Men här skickade Cobolprogrammet
ingen parameter utan man hade ett anropat-anropande-program för varje dynamisk modul. Det blev
omkring 160 program att produktionssätta i stället för ett.

Budgeten
När Bo Skoglund blev datachef blev han också ansvarig för budgeten på avdelningen. När han skulle
göra budgeten hade han en för mig obegriplig idé hur han skulle ta fram underlag från bokföringen.
Obegriplig i meningen hur det kunde bli en bra budget av underlaget. Däremot förstod jag precis
vad han ville ha fram. Detta var inte heller några problem att ta fram. Det blev ett enkelt
Cobolprogram som inte produktionssattes i vanlig ordning. I stället fick jag varje år deltaga
i budgetarbetet.

Kompletteringsstansning
På 1970-talet fanns det fortfarande filer på hålkort. Till datorn fanns också i regel kopplat
en enhet som kunde läsa och stansa hålkort och placera dem i valfritt stansfack eller läsfack.
Nu ville man med hjälp av datorn komplettera ett redan stansade kort med ytterligare hål.
Min hårdvarukunnige chef hade undersökt stansmaskinen och konstaterat att den kontrolläste
hålkorten sedan de passerat själva stansfunktionen. Därför borde det gå att stansa redan
stansade kort. Det borde finnas någon möjlighet för en assemblerprogrammerare att göra
något så tabubelagt som att göra ett program som kunde stansa i “begagnade” hålkort.
Jag skriver inte assembler bara för att det är så mycket roligare äm Cobol utan väljer
det språk som är effektivast. Cobol skall enligt legenderna inte vara särskilt maskinnära.

I verkligheten använder Cobol konstiga men väl dokumenterade instruktioner för att utnyttja
olika tekniska finesser i skrivare, kortläsare och stansar med hjälp av kombinationer
av orden write, read, punch, after, before och speciella siffer- och bokstavskombinationer.
Det var ovanligt med programmerare som förstod Cobols möjlighetet. Jag konstruerade
ett enkelt program för uppgiften och skrev driftdokumentation. Det blev många protester
typ “man kan bara lägga ostansade kort i stansfacket”. Datapersonal började redan på den tiden
skaffa sig förutfattade meningar om vad som gick och inte gick. Så småningom gick det i alla
fall att få dem att köra programtesten. De som varit med på testen hade sedan inga problem
att köra programmet i produktion. Men deras världsbild var förändrad.

CICS-programmering
Jag programmerade också en del för onlinemiljön. Syftet var främst att beskriva effektiva
metoder för bra svarstider och för att skapa program som var lätta att underhålla. Så små
program som möjligt underlättade programmeringsarbetet och gav effektiv kod. Men när det virtuella
minnet blev verklighet ändrades principerna delvis i varje fall i teorin. Jag hävdade att de små
programmen fortfarande var det bästa. Men det fanns också de som ville att programmen skulle
ta hänsyn till den rådande minnestekniken som i VS1 byggde på 2 KB-block och i MVS på
4 KB-block.

En Microdator
I visioner och tekniska rapporter talades det på sjuttiotalet om “intelligenta terminaler” som
skulle ersätta de “dumma terminaler” som användes på sjuttiotalet. I Studentlitteraturs katalog
fanns en maskin med en processor från ett företag som hette Intel. Vad jag minns var namnet 8080.
Den var monterad på ett sätt som gjorde att det gick lätt att lära sig hur en dator var konstruerad
med hjälp av datorn och en medföljande lärobok. Jag övertalade ledningen att skicka efter den.

När den kom fick jag disponera den en tid och fick lära mig lite mer om hur en datamaskin
ser ut innerst inne. Självklart skrev jag några små program på maskinen innan jag lämnade den
 vidare.

Detta var min första kontakt med den processorserie som idag kallas för Pentium.
I USA började en yngling som hette Bill Gates mecka med en liknade maskin. Själv köpte jag
1982 en annan dator främst för att mitt yngsta barn skulle få lära sig lite mer om datorer.
Den hade en processor som hette Zilog. Maskinen hette ZX81 och var tillsammans med dess
företrädare ZX80 och uppföljare Spectrum en tid världens vanligaste datamaskin.

Detta var början till den tid datorer inte bara fanns i datahallar utan också i barnens
rum och i hobbyrum hos dataentusiaster. Ganska snart hamnade de också på skrivborden.

IBM kom småningom att marknadsföra en Intelbaserad microdator som de kallade PC,
Pesonal Computer eller persondator. Vi fortsatte att använda de vedertagna namnen UFO
eller Dinky Toy.

Facket
Skyddsombud
Under en lugn period lockades jag att åtaga mig att bli skyddsombud. Det hade inte varit
någon större aktivitet på det området tidigare. Arbetet med att förbättra arbetsmiljön
blev intensivt. Det fanns synproblem hos dem som arbetade med bildskärmar. Det minskades
med hjälp av fria terminalglasögon och nya armaturer.

I datahallen var det infraljud på en bra bit över 100 Db på grund av kylsystemet. Detta
bullerproblemet som drabbade maskinoperatörerna minskades med att man byggde
operatörsutrymmen utanför hallen. Ingen som inte skulle montera magnetband eller
fortfarande någon gång hanterade hålkort behövde vistas i bullret.

Ett ännu värre buller fanns i efterbehandlingen där man till exempel arbetade med
kuvertering. Här måste man i fortsättningen använda hörselskydd.

Datakursen
Vi som arbetade i samma kontorslandskap hade mycket bra personliga kontakter. På den tiden
var intresset för sådant som hade med datateknik att göra stort hos många. Jag fick en vink
från någon av dem som arbete med kundregistret att några gärna ville ha en bredare
kunskaper inom området. Jag erbjöd mig att leda en sådan utbildning inom huvudkontoret.

Företaget gick med på att kursverksamheten fick genomföras delvis på arbetstid och i OK’s
lokaler. TBV ställde upp med kursmaterial, bland annat en bok som hette “Datorer på våra
villkor”. Den typen av kurser borde finnas än idag bland medborgarna. Tyvärr känns det
som om de flesta människor gärna använder datorer men samtidigt vill veta så lite som möjligt
om dem. De vill ogärna ta något som helst ansvar för hur de används.

Metalls besök
En dag kom en person till OK med ett hemligt uppdrag. Hon sökte en IT-leverantör åt
Metallindustriarbetareförbundet som inte var helt nöjt med sin nuvarande. Jag blev
helt korrekt utvald att som den mest insatta i dataavdelningens infrastruktur
bli intervjuad. Det blev ett lågt samtal där jag försökte ge så korrekta svar som möjligt
på alla frågor. Det blev, trodde jag, en bild av en dataavdelning med dålig ordning,
kompetensbrist och många andra problem. Men jämfört med konkurrenterna gjorde vi tydligen
ett bra intryck.Vi vann, som man skulle ha uttryckt det i dagens konkurrensutsatta värld.

Nya kunder
Det började hända saker inom konsumentkooperationen. Det pratades om en gemensam datacentral
till exempel. Vi befarade att OKs dataavdelning skulle läggas ner. Det blev inte så. I
stället fick i ta över datadrift från andra delar av konsumentkooperartionen.
Systemprogrammerarefunktionen växte så att i var fyra i gruppen vad jag minns. Under åren
tidigare hade vi varit en eller två.

Nya intressanta tekniska arbetsuppgifter kom till. Jag sökte ett jobb i en nyskapad
specialistfunktion men fick beskedet att jag var alltför värdefull på det jobb jag hade.
En filosofie doktor i datateknik fick det jobbet. Självklart fick han mycket mer betalt
än vad jag hade.

Min grupp hade nu egen budget. Jag ansvarade för budgetarbetet. Men företaget insåg
att det behövde en formell gruppchef. Själv insåg jag att det var dags att prova på någonting
annat. Det blev ett gruppchefsjobb på ett annat företag. OK som fortfarande hade en väl
fungerande infrastruktur såldes till EDS. Men då jobbade jag redan på Slakteriförbundet.