NCR-315: werking / programmeren / conversie

Werking van de 315

De NCR-315 ging uiterst efficiënt om met geheugenbeslag en gebruikte een opslageenheid die 'slab' (syllable = lettergreep) genoemd werd. Deze 'slab' bestond uit 12 bits (weet je het nog? de 12 gaatjes uit de ponskaart?) en kon qua inhoud beschouwd worden als:

• 3 cijfers ( 3 x 4-bits): 0-9 en enkele speciale tekens, zoals . , - &
  
  of
  
  
• 2 alfanumerieke tekens (2 x 6 bits): complete charactertabel

besturingssysteem

Het standaard besturingssysteem (ook wel: Operating System) was slechts 1.800 slabs groot en bevatte alleen het aller-noodzakelijkste om de computer te kunnen aansturen. De rest van de logica werd door de compiler toegevoegd, middels kleine macro's (dat zijn voorgeprogrammeerde specifieke functies) in het programma, en al het overige diende elke programmeur zelf te maken. Ook hier praten we over slechts enkele honderden 'slabs'. Meestal waren de in- en outputbuffers groter dan het hele Operating Systeem bij elkaar! Door het vrij kleine interne geheugen (10 KS = 10.000 slabs) werden programmeurs gedwongen om uiterst efficiënt met geheugenbeslag om te gaan: lekker uit de losse pols coderen was er niet bij, want dan paste het niet in het geheugen!

