IBM MQ Scenario-Based Interview Questions

Scenario-based interviews reward calm structure. The panel is not only testing whether you know that 2035 means not authorized—they want to hear how you would lead a bridge call when payments stop flowing because a channel entered RETRYING after a certificate expired. This page presents realistic case studies with model answers: symptoms, diagnostic order, commands, fix, and prevention. Adapt stories to your own experience; interviewers detect scripted answers that never mention logs or business impact.

Scenario 1: Channel in RETRYING After Maintenance

The story

Sunday maintenance completed on the network. Monday 08:00, DISPLAY CHSTATUS shows PARTNER.SDR in RETRYING. Transmission queue depth is 12,000 and growing. Payments from branch offices are delayed.

Model answer structure

  1. Confirm scope: one channel pair or all partners—DISPLAY CHSTATUS(*) WHERE(CHSTATUS EQ RETRYING).
  2. Check partner listener and port from sender CONNAME; telnet or TLS test from sender host.
  3. Review AMQERR on receiver for CHLAUTH or SSL handshake errors (2538).
  4. Verify certificate expiry and cipher mismatch if TLS recently changed.
  5. If auth: DISPLAY CHLAUTH and adjust scoped ALLOW rule, not global DISABLE.
  6. After fix, START CHANNEL; monitor XMITQ depth drain rate; notify business of ETA.
  7. Prevention: certificate expiry monitoring 30 days ahead; post-change validation script.

Scenario 2: Queue Full on ORDER.CREATED

The story

Ecommerce reports checkout failures. Application logs show MQRC 2053 on PUT to ORDER.CREATED. CURDEPTH equals MAXDEPTH.

Model answer structure

  1. Identify consumer: DISPLAY QSTATUS IPPROCS—are warehouse services running?
  2. If consumers down, restart pods or batch jobs; depth should fall.
  3. If consumers running but slow, scale consumers or optimize processing; temporary MAXDEPTH increase only with capacity approval.
  4. Check for poison messages causing crash loop—DLQ and backout count.
  5. Communicate: orders accepted if you enable temporary store-and-forward at edge (if architecture allows) or display maintenance page.
  6. Prevention: depth alerts at 70% MAXDEPTH; autoscaling on consumer CPU and queue depth metric.
Scenario symptom quick map
SymptomFirst checkCommon cause
RETRYING channelNetwork, TLS, CHLAUTHFirewall or cert
2053 on PUTCURDEPTH vs MAXDEPTHSlow or dead consumer
2035 on OPENOAM and MCAUSERAuth regression
2085 on OPENObject exists on QMWrong QM or typo
DLQ growthMessage payload sampleSchema or poison

Scenario 3: Migration Weekend Cutover

The story

You migrate applications from QM_OLD to QM_NEW. Parallel run was planned. At cutover, half of traffic still hits QM_OLD; duplicate processing risk is raised.

Model answer structure

  1. Stop new puts to QM_OLD: remove aliases, stop channels, or application config flag.
  2. Drain QM_OLD queues with controlled consumers; compare depth zero before decommission.
  3. Verify CCDT and connection strings in all deployments—including batch JCL and CICS definitions.
  4. Reconcile idempotency: same payment reference must not post twice if both QMs processed overlap.
  5. Rollback plan: DNS or CCDT revert to QM_OLD if QM_NEW fails health checks.

Scenario 4: Security Incident — Anonymous Client Blocked

The story

New microservice deployed. Connections fail. AMQERR shows CHLAUTH blocked anonymous or user not mapped. CHLAUTH is ENABLED.

Model answer structure

  1. Confirm SVRCONN name matches client CCDT.
  2. Define CHLAUTH ALLOW rule for certificate DN or authenticated user with least privilege MCAUSER.
  3. Grant OAM put/get only on required queues to that MCAUSER.
  4. Reject DISABLE CHLAUTH as permanent fix; acceptable only in isolated dev with documented risk.
  5. Post-incident: add pipeline check that deployment includes auth policy manifest.
shell
1
2
3
4
DISPLAY CHSTATUS('PARTNER.SDR') ALL DISPLAY QSTATUS('PAYMENTS.XMIT') CURDEPTH DISPLAY QSTATUS('PAYMENTS.REQUEST') CURDEPTH IPPROCS * Scenario interviews: say which DISPLAY you run and what you learn from each

Scenario 5: Duplicate Payments After Redelivery

The story

Consumer crashed after Db2 commit but before MQCMIT. Messages reprocessed. Finance reports duplicate posts.

Model answer structure

Explain at-least-once delivery. Consumer must use idempotency table keyed by business reference. Fix forward: add unique constraint and duplicate detection; replay DLQ only after code fix. Interview gold: tie MQ semantics to business control, not only restart the listener.

How to Present Scenario Answers

  • Restate the business impact in one sentence.
  • Prioritize checks that are fast and non-destructive.
  • Name specific DISPLAY commands and log files.
  • State what you would not do (disable security globally).
  • Close with prevention and monitoring improvement.

Explain Like I'm Five: Scenarios

The interviewer tells a story about something broken. You play detective: look at the clues (logs and commands), say what you think broke, fix it, and tell how to stop it breaking again.

Practice Exercises

Exercise 1

Pick two scenarios; answer in writing under five minutes each.

Exercise 2

Break a lab channel; time yourself fixing it using only your written steps.

Exercise 3

Convert Scenario 2 into a STAR story from a fictional on-call shift.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. Channel RETRYING first check:

  • Partner connectivity and CHLAUTH/TLS
  • MAXDEPTH only
  • JCL
  • COBOL compile

2. Queue full producer sees:

  • MQRC 2053
  • 2033
  • Only success
  • 2080 only

3. After firewall change suspect:

  • Channel not RUNNING
  • Wrong DNS for unrelated app
  • Browse only
  • Topic delete

4. Poison message fix includes:

  • DLQ and root cause on payload
  • Disable all security
  • Delete QM
  • Infinite retry
Published
Read time20 min
AuthorMainframeMaster
Verified: IBM MQ 9.4 documentation