The Binding Process

The binding process improves runtime performance as program objects are able to use static procedure calls to routines already bound as part of a program object. Dynamic program calls are not needed to access the routines. Individual module objects created by different ILE HLL compilers can be bound together in the same program object allowing for a routine to be coded in the most appropriate language and then bound to a program object that requires it.

Previously compiled module objects can be bound in various sequences to create new runnable program objects. The previously compiled module objects can be re-used to create new runnable program objects without having to recompile the original source program. This allows a module object to be re-used as needed.

Instead of re-creating programs each time a module object changes, service programs may be used. Common routines can be created as service programs. If the routine changes but its interface does not, or if only upward compatible changes are made to the interface, then the change can be incorporated by re-creating the service program. The program objects and service programs that use these common routines do not have to be re-created.

There are two paths that allow you to create a program object using the binding process. The diagram below shows the two available paths:
Figure 1. Two paths for creating a Program Object
Path 1 uses CRTCBLMOD and CRTPGM. Path 2 uses CRTBNDCBL.

These two paths both use the binding process. The Create Program (CRTPGM) command creates a program object from module objects created from ILE COBOL source programs using the Create COBOL Module (CRTCBLMOD) command, and zero or more service programs.

Note: Module objects created using the Create RPG Module (CRTRPGMOD), Create C Module (CRTCMOD), and Create CL Module (CRTCLMOD) commands can also be bound using Create Program (CRTPGM).
The Create Bound COBOL (CRTBNDCBL) command creates one or more temporary module objects from one or more ILE COBOL compilation units, and then creates one or more program objects. Once the program object is created, CRTBNDCBL deletes the module object(s) it created. This command performs the combined tasks of the Create COBOL Module (CRTCBLMOD) and Create Program (CRTPGM) commands in a single step. Previously created module objects and service programs can be bound using a binding directory. However, the input source member bound using this step must be the PEP module.
Note: Every program object only recognizes one PEP (and one UEP). If you bind several module objects together to create a program object using CRTPGM and each of these module objects has a PEP, you must specify in the ENTMOD parameter, which module object's PEP is to be used as the PEP for the program object. Also, the order in which module objects and service programs are specified in the CRTPGM command affects the way symbols are resolved during the binding process. Therefore, it is important that you understand how binding is performed. For more information on the binding process, refer to the ILE Concepts book.

A binding directory contains the names of modules and service programs that you may need when creating an ILE program or service program. Modules or service programs listed in a binding directory are used when they provide an export that can satisfy any currently unresolved import requests. A binding directory is a system object that is identified to the system by the symbol *BNDDIR.

Binding directories are optional. The reasons for using binding directories are convenience and program size.
  • They offer a convenient method of packaging the modules or service programs that you may need when creating your own ILE program or service program. For example, one binding directory may contain all the modules and service programs that provide math functions. If you want to use some of those functions, you specify only the one binding directory, not each module or service program you use.
  • Binding directories can reduce program size because you do not specify modules or service programs that do not get used.

Very few restrictions are placed on the entries in a binding directory. The name of a module or service program can be added to a binding directory even if that object does not yet exist.

For a list of CL commands used with binding directories, see the ILE Concepts manual. Characteristics of a *BNDDIR object are:
  • Convenient method of grouping the names of service programs and modules that may be needed to create an ILE program or service program.
  • Because binding directory entries are just names, the objects list does not have to exist yet on the system.
  • The only valid library names are *LIBL or a specific library.
  • The objects in the list are optional. The named objects are used only if any unresolved imports exist, and if the named object provides an export to satisfy the unresolved import request.