CF Structures

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.

DEFINE CFSTRUCT and Administrative Objects

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.

text
1
2
3
4
5
6
7
8
DEFINE 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.

Binding Queues to Structures

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.

Structure design choices
ChoiceBenefitCost
One large structureSimple namingSingle point of fullness
Structure per domainBlast radius isolationMore objects to monitor
Structure per message size classPredictable entry sizeMore planning overhead
Test structure separateLoad test without prod riskExtra CF memory in LPAR

Sizing Methodology (Conceptual)

  1. Estimate average and maximum message body size including headers.
  2. Estimate peak depth per queue sharing the structure (sum if concurrent peaks possible).
  3. Add overhead for control entries per IBM sizing manuals for your version.
  4. Add growth margin for new applications—structures are painful to shrink.
  5. Validate in performance test sysplex with production-like rates.

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.

Monitoring

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.

Recovery and Maintenance

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.

Explainer: Parking Garage Levels

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.

Explain Like I'm Five: CF Structures

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.

Practice Exercises

Exercise 1

Propose three structure names for payments, claims, and test traffic with one-sentence justification each.

Exercise 2

Given peak depth 2 million and 4 KB messages, outline sizing inputs you would hand to capacity planning.

Exercise 3

Write an alert rule that fires on structure utilization before individual queue MAXDEPTH.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. CFSTRUCT on DEFINE QLOCAL points to:

  • Coupling facility structure name
  • Channel name
  • JCL job
  • RACF class

2. Structure full affects:

  • All shared queues in that structure
  • Only Linux clients
  • Only DNS
  • Only IMS

3. Sizing structures uses:

  • Message size and depth
  • Only channel count
  • Only TLS cipher
  • Only SMP/E

4. Multiple structures help:

  • Isolate capacity and contention
  • Disable QSG
  • Remove logs
  • Skip RACF
Published
Read time22 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation