Alcatel Bell te Antwerpen - onderdeel van het Franse bedrijf Alcatel Alsthom - houdt zich ondermeer bezig met het maken van telefoons en telefooncentrales. De service-afdeling GZ5 startte in februari 1995 het project P2000 om het 2000-probleem op te lossen. GZ5 voert P2000 uit met eigen mensen, zonder voor de gelegenheid extra scan-hulpmiddelen te kopen, en met alleen een MSP-methodmanager repository als hulpmiddel voor projectcoördinatie. Dit artikel beschrijft alleen de werkzaamheden op het mainframe.
De hardware van Alcatel bestaat uit IBM-mainframes, een aantal AS/400's en PC's. De databasemanagement-infrastructuur van het mainframe bestaat voornamelijk uit IMS en DB2 met Cobol en PL1. Onder de verantwoordelijkheid van GZ5 vallen circa 75 systemen. Deze bestaan gezamenlijk uit ongeveer vijftien duizend programma's.
GZ5 gebruikt de methodmanager repository van MSP om de DB2- en de IMS-systemen te documenteren. Ook worden alle databases vanuit deze repository gegenereerd. Op deze wijze is precies bij te houden welke systemen en programma's welke gegevens gebruiken. Met name de mogelijkheden van de repository om versies bij te houden zijn van belang. Voor een te behandelen systeem wordt een kopie van de metadata gemaakt. Die krijgt een aparte ruimte in de repository. Deze repository wordt tijdens P2000 op twee manieren ingezet. Hij dient om de projecten te plannen en te coördineren. Tijdens de projectplanning bekijkt men welke bestanden door welke systemen worden gebruikt. Later gaat men tijdens het P2000-onderhoud na welke velden werkelijk met een datum van doen hebben. Deze worden dan gewijzigd en de relevante database-definities worden opnieuw uit de repsoitory gegenereerd.
P2000
Het grootste probleem is het coördineren van de projecten die systemen converteren, die wellicht gegevens van andere systemen gebruiken.
Het uitgangspunt bij de planning van de conversies zijn de bestanden en niet de programma's. Bij GZ5 zijn de systemen ook afhankelijk van elkaar, omdat bestanden worden gebruikt door programma's uit meerdere systemen. In de repository staan alle systemen gedocumenteerd met hun programma's, de gebruikte bestanden en de relaties ertussen. Aan de hand hiervan bepaalt men welke systemen en programma's daarvan in behandeling genomen worden.
Nadat voor een zekere stap is vastgesteld welk systeem geconverteerd zal worden, bepaalt men de te converteren bestanden daarvan of van een gedeelte ervan. Een belangrijk aspect hierbij is de tijd die nodig zal zijn om in een later stadium de conversie van de bestanden uit te voeren. Omdat in Antwerpen het rekencentrum actief is voor alle vestigingen van Alcatel, spelen tijdsverschillen een belangrijke rol en blijft er een interval van acht uur over om de conversie uit te voeren. In Mexico werkt men tot zaterdagmiddag (mid-Europese tijd); in Azië begint men alweer vroeg in de zondagnacht. Deze relatief kleine periode bepaalt voor een belangrijk deel welke bestanden in een zekere conversiestap meegenomen zullen worden.
Op basis van de gekozen bestanden stelt men vast welke programma's bewerkt zullen worden. Deze kunnen of een onderdeel zijn van het systeem dat onder behandeling is, of deel uitmaken van een ander systeem, maar wel de te converteren bestanden gebruiken. Die laatste programma's worden dan alleen aangepast voor zover het de bestanden uit het te converteren systeem betreft. Dit betekent wel dat een programma meerdere keren wordt geconverteerd. De coördinatie en registratie van al die wijzigingen vereisen de inzet van de MSP-repository, waarin de relatie tussen de programma's en toepassingen beschreven staat.
Andere informatiebehoeften ontstaan tijdens de werkelijke uitvoering van de conversie-projecten. Een voorbeeld daarvan is de vraag: welke velden hebben 'datum', 'dat' of 'jaar' in de naam staan en aan welke programma's in welke systemen zijn die velden gerelateerd? Hierbij moet men er wel rekening mee houden dat met dergelijke vragen in het algemeen niet alle velden te vinden zijn. Velden worden soms met een datum gevuld zonder dat dit uit de naam blijkt, of zonder dat dit oorspronkelijk de bedoeling was. Bekend in dit opzicht is een veld 'kleur-van-de-auto' van een programma voor schadebehandeling. Dit veld werd nooit ingevuld. Toen men om een veld verlegen zat waarin werd aangegeven op welke datum de claim door een tussenpersoon naar de maatschappij was gestuurd, ging men dit veld gebruiken. Een inventarisatie bij de Nederlandse verzekeringsmaatschappij Zilveren Kruis wees uit dat aan circa 5 procent van de velden niet te zien was dat het voor een datum werd gebruikt. Bij het achterhalen van die velden zal men gebruik moeten maken van bestaande documentatie - in repositories en elders - en van systeemdeskundigen. Zij zijn vaak de enigen die weten hoe een programma velden gebruikt.
Repository
In het begin van het 2000-project was het van belang om inzicht te krijgen in de tijd die de conversie-activiteiten in beslag zouden nemen. Daartoe ontvingen de systeemverantwoordelijken een lijst van hun systemen en de gegevens die deze gebruiken, bestaande uit programma's en job-flows. Deze lijst was gegenereerd vanuit de repository. De vraag daarbij luidde: hoeveel tijd kost het om de aanpassingen in de programma's te maken? Aanvankelijk had men enigszins de neiging om het probleem te onderschatten. Het zijn toch maar data, werd gezegd. Maar men raakte toch snel overtuigd van de ernst van de zaak. Niet alleen berekeningen en sorteringen zouden verkeerd gaan lopen, ook veel schermen zouden aangepast moeten worden. Vooral volle schermen zouden overvol raken als de zes-cijferige datum werd vergroot tot een veld van tien karakters. De systeemverantwoordelijken hadden de repository en hun eigen documentatie ter beschikking om dit uit te zoeken. In de repository stonden wel alle velden opgeslagen met relaties naar de bestanden waarin ze werden gebruikt. Aan een veldnaam is echter niet altijd af te zien waarvoor hij wordt gebruikt. Zo kan het veld ps_status_no gebruikt worden voor de datum waarop een status is gewijzigd.
Een bijkomend effect was het opschonen van programma's. Ongebruikte programma's werden verwijderd.
Planning
Nadat de systeem-verantwoordelijken de gegevens hadden aangeleverd, werd een planning opgesteld. Een belangrijke eis was dat het laatste systeem halverwege 1999 geconverteerd moest zijn.
De volledige conversie werd ingedeeld in stappen van een maand. Per maand zouden één of meer systemen in bewerking worden genomen. Op deze basis werd de planning opgesteld, waarbij het acquisitie-systeem de hoogste prioriteit kreeg en daarna verzending en facturering.
Een ander aspect van de planning was dat systemen alleen tegelijkertijd in conversie genomen zouden worden als het zeker was dat ze niet gemeenschappelijk gegevens in gebruik hadden. De repository leverde de invoer voor deze controle.
Ook werd het zo geregeld dat de bij de conversie betrokken mensen - in de loop van het project waren dat alle ontwikkelaars - daar niet langdurig mee bezig zouden zijn. De reden daarvan is dat de vastgestelde conversietijd van een maand impliceert dat er onder druk gewerkt moet worden, waardoor geen tijd overblijft voor onderhoudswerk en nieuwe ontwikkelingen.
Nadat de planning was opgesteld, heeft het management zijn goedkeuring gegeven aan de eerste stap. Voor de volgende stappen zal steeds afzonderlijk goedkeuring gevraagd moeten worden. Het gaat immers om een traject van vijf jaar, waarin veel kan veranderen. Systemen kunnen worden herschreven of door pakketten vervangen. Van de planning afwijken is mogelijk, bijvoorbeeld door de aanschaf van een pakket dat een systeem vervangt. De consequenties zijn echter voor de gebruiker.
Conversiestap
Een conversiestap begint met activiteiten van de gegevensbeheerder. Hij zorgt ervoor dat de gegevens van het betreffende systeem naar een deel van de repository worden gekopieerd. Daar staan ze ter beschikking van het project. Op deze wijze is het mogelijk dat strikt noodzakelijk onderhoud ook nog kan plaatsvinden op systemen die in P2000-conversie verkeren. Het is nu vanuit beide omgevingen mogelijk om databases en dergelijke te genereren.
Tijdens de analyse van de programma's stellen de systeemverantwoordelijken en systeem-analysten een lijst op van de velden die betrekking hebben op de datum en die gewijzigd moeten worden. Deze lijst gaat naar de gegevensbeheerder en de databasebeheerder. Zij zorgen voor het genereren van nieuwe databases, segmenten, record-layouts enzovoort.
Na vier weken wijzigen en testen worden de produktiegegevens geconverteerd op zondagochtend tussen één en negen uur.
Uitvoering
De eerste twee conversiestappen zijn nu uitgevoerd. De eerste stap betrof een commodity-systeem. De gegevens hiervan worden door veel andere systemen gebruikt. Dit project werd als eerste gekozen om vertrouwd te raken met de problematiek van de complexiteit. De tweede stap betrof een systeem bestaande uit circa vijfhonderd programma's. Hiermee werd ervaring opgedaan met het converteren van een groot systeem.
Deze twee stappen zijn zonder vertragingen uitgevoerd. Alles verloopt nu nog volgens de planning. De projectleiding omschrijft het belang van de repository als volgt: "het gebruik van de repository garandeert een wijziging van hoge kwaliteit en een dekking van 100 procent betreffende te wijzigen databases."
Durk Gardenier is operations manager bij MSP te Oosterhout.
Om te kunnen beoordelen moet u ingelogd zijn: