Program object formats

The program object formats can be specified by the COMPAT option. The main purpose of the COMPAT option is to notify the binder to generate a program object (PO) at a particular program-management (PM) level.

When a COMPAT level is specified in terms of the z/OS system release, it corresponds to a specific program-management level and program management sub-level (such as PM4SUB3). For best results, specify the z/OS system. This can also be done to request a specific program management sub-level. For example, while COMPAT=PM4 can be used instead of COMPAT=ZOSV1R3, using COMPAT=PM4SUB3 results in an error; COMPAT=ZOSV1R7 must be used instead. The following table shows the corresponding z/OS system releases and program management levels.
Table 1. z/OS system releases, their corresponding program management levels, and features added
z/OS system release Program management level and sub-level Summary of features added
Start of changeZOSV2R5,End of change ZOSV2R4, ZOSV2R3, ZOSV2R2, ZOSV2R1 PM5SUB4 COMPAT=ZOSV2R1 is the minimum level that supports preserving all boundary alignments specifications coming from ESD records. ALIGNT can be used to specify boundary alignments for both load modules and program objects without requiring the use of COMPAT(ZOSV2R1).
ZOSV1R13 PM5SUB3 COMPAT=ZOSV1R13 is the minimum level that supports conditional sequential RLDs.
ZOSV1R12, ZOSV1R11, ZOSV1R10 PM5SUB2 COMPAT=ZOSV1R10 is the minimum level that supports saving the timestamp from compiler IDRL records in program objects. It also supports the RLD type corresponding to the assembler QY-con. The QY-con is a special form of QCON representing the displacement in RXY type instructions.
ZOSV1R9, ZOSV1R8 PM5 COMPAT=PM5 is the minimum level that supports cross-segment references in relative immediate instructions in program objects.
CAUTION:
Programs bound with this option cannot be loaded, inspected, or reprocessed on any version prior to z/OS® 1.8.
ZOSV1R7 PM4SUB3 COMPAT=ZOSV1R7 is the minimum level that supports relative/immediate instructions across compile units or compression of non-program data.
ZOSV1R6, ZOSV1R5 PM4SUB2 COMPAT=ZOSV1R5 is the minimum level that can be specified if RMODE 64 has been specified by a compiler for deferred load data segments.
ZOSV1R4, z/OSV1R3 PM4 COMPAT=PM4 is the minimum level that can be specified if any of the following features are used:
  • Input modules contain 8-byte adcons
  • Any ESD record is AMODE 64
  • Input contains symbol names longer than 1024, unless EDIT=NO
  • A value of 64 is specified on the AMODE option or control statement
If COMPAT=PM4 and OVLY are both specified, COMPAT=PM4 is changed to PM1. PM4 supports all PM3, PM2 and PM1 featurzes.
ZOSV1R2, ZOSV1R1, OSV2R10, OSV2R9, OSV2R8 PM3 COMPAT=PM3 is the minimum level that can be specified if any of the following features are used:
  • Binding modules compiled using the XPLINK attribute
  • DYNAM=DLL
  • XOBJ format input to the binder without going through the Language Environment® prelinker, or rebinding modules containing input from such sources
  • Hidden aliases (from ALIASES control statement)
  • Support for both deferred load classes and merge classes with initial text (from GOFF format input modules or data buffers passed by way of the binder API.)
  • Language Environment-enabled programs
If COMPAT=PM3 and OVLY are both specified, COMPAT=PM3 is changed to PM1. PM3 supports all PM2 and PM1 features.
Not applicable PM2 COMPAT=PM2 is the minimum level that can be specified if any of the following are used:
  • User-defined classes passed in GOFF format input as well as certain other information supported only in GOFF format
  • Names (from input modules or created by control statements which cause renaming) that are longer than 8 bytes.
  • Use of RMODE=SPLIT
If OVLY is specified, COMPAT=PM2 is changed to PM1. PM2 supports all PM1 features.
Not applicable PM1 This is the minimum level which supports binder program objects. In addition to old linkage editor load module features, program object features supported here include the following:
  • Device-independent record format
  • Text length greater than 16 megabytes
  • More than 32,767 external names
OVLY is supported, and will force PM1 to be used.

Clarifying sub-levels

In a case where the program management levels are identical and only the program management sub-levels differ, this indicates that there is new binder functionality; however, none of the program object information that the loader uses is incompatible (only information that the binder uses for rebinding, diagnostics, and so forth is different). Therefore, when considering a COMPAT level, use just the program management level without regard for the sub-level to determine the earliest release on which to use it.

For example, if z/OS V1R7 is targetted with COMPAT=ZOSV1R7, create a PM4SUB3 format program object. Then, in addition to z/OS V1R7, that program object can be run on releases all the way down to z/OS V1R3, because that was the first release to introduce program management level PM4 format (effectively, this is level 4, sub-level 1, or COMPAT level PM4SUB1 format — but the binder does not use the SUB1 designation).

Be aware of the consequences of the program management sub-level when it indicates that there is new binder function, because this means that the only thing that can be done is to run the program.

For example, a format program object that is at COMPAT level PM4SUB3, contains information that only a binder at z/OS V1R7 and above can understand. While the program can run based solely on the program management level, without regard for the sub-level, it cannot be rebound with a binder (the IEWL program, the TSO LINK command, or the UNIX ld utility) at a lower release program management level and sub-level. No other programs running on a lower release z/OS system than that program can use the Program Management Binder services against it. The services include the following:
  • IEBCOPY
  • SMP/E
  • SPZAP
  • Any programs that use the binder APIs (such as the AMBLIST, IEBCOPY, and UNIX utilities cp, mv, c89, and nm)
  • The fast data APIs
  • The binder C/C++ API interfaces introduced in z/OS V1R9.
Any attempt to do so by a properly coded program fails with the following message:
IEW2509S 3602 MODULE *NULL* IDENTIFIED BY DDNAME /0000001 IS AN UNSUPPORTED VERSION 
AND CANNOT BE PROCESSED.
Each program object format that is introduced will support for features that were not previously available and, except for overlay structure, each format will support all features provided by earlier formats. By default, the binder will choose the earliest format supporting all of the features being used. See COMPAT: Binder level option for more information.
Note: As was indicated earlier, the binder also continues to support the old load module format. Note the difference in terminology. A load module is stored in a standard partitioned data set in a format compatible with older operating systems. A program object is stored in a PDSE ( DSNTYPE=LIBRARY) or a z/OS® UNIX file in one of the formats listed above. The choice between load module and program object for binder output is based solely on the output destination.