Queue Sharing

Queue sharing sounds like one idea but IBM MQ uses it at two levels. On every platform, the SHARE attribute on a queue definition controls whether multiple applications can hold get access at the same time—essential for worker pools pulling from one backlog. On z/OS, shared queues in a queue sharing group go further: one logical queue name in the coupling facility, reachable from many queue managers in the Sysplex. Beginners confuse SHARE with QSGDISP(SHARED); this tutorial separates them, explains when to use each, how open options interact, and what breaks when sharing is wrong for your pattern.

SHARE Attribute: Concurrent Access on One Queue Manager

DEFINE QLOCAL with SHARE(YES) is the default pattern for work queues consumed by several instances of the same service. Each application MQOPENs the queue, MQGETs messages, and processes them; the queue manager serializes access to individual messages so two getters rarely receive the same message twice under normal options. SHARE(NO) means the queue manager rejects or restricts additional openers depending on platform and open options—sometimes used for legacy programs that assume exclusive access.

SHARE does not replace security. Every consumer still needs get authority. SHARE also does not create multiple copies of a message—that is publish/subscribe. One message, one successful destructive get, one consumer.

Explainer: Competing Consumers

Ten Java instances each run MQGET in a loop on ORDERS.IN with SHARE(YES). Message volume divides across instances automatically—faster than one thread. If SHARE is NO, the second instance may fail MQOPEN with reason codes indicating sharing violation. Operations scaling pods in Kubernetes increase consumer count the same way mainframe started multiple CICS tasks against one queue.

z/OS Shared Queues in a Queue Sharing Group

When you define a queue with QSGDISP(SHARED), message data lives in an application CF structure, not only on one member page set. A CICS region on LPAR1 and a batch job on LPAR2 can MQGET the same queue name without a channel between them. Private queues (QSGDISP(QMGR) or COPY/GROUP patterns per your standards) keep data on the member that received the put unless routed otherwise. Planning which queues are shared versus private is a core QSG design activity—shared for cross-LPAR workload; private for high-volume local staging.

QSGDISP Values (z/OS)

• QMGR — definition private to one member; typical local queue.
• GROUP — definition on shared repository for all members to see.
• COPY — member copy of a group definition.
• SHARED — shared queue data in CF; all members access the same messages.

QSGDISP is chosen at define time and is not casually changed—migration requires planned procedures. Coordinate with the CF structures tutorial for structure names and capacity.

Open Options and Browse

MQOPEN options such as MQOO_INPUT_SHARED versus exclusive input interact with SHARE. Browse opens (MQOO_BROWSE) let programs look without removing messages; multiple browsers plus getters require understanding handle scope. Application developers and administrators share responsibility: wrong open options look like sharing bugs in test.

Distributed MQ: No QSG Shared Queues

Linux and Windows queue managers do not use QSGDISP(SHARED). Achieve cross-host access via channels, clusters, or multi-instance patterns—not CF shared queues. The SHARE attribute still matters on distributed systems for multi-instance consumer programs on one queue manager.

Tutorial: Verify SHARE and Depth with Multiple Getters

1
2
3
4
5
6
7
DEFINE QLOCAL('WORK.SHARED') REPLACE +
  SHARE(YES) MAXDEPTH(10000) GET(YES) PUT(YES)
DISPLAY QLOCAL('WORK.SHARED') SHARE
* Run two amqsget processes or consumer apps in parallel
* DISPLAY QSTATUS('WORK.SHARED') IPSPROCS OPSPROCS CURDEPTH
* z/OS shared queue example (names illustrative):
* DEFINE QLOCAL('PAY.SHARED') QSGDISP(SHARED) CFSTRUCT(APPL01)

When Sharing Hurts

Exclusive processing requirements—strict message order by a single thread, legacy programs that crash with SHARE(YES)—need SHARE(NO) or single-consumer design. Shared z/OS queues add CF latency and structure limits; not every queue belongs in CF. Measure before converting all queues to shared.

Explain Like I'm Five: Queue Sharing

SHARE(YES) is several workers sharing one ticket window—they take the next person in line, not the same person twice. z/OS shared queue is one lost-and-found box in the school lobby every classroom can use, instead of each room having its own box.

Practice Exercises

Exercise 1

Second consumer fails MQOPEN on WORK.Q. List SHARE, authority, and open option checks.

Exercise 2

When would you choose QSGDISP(SHARED) over private local on z/OS?

Exercise 3

Compare achieving multi-host access with cluster queues versus z/OS shared queues.

Frequently Asked Questions

Test Your Knowledge