IBM Support

PK50231: DFHAP0002 A SEVERE ERROR (CODE X'4E0D') OR (CODE X'4E12') HAS OCCURRED IN MODULE DFHAPCR.

A fix is available

Subscribe

You can track all active APARs for this component.

 

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

  • R400 PSY UK31280

       UP07/11/20 P F711

  • R500 PSY UK31281

       UP07/11/20 P F711

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