CICS-MQ Bridge

CICS processes millions of short transactions per day; IBM MQ carries asynchronous work and enterprise events. The CICS-MQ bridge is the umbrella of techniques that connect those worlds—applications calling the Message Queue Interface inside a CICS task, trigger monitors starting programs when messages land, and syncpoint coordination keeping DB2 rows and MQ messages aligned. Banks still route authorization requests from MQ into CICS programs written in COBOL; retailers trigger inventory updates when warehouse messages arrive. Beginners should not assume MQ is only for Java in the cloud; on z/OS, CICS is often the consumer of record. This tutorial explains bridge concepts versus raw MQI, trigger-driven entry, transaction definition requirements, security through CICS and RACF, error handling and abends, performance considerations for high MQ volume into CICS, and how bridge patterns differ from distributed JMS listeners.

Integration Patterns

MQI From a CICS Task

Application programs link to MQ calls or use EXEC CICS wrappers depending on site standards. The task connection to the queue manager uses definitions in CICS and MQ that map the region to the correct QSG member. Units of work may end with EXEC CICS SYNCPOINT including MQ operations when coordination is enabled. Long MQGET waits inside CICS tasks can tie up transaction slots—architects use trigger patterns or shorter timeouts for high volume. Return codes must map to CICS HANDLE CONDITION or explicit error branches so poison messages do not loop silently.

1
2
3
4
5
6
7
8
9
Conceptual CICS task flow:
 
Transaction START
  -> MQCONN / implicit connection
  -> MQGET from WORK.IN
  -> update VSAM or EXEC SQL Db2
  -> MQPUT reply to WORK.OUT
  -> EXEC CICS SYNCPOINT
Transaction END

Trigger-Driven Bridge

A message on a queue satisfies trigger criteria; IBM MQ issues a trigger message to the initiation queue; CICS runs the trigger monitor (CKTI) which starts the application transaction with context from the trigger data. This decouples producers from CICS transaction IDs. Misconfigured PROCESS or TRIGGER objects cause messages to sit without CICS ever starting—operations watches depth on the application queue and initiation queue together.

Definitions and Resources

• CICS connection to queue manager—group name, auth, and attach limits.
• Transaction definitions for trigger monitor and application programs.
• MQ TRIGGER, PROCESS, and application queue TRIGGR attributes aligned.
• Program definitions with correct language and execution key.
• RACF profiles for CICS region user and MQ object access.

Security

The CICS region connects to MQ with a defined user; applications may run under transaction IDs with different authority. RACF checks MQ objects for put and get. Bridge patterns must not bypass controls by running all tasks in overly powerful IDs. Audit both CICS and MQ logs for failed authority during penetration tests.

Performance and Capacity

Each message-driven transaction consumes CICS task and MQ handle resources. Burst traffic from MQ can flood CICS MAXTASK limits. Throttle at MQ (backout, depth alerts) and CICS (max active, workload management). Consider shared queues on QSG for inbound work queues accessed from multiple LPARs serving CICS regions.

Explainer: Reception Desk Calling Workers

The bridge is the reception desk that phones the right CICS worker when a package (message) arrives, or hands the worker a phone (MQI) to call the warehouse directly during an existing conversation.

Explain Like I'm Five: CICS-MQ Bridge

The bridge helps the CICS program know when mail arrived in IBM MQ and helps it send mail back without leaving the CICS building.

Practice Exercises

Exercise 1

Diagram trigger flow from MQPUT to CICS application start for one queue at your site.

Exercise 2

List CICS and MQ definitions required for one new trigger-driven transaction.

Exercise 3

When would you avoid long MQGET in a CICS task and use triggers instead?

Frequently Asked Questions

Test Your Knowledge