Tuning considerations for CICS Bridge Transaction
ByronBaldwin 06000099ST Comments (2) Visits (2391)
Recently I have worked on issues where clients are running into MAXTASK conditions when running bridge transactions. A contributing factor to the condition occurring is due to not properly coding MAXOPENTCBS comparable to the MAXTASK value in CICS Transaction Server for z/OS (CICS TS) 4.2 or lower.
(Please note for CICS TS 5.1, MAXOPENTCBS is obsolete. The limits for these types of open TCB are now set by CICS automatically based on the MXT value for the CICS region.)
When running these bridge transactions, CICS will start by initiating a CWXN transaction which will start a CWBA (alias) transaction. The alias transaction will start your user transaction. The CICS Bridge process uses a DRIVER (CWBA) and PARTNER (user defined transaction) transaction in order to complete. For the sake of this blog entry, my user transaction will be called USER.
Documentation revealed the USER transaction was attached at 9:00:00 but got suspended 9:00:07. This indicates the RECEIVE is not the initial receive for input from the browser but a subsequent receive. When the bridge application runs conversationally it issues a RECEIVE which causes it to ENQUEUE and enters a conversational wait for the RECEIVE to complete. This conversational RECEIVE will trigger the DRIVER Transaction (CWBA) to send a screen of data to the browser and then end. At this point your USER transaction is placed in a WEB_ECB type wait. This RECEIVE will complete when the browser user responds. This will start a new CWBA task which will join the partnership again and trigger PARTNER Transaction (USER) to run.
Below is an example of a stack in a WEB_ECB wait:
0000 237E7040 01D0 Bot 21A03C00 A1A04236 000636 DFHKETA 0000 237E7210 03E0 Dom 21A209A0 A1A20BE4 000244 DFHDSKE 0000 237E75F0 0FC0 Dom 21A514A0 A1A52986 0014E6 DFHXMTA 0000 237E85B0 06D0 Dom 2213CD38 A213DEAE 001176 DFHPGPG Int +000374 A213CED4 00019C INITIAL_LINK 0000 237E8C80 0E40 Dom 224A2F00 A24AE626 00B726 DFHAPLI1 Int +002894 A24A3B32 000C
The MAXTASK condition occurred in this example due to a number of contributing factors (ZCIOWAITS, IRLINK waits, and DISPATCH OPENPOOL waits). In this example, the client had MAXTASK set at 200 and MAXOPENTCBS set to 50. So once all MAXOPENTCBS were in use the USER transaction would stay in the WEB_ECB wait and any task requesting to run on a L8 or L9 TCB would be placed in a DISPATCH OPENPOOL wait until CICS reached MAXTASK.
Outside of resolving the IRLINK and ZCIOTWAITs, it was recommended the client increase the MAXOPENTCBS to allow the bridge transactions to complete. A standard way to calculate MAXOPENTCBS is (MAXTASK X 2) + 24 (to account for system tasks) = MAXOPENTCBS for CICS TS 4.2 and lower.
If there are any questions, concerns, or topics you would like to see blogged about please let us know.