Option to prevent inadvertent use of LINKAGE-SECTION data items prior to establishing addressability

It is important for all to realize that uninitialized LINKAGE-SECTION data structures are not "undefined", rather, they DIRECTLY map and address IBM control block IHAPSA.  Here's some additional information from IBM regarding this control block and changes that have been made over time.

User Application starts failing after migrating from z/OS 2.4 to z/OS 2.5 or a newer release (ibm.com)

User Application starts failing after migrating from z/OS 2.4 to z/OS 2.5 or a newer release

Troubleshooting

Problem

At z/OS 2.5, a change was made to several non-programing interface (IBM-only) fields in the first page of the Prefixed Save Area (PSA) storage, which resides at virtual storage address 0 on any central processor (CP).  This storage is sometimes referred to as “low core”.   This change was intentional and necessary and did not affect any Programming Interface (PI) fields.  However, the change has exposed errors in application programs which historically have been perceived as working, but in fact have been inadvertently accessing and using the content of these IBM-only fields. Typically, this happens as a result of the erroneous program using an instruction base register content of zero rather than the intended value, leading to an access of storage at some displacement into low core.  If one of these changed fields is the target of the inadvertent access, the erroneous program may experience different results when executing on z/OS 2.5  or a newer release than it did when executing on z/OS 2.4 .

As an example, let’s assume the following instruction sequence in a program:

L        R5,MYBLOCK@           Retrieve address of my control block from a location in storage
L        R6,4(,R5)                      Load the content of the field at offset +4 into my control block
LTR   R6,R6                            Test whether loaded value is zero
BNZ  EXITPGM                      If non-zero, exit program

In this instruction sequence, if the content of storage area MYBLOCK@ is zero (perhaps due to the field not yet being initialized), this would lead to an inadvertent access of low core by the second load instruction.  At z/OS 2.4, a non-zero value would have been loaded into register 6, with the result being that the program would have branched to label EXITPGM.  At z/OS 2.5 and newer releases, register 6 would be loaded with a value of 0, resulting in the program continuing execution instead, likely with unexpected results.  In either case (at z/OS 2.4 or newer releases), the program was not performing correctly, but at z/OS 2.4, the errant behavior could have gone undetected due to the difference in the data inadvertently retrieved from the low core storage access.

This example demonstrates an assembler program that is in error.  However applications written in a higher level language may experience such a problem as well.  For example, in COBOL, a coding problem that could lead to an inadvertent access of low core storage would be LINKAGE SECTION items (other than parameters) not having addressability, leaving the associated BLL cell (the pointer to the item) having a value of zero.

Symptom

An application program behaves differently after moving from z/OS 2.4 to a higher release of z/OS.

Diagnosing The Problem

Customers experiencing a change in application behavior upon moving from z/OS 2.4 to either z/OS 2.5 or a newer release should review and diagnose their problem code with this possibility in mind.  It may be helpful to refer to this document which describes how to use SLIP Zero Address Detection (ZAD), a z/OS feature that detects and documents execution of an instruction that accesses storage by using an operand address that was formed from a general register containing zero. 

Customers who are not experiencing an application issue but who would like to proactively check for potential exposure in a test environment may also want to consider SLIP Zero Address Detection (ZAD).

Similarly, for detecting possible concerns in assembler programs, assembler option FLAG(PAGE0) may be helpful.  This option instructs the assembler to issue diagnostic warning message ASMA309W when an operand that references storage is resolved to a baseless address (i.e. a reference to low core) where a base and displacement is expected. For fields such as the CVT address (CVTPTR) where such a reference is intentional, the ASMA309W warning message can be suppressed by coding a zero base register:

L    R15,16(,0)

or

L    R15,CVTPTR(,0)

This Idea is being accepted and will be updated again once put into plan.

Hi Brian,

Thank you for submitting this Idea.

We are reviewing it and we are leaning towards to implementing a compile time option that will generate instructions to check for linkage items with an address section of 0 at runtime.

Would that be acceptable?

An important use case for the option is to flag instances where the linkage section structure contains one or more ODO items resident in the group itself. Such references will fail during ALLOCATE or CICS GETMAIN either immediately (eg. out of memory) or some time later (eg. 0C4) that's not clearly connected to the allocation per se, as the ODO items will come from low memory during a LENGTH OF calculation.

Such cases have increased with z/OS 2.5, which changed location zero from 000A0000 to 00000000 among other changes to the PSA.