Other considerations

When you compile and link edit a program, the resulting executable is either XPLINK or non-XPLINK. That is, XPLINK-compiled parts and NOXPLINK-compiled parts cannot be link-edited together in the same program object. The one exception to this is the use of the #pragma linkage(OS) directive for C (or extern "OS" for C++). The intent here is to allow the calling of existing assembler programs that typically perform some function that cannot be done in C or C++ without having to rewrite the assembler program using XPLINK conventions (although this could be done if performance is critical, see the topic on "Combining C or C++ and Assembler" in z/OS XL C/C++ Programming Guide). XPLINK and non-XPLINK executables can be mixed at run time, for example by using DLL function calls. An XPLINK function can call a non-XPLINK function in a separate DLL, and vice versa. If needed, glue code is inserted automatically by Language Environment to perform the necessary stack switching and parameter passing adjustments.

The existing static/resident libraries cannot be used when building XPLINK applications. They contain static parts that get resolved by the binder before the entries in the XPLINK side-decks.

The DFSMS binder must be used to create an XPLINK application. The resulting program module exploits the format of the PM3 Program Object.

There are also XPLINK versions of locales and iconv converters which are provided for use by XPLINK applications.

There is a new XPLINK-compiled version of the Curses archive file. It is called libcursesxp.a, and resides in /usr/lib. The usage is the same as the old archive file except the compiler and environment must be set up using XPLINK. The following is an example of compiling test.c with the Curses XPLINK archive:

 c89 -o test -Wc,xplink -Wl,xplink test.c -lcursesexp