CICS bridge improvements

There have been several improvements to the CICS bridge to allow work to improve availability and scalability by allowing work to be distributed across multiple CICS regions.

 

Multiple bridge monitors

The Bridge monitor task for a bridge queue can be run in multiple CICS regions connected to V6 queue managers allowing, with shared queues, the work to be distributed across a CICSplex. To support user verification by RACF passtickets across multiple regions a new PASSTKTA applid keyword has been added to monitor start up.

Note:

Existing 3270 bridge applications may need to be updated to propagate the MQCIH RemoteSysId field returned by the first transaction of a pseudo-conversation into the request messages of subsequent transactions. Multiple bridge monitors cannot be used from CICS regions attached to pre-V6 queue managers in a queue sharing group.

 

Transaction routing

User applications started by the bridge monitor no longer need to be run in the same CICS region as the bridge monitor this can be achieved by either CICS transaction routing facilities (when using CICS Transaction Server V2.2 or later) or MQ transaction routing by specifying the desired CICS system id in the MQCIH RemoteSysId field. When using CICS routing the target CICS region does not have to be connected to a queue manager while with MQ routing the target region must be connected to a queue manager that has access to the bridge queue.

 

Pseudoconversational programming model

The normal CICS programming model is pseudo-conversational with individual transactions linked to form a conversational flow and in the past the MQ messages sent to the bridge had to follow the same model with the first message for each transaction being a new session message. Now, when using CICS Transaction Server V2.2 or later, it is possible to include all of the MQ messages for multiple transactions within the same bridge session which reduces monitoring overheads and improves performance.

 

Additional headers tolerated

MQ headers with format names starting MQH and standard header chaining fields can be included in MQ bridge messages prior to the MQCIH header. They are not processed by the bridge but are returned unchanged in the bridge reply messages. Applications could use these headers to contain state data that they wish to flow with the message.

 

Expiration time control

To control the expiration time of reply messages application can specify either MQRO_PASS_DISCARD_AND_EXPIRY in the MQMD Report field or MQCIH_PASS_EXPIRATION in the MQCIH flags field. If either option is specified the reply message will have the remaining expiry time from the request message rather than unlimited expiry.

 

Failed messages to backout requeue queue

If a backout requeue queue is defined for the bridge queue it will be used for messages that have been backed out more than the backout threshold instead of being written to the dead-letter queue. If the backout queue doesn't exist or can't be written to then the dead-letter queue will be used unless the MQRO_DISCARD_MSG report option has been specified.

 

Operator messages destination control

Messages generated by the bridge can now be directed to the CICS master terminal (CSMT), CICS job log, or both.