MODULE

Understanding ILE Module Objects

What is a Module?

• A module is a non-executable object created by an ILE compiler.
• The system identifies it with the special symbol *MODULE.
• Modules act as building blocks in larger applications, allowing developers to reuse code efficiently.

Why Use Modules?

• They simplify development in large systems by enabling code reuse.
• A module can contain one or more procedures (similar to functions).
• Procedures accept parameters, perform logic, and can return values.
• Modules can be combined into different executable objects, making them versatile components.

Creating Programs and Service Programs

• When you compile source code with an ILE compiler, you get a *MODULE.
• You can then use:
  • CRTPGM → to build a *PGM (program object)
  • CRTSRVPGM → to build a *SRVPGM (service program object)
• During this process, the compiled code is copied from the module into the program or service program.
• Once copied, the module itself is no longer required unless you plan to rebuild the program later.
• Important: You cannot directly call a module; only the routines inside it are callable.

---

Procedures in Modules

• In ILE terminology, routines inside modules are called procedures.
• There are two types:
  • Main procedures – usually named after the module itself.
  • Subprocedures – additional routines defined within the module.
• Both are invoked in the same way, but the naming convention sometimes creates confusion, leading people to think they are calling the module directly.

---

Key Points About Modules

• Modules group related tasks into smaller, manageable units.
• They can be bound into programs or service programs.
• They cannot be invoked with a dynamic CALL. Instead, they are accessed through:
  • CALLB (bound call in RPG)
  • CALLP (prototyped call in RPG)
• NOMAIN modules cannot be called directly; only their subprocedures can be invoked.

---

Types of RPG Modules

1. Cycle-Main Module

• Contains a cycle-main procedure plus optional subprocedures.
• Implements the full RPG cycle logic.
• Can be called via a bound call or a program call.

2. Linear-Main Module

• Contains a linear-main procedure and optional subprocedures.
• The main procedure is explicitly defined with the MAIN keyword.
• Can only be called through a program call (not a bound call).

3. NOMAIN Module

• Defined with the NOMAIN keyword.
• Contains only subprocedures, with no main procedure.
• Cannot serve as the entry point of a program.

---

RPG Module Types Summary

Module Type	Keyword	RPG Cycle Features	Main Procedure	Behavior
Cycle-main	—	Yes	Implicitly defined in source	Runs RPG cycle logic; can be called via bound or program call
Linear-main	MAIN	No	Explicitly defined with MAIN	Entry procedure only via program call
NOMAIN	NOMAIN	No	None	Contains only subprocedures; cannot be program entry

---

Linear-Main Modules Explained

• A linear-main module is created by specifying the MAIN keyword in the control specification.
• It has one or more procedures, with one designated as the entry point.
• Unlike cycle-main modules, it does not include RPG cycle-related specifications.

Rules for Linear-Main Procedures

• The procedure name must match one defined in the source.
• Calls to the linear-main procedure are program calls, not bound calls.
• Recursive calls are treated as dynamic program calls.
• If a prototype is defined, it must include the EXTPGM keyword.
• Exporting the main procedure is not allowed (EXPORT keyword cannot be used).

---

Linear and NOMAIN Modules

• Modules compiled with MAIN or NOMAIN keywords exclude the RPG program cycle.
• Restrictions in the main source section:
  • No primary/secondary file specs
  • No heading/detail/total output specs
  • No executable calculations (including *INZSR)
  • No *ENTRY PLIST
• Allowed elements include:
  • Full-procedural files
  • Input and definition specifications
  • Declarative calculations (DEFINE, KFLD, KLIST, PARM, PLIST)
  • Exception output

⚠️ Note: In linear modules, global files and data areas are not automatically closed or unlocked. Developers must explicitly handle these operations.

---