NCR-Century 200/2001: conversie

De eerste toepassing

Een van de eerste toepassingen was het ontlasten van het tijdrovende printwerk op de NCR-315. De programma's werden aangepast zodat printregels niet meer naar de printer werden gestuurd, maar op tape geplaatst. Deze bestanden werden vervolgens op de Century afgedrukt. Deze nieuwe printer was niet alleen aanzienlijk sneller dan die van de 315, maar had ook een kwalitatief veel betere afdruk.
Er werd gebruik gemaakt van een standaard printprogramma (STANDPR); dit programma werd zo vaak gebruikt en aangepast voor nieuwe toepassingen dat de programmeur als snel de bijnaam 'STANDPR-specialist' kreeg.

Nieuwe ontwikkelingen

Verder werden alle nieuwe toepassingen geschreven op de Century. De verwerking geschiedde eerst alleen in dagdienst, maar al snel gevolgd door een 3-ploegendienst, zoals bij de nog steeds draaiende NCR-315 gebruikelijk was.
Ook op de Century werd er veel werk verricht voor derden; hierover later meer.

NCR Europa

NCR Europa, gevestigd in Brussel, had in al haar wijsheid besloten dat slechts een deel van de programmeer instructies aan het gewone volk mocht worden vrijgegeven. De programmeertaal was van origine namelijk onderverdeeld in 3 levels (niveaus):

level-1: hoogste niveau van programmeren, vrijwel alles via macro's (één commando dat een hele reeks voorgeprogrammeerde instructies uitvoert); simpel te leren, maar relatief traag
level-2: de machinetaal zelf (de symbolische taal waarin de programmeur zijn instructies schrijft komt één op één overeen met de machinetaal, vergelijkbaar met de NCR-315)
level-3: machinetaal op input/output niveau (fysieke lees/schrijfinstructies naar de apparatuur)

NCR Europa voerde een soort 'censuur' uit op de Amerikaanse handboeken; zij haalden alle verwijzingen naar level-2 en level-3 eruit en gaven 'herziene' boekwerken uit, geschikt voor de Europese markt.
Niet leuk voor de programmeurs, maar het werkte wel en NCR Europa kreeg geen moeilijke vragen over nog moeilijker assembleerproblemen. Bovendien werd gesteld dat gebruik van level-2 of level-3 ten koste zou gaan van support!
In de normale programmatuur was dat nauwelijks een probleem, want je kon in level-1 alles programmeren.
Complexe-, processor-intensieve- en zware rekeningkundige toepassingen hadden hier wel last van, wat keihard naar voren kwam bij de voorbereidingen van de conversie van de 315 naar de Century.

Conversie 315 naar Century

Behalve het ontlasten van de oude NCR-315 was het uiteindelijk ook de bedoeling om alle verwerking van de 315 over te zetten naar de Century. Het wachten was op de nieuwe bestandsstructuur: de FAMOUS-database, een geïndexeerd bestand, waarmee het totale polisbestand in een keer bereikbaar zou worden (noodzakelijk voor de online plannen die er lagen) en waarmee je via bepaalde indexering snel toegang had tot de daadwerkelijke polisgegevens; denk hierbij aan polisnummer, kenteken, naam en dergelijke.

Berekeningen hadden aangetoond dat het alleen met zeer hoge compressie van de informatie mogelijk zou zijn om het hele polisbestand op twee Century CRAM-decks te laten passen. Er werd een record ontworpen met een zeer ingewikkelde structuur waardoor alles net aan paste in de ter beschikking staande ruimte. Er werden testprogramma's ontwikkeld om aan de 315-zijde het polisbestand op tape te zetten en aan de Century zijde de gegevens vanaf tape om te zetten naar de nieuwe recordstructuur. Dan nog even alles sorteren in de nieuwe volgorde en er vervolgens een FAMOUS-database van maken.
Al snel werd duidelijk dat dit qua doorlooptijd een hopeloze zaak zou worden: vele weken conversietijd !!

In overleg met de directie werd besloten om het conversieprogramma in machinetaal (level-2) te gaan schrijven: vanuit NCR bezien was dat een uiterst 'illegale' en 'niet-ondersteunde' actie. Voor DZP een gelukje: de conversie zou nu slechts 24 - 28 uur bedragen in plaats van enkele weken. Voornaamste boosdoener was de ingewikkelde record structuur.

Daarnaast werd al snel duidelijk dat niet iedere programmeur in staat zou zijn om informatie te onttrekken aan de nieuwe records en nog minder om er wijzigingen in aan te brengen, met als mogelijk risico een corrupte database. Vervolgens werd besloten dat alle recordmanipulatie (lezen/wijzigen van de individuele velden binnen het gecomprimeerde record) via een standaard routine zou moeten verlopen om de integriteit van de records te bewaren. Ook hier gold dat snelle verwerking alleen mogelijk was binnen de level-2 structuur.

NCR Europa werd erbij gehaald om deze problematiek voor te leggen; de uitgeoefende druk op NCR was uiterst hoog, want niemand binnen DZP was tevreden met het idee van een computer zonder support.
Het feit dat elk programma voortaan level-2 zou kunnen bevatten was onaanvaardbaar voor NCR; immers, als er wat fout zou gaan, zouden specialisten uit België of zelfs Amerika over moeten komen om problemen te verhelpen. NCR stelde onder meer: “Hoe zorg je er voor dat de standaardroutine in elk programma wordt geüpdate bij eventuele aanpassingen in de recordstructuur of na correctie c.q. aanvulling van de subroutine?”.
Het antwoord hierop was simpel: al deze problemen zouden te voorkomen zijn door van de standaardroutine een macro te maken: één persoon maakt en onderhoudt deze macro, de kennis blijft beperkt en feitelijk verandert er voor de gewone programmeurs niets, want bijna de hele Century programmataal is opgebouwd uit macro's. Er komt er alleen eentje bij. Hik...slik...
Aangezien NCR nauwelijks nog mogelijkheden had om hier tegenin te gaan, werd dit (met de nodige tegenzin) aanvaard. Consequentie van dit besluit was wel dat de volledige en ongecensureerde Amerikaanse documentatie overhandigd moest worden, inclusief de handboeken over level-2, het schrijven van macro's en macrogeneratoren en niet te vergeten de Software Toolkit (STK), die nodig was voor het ontwikkelen van macro's en aanpassen van de compiler. NCR ging akkoord, mits DZP bereid was om de kennis van de technisch programmeur (schrijver van de macro en overige level-2 programmatuur) eerst te laten beoordelen door een specialist van NCR. Dat bleek geen probleem en korte tijd later werd alle documentatie en speciale software ter beschikking gesteld aan DZP.

De macro werd ontwikkeld, het conversieprogramma geschreven en getest. De nieuwe macro kreeg de naam 'CCCREC' en daarmee waren de programmeurs in staat om alle informatie uit het record op te vragen of te wijzigen. Integriteitroutines controleerden bij elk gebruik of de recordstructuur nog in orde was en zorgde hier mede voor dat de database in tact zou blijven. Een aantal programmeurs vonden het maar niks en probeerden toch zelf de informatie te benaderen of schoven elke programmafout die optrad af op de macro (“het ligt aan CCCREC”). Nadat de maker en de heren Bramsen en Van der Heijden menigmaal voor hun karretje waren gespannen om programmafouten op te zoeken, en het telkens aan slecht programmeerwerk van de betrokkenen bleek te liggen, werd hen te verstaan gegeven zich aan te passen aan de standaards of anders ...

een lang weekend...

Het Hemelvaartsweekend van 1973 (31 mei t/m 2 juni) werd gekozen om de conversie uit te voeren; de vrijdag was een collectieve vrije dag, er waren vier dagen beschikbaar om de klus te klaren. De conversie bestond uit vier delen:

op de NCR-315 aanmaken records op tape
op de Century deze records converteren naar de nieuwe lay-out
sorteren in de gewenste volgorde
opbouwen FAMOUS database

Donderdagochtend vroeg gingen twee specialisten enthousiast aan de slag. De eerste en tweede fase van de conversie verliepen vlekkeloos. Tijdens de derde fase sloeg het noodlot toe: na lange tijd draaien liep de Century computer plotseling vast met een onbekende fout. Memory dump (= afdruk wat op een bepaald moment in het geheugen van de computer staat; dat is het programma en inhoud van alle variabele gegevens) gemaakt en om tijdverlies te voorkomen werd de sortering opnieuw gestart. Uitpluizen van de dump leverde in eerste instantie niets op. Na enige uren opnieuw een vastloper en wederom een memory dump gemaakt. Vergelijking van de twee dumps leerde uiteindelijk dat de fout in beide gevallen optrad bij het 105.000e record! Kennelijk waren we tegen een onbekende limiet van het sorteerprogramma opgelopen. Ter plekke besloten we om een programmaatje te maken dat de enorm grote input file opsplitste in brokken van 100.000 records; deze elk apart te sorteren en daarna met een tweede programma de gesorteerde bestanden weer samen te voegen tot één bestand.

De benodigde programma's werden geschreven en 'on the fly' getest. Dit werkte, en uiteindelijk werd de database opgebouwd.

Het noodlot sloeg opnieuw toe: tijdens verdere controle van de dumps en de recordstructuur bleek dat in het programma op de 315 een paar velden verwisseld waren en eentje bevatte onvolledige informatie. Op de een of andere manier was dit niet ontdekt tijdens de testfase. Het conversieteam paste dit 315-programma direct aan en de conversie werd opnieuw opgestart en uiteindelijk was de database op de Century opgebouwd.

Als laatste stap werden nog allerlei indexen gemaakt, zodat je niet alleen op polisnummer, maar ook op agentennummer, kenteken, bromfietsplaat, naam, adres/woonplaats en later ook op postcode kon zoeken (handig voor het latere online programma!).

Na lang doorwerken met vrijwel geen slaap werd de nieuwe database uiteindelijk op zondag opgeleverd. De leden van het conversieteam konden eindelijk met een voldaan gevoel lekker gaan uitrusten.

lees verder Computers:NCR-Century (3)