The daily edition.

Scope: Rocket Enterprise Developer 12.0 for Eclipse (UNIX), documenting Enterprise Server IMS TM operation. The referenced transaction-manager documentation also describes Linux, UNIX, and Windows deployment targets; the configuration and monitoring pages cited here are from the UNIX bundle.

Scheduling is more than a queue

Rocket's IMS TM-compatible transaction manager supports transaction class codes, prioritization, and serialized or parallel transaction processing control. It also supports conversational and non-conversational transactions, response and non-response modes, and IMS message-processing programs. Those are distinct dimensions: class eligibility identifies work that a message processing region (MPR) can handle, while scheduling controls how that work proceeds. The capability is explicitly listed in IMS TM Compatible Transaction Manager.

This matters when investigating a backlog. The existence of queued messages alone does not establish that an eligible MPR is processing them. Rocket's ESCWA monitoring surface exposes both the IMS queue and the MPRs that may consume its messages.

Observe the actual processing region

In ESCWA's SEP monitor, Queue Display for the IMS service opens the queue view. The IMS MPR detail includes Message Classes, showing up to four classes schedulable in that MPR, Message Count, showing messages processed during the current Enterprise Server run, and Transaction ID, identifying the current message processing program when one is scheduled. These fields let an operator compare queue activity with actual region assignments. See SEPs.

Two status values deserve attention: WFI means Wait For Input, while pWFI means a pseudo wait caused by the MPR definition rather than the transaction definition. The display also exposes PROCLIM, the number of messages remaining before the MPR reaches its processing limit. Rocket notes that the MPR might not be rescheduled for a different MPP until that limit is reached—or, for non-WFI processing, until no more messages are waiting for the current transaction. Thus, a processing limit can influence when another program gets the region. See SEPs.

Capacity and an important failure mode

IMS configuration separately controls message-queue capacity. Maximum Blocks specifies 4–63,488 blocks, each approximately 64 KB, with 254 allocation segments per block. The initial server-definition default is 32 blocks, and the limit can be changed while the server runs. Crucially, Rocket documents that when queue space is exhausted, a TM thread waits for allocation: the resulting failure mode is a hang, not simply a rejected message. Enterprise Server reserves a configurable cushion of space for intervention, temporarily restricting other queue operations until that cushion is reacquired. See IMS Configuration.

For operational diagnosis, inspect the queue, MPR class assignments, current transaction, WFI/pWFI status, and remaining PROCLIM before treating slow queue drainage as a capacity-only issue.

Takeaway: IMS TM queue throughput depends on both eligible processing regions and scheduling state; monitor PROCLIM and queue space together, because exhaustion can leave threads waiting rather than producing an immediate error.