RPG & CL development · Intermediate

RPG procedures & data structures

Design typed contracts, manage storage lifetime, and prevent parameter mismatches.

Learn this topic first: RPG development: from opcodes to procedures →

6 explained questions · 5 practice MCQs

Questions and answers

1. What is the difference between a prototype and a procedure interface? (Easy)

A prototype describes a callable contract to the compiler at the call site. The procedure interface describes the parameters and return type within the implementation. Keep their types, lengths, passing conventions, and options compatible.

A shared definition reduces drift. A mismatch can corrupt data or storage even if a call binds successfully. Compiler checking is strongest when callers have the correct prototype and are rebuilt when the contract changes.

2. How do value, reference, and CONST parameters differ? (Intermediate)

Reference passing gives access to caller-provided storage, so the callee can normally alter it. VALUE passes a value according to the supported ABI. CONST expresses a read-only reference contract and may allow compatible expressions or temporary values.

Choose based on semantics, not just performance folklore. Use an output parameter deliberately when the caller should receive a change. Do not pass short storage to an interface expecting a larger structure; the callee’s declaration is not proof of the caller’s actual buffer size.

3. Why use qualified data structures and templates? (Intermediate)

Qualified data structures scope field references under the structure name, reducing collisions and making ownership visible. Templates and LIKE/LIKEDS-style definitions keep related layouts consistent. This is especially useful for request/response contracts and external record definitions.

Avoid copying field definitions into many programs. When the source layout changes, rebuild and validate dependent contracts rather than assuming a shared template magically updates already compiled callers.

Example

dcl-ds order qualified;
  id int(10);
  total packed(11:2);
end-ds;
order.total = 0;
4. How do automatic and static storage affect repeat calls? (Intermediate)

Automatic local storage has an invocation lifetime. Static storage persists according to its program or activation lifetime. Global variables and explicitly static local state can retain values across calls.

Use automatic data for independent request processing where possible. If state must persist, define who initializes, resets, and synchronizes it. Long-lived server jobs and concurrent execution expose bugs that short interactive test runs can hide.

5. How should a procedure report business failure versus technical failure? (Advanced)

A business rejection, such as insufficient stock, should have a defined result the caller can handle. A technical failure, such as database unavailability or a malformed API response, needs diagnostic context and a recovery policy.

Design explicit result/status contracts and preserve relevant messages. Document whether the procedure commits, leaves rollback to the caller, or has external side effects. Returning a Boolean alone may hide whether retrying is safe or whether partial work occurred.

6. Can an unchanged service-program signature prove parameter compatibility? (Advanced)

No. A service-program signature identifies an exported interface list, not a full runtime validation of each parameter layout. Changing a parameter’s type, length, or passing convention can break callers even if an explicit signature remains unchanged.

Version the procedure contract or coordinate caller recompilation and rebinding for incompatible changes. Keep old entry points as adapters when practical. Add tests that exercise old and new callers, not merely a check that activation succeeds.

Example

Old: customer ID packed(7:0)
New: customer ID char(12)
Same export name does not make these ABI compatible.

Practice checkpoint

  1. 1. Which definition informs the caller about parameters?
    1. Job description
    2. Prototype
    3. Access path
    4. Output queue
  2. 2. Which parameter convention normally permits modifying caller storage?
    1. Read-only CONST
    2. A copied VALUE input only
    3. Reference
    4. No parameters
  3. 3. Why qualify data-structure fields?
    1. To force an SQL commit
    2. To run in a new subsystem
    3. To eliminate all compile dependencies
    4. To make ownership explicit and avoid collisions
  4. 4. Which state can survive procedure calls?
    1. Static storage
    2. Every automatic local forever
    3. Only SQL null indicators
    4. No RPG state ever
  5. 5. Does a matching binder signature validate each parameter type?
    1. Yes, all byte layouts
    2. No
    3. Only for packed values
    4. Only on 7.6
Show answer key and explanations

1. B — Prototype The prototype supplies compile-time information at the call site.

2. C — Reference Reference parameters can expose the caller’s storage directly.

3. D — To make ownership explicit and avoid collisions Qualified names clarify which structure owns a field.

4. A — Static storage Storage lifetime matters in repeated and long-lived execution.

5. B — No The binder signature does not replace a compatible procedure ABI.

IBM documentation and further reading