Definition of a Module Object
Module objects are the output of all ILE compilers including the ILE COBOL compiler. They are system objects of type *MODULE. For ILE COBOL, the name of any permanently created module objects is determined by the CRTCBLMOD command or the PROGRAM-ID paragraph of the outermost ILE COBOL source program. Each compilation unit in a source member creates a separate module object. The outermost ILE COBOL program in a module object can be called by another ILE COBOL program in a different module object through a bound procedure call. It can also be called using a dynamic program call after the module object has been bound into a program object. Refer to Calling an ILE COBOL Program for a description of bound procedure calls and dynamic program calls.
- Reuse pieces of code generally resulting in smaller programs.
- Share code between several programs therefore eliminating the chance of introducing errors to other parts of the overall program while updating a shared section.
- Mix languages to select the language that best performs the task that needs to be done.
A module object can consist of one or more ILE procedures.
The Create COBOL Module (CRTCBLMOD) command creates one or more module objects from ILE COBOL source statements. These module objects remain stored in the designated library until explicitly deleted or replaced. The module objects can then later be bound into a runnable program object using the Create Program (CRTPGM) command or into a service program using the Create Service Program (CRTSRVPGM) command. The module objects still exist in the library after the program object or service program has been created. For more information on creating a program object from one or more module objects, refer to Using the Create Program (CRTPGM) Command. For more information on creating a service program from one or more module objects, refer to Creating a Service Program.
The Create Bound COBOL Program (CRTBNDCBL) command creates a program object(s) from ILE COBOL source statements in a single step. CRTBNDCBL does create module objects; however, these module objects are created only temporarily and are not reusable. Once CRTBNDCBL has completed creating the program object(s), the temporary module objects are deleted.
For more information on creating a program object in one step, refer to Using the Create Bound COBOL (CRTBNDCBL) Command.
- Debug data
Debug data is the data necessary for debugging a program object using the ILE source debugger. This data is generated based on the option specified in the DBGVIEW parameter of the CRTCBLMOD or CRTBNDCBL command.
- Program entry procedure (PEP)
A program entry procedure is the compiler-generated code that is the entry point for a program object on a dynamic program call. Control is passed to the PEP of a program object when it is called using a dynamic program call. It is similar to the code provided for the entry point in an OPM program. The PEP identifies the ILE procedure within a module object that is to be run first when its program object is called using a dynamic program call. When a module object is created by the ILE COBOL compiler, a PEP is generated. This PEP calls the outermost ILE COBOL program contained in the compilation unit.
When you bind multiple module objects together to create a program object, you must specify which module object will have the PEP of the program object being created. You do this by identifying the module object in the ENTMOD parameter of the CRTPGM command. The PEP of this module object then becomes the PEP for the program object. The PEPs of all other module objects are logically deleted from the program object.
- User entry procedure (UEP)
When a module object is created by the ILE COBOL compiler, the outermost ILE COBOL program contained in the compilation unit is the user entry procedure. During a dynamic program call, the UEP is the ILE procedure that gets control from the PEP. During a static procedure call between ILE procedures in different module objects, the UEP is given control directly.

In Figure 1, *PGM A is created with *MODULE A designated the module object having the entry point for the program object. The PEP for *MODULE A calls ILE Procedure A. The PEP for *MODULE A also becomes the PEP for *PGM A so the PEP for *PGM A calls ILE Procedure A. The UEP for *PGM A is also ILE Procedure A. *MODULE B, *MODULE C, and *MODULE D also have PEPs but they are ignored by *PGM A. Also, ILE Procedure Z can only be called from ILE Procedure A. ILE Procedure Z is not visible to ILE Procedures B, C, and D as they are in separate module objects and ILE Procedure Z is not the outermost COBOL program in *MODULE A. ILE Procedures A, B, C, and D can call each other. Recursion is not allowed because all of them are non recursive procedures.
Each declarative procedure in an ILE COBOL source program generates a separate ILE procedure.
Each nested COBOL program generates a separate ILE procedure.
A module object can have module exports and module imports associated with it.
- A procedure name corresponding to the outermost ILE COBOL program in a compilation unit.
- A cancel procedure name corresponding to the outermost ILE COBOL program in a compilation unit.
- A weak export of an EXTERNAL file or EXTERNAL data.
- A procedure name corresponding to an ILE COBOL program that is called using a static procedure call.
- A cancel procedure name corresponding to an ILE COBOL program that is called using a static procedure call.
- A weak import of an EXTERNAL file or EXTERNAL data.
- A procedure name corresponding to an ILE COBOL program that is set by the SET procedure-pointer-item TO ENTRY procedure-name statement where the name of procedure-name is to be interpreted as an ILE procedure.
The module import is generated when the target procedure is not defined in the referencing module object. A weak import to data item is generated when the data item is referenced in the ILE COBOL program.