LESSON 7 · Intermediate

Messaging, data queues, data areas and recovery

Plain-English notes, safe code skeletons, IBM i commands, and a checkpoint you can use before opening the deeper question bank.

After this lesson

Learning notes

Choose the smallest communication primitive

A data queue is designed for passing entries between jobs, often as a producer-consumer channel. A data area is a small named value used for configuration or coordination. A message queue carries messages for a job, user, or program and supports IBM i message handling semantics.

Do not use a data area as a general-purpose database row, and do not assume a queue is durable business history. Persist the business state separately when replay, audit, or reconciliation is required.

  1. Producer validates and writes an entry
  2. Queue preserves the agreed ordering and key
  3. Consumer waits or reads with a timeout
  4. Consumer applies an idempotent business action
  5. Success is acknowledged; failure is retried or quarantined

Make waiting and ownership explicit

A receiver should state whether it waits, how long it waits, and what an empty queue means. A sender should handle a full or unavailable queue. Include a correlation or operation identifier so an operator can trace one message through the job log and business tables.

For a data area, define who creates it, who can change it, its length and format, and how a deployment updates it. A clear owner prevents hidden configuration changes.

CL commands to discuss

CRTDTAQ DTAQ(APPDATA/ORDERQ) TYPE(*STD)
SNDDTAQ DTAQ(APPDATA/ORDERQ) LEN(80) DTA('order-123')
RTVDTAQ DTAQ(APPDATA/ORDERQ) WAIT(30)
CRTDTAARA DTAARA(APPDATA/MODE) TYPE(*CHAR) LEN(10)

Design the failure path before the happy path

A queue consumer can fail after applying a change and before acknowledging the entry. The handler must be safe to run again or must record a durable de-duplication key. Add retry limits and a dead-letter or operator review path for poison messages.

Use message APIs and job logs to make a failure diagnosable. A useful message includes the operation ID, object or table, reason, and the next safe action.

Consumer pseudocode

receive entry with timeout
if no entry: return normally
if already processed(operationId): acknowledge and continue
apply business change in one transaction
record operationId
acknowledge only after commit

Open the detailed question chapters

Practice checkpoint

Answer all five, then review the explanations. The interactive site stores your completed learning checkpoints in this browser.

  1. 1. Which API sends a data-queue entry?
    1. QRCVDTAQ
    2. CRTPGM
    3. QSNDDTAQ
    4. DSPFFD
  2. 2. Does FIFO guarantee exactly-once business processing?
    1. Yes, even after crashes
    2. Only with two consumers
    3. Only for RPG
    4. No
  3. 3. A consumer loses an entry after receive then crashes. What design helps?
    1. Durable work records and reconciliation
    2. Only a larger terminal window
    3. A shorter object name
    4. Ignoring failed work
  4. 4. How should database changes and notification intent be coordinated?
    1. Assume every send rolls back
    2. Persist outbound intent in the same database transaction
    3. Send twice before every COMMIT
    4. Keep all intent only in a variable
  5. 5. Which backlog metric identifies aging work?
    1. Only the queue object name
    2. Only source line count
    3. Age of the oldest pending item
    4. Only compile duration
Show answer key and explanations

1. C — QSNDDTAQ QSNDDTAQ sends entries and QRCVDTAQ receives them; their parameter contracts must match the queue and payload.

2. D — No Ordering and end-to-end delivery guarantees are different concerns.

3. A — Durable work records and reconciliation Persisted intent lets the system rediscover incomplete business work.

4. B — Persist outbound intent in the same database transaction An outbox avoids losing intent between database commit and external notification.

5. C — Age of the oldest pending item Depth plus age and throughput are useful operational indicators.

IBM documentation for this path