DEFSOPT stands for default share option. It lives on your local queue definition and answers a practical question: when an application opens this queue to read messages, should the queue manager assume shared access (many readers can cooperate) or exclusive access (one reader owns input)? Beginners often discover DEFSOPT only after a second consumer fails to open a queue, or after migrating code from z/OS to Linux and seeing different default behavior. This page explains each DEFSOPT value, how it interacts with MQOPEN options and the separate SHARE attribute, platform defaults, and how to design work queues for competing consumers versus single-threaded batch drains.
Applications call MQOPEN with options such as MQOO_INPUT_SHARED or MQOO_INPUT_EXCLUSIVE. If the application specifies those bits clearly, the explicit request usually wins. DEFSOPT matters when code opens for input with minimal options—common in older samples and generated bindings—and relies on the queue definition to supply the share behavior. The queue manager combines queue attributes (including SHARE, which can inhibit shared opens entirely) with DEFSOPT to decide whether the open succeeds and whether another application can open for input at the same time.
| Value | Default input open | Typical use |
|---|---|---|
| SHARED | Shared input (MQOO_INPUT_SHARED implied) | Work queues with multiple competing consumers |
| EXCL | Exclusive input (MQOO_INPUT_EXCLUSIVE implied) | Single consumer, legacy batch, strict ordering by one thread |
| EXCLSHARED | Depends on application open options | Queues used both ways; apps must request the mode they need |
DEFSOPT(SHARED) is the pattern behind scalable message processing. Ten instances of the same Java or COBOL consumer can each MQOPEN the queue for shared input and MQGET messages in parallel—the queue manager delivers different messages to different threads (subject to message grouping and browse rules). Load increases by adding instances, not by making one program faster. Operations teams pair SHARED with TRIGGER or container autoscaling so depth on the queue spawns more workers. If SHARED is wrong for your business rule—only one financial reconciliation job may run—you need EXCL or application-level locking instead.
DEFSOPT(EXCL) defaults new opens to exclusive input. A second application attempting a conflicting open may receive MQRC_ALREADY_EXISTS or similar reason codes depending on options and platform. Exclusive access protects assumptions like “I am the only getter, so I can cache state in memory” or “this queue feeds a single sequential file writer.” On z/OS, queue definitions created without an explicit DEFSOPT often inherit EXCL from the queue manager default—migrations to distributed MQ that omit DEFSOPT in scripts can accidentally leave EXCL on queues meant for microservices, starving extra consumers.
EXCLSHARED tells the queue manager the queue supports both shared and exclusive input opens; DEFSOPT still records which mode is default when the application does not specify. A nightly batch job might open exclusive to drain the entire backlog alone, while daytime online programs open shared for parallel processing—provided SHARE on the queue allows shared access and applications use the correct MQOPEN bits. Misconfigured teams sometimes set EXCLSHARED but every program uses implicit defaults, so all opens behave like EXCL or all like SHARED without anyone noticing until load tests.
The SHARE attribute on a queue (YES/NO) is a gate: can this queue ever be opened for shared input? DEFSOPT chooses the default flavor when opens are ambiguous. A queue with SHARE(NO) cannot honor shared competing consumers even if DEFSOPT is SHARED—opens requesting shared input fail. Designing for scale requires both SHARE(YES) and DEFSOPT(SHARED) (or explicit MQOO_INPUT_SHARED in every program). Review both attributes in DISPLAY QLOCAL output during queue audits.
12345678DEFINE QLOCAL('ORDERS.WORK') REPLACE + SHARE(YES) DEFSOPT(SHARED) MAXDEPTH(500000) + DESCR('Competing consumer work queue') DISPLAY QLOCAL('ORDERS.WORK') SHARE DEFSOPT * Batch-only drain queue: DEFINE QLOCAL('RECON.NIGHTLY') REPLACE + SHARE(YES) DEFSOPT(EXCL) DESCR('Single exclusive consumer') ALTER QLOCAL('ORDERS.WORK') DEFSOPT(SHARED)
Best practice in new code is to set MQOPEN options explicitly rather than relying on DEFSOPT. In Java JMS, listener containers request shared access appropriate to their domain. In C and COBOL, MQCNO and MQOO flags should document intent in source control. Explicit opens make behavior identical across Dev, Test, and Prod even if someone clones a queue definition from z/OS with EXCL defaults. When reviewing a failure, capture the failing program's open options and compare to DISPLAY QLOCAL SHARE DEFSOPT.
IBM MQ queue managers on z/OS historically default DEFSOPT toward exclusive access for new local queues, reflecting decades of single-threaded consumers. On Linux, Windows, and Unix, defaults often favor SHARED. Never assume your sandbox matches production on another platform—export MQSC from each environment and diff DEFSOPT. Infrastructure-as-code pipelines should set DEFSOPT explicitly on every application queue so platform defaults cannot drift silently between regions.
The queue is a room with messages inside. DEFSOPT is the sign on the door saying whether new readers by default share the room or lock it for themselves. SHARED means several readers can walk in and each take different letters. EXCL means the first reader locks the door until they leave. Applications can still bring their own key (MQOPEN options), but if they do not, they follow the sign.
Three consumers should process one work queue in parallel. List the SHARE and DEFSOPT settings you would choose and one MQOPEN flag each program should set.
A queue migrated from z/OS to Linux still has DEFSOPT(EXCL). Symptom: only one Kubernetes pod gets messages. Write the ALTER command and rollout step.
When would EXCLSHARED be preferable to forcing SHARED on all queues?
1. DEFSOPT primarily affects:
2. Multiple microservice instances getting from one work queue usually need DEFSOPT:
3. DEFSOPT(EXCL) means the default open is:
4. Platform default for DEFSOPT often differs between: