Binder processing

You can bind any z/OS® XL C/C++ object module or program object.

Object files with long name symbols, reentrant writable static symbols, and DLL-style function calls require additional processing to build global data for the application. You can always rebind if you don't require this additional processing. You can also re-bind if you used the binder for this additional processing and produced a program object (in other words, you didn't use the prelinker). If you used the prelinker and performed this additional processing, you cannot later rebind. If you have done additional processing and output it to a PDS, you cannot rebind it. For further information, refer to About prelinking, linking, and binding.

Various limits have been increased from the linkage-editor; for example, the z/OS V1R6 binder supports variable and function names up to 32767 characters long.

For the Writable Static Area (WSA), the binder assigns relative offsets to objects in the Writable Static Area and manages initialization information for objects in the Writable Static Area. The Writable Static Area is not loaded with the code. Language Environment® run time requests it.

For C++, the binder collects constructor calls and destructor calls for static C++ objects across multiple compile units. C++ linkage names appear with the full signature in the binder listing. A cross-reference of mangled versus demangled names is also provided.

For DLLs, the binder collects static DLL initialization information across multiple compile units. It then generates a function descriptor in the Writable Static Area for each DLL-referenced function, and generates a variable descriptor for each DLL-referenced variable. It accepts IMPORT control statements in its input to resolve dynamically linked symbols, and generates an IMPORT control statement for each exported function and variable.

The C++ compiler may generate internal symbols that are marked as exported. These symbols are for use by the runtime environment only and are not required by any user code. When these symbols are generated, if the binder option is DYNAM=DLL and the definition side-deck is not defined for the binder, the binder issues a message indicating the condition. If you are not building a DLL, you can use DYNAM=NO or you can ignore the message; or you can define a dummy side deck for the binder and then ignore the generated side deck.
Note: When binding a DLL in z/OS UNIX System Services, specify -Wl,DLL on the command line.

The z/OS UNIX file system support allows a library search of archive libraries that were created with the ar utility. UNIX files can be specified on binder control statements or specified directly on the compiler invocation command line.

C/C++ code is rebindable, provided all the sections are named. You can use the CSECT compiler option or the #pragma csect directive to name a section. If the GOFF option is active, then your CSECTs will automatically be named. See CSECT | NOCSECT.
Note: If you do not name all the sections and you try to rebind, the binder cannot replace private or unnamed sections. The result is a permanent accumulation of dead code and of duplicate functions.

The RENAME control statement may rename specified unresolved function references to a definition of a different name. This is especially helpful when matching function names that should be case insensitive. The RENAME statement does not apply to rebinds. If you rebind updated code with the original name, you will need another RENAME control statement to make references match their definitions.

The binder starts its processing by reading object code from primary input (DD SYSLIN). It accepts the following inputs:

During the processing of primary input, control statements can control the binder processing. For example, the INCLUDE control statement will cause the binder to read and include other code.

Among other processing, the binder records whether or not symbols (external functions and variables) are currently defined. During the processing of primary input, the AUTOCALL control statement causes a library to be immediately searched for members that contain a definition for an unresolved symbol. If such a member is found, the binder reads it as autocall input before it processes more primary or secondary input.

After the binder processes primary input, it searches the libraries that are included in DD SYSLIB for definitions of unresolved symbols, unless you specified the options NOCALL or NORES. This is final autocall processing. The binder may read library members that contain the sought definition as autocall input.

Final autocall processing drives DD SYSLIB autocall resolution one or two times. After the first DD SYSLIB autocall resolution is complete, symbols that are still unresolved are subject to renaming. If renaming is done, DD SYSLIB autocall is driven a second time to resolve the renamed symbols.

After the binder completes final autocall (if autocall takes place), it processes the IMPORT control statements that were read in to match unresolved DLL type references. It then marks those symbols as being resolved from DLLs.

Finally, the binder generates an output program object. It stores the program object in a z/OS UNIX file, or as a member of the program library (PDSE) specified on the DD SYSLMOD statement. The Program Management Loader can load this program object into virtual storage to be run. The binder can generate a listing. It can also generate a file of IMPORT control statements for symbols exported from the program that are to be used to build other applications that use this DLL.