Bind Failures

Bind failures sit in the uncomfortable middle of channel troubleshooting: the network team sees TCP success, the security team may see TLS completed, yet DISPLAY CHSTATUS never reaches RUNNING and the channel flips to RETRY or INACTIVE with errors referencing bind, channel, or CHLAUTH. BINDING is the phase where queue managers agree they are the right partners—matching names, types, and policies—before message batches flow. Beginners who only ping the host miss the protocol layer entirely. This tutorial walks through the bind timeline, the most common misconfigurations, how CHLAUTH and SSLPEERMAP interact after encryption, MCAUSER and authority surprises, sequence errors that surface at bind, and a disciplined two-sided log correlation method you can use on your first on-call shift.

Timeline: From TCP to RUNNING

The sender opens TCP to CONNAME host and port on the listener. TLS may negotiate cipher suites and certificates. IBM MQ then runs channel bind processing: present channel name, exchange protocol version and capabilities, run channel authentication if enabled, establish logical sequence state, and transition to RUNNING when both sides accept. A failure at any post-TCP step leaves BINDING briefly or moves to RETRY with a specific LASTCHLERR. Receiver logs often contain the authoritative rejection reason even when the sender only reports generic bind failure.

Bind failure categories
CategoryExampleFix direction
Name mismatchSDR PARIS.LON vs RCVR PARIS.LONDONAlign DEFINE CHANNEL names
CHLTYPE mismatchSDR to SDRSDR pairs with RCVR
CHLAUTHBLOCK from ADDRESSMAPSET CHLAUTH ALLOW or MAP
SSLPEERCert DN changedUpdate SSLPEERMAP
SequencePost-DR skewCoordinated RESET

Channel Name and Type Pairing

shell
1
2
3
4
5
6
* QM_PARIS DEFINE CHANNEL('PARIS.TO.LONDON') CHLTYPE(SDR) CONNAME('london.corp(1414)') + XMITQ('SYSTEM.XMITQ.LONDON') TRPTYPE(TCP) * QM_LONDON — name must match DEFINE CHANNEL('PARIS.TO.LONDON') CHLTYPE(RCVR) TRPTYPE(TCP) DISPLAY CHANNEL('PARIS.TO.LONDON') CHLTYPE

Typos break bind immediately. Case sensitivity depends on platform conventions—treat names as exact strings. Cluster channels use CLUSSDR and CLUSRCVR with cluster naming rules; point-to-point uses SDR and RCVR. Requester and server pairs follow their own matrix—do not mix definitions from outdated WebSphere MQ guides.

CHLAUTH at Bind Time

With CHLAUTH ENABLED, inbound connections evaluate rules during bind. BLOCKUSER may reject asserted user IDs on SVRCONN. ADDRESSMAP may reject IP. SSLPEERMAP may reject cert DN. QMGRMAP may reject remote queue manager name. A BLOCK outcome never reaches RUNNING. DISPLAY CHLAUTH and search logs for the rule name—temporary narrowly scoped ALLOW for a known partner IP during a maintenance window is better than global DISABLE CHLAUTH, which auditors flag. After adding ALLOW, START CHANNEL again and confirm MCAUSER maps to an ID with correct OAM.

MCAUSER and Authority After Bind

Sometimes bind appears to succeed briefly then fails when the first put requires authority—less common than pure bind errors but worth checking when logs mention not authorized. Channel MCAUSER and mapped MCAUSER from CHLAUTH need +put on target queues. On z/OS, profiles differ from distributed OAM but the principle is the same: identity used at bind must be authorized for intended objects. Test with a small persistent message after RUNNING.

TLS Versus Bind: Split Diagnosis

  • Handshake fails—no BINDING; see SSL handshake failures tutorial.
  • Handshake OK, immediate RETRY with CHLAUTH—fix rules or SSLPEER.
  • Handshake OK, sequence error—DR recovery, not firewall.
  • Never reaches partner—connection refused; listener or CONNAME.

Splitting the timeline prevents thrashing: teams rotating certificates while the channel name is wrong waste hours. Capture one failed attempt with millisecond-aligned logs on both sides.

Two-Sided Correlation Procedure

  1. Note exact UTC time of failed START or automatic attempt.
  2. Sender DISPLAY CHSTATUS ALL; save LASTCHLERR.
  3. Receiver DISPLAY LSSTATUS; confirm connection attempt arrived.
  4. Receiver error log search CHLAUTH or channel name in same second.
  5. Compare channel names and CHLTYPE on both QMs.
  6. DISPLAY CHLAUTH(*) if security suspected.
  7. Apply fix; STOP and START on sender after receiver ready.

Explainer: Handshake at the Security Desk

TCP is walking in the building. TLS is showing ID at the front desk. BINDING is the meeting where both sides confirm they are the expected project partners with the right badges—if the meeting name on the door does not match, you leave even though you passed the desk.

Explain Like I'm Five: Bind Failures

You and your friend picked a secret club name to meet, but one of you said the wrong secret word at the door—so the club does not let you play together even though you arrived at the right building.

Practice Exercises

Exercise 1

Given mismatched channel names in a diagram, write the corrected DEFINE pair.

Exercise 2

Parse a sample CHLAUTH block log line and draft SET CHLAUTH fix with CHNAME scope.

Exercise 3

Explain to a network engineer why ping success does not prove bind success.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. BINDING happens:

  • After TCP connect during protocol exchange
  • Before TCP
  • Only on DLQ
  • Only for topics

2. SDR and RCVR names must:

  • Match
  • Differ
  • Be random
  • Equal XMITQ name

3. TLS OK but bind fails—check:

  • CHLAUTH and channel names
  • Only BATCHSZ
  • DEFPSIST
  • Namelist

4. CHLAUTH BLOCK during bind shows in:

  • Error log and CHSTATUS
  • Only SMF
  • JCL
  • CICS trace only
Published
Read time20 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation