IBM Support

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-programming 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. 
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)
There is also a COBOL compiler option that has been added to detect and prevent possible concerns.  The new COBOL compiler option is LSACHECK, and when that is used the compiler initializes LINKAGE SECTION data item addresses (the BLL cells) to x'7FFFF000' instead of x'00000000' as before.  The result is that if there are LINKAGE SECTION data items whose addressability has not been set, instead of accessing low core and getting possible incorrect results, the program will ABEND with an ABEND0C4 code.  There is no performance overhead at all to using this compiler option, and many users might want to set that compiler option for all of their programs.  Note: No programs should ever be accessing low code addresses by accident, and LSACHECK will catch those cases.

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB56","label":"Z HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG90","label":"z\/OS"},"ARM Category":[{"code":"a8m0z0000000A73AAE","label":"z\/OS-\u003ESupervisor-\u003ESupervisor-\u003EMisc\/Other"}],"ARM Case Number":"","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"2.5.0;3.1.0;and future releases"}]

Document Information

Modified date:
05 February 2025

UID

ibm17162097

Page Feedback