Production engineering · Intermediate

Debugging RPG, CL & batch

Reproduce failures in the correct job and inspect the code that is actually running.

Learn this topic first: Production engineering: debug, secure, integrate and tune →

6 explained questions · 5 practice MCQs

Questions and answers

1. What is needed for useful source-level debugging? (Easy)

Compile with appropriate debug information and retain the source/build identity used for the object. Start a supported debugger against the correct program and job. Without matching views, the displayed source may not accurately represent executable behavior.

Prefer a controlled test environment with representative data. Verify the object library and build attributes before stepping through code. Optimization can affect variable visibility and stepping, so interpret the debugger in the context of the compiled object.

2. How do you debug a batch job? (Intermediate)

Identify the exact target job and arrange for it to pause before the failing code, using a supported service-job/debug workflow or an IDE debugger. STRSRVJOB and STRDBG are common command-based parts of such a workflow, followed by appropriate cleanup.

Avoid racing a short-lived job that finishes before attachment. Use a controlled held submission or agreed breakpoint setup, then release it intentionally. Debugging can suspend work and retain locks, so plan the impact before targeting an active production process.

3. Why is a breakpoint not being hit? (Intermediate)

Verify that the invoked object is the expected library/version, that the target job is correct, and that the execution path reaches the line. Check whether the code resides in a service-program procedure or a different module than assumed.

Also inspect debug views and optimization. A stale active object or a second build in another library can explain the mismatch. Begin with a reliable entry breakpoint and trace the real call path instead of adding random breakpoints throughout the source.

4. How do you debug decimal-data errors? (Intermediate)

Locate the failing operation and inspect the source of the invalid numeric representation. Common causes include incompatible call parameters, character-to-number conversion, malformed imported data, or interpreting a record with the wrong layout.

Trace the data back to its boundary and compare types, lengths, scale, and CCSID where relevant. Fix validation or interface compatibility there. Replacing the failing value with zero may hide the symptom while changing a financial result.

5. How do you debug SQL errors inside RPG? (Advanced)

Capture SQLSTATE, SQLCODE, diagnostics, and relevant input values immediately after the failing statement. Check host-variable types, null indicators, schema resolution, commitment options, and parameter values.

RPG exception handling and SQL diagnostics are separate mechanisms. Reproduce the statement with equivalent settings and data, not merely similar SQL text in another session. Avoid logging sensitive payloads; retain enough context to identify the operation and reproduce it safely.

6. How do you investigate an intermittent production failure? (Advanced)

Correlate failures by job, business key, time, release, and dependency state. Compare successful and failed cases to find a differentiator such as concurrent updates, a specific character encoding, or a reused server job.

Add targeted observability at suspected boundaries, then build a controlled reproduction. Capture lock timing, retries, and transaction outcomes for races. Avoid a broad rewrite or repeated restarts that remove the evidence without explaining the fault.

Practice checkpoint

  1. 1. A breakpoint is missed. Verify first:
    1. Only the monitor size
    2. Only the source comment
    3. Target job, object library/version, and execution path
    4. Only the user’s keyboard
  2. 2. Which command is commonly used to select a service job for debugging?
    1. CRTPF
    2. DSPDTAARA
    3. SETGT
    4. STRSRVJOB
  3. 3. Why can debugging affect other users?
    1. Paused work may retain locks and resources
    2. It always changes every record
    3. It deletes all indexes
    4. It automatically ends the subsystem
  4. 4. What should be captured after a failing embedded SQL statement?
    1. Only %EOF
    2. SQLSTATE, SQLCODE, and diagnostics
    3. Only the last screen text
    4. Only the compile timestamp
  5. 5. A decimal-data error follows a program call. Investigate:
    1. Only job priority
    2. Only the output queue
    3. Parameter storage compatibility
    4. Only database indexes
Show answer key and explanations

1. C — Target job, object library/version, and execution path Debugging the wrong object or job is a common cause.

2. D — STRSRVJOB STRSRVJOB is part of the command-based workflow for servicing another job.

3. A — Paused work may retain locks and resources A breakpoint can prolong resource ownership.

4. B — SQLSTATE, SQLCODE, and diagnostics SQL status identifies the database failure category and context.

5. C — Parameter storage compatibility A type or size mismatch can make valid bytes invalid under the callee’s interpretation.

IBM documentation and further reading