PM80004: NEW FUNCTION TO PROVIDE SUPPORT FOR NOTIFICATION WHEN A TCP CONNECTION IS TERMINATED.

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as new function.

Error description

  • New Function to provide support for notification when a TCP
    connection is terminated.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of the IBM Communications Server   *
    *                 for z/OS Version 1 Release(s) 13 IP          *
    ****************************************************************
    * PROBLEM DESCRIPTION: New Function to provide support for     *
    *                      notification when a TCP connection      *
    *                      is terminated.                          *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    New Function to provide support for notification when a TCP
    connection is terminated.
    
    In certain application models there is a need to recognize when
    the TCP connection has reached a point where the peer will send
    no additional data.  This can be caused by the peer application
    issuing a shutdown() or close() socket call.  The peer TCP/IP
    will generate a FIN or RST packet depending on the state of the
    connection and options set on the socket.  The local TCP/IP can
    generate a RST to the peer when a networking error is detected,
    preventing any new data from arriving.
    
    In the case of a RST packet in either direction, the local
    application can detect this condition using any i/o type socket
    operation.  In the case of a FIN packet inbound, a receive
    type socket operation will return with zero bytes after all
    queued data has been consumed.  If the local application is in
    a processing state unrelated to socket operations or is sending
    to the peer, the connection state change may not be detected.
    
    A mechanism that allows an application to issue a synchronous
    or asynchronous receive type socket API call that completes
    only when a TCP connection enters the state where no new data
    can arrive is being introduced.
    +-------------------------------------------------------------+
    + Please check our Communications Server for OS/390 homepages +
    + for common networking tips and fixes.  The URL for these    +
    + homepages can be found in Informational APAR II11334.       +
    +-------------------------------------------------------------+
    

Problem conclusion

Temporary fix

Comments

  • The MSG_CONNTERM flag is being introduced to provide a method of
    requesting notification when a TCP connection reaches the state
    where no new data will arrive.  This support is available on the
    recv(), recvfrom(), and recvmsg() functions in the z/OS XL C/C++
    Run-Time library.  This support is also available on the
    recv(BPX1RCV,BPX4RCV), recvfrom(BPX1RFM,BPX4RFM),
    recvmsg(BPX1RMS,BPX4RMS), and asynchio(BPX1AIO,BPX4AIO)
    assembler callable services.
    
    Usage considerations:
    1. MSG_CONNTERM requests that the function completes only when a
       TCP connection is terminated.  It is valid for TCP sockets
       only.
    2. MSG_CONNTERM will always result in the socket call being
       handled as a blocking call.  Due to the blocking nature,
       using MSG_CONNTERM in a synchronous fashion may require using
       a dedicated thread so other processing can continue within
       the application.
    3. MSG_CONNTERM is mutually exclusive with other flag values
       (MSG_OOB, MSG_PEEK, MSG_WAITALL).
    4. MSG_CONNTERM must use a buffer length of zero for recv() and
       recvfrom(), or an IOV element number of zero for recvmsg().
    5. If there are other normal outstanding receive requests,
       those receive requests will be completed too.  The
       application must be able to deal with the fact that a normal
       receive and this special connection termination receive may
       be driven in parallel.
    
    AT-TLS considerations:  If AT-TLS is being used to provide
    transparent TLS/SLL support for a TCP socket and a receive
    request with MSG_CONNTERM is outstanding, AT-TLS will
    immediately honor any TLS/SLL close notify alerts sent by the
    peer and initiate TLS/SLL session shutdown immediately as well.
    For more information on AT-TLS and determining whether a TCP
    connection is using AT-TLS refer to the Comm Server IP
    Programmer's Guide and Reference chapter on AT-TLS.
    

APAR Information

  • APAR number

    PM80004

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    1D0

  • Status

    CLOSED UR1

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    YesSpecatt / New Function

  • Submitted date

    2013-01-04

  • Closed date

    2013-02-27

  • Last modified date

    2013-04-02

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

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

    UK92097

Modules/Macros

  • EZBCTFME EZBITTRC EZBPFFSF EZBPFFSM EZBPFFSR
    EZBPFSDR EZBPFSRF EZBPFSRM EZBTCFRD EZBTCITS EZBTCRD  EZBZREAD
    EZB2TCB  ITEVENT  TOTCPDS
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R1D0 PSY UK92097

       UP13/03/30 P F303

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.



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

z/OS family

Software version:

1D0

Operating system(s):

z/OS

Reference #:

PM80004

Modified date:

2013-04-02

Translate my page

Machine Translation

Content navigation