Creating Objects

Creating IBM MQ objects is the foundation of every integration: without QLOCAL definitions, applications have nowhere to MQPUT; without channels and listeners, remote sites cannot connect; without topics and subscriptions, pub/sub has no tree to route events. CREATE in MQ means DEFINE in MQSC—or POST in REST, or New in MQ Explorer—all converging on the command server writing to the object repository. Beginners often create a queue, see applications fail with 2035, and learn that creation and authorization are separate steps. This tutorial walks through major object types, essential attributes explained one by one, naming standards, dependency order in scripts, REPLACE for DevOps, distributed versus z/OS command paths, post-create verification with DISPLAY, and pitfalls that cause production outages when objects are half-defined.

Object Types You Will Create First

QLOCAL holds messages on this queue manager—the default mailbox. QREMOTE and QALIAS support routing and indirection. CHANNEL (SDR, RCVR, SVRCONN, CLNTCONN, and others) moves messages between queue managers or clients. LISTENER accepts inbound TCP connections. TOPIC and SUB define pub/sub topology. PROCESS and NAMELIST appear in trigger and cluster scenarios. AUTHINFO supports CONNAUTH. STORAGE CLASS and queue sharing objects appear on z/OS. Start with QLOCAL, LISTENER, and one SDR/RCVR pair before advanced cluster objects.

Creating a Local Queue (Attribute by Attribute)

MAXDEPTH is the maximum number of messages the queue can hold—when full, MQPUT returns queue full unless overridden. MAXMSGL caps single message size; must not exceed queue manager MAXMSGL. DEFPSIST(YES) means messages default to persistent (survive restart); NO is faster but data loss risk on crash. DEFPRTY sets default priority. DESCR is documentation for operators. BOQNAME and BOTHRESH define backout to a dead-letter queue after repeated failures. GET and PUT can disable one direction for maintenance. Each attribute has operational impact—do not copy defaults from lab without risk review for production payment queues.

1
2
3
4
5
6
DEFINE QLOCAL('ORDERS.IN') REPLACE +
  DESCR('Customer orders inbound') +
  MAXDEPTH(100000) MAXMSGL(4194304) +
  DEFPSIST(YES) DEFPRTY(5) +
  BOQNAME('ORDERS.DLQ') BOTHRESH(5)
DISPLAY QLOCAL('ORDERS.IN') ALL

Remote Queues, Transmission Queues, and Channels

To send to a partner, define QREMOTE naming the target queue and queue manager, XMITQ (transmission queue) that stages messages for the channel, and CHANNEL SDR with CONNAME pointing to partner listener. Partner defines matching RCVR and QLOCAL target. Names must align across organizations—document interface control documents. Creating only QREMOTE without XMITQ or channel leaves messages with nowhere to go. START CHANNEL after both sides ready.

Listeners and Server-Connection Channels

DEFINE LISTENER with PORT(1414) and TRPTYPE(TCP) opens the dock for inbound trucks. Client applications use SVRCONN channels; DEFINE CHANNEL with CHLTYPE(SVRCONN) and pair with CONNAUTH and CHLAUTH rules. MCAUSER on channel affects the OS user for authority checks—coordinate with security when creating SVRCONN for Java clients.

Topics and Subscriptions

DEFINE TOPIC creates administrative topic objects anchoring the topic tree. Applications publish to topic strings; subscribers use SUB objects or dynamic subscriptions. Creating TOPIC without planning hierarchy leads to security holes—pub/sub authority is per topic string pattern. See topic tutorials for STRUCUR and model queue attributes.

Explainer: Adding Rooms to the Building

Creating objects is adding labeled rooms (queues) and hallways (channels) to the message building before people (applications) move in with keys (authority).

Naming Standards

• Use environment prefix: PROD.PAYMENT.IN versus TEST.PAYMENT.IN.
• Avoid spaces and ambiguous characters; follow site charset rules.
• Match partner interface documents exactly for remote names.
• Keep channel names symmetric between queue managers in point-to-point pairs.

Creation Order in Scripts

1. Transmission queues and local queues referenced by channels.
2. Channels referencing CONNAME and XMITQ.
3. Listeners (may exist already shared).
4. Remote queues and aliases.
5. START commands after definitions and authority.

Verification After CREATE

DISPLAY object ALL confirms attributes saved. Use PCF or REST GET in automation. Application smoke test with amqsputc/amqsgetc or client put/get. Check CURDEPTH stays zero until traffic. For channels, DISPLAY CHSTATUS after START. Document creation in CMDB with owner and retention policy.

z/OS Considerations

Object creation may use CSQUTIL or operations console with RACF checks instead of runmqsc. Queue sharing groups require CF structures and shared naming conventions. Storage class and DEFPSIST interact with media recovery policies. Mainframe change windows often require separate RACF profile creation in the same change record.

Common Mistakes

• Creating queue without DLQ when application uses backout.
• MAXMSGL smaller than largest expected message.
• Duplicate object names across test/prod on same host with wrong QM.
• Forgetting REPLACE in redeploy scripts.
• No setmqaut after DEFINE on distributed.

Explain Like I'm Five: Creating Objects

Creating objects is building the mailboxes and roads before any letters are sent.

Practice Exercises

Exercise 1

DEFINE a QLOCAL with MAXDEPTH, DEFPSIST, and DLQ; DISPLAY ALL and explain each attribute.

Exercise 2

Sketch SDR, RCVR, XMITQ, QREMOTE relationships for two queue managers.

Exercise 3

Write setmqaut lines needed after creating ORDERS.IN for group ORDERING.

Frequently Asked Questions

Test Your Knowledge