The SHARE attribute decides whether more than one application can read from a queue at the same time using shared get access. Horizontal scaling—ten Java consumers all draining ORDERS.IN—requires SHARE(ENABLED) on the queue and MQOO_INPUT_SHARED (or equivalent) on MQOPEN. SHARE(DISABLED) enforces exclusive consumer patterns needed by some legacy programs that assume they alone own the queue. Misconfiguration produces MQOPEN failures when the second instance starts, or worse, hidden serialization that negates your scale-out investment. This page explains ENABLED versus DISABLED, open options, competing consumers versus exclusive reader, relation to z/OS queue sharing (different concept), and troubleshooting share conflicts.
| SHARE | Concurrent getters | Pattern |
|---|---|---|
| ENABLED | Multiple (shared open) | Competing consumers |
| DISABLED | Exclusive | Single reader / legacy |
Ten identical consumer instances each MQOPEN with input shared, MQGET with wait. Messages distribute across instances—each message to one consumer. Throughput scales roughly with instance count until CPU, disk, or get contention limits gains. Kubernetes replicas and mainframe parallel batch jobs use the same idea. TRIGGER(DEPTH) can start more instances when SHARE(ENABLED) allows parallel get.
12345DEFINE QLOCAL('ORDERS.IN') REPLACE + SHARE(ENABLED) GET(ENABLED) PUT(ENABLED) + MAXDEPTH(500000) DEFPSIST(YES) * Application: MQOPEN with MQOO_INPUT_SHARED * Second instance must also use shared open - not exclusive
MQOO_INPUT_SHARED requests shared access; MQOO_INPUT_EXCLUSIVE requests exclusive access. Queue SHARE must align: exclusive open to SHARE(ENABLED) queue may fail or behave per platform rules. Application frameworks often hide open options—verify Spring JMS, Quarkus, and COBOL connection settings when scaling instances. Second instance failing at startup is the classic SHARE mismatch symptom.
IBM MQ queue sharing groups (QSG) let multiple queue managers access coupling facility shared queues—a different feature from the SHARE attribute on a queue definition. The queue-sharing tutorial covers QSG. Here SHARE means object attribute for concurrent application getters on one queue manager (or member). Both terms say “share” but address different layers—do not confuse them in architecture reviews.
Dynamic reply queues from QMODEL often use SHARE(ENABLED) when only one client owns the reply queue—exclusive is also valid for single-threaded clients. Request queues for competing consumers use SHARE(ENABLED). Match model SHARE to client concurrency design.
Second consumer MQOPEN fails: compare SHARE, open options, and whether first consumer holds exclusive browse. Throughput flat with many instances: instances may serialize on one queue partition, poison message blocking get, or SHARE(DISABLED). DISPLAY QSTATUS OPROCS IPSPROCS shows open handles—interpret per IBM guide for your release.
SHARE(ENABLED) means many workers can take tickets from the same line at once—each ticket goes to only one worker. SHARE(DISABLED) means only one worker is allowed at the ticket window at a time.
Design DEFINE QLOCAL for 8 competing consumers on WORK.Q.
Second instance fails MQOPEN. List SHARE, open option, and first instance checks.
Explain difference between SHARE attribute and z/OS queue sharing group.
1. SHARE(ENABLED) supports:
2. Competing consumers need typically:
3. SHARE(DISABLED) implies:
4. MQOO_INPUT_SHARED relates to: