IBM Support

PH01208: APPLICATIONS USING RECV WITH MSG_WAITALL MAY HANG IF DATA ARRIVES TOO SLOWLY FROM A PEER

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • An application that is using recv with msg_wait may hang
    without receiving all of the data from a peer. The issue arises
    if data arrives slower than normal inbound. This will cause
    TCPIP to move the unread application data to pageable buffers.
    In this scenario, if the msg_waitall size is larger than the
    TCP receive buffer size (either coded in the TCPIP profile or
    programatically by the application) can cause the receive
    buffer size calculated by TCPIP to be set smaller than the
    msg_waitall size. This can cause a zero TCP window to be sent
    to the peer, resulting in the flow of data from the peer to
    stop.
    

Local fix

  • Insure that the TCP receive buffer size is set to atleast the
    size of the msg_waitall size, either in the TCPIP profile or
    programatically by the application
    
    verification steps:
    
    a dump will show a receive event (x'20') with a msgwait_all size
    at offset x'10, which is larger than the TCB_RCVBUF_SIZE and
    TCB_SO_RCVBUF_SIZE. A TCB_RCV_WND of zero will also be set with
    data on the TCB_RECV_QLEN less then the msgwait_all size
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * IBM Communications Server for z/OS Version 2 Release 2 and 3 *
    * IP                                                           *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * TCP connection receive type operation with the MSG_WAITALL   *
    * flag does not complete                                       *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    Application issues a receive socket operation with the
    MSG_WAITALL flag and a buffer size that is greater than the
    connection ReceiveBufferSize.  The receive operation will not
    complete until the buffer size is satisfied or the connection
    terminates.  If the arrival of data on the connection is slow or
    consists of multiple small size packets the TCPIP stack will
    consolidate the pending receive data into pullup buffers for
    better memory management.  The connection receive window is
    limited to the connection ReceiveBufferSize when the receive
    data has been pulled up and will remain limited until an
    applicate receive operation completes.  The limited window
    prevents the peer from sending the data that is needed to
    satisfy the pending receive operation.
    The application should not issue a receive operation with a
    buffer size that is larger than the ReceiveBufferSize.  The
    ReceiveBufferSize can be manipulated using setsockopt() with the
    so_rcvbuf option and the value can be retrieved using
    getsockopt() with the so_rcvbuf option.  The value can only be
    manipulated prior to the connect() call on a client connect and
    prior to the listen on a server connection.  The maximum value
    that can be set using setsockopt() is limited by the TCPIP
    profile configuration value specified on TCPCONFIG
    TCPMAXRCVBUFRSIZE.
    

Problem conclusion

  • EZBTCFRD has been amended to expand the connection receive
    buffer size to the buffer size specified on a receive operation
    with the MSG_WAITALL flag set, limited by the TCPMAXRCVBUFRSIZE.
    Applications issuing a receive operation with the MSG_WAITALL
    flag and a buffer size larger than TCPMAXRCVBUFRSIZE will not
    benefit from this change.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PH01208

  • Reported component name

    TCP/IP MVS

  • Reported component ID

    5655HAL00

  • Reported release

    220

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2018-08-01

  • Closed date

    2019-02-06

  • Last modified date

    2019-05-02

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

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

    UI60907 UI60908

Modules/Macros

  • EZBTCFRD
    

Fix information

  • Fixed component name

    TCP/IP MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R230 PSY UI60908

       UP19/04/23 P F904

  • R220 PSY UI60907

       UP19/04/23 P F904

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":"220","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":"220","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 May 2019