IBM MQ V9.1 System Administrator common mistakes
IBM MQ V9.1 System Administrator · Understand the traps and how to avoid them.
Assuming a queue manager can be configured for a new listener or channel purely from memory of MQ V8 behaviour, and answering questions about attribute defaults (such as SHARECNV, TRPTYPE, or channel MAXINST/MAXINSTC) without checking what V9.1 changed.
The exam targets V9.1 specifically, and several defaults and capabilities differ from earlier releases (for example the default SHARECNV value and the deprecation of some SSL/TLS channel attributes in favour of SSLCIPH and certificate labels). Candidates prepared on older material pick the legacy default. The exam-writer expects V9.1 semantics.
What to do instead
Build a one-page delta sheet of V9.1-specific defaults and deprecated attributes and review it before the exam. For any question about a default value, recall the V9.1 documented default rather than the value you last used in production. Where a question tests behaviour you cannot confirm, reason from the documented V9.1 command reference rather than V8 habits.
Confusing the effect of ALTER QMGR versus ALTER QLOCAL versus ALTER QMGR on a running versus stopped queue manager, and answering that attributes like MAXMSGL, DEADQ, or MAXHANDS take effect immediately when they actually require a restart or only apply to new objects.
Many queue-manager attributes are read at startup or when the object is created, so ALTER QMGR succeeds but the change does not take effect until the queue manager is restarted. Candidates who only ever changed attributes on a stopped queue manager assume every change is live. The exam deliberately tests which attributes are dynamic.
What to do instead
Memorise the small set of genuinely dynamic queue-manager attributes (for example MAXCHL, MAXHANDS, and some event attributes) and treat the rest as requiring a restart. For queue attributes, remember that MAXMSGL on a queue is checked at put time but the queue manager-level MAXMSGL caps it. Practise by altering an attribute on a running queue manager and observing whether DISPLAY reflects the new value immediately.
Treating a channel as a single object during troubleshooting and proposing a fix on only one side (for example changing MAXMSGL or SSLCIPH on the sender but not the receiver), or forgetting that the channel definition must exist on both ends with matching names and compatible attributes.
Channels are paired objects: SENDER/REQUESTER on one side and RECEIVER on the other, with matching channel names and compatible security and message-size settings. Candidates who have only administered one queue manager in a lab forget the remote definition. The exam frames scenarios where one side was changed and the channel still fails.
What to do instead
For any channel problem, enumerate both ends explicitly: channel name, type, TRPTYPE, SSLCIPH, certificate label, MAXMSGL, and the listener/port on the receiving side. When a question describes a channel that will not start, check that the receiver definition exists and that security attributes match before proposing queue-level fixes. Practise with a two-queue-manager setup so the pairing becomes instinctive.
Misdiagnosing a channel that is in RETRYING or STOPPED state as a queue problem, or assuming that a channel stuck in BINDING or INITIALIZING means the remote queue manager is down, when the actual cause is often a listener not running, a firewall, or an incorrect CONNAME/port.
Channel states are the primary diagnostic signal, and the exam tests whether you can read them. Candidates jump to message-level causes (full queue, authority) when the channel has not even reached the message-transfer stage. The distinction between RETRYING (retrying connection), BINDING (TCP connect in progress), and RUNNING (transferring) is frequently tested.
What to do instead
Learn the channel state machine and map each state to its most likely cause: RETRYING usually means the remote listener is unreachable or the CONNAME is wrong; BINDING that hangs suggests a network or DNS issue; a channel that starts then stops with a security error points to SSLCIPH or certificate mismatch. When a scenario gives a channel state, let that state drive the diagnosis before considering queue depth or authority.
Answering security questions by reaching for CHLAUTH rules alone and ignoring the interaction between CHLAUTH, the channel's MCAUSER, the queue's authority records, and the context (put authority, user ID propagation) that determines the effective identity at put time.
MQ security is layered: CHLAUTH decides whether a connection is allowed and can set MCAUSER; the effective user ID then determines queue access via OAM authority records; message context and PUTAUT decide which identity is used for context fields. Candidates fix one layer and are surprised the problem persists. The exam tests the interaction, not isolated facts.
What to do instead
For every security scenario, trace the identity path end to end: inbound channel authentication (CHLAUTH), resulting MCAUSER, the OAM authority check on the target queue, and any context/PUTAUT rules. State which layer you are changing and why. Review the CHLAUTH rule types (BLOCK, ADDRESSMAP, USERMAP, SSLPEERMAP) and their precedence, and remember that a BLOCK rule matched before a mapping rule wins.
Confusing TLS configuration elements: mixing up SSLCIPH (the cipher spec), the certificate label on the channel (CERTLABEL), the key repository location (SSLKEYR), and the certificate label in the key store, and therefore proposing the wrong fix for a handshake failure.
TLS on MQ channels involves several distinct attributes that must all be consistent, and V9.1 uses certificate labels rather than the older SSLPEER-based matching in many designs. Candidates who have only done basic TLS setup conflate the cipher spec with the certificate identity. The exam tests whether you can isolate which element is wrong.
What to do instead
Memorise the role of each attribute: SSLKEYR points the queue manager at the key database; CERTLABEL selects the personal certificate; SSLCIPH on both ends must be compatible; SSLPEER (where used) restricts the peer distinguished name. For a handshake failure, check cipher compatibility first, then certificate label and key repository, then peer-name matching. Use runmqakm or the IBM key management tool to verify the key store contents rather than guessing.
Assuming messages will always land on the queue named in the MQPUT call and ignoring name resolution: remote queue definitions, queue-manager aliases, transmission queues, and the dead-letter queue when the destination is unreachable. Candidates then misdiagnose 'message disappeared' scenarios.
A put to a remote queue resolves through a remote queue definition to a transmission queue and then to the destination, and if the channel is down the message waits on the transmission queue (or goes to the DLQ if it expires or the queue is full). Candidates who only tested local queues miss this indirection. The exam uses scenarios where the message is on the wrong queue.
What to do instead
For any 'where did the message go' question, trace the resolution path: local queue, remote queue definition (RNAME/RQMNAME/XMITQ), transmission queue, channel, destination queue. Check the transmission queue depth and the DLQ before concluding loss. Remember that a message can also be on the DLQ because the destination queue was full or the message expired in transit.
Answering trigger and application-related questions without distinguishing trigger types (FIRST, EVERY, DEPTH) and the role of the initiation queue, trigger monitor, and the process definition, and therefore predicting the wrong number of trigger messages.
Triggering has several interacting attributes (TRIGGER, TRIGTYPE, TRIGDPTH, TRIGMPRI, INITQ, PROCESS) and the exam tests the resulting behaviour, such as how many trigger messages are produced for a given put pattern. Candidates who have not configured triggering in a lab guess. The FIRST versus EVERY distinction is a common trap.
What to do instead
Work through triggering as a state machine: a trigger message is generated when the trigger condition is met, and with TRIGTYPE(FIRST) no further trigger message is produced until the queue is emptied or the trigger is reset, whereas EVERY produces one per qualifying put. Practise with a queue, an initiation queue, and runmqtrm so the counts become concrete. For any scenario, state the trigger type, depth, and whether the queue was emptied between puts.
Ignoring the dead-letter queue in troubleshooting: not checking whether a DLQ is defined, assuming the default SYSTEM.DEAD.LETTER.QUEUE exists, or failing to read the dead-letter header to identify why a message was dead-lettered.
Many queue managers in exam scenarios have no DLQ configured, in which case undeliverable messages are lost or the put fails, and the behaviour differs. Candidates who always assume a DLQ exists misdiagnose. The dead-letter header reason code is the authoritative clue, and the exam expects you to use it.
What to do instead
Always check whether a DLQ is defined (the DEADQ queue-manager attribute) before assuming messages were preserved. When a DLQ exists, read the dead-letter header (for example with amqsdlh or by browsing) to get the reason code, then map that code to its cause: queue full, no authority, message too long, expiry, or unknown object. Make 'check the DLQ and its header' the first step in any lost-message scenario.
Treating problem determination as a single command and not knowing the diagnostic chain: runmqsc DISPLAY commands, error logs (AMQERR01.LOG), FFST files, and the MQ trace facilities, and therefore choosing the wrong tool for a given symptom.
The exam tests whether you know where to look: queue-manager error logs for startup and channel errors, FFST files for internal failures, DISPLAY commands for current state, and trace for deep problems. Candidates who rely on one command cannot answer questions that ask for the appropriate next diagnostic step. The distinction between the queue-manager log and the system log is also tested.
What to do instead
Build a diagnostic decision table: symptom to first command to log to escalate to trace. Know the location and naming of AMQERR01.LOG (and rotation), the meaning of an FFST file and when it is produced, and that trace is a last resort because of overhead. For scenario questions, name the specific command or file you would inspect first and what output would confirm the diagnosis.