Omdat de meeste programma’s met ‘jaar 2000’-fouten in Cobol zijn geschreven, denken veel mensen dat alle ellende de schuld is van die programmeertaal. Dat is absoluut niet waar, zoals Cobol-goeroe Jerry Garfunkel regelmatig benadrukt.
Om te beginnen vormen de applicatieprogramma’s maar een deel van het probleem. Datumproblemen in besturingssystemen, middleware, utiliteiten, batchroutines en bibliotheken zijn in aanleg net zo problematisch als de applicaties. Zoals iedereen inmiddels wel weet ligt de oorzaak van de problemen met de applicaties in het representeren van 1995 door de twee cijfers 95, waarbij de aanname is dat de 1 en de 9 daaraan voorafgaan. Het is niet voldoende om de datum door een viercijferig datumveld te vervangen; de analyse en correctie van berekeningen met datums vormt een veel gecompliceerder vraagstuk!
Het probleem met legacy-applicaties is dus geen kwestie van Cobol, maar van programma-ontwerp. Het is onafhankelijk van de taal. C-programma’s zijn eenvoudigweg niet zo erg aangetast als Cobol-programma’s doordat er niet zoveel van zijn en doordat ze relatief kort geleden geschreven zijn met viercijferige datumvelden, terwijl sommige Cobol-programma’s al tientallen jaren oud zijn. Omdat C vergeleken met Cobol een syntactisch zwakke taal is (voor transactiesystemen dan), is het een goede zaak dat er zo weinig legacy-programma’s van bestaan. Anders zou het probleem nog veel moeilijker op te lossen zijn. Het feit dat legacy-systemen in Cobol nog zijn aan te passen, is in feite al een bewijs voor de superioriteit van deze taal.
Het is moeilijk in te schatten welke invloed Cobol heeft gehad op de levensduur van – vooral de grotere – applicaties. Toen hij dertig jaar geleden werd geïntroduceerd was hij de helderste taal die er bestond, en dat is nog steeds zo. Juist hierdoor werden Cobol-programma’s steeds verder uitgebreid en gewijzigd. Achteraf bezien is dat een vergissing geweest, omdat de bedrijfsfuncties zich verder hebben ontwikkeld en er al veel eerder totaal nieuwe applicaties ingevoerd hadden moeten worden. Alleen belangrijke architecturale veranderingen als relationele databases of client/server-systemen hebben geleid tot echt nieuwe applicaties. De technologie heeft teveel invloed gehad, zakelijk denken te weinig. Het is echter te gemakkelijk om de overcomplexiteit van veel legacy-applicaties aan Cobol te wijten. De echte oorzaak van het probleem zijn de systeemontwerpers.
Er zijn een paar serieuze tools op de markt die ondersteuning kunnen bieden bij het analyseren en corrigeren van Cobol-code. Hetzelfde geldt in mindere mate voor andere talen, zoals PL/1, RPG en 4GL’s. Dat is te danken aan het feit dat de meeste legacy-applicaties in Cobol geschreven zijn, waardoor dat de grootste markt is. In alle gevallen zijn er, onafhankelijk van de taal, ook testtools nodig. Gelooft u de claims van de leverancier van uw pakketten dat al uw utiliteiten en operationele systemen in orde zijn, of zou u ze toch liever eens testen?
De meeste ‘jaar 2000’-zorgen concentreren zich op grote applicaties, vandaar de nadruk op Cobol. Zijn de kleine zakelijke systemen en afdelingsapplicaties echter wel betrouwbaar? Over het algemeen zijn ze nieuwer en zouden ze geschreven moeten zijn met een viercijferige jaarrepresentatie. Hier domineren echter de onleesbare talen, zoals C en Visualbasic. Die zouden vrij moeten zijn van ‘jaar 2000′-problemen, maar als dat niet zo is, zal de reparatie veel lastiger zijn dan bij Cobol-programma’s. De leesbaarheid van Cobol-programma’s is in jongere talen opgeofferd aan slimheid.
De academische wereld is grotendeels verantwoordelijk voor de huidige programma’s. Academici concentreren zich op ‘informatica’ en gaan voorbij aan zakelijke gegevensverwerking zoals die in de praktijk plaatsvindt. Systeemtalen op laag niveau, zoals C, overheersen. Daardoor stromen nieuwkomers de IT-industrie in zonder teamervaring, zonder kennis van middleware, zoals transactiemonitors, en zonder enig idee van wat het concept ‘onderhoudbare code’ inhoudt. Professionals die beter moeten weten zijn opgeklommen tot het de management en ontvluchten zo hun verantwoordelijkheden.
De behoefte aan diverse talen is evident. C is ideaal voor het schrijven van devicedrivers, C++ is perfect voor het bouwen van beheertools en tekstverwerkers, en visuele gui-editors zijn goed voor het ontwerpen van gebruikersinterfaces. Voor het ontwikkelen van zakelijke applicaties en nieuwe servercomponenten lijkt Cobol echter weer de beste keuze. Dit impliceert dat Cobol geen dode taal mag worden; voortdurende ontwikkeling is noodzakelijk. De eisen ten aanzien van ‘jaar 2000’-reparaties hebben al een richting aangegeven. Intrinsieke functies worden in de taal opgenomen en objecttechnologie wordt toegepast. Deze en andere eigenschappen zullen deel uitmaken van de nieuwe standaardtaal Cobol 2000, en in eerdere versies al opduiken.
De conclusie luidt dat de noodzakelijke aandacht voor Cobol inzake het ‘jaar 2000’-probleem als katalysator kan dienen voor het opnieuw uitstippelen van Cobol-strategieën voor nieuwe applicaties. De combinatie van server-routines in Cobol en gui-clients in Java is zeer aantrekkelijk.
