De meeste software-systemen, zoals besturingssystemen, sorteerroutines, batch- en transactiemonitors, en tools voor geautomatiseerde verwerking, zijn gekocht of onder licentie in gebruik. Alle leveranciers van zulke produkten brengen nu of op korte termijn nieuwe versies uit die gecorrigeerd zijn voor het jaar 2000. Hierbij spelen drie problemen.
Nieuwe en oude software moet parallel draaien totdat alle programma’s en diensten omgezet zijn. Er bestaan verouderde produkten die niet meer ondersteund worden maar nog wel een belangrijke rol spelen voor oude programma’s. Het is niet altijd duidelijk of men produkten moet aanpassen of helemaal opnieuw bouwen, waarbij één modern produkt meerdere oudere zaken vervangt. Het probleem bij het rationaliseren van systeemsoftware is de behoefte om applicaties op maat aan te passen. In dat geval kan het 2000-probleem een goed excuus vormen voor ingrijpende wijzigingen – maar die moeten wel voordeel opleveren. Alle systemen opwaarderen is duur, door de hoge kosten van licenties, conversies en testen.
De applicatiecode valt ruwweg op te splitsen in twee delen: de applicatie- en de operationele programma’s, met name JCL-scripts. Uit vorige conversie-trajecten (bijvoorbeeld VSE naar MVS) blijkt dat organisaties de inspanning die het opschonen van batch- en verwerkingsroutines kost vaak onderschatten. Kijk daarom naar vorige conversies om probleemgebieden en de benodigde middelen in te schatten.
Een probleem voor de software-leveranciers zijn de licenties. Veel produkten hebben een licentie voor een bepaalde periode en stoppen ermee als deze niet vernieuwd wordt. Dit impliceert dat ze data berekenen – hopelijk de juiste!
Daarnaast moet men de applicatiecode zelf aanpakken. Dat zal veel discussie opleveren. De algemene opinie is dat investeringen in software-tools essentieel zijn. Het probleem is te grootschalig voor een sequentiële benadering; daarbij zou men miljoenen regels code moeten bestuderen. Als een organisatie het werk intern verricht, kan ze zulke tools aanschaffen. Die zijn immers algemeen toepasbaar voor het opschonen van code, al dienen ze nu voor één specifiek probleem. Het is verstandig om ook na 2000 oude code op te schonen, bijvoorbeeld bij elke grote upgrade. Als het werk wordt uitbesteed aan een specialistisch softwarehuis, moet dat de tools hebben. Zelfs dan is intern enige softwarematige ondersteuning nodig, om de toestand van bestaande code te beoordelen.
Wijziging van de code biedt de kans om standaarden te verbeteren. Veel applicaties gebruiken code die bestaat uit een mengsel van subroutine-calls, code die is ingevoegd vanuit copy books en hard-gecodeerde in-line routines. Verder is sommige code in oudere versies van een programmeertaal geschreven. Deze versies zullen geen intrinsieke functies voor datumberekening ondersteunen. Recente compilers ondersteunen wel Ansi-standaarden, zowel voor de datum-formaten als voor de syntax van datum-gerelateerde berekeningen. Dit is de kans om standaard-routines te introduceren, gebruik makend van één van de bibliotheken die opportunistische softwareleveranciers momenteel aanbieden. Deze code moet aangepast worden voor het gebruik van intrinsieke functies, die op hun beurt gemeenschappelijke bibliotheken benutten. Directe subroutine-calls mogen alleen gebruikt worden als intrinsieke functies niet beschikbaar zijn. Hard-gecodeerde routines moet men in elk geval opsporen en vervangen door standaard-code.
Dit alles is afhankelijk van de taal. Daardoor zullen aanzienlijke verschillen ontstaan in het bereik en de kwaliteit van de beschikbare tools. Cobol wordt redelijk ondersteund, want het gros van de zakelijke toepassingen is daarin geschreven. Verder zijn de Ansi-standaarden goed gedefinieerd en worden ze in ruime mate ondersteund voor de code-conversie. Andere talen, zoals PL/1 en 4GL’s als Natural, Sapiens en Mantis, krijgen minder aandacht van de industrie, maar de ontwikkelaars zullen er zeker aandacht aan besteden. Assembler-programma’s zijn een knelpunt, omdat het 2000-probleem en de tools om deze programma’s te analyseren en te wijzigen nog steeds een enorm probleem vormen.
Systeemtalen als C en C++ zouden weinig problemen moeten opleveren. Ze zijn echter op grote schaal misbruikt voor applicatie-ontwikkeling. Omdat die talen zelf weinig functies voor zakelijke applicaties bieden, zijn veel verschillende procedure- en klassebibliotheken in gebruik. De taal zelf is dus niet het probleem, maar het grote aantal inconsistente en vaak krakkemikkige bibliotheken. Ook de grote verschillen in syntax om deze routines en objecten aan te spreken kunnen een nachtmerrie worden. Gezien de beschikbaarheid van Cobol had men C nooit voor zakelijke toepassingen mogen gebruiken. Het is te laat om applicaties opnieuw te bouwen in Cobol; tools voor C en C++ zijn dus nodig. Misschien kunnen commerciële applicatie-ontwikkelaars op dit vlak hulp krijgen van ingenieurs en andere experts uit technische disciplines. Aan Visualbasic durf ik niet eens te denken!
