This figure compares and contrasts the original program model (OPM) and the Integrated Language Environment (ILE) model.
Structure of an ILE Program
An ILE program contains one or more modules. A module, in turn, contains one or more procedures.
Procedure
A procedure is a set of self-contained high-level language statements that performs a particular task and then returns to the caller. For example, an ILE C function is an ILE procedure.
Module Object
A module object is a nonrunnable object that is the output of an ILE compiler. A module object is represented to the system by the symbol *MODULE. A module object is the basic building block for creating runnable ILE objects. This is a significant difference between ILE and OPM. The output of an OPM compiler is a runnable program.
A module object can consist of one or more procedures and data item specifications. It is possible to directly access the procedures or data items in one module from another ILE object. See the ILE HLL programmer’s guides for details on coding the procedures and data items that can be directly accessed by other ILE objects.
ILE RPG, ILE COBOL, ILE C, and ILE C++ all have the following common concepts:
• Exports An export is the name of a procedure or data item, coded in a module object, that is available for use by other ILE objects. The export is identified by its name and its associated type, either procedure or data. An export can also be called a definition.
• Imports An import is the use of or reference to the name of a procedure or data item not defined in the current module object. The import is identified by its name and its associated type, either procedure or data. An import can also be called a reference.
A module object is the basic building block of an ILE runnable object. Therefore, when a module object is created, the following may also be generated:
• Debug data Debug data is the data necessary for debugging a running ILE object. This data is optional.
• Program entry procedure (PEP) A program entry procedure is the compiler-generated code that is the entry point for an ILE program on a dynamic program call. It is similar to the code provided for the entry point in an OPM program.
• User entry procedure (UEP) A user entry procedure, written by a programmer, is the target of the dynamic program call. It is the procedure that gets control from the PEP. The main() function of a C program becomes the UEP of that program in ILE.
Figure shows a conceptual view of a module object. In this example, module object M1 exports two procedures (Draw_Line and Draw_Arc) and a data item (rtn_code). Module object M1 imports a procedure called Draw_Plot. This particular module object has a PEP, a corresponding UEP (the procedure Draw_Arc), and debug data.
Characteristics of a *MODULE object:
• A *MODULE object is the output from an ILE compiler.
• It is the basic building block for ILE runnable objects.
• It is not a runnable object.
• It may have a PEP defined.
• If a PEP is defined, a UEP is also defined.
• It can export procedure and data item names.
• It can import procedure and data item names.
• It can have debug data defined.
ILE Program
An ILE program shares the following characteristics with an OPM program:
• The program gets control through a dynamic program call.
• There is only one entry point to the program.
• The program is identified to the system by the symbol *PGM. An ILE program has the following characteristics that an OPM program does not have: • An ILE program is created from one or more copied module objects.
• One or more of the copied modules can contain a PEP.
• You have control over which module’s PEP is used as the PEP for the ILE program object. When the Create Program (CRTPGM) command is specified, the ENTMOD parameter allows you to select which module containing a PEP is the program’s entry point.
A PEP that is associated with a module that is not selected as the entry point for the program is ignored. All other procedures and data items of the module are used as specified. Only the PEP is ignored.
When a dynamic program call is made to an ILE program, the module’s PEP that was selected at program-creation time is given control. The PEP calls the associated UEP.
When an ILE program object is created, only those procedures associated with the copied modules containing debug data can be debugged by the ILE debugger.The debug data does not affect the performance of a running ILE program.
Figure shows a conceptual view of an ILE program object. When the program PGMEXAMP is called, the PEP of the program, which was defined in the copied module object M3, is given control. The copied module M2 also has a PEP defined, but it is ignored and never used by the program.
In this program example, only two modules, M1 and M3, have the necessary data for the ILE debugger. Procedures from modules M2 and M4 cannot be debugged with the ILE debugger.
The imported procedures print and SIN are resolved to exported procedures from service programs PRINTS and MATHFUNC, respectively.
Characteristics of an ILE *PGM object:
• One or more modules from any ILE language are copied to make the *PGM object.
• The person who creates the program has control over which module’s PEP becomes the only PEP for the program.
• On a dynamic program call, the module’s PEP that was selected as the PEP for the program gets control to run.
• The UEP associated with the selected PEP is the user’s entry point for the program.
• Procedures and data item names cannot be exported from the program.
• Procedures or data item names can be imported from modules and service programs but not from program objects.
• Modules can have debug data.
• A program is a runnable object.
Service Program
A service program is a collection of runnable procedures and available data items easily and directly accessible by other ILE programs or service programs. In many respects, a service program is similar to a subroutine library or procedure library.
Service programs provide common services that other ILE objects might need; hence the name service program. An example of a set of service programs provided by the operating system are the runtime procedures for a language. These runtime procedures often include such items as mathematical procedures and common input and output procedures.
The public interface of a service program consists of the names of the exported procedures and data items accessible by other ILE objects. Only those items that are exported from the module objects making up a service program are eligible to be exported from a service program.
The programmer can specify which procedures or data items can be known to other ILE objects. Therefore, a service program can have hidden or private procedures and data that are not available to any other ILE object.
It is possible to update a service program without having to re-create the other ILE programs or service programs that use the updated service program.The programmer making the changes to the service program controls whether the change is compatible with the existing support.
The way that ILE provides for you to control compatible changes is by using the binder language. The binder language allows you to define the list of procedure names and data item names that can be exported. A signature is generated from the names of procedures and data items and from the order in which they are specified in the binder language. To make compatible changes to a service program, new procedure or data item names should be added to the end of the export list.
Figure shows a conceptual view of a service program. Notice that the modules that make up that service program are the same set of modules that make up ILE program object PGMEXAMP in Figure 8 on page 18. The previous signature, Sigyy, for service program SPGMEXAMP contains the names of procedures P3 and P4. After an upward-compatible change is made to the service program, the current signature, Sigxx, contains not only the names of procedures P3 and P4; it also contains the name of data item D. Other ILE programs or service programs that use procedures P3 or P4 do not have to be re-created.
Although the modules in a service program may have PEPs, these PEPs are ignored. The service program itself does not have a PEP. Therefore, unlike a program object, a service program cannot be the target of a dynamic program call.
Characteristics of an ILE *SRVPGM object:
• One or more modules from any ILE language are copied to make the *SRVPGM object.
• No PEP is associated with the service program. Because there is no PEP, a dynamic program call to a service program is not valid. A module’s PEP is ignored.
• Other ILE programs or service programs can use the exports of this service program identified by the public interface.
• Signatures are generated from the procedure and data item names that are exported from the service program.
• Service programs can be replaced without affecting the ILE programs or service programs that use them, as long as previous signatures are still supported.
• Modules can have debug data
• A service program is a collection of data items and runnable procedures.
• Weak data can be exported only to an activation group. It cannot be made part of the public interface that is exported from the service program.
Binding Directory
A binding directory lists 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 only if 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 listing the modules or service programs that you may need when creating your own ILE program or service program. For example, one binding directory may list 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.
The more modules or service programs a binding directory lists, the longer it may take to bind the programs. Therefore, you should include only the necessary modules or service programs in your binding directory.
• 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.
Figure shows a conceptual view of a binding directory.
Characteristics of a *BNDDIR object:
• 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 listed do 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.
Binding Directory Processing
During binding, processing happens in this order:
1. All of the modules specified on the MODULE parameter are examined. The binder determines the list of symbols imported and exported by the object. After being examined, modules are bound, in the order listed, into the program being created.
2. All of the service programs on the BNDSRVPGM parameter are examined in the order listed. The service programs are bound only if needed to resolve an import.
3. All of the binding directories on the BNDDIR parameter are processed in the order listed. All the objects listed in these binding directories are examined in the order listed, but they are bound only if needed to resolve imports. Duplicate entries in binding directories are silently ignored.
4. Each module has a list of reference system objects. This list is simply a list of binding directories. The reference system objects from bound modules are processed in order such that all the reference system objects from the first module are processed first, then the objects from the second module, and so on. The objects listed in these binding directories are examined in the order listed, only as needed, and bound only if needed. This processing continues only as long as unresolved imports exist, even if OPTION(*UNRSLVREF) is used. In other words, processing objects stops when all imports are resolved.
While objects are examined, message CPD5D03, "Definition supplied multiple times for symbol", may be signalled even if the object is not ultimately bound into the program being created.
Module or service program objects that are bound into the program or service program being created are indicated in the Binder Information Listing section of a CRTPGM or CRTSRVPGM DETAIL(*EXTENDED) listing. Once an object is created, you can also use the DSPPGM or DSPSRVPGM command DETAIL(*MODULE) to see the bound *MODULE objects, and DETAIL(*SRVPGM) to see the list of bound *SRVPGM objects.
Binder Functions
The function of the binder is similar to, but somewhat different from, the function provided by a linkage editor. The binder processes import requests for procedure names and data item names from specified modules. The binder then tries to find matching exports in the specified modules, service programs, and binding directories.
In creating an ILE program or service program, the binder performs the following types of binding:
• Bind by copy
To create the ILE program or service program, the following are copied:
- The modules specified on the module parameter
- Any modules selected from the binding directory that provide an export for an unresolved import
Physical addresses of the needed procedures and data items used within the copied modules are established when the ILE program or service program is created.
For example, Figure procedure P3 in module M3 calls procedure P2 in module M2. The physical address of procedure P2 in module M2 is made known to procedure M3 so that address can be directly accessed.
• Bind by reference
Symbolic links to the service programs that provide exports for unresolved import requests are saved in the created program or service program. The symbolic links refer to the service programs providing the exports. The links are converted to physical addresses when the program object to which the service program is bound is activated.
Figure shows an example of a symbolic link to SIN in service program *MATHLIB/ MATHFUNC. The symbolic link to SIN is converted to a physical address when the program object to which service program SPGMEXAMP is bound is activated.
At runtime, with physical links established to the procedures and data items being used, there is little performance difference between the following:
• Accessing a local procedure or data item
• Accessing a procedure or data item in a different module or service program bound to the same program
Figure show conceptual views of how the ILE program PGMEXAMP and service program SPGMEXAMP were created. The binder uses modules M1, M2, M3, and M4 and service programs PRINTS and MATHFUNC to create ILE program PGMEXAMP and service program SPGMEXAMP.
