IBM Support

PM04902: TASKS GETTING STUCK IN RZRSTRIG WAITS DUE TO PASSING DATA ON AN IMPORT_ALL REQUEST FOR A LENGTH OF 32767 + 4 BYTES.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • This problem occurs when the data being returned from an AOR is
    a multiple of 32767 + 4.  When the data is this size the 32767
    bytes of data get sent in the TIOA.  The data up to the end of
    the last full TIOA is enough to satisfy the IMPORT_ALL call made
    in the TOR.  By the length of data available exactly matching
    the available data, DFHAPTC returns LAST(YES) to the
    receive_reply routine in RZ domain.
    .
    Upon seeing LAST(YES) the RZ code believes that it has received
    everything.  When it gets called again by DFHPIPM to receive the
    4 byte trailer data it assumes that a new reply is being
    received to waits on RZRSTRIG for new data to arrive.
    .
    Meanwhile the AOR is waiting on IRLINK for the TOR to
    acknowledge receipt of the last TIOA and request the final 4
    bytes.
    .
    Additional Symptom(s) Search Keyword(s):
    KIXREVrer
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICS users.                              *
    ****************************************************************
    * PROBLEM DESCRIPTION: A webservice task gets stuck on an      *
    *                      RZRSTRIG suspend in a TOR while the     *
    *                      partner task in the AOR is stuck on an  *
    *                      IRLINK suspend.                         *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    A webservice request is received by a front-end CICS region
    (TOR). This executes under the control of the webservice
    pipeline. A service handler requests a context switch onto a
    different TRANSACTION ID. This ID is defined as remote so CICS
    uses REQUESTSTREAMS to propagate the webservice request to a
    back-end CICS (AOR).
    The AOR generates a webservice response which is passed back to
    the TOR in a channel. A 4-byte trailer is also sent back which
    follows the channel response.
    DFHPIPM receives the channel using REQUESTSTREAMS. The total
    length of data being returned is X'20000'. This is received by
    DFHAPTC - the REQUESTSTREAMS TC transport module. It is received
    in X'7FFF' chunks. The channel data makes up precisely 4
    X'7FFF' byte chunks. When the last section of the channel is
    received DFHAPTC detects that the X'7FFF' byte TIOA is now empty
    so returns LAST(YES). The REQUESTSTREAM state is therefore
    changed from inbound to outbound.
    DFHPIPM now calls REQUESTSTREAMS to receive the final 4-byte
    trailer which is still in the AOR. However, as the REQUESTSTREAM
    state is no longer inbound, the task suspends on RZRSTRIG -
    waiting to be triggered by the AOR.
    The AOR task is suspended on IRLINK - waiting for the TOR to
    receive the last 4-bytes of data.
    
    ADDITIONAL KEYWORDS :- MRO IRC
    

Problem conclusion

  • DFHPIPM has been changed to pass a LAST(NO) indicator when
    importing the channel which contains the webservice response.
    This notifies REQUESTSTREAMS that the imported channel is not
    the last block of data to be received. This stops REQUESTSTREAMS
    from switching the state to outbound during channel import.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PM04902

  • 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

    2010-01-12

  • Closed date

    2010-02-09

  • Last modified date

    2010-03-01

  • APAR is sysrouted FROM one or more of the following:

    PK73770

  • APAR is sysrouted TO one or more of the following:

    UK54235

Modules/Macros

  •    DESAPCR  DESPIIS  DESPIPM  DESRZRS  DESRZST
    DESRZTR  DFHAPCR  DFHAPCRA DFHAPCRM DFHAPCRT DFHAPCR1 DFHPIISC
    DFHPIISI DFHPIPM  DFHRZRMC DFHRZRMD DFHRZRSC DFHRZRSD DFHRZRS1
    DFHRZSO  DFHRZSOA DFHRZSOJ DFHRZSOM DFHRZSOT DFHRZSOV DFHRZSO1
    DFHRZTA  DFHRZTAA DFHRZTAM DFHRZTAT DFHRZTRC DFHRZTRD DFHRZTR1
    

Fix information

  • Fixed component name

    CICSTS V3 Z/OS

  • Fixed component ID

    5655M1500

Applicable component levels

  • R400 PSY UK54235

       UP10/02/17 P F002

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:
01 March 2010