Multipart program objects

Under certain circumstances, the binder will create a program object with multiple segments. When loading this type of module, each segment has a different load point. The binder currently uses RMODE and time of load (initial or deferred) of the classes as the criteria for splitting a module into segments. If all input is from traditional object modules (not XOBJ or GOFF) or load modules, a multipart module is created only if RMODE(SPLIT) is specified. If using the assembler CATTR support to create user-defined text classes (supported only in GOFF object format), or if GOFF or XOBJ object modules from a compiler are part of the input, there can be text classes other than B_TEXT. The RMODE of these additional text classes is used to assign each of these classes to a segment. In addition, deferred load classes, such as C_WSA, are each placed in a separate segment. There is no binder external to override this division into segments. Certain restrictions apply to multipart modules.

If you use the capabilities of the High Level Assembler or the binder RMODE(SPLIT) option to create multipart program objects, certain restrictions apply.

If the module is the target of a directed load (where the issuer of the LOAD is providing the storage in which to load the module), the two class segments are concatenated and loaded into storage as a single unit.
All entry points (primary and alternate) must be defined in the same class.
If parts of the program will reside above 16 MB, then you must ensure that the entire module can execute with AMODE(31) or that linkage between sections on opposite sides of the 16 MB line use BASSM or equivalent instructions to force an AMODE switch when necessary.
A binder option, HOBSET, will cause the high order bit on V-type address constants to be set according to the addressing mode of the target.
Overlay format is incompatible with multipart program objects.

If a multipart program object is subsequently loaded through a directed load or by the binder, all text classes are loaded into consecutive storage locations according to the minimum RMODE value for all loaded classes.