PN88789: LPR CONNECTION TAKES TOO LONG TO CLOSE

Obtain the fix for this APAR.

APAR status

• Closed as new function.

Error description

• When using LPR, under TCP/IP, periodically, it takes longer for
  the connection to CLOSE once a print job is completed. This
  problem occurs when using a UNIX server, and heavy print
  activity.
  
  When this problem occurs, LPR is in a FIN_WAIT_2 state. It
  appears that LPD is not sending the FIN to LPR, and LPR remains
  in this state, until receiving the FIN. LPR is abiding by the
  Sockets protocol.
  If the FIN is sent by the server (LPD), then LPR will go into a
  time_wait state, which uses the standard 2MSL time delay for
  closing the connection. TCP/IP is using a TCPShutdown and
  TCPClose.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: TCP/IP 3.2 customers who use LPR or NPF.     *
  ****************************************************************
  * PROBLEM DESCRIPTION: After LPR is done using a TCP/IP        *
  *                      port, the port cannot be re-used for    *
  *                      a new connection for 2 minutes.         *
  *                      Issuing many LPR commands within 2      *
  *                      minutes can result in message           *
  *                      EZB1051E (MSGEZB1051E) because no       *
  *                      ports are available.                    *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  LPR (EZABB01Q) only does "shutdown" for the send direction
  of the TCP/IP connection to LPD.  The port is tied up in
  FINWAIT 2 state for 2 minutes during this normal shutdown.
  Since only 11 ports are available between each user and a
  particular printer, the user can run out of ports.
  
  For performance reasons, LPR should use a faster type of
  shutdown.  The setsockopt with the solinger is being used
  to cause a reset to occur which destroys the connection
  immediately.  Depending on the connection state at the time
  the close is done, the reset may not be sent.  This means
  there are still situations in which the timewait state will
  be entered for some LPR connections.
  

Problem conclusion

Temporary fix

Comments

• Modules EZABB01Q (LPR) and EZAPASSK were modified to
  default to the faster type of connection shutdown which
  terminates further operations in both directions (send and
  receive).
  
  A new option, "SLOWSHUTDOWN", was added to LPR allowing the
  slower type of TCP/IP connection shutdown in cases where it
  is needed.
  
  Additional Keywords:
  PASR 00055980 55980
  --------------------------------------------------------------
  A future release of publication SC31-7136-02 ( SC317136 )
  TCP/IP for MVS Version 3 Release 2 User's Guide
  will be updated as follows.
  
  On page 239 (in Chapter 5 Using Remote Printing),
  change the following line in the "SYNTAX" chart
  
  |--- Sjiskanji  ------|
  to
  |--- SJiskanji  ------|
  
  
  On page 239 (in Chapter 5 Using Remote Printing),
  add the following line to the "SYNTAX" chart
  after the SJiskanji entry.
  
  |--- SLowshutdown  ------|
  
  
  On page 244 (in Chapter 5 Using Remote Printing),
  to the LPR Parameters section change the heading "Sjiskanji"
  to "SJiskanji".
  
  On page 244 (in Chapter 5 Using Remote Printing),
  to the LPR Parameters section add the following paragraph
  after the paragraph describing "SJiskanji".
  
  SLowshutdown
  ------------
      Causes slower TCP/IP connection termination after the job
      is sent to the printer.  This option is rarely needed.
      This option is provided for print servers which discard
      the print job it just successfully received when LPR uses
      the fast shutdown.  Before using this option, check the
      print server for errors (such as spool file full) that
      may be causing the job to be discarded instead of printed.
  

APAR Information

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

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

  UN98063

Modules/Macros

• EZABB01Q EZAPASSK
  

Fix information

• Fixed component name

  TCP/IP V3 MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R320 PSY UN98063

     UP96/11/28 P F611

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.