A fix is available
APAR status
Closed as program error.
Error description
In one case, CICS ends up with a negative length (FFFFFFF9) which leads to the "DFHAP0002 A severe error (code X'4E0D') has occurred in module DFHAPCR". This results in a Getmain for this size, the Getmain doesn't fail, but then later CICS fails in DFHAPCR IMPORT_ALL function. DFHRZSO also uses the negative length. The trace will have: AP 4E0D APCR *EXC* - Extract_channel_header FUNCTION(IMPORT_ALL) COMMAND(SIBUS) ... TIOA Remaining FFFFFFF9 . This timing problem can also result in a "DFHAP0002 A severe error (code X'4E12') has occurred in module DFHAPCR." and the trace will have: AP 4E12 APCR *EXC* - Bad_Channel_Eye-catcher FUNCTION(IMPORT_ALL) COMMAND(SIBUS) ... . The problem is a 5 instruction timing window involving two tasks paired by request streams. What happens is as follows (TASK A and B are paired via an instore RZ): . - TASK A is waiting for the response from TASK B. - TASK B sends the response. - TASK A begins receiving the response. This is done via several RECEIVE_REPLY calls each reading data from the RUEI holding the response from TASK B. - TASK A needs to import the channel that is being returned so issues a DFHRZSO RECEIVE_REPLY call passing an 8 byte buffer. - This is processed by rzis_buffer_receive. - The state of the transport (tport.t_status) is checked to see if it is valid and found to be R (receiving). - The status is saved (in saved_t_status). >>> The L8 TCB that TASK A is running on now loses control of the processor. - TASK B terminates its half of the request stream which sets the t_status in the transport block for TASK A to U (unattached). - TASK A continues and checks the t_status for R (receiving) It is not R so the actual receive is bypassed. - TASK A then checks the saved_status for U (unattached). That was R (the actual status is now unattached) so the receive is again bypassed. - TASK A exits DFHRZSO RECEIVE_REPLY with an OK response but has not actually put any data in the buffer. - TASK A continues using residual data from the buffer. This results in the failures in DFHAPCR. . If the failing receive was for 8 bytes then the residual data is always an address and a fullword of 1. This leads to the getmain with a length of FFFFFFF9. If the failing receive was for the actual flattened channel you get the second failure complaining about an invalid channel header because the buffer is full of nulls.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All. * **************************************************************** * PROBLEM DESCRIPTION: MSGDFHAP0002 with code X'4E0D' OR * * X'4E12' using requeststreams. * **************************************************************** * RECOMMENDATION: * **************************************************************** A request is received which starts 2 tasks connected by request streams. Task A (source) sends a request to task B (target) and then waits for a response. Task B sends the response and task A begins to receive the response. The total response takes several RECEIVE_REPLYs to complete. Before all the replies are received, task A loses control and task B terminates, setting the status of the request stream to U (unattached). When task A resumes control, it checks to see that the status is R (receiving) and finds it to be false so does no actual data transfer. Now it depends on the timing as to what problem occurs. It could be one of the following; an exception invalid_header_read returned, an abend AP0002 following either a severe error code x'4E12' in module DFHAPCI or a severe error code x'4E0D' in module DFHAPCR. Additional keywords: APCR01 APCR02 4E12 4E0D
Problem conclusion
DFHRZSO has been changed in rzis_buffer_receive to always receive the rest of the data if the status is R(receiving) or U(unattached).
Temporary fix
FIX AVAILABLE BY PTF ONLY
Comments
APAR Information
APAR number
PK50231
Reported component name
CICSTS V3 Z/OS
Reported component ID
5655M1500
Reported release
400
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2007-08-01
Closed date
2007-11-15
Last modified date
2007-12-03
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK31280 UK31281
Modules/Macros
DESRZIS DESRZST DFHRZISC DFHRZSO DFHRZSO1 DFHRZTA
Fix information
Fixed component name
CICSTS V3 Z/OS
Fixed component ID
5655M1500
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":"3.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":"3.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
03 December 2007