PM14467: LPD SERVER (LPSERVE) STOPS ACCEPTING NEW CONNECTIONS

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• LPSERVE is running normally, no error messages.  But at some
  point client (LPR) requests are no longer processed by the
  server.  Recycling the server restores normal operation.
  
  This problem can occur when there is a network port scanner
  being used to monitor server status, and that monitor
  immediately RESETs connections once they become established.
  
  
  Other Symptoms:
  
     Displaying the status of the listener port (515) will show
     that the backlog is full (CurrentBacklog matches
     MaximumBacklog), and the count of dropped connections
     (ConnectionsDropped) is increasing.
  
     From TSO:
        NETSTAT ALL SERVER (PORT 515
  
     From Unix Shell:
        netstat -A SERVER -P 515
  
     From Operator Console (z/OS 1.10 or higher):
        DISPLAY TCPIP,,NETSTAT,ALL,SERVER,PORT=515
  

Local fix

• Periodically recycle LPSERVE.  The period to choose for this
  depends on the level of scanner activity in the network and how
  quickly it RESETs the associated connections.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of the IBM Communications Server   *
  *                 for z/OS Version 1 Releases 9, 10, 11, & 12  *
  *                 IP: Pascal API                               *
  ****************************************************************
  * PROBLEM DESCRIPTION: Pascal listener stops accepting new     *
  *                      connections because the backlog is full *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The LPD Server (LPSERVE) is running and is using the Pascal API
  to listen for LPR requests on port 515.  A port scanner connects
  to port 515.  The connection is added to LPSERVE's backlog and a
  T_CONN_IND is built in order to notify the Pascal interface.
  Before the T_CONN_IND can be delivered, the port scanner resets
  the new connection causing the T_CONN_IND to be freed and the
  new connection to be deleted.  Thus, the Pascal interface never
  receives the T_CONN_IND and is therefore never aware of the new
  connection.  However, the new backlog entry is never deleted.
  This sequence of events continues to occur until the backlog
  becomes full.  Therefore, LPSERVE stops processing LPR requests.
  +-------------------------------------------------------------+
  + 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

• EZBTCRDG and EZBTCUTL have been amended to free the backlog
  entry if the new connection is reset before the T_CONN_IND can
  be delivered to the Pascal interface.
  
  * Cross Reference between External and Internal Names
  

Temporary fix

Comments

APAR Information

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

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

  UK57887 UK57888 UK57889 UK57890

Modules/Macros

•    EZBTCRDG EZBTCUTL ZZTOTCP
  

Fix information

• Fixed component name

  TCP/IP V3 MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R1A0 PSY UK57887

     UP10/07/03 P F007

• R1B0 PSY UK57888

     UP10/07/03 P F007

• R1C0 PSY UK57889

     UP10/07/03 P F007

• R190 PSY UK57890

     UP10/07/03 P F007

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.