COBOL is perhaps the most widespread programming language in the world and on the mainframe there is no perhaps. When taking this into account it would be nice with an update of COBOL. Something has happened though. It is possible to code object oriented COBOL. When a programming language is declared object oriented data structures must be able to survive from one call to another. COBOL has this feature for working storage whether you like or not in most of its implementations on the mainframe and it has been working like this before objects were introduced in COBOL. When using COBOL in CICS you must be aware that working storage does not survive between EXEC CICS LINK calls. You may also get into trouble when mixing COBOL and other mainframe programming languages, but you should be home free if you are using Language Environment (which I hope everybody is nowadays).

Besides this feature of working storage COBOL has a special data structure called EXTERNAL which makes it possible to share a piece of working storage between COBOL programs without using them as parameters. EXTERNAL variables exists for as long as normal working storage and its survival is not dependent on Language Environment (but EXEC CICS LINK spoils the beauty of EXTERNAL variables just like it does for working storage in general). The declaration of an EXTERNAL variable is straight forward:

01 MyExternalDataStructure EXTERNAL.
02 MyEyeCatcher     PIC X(8).
02 MyFirstDataItem  PIC X(10).
02 AndSoOn          PIC X(50).

A huge disadvantage for EXTERNAL variables is that VALUE is not allowed. Therefore the contents of variables in EXTERNAL storage is undefined until values are assigned. Therefore I always use an eyecatcher whose value I test. If the eyecatcher does not contain my eyecatcher value I asume it has not yet been initialised. I choose an eyecatcher value which is alfanumeric and which I beleive will not be used in any other connection.

The brilliant thing about EXTERNAL is the ability to communicate values between programs without having to use parameters. Imagine main program A calling sub program B and C. You can define the same EXTERNAL data sructures in B and C without having to declare them in A and communicate between B and C without having to change anything in A. To make this work the requirement is that level 01 has exactly the same name in all programs to share data between and that the rest of the structure is declared in exactly the same way. COBOL will find out at execution time if two EXTERNAL structures with the same name has different declarations and COBOL will try to abend. If they do not have the same name COBOL cannot communicate data. It is possible to have many external data structures in the same program.

When you have understood the idea of EXTERNAL it has many good uses. For the time being I use EXTERNAL to communicate data between selected main programs and sub programs where many layers of programs exists between the main program and the sub program. If the sub program is called directly or indirectly from another main program the sub program will know because the EXTERNAL data structure has not been declared in those main programs and hence the value of the eyecatcher has not been initialised with the value agreed upon. By testing the value of the eyecatcher in the sub program the sub program has the proper konowledge about how it was called.