COBOL V5, Change In Behavior Caused S0C4 In ODSZUPDZ

[Ed_Arnold]

We had a report of ODSZUPDZ recompiled with COBOL V5 and S0C4's were being received.

(Thanks go to COBOL support for the following explanation.)

It turns out that when module ODSZUPDZ is built with the COBOL 5.1 compiler, it has a deferred segment. 

The module ODSXUPDZ is loaded (via a directed load) in ASID x and the LFMD for it is built in this ASID with a valid loader token. 

Later CEEPPOS tries to load the deferred segment of the module for which LE does not have addressability to the LFMD, because the LFMD resides in ASID x, but the deferred segment is being attempted to be loaded in ASID y. 

The only solution thus far is to add the module into LPA. 

When the module is loaded from LPA, the LFMD is built in common storage that can be accessed from any ASID and allows it to work.

Ed

[cmodpuser]

Ed, some more detail about the case:

The problem with ODSXUPDZ recompiled with Cobol 5.1 was:
Loading reports from JES2 spool was functioning since ODSXUPDZ exit is loaded in the ARSLOAD address space.
The S0C4 was only happening during AFP load batch job (arsload in batch).

The module had to be added to dynamic LPA to make this work. You can't have PDS/E in LPA.

ODSXUPDZ is Cobol version of ARSUUPDZ provided by IBM Services.

[Ed_Arnold]

The following Technote has been published on this subject:

http://www-01.ibm.com/support/docview.wss?uid=swg21972988

Ed