A fix is available
APAR status
Closed as program error.
Error description
You have an AOR/TOR environment. The TOR taks an SVC dump with an AZI9 abend in module DFHAPCR at offset x'3DB2'. This is followed by the AOR issuing a DFHSR0622 message followed by an 0C4 abend in module DFHXTP. The AOR then begins to take repeated dumps and eventually abends. Upon review of the dump, you find that the failing instruction is an 0EE0. This is a move character long. Reg1 and RegF are being used as the length and are negative. When the data moves into storage which is protected, the 0C4 happens. The problem is due to the negative lengths on the MVCL instruction. Additional Symptoms:ABEND0C4 3DB2transformer KIXREVSCB
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All CICS Users * **************************************************************** * PROBLEM DESCRIPTION: Messages, DFHSR0622 An attempt to * * overwrite the ERDSA has caused the * * abend which follows; DFHAP0001 An abend * * (code 0C4/AKEA) has occurred at offset * * X'000033FC' in module DFHXTP. * **************************************************************** * RECOMMENDATION: * **************************************************************** A transaction routing request is received in an AOR with a CHANNEL that is greater than 32K in length. During transaction initialization, DFHXTP calls DFHAPCR IMPORT_ALL to unwrap the CHANNEL data. DFHAPCR IMPORT_ALL returns an EXCEPTION response with a reason TERMINAL_ERROR because the MRO communication with the TOR has been lost. The error is handled correctly by DFHXTP which then attempts to return to the calling module, DFHZTSP, by branching to label ALLDONE. Label ALLDONE is part of CSECT XFORM24E which uses register 9 as a base register. The CHANNEL upwrap routine, CDEARGCH_EXT, is part of CSECT XF24ARGE which also uses register 9 as a base register. When CDEARGCH_EXT branch to label ALLDONE, register 9 is not re-loaded with the base address of CSECT XFORM24E. This causes an incorrect path code in DFHXTP to be taken and messages DFHSR0622 and DFHAP0001 to be issued.
Problem conclusion
Routine CDEARGCH_EXT in DFHXTP has been changed to re-load register 9 with the base address of CSECT XFORM24E before branching to label ALLDONE after DFHAPCR has returned an EXCEPTION response with a reason code of TERMINAL_ERROR.
Temporary fix
********* * HIPER * ********* FIX AVAILABLE BY PTF ONLY
Comments
APAR Information
APAR number
PM24370
Reported component name
CICSTS V3 Z/OS
Reported component ID
5655M1500
Reported release
500
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt
Submitted date
2010-10-12
Closed date
2010-12-02
Last modified date
2012-07-16
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
PM26902 UK62750
Modules/Macros
DFHXTP
Fix information
Fixed component name
CICSTS V3 Z/OS
Fixed component ID
5655M1500
Applicable component levels
R500 PSY UK62750
UP10/12/07 P F012
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":"3.2","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":"3.2","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
16 July 2012