XPLINK restrictions
- In general, XPLINK-compiled objects cannot be statically bound
with non-XPLINK-compiled objects. A program object (or load module)
consists of either XPLINK objects or non-XPLINK objects.
The one exception to this is when an XPLINK function calls a function defined as either OS_UPSTACK or OS_NOSTACK. In this case the called function is non-XPLINK and uses OS linkage conventions. However, since the bind step of XPLINK and non-XPLINK executables uses different data sets (see Planning to link-edit and run), all external references from the non-XPLINK function must be resolved using the XPLINK link-edit data sets. For example, if a called OS_UPSTACK function makes a call to the C runtime (RTL), the C RTL function must be resolved via the CELHS003 side deck in SCEELIB. It cannot use the SCEELKED static stubs since these are not used to bind XPLINK objects.
The intent of OS_UPSTACK is to be able to call a non-XPLINK function that is not going to be recompiled or rewritten as XPLINK, but is itself a leaf routine and does not make any further calls. The intent of OS_NOSTACK is to call non-XPLINK functions that only need an OS linkage register save area, and are either leaf routines or make calls to other system services that do not use the Language Environment stack.
- XPLINK Assembler programs cannot resolve the address and environment
of other XPLINK functions in order to call them. If a function pointer
is passed to an XPLINK Assembler program, it can be used to call that
function as long as XPLINK calling conventions are used (see z/OS Language Environment Vendor Interfaces).
There is currently no CALL macro support for XPLINK.
The intent of the XPLINK Assembler support is to be able to call an Assembler function that was rewritten using XPLINK conventions (either for performance reasons or to perform some function not easily implemented in C or C++), but is itself a leaf routine and does not make any further calls.
- Calls between XPLINK and non-XPLINK functions are allowed when they cross program object (or load module) boundaries. The use of DLLs is the primary method, where a function in a non-XPLINK DLL calls another function in an XPLINK DLL (or vice versa). The fetch() function also provides compatibility between XPLINK and non-XPLINK functions.
- The following do not support calls to XPLINK functions:
- COBOL dynamic call
- PL/I FETCH
- XPLINK functions can only call non-XPLINK functions that are also Language Environment-conforming, that is, they were compiled using a Language Environment-conforming compiler.
- XPLINK applications must run AMODE 31, so the ALL31 runtime option will be forced ON. This means all non-XPLINK applications that can call or be called by an XPLINK application must also run AMODE 31.
- Make a reference from XPLINK code into non-XPLINK code only if the reference is by an imported function or variable, or the function pointer is a parameter into the XPLINK code. This prevents incompatible references to a non-XPLINK function entry point.
- XPLINK applications must be built using the DFSMS Binder, and they must reside in either a PDSE or the HFS. The Prelinker cannot be used to create an XPLINK application.
- The following environments and subsystems do not support applications
that have been compiled XPLINK:
- Releases of CICS® TS before CICS TS 3.1 (Running applications under CICS )
- DB2® stored procedures cannot be compiled XPLINK (Running applications under DB2 )
- A nested (child) enclave must run with the same XPLINK environment as its parent (Using nested enclaves)
- The CEEBXITA and CEEBINT user exits cannot be XPLINK (Using runtime user exits
- PICI
- System Programmer C (SPC)
- C Multitasking Facility (C MTF)
- PL/I Multitasking