Creating a Binder Language Source File - IBM-ILE

Binder language is based on the exports available from modules that are bound into service programs. A binder language source file must contain the following entries:

  1. The Start Program Export (STRPGMEXP) command identifies the beginning of the list of exports from the service program.
  2. Export Symbol (EXPORT) commands identify each a symbol name available to be exported from the service program.
  3. The End Program Export (ENDPGMEXP) command identifies the end of the list of exports from the service program.

The following example shows the structure of a binder language source file:

EXPORT SYMBOL("mangled_procedure_name_a")
EXPORT SYMBOL("mangled_procedure_name_b")
EXPORT SYMBOL("mangled_procedure_name_x")

Note: You must specify the mangled name of each symbol on the EXPORT command, because the binder looks for the mangled names of exports when it tries to resolve import requests from other modules.

Once all the modules to be bound into a service program have been created, you can create the binder language source file. You can write this file yourself, using the Source Entry Utility (SEU), or you can let the iSeries system generate it for you, through the Retrieve Binder Source (RTVBNDSRC) command.

Creating Binder Language Using SEU

You can use the Source Entry Utility (SEU) to create a binder language source file:

  1. Create a source physical file QSRVSRC in library MYLIB.
  2. Create a member MEMBER1 that will contain the binder language
  3. Use the DSPMOD command to display the symbols that can be exported from each module.
  4. Decide which exports you want to make available to calling programs.
  5. Use the Source Entry Utility (SEU) to enter the syntax of the binder language.

You need one export statement for each procedure whose exports you want to make available to the caller of the service program. Do not list symbols that you do not want to make available to calling programs.

For example, based on the information shown in Figure the binder language source file for module SEARCH could list the following export symbols:

EXPORT SYMBOL(" __ct__6SearchFPc")
EXPORT SYMBOL(" __ct__6SearchFPUc")
EXPORT SYMBOL(" __ct__6SearchFPUci")

Creating Binder Language Using the RTVBNDSRC Command

The Retrieve Binder Source (RTVBNDSRC) command can automatically create a binder language source file. It retrieves the exports from a module, or a set of modules. It generates the binder language for these exports, and places exports and binder language in a specified file member. This file member can later be used as input to the EXPORT parameter of the CRTSRVPGM command.

Note:After the binder language has been retrieved into a source file member, you can edit the binder language and modify it as needed, for example, if you make changes to a module, or if you want to make certain exports unavailable to calling programs.

The syntax for the RTVBNDSRC command is:


For detailed information on the RTVBNDSRC command and its parameters enter RTVBNDSRC on a command line and press F1 for Help.

Example of Creating Binder Language With RTVBNDSRC
The following example shows how to create a binder language source file for module SEARCH, located in library MYLIB, using the RTVBNDSRC command.The source code for module SEARCH is shown in “Source Code Files”. RTVBNDSRC MODULE(MYLIB/SEARCH) SRCFILE(MYLIB/QSRVSRC) SRCMBR(ONE)

This command automatically:

  1. Creates a source physical file QSRVSRC in library MYLIB.
  2. Adds a member ONE to QSRVSRC.
  3. Generates binder language from module SEARCH in library MYLIB and places it in member ONE.

Member ONE in file MYLIB/QSRVSRC now contains the following binder language:

Binder Language Source File Generated for Module SEARCH

Binder Language Source File Generated for Module SEARCH

Updating a Service Program Export List
You can use binder language to reflect changes in the list of exports a service program makes available.When you create binder language, a signature is generated from the order in which the modules that form a service program are processed, and from the order in which symbols are exported from these modules. The EXPORT keyword in the binder language identifies the procedure and data item names that make up the signature for the service program.

When you make changes to the exports of a service program this does not necessarily mean that all programs that call this service program must be re-created. You can implement changes in the binder language such that they are backward compatible. Backward-compatible means that programs which depend on exports that remain unchanged do not need to be re-created.

To ensure backward compatibility,add new procedure or data item names to the end of the export list, and recreate the service program with the same signature. This lets existing programs still use the service program, because the order of the unchanged exports remains the same.

Note: When changes to a service program result in a loss of exports, or in a change of existing exports, it becomes difficult to update the export list without affecting existing programs that require its services. Changes in the order, number, or name of exports result in a new signature that requires the re-creation of all programs and service programs that use the changed service program.

Using the Demangling Functions
You can retrieve the mangled names of exported symbols with the RTVBNDSRC command. To help you find the corresponding demangled names, the runtime library contains a small class hierarchy of functions that you can use to demangle names and examine the resulting parts of the name. The interface is documented in the <demangle.h> header file.

Using the demangling functions, you can write programs to convert a mangled name to a demangled name and to determine characteristics of that name,such as its type qualifiers or scope. For example, given the mangled name of a function, the program returns the demangled name of the function and the names of its qualifiers. If the mangled name refers to a class member, you can determine if it is static, const, or volatile. You can also get the whole text of the mangled name.

To demangle a name, which is represented as a character array, create a dynamic instance of the Name class and provide the character string to the class’s constructor. For example, to demangle the name f__1XFi, create:

char *rest;
Name *name = Demangle("f__1XFi", rest);

The demangling functions classify names into five categories: function names, member function names, special names, class names, and member variable names. After you construct an instance of class Name, you can use the Kind member function of Name to determine what kind of Name the instance is. Based on the kind of name returned, you can ask for the text of the different parts of the name or of the entire name.

For the mangled name f__1XFi, you can determine:

name->Kind() == MemberFunction
((MemberFunctionName *) name)->Scope()->Text() is "X"
((MemberFunctionName *) name)->RootName() is "f"
((MemberFunctionName *) name)->Text() is "X::f(int)"

If the character string passed to the Name constructor is not a mangled name, the Demangle function returns NULL.

For further details about the demangling functions, refer to the information contained in the <demangle.h> header file. If you installed ILE C/C++ using default settings, this header file should be in IFS in the ’/QIBM/include’ directory and in DM in ’QSYSINC/H’.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

IBM-ILE Topics