Tijdens de systeemanalyse fase werd een project uitgewerkt en opgedeeld in een aantal zelfstandige eenheden: de programma's werden qua functionaliteit beschreven en soms tot op flowchartniveau gedetailleerd uitgewerkt. Een flowchart is een schematische weergave van de werking van een programma.
Programmeurs zetten deze beschrijving om, in de voor de NCR-315 gebruikelijke programmeertaal: NEAT (National's Electronic Autocode Technique). Dit was een programmeertaal die een fractie hoger lag dan een kale assembler. Een door de programmeur uitgecodeerd programma werd vervolgens op de ponskamer verponst en afgedrukt. De programmeur keek deze lijst na en corrigeerde de gemaakte ponsfouten op de lijst of bracht nog enkele wijzigingen aan in zijn programma. Daarna werd de stapel ponskaarten door de computer omgezet in een voor de computer begrijpelijke taal ('het compilatieproces'), tevens werd het nieuwe programma afgedrukt. De compilerlijst bestond uit de inhoud van de ponskaarten plus de door de computer gegenereerde machinecode. Deze machinecode werd ook op ponsband gezet en bevatte het uiteindelijke programma dat door de computer in te lezen en uit te voeren was.
Een volgende stap was het testen op correcte werking, fouten verbeteren, opnieuw testen, net zolang totdat de verantwoordelijke systeemanalist tevreden was met het door de programmeur opgeleverde resultaat. Daarna werden de programma's waaruit zo'n project bestond ingepland in het dienstrooster van Operating en uitgevoerd in de bedoelde frequentie (dagwerk, weekwerk, maandwerk, kwartaalwerk, jaarwerk, incidenteel).

De operators haalden met nieuwe programmeurs vaak een geintje uit als ze voor het eerst kwamen testen: apparatuur werd dan bijvoorbeeld in stand-by gezet, waardoor het programma ogenschijnlijk niet functioneerde, omdat de programmeur 'vergeten' was dat je voortdurend de status van de apparatuur moest opvragen. Dit was vooral bij printers van belang, want het kon gebeuren dat het papier op was en de operator een nieuwe doos papier moest in hangen. Als het programma dat niet controleerde, kreeg je rare resultaten, want het programma stuurde wel printregels naar de printer, alleen kon de printer die op dat moment niet verwerken, want er was geen papier om op af te drukken. Als de operator dan voor nieuw papier had gezorgd en de printer er weer helemaal klaar voor was, ging zo'n programma door waar het gebleven was en werd verder gegaan ergens halverwege een pagina. De correcte manier was om het papier in de printer dan eerst naar het begin van een nieuw blad door te schuiven en daar eerst kopregels te printen, voordat verder gegaan werd met de werkelijke print output.
De arme programmeur werd vervolgens met een memory dump weer teruggestuurd naar zijn werkplek met de mededeling om weer terug te komen als hij een werkend programma had.

Programmeren

De 315 had een aanmerkelijk betere methode om te programmeren dan de Bull-Gamma: geen gedoe meer met allerlei panelen waar je stekkertjes in moest steken, maar instructies die overeen kwamen met de hardwaremogelijkheden van de computer. Er waren ook een aantal voorgeprogrammeerde functies die elke programmeur aan zijn programma kon toevoegen. In feite was er een 1 op 1 relatie tussen de symbolische instructie die een programmeur opschreef en de hardware instructie die de computer kon uitvoeren. Dit noemen we een 'assembleertaal'. De programmeur werd geacht veel kennis te bezitten van een computer, zodat hij er het maximaal mogelijke rendement uit kon halen.

Een programmeur vertaalt dus eigenlijk de oplossing van een probleem in voor de computer begrijpelijke instructies. Deze voor de mens leesbare instructies werden op speciale formulieren geschreven en vervolgens door de ponskamer op ponskaart gezet.

Een speciaal programma (de compiler) las deze kaarten in en maakte er een voor de computer begrijpelijk geheel van: het programma. Het samengestelde programma werd op CRAM gezet en/of verponst in ponsband. Een piepklein programmaatje (ook op ponsband, MIDSUPER geheten) kon deze programmaponsbanden dan inlezen en op de juiste locatie in het geheugen plaatsen, zodat het ook kon functioneren.

Het kwam nooit voor dat een programma helemaal foutloos was. Door schade en schande wijs geworden werden correcties niet in het originele ponskaartenprogramma aangebracht en vervolgens opnieuw gecompileerd, maar werden correcties in machinetaal geschreven en tijdens het laden van het programma aangebracht. Elk programma had verplicht een vrij gebied bestaande uit enkele honderden nullen (ZERO-gebied). Op de plek in het programma waar een fout zat, of een aanvulling moest komen, werd een sprongopdracht gemaakt naar het ZERO-gebied en daar werd de correctie of aanvulling gezet en vervolgens werd met een andere sprongopdracht teruggekeerd naar de instructie direct volgend op de plek des onheils.

De reden dat er slechts zelden een totale hercompilatie werd gemaakt, lag in de kwetsbaarheid van de stapel ponskaarten. Niemand kon garanderen dat de stapel nog compleet was of op de juiste volgorde lag. Hercompilatie betekende dus moeizaam en langdurig opnieuw testen en daar was nauwelijks tijd voor.

Merkwaardig was dat bijna niemand zich realiseerde dat enerzijds elke ponskaart een volgnummer had waarop gesorteerd kon worden en anderzijds het compilerprogramma de originele stapel in de correcte volgorde had ingelezen en ook nog eens bewaard had op het compiler CRAM-deck.
Vrijwel elke programmeur gebruikte exact dezelfde locatie om de ponskaarten in te lezen op het compiler CRAM-deck en overschreef daarmee dus het programma van een ander! Dat de auteur een andere, vrije, locatie gebruikte voor zijn compilers en regelmatig gebruik maakte van het fenomeen 'hercompilatie', werd belangstellend bekeken, maar verder waagde niemand zich aan dat nieuwerwetse gedoe. Dat kwam pas in zwang op de volgende computer en nog slechts mondjesmaat.

De eerste opleidingen

Na aanschaf van de apparatuur moesten er ook nog mensen worden opgeleid die de machine zouden programmeren en bedienen. Een pionier uit die tijd, Jan van Mierloo, vertelt:

“Er werd een computerafdeling geformeerd en van diverse afdelingen medewerkers vrijgemaakt en overgeplaatst naar de nieuwe afdeling. Het betrof de heren De Boer, Bramsen, Gelderman en mijzelf. De eerste opleiding werd door NCR 'droog', d.w.z. zonder computer in de buurt, deels klassikaal gegeven. De cursusboeken in de Engelse taal werden doorgewerkt, dag in, dag uit, op kantoor in een stille kamer en thuis. Flowcharts en kleine programmaatjes werden gemaakt en op bladen met potlood (corrigeerbaar!) vastgelegd. Voor de een was dit een makkie, voor de ander een probleem, maar er werd nooit opgegeven.
Om meer inzicht te krijgen werd er per 13 december 1963 een kennismakingsexcursie per trein naar Frankfurt georganiseerd van 3 dagen (de heer Stolk met zijn medewerkers van DZP en een aantal medewerkers van NCR Nederland). De stemming is voortreffelijk. De eerste ervaringen met de echte computer verhelderend. Het door NCR gemaakte programma om in een bestand met tussenpersonen te zoeken, raakt tot grote hilariteit in een 'loop' ...
Verdere testen verlopen voorspoedig en wij zijn nu zeker van succes, de onbegrensde mogelijkheden van het systeem zijn duidelijk aangetoond. Tot besluit hadden we nog een prima diner samen met Herr Direktor van NCR Frankfurt.”

Later werd er een opleidingsinstituut opgericht te Amsterdam, gevestigd aan de Amstel. Eén van de betere docenten was de heer Edixhoven, die een zeer gedegen kennis had van de 315 en didactisch erg vaardig. In latere jaren kon je de programmeurs die door hem waren opgeleid er zo tussenuit pikken.

De eerste conversie

Omdat een groot deel van het polisbestand al in ponskaarten lag opgeslagen, werd besloten deze als eerste over te zetten naar de NCR 315 computer. Jan van Mierloo vertelt verder:

“We begonnen met het ontwerpen van de noodzakelijke computerbestanden (het hele polisbestand, het hele tussenpersonenbestand, etc.) en de indeling van de records (alle informatie behorende bij één polis of één tussenpersoon). We moesten erg zuinig omspringen met de geheugencapaciteit, vandaar dat we variabele records ontwierpen, al of niet opgebouwd met variabele delen en/of zoektabellen (zie uitleg op de volgende pagina).

Ook worden invoerdocumenten (ponsslips) ontworpen, met rubrieken gekenmerkt met vreemde codes zoals ,@ en ,.

De te schrijven computerprogramma's worden verdeeld onder de medewerkers, waarna het grote werk kan beginnen. De geschreven programma's worden vastgelegd in ponskaarten. Compilers maken en testen gebeuren op het service centrum van NCR, totdat er bij DZP een installatie staat. Als eerste was er de omzetting van de prolongatiegegevens in ponskaarten naar CRAM: eerst het autobestand in verband met de aanstaande WAM-aanhangsels (invoering Wettelijke Aansprakelijkheid Motorrijtuigen per 1 januari 1965), daarna Brand en Varia en ten slotte de Transportafdeling (voornamelijk pleziervaartuigen).

Uit het omgezette autobestand zijn in het bijzijn van de programmeurs de WAM-aanhangsels vervaardigd. De programmeurs dienden gewoon mee te draaien in de shifts om direct te kunnen ingrijpen bij mogelijke problemen. Uit de financiële records werden per agent zijn overzicht met eindtotalen gemaakt, die vervolgens in de rekening-courant werden overgenomen. Het autobestand werd voortaan dagelijks bijgewerkt met de dagmutaties.

Nadat de prolongatieprogramma's klaar zijn, worden de overige prolongatiegegevens omgezet en voortaan de prolongatiestukken op de computer vervaardigd; bijwerken van deze bestanden met de dagmutaties.

Zodra ook de polismutaties kunnen worden verwerkt, polissen afgedrukt en de programma's voor de rekening courant klaar zijn, worden alle polismutaties via ponsslips vastgelegd in ponsband, dagelijks verwerkt in de avond/nachturen, opdat 's morgens de output, gesneden en geburst, voor de afdelingen gereed ligt.

De Bull-ponskaartenmachines worden stilgezet.

In de loop van de tijd worden de programma's uitgebreid met bereken-modules en nieuwe toepassingen ingevoerd.”

lees verder Computers:NCR-315 (4)