PM91679: DELAYACKS ARE DONE ON TELNET CONNECTION WHEN THEY SHOULD NOT OCCUR

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as unreproducible.

Error description

  • Customer is running IND$FILE to send a file from the host to the
    client. The file transfer sends data in a single PIU (OIC, Only
    In Chain). The client responds with a "Send More data". The
    Acknowledgement to this packet is delayed .2 seconds when it
    should not have been.
    
    This can occur anytime the host application sends data in a OIC
    PIU. However, it is more noticable with a file transfer because
    the transfer takes much longer to complete.
    

Local fix

  • In the IND$FILE configuration, change the buffer size to where
    it is greater that the VTAM logmode setting for the RUSIZES.
    10,000 would be a fairly safe number to use. This will result
    in the PIU being Chained (i.e. First-In-Chain, Middle-In-Chain,
    ...,Last-In-Chain). When the PIU from VTAM is chained, the
    Telnet Server sets the NODELAYACK and the file transfer will go
    much faster.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of Communications Server for       *
    *                 z/OS Version 1 Release(s) 10 IP:             *
    *                 Telnet Services.                             *
    ****************************************************************
    * PROBLEM DESCRIPTION: Slow file transfer because delayacks    *
    *                      is not turned off in all cases.         *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The problem may be summarized as follows:
    1. A connection sends large amounts of data to the client.
    2. The data arrives from VTAM without chaining.
    3. Telnet sends the data to the client, but does not tell
       TCPIP to turn on NoDelayAck for this send.
    4. TCPIP delays the ACK packet, delaying inbound data from
       the client.  This slows down the throughput.
    +-------------------------------------------------------------+
    + 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

  • Telnet is changed to correctly turn on the NoDelayAck
    flag when sending data to TCPIP.
    

APAR Information

  • APAR number

    PM91679

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    1A0

  • Status

    CLOSED UR3

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-06-24

  • Closed date

    2013-07-23

  • Last modified date

    2013-07-23

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

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

    UK96067

Modules/Macros

  • EZBTTSND
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R1A0 PSY

       UP



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

z/OS family

Software version:

1A0

Operating system(s):

z/OS

Reference #:

PM91679

Modified date:

2013-07-23

Translate my page

Machine Translation

Content navigation