ILE & application design · Advanced

Activation groups & lifecycle

Reason about storage, open files, commitment scope, and repeated calls.

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

6 explained questions · 5 practice MCQs

Questions and answers

1. What is an activation group? (Intermediate)

An activation group is a resource grouping within a job for ILE execution. It helps organize activated programs and associated storage, files, and other scoped resources. It is not a separate job or a security identity.

Use it to reason about lifecycle and isolation of runtime resources. Two groups can still access the same database records and contend on locks. Explain how the application creates, reuses, and ends the group rather than treating its name as a performance setting.

2. What do named, *NEW, and *CALLER choices imply? (Intermediate)

A named activation group can be reused across calls in a job. A program using *NEW gets a new activation group for its invocation. *CALLER runs in the caller’s activation group where that attribute is supported.

These choices affect resource lifetime and interaction with the caller. Service programs have their own supported activation attributes and are not configured identically to every program. Check object attributes and command rules rather than applying one compile recipe to all ILE object types.

3. Is an activation group the same as a transaction? (Advanced)

No. An activation group is a runtime resource boundary. Commitment control may be scoped to an activation group or to a job, so transactions and activation groups have related but distinct lifecycles.

A procedure in another group may not participate in the transaction you expected if it uses a different commitment definition. Establish and document commitment scope before composing updates across components. Verify rollback behavior with an intentional failure after the first update.

4. Why can a service retain yesterday’s configuration in one server job? (Advanced)

The service may cache configuration in static or global state that persists for its activation lifetime. Long-lived jobs can continue using that state even after the underlying configuration has changed.

Define invalidation explicitly: a version check, bounded cache lifetime, reload operation, or controlled job recycling. Do not assume recompiling source or changing a data area causes active cached variables to refresh. Test repeated requests within the same job, not only fresh calls in new jobs.

5. When is reclaiming an activation group appropriate? (Advanced)

It can be appropriate to release a group’s resources when the application is quiescent and the group’s lifecycle is understood. Reclaiming is not a substitute for application cleanup or a universal fix for every persistent-state bug.

Determine whether procedures are active, whether files or transactions are in use, and how callers expect resources to persist. Coordinate with the application owner and validate after reclamation. The precise reclaim restrictions and behavior depend on object/runtime conditions.

6. How do you choose activation-group strategy for a reusable component? (Advanced)

Start with desired ownership: should the caller own state and transaction scope, or should the component maintain a deliberate independent lifecycle? Identify file sharing, static state, error propagation, and concurrency requirements.

Prefer simple explicit contracts and measure actual activation overhead if performance matters. Avoid choosing a single group for the entire estate by habit. Document the decision and test independent callers, repeated calls, failure cleanup, and long-lived server behavior.

Practice checkpoint

  1. 1. Is an activation group a separate job?
    1. Yes, with its own job queue
    2. No
    3. Only when named
    4. Only for SQL
  2. 2. Which choice commonly reuses a named group within a job?
    1. Always *NEW
    2. A new job queue
    3. A named activation group
    4. An output queue
  3. 3. Does a new group necessarily create the desired independent transaction?
    1. Yes, always
    2. Only for CL
    3. Only for data areas
    4. No, commitment scope must be checked
  4. 4. A configuration cache is stale in one long-lived job. Check:
    1. Static state and invalidation
    2. Only source file timestamps
    3. Only terminal settings
    4. Only the library object size
  5. 5. Should reclamation be used blindly on an active application?
    1. Yes, after every request
    2. No, understand resource ownership and activity
    3. Yes, it is just a cache clear
    4. Only when a user complains
Show answer key and explanations

1. B — No Activation groups are resource subdivisions within a job.

2. C — A named activation group Named groups can retain resources across calls in that job.

3. D — No, commitment scope must be checked Commitment definitions and runtime grouping are distinct concepts.

4. A — Static state and invalidation Persisted runtime state may outlive configuration changes.

5. B — No, understand resource ownership and activity Reclamation changes resource lifecycle and requires application context.

IBM documentation and further reading