MODULE

Module Object

A module is a nonrunnable object that is the output of an ILE compiler .

A module object is represented to the system by the symbol *MODULE.

Implementing modules can be extremely useful, especially in big applications because it allows the reuse of code in a fairly simple manner.

A module can have one or more procedures. A procedure is like a function. You can pass parameters to it and return values.

One of the advantages of modules is the possibility of reusing the code, since you can use a module as a component of several different executable objects.

A module is a building block. When you use an ILE compiler, it creates a module object. You can then use the Create Program (CRTPGM) command to create a *PGM object or the Create Service Program (CRTSRVPGM) command to create a *SRVPGM object from the module.

When the CRTPGM or CRTSRVPGM commands are run, the compiled code is copied out of the *MODULE object and into the *PGM or *SRVPGM object. At that point, it becomes a routine in that program or service program. After that, you can delete the module if you like, because it's no longer needed (unless of course you want to use it to re-create the program or service program later).

You can't ever call the code in a module. It's not possible.

The code copied into your program or service program is now either a routine or a set of routines. These routines are known in ILE terminology as "procedures." There are two types of procedures, main procedures and subprocedures. Both are called the same way. However, main procedures are named the same as the module they came from, which contributes to the myth that you're actually calling the module.

Module is another concept that is used in Service program.

·         Modules allow you to organize related tasks into smaller units of code, which can then be bound together into programs or service programs.

·         They cannot be called using the dynamic CALL operation but are, instead, called with either the bound call (CALLB in RPG) or a prototyped call (CALLP in RPG).

·         NOMAIN modules cannot be called directly. Instead, the subprocedures contained inside the module are called using prototyped call (CALLP in RPG).

The three types of RPG modules are distinguished by the nature of the main procedure in the module.

A module with a cycle-main procedure

The module contains a cycle-main procedure and zero or more subprocedures. The cycle-main procedure includes the logic for the full RPG cycle. A cycle-main procedure can be called through a bound call, or through a program call.

A module with a linear-main procedure

The module contains a linear-main procedure and zero or more ordinary subprocedures. The linear-main procedure is identified by the MAIN keyword on the Control specification. The main procedure itself is coded as a subprocedure (with Procedure specifications). The linear-main procedure can only be called through a program call; it cannot be called using a bound call.

A module with no main procedure

The NOMAIN keyword on the Control specification indicates that there is no main procedure in the module. The module contains only subprocedures. The module does not include the logic for the RPG cycle.

This type of module cannot be the program-entry module of a program, since it has no main procedure.

Table 1. Summary of RPG module types
Module Type	Keyword	Cycle Features Allowed	Main Procedure	Initialization of global variables, opening of global files, and locking of UDS data areas	Implicit closing of global files and unlocking of data areas
Cycle-main		Yes	Implicitly defined in the main source section	When the first procedure in the module is called after the activation group is created. When the main procedure is called, if the main procedure previously ended with LR on, or ended abnormally.	When the main procedure ends with LR on, or ends abnormally.
Linear-main	MAIN	No	Explicitly defined with the MAIN keyword and Procedure specifications	When the main procedure is first called after the activation group is created, or if somehow a sub-procedure is called first.	Never
No main	NOMAIN	No	None, indicated by the presence of the NOMAIN keyword	When the first procedure in the module is called after the activation group is created	Never

Linear Main Module

A module which has a program entry procedure but does not use the RPG Program Cycle can be generated by specifying the MAIN keyword on the control specification.

This type of module has one or more procedures, one of which is identified as the main procedure. It does not allow specifications which relate to the RPG Program Cycle.

MAIN(main_procedure_name)

The MAIN keyword indicates that this source program is for a linear-main module and contains a linear-main procedure, identified by the main_procedure_name parameter, which will be the program entry procedure for the module.

The main_procedure_name must be the name of a procedure defined in the source program. The linear-main procedure is intended to be called only through the program call interface and not as a bound procedure call; if you make a recursive call to the linear-main procedure, the call will be a dynamic program call.

Therefore, the following rules apply:

• If a prototype is specified for the linear-main procedure, it must specify the EXTPGM keyword.
• If a prototype is not specified for the linear-main procedure, and a procedure interface is specified, the procedure interface must specify the EXTPGM keyword.
• If the program has no parameters, and the program is not called from an RPG program, neither a prototype nor a procedure interface is required.
• The procedure cannot be exported; the EXPORT keyword may not be specified on the procedure-begin specification for main_procedure_name.

Linear Module

A module which specifies the MAIN or NOMAIN keyword on the Control specification is compiled without incorporating the program cycle.

When the program cycle is not included in the module, you are restricted in terms of what can be coded in the main source section. Specifically, you cannot code specifications for:

• Primary and secondary files
• Heading, detail and total output
• Executable calculations, including the *INZSR Initialization subroutine
• *ENTRY PLIST

Instead you would code in the main source section:

• Full-procedural files
• Input specifications
• Definition specifications
• Declarative calculations such as DEFINE, KFLD, KLIST, PARM, and PLIST (but not *ENTRY PLIST)
• Exception output

Caution: There is no implicit closing of global files or unlocking of data areas in a linear module. These objects will remain open or locked until they are explicitly closed or unlocked.