ESI wants MQ driven CICS transactions to be processed by the CEC with the most CPU capacity within the Parallel Sysplex

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

The required functionality we believe can be achieved on inserting "TOR" fron-end routers for inbound WMQ work. The TORs would use the link-neutral routing option introduced in CICS TS 4.2 and the sysplex-optimised routing function introduced in CICS TS 4.1. This RFE is being answered as closed, delivered, ie the functionality is already available.

Question 1 - All three CEC's in the Sysplex have multiple LPARs, with each LPAR containing MQ Queue Managers and CICS Regions. The reason that the customer chart focuses on the SYSE, POB1, and POA1 LPARs is that they are the only LPARs participating in the processing of Shared Queue Messages. This processing is made possible by starting a second CKTI in the appropriate CICS Regions against a shared Initiation Queue.

Question 2 – SYS 1 does have four AORs. TORs and QORs are not used since the workload is all distributed. The statement that “all (AORs are) just independent CICS regions competing to get messages from the same shared queues” is correct. The Region's independence is due to a second CKTI.

Questions 3 and 4 – We have been working with IBM ATS (Lyn Elkins for MQ and Steve Zemblowski for CICS) and IBM Hursley CICS Development (Dermot Flaherty) for almost two years trying to solve this issue. ESI has tried dedicated QOR's, custom polling programs, and other techniques, but none have worked. ESI feels that it is imperative that TRIGGER EVERY be used and that a 1:1 relationship between the MQ message and the CICS transaction be maintained to provide granular monitoring. This RPE has in fact been submitted on the advice of Lyn Elkins and Dermot Flaherty who have told ESI that this is the only feasible solution

Please could you provide some clarification for the following points:

1/  Parallel Sysplex of three CEC's (SYS1 - z196 (17 CPU) POB1 LPAR, SYSE – z196(16 CPU) SYSE LPAR, and PAID z10(36 CPU) POA1 LPAR).

We understand you have CECs called SYS1 (z196), SYSE (z196), and PAID (z10), but need clarification on what "POB1 LPAR", "SYSE LPAR", and "POA1 LPAR" mean. Does it mean there is just one LPAR on each CEC, or one LPAR for CICS on each CEC, or something else?

2 /SYSE has two CICS Regions while SYS1 and PAID have four CICS Regions each

Does this mean (for example) SYS1 has four AORs plus a TOR or a QOR or something, or if they are all just  independent CICS regions competing to get messages from the same shared queues. (The text seems to imply they are all simple competing regions.)

The picture also seems to indicate that the shared queues for the scenario are an init queue (IQ) and an application queue (LQ). Is this right? And are you using trigger-every ?

3/Depending on what the actual configuration might be, there are things they could maybe do. For example, maybe configure so that the trigger monitor issues EXEC CICS STARTs for the transaction that consumes the actual request messages. It should be feasible for those STARTs to be delivered to run in other regions using CPSM or custom workload routing. The trigger monitor would not need to run in all CICS regions but could (for example) run one or two of the z10 regions or in a new dedicated QOR.

Have you tried this?

4/ Have you tried any other solutions for workload management and if so what were the issues that prevented adoption?

Attachment (Use case)