COBOL er kendt for at være det mest udbredte programmeringssprog i verden i hvert fald på IBM mainframen. I betragtning heraf kunne man godt have tænkt sig en gennemgribende modernisering af sproget. Der er også gjort en hel del forsøg. Man kan nu lave objekt orienteret COBOL. Lige så snart noget er objekt orienteret, ja så skal det kunne indkapsle data, der skal kunne overleve fra kald til kald. Det pudsige ved COBOL er, at indholdet af working storage i de fleste runtime versioner af COBOL rent faktisk overlever fra kald til kald. Der har været forskelle på CICS og batch runtime af COBOL, men med Language Environment bør det være således, at working storage altid overlever fra kald til kald.
Der findes faktisk en datastruktur, man kan erklære i working storage, som man kan være 100% sikker på overlevelsen af uanset batch eller CICS og uanset runtime version. Den hedder EXTERNAL. Erklæringen er meget simpel:
Der er en stor ulempe ved EXTERNAL og det er, at man ikke må bruge VALUE i en datastruktur, der er erklæret som EXTERNAL. Det er derfor udefineret, hvad en EXTERNAL datastruktur indeholder fra starten. Jeg benytter derfor altid en eyecatcher, som jeg spørger om værdien af. Hvis den ikke indeholder min eyecatcher værdi, ja så antager jeg, at den ikke har været benyttet før. Eyecatcher værdien skal være noget alfanumerisk, der ikke vil forekomme i andre sammenhænge.
Det rigtig geniale ved EXTERNAL er, at man kan benytte en EXTERNAL datastruktur til at kommunikere data mellem to programmer, der ikke kalder hinanden. Forestil dig hovedprogram A, der kalder underprogram B og underprogram C. Du kan definere den samme EXTERNAL datastruktur i B og C uden at erklære den i A og kommunikere data mellem B og C uden at A ved noget som helst om det. For at det virker er kravet, at 01 niveauet hedder det samme i B og C og at de øvrige elementer i datastrukturen er fuldstændig ens. COBOL brokker sig på runtime tidspunktet, hvis den finder ud af, at to EXTERNAL strukturer med samme navn ikke er ens defineret. Hvis de ikke har samme navn, ja så kan COBOL ikke kommunikere data. Det er altså muligt at have mange EXTERNAL datastrukturer i samme program.
Når først man har fanget ideen i EXTERNAL, så er der mange rigtig gode anvendelsesmuligheder. Lige for tiden benytter jeg EXTERNAL til at kommunikere data mellem udvalgte hovedprogrammer og underprogrammer, hvor der er flere lag af programmer i mellem hovedprogrammet og underprogrammet. Hvis underprogrammet bliver kaldt i andre sammenhænge, hvor EXTERNAL strukturen ikke er erklæret, så opdager underprogrammet det ved at se om eyecatcheren er udfyldt med den rigtige værdi.