PM79869: TELNET PRINTER STOPS BEFORE THE PRINT JOB IS COMPLETED

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • Telnet printer client is in session with a print application.
    The print application sends all of the data to the Telnet server
    and then does an immediate UNBIND. The Telnet server processes
    the UNBIND before sending all of the data to the printer client.
    
    This problem can also be seen as a storage growth in the Telnet
    Server. If enough data is spooled by the print application to
    the Telnet Server, the Server could run out of private storage.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of the IBM Communications Server   *
    *                 for z/OS Version 1 Release 13 IP: Telnet     *
    *                 Services.                                    *
    ****************************************************************
    * PROBLEM DESCRIPTION: Printer output is ended before          *
    *                      it is complete.                         *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The problem may be summarized as follows:
    1. A connection is established to a Telnet printer.
    2. The PLU application is sending a print job to the
       printer.
    3. The sends to the printer client are completing
       asynchronously and Telnet is issuing Receives
       to VTAM before the send completes.
    4. The VTAM Receives allow pacing responses to flow
       to the PLU, which then sends more of the print job.
       The queue of data destined for the printer grows.
    5. When the PLU completes the sending of the print
       job and receives a pacing response for the last
       piece of data, it ends the session.
    6. The UNBIND arrives at Telnet before all the data
       is delivered to the printer and the connection to
       the printer is terminated before the print job is
       completely delivered.
    7. Another symptom may be that storage is exhausted if
       too much data gets queued up in Telnet.
    +-------------------------------------------------------------+
    + 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

  • A mechanism to delay the issuing of the VTAM Receive
    when the client send is going to complete asynchronously
    is achieved as follows:
    1. EZBDUCB has two new bits - one is for input to ttsend
       processing and indicates that the ttsend was issued
       on the EZBTVXRC thread, the other is for output from
       the ttsend processing and indicates whether EZBTVXRC
       is allowed to issue a new VTAM Receive.
    2. EZBTVXRC manages the new ducb bit that is
       input for ttsend processing.    EZBTVXRC checks the
       other new ducb bit to see if it is allowed to issue
       a new VTAM Receive.
    3. EZBTVXR2 indicates to ttsend that a VTAM Receive
        will need to be issued by some process when the
       send of the data to client completes.
       EZBTVXR2 also copies any indication from the
       ttsend procedure not to issue the Receive to the
       ducb for forwarding to EZBTVXRC.
    4. EZBZTTIF (ttsend) is updated with two bits -
       one for indicating a Receive is needed after the send
       and one for indicating to the ttsend issuer that it
       is not to issue Receive.
    5. EZBTTSND manages the bits that indicate if a Receive
       is needed or allowed in various situations.  It calls
       EZBTVRCV if a Receive is needed and now allowed,
       but it is not on the EZBTVXRC thread.
    6. EZBZTMOD/EZBTTMST are updated so
       EZBTTSND can call EZBTVRCV.
    7. EZBZASY also has a bit for remembering across an
       asynchronous completion that a Receive is needed.
    8. Other users of ttsend are recompiled.
    
    * Cross Reference between External and Internal Names
    

Temporary fix

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

Comments

APAR Information

  • APAR number

    PM79869

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    1D0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-01-03

  • Closed date

    2013-01-15

  • Last modified date

    2013-04-17

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

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

    UK90986

Modules/Macros

  • EZBDUCB  EZBTPACP EZBTPAYT EZBTPCCO EZBTPELU
    EZBTPHAO EZBTPHDB EZBTPHDR EZBTPISY EZBTPLMB EZBTPLMO EZBTPOEF
    EZBTPSOM EZBTPSOW EZBTPSTF EZBTPSUS EZBTPTDP EZBTPTKO EZBTPUSL
    EZBTPUSM EZBTPUSW EZBTPUTS EZBTRCLT EZBTRTFO EZBTTCCC EZBTTMST
    EZBTTSND EZBTTTSI EZBTVBND EZBTVCLR EZBTVSSC EZBTVXRC EZBTVXR2
    EZBZASY  EZBZTMOD EZBZTTIF EZB2ASY
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R1D0 PSY UK90986

       UP13/03/15 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 #:

PM79869

Modified date:

2013-04-17

Translate my page

Machine Translation

Content navigation