CF structures are the named buckets in the coupling facility where IBM MQ stores shared queue messages and associated control information. Every shared queue in your queue sharing group points at a structure name through the CFSTRUCT attribute; when that structure runs out of space, every queue bound to it feels the pain—not just the queue that happened to spike first. Beginners learn queues and channels first; veterans respect structures because structure-full incidents are sysplex-wide Sev-1 events. This tutorial explains how to define CFSTRUCT objects in MQ, how structure names bind to shared queues, sizing inputs and trade-offs, monitoring utilization, altering structures in maintenance windows, recovery concepts when structures fail, and governance patterns that keep payments and claims traffic separated.
Before queues reference a structure, administrators define the CFSTRUCT object to IBM MQ and ensure the sysplex team allocated the corresponding coupling facility structure. MQ tracks structure names, size parameters, and recovery options in object definitions; the physical CF allocation is sysplex infrastructure. Mismatch between MQ definition and CF reality causes startup failures or structures that never come online. Documentation should map MQ structure name to sysplex structure name one-to-one for on-call engineers.
12345678DEFINE CFSTRUCT('MQSG001') + DESCR('Primary shared message structure') + CFLEVEL(5) + SIZE(1048576) ALTER CFSTRUCT('MQSG001') SIZE(2097152) DISPLAY CFSTRUCT('MQSG001') ALL
SIZE and CFLEVEL values must follow IBM documentation for your release—do not copy numbers from blogs without verification. ALTER to increase size typically requires structure offline maintenance coordinated with sysplex programming. Decreasing size is rarer and riskier; plan messages drained first.
Shared queue definition includes CFSTRUCT(MQSG001). Many queues may share one structure—they compete for the same CF memory pool. High-volume PAYMENTS.IN and low-volume AUDIT.LOG in one structure mean audit traffic can be evicted statistically by payment spikes—separate structures isolate risk tiers. Application teams request new shared queues with expected message size, peak depth, and put rate so capacity models stay honest.
| Choice | Benefit | Cost |
|---|---|---|
| One large structure | Simple naming | Single point of fullness |
| Structure per domain | Blast radius isolation | More objects to monitor |
| Structure per message size class | Predictable entry size | More planning overhead |
| Test structure separate | Load test without prod risk | Extra CF memory in LPAR |
INREC and other advanced attributes appear in IBM documentation for specific recovery and efficiency scenarios—if your team uses them, document why in the runbook. When uncertain about a keyword effect, log it for research rather than guessing in production.
Monitor structure utilization percentage, structure status, and associated queue depths together. Alert thresholds at eighty percent give time to drain or expand before hard failure. Dashboards should show which queues map to which structure so incident command knows whom to call. Automations that only alert on individual queue depth miss structure-level starvation where no single queue hit MAXDEPTH yet.
Structure recovery procedures are sysplex and MQ dual procedures: rebuild, restore from duplex copy, or recreate empty structure with message loss acceptance—business decides. Maintenance windows communicate to application teams because shared queues may be unavailable during alter. After recovery, verify member connectivity and depth consistency before reopening traffic floodgates.
A CF structure is one level of a parking garage. Every shared queue parked there shares the same number of spaces. When the level is full, every car (message) waiting to enter that level is turned away—even if another level has room.
A CF structure is a labeled toy box in the sky. IBM MQ puts shared messages in the box you label. If the box is full, no more messages fit until someone makes the box bigger or takes toys out.
Propose three structure names for payments, claims, and test traffic with one-sentence justification each.
Given peak depth 2 million and 4 KB messages, outline sizing inputs you would hand to capacity planning.
Write an alert rule that fires on structure utilization before individual queue MAXDEPTH.
1. CFSTRUCT on DEFINE QLOCAL points to:
2. Structure full affects:
3. Sizing structures uses:
4. Multiple structures help: