A fix is available
APAR status
Closed as program error.
Error description
Program A has issued a LINK to Program B, passing a CHANNEL and an invalid TRANSID. An INQUIRE_CHANNEL is done to get the channel token, and program EYU9XLOP. After that completes, DFHEPC calls DFHISP CONVERSE, and the request is sent to run the program in another region. This generates the IR3783 error due to the invalid transaction ID. The routing program EYU9XLOP is driven again to inform it of the routing failure. DFHEPC goes around its loop a second time, and makes another call to ISP CONVERSE. This time the register 2 value has changed, and so DFHEPC incorrectly think that there is no channel, and does not populate the channel token into the data passed to DFHISP. This is why DFHAPCR is called with nulls instead of the channel token, and is what causes the 0C4 in DFHAPCR. Additional Symptom(s) Search Keyword(s): DFHIR3783 KIXREVxxx
Local fix
n/a
Problem summary
**************************************************************** * USERS AFFECTED: All CICS users * **************************************************************** * PROBLEM DESCRIPTION: An 0C4 program check happens after a * * TRANSID with hexadecimal characters is * * used in a Dynamic DPL with a CHANNEL * * and the routing is re-driven by a * * dynamic routing program. * **************************************************************** * RECOMMENDATION: * **************************************************************** An EXEC CICS LINK request is sent in with a CHANNEL and a TRANSID containing some hexadecimal characters (e.g.x'00'). DFHEPC is called to handle the request and it uses a TRT instruction to test whether the TRANSID contains any hexadecimal characters. The TRT test table is set up to treat anything other than the following as a hexadecimal character... A-Z a-z 0-9 $ . < + | & ! * ; ? - / , % _ > ? : # @ = " The TRT instruction sets registers R1 and R2 if a hexadecimal character is found. In this case the address pointer for ARG0 is corrupted because R2 is being used to address ARG0 in DFHEPC. The request is then shipped to the remote system but it is rejected. DFHEPC calls the dynamic routing program which allows the request to be re-routed. However, the TRT instruction has set R2 and the ARG0 address pointer is corrupt. DFHEPC incorrectly sets a zero channel token and uses that token to ship the request. The result is an S0C4 program check in DFHAPCR routine ESTIMATE_ALL. Additional keywords: msgDFHAC2001, abendAXGA
Problem conclusion
DFHEPC has been changed to save and restore register R2 when using a TRT instruction.
Temporary fix
FIX AVAILABLE BY PTF ONLY
Comments
APAR Information
APAR number
PI40696
Reported component name
CICS TS Z/OS V5
Reported component ID
5655Y0400
Reported release
800
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2015-05-07
Closed date
2015-05-29
Last modified date
2015-07-01
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI28043 UI28044
Modules/Macros
DFHEPC
Fix information
Fixed component name
CICS TS Z/OS V5
Fixed component ID
5655Y0400
Applicable component levels
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.
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"5.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"5.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
01 July 2015