PQ87604: Telnet Server Hung Due to Lock Contention

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The lock contention is a result of the following events:
  1) A connection is accepted by Telnet, the solicitor screen
     is sent and the user enters userid and password.
  2) Telnet task EZBTTTSK calls EZBTPRAC (call to RACF) to verify
     the userid and password.  EZBTTTSK gets the TCVB lock shared
     before making the call.
  3) Because of no activity for an exended period of time, RACF
     issues message ICH303I INACTIVE INTERVAL EXCEEDED BY SPECIAL
     USER.  This message is followed by WTOR which requires an
     operator rsponse to activate this userid.
  
  4) At the same time other Telnet tasks get invoked to process
     CVB deletes and require the TCVB lock exclusive. They get
     suspended because the lock is still held by shared EZBTTTSK,
     who cannot release the lock until RACF has completed
     processing the verify.  This caused the Telnet server to be
     hung and no new connections or Telnet displays are possible.
  
  VERIFICATION STEPS:
  1) Lock report will show contention for TCVB lock.
  2) The ducb report will show many suspended tasks that are
     doing timemark processing and delete CVB processing and
     are waiting on TCVB lock.
  

Local fix

• Operator should respond to WTOR as soon as possible.
  This will allow RACF to complete the Verify request and
  the Telnet task will release the TCVB lock.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of Communications Server           *
  *                 for z/OS Version 1 Release 2, Version 1      *
  *                 Release 4 and Version 1 Release 5 IP Telnet  *
  *                 facilities.                                  *
  ****************************************************************
  * PROBLEM DESCRIPTION: Telnet server becomes locked up after   *
  *                      a RACF call is done for a new           *
  *                      password, and Racf issues WTOR for      *
  *                      permission for the user to enter or     *
  *                      not.                                    *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem begins with a client with an expired password
  to RACF. A new password is requested from the client, and
  Racf is called while the CVB lock is held shared.
  Racf does the WTOR to the operator and the operator does not
  reply to it, so it hangs. Next EZBTTTMI, the inactivity routine
  finds this same client and calls EZBTTCLS to disconnect the
  client. EZBTTCLS releases the CVB shared lock and requests it
  exclusive so this process is suspended. EZBTTTMI was holding
  the TCFGCVB lock shared at this time. Next, more than 10 CVBs
  are queued to the CVBDELETEQ so command control is posted to
  to cleanup and delete the CVBs. EZBTMCVB requests the TCFGCVB
  lock exclusive, but is suspended because EZBTTTMI has it held.
  Next EZBTTCVB requests the TCFGCVB lock shared, and gets
  suspended because of the pending exclusive request. Now no new
  connections can come in. The server doesn't have an Accept put
  up.
  +-------------------------------------------------------------+
  + 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

• To resolve this problem, EZBTTTSK will be changed to get the CVB
  lock exclusive for any RACF needed CMRB request. Then in
  the ROUTECMRB routine, after the return from Racf, the CVB lock
  will be released and the request the lock shared.
  EZBTTTMI, the inactivity timer routine, and EZBTTTSI, the
  scaninterval routine already have the CVB lock request as share
  nowait. This will cause any CVB held exclusive to be skipped on
  this interval. This will prevent the server from becoming hung
  up. This missed WTOR will only affect the user involved.
  Note: If this occurs and a stop of TCPIP is done or a stop
  port is done to TELNET, it will not complete until the operator
  replies to the WTOR outstanding.
  
  * 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:

  UQ88334 UQ88335 UQ88336 UQ88337

Modules/Macros

• EZBTTTSK
  

Fix information

• Fixed component name

  TCP/IP V3 MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R120 PSY UQ88334

     UP04/05/25 P F405 Ž

• R140 PSY UQ88335

     UP04/05/25 P F405 Ž

• R150 PSY UQ88336

     UP04/05/25 P F405 Ž

• R160 PSY UQ88337

     UP04/06/02 P F406 Ž

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.