A fix is available
APAR status
Closed as program error.
Error description
Abend0C4 PIC11 on a Compare instruction ( 5910 F000 ) ( C R1,X'0'(,R15) ) at +x'286' into DSNXERD because Reg15 references a free page. The bottom half of Reg1 contains D7C24040 . The bottom half of Reg15 contains FD633B00. 7D633B00 is supposed to be the address of a PB ( Performance Block). The Compare instruction is validating that Reg15 addresses a PB. But 7D633B00 falls within a free page, causing the 0C4-11. This program check results in transaction abend AD2R abendAD2R . 7D633B00 is the address of the PB that was used by the prior transaction to use this thread. That PB was freed when that transaction ended. The current transaction using this thread has a different PB. When a connection/thread is IDENtified to Db2, CICS passes to Db2 the address of csb_wlm_perf_token ( CSB +x'DC'). As multiple transactions use this thread, one at a time, Db2 reloads the current PB from csb_wlm_perf_token when CICS calls Db2 to ASSOciate a new transaction to the thread. But CICS is populating csb_wlm_perf_token with a new transaction's PB *after* calling Db2 for ASSOciate. That is why Db2 uses the PB that belonged to the prior transaction. Getting the 0C4 in DSNXERD does not usually happen because CICS does not usually freemain a PB at the end of the transaction. CICS freemains the PB and the end of the transaction when there was a problem during CICS initialization that leaves the WLM Free Performance Block Array uninitialized. To check that in a dump of CICS, do verbx dfhpd730 'MN=3' and find on MNFPBA. If the array is all binary zeroes and below that you see Current XM Notified MXT Value = 0, then this region had a problem during initialization and will be freemaining PBs at the end of each transaction.
Local fix
Do CEMT INQ SYSTEM and scroll down to see MAXTASKS. Overtype the MAXTASKS value to make it one more or one less than it is. That should cause the WLM PB Array to be initialized, and that should cause CICS to quit freeing PBs at the end of each transaction, and that should cause the 0C4 in DSNXERD to stop. You can put the MAXTASKS value back to what it was if you want.
Problem summary
**************************************************************** * USERS AFFECTED: All CICS Users. * **************************************************************** * PROBLEM DESCRIPTION: Abend 0C4 in DSNXERD and Abend AD2R in * * CICS. * **************************************************************** It is possible for a CICS Db2 transaction to issue a GETMAIN for a WLM Performance Block. At transaction end the WLM PB is freed. However a field in the CSUB, csb_wlm_perf_token, still references the freed WLM PB and not the newly GETMAINed WLM PB. This freed WLM PB will now be used by Db2 to set up this connection. Using the freed WLM PB causes Db2 to abend 0C4 in DSNXERD and for CICS to take an AD2R.
Problem conclusion
DFHD2D2 has been changed to use the correct WLM Performance Block for each transaction.
Temporary fix
Comments
APAR Information
APAR number
PH41022
Reported component name
CICS TS Z/OS V5
Reported component ID
5655Y0400
Reported release
300
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2021-09-30
Closed date
2021-11-23
Last modified date
2021-12-01
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI78227
Modules/Macros
DFHD2D2
Fix information
Fixed component name
CICS TS Z/OS V5
Fixed component ID
5655Y0400
Applicable component levels
R300 PSY UI78227
UP21/11/24 P F111
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Line of Business":{"code":"LOB35","label":"Mainframe SW"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"5.6"}]
Document Information
Modified date:
02 December 2021