We have some programs that use COBOL External variables. Can anyone point me at a document that lets me know (in reasonable detail) how these get implemented? I understand that the BLX cells are populated at program startup, for programs that use them, and can guess what needs to happen, but there my knowledge ends.
This is of particular interest as we're getting an intermittent failure in a scenario that uses External variables. CSECT IGZCIPS fails S0C4 (at offset X'1C2'), but all BLW cells for the COBOL program that invokes it are populated, implying that Working-Storage has been obtained. However all BLX cells in the (COBOL) module are null at point of failure. Caller was compiled with Enterprise COBOL 4.2, called with 3.4. Any clues?
Many thanks in advance!
This topic has been locked.
4 replies Latest Post - 2011-10-31T20:08:06Z by uskobus
Pinned topic COBOL External Variables
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2011-10-31T20:08:06Z at 2011-10-31T20:08:06Z by uskobus
brataj 100000816340 PostsACCEPTED ANSWER
Re: COBOL External Variables2011-08-05T20:47:46Z in response to PeteInOxfordIGZCIPS is responsible for setting up (or rediscovering already set up) EXTERNAL items the first time a compile unit is invoked. Although EXTERNAL items are defined in the WORKING-STORAGE section, they are actually allocated on a list of EXTERNALs by name.
If IGZCIPS abends and the BLX's are null, that would imply that IGZCIPS failed before it was able to define/rediscover some EXTERNALs, possibly because EXTERNAL metadata has been overlayed, for example because of length-incompatible EXTERNAL items.
If an EXTERNAL A when initially defined is shorter than a subsequent definition A', and the longer A' version is fully initialized, it may overlay whatever EXTERNAL B is on the EXTERNALs list after A. The next time IGZCIPS comes along the list will have a bad pointer in it.
PeteInOxford 270002TGF825 PostsACCEPTED ANSWER
Re: COBOL External Variables2011-08-06T11:39:13Z in response to bratajMr. Rataj,
Thanks very much for a splendidly helpful and informative post; I've marked my question answered.
But if I might impose further ... this seems to imply that the metadata for EXTERNAL items is contiguous with those items in storage (hence the possibility for corruption of said metadata). Must EXTERNAL items always be declared in the same order in the various compile units, and (for variable-length items only) am I correct in assuming that it's the maximum (i.e. declared) size of the item, not it's current length, that gets checked? I know what I think happens, but I'd like to be sure, if you don't mind.
I'd have a modest bet the problem I'm seeing is the result of array overflow in an EXTERNAL area, if I understand what you're saying correctly.
Thanks again for your reply. Have a preen - you've earned it.
brataj 100000816340 PostsACCEPTED ANSWER
Re: COBOL External Variables2011-08-07T01:28:47Z in response to PeteInOxfordHi Pete,
I don't know the exact details of the data structures, just that they're allocated dynamically the first time an EXTERNAL is encountered. Whether the metadata is contiguous or not, an overlay of data can of course still damage metadata, since both are allocated from the LE heap, usually in order of ascending address.
The WORKING-STORAGE could also be a source of the overlay, and is possibly more likely than an EXTERNAL vs EXTERNAL overlay as outlined previously
The EXTERNALs don't need to be given in the same order in each compile unit, as they're tracked individually by 01 level name, and yes, allocated by maximum length. The manual says the base definitions of all uses of an EXTERNAL must be the same, but that's not really checked as far as I know.
I intended to comment in my previous reply that you should compile with SSRANGE to catch a possible overlay, but hit PostMessage too early...
uskobus 1200009JF72 PostsACCEPTED ANSWER
Re: COBOL External Variables2011-10-31T20:08:06Z in response to bratajYou will get a S level runtime error if you try to define two variables with the same name and different lengths for external variables. The lenght is set on the execution of the first program that has the variable defined in it. When it finds an external variable, it must check to see if it has been allocated already. If it has, it checks to make sure the size is the same for the variables. If it hasn't been allocated, then will will allocate it and that is the size that all other programs must use for that run.
IGZ0066S The length of external data record data-record in program
program-name did not match the existing length of the record.
If you are having an 0C4, you more than likely have an overlay problem. Those are one of the hardest to track back to who did the overlay. If you are blowing up in an IBM module, you may need some help with from IBM to figure out what went wrong since you don't have their source or know what that module is doing.