Na deze opsomming een hoofdstukje over meten en een bespreking van het HBSO. En tot slot wat foto s.

04 De afdelingen De systeemontwikkeling Inleiding Er is nogal een verschil tussen de programmeur van het eerste uur die zijn COBOL programma op ponsformulieren schreef en de man of vrouw die nu met een beeldscherm een programma met IEF genereert. Er zit dan ook veertig jaar ontwikkeling tussen. In die tijd werden talloze Tools en methoden bedacht om het programmeren maar sneller en met minder fouten te laten verlopen. We bespreken ze niet allemaal, dat zou te ver voeren. Alleen de belangrijkste zaken zijn opgenomen. Maar één ding is hetzelfde gebleven: IEF genereert nog steeds COBOL. Een oma uit 1960! Na deze opsomming een hoofdstukje over meten en een bespreking van het HBSO. En tot slot wat foto s. Voor 1967 Er waren tot 1967 twee ontwikkelafdelingen. De Gamma en de 1401 in Den Haag. Op de 1401 werd met SPS geprogrammeerd; de taal van de Gamma is niet meer bekend. In Rotterdam bij de Nationale werd er op de 650 geprogrammeerd. In eerste instantie werd er gewerkt in Assembler, (10 was optellen, 11 was aftrekken), later werd dit Soap (Symbolic Optimal Assembly Program). Wim Combé die nog op deze machine geprogrammeerd heeft noemt SOAP een hele verbetering ten opzichte van Assembler. Je kon nu ADD en SUB schrijven in plaats van 10 en 11, maar vermenigvuldigen was wel herhaald optellen. Hij herinnert zich ook nog de onbetrouwbaarheid van de machine. Leo Verwoert kan zich nog uit het begin weekenden herinneren waarin hij meerdere malen naar de zaak moest omdat de 650 een dump gaf. Meestal was dat verkeerde input waar het programma op stuk liep. Of ze hadden op de afdeling wat trucjes gebruikt om een post in te voeren en daar kon dan het programma niet tegen. Hij moest dan Martha Bestebreurtje helpen om de invoer te verbeteren en dan ging de boel weer verder zolang als het duurde. Wel op je sokken i.v.m. met vuil. Het was trouwens een vervelende tijd, het jaar na de fusie. Er was nog niet besloten welke machine gekozen zou worden, en er werd dus niets nieuws meer opgezet. Er was niets te doen. Jaarverslagen kleuren uit verveling. En toen de machine eenmaal gekozen was werd hij op het laatste nippertje vervangen door een 360/40 waar niemand nog iets vanaf wist. De 1401 cursus die ze gevolgd hadden was ook voor niets geweest. Vanaf de bestelling van de 360/40 gingen de nieuwe programma s in COBOL, bij beide programmeringsgroepen. Hillard van der Steeg herinnert zich zijn opleiding tot leerling-programmeur in najaar 1967: Wij (Leen Buitelaar, Dik Heikoop, Marijke Weststrate, Hans Broekhans en mijn persoon) zaten in een kamer op de begane grond van de nieuwbouw (Schiekade) vlakbij de directie (Nieuwland, Van den Broek en Kuyte). Van Wijk was toen nog directiesecretaris. Cursussen (Inleiding /360, Cobol en RPG) volgden we in Amsterdam bij IBM in het kerkgebouw Het Open Hof. Tussen deze cursussen door hielpen wij op de Hollerith afdeling met sorteren e.d. Pletser, Blom en Leentfaar waren onze begeleiders. Af en toe mochten we wat experimenteren met het maken van een eenvoudig programmabord (zo n bord met al die snoertjes). Verder

was er genoeg tijd om ons voor te bereiden op het examen Actuarieel A. Van den Broek was daar altijd zeer geïnteresseerd in en kwam af en toe langs om ons van advies te dienen. Na afloop van de cursussen gingen we naar de dependance Kramer & Röder waar toen de afdeling Systeemanalyse en Programmering onder leiding van Van der Ven was gehuisvest. Dik Heikoop en ik kwamen bij de groep Leven Individueel, waar o.a. Bestebreurtje en Den Hond deel van uitmaakten, om onze eerste cobolprogramma s te schrijven (P60winst en een programma voor het IVARO boek (inschrijvingen, veranderingen en royaties). Ponsen en terminals Zo zaten Dick van Veelen, André van der Hart en Wessel Burger achter hun bureau in 1972. Het was een kantoortuin, flinterdun groen slaapkamertapijt, de bureaus in een vlinderopstelling en veel plantenbakken en geluidschotten. Potlood en papier om te programmeren. Niks geen schermen. Cobol sheets waarop het programma gecodeerd werd. De sheets werden daarna geponst want in die tijd stonden de programma s in ponskaarten. En moest je die zelf netjes opbergen. De bakken werden met testopdrachten ingeleverd bij de computerafdeling en dan maar wachten tot de output terugkwam. Bij de operating waren er duidelijke instructies in welke bakken de testjobs aangeleverd moesten worden en wanneer er gedraaid moest worden. Ton Modderman herinnert zich nog: Ponskaarten de trap af Elke programmaregel stond vroeger in even zo vele ponskaarten. Die ponskaarten zaten in stalen bakken. Zo heb ik eens een keer een programma dat uit 5 stalen bakken ponskaarten bestond vanaf driehoog in het trappenhuis laten vallen. Geeft effe veel rommel en lawaai. Versiebeheer in vroeger tijden Lang geleden toen programma's nog in ponskaarten waren vastgelegd, was ook al sprake van versiebeheer. Er waren van elk programma 2 versies aanwezig. De ene versie was bedoeld om verder mee te ontwikkelen en de andere versie was de productieversie. Deze versies zaten dus in stalen bakken. Nu iets over de procedure. Zodra een programma na het testen in productie kon, werd de complete set ponskaarten van de ontwikkelversie mechanisch gekopieerd. De kopie werd daarna opnieuw gecompileerd naar de productieomgeving en de ponskaarten van de oude versie werden in de bakken vervangen door de nieuwe versie. Je kon dus heel goed zien wat productie was of ontwikkelversie. De set ponskaarten van de ontwikkelversie was sterk beduimeld door het vele gebruik door de programmeurs. Maar er gebeurden ook leuke dingen door de ponskaarten volgens Irene Oostrum: Liefde op het werk Onder de jonge meiden (tussen 15 en 20 jaar) bloeide altijd wel iets moois op. Er was dan ook een periode van verlovingen, van huwelijken en later van zwangerschappen. Ook met de programmeurs (die hun correcties ) kwamen brengen werd hevig geflirt en afspraakjes gemaakt in de fietsenkelder van de Groenhovenstraat. We werden zelfs omgekocht met snoepjes en rolletjes pepermunt in de programma s om maar zo snel mogelijk een programma geponst terug te krijgen. Als er in een programma maar een enkele kaart gewijzigd moest worden deed een programmeur dat vaak zelf, met de handponsmachine. Bij de operating waren er duidelijke instructies in

welke bakken de testjobs aangeleverd moesten worden. De programmalijsten waren de documentatie, die werden uiteraard ook netjes opgeborgen. En als je de lijsten niet goed opborg gebeurde het volgende: Je maakt dat af en toe wel eens mee. Het programma loopt stuk en je kan de zaak niet repareren omdat je de oorzaak niet kan vinden. Geleerde heren hadden ontdekt dat het programma in het geheugen 8 posities was verschoven. De oorzaak daarvan was onvindbaar, ondank vele interessante theorieën. Uiteindelijk na vele dagen kwamen we er achter dat het programma vlak voor het draaien was aangepast en dat de bijbehorende listing nog niet opgeborgen was. Nadat we de goede listing hadden, was het een zeer eenvoudig op te lossen standaardfoutje geworden. In 1974 werd een proef gehouden met terminals, en in 1977 kwamen de eerste beeldschermen aan de Groenhovenstraat. Bert Rosbach vertelt er meer over: Kort na de oplevering van PCS volgde de evaluatie door de groep TSO-testers. Die groep was overigens een select gezelschap van ervaren programmeurs. Het was ons goed bevallen, met uitzondering van het lawaai. In het geval van PCS was het voortreffelijk te gebruiken omdat je de interne tabel met te selecteren rekeningnummers goed zichtbaar kon maken. Toen we daarna allemaal naar TSO gingen kregen we gelukkig een beeldscherm. Die maakten geen lawaai als er een stuk output gepresenteerd moest worden. Ook was het intoetsen van de benodigde gegevens wat geruislozer. In 1977 hadden we een open dag in KG (Kantoor Groenhovenstraat). Daarbij was ook een demo TSO op een COBOL-source, die ik met een paar anderen verzorgde. In een COBOL-source kun je de auteur meegeven. Dat deden we toen nog wel. Bij die demo geven we soms het toetsenbord over aan de gast. Dan veranderden we de naam, zetten via het repeatcommando het hele scherm vol met die naam, om het daarna met een grapje weer weg te halen. Kinderen vonden het prachtig. Als je hetzelfde door hun moeder wilde laten doen, dan kreeg je soms het idee, alsof het van de duivel was en ze hun vingers konden branden aan het toetsenbord. Leo van den Berg weet nog dat in 1980 alleen de wijzigingen nog maar door hemzelf werden ingevoerd achter de terminal. De eerste invoer gebeurde toen nog door de ponskamer. Pas in 1985 had iedereen zijn eigen terminal. En zo zaten de heren Van Veelen, Burger en Van der Hart er in 2003 bij. De modernste bureaus, nog meer plantenbakken, en een dikker tapijt dan in 1972. Mooie platte schermen, een extra scherm voor ingescande documenten en de PC onder het bureau. Geen lijsten meer, de gegevens staan op het mainframe en kunnen elke minuut worden opgeroepen.

Talen en Ontwikkelmethodes RPG (Report Program Generator) Zowel op de 360/40 als op de 360/20 werd RPG (zeker in het begin) veel gebruikt. Je kon er heel snel lijstjes mee draaien, en eigenlijk alle mechanische apparatuur mee imiteren. Door de voorgedrukte formulieren was het eigenlijk geen programmeren, maar meestal meer coderen. Maar er werd wel flink productie mee gedraaid. Bas Snaauw weet nog dat ze naast een RPG programma ook nog een assembler programma lieten draaien op de 360/20. Dat was verboden (het operating system van de 20 kon maar één programma tegelijk aan) maar de truc was er des te leuker om. Het was bijna een vergeten taal, maar RPG kwam weer helemaal terug op de S/34 en de S/38. Het was wel een heel wat mooiere taal geworden dan de oude RPG op de veertig. Bij Leven is RPG fanatiek gebruikt. Op de AS/400 werd dan wel geen nieuw programma in RPG geschreven, maar het onderhoud vroeg nog steeds de nodige kennis. Tot in de jaren negentig werden er mensen opgeleid voor RPG. COBOL Vanaf het eerste uur werd in COBOL geprogrammeerd. Adri Vergalen heeft opnieuw blijk gegeven van historisch besef door een COBOL boek uit 1960 te bewaren. Het zit in een Oranje map met Opleidingscentrum-DP erop gedrukt, bovenaan die map staat IBM. En met de pen staat er ook nog Hans Nijman opgeschreven. En het boek was oorspronkelijk van Joost Kegge! We hebben op de CD een stukje geschiedenis van COBOL uit het boek overgenomen. Er is tenslotte geen enkele taal die het zolang uitgehouden heeft en zoveel gebruikers gehad heeft. Er is zelfs nog een streven geweest om COBOL op de PC als standaard in te voeren, maar dat is toch niet gelukt. Uit de inhoudsopgave zien we wat er in die tijd kon met COBOL. Maar een NN er moest zich aan het rode boekje houden. Daar waren de instructies opgenomen die ze mochten gebruiken. De rest was taboe. En als je een dump had en de referencekaart hielp je niet verder, dan kon je bij Jan van der Linden de uitgebreide lijst met interrupts gaan bestuderen, en er misschien een nieuwe dumpoorzaak bij zetten. SDM In 1970 wordt Pandata opgericht door drie Nederlandse bedrijven: PTT, AKZO en Nationale- Nederlanden. Eén van de eerste dingen die uit deze samenwerking te voorschijn komt is SDM, de systeemontwikkelings-methode die heel lang in gebruik geweest is bij NN. In 1987 kwam er een nieuwe versie uit, die ook wel SDM II genoemd werd. In de 2N uit 1989 wordt verteld hoe deze methode bij NN wordt toegepast.

SDW SDW (System Development Workbench) is in 1986 ontwikkeld door Pandata. Het is vanaf 1987 ingezet bij veel nieuwe projecten. Voor de eerste keer wordt de PC bij programmaontwikkeling voor het Mainframe ingezet. Ilias was een goed voorbeeld. Na de introductie van IEF sterft SDW uit. ADS ADS (Application Development System) is een aparte taal binnen IDMS. Je gebruikt hem om IDMS Maps te genereren gebruik makend van de MAPC compiler. Het is een voorbeeld van een vierde generatie taal. Hij werd vooral voor Schade gebruikt vanaf 1985. Toen DB2 werd ingevoerd verdween ADS. CSP (Cross System Product) In 1991 wordt er een proef gehouden met CSP bij Leven, VOS wordt nieuw opgezet met CICS/DB2. Iedereen is enthousiast, nu is er een vierde generatie taal met DB2. Er wordt besloten om het tool in te voeren. Zoals wel meer gebeurt bij proeven wordt VOS niet op het mainframe ingevoerd, maar blijft vrolijk op de AS/400 draaien. En door de ontwikkelingen binnen IEF sterft CSP een vroege dood. IEF (Information Engineering Facility) In 1993 verschijnt er een TOS Kompas gewijd aan Applicatiegeneratoren. Een werkgroep heeft vier producten onderzocht en komt nu met zijn conclusie. De vier producten waren ESDF HPS, Huron en Sapiens. Er wordt besloten om HPS verder te onderzoeken. Maar in de loop van het onderzoek komt IEF op de proppen en dat wordt de uiteindelijke keuze. Corine Cools schrijft in oktober 1993: IEF is een I-Case Tool dat gedeeltelijk op het werkstation onder OS/2 en gedeeltelijk op het mainframe draait. De systeemontwikkeling vindt in zijn geheel op het werkstation plaats, enkele centrale functies bevinden zich op het mainframe. IEF biedt ondersteuning voor de gehele systeemontwikkelcyclus, vanaf informatie planning tot en met implementatie. In 1994 wordt een proef gestart met RSL bij Leven. Die proef slaagt, en vanaf dat moment gaan alle grote nieuwe projecten met IEF. Dat mag ook wel want een IEF pakket kost ongeveer 40.000 gulden, en draait alleen maar op een zware PC. Dus het is een behoorlijke investering. Jammer dat veel van de in die tijd ontwikkelde systemen nooit verder gekomen zijn dan het teststadium. Wat dat betreft is de score van COBOL veel beter. RAD (Rapid Application Development) Bij Leven toegepast bij PC programmering. Goedkeuring van gebruikers in een vroeg stadium door middel van prototyping is de basis van deze methode.

CMM Onder de Naam SPINN (Software Process Improvement NN) wordt in 1997 een proces op gang gebracht om het softwareontwikkel traject te verbeteren. Er wordt gebruik gemaakt van CMM, het Capability Maturity Model. Meten Meten van prestaties, plannen van projecten en beheersen van testkosten is vanaf het begin een belangrijk punt bij de leiding van SAP. Prompt Nou niet gelijk boos worden. Er roept niemand dat Prompt vandaag ingeleverd moet worden. Het wordt alleen maar besproken. Als er ooit een systeem geweest is waar iedere automatiseerder een hekel aan had dan was het Prompt wel. In 1971 wordt Prompt ingevoerd. Het werd gebruikt voor de verantwoording van de computerkosten en van de manuren. Er is een formulier uit 1971 waarmee de computerkosten van een testrun werden vastgelegd, in 1/100 uren. Maar het meest werden er toch manuren uren mee geboekt. Niet alleen bij het AC, ook bij Leven en Schade. In 1980 wordt er een rapport opgesteld over de bestaande meetinstrumenten en daarin wordt Prompt als volgt omschreven: Het Prompt-systeem heeft binnen SAP betekenis als tijdverantwoording- en planningsysteem. Per medewerker kunnen taken, onderverdeeld in subtaken, gepland worden en kan de tijdbesteding per subtaak geregistreerd worden. De gegevens per taak worden getotaliseerd naar fase/projekt/gebruiker/afdeling/generaal totaal. Gekoppeld aan de opgenomen taken kan informatie over testen opgenomen worden v.w.b. planningen en realisaties van aantal testshots en bestede CPU-tijd. Alle registratie van mantijd en CPU-tijd worden door het systeem tegen de ingebrachte tarieven omgerekend naar kosten. Maar daarna volgt direct: De tevredenheid over het Prompt-systeem is matig en de motivatie om alle mogelijkheden van het systeem te benutten is laag. Met betrekking tot de huidige situatie zijn de volgende opmerkingen te maken: 6.4.1 Prompt is mede bedoeld als planningssysteem en biedt de mogelijkheid om aan de hand van ingebrachte planningen capaciteitsoverzichten te vervaardigen per project, functie en afdeling. Het corrigeren van eenmaal ingebrachte planningen is echter dermate veel werk dat hiervan nauwelijks gebruik gemaakt wordt. 6.4.7 Slechts voor de AC-aktiviteiten geeft Prompt een enigszins betrouwbaar beeld. De wijze waarop Prompt door de verschillende AO s gehanteerd wordt is volledig ongecontroleerd en betekent in het ergste - en zeker niet uitzonderlijke geval, een verantwoording van 40 uur per week op een willekeurig nummer. De leiding van de AO s zal het met de laatste opmerking niet helemaal eens zijn geweest. Als José Killian bij AO Schade in 1992 een rapport schrijft over een factureringssysteem voor automatiseringskosten, geeft ze een samenvatting van het gebruik van Prompt. Binnen NN-Schade hanteren de automatiseringsafdelingen Nieuwbouw en Onderhoud & Beheer het door AN beheerde PROMPT (PROgramming, Monitoring and Planning Techniques) als tijdschrijfsysteem. Van dit systeem is voor deze studie van belang dat het, naast het plannen van de werkzaamheden, gebruikt wordt als basis voor de doorbelasting van de mankosten die met het ontwerpen en beheren van systemen gepaard gaan.

Niet iets wat je op schrijft als er niets met Prompt gedaan wordt. Al moet er bij gezegd dat Schade op dat moment Prompt wil gaan vervangen. En bij Leven schrijft Dick van Valkenburg in 1980 in INFOO: Bij Leven wordt Prompt ook rond 1992 afgeschaft en vervangen door BOMIS en allerlei programmaatjes op de PC om schattingen te maken. Het AC gaat nog even door na 1992 (daar hadden ze wat extra programma s gemaakt om de rapportage naar de leiding wat makkelijker te maken) en gaat dan over op PIT. In 2002 legt René Landsman nog eens een keer uit waarom PIT er is: om goede nota s bij de klant te krijgen. Plannen Als hulpmiddel voor de planning treffen we in 1975 een paar formulieren aan. Ze worden in 1980 bij het Metingen rapport niet meer genoemd. En Prompt was natuurlijk ook bedoeld om te plannen. Maar daar kwam in de praktijk niet veel van terecht. Bij IFPA, dat in 1990 wordt ingevoerd bij NN, is het opstellen van de planning één van de doelen. Edith Verheusen schrijft in TOS Kompas in 1994: Het doel van het gebruik van IFPA binnen het concern en de uitvoering van een IFPA-telling is drieledig: - Het vaststellen van de omvang van een systeem in een vroegtijdig stadium van een projekt ter ondersteuning van het maken van een planning. - Het na afloop van een projekt kunnen bepalen van de behaalde produktiviteit (werkelijk bestede uren in verhouding tot het aantal funktiepunten). Met deze nieuwe produktiviteitscijfers kan het gemiddelde worden gecorrigeerd, zodat de nieuwe planningen hierop kunnen worden gebaseerd. - Het kunnen vaststellen van de toename van de funktionaliteit van een systeem door het vergelijken van tellingen die zijn gemaakt na het Basisontwerp en na het gereedkomen van het projekten Een paar jaar later wordt met IEF weer een andere funktiepunt analyse in gebruik genomen. Andere registraties Behalve Prompt worden in het Metingen rapport nog twee overzichten genoemd die ook echt gebruikt worden. Het zijn de performance meting SAP NS, die metingen per module geeft en de TSO lijsten waarin per medewerker per TSO sessie tijdsduren en kosten vermeld worden.

HBSO In 1979 schrijft Joop Hakkennes: De richtlijnen Programmering in hun huidige vorm zijn in het grijze verleden ontstaan als een voorlopige noodoplossing, na een rapport van Hendriks, Verbaan en Van Zaanen d.d. 15-2-72, door het verzamelen van allerlei, tot dat moment verschenen, losse circulaires. Ondanks vele uitbreidingen en verfraaiingen is de opzet nooit gewijzigd en daardoor is een tamelijk onsamenhangend (afgezien van wat verwijzingen over en weer) geheel ontstaan. Van de problemen, die aan de huidige opzet verbonden zijn, zijn de belangrijkste: - Richtlijnen Detailontwerp, Basisontwerp, e.d. kunnen moeilijk worden ingepast. - De ordening is per onderwerp en niet per aktiviteit, waardoor de richtlijnen niet als een echt richtsnoer bij de systeemontwikkeling gebruikt kunnen worden. - Door het verzamelen van alle informatie per onderwerp (bijv. JCL) ontstaat een mengsel van richtlijnen, gebruiksaanwijzing en (soms) motivering. - Op veel punten is er geen goede aansluiting van de richtlijnen op de diverse kursussen. De inhoud van de kursussen zou in de richtlijnen terug te vinden moeten zijn, zodat bijv. gewijzigde inzichten ook doordringen tot de mensen die een kursus waarin dit verteld wordt al gevolgd hebben. Om aan dit soort problemen het hoofd te bieden is m.i. een totaal andere opzet gewenst, waarvoor hierna een voorstel volgt. Er zou een "Handboek Systeemontwikkeling" moeten komen, bestaande uit drie delen: 1. Richtlijnen 2. Technieken/Methodieken 3. Hulpmiddelen. Bij dit verhaal is een inventarisatie bijgesloten van alle richtlijnen: Gijs van Zaanen (rechts op de foto, links Kees Heijning) krijgt de opdracht een dergelijk Handboek Systeemontwikkeling samen te stellen. In 1985 zijn er twee delen klaar: deel 1 Beschrijving werkmethodes en Deel 3 Beschrijving hulpmiddelen. Deel 2 is er nog niet. Van 1985 tot 1988 wordt er driftig heen en weer gepraat over verbeteringen. Een voorbeeld van zo n discussie is het bijgaande verhaal over verschillen in systeemontwikkeling. Jan van der Linden, belast met de leiding van Schade, geeft de verschillen aan in systeemontwikkeling tussen Leven en Schade.

Zo n tendentieus verhaal wordt niet gepikt door de Leven mensen, en dezelfde dag schrijven ze een weerwoord: Ondanks deze verschillen komt het er dan toch van. In 1988 worden de voorstellen van Piet Brijs en Jan van der Linden uitgevoerd, er komt een HBSO. Uit de naam moet al blijken dat in dit handboek alle regels staan. Alle losse regels en instructies zijn naar de prullenbak verwezen De hoofdstukindeling met de geplande manmaanden: Deel 1 Algemeen 1 manmaand Deel 2 Organisatie 5 manmaanden Deel 3 Systeemontwikkeling 5 manmaanden Deel 4 Technieken en methoden 5 manmaanden Deel 5 Hulpmiddelen AO 5 manmaanden Deel 6 Hulpmiddelen SO samen met deel 5

Deel 7 Technische zaken algemeen Deel 8 Technische zaken PC Deel 9 Beveiliging Deel 10 Standaards en controles Deel 11 Formulieren 1 manmaand Totaal 2 manweken 1,5 manmaand 1 manmaand 1 manmaand 26,5 manmaanden Jan van der Linden herinnert zich uit die periode nog het volgende: Bij het schrijven van het HBSO werden veel medewerkers ingeschakeld om een hoofdstuk te maken. Ik zelf kreeg hoofdstuk 8 toegewezen. Wanneer een versie klaar was gaf Gijs van Zaanen persoonlijk commentaar. Nadat ik versie 7 had ingeleverd was het commentaar als van ouds: niets was goed, het moest geheel anders. Daarop heb ik versie 1 van het verhaal opnieuw ingeleverd, hetgeen onmiddellijk wordt goedgekeurd. In 1989 is de klus klaar en vanaf dat moment staan er op iedere afdeling van Systeemontwikkeling een 11 tal delen te pronken. Jammer genoeg is er ook nog zoiets als onderhoud. Dat betekent om de twee maanden een zogenaamde HBSO wijzigingsronde, waarbij alle delen bijgewerkt moeten worden door de administratieve krachten. Op sommige afdelingen gebeurt dat wat onregelmatig (het is een vervelende klus) en daarom ligt er wel eens wat achterstand. Het is de bedoeling om bij elk nieuw project eerst de betreffende hoofdstukken in het HBSO te raadplegen, maar als ik in 1992 als nieuwkomer bij Leven op zoek ga naar het HBSO is er eigenlijk maar één exemplaar bij (BOC, op dat moment de afdeling van Jan van der Linden) de rest loopt achter of slechts de oude garde weet waar het staat. Bij Leven speelt het handboek dus geen grote rol. In 1995 wordt het handboek online gezet. Foto s De programmeursafdeling in 1972 (Schiekade) met op de voorgrond Ben van Geffen (bekend schaker). Op de andere foto Wessel Burger die zijn programma update door ponskaarten daarin te vervangen.

De Uitvoering Organisatie In de loop van de jaren wijzigt de organisatie van de productie natuurlijk geregeld. Er zijn drie groepen constant. De Operating, de Werkvoorbereiding en de Invoerafdeling. De overige functies zoals Kontrole/Kontakt, Systeemprogrammering, Planning en Nabewerking worden in de loop van de jaren voortdurend herschikt en herbenoemd. Verder zien we bij de ondersteuning een groep Telecom ontstaan, die in de loop van de jaren uitgroeit tot een aparte poot. Jan Rotteveel krijgt hierover de leiding. Op de foto drie leidinggevenden van de uitvoering in 1970. Van links naar rechts : Leen Velthuizen, Joop Fokke en Thijs Blom Er wordt in ploegen gewerkt. Twee, eventueel drie shifts. In 1971 komt er een circulaire die de ploegendienst regelt na de verhuizing naar KG. Uit deze circulaire kun je afleiden dat er in Rotterdam ook al zo n regeling was vóór het jaar 1971. In 1973 hebben we een afdeling Produktie onder leiding van Van Deursen, en daar onder de groepen Werkvoorbereiding, Operations en Kontrole/Kontakt. Wim van Berkum, Dick de Paus en Hans van Moerkerken zijn bekende werkvoorbereiders in die tijd. De shiftleiders hebben functionele verantwoordelijkheid. In 1982 zijn er vier groepen: Werkvoorbereiding, Kontrole, Operations en Nabewerking, onder hiërarchische leiding van de afdeling Shiftleiders. In 1986 zijn er drie groepen. Operations, Werkvoorbereiding en Kontrole en Nabewerking, hiërarchische vallend onder de groep Produktiebeheer. In 1991 wordt de Wilgenplas betrokken. De uitvoering van AN en RVS worden samengevoegd, en de bediening van de AS/400 van de Schiekade gaat ook naar WP. Er wordt een drieploegendienst ingevoerd. Kennelijk was de derde shift na 1971 verdwenen. Jan van der Linden merkt op dat er normaal twee ploegen waren, maar dat er zo nu en dan, bij grote drukte (eind van het jaar of bijzondere klussen) in drie ploegen gewerkt werd. In 1993 wordt het contact naar de klanten geaccentueerd, en praten we over Relatiebeheer. Er wordt in SO Kompas een artikel gewijd aan deze reorganisatie. Er wordt ook een aantal plannen voor de toekomst aangegeven. Afschaffen van de nachtploeg in 1996 is er één van. In plaats daarvan werd het 7 dagen per week 24 uur.

Directeur speelt voor operator Als je de foto s in de Schakel en 2N wilt geloven zijn directeuren de operators. Als er een nieuwe machine in gebruik genomen wordt, staat er altijd wel een directeur de knoppen te drukken of boter kaas en eieren te spelen. Systeemprogrammeurs en chefs willen ook nogal eens achter het console plaatsnemen voor de foto. Of we zien een lege zaal die suggereert dat alles vanzelf gaat. Zelfs als de mensen die op de foto gingen bij de computerafdeling horen (Huub Klunder met een bezoekster, Coby Schoneveld), zie je ze nog niet bezig met het dagelijkse werk. Want als je operator was op de 1401, de 650 of later op de kleine systemen dan stond je ponskaarten in te lezen, uren achter elkaar. Of je stond volle dozen zebrapapier leeg te printen. En als I/O operator sleepte je met tapes en diskpacks. De glamour van de man die achter het console de computer bediende ging ook voor de console operator niet helemaal op. Natuurlijk bediende je het console, maar meestentijds was je met JCL bezig. En die stond in de begin jaren echt nog op kaart. Pas nadat een paar jaar met de 158 was gewerkt gingen beeldschermen voor de bediening een rol spelen. En kon je zittend een mountopdracht doorsturen aan je collega bij de tapes. Uiteindelijk kon de console operator het hele netwerk bedienen vanuit zijn stoel. En in 2005 zelfs een zaal in Arnhem vanuit WP. De verantwoordelijkheid s avonds en s nachts hoeft meestal niet gedeeld te worden, iedereen is blij als hij thuis mag zitten. Maar bij incidenten overdag bemoeit Jan en alleman zich er mee. In de beginjaren stond er dan ineens een systeemprogrammeur op de vloer die het overnam, maar later verdwenen de consoles soms onder je handen vandaan, omdat iemand van Telecom of Systeemprogrammering zonder overleg besloot het van je over te nemen.

Werkvoorbereider Het meest verguisde vak binnen de automatisering. Als we bijvoorbeeld dit stukje tekst uit het Otto Dicke verhaal uit 1970 lezen wordt de werkvoorbereider in de laatste alinea wel heel makkelijk weggezet. In het boekje met functies uit 1973 krijgen we een heel wat meer afgewogen beeld van de werkvoorbereider. De lastigste taak was (en is) het accepteren van de rundiagrammen, de nieuwe programma s van de systeemontwerpers. Natuurlijk is er al die jaren een perfecte beschrijving geweest van wat er aan documentatie aanwezig moest zijn bij overdracht, maar als er ergens tegen gezondigd werd, was het hier tegen. Het maken van JCL en de documentatie voor de uitvoering was niet moeilijk, maar wel als de programmeurs de programma s over de schutting gooiden. Of op het laatste moment nog een wijziging hadden die echt die avond nog mee moest. Ook de operator die de bijgevoegde instructie niet las, maar gewoon begon, waardoor die job over moest, gaf veel irritatie. Handleidingen Het Handboek Operations uit 1972 dat Jan van den Broek (hiernaast rechts op de foto samen met Dik Heikoop) bewaard heeft, is onderdeel van een Handboek A.C. De eerste wijzigingsmededeling is van 12 mei 1972. Samensteller is de afdeling AO van het AC, maar de afdelingen S.O.S (Systeem Ondersteuning Systeemontwikkeling) en Productie Algemeen zijn in eerst instantie verantwoordelijk. In 1976 kunnen er ook richtlijnen opgenomen worden voor de overige werkzaamheden van de sector Produktie en de naam luidt daarom voortaan Richtlijnen voor de sector Produktie (RSP). Naast algemene regels (niet roken op de zaal, ieder is verantwoordelijk voor orde en netheid) is er een hoofdstuk voor Noodsituaties, een beschrijving van alle computers en de randapparatuur, de aanwezige software en hoe te handelen bij allerlei voorkomende situaties. De inhoudsopgave 16-1-74 geeft de details. Het voorbeeld van een jobbegeleidingsformulier met de instructie over invullen geeft de mate van detail aan waar het handboek zich mee bemoeide. En de kontakten tussen WVB (Werkvoorbereiding), Computers en KK (Kontrole Kontakt) zeggen iets over de wijze van communicatie in die tijd.

In het overzicht van Joop Hakkennes uit 1979 worden ook de richtlijn overdracht aan produktie genoemd in het Handboek AC. Er wordt op dat moment een begin gemaakt met het HBSO, waarvan Hakkennes opmerkt dat het vervaardigen in een tamelijk strakke planning moet plaatsvinden, om te voorkomen dat een soort Handboek AC ontstaat met veel tabbladen en weinig inhoud. Of deze opmerking zo lelijk bedoeld is als hij er staat, zal altijd wel een geheim blijven. In een memo van 1986 van Jan van der Linden staat een voorstel voor een andere hoofdstukindeling van het HBSO, waarbij het bestaande hoofdstuk 1.6.3. Overdracht aan Produktie wordt genoemd. In 1988 bestaat het uit blz. 10 t/m 90. De invoering van Endevor in 1992 zorgt voor een stroomlijning van de overdracht, de invoering van Changemanagement in 1994 verhoogt de grip van de uitvoering op wijzigingen. Al vonden vele systeemontwikkelaars het maar ambtenarij, zeker toen eind 1999 de hele overdracht ook nog eens door de directie moest worden goedgekeurd i.v.m. de eeuwwisseling. (dat duurde trouwens maar twee maanden). Hulpmiddelen uitvoering Scheduling en Tapemanagement. Huub Klunder vertelt hoe de gang van zaken was voor er sprake was van een schedulingspakket: Voordat een schedule/planningspakket werd ingevoerd, werd als volgt gewerkt. De afdeling Planning van Fred Desmet maakte aan de hand van aan hen toegestuurde opgaven per plandag een overzicht waarop de jobs stonden die op een bepaalde plandag moesten draaien. Hierbij waren jobs die zonder afhankelijkheid direct konden draaien. Uiteraard stonden er ook jobs op die een afhankelijkheid hadden, bijvoorbeeld van invoer van Invoerverwerking. Deze jobs werden pas aangeboden aan het systeem op het moment dat de invoer aanwezig was. Voor de onderlinge afhankelijkheid tussen jobs werd gebruik gemaakt van het door Dik Heikoop geschreven programma "COMMANDS". Hiermee konden jobs worden geactiveerd of reset. Dit programma was dan het laatste programma van een totale job met programma s.

Voordat CA1 werd gebruikt, werden aan de hand van de joblogs de nummers van gemaakte tapes genoteerd en ingevoerd in de tapeadministratie. Dit pakket voorzag ook in een opgave van tapes die weer vrij kwamen, dus waarvan de retentieperiode was verstreken. Er was geen enkele koppeling tussen de tapeadministratie en de catalog, zoals dat bij CA1 wel het geval is. In 1987 wordt het scheduling pakket UCC 7 geïnstalleerd. Dit pakket wordt later omgedoopt tot CA 7. In de plannen voor 1993 wordt een overgang aangekondigd naar OPC/ESA, het scheduling pakket van IBM. In 1988 neemt CA1 de plaats in van de tapeadministratie. Netview Dit pakket voor de controle van het netwerk werd in 1988 ingevoerd. BUNDL In 1991 wordt Bundl ingevoerd, een pakket voor de distributie van de output. Dick de Paus schrijft er een stukje over. Endevor In 1992 wordt Endevor ingevoerd, een pakket om overdrachtsprocedures tussen verschillende omgevingen te standaardiseren. TOS Kompas geeft bij monde van de werkgroep Endevor een samenvatting van het systeem. SMS (System Managed Storage) SMS maakt het mogelijk de specificaties van bestanden los te koppelen van de karakteristieken van de opslagmedia. Bestanden kunnen gewoon op schijf staan, gecomprimeerd op schijf staan, of op tape zijn gearchiveerd. Dit pakket vroeg een stevige conversie, maar gaf een nieuwe kijk op het opslaan van gegevens. In 1994 geeft Kleywegt een toelichting op dit pakket waarvan de invoering gestart was. In 1995 nog wat meer details in IT Kompas. Insluitstraat Machines om output te verwerken zijn er al zo lang er printers bestaan. Hak- en burstmachines waren er al in de Hollerithtijd. Later kwam daar de insluitmachine bij. Salarisstroken, winstbrieven, belastingopgaven, er kwamen steeds meer formulieren die automatisch ingesloten en verzonden konden worden. In 1992 wordt er een moderne insluitstraat geïnstalleerd. In 1994 wordt er een selectief reprint programma gemaakt, om door de insluitstraat kapot gemaakte formulieren over te maken, zonder de klant lastig te vallen. Aad van der Spek (voormalig Postbanker) nu bij AN

AS/400 Er was in de loop van de jaren rondom de S/38 een produktieafdeling ontstaan bij Leven. Nadat de eerste online koppeling naar het mainframe in 1981 was gemaakt nam het aantal toepassingen hand over hand toe. Binnen enkele jaren stonden er drie machines, en het aantal operators groeide mee. In de kwaliteitskrant Blijvend Beter uit 1989 staat een stukje over de servicegerichte afdeling Produktie. Hierbij wordt ook even de ploegendienst aangetipt. Er waren bij Leven minder regels waar de operators zich aan moesten houden. Er moest zeker in het begin wat meer geïmproviseerd worden en dat werkte door in de totale aanpak van de afdeling. Afzetten tegen het logge apparaat van het AC was normaal. De overkomst van Ger Leentfaar (zie foto), die jarenlang leiding gegeven had bij AC Produktie, kon die mentaliteit niet veranderen. Toen dan ook de AS/400 in 1991 verplaatst werd naar WP, voelden de meeste operators er niets voor om overgeplaatst te worden. Ze wilden, nadat ze de kennis hadden overgedragen, weer terug. Na zes maanden gebeurde dat ook. Uiteindelijk bleef er maar één operator bij AN. Het duurde dan ook even voordat alle ploegen de trucjes van de bediening van de AS/400 onder de knie hadden, dit tot grote verontwaardiging van de oude AS/400 ploeg, die soms met stijgende verontwaardiging meekeek vanaf de Helpdesk Leven. Nadat alle procedures, vooral die van Postinfo nog eens op een rijtje gezet waren, werden alle SLA s voor de AS/400 weer ruimschoots gehaald. Tegenwoordig wordt de AS/400 niet alleen voor Leven maar ook voor de Postbank en de RVS gebruikt.

De ponskamers In 1956, bij een uitvoerige behandeling van de Ponskaartenadministratie, wordt voor het eerst een foto gemaakt van een ponstypiste bij De Nederlanden. Maar toen waren ze al een paar jaar aan het werk. Na de oorlog werden op alle ponskamers in Nederland vrouwen in dienst genomen om ponsformulieren om te zetten in ponskaarten. In de verzekeringswereld en ook bij NN is het altijd een vrouwenberoep geweest. Middenin het mannenbolwerk, wat de automatisering in het begin was, zaten daar veertig tot vijftig, overal het algemeen jonge, meisjes en vrouwen, met veel lawaai ponskaarten aan te maken. Het lawaai kwam van de machines, want tijdens het ponsen kon je niet praten. In 1958 wordt mevrouw Schuijer benoemd tot chef de bureau op de ponsafdeling. Dat blijft ze tot ze in 1968 met pensioen ging. Maar dan is het wel in 1963 één van de ponskamers van het AC geworden. Van Hoewijk volgt haar op. De andere ponskamer is uiteraard ontstaan uit die van de Nationale. Er waren daar heel wat dames nodig vanaf het moment dat de 650 administratie voor individueel ingevoerd werd. Die conversie vroeg nogal wat ponskaarten (minimaal zes per verzekering). Een kijkje in de ponskamer in 1966 laat slechts een klein gedeelte van de afdeling zien, en dan ook nog op de rug. Het eerste concrete aantal dat we kunnen vinden dateert van 1969, dan zijn er 41 dames in Rotterdam. Ans Wagenaar heeft daar de leiding. In datzelfde jaar krijgen we ook nog een overzicht van een groter gedeelte van de zaal dan in 1966. Met bezoek van buitendienst mensen. Die moesten altijd op de ponskamer kijken, zeker nadat in 2N deze foto met Lenie Luneberg gestaan had. Dat zou je nu toch niet moeten flikken, met als onderschrift dat er nog veel fotogenieke schatjes rondlopen bij NN. In 1973 hebben we een organisatieschema waarin Wagenaar (zie foto hiernaast) de algehele leiding heeft van beide ponskamers, met in Rotterdam Steylen en in Den Haag Van Hoewijk als direct verantwoordelijke. Een fotootje uit 1974 in Den Haag genomen laat de Univac apparatuur zien en de 026 en 029 van IBM. Tegen die tijd worden de ponsmachines langzaam maar zeker vervangen door MDS apparatuur. Hierbij worden de gegevens vastgelegd op tape. De tape wordt s avonds naar het rekencentrum gebracht. Begin jaren tachtig wordt de tape vervangen door een RJE aansluiting, de gegevens gaan rechtstreeks naar de computer in KG.

De allerlaatste ponsmachine (Univac) heeft nog heel erg lang eenzaam en alleen verstopt in een hoekje op de grote Ponszaal in HKR gestaan. Deze stond er voor noodgevallen die nog op ponskaarten moesten worden verwerkt. Deze machine heeft er zeker tot 1985 gestaan. Tussen 1970 en 1980 is het verschrikkelijk druk op de ponskamers. Er is veel verloop, dus er komen ook veel nieuwe dames binnen. Op elke introductiecursus zitten wel een paar ponstypistes. Vooral augustus en september waren dé maanden. Ze doen mee met de introductie van de gebouwen waar ze in werken, want met het AC hebben ze eigenlijk niet zo n band. In de tachtiger jaren zien we de teruggang van de centrale ponskamers. Interactieve invoer wint veld, langzaam maar zeker verdwijnt de ponsinvoer. In Den Haag gaat het harder dan in Rotterdam, het begint in 1980 met de AVP, het eindigt in 1989 met de restadministratie. Maar dan is de Haagse ponskamer al lang opgeheven (1979), alles wordt nu naar Rotterdam gestuurd. In 1990 draagt het AC de ponskamer over aan Leven, Wim Combé wordt verantwoordelijk, en mag afbouwen. Maar eerst moet er nog even verhuisd worden naar de Zalmstraat, totdat DP klaar is. Ans Wagenaar verdwijnt in 1993 naar de telefooncentrale in HKH, en Irene Oostrum mag, samen met de chef van EXO, Henk de Jong, de laatste loodjes dragen. Ze wegen zwaar omdat er niet voor iedereen vervangend werk is. Dat geeft een vervelende sfeer op het laatst. In 1994 is het voorbij. De laatste LEGO mutaties, werksoort 7500, worden ingevoerd en overgezonden. Irene vertrekt als laatste, naar INO als administratief medewerkster. Naast de ponskamer was er nog invoer op de boekhouding. Die gebruikte daar eerst boekhoudmachines, later een Philips X 1150 voor. Bij De Vaderlandsche stond Nixdorf apparatuur. Dat zal dan wel een Nixdorf 820 geweest zijn. Als aanvulling hier de persoonlijke herinneringen van Irene herself. Die heeft het echt allemaal meegemaakt. Van ponstypiste tot secretaresse MT Op 18 september 1972 ben ik in dienst gekomen na een open sollicitatie. Na een test werd ik geplaatst op de Ponskamer voor het riante salaris van fl 315,00 voor 5 dagen. Toen waren we nog verplicht om één dag in de week deel te nemen aan partiële leerplicht, dus moest ik 1/5 van mijn salaris inleveren. Hetgeen neerkwam op een salaris van fl 252,00 en daar ging nog iets van inhoudingen af waardoor ik ongeveer fl 220,00 per maand kreeg. Belastingen hoefden we vanwege onze jonge leeftijd nog niet te betalen. De eerste werkdag Het ging al meteen mis, ik moest me melden op de Prinses Beatrixlaan 15 voor een introductie ochtend. Dit stond in mijn bevestiging. Doordat ik halverwege de maand begon (18 september 72) hadden ze niet in de gaten dat er dan géén introductie werd gehouden. Dus ik weer op mijn vouwfiets naar de Groenhovenstraat waar de Ponskamer zetelde. Aan de slag Doodnerveus mocht ik beginnen met oefeningen. Op een handkar zelf een ponskaart er in stoppen en de cijfertjes 1-2-3-4 uit den treuren intoetsen. Het ging heel erg zwaar en als je een hele grote

stapel had gedaan moest je dit laten controleren door de cheffin Mw. Van Hoewijk. Ze maakte dan een mooie stapel en keek dan door de gaatjes of deze allemaal op dezelfde plaats zaten. Als dat zo was dan mocht je verder met de volgende cijfertjes 2-3-4-5. En zo ging je door tot je alle cijfers van 1 t/m 0 (de 0 was het laatste cijfer) had gehad. Na 2 weken had ik het wel gezien en wilde ik graag op een echte ponsmachine gaan werken. Dit verzoek werd ingewilligd. Ik mocht op de IBM 29 simpel ponswerk gaan doen. Een machine die direct een gaatje maakte van het cijfer of de combinatie die je had ingetoetst. We sloegen heel vaak mis, dus er gingen heel wat ponskaarten de prullenbak in. Na hier weer een maandje op te hebben gewerkt wilde ik weer een stapje verder en mocht ik op de Univac 2410 gaan werken. Dit was een snellere machine met geheugen. Je toetste eerst alles in en als de kaart eruit werd gespuugd werden ook de gaatjes in de kaart gestanst. Op deze machines werd ook controle geponst. De stapel kaarten die door de beginners waren geponst werden weer in de machine gestopt en de cijfercombinaties of letters werden weer ingetoetst. Wanneer er een fout was aangetroffen ging er een rood lampje branden en moest er een nieuwe kaart gemaakt worden. Van ponskaart naar magnetische tapes Medio 1973 werd in de Rotterdamse ponskamer gestart met het MDS (Mohawk Data entry Systeem). Dit was een systeem bestaande uit een CPU, Diskdrive en een tape unit. Alle gegevens die normaliter op ponskaarten werden ingetoetst werden nu opgeslagen onder een batchnummer op de disk. Door middel van een toetsenbord en een klein beeldschermpje kon je zien wat je intoetste. Ook konden de records, zoals de ponskaarten daarna werden genoemd, worden verlengd van 80 characters naar 125. Zelfs records van 250 posities (characters) konden worden gemaakt. Door een supervisor werden de batches op een tape gezet die vervolgens met de pendel naar de computerruimte in de Groenhovenstraat werden gebracht. Elke werksoort had een eigen tape die voorzien was van een tapelabel zodat de operators wisten welke werksoort ze ontvingen. Nadat we allemaal een weekje naar Rotterdam waren gezonden om te leren werken op het MDS systeem werd ook in Den Haag dit systeem neergezet. Er werden 2 supervisors aangesteld. Bep van der Winden van de Haagse ponskamer en Johanna Smits kwam over uit Rotterdam. Met de ingebruikname van het MDS systeem ging Ans Wagenaar de scepter over de Haagse en Rotterdamse Ponskamer zwaaien. Dit zorgde voor de nodige commotie, want deze dame wist wel

van wanten. Wie niet luisteren wilde, kon haar carrière elders gaan voortzetten (ontslag). Met hoogrode wangen en het zweet in mijn handen ging ik door met mijn werk. Er was in de periode heel veel achterstand. We hebben met ca. 150 datatypistes (verdeeld over Rotterdam en Den Haag), met heel veel overwerk, uitbesteding van werkzaamheden aan Service Bedrijven en zelfs met avondploegen, de achterstanden kunnen wegwerken. We werkten toen al met planningsroosters, want dagwerk moest dezelfde dag nog gedraaid worden op de computers. We hadden ook maand-, week-, kwartaal- en jaarwerk. In die periode zijn ook LABORA en LEGO ingevoerd. Om er nog een paar te noemen: Hypotheken, Restadministratie, Medisch Fonds, ER, Fatum, Brand, AVLI en OVLI, HIS, CIS, Bromfietsverzekeringen, etc. Ook de tijdverantwoording (PROMPT) van de programmeurs werd door ons verwerkt. Evenals de programma s (Cobol) die door onze programmeurs werden geschreven werden door ons ingevoerd. Het was niet altijd even makkelijk om die rare teksten in te toetsen. Na een maand of 6 vroeg Ans Wagenaar of ik Supervisor wilde worden. Hier had ik wel oren naar en zo werd ik gedurende een jaar ingewerkt. Ik leerde hoe je de data van disk op tape kon zetten, maar ook hoe je programma s kon maken. Deze programma s zorgden ervoor dat er blanks (skippen) kwamen waar blanks moesten en ook het uitvullen met nullen kon je helemaal voorprogrammeren. Ook vaste gegevens kon je opgeven en alfabetische en numerieke velden kon je van te voren bepalen. Na een jaar werd ik bij de directeur, Dhr. Van Wijk, geroepen en kreeg ik mijn officiële benoeming tot Supervisor. Dit werk heb ik tot medio november 1990 gedaan. Toen was de Invoerverwerking al in de afbouwfase en zaten er nog slechts 6 dames op de afdeling. Deze zijn later elders binnen ons bedrijf geplaatst of hebben ontslag genomen. Verplicht pauze houden Als je zulk geestdodend werk doet, ben je verplicht om elk uur een kwartier rust te houden. Omdat het vervelend is om elk uur van het werk te moeten, werd er na 2 uur werken een half uur pauze ingesteld. Dit werd meteen gecombineerd met één kop koffie s ochtends en s middags één kop thee. Ik weet nog goed dat de serveerster (de koffie of thee werd toen nog uitgeserveerd) niet eerder dan de afgesproken tijd de afdeling op mocht komen. Zij stonden dan ook geduldig te wachten totdat het precies 10.00 uur of 14.45 uur was. Liefde op het werk Onder de jonge meiden (tussen 15 en 20 jaar) bloeide altijd wel iets moois op. Er was dan ook een periode van verlovingen, van huwelijken en later van zwangerschappen. Ook met de programmeurs (die hun correcties ) kwamen brengen werd hevig geflirt en afspraakjes gemaakt in de