IBM Support

OA40894: PERMFORMANCE DEGRADATION USING ZIIP ASSISTED IQDMULTIWRITE

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Connections traversing hipersockets experience performance
    degradation, the results of which range from slow data tranfers
    to connection termination.  The problem may not occur
    immediately after an IPL, but instead make take several days to
    surface.  Some of the symptoms include:
    
    1. Packet traces taken on both systems will show data leaving
    one system and never arriving on the other, or it will show the
    packets leaving one system but arriving at the other
    significantly later.
    
    2. Large packets are sent, but do not arrive until a small
    packet traverses the same hipersocket (the small packet may
    trigger the actual transmission of the other data across the
    hipersocket).
    
    This only affects connections which use zIIP assisted
    IQDIOMULTIWRITE, configured on the GLOBALCONFIG statement of the
    TCPIP profile.
    

Local fix

  • Disable the zIIP assisted IQDIOMULTIWRITE function by setting
    the GLOBALCONFIG ZIIP subparamater to NOIQDIOMULTIWRITE,
    either explicitly or by default (by simply removing the
    the subparamater value of IQDIOMULTIWRITE).
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All using Hipersockets IQDMULTIWRITE with    *
    *                 zIIP Assist.                                 *
    ****************************************************************
    * PROBLEM DESCRIPTION: Various symptoms (e.g., slow data       *
    *                      tranfer, connection termination) on     *
    *                      hipersockets devices running            *
    *                      IQDMULTIWRITE with zIIP Assist.         *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The problem may be summarized as follows:
    
    1. Packets are sent from the TCP/IP IF layer to VTAM
       (IUTLLCIZ).  They are destined to be written to a
       hipersockets device utilizing the IQDIOMULTIWRITE with
       zIIP assist functionality.  An enclave SRB is scheduled in
       this case.
    2. This gives control to the exit routine IUTLLCZ1, which sets
       up an RPH and passes the data to ISTLLCHI via escape.
    3. However, niether RPH_Pass_Thread nor RPH_Passed_Work are
       explicitly set, so their values are residual based on
       previous uses of that particular DWA workarea.  The fatal
       residual combination of RPH_Pass_Thread=ON and
       RPH_Passed_Work=0 causes ISTLLCHI to exit without resetting
       the synch byte (DINCB_Wr_Qpoint_WorkQ_zIIP_SRB_Lock) for the
       queue DINCB_Wr_Qpoint_WorkQ(3), thus leaving that SRB_Lock
       held erroneously.
    4. Any subsequent packets sent over this hipersockets device
       get queued to the DINCB work queue, but do not get processed
       because the synch byte is on.
    5. The data is left stranded on the queue until another packet
       (not using IQDIOMULTIWRITE with zIIP assist) is sent to the
       same destination.  That then causes all elements on the
       queue to be processed.
    

Problem conclusion

  • IUTLLCZ1 has been changed to explicitly set RPH_Pass_Thread=OFF
    and RPH_Passed_Work=0 during RPH setup.  This will ensure
    DINCB_Wr_Qpoint_WorkQ_zIIP_SRB_Lock is maintained properly by
    ISTLLCHI.
    
    ISTLLCM8 has been included for maintenance purposes.
    

Temporary fix

  • *********
    * HIPER *
    *********
    

Comments

APAR Information

  • APAR number

    OA40894

  • Reported component name

    VTAM V4 MVS/ESA

  • Reported component ID

    569511701

  • Reported release

    1D0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2012-11-28

  • Closed date

    2012-12-05

  • Last modified date

    2013-02-04

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

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

    UA67411 UA67412

Modules/Macros

  • ISTLLCM8 IUTLLCIZ
    

Fix information

  • Fixed component name

    VTAM V4 MVS/ESA

  • Fixed component ID

    569511701

Applicable component levels

  • R1C0 PSY UA67411

       UP13/01/17 P F301 Ž

  • R1D0 PSY UA67412

       UP13/01/17 P F301 Ž

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":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1D0","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSCY4DZ","label":"DO NOT USE"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1D0","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
04 February 2013