SHARECNV (Shared Conversations)

Remote applications connect to IBM MQ through server connection channels. Each TCP connection costs setup time, TLS handshakes, and CHLAUTH evaluation. SHARECNV lets multiple logical MQ conversations ride on one connection, which is why application servers and microservice meshes can sustain thousands of MQPUT calls per second without opening thousands of sockets. Set SHARECNV too low and CPU spends life in connect/disconnect; set it too high without understanding MAXINST and client pool settings and one bad client can pin resources others need. Beginners configuring their first SVRCONN often copy SHARECNV(10) from a template without knowing what a conversation is in MQ terms—this tutorial defines conversations versus connections, explains SHARECNV numeric range and defaults, relates SHARECNV to Java connection pooling and MQCONNX, contrasts with message channel batching, and gives practical tuning steps for lab and production.

Connection vs Conversation

A TCP connection is the socket between client library and queue manager listener. An MQ conversation is a logical session on that socket: authenticate, open queues, syncpoints, disconnect conversation while optionally keeping TCP open for the next conversation. Before shared conversations, many clients opened one TCP connection per thread or per short-lived task. SHARECNV tells the server how many concurrent conversations may multiplex on the same channel instance connection. Client libraries must request shared conversation support compatible with the channel SHARECNV value—mismatch leads to extra connections or capability negotiation failures depending on client version.

SHARECNV tuning trade-offs
SHARECNV tendencyBenefitRisk
Low (1–2)Strong isolation per connectionHigher TCP and TLS overhead
Medium (~10)Good for app server poolsShared fate on connection errors
High (50+)Fewer sockets at extreme scaleHarder troubleshooting; resource pinning

Defining SHARECNV on SVRCONN

shell
1
2
3
4
5
DEFINE CHANNEL('PAYMENTS.APP') CHLTYPE(SVRCONN) TRPTYPE(TCP) + MCAUSER('apppay') SHARECNV(10) MAXMSGL(4194304) ALTER CHANNEL('PAYMENTS.APP') SHARECNV(15) DISPLAY CHANNEL('PAYMENTS.APP') SHARECNV MAXINST MCAUSER * Client: enable shared conversations in connection factory per IBM client docs

ALTER SHARECNV affects new connections after client reconnect; running pools may need application bounce to pick up optimal values. MAXINST caps parallel channel instances—if fifty JVMs each open ten conversations on one instance with SHARECNV(10), math matters for file descriptors and memory on the queue manager host.

Client Application Considerations

Java MQ classes support shared conversation settings on MQConnectionFactory (names vary by client version). .NET and C clients have parallel properties. Connection pooling in Spring or Jakarta EE should align pool size, SHARECNV, and queue manager MAXINST. A pool of twenty connections times SHARECNV(10) implies up to two hundred logical conversations if fully utilized—verify queue manager limits and OS ulimit. Heartbeat HBINT and TCP KAINT still apply to long-lived shared sockets; firewalls dropping idle TCP affect all conversations on that socket simultaneously.

SHARECNV and Security

CHLAUTH rules still evaluate client connections; SSLPEERMAP may map certificates to MCAUSER per conversation. Lower SHARECNV does not replace CHLAUTH—it only reduces how many conversations share one TCP pipe. Regulated environments sometimes mandate separate SVRCONN definitions per application with SHARECNV(1) for audit clarity even at higher cost. Document which SVRCONN names map to which enterprise applications in your configuration management database.

Message Channels and SHARECNV

Distributed queue pairs (SDR/RCVR) move messages in bulk with BATCHSZ rather than client-style SHARECNV tuning. DISPLAY CHANNEL on an SDR may still show SHARECNV for completeness; focus performance work on BATCHSZ, BATCHINT, and network bandwidth for message channels. Do not copy SVRCONN SHARECNV numbers onto SDR without IBM guidance—they solve different problems.

Explainer: Carpool Lane

TCP is the highway. SHARECNV is how many passengers (conversations) may carpool in one car (connection) before MQ says open another car. More carpooling saves gas (CPU) but if the car breaks down, every passenger is delayed together.

Monitoring

  • DISPLAY CHSTATUS on SVRCONN—count instances and conversations where supported.
  • Operating system netstat—socket count to listener PORT should correlate with instance design.
  • Application metrics—connect rate versus MQPUT rate; high connect rate suggests SHARECNV or pool misconfiguration.
  • Queue manager error log—conversation limit or channel limit messages.

Explain Like I'm Five: SHARECNV

SHARECNV is how many friends can talk on the same phone call to the queue manager before MQ asks them to use a second phone line.

Practice Exercises

Exercise 1

Calculate max conversations: 8 app servers, pool size 5, SHARECNV(10)—what should MAXINST be at minimum?

Exercise 2

Write MQSC for two SVRCONN channels: batch reporting (low rate) vs payments (high rate) with different SHARECNV rationale.

Exercise 3

After firewall idle timeout, why might all pooled conversations fail at once?

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. SHARECNV mainly tunes:

  • Conversations per TCP connection
  • Queue MAXDEPTH
  • DLQ name
  • Topic wildcard

2. Higher SHARECNV often:

  • Reduces connect overhead
  • Disables TLS
  • Removes listener
  • Sets CHLTYPE SDR

3. SHARECNV is commonly set on:

  • SVRCONN
  • Transmission queue
  • Namelist only
  • Process definition

4. MAXINST vs SHARECNV:

  • Instance count vs conversations per connection
  • Same attribute
  • Cipher vs auth
  • Batch vs retry
Published
Read time17 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation