Controlling CICS bridge throughput

We can control the throughput of the bridge by putting the bridge transaction, CKBP, in a class of its own and setting the CLASSMAXTASK to suit your requirements.

If a high volume of requests is expected, you could consider starting a second or subsequent monitor task in another CICS region. Such monitors can each have a separate request queue for their sole use, which create. In this case you could give each monitor different service characteristics, but this has the disadvantage that applications have to know the names of the various queues.

We can avoid this problem by having several bridge monitors sharing the same request queue. In this case ensure that:

• all transactions in a 3270 pseudoconversation specify the remote SYSID returned by the first transaction in all subsequent messages in the pseudoconversation. This is required even if you use CICS transaction routing facilities to direct the transactions to other CICS regions.

• if you use passtickets for user validation, all bridge monitors for a queue specify the same PASSTKTA applid.

• each CICS region running a bridge monitor has a unique SYSID and there are CICS ISC links between the CICS regions.

When doing problem determination with multiple CICS bridge monitors you might have to look at all of the logs of all of the CICS regions to find any error messages produced by the bridge. We can use the command DISPLAY QSTATUS(queuename) TYPE(HANDLE) on each queue manager to show which CICS regions have the queue open.