Why is the CKBP transaction performing badly?

We have a CICS region that uses the CICS-WebSphere MQ bridge. During higher than normal volumes we see periods of time where there are large gaps for CKBP tasks.

Messages are sent in groups of 6, each with MQCI_NEW_SESSION in the Correlid and MQCUOWC_FIRST in UOWControl. Normally the 6 messages (CKBP tasks) get processed in less than 2 or 3 seconds, but on the days when delays occur they are slow and can take up to 11 seconds.

CKBR is started with AUTH=VERIFY_ALL. A CICS trace shows that AUTHENTICATE_USERID is taking relatively long to complete. During that processing, MQ makes a RACROUTE REQUEST=VERIFY request (MQ trace entry id VRFYSAFN). A large portion of that gap has to do with ENQ/DEQ requests for SYSZRACF as seen in the systrace.

If additional systems are added to the GRS RING in the future, it is also recommended to use Ring Acceleration by specifying ACCELSYS(2). RING acceleration defines how many systems must see the RSA-message before a system sends the shoulder-tap acknowledgment.

If there is not an authentication delay, some other things to check include:

Have your performance specialists check RMF for any CPU or WLM delays for CICS, MQ, or RACF; DASD delays for data sets associated with those products; or storage constraint.

Be sure the bridge request queue is defined with INDXTYPE(CORRELID) as recommended at Setting up the CICS-WebSphere MQ bridge. If that is not set, it can cause delays for the bridge the larger the queue depth becomes.