PM79869: TELNET PRINTER STOPS BEFORE THE PRINT JOB IS COMPLETED

Obtain the fix for this APAR.

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 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.