On Linux you install IBM MQ with rpm or deb packages and start the queue manager with strmqm. On z/OS you install with SMP/E, customize the subsystem, and bring address spaces online under rules written decades before Kubernetes existed. MQ subsystem setup is the foundation: without a healthy queue manager controller task, logs, and page sets, no CSQ command or CICS bridge matters. Beginners who learned MQ in containers must learn started tasks, APF-authorized libraries, PARMLIB members, and how a queue sharing group member announces itself to the sysplex. This tutorial walks through what subsystem setup means, major customization inputs, cold start versus warm start concepts, relationship to JCL procedures, verification displays operators run after IPL, and mistakes that leave MQ up but disconnected from the coupling facility or wrong QSG name.
z/OS documentation speaks of the MQ subsystem and the queue manager. In practice your site runs one or more queue manager members, each with a name, logs, and page sets, participating in a queue sharing group or standing alone. Subsystem setup ensures the z/OS environment can load MQ modules, allocate data sets, and start the controller. Queue manager customization sets QMNAME, listener ports, and default objects. Confusing installation (SMP/E) with customization (macros, jobs) with daily operations (CSQ) causes onboarding friction—this page focuses on customization and first start after install.
| Phase | Outcome | Typical owner |
|---|---|---|
| SMP/E install | Libraries on DASD | Systems programming |
| Customization | Parms, VSAM, CF defs | MQ + sysplex |
| Subsystem start | CSQ1 active | Operations |
| Object define | Queues, channels | MQ admin |
| App connect | CICS, batch, JMS | Application |
Installation jobs generate customized members: queue manager name, QSG name if applicable, log and page set data set names, buffer pool sizes, and security interfaces to RACF. Coupling facility structure names for shared queues must match sysplex definitions created before MQ starts. Channel initiators and listeners may be started automatically or via procedures depending on policy. Document every customized value in the configuration management database—guessing DSN names during a 3 a.m. recovery extends outages.
Operators start MQ through JCL procedures (see MQ procedures tutorial) submitted manually, from automated IPL actions, or from operations products. Cold start processes logs from beginning state; warm start assumes prior clean shutdown. Wrong mode after unclean shutdown triggers recovery jobs operators train for quarterly. DISPLAY QMGR and member status commands confirm the subsystem accepted customization. Channel initiators may need separate START commands after the base queue manager is active.
1234567Post-start verification (illustrative): 1. Confirm CSQ1 (or site task) is active in SDSF 2. DISPLAY QMGR STATUS 3. If QSG: verify member joined group display 4. DISPLAY CFSTRUCT for MQ structures 5. Test authorized CSQUTIL DEFINE on qualification queue
MQ modules link from authorized libraries. APF marking and LPA/LLA considerations follow IBM installation guide for your release. Migration projects re-verify APF after SMP/E apply when load library names change. Application regions (CICS, IMS, batch) need STEPLIB or linklist access to MQ API modules without loading wrong versions from an old library rank.
Adding a new member to an existing QSG requires coordinated customization: unique member name, CF structure connectivity, and network or VTAM definitions for remote clients. Starting a lone member while the sysplex believes it should be quiesced causes split-brain style symptoms operations document in runbooks. New members are never copy-paste from distributed crtmqm—follow IBM QSG expansion procedures.
Subsystem setup is building the power plant. Defining queues is wiring individual buildings. Applications flipping switches mean nothing if the plant never opened.
Subsystem setup is turning on the big IBM MQ machine in the computer room and making sure it knows its name and which shared toy box it may use.
List five customized values your site uses for production MQ and where each is stored.
Describe cold versus warm start in your own words and when operations chooses each.
Write a post-IPL checklist with five verification steps for MQ subsystem health.
1. IBM MQ on z/OS runs as:
2. Subsystem setup is separate from:
3. QSG membership is configured:
4. APF authorization applies to: