ILE & application design · Intermediate

ILE: modules, programs & services

Understand what gets compiled, bound, activated, and shared.

Learn this topic first: Modern RPGLE: modules, service programs & runtime →

7 explained questions · 5 practice MCQs

Questions and answers

1. What problem does ILE solve? (Easy)

The Integrated Language Environment supports modular applications and compatible calls across participating languages. It separates compilation into modules from binding into executable objects and provides runtime organization through activation groups.

The practical benefit is reusable procedures with explicit contracts. A CL orchestration layer can call RPG business logic and other ILE routines without placing all code in one source member. Modularity still requires versioning, ownership, and build discipline.

2. Is a module directly callable with CALL? (Easy)

A *MODULE is a compiled unit intended for binding. It is not a standalone *PGM you invoke with the CL CALL command. A program or service program incorporates modules and exposes the appropriate callable entry points.

If asked to deploy a recompiled module, explain which containing objects must be updated or rebuilt. Copying a new module into the library does not automatically replace the code already bound into a program.

Example

CRTRPGMOD → *MODULE
CRTPGM → *PGM
CRTSRVPGM → *SRVPGM
3. How do a program and service program differ? (Intermediate)

A *PGM provides a program entry point for a program call. A *SRVPGM supplies exported procedures or data used by bound consumers. A service program is normally invoked through those procedure references, not by issuing CALL to it as though it were a program.

Use service programs for stable shared business functions, and keep their public surface small. Document runtime state and transaction ownership because sharing reusable code does not automatically make it stateless or independently transactional.

4. What is bind by copy versus bind by reference? (Intermediate)

Modules selected for an ILE program or service program are copied into that object during binding. References to supplying service programs remain references and are resolved into callable addresses during activation.

Consequently, replacing a standalone module does not refresh programs that copied it. Compatible service-program implementation changes can be deployed differently, but active jobs and interface compatibility still require planning. Inspect dependencies and restart/activation behavior during rollout.

5. What does a binding directory contain? (Intermediate)

A binding directory lists modules and service programs that the binder can search to resolve imports. It is a build-time resolution aid, not a runtime queue, source-code repository, or container of executable copies.

The existence of an entry does not mean every object in the directory is pulled into a program. Resolution follows binder rules and unresolved imports. Keep directories intentional and qualified enough to avoid binding an unexpected library’s implementation.

6. How would you split a monolithic application into service programs? (Advanced)

Identify stable business capabilities such as pricing, customer validation, or posting. Define typed contracts that avoid leaking internal file layouts unnecessarily. Separate user-interface, orchestration, and persistence decisions where that clarifies ownership.

Begin with one capability and preserve existing behavior through comparison tests. Avoid a single giant service program that requires every consumer to redeploy for unrelated changes. Plan compatibility, activation lifetime, error semantics, and caller-owned transactions before expanding the public API.

7. How do module and program entry procedures differ? (Advanced)

A module has an entry procedure associated with its compilation model. When modules are bound into a program, one module provides the program entry point used for a program call. Other exported procedures can satisfy bound calls without being the program’s entry.

Understand this distinction when composing multiple modules or diagnosing an unexpected startup path. A module with reusable no-main procedures serves a different role from a main program module. Verify the binder’s entry selection and exported symbols instead of relying on source member order.

Practice checkpoint

  1. 1. Can CL CALL directly execute a standalone *MODULE?
    1. Yes, always
    2. Only if the source is free-form
    3. Only in QTEMP
    4. No
  2. 2. What is copied into a program during binding?
    1. Selected module code
    2. Every job in QBATCH
    3. All source members automatically
    4. The entire library list
  3. 3. What does a binding directory provide?
    1. Runtime message storage
    2. Candidates for resolving imports
    3. A list of active jobs
    4. A record-format buffer
  4. 4. How are service-program functions normally called?
    1. By CALL directly to *SRVPGM
    2. By RCVF
    3. Through exported procedure references
    4. By adding a job queue entry
  5. 5. Replacing a *MODULE alone updates all bound consumers:
    1. True immediately
    2. True after the next CHAIN
    3. True only for CL callers
    4. False
Show answer key and explanations

1. D — No Modules must be incorporated into a callable program or service program.

2. A — Selected module code Bind by copy incorporates selected modules into the resulting object.

3. B — Candidates for resolving imports It is used by the binder to find exports for unresolved imports.

4. C — Through exported procedure references Consumers bind to exported procedures rather than treating the service object as a normal program entry.

5. D — False Consumers contain copied code and need an appropriate update or rebuild.

IBM documentation and further reading