IMS TM developer on retainer: ACCINQ transaction suspended after 3 ABENDs when S0C7 in ACCIQR01 on teller message layout change — /DISPLAY TRAN shows TRANSTAT=SUSPEND ABNDCNT=3

IMS 15 • z/OS 2.4 • MPP ACCIQR01 • S0C7 data exception • TRANSACT ABNDCNT • /DISPLAY TRAN • /START TRAN • retainer billing

At Lakeside Federal Credit Union, twelve tellers started their Monday morning unable to query member accounts. Every ACCINQ (account inquiry) transaction came back with a terminal error. The IMS system message on their 3270 screens read: DFS058I TRANSACTION CANNOT BE PROCESSED. The IMS TM retainer developer was paged at 10:22 AM.

The root cause was a message layout mismatch introduced by a teller front-end upgrade deployed over the weekend. The ACCINQ transaction program — ACCIQR01, a COBOL MPP (Message Processing Program) running in IMS region ACCMPPA — had not been updated to match the new input message structure. When it tried to process the first inquiry after the upgrade, it ABENDed with a data exception. IMS backed out the call and re-queued the message. The program ABENDed again on the same message. After the third ABEND, IMS reached the transaction’s ABNDCNT threshold and suspended the entire ACCINQ transaction. All queued account inquiries were frozen.

The teller front-end change and the message layout shift

The teller front-end team had updated their application over the weekend (Change Order CHG-2026-0891). The new teller software sent an 82-byte IMS input segment where the old one had sent 80 bytes. The change added a 2-byte branch code field immediately after the account number field. This shifted every field after the account number by 2 bytes to the right.

Before the change, the ACCINQ input segment layout was:

Old layout (80 bytes):
  Bytes  1-9:  ACCOUNT-NBR   PIC X(9)
  Bytes  9-12: ACCT-TYPE     PIC 9(4) COMP  (binary, 2 bytes)
  Bytes 11-14: TELLER-ID     PIC X(4)
  Bytes 15-80: (other fields)

New layout (82 bytes):
  Bytes  1-9:  ACCOUNT-NBR   PIC X(9)
  Bytes  9-10: BRANCH-CODE   PIC X(2)   ← NEW field inserted here
  Bytes 11-14: ACCT-TYPE     PIC 9(4) COMP  (binary, 2 bytes)
  Bytes 13-16: TELLER-ID     PIC X(4)
  Bytes 15-82: (other fields, each shifted 2 bytes)

ACCIQR01’s WORKING-STORAGE section mapped ACCT-TYPE at bytes 9–12 — the old location. After the teller upgrade, bytes 9–10 contained the new branch code field and bytes 11–12 contained the first 2 bytes of ACCT-TYPE. The branch code field carried the 2-byte value S0 (branch code for the main Lakeside branch). When ACCIQR01 moved bytes 9–12 into its ACCT-TYPE PIC 9(4) COMP working-storage field, it was moving the character string S002 — the letter S, zero, zero, two — into a binary numeric field. That is a S0C7 data exception.

IMS re-queue, ABNDCNT, and suspension

IMS TM’s behavior on an MPP ABEND is defined by the TRANSACT macro parameter ABNDCNT. When an MPP program ABENDs during message processing, IMS treats the UOW (unit of work) as incomplete. If the GU (Get Unique) call that retrieved the input message has not been committed via a CHKP (checkpoint) or a normal RETURN, IMS backs it out — the message is placed back in the IMS message queue and the transaction is rescheduled. The ABNDCNT counter increments by one for each ABEND. When the counter reaches the configured threshold, IMS sets the transaction’s TRANSTAT (transaction status) to SUSPEND and stops scheduling it.

The ACCINQ TRANSACT macro had ABNDCNT=3. The sequence of events on Monday morning:

10:14:22  Teller TLRWND01 submits ACCINQ for account 510020047
          IMS queues input message (82 bytes, new layout)
          ACCIQR01 scheduled in region ACCMPPA
          EXEC DLI GU USING PCB1 — message retrieved
          MOVE IO-MSG(9:4) TO ACCT-TYPE-WORK — bytes 9-12 = X'E2F0F0F2' ('S002')
          MOVE ACCT-TYPE-WORK TO ACCT-TYPE PIC 9(4) COMP — S0C7 data exception
          ACCIQR01 ABENDs — SYSLOG: DFS040I ACCINQ ABEND 0C7 BLKNO=00A4
          IMS backs out GU — message re-queued — ABNDCNT = 1

10:14:25  IMS reschedules ACCINQ — same message — same ABEND — ABNDCNT = 2

10:14:28  IMS reschedules ACCINQ — same message — same ABEND — ABNDCNT = 3
          DFS554I ACCINQ TRANSACTION STATUS CHANGED TO SUSPEND
          All 14 queued ACCINQ messages frozen
          New ACCINQ submissions from all 12 tellers queue but not processed
          DFS058I TRANSACTION CANNOT BE PROCESSED on all teller terminals

The three-ABEND cycle happened in six seconds. By the time the first teller reported the error to the IMS team, the transaction was already suspended and thirteen more messages had queued behind it.

/DISPLAY TRAN ACCINQ and the SYSLOG ABEND dump

The IMS operator issued the first diagnostic command:

/DISPLAY TRAN ACCINQ

DFS000I DISPLAY FROM ID=IMSA
TRAN      TRANSTAT  ABNDCNT  QCNT  CLASS  SCHD  PRTY
ACCINQ    SUSPEND       3      14       2     1     7

TRANSTAT=SUSPEND confirmed the suspension. ABNDCNT=3 confirmed the three-ABEND trigger. QCNT=14 showed fourteen messages queued and waiting.

The retainer developer went to SDSF to read the ABEND dumps in the IMSA JESLOG. The dump at BLKNO=00A4 showed the S0C7 data exception at PSW address 000F2A14 — the instruction performing the binary move of the non-numeric data. The ABEND dump included a formatted storage display of the IMS I/O PCB message area, which showed the raw bytes of the input segment. Bytes 9–10 clearly contained E2F0 in hex (the EBCDIC encoding of ‘S0’) — the new branch code field that ACCIQR01 did not know existed.

A quick comparison of the teller front-end change order (CHG-2026-0891) against ACCIQR01’s WORKING-STORAGE data map confirmed the mismatch. The ACCIQR01 data map had not been listed as a dependent in the change order’s impact analysis. The teller team had updated only their front-end application, assuming the field insertion at byte 9 would not affect downstream IMS programs since they were adding a new field — not changing an existing one. The IMS side saw it differently: every field after byte 8 moved.

Fix: update ACCIQR01 WORKING-STORAGE and /START TRAN

The fix required updating ACCIQR01’s WORKING-STORAGE message map to reflect the new 82-byte segment layout:

* Before (old layout, 80 bytes):
01  ACCINQ-INPUT-MSG.
    05  AI-ACCOUNT-NBR     PIC X(9).
    05  AI-ACCT-TYPE       PIC 9(4) COMP.
    05  AI-TELLER-ID       PIC X(4).
    05  AI-REMAINDER       PIC X(67).

* After (new layout, 82 bytes):
01  ACCINQ-INPUT-MSG.
    05  AI-ACCOUNT-NBR     PIC X(9).
    05  AI-BRANCH-CODE     PIC X(2).    ← added
    05  AI-ACCT-TYPE       PIC 9(4) COMP.
    05  AI-TELLER-ID       PIC X(4).
    05  AI-REMAINDER       PIC X(67).  * (same length; segment total 82)

After editing ACCIQR01, the program was assembled using ASMA90 and link-edited to the ACCINQ load library. Before deploying, the operator issued /STOP TRAN ACCINQ to prevent IMS from scheduling the old load module for any new submissions. The new load module was loaded via an IMSCONN REFRESH. The operator then issued:

/START TRAN ACCINQ

DFS058I TRANSACTION ACCINQ STARTED

/DISPLAY TRAN ACCINQ

DFS000I DISPLAY FROM ID=IMSA
TRAN      TRANSTAT  ABNDCNT  QCNT  CLASS  SCHD  PRTY
ACCINQ    STARTED       0      14       2     1     7

TRANSTAT changed from SUSPEND to STARTED. ABNDCNT reset to 0. The fourteen queued messages were processed immediately — all succeeded with the corrected layout. The teller terminals responded normally within thirty seconds of the /START command. Total downtime: 2 hours 8 minutes from first ABEND to /START.

Post-incident: the credit union’s change management process was updated to require an IMS message layout dependency check for any teller front-end change that modifies an input segment used by an IMS transaction. The ACCINQ TRANSACT macro’s ABNDCNT was changed from 3 to 1 — so a future layout mismatch suspends the transaction after one ABEND instead of three, reducing the window during which garbage messages can accumulate in the queue.

How HourTab helps IMS TM retainer developers

The diagnosis and fix took 2.5 hours. But the retainer developer also spent 45 minutes in a post-incident call with the teller front-end team explaining what an IMS TRANSACT ABNDCNT threshold is, why IMS re-queues on ABEND rather than discarding the message, and why a field insertion at byte 9 shifts all downstream field offsets. That education time is invisible in a flat invoice. In a HourTab log entry, it appears as “post-incident debrief + IMS message lifecycle explanation to teller dev team, 0.75h” — a line item the credit union CTO can read and understand, and one that justifies the retainer cost relative to what it would cost to have no IMS TM expertise available at all.

HourTab turns a time-tracker CSV into a public retainer-hours URL your client can bookmark — no login, no portal, no “how many hours do I have left?” emails. Free for one retainer. $9/mo for up to ten.

FAQ: IMS TM developer retainers

See also: IMS DB developer retainer · CICS developer retainer · JCL developer retainer