- z/OS Language Environment 64-bit Support Overview
Compared with 31-bit applications, we are seeing more exciting new technologies happen for 64-bit z/OS applications. It not only allows applications to access larger memory range (for C/C++, Java, COBOL and PL/I), but also brings new modern languages (Python, Node.js, Go and Java 11 on z/OS are 64bit only) and experiences for users.
However, you may need to know some key differences between 31-bit and 64-bit applications, to help you to manage them in a more efficient way.
- z/OS 64-bit Application Environment and considerations
- Installation
With 64-bit support introduced, LE now consists of three forms:
- Base form: 24-bit & 31-bit addressing, standard LE linkage
- 31-bit XPLINK form: 31-bit addressing, XPLINK linkage
- 64-bit form: 64-bit addressing, XPLINK linkage
We have no new datasets introduced for 64-bit support, and just add new members with the CELQ prefix in existing datasets, summarized as follows:
SCEERUN2 contains new members CELQLIB (Combined both 64bit CEL & C runtime), CELQV004 (64bit COBOL runtime) and CELQV011 (64bit PL/I runtime);
SCEEBND2 contains LE resident routines for AMODE 64 applications;
SCEELIB contains side-decks for AMODE 64 DLLs provided by LE.
- Compile and Bind considerations
AMODE 64 only supports XPLINK linkage. The only object file format supported is GOFF. Only Program Management Binder can be used to perform the bind process for AMODE 64 applications. The Binder converts an object module into an AMODE 64 executable program and stores it either in a PDSE or a Unix directory.
The following picture shows the register use and linkage
|
GPR1-3
|
arguments (depending upon type)
|
|
GPR4
|
the caller's stack frame in the downward-growing stack. This is biased and actually points to 2048 bytes before the real start of the stack frame.
|
|
GPR5
|
the called routine's environment pointer
|
|
GPR6
|
the entry point in the called routine if the call was made by a BASR instruction
|
|
GPR7
|
the return point in the caller's routine. The return point also contains information to determine if the call was made via BASR or branch relative
|
|
GPR8-15
|
preserved
|
|
FPRs
|
arguments (depending upon type)
|
|
VR24-31
|
arguments (depending upon type)
|
- Runtime Option considerations
The list of available runtime options in 64-bit is reduced.
Some 31-bit options that are not required for 64-bit support have been removed (e.g. ALL31, LIBSTACK). If 31-bit only option specified, message will be issued by LE to indicate the error.
Some 24/31-bit runtime options remain, while their defaults may be changed (e.g. POSIX default changed from OFF to ON, STORAGE –4th sub option, reserve stack size, is ignored; always 1MB above the bar)
Several AMODE 64 specific runtime options are added, to support both stack and heap storage above the bar.
- 64-bit stack considerations
Used by both LE and applications, for C/C++ and PL/I local variables and COBOL LOCAL-STORAGE.
All stacks are downward growing (XPLINK). Stack storage is a contiguous one big chunk, you need to specify its maximum size with STACK64 runtime option.
Maximum size allocated at thread initialization plus a 1M guard area. When a 64bit program starts, all stack storage guarded except initial size. “Increments” achieved by reducing size of guard area. Initial/increments/maximum size rounded up to 1MB.
- 64-bit heap considerations
The algorithm to maintain individual heap segments remains the same as before, and pointers and sizes doubled when managing an above the bar heap segment, and 64bit heap segments are on 1MB boundaries.
64bit user heap mainly used by user application, 64bit library heap used internally by Language Environment, 64bit I/O heap internally by Language Environment I/O services.
APIs are provided to obtain below the bar and below the line storage for 64bit applications: __malloc31() to obtain user heap storage below the bar, and __malloc24() to obtain user heap storage below the line.
- 31-bit and 64-bit interoperability
To extend the life and value of existing 31bit applications and to accelerate the creation of new 64bit services, 31-bit and 64-bit interoperability support is introduced.
This solution introduces new services (CWIs) in Language Environment (LE), that make use of the LE pre-initialization environment to establish the runtime environment of the complementary addressability mode and then continue to reuse this established environment for any subsequent calls. This provides the framework for language and addressing mode interoperability.
The new interfaces would then be exploited by the application runtime libraries such as the Java Native Interface (JNI) shipped as part of the IBM Java SDK and by various subsystems like IMS and WAS, thereby making the interoperability between addressing modes transparent to the application developer.
Below is a picture that shows how 31bit COBOL and 64bit Java can interact with each other transparently with this solution.
Moving z/OS applications to 64-bit is a long journey. By knowing those key characteristics of 64-bit environment will help you better managing your applications.