PQ51829: STORAGE GROWTH BECAUSE TELNET LINEMODE PROCESSING DOES NOT FREE STORAGE ON F801 OR 4012 RETURN CODE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Customer experienced ABEND 4C5 reason: 74BE2500 . Subpool 231
  key 6 (sp231k6) was full of x'7000' allocations of pools of
  SKMB and SKDB message triples.
  Telnet client had sent data before negotiation had completed.
  It was being processed through Telnet Linemode processing.
  The data was moved into new messsage triples that are
  obtained in subpool 231 key 6.  Before sending the data
  to VTAM, Telnet recognized that negotiation never completed
  and set return code to F801 and disconnected the client.  The
  storage was not freed.   This caused a build up of storage in
  sp231k6.
  VERIFICATION STEPS:
   1) Use VSMDATA to determine what size of allocations were
      using up the largest amount of 231 key 6.
   2) if CSATRACKER was running, use VERBX VSMDATA 'OWNCOMM DETAIL
      SORTBY(LENGTH)' to determine the timeframe of the storage
      build up.
   3) Look at CTRACE for telnet error records during the time
      of the build up.  If there are alot of records showing
      a return code of x'F801' from modules EZBTPTDP, EZBTPLMB,
      and EZBTTRCV this may be the problem.
  ADDITIONAL SYMPTOMS:
  after application of PQ47399 the return code will be x'4012'
  instead of x'F801'
  

Local fix

• none
  KEYWORDS: ITSH SKMB SKDB LINEMODE F801 4012 STORAGE GROWTH
    4C5 ABEND4C5
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of Communications Server           *
  *                 for OS390 Release 5, 6, 7, 8 and             *
  *                 10 And z/OS Version 1 Release 2 IP           *
  *                 Telnet facilities with Linemode clients.     *
  ****************************************************************
  * PROBLEM DESCRIPTION: Subpool 231 key 6 storage growing at    *
  *                      a fast rate.                            *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Client connects and before negotiation is complete, sends in
  data that must get sent to VTAM. This causes a F801 reason code
  in the EZZ6035 message or 4012 if PQ47399 is installed. The
  client is disconnected following this, but the messagetriple
  that was being attempted to be sent is never freed.
  +-------------------------------------------------------------+
  + 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, EZBTPLMI will be changed to check the
  return code after calling the TVSERVERSEND routine, and if not
  zero, free the messagetriple before passing the return code back
  to cause the client to be disconnected.
  
  * 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:

  UQ57386 UQ57387 UQ57388 UQ57389 UQ57390

Modules/Macros

• EZBTPLMI
  

Fix information

• Fixed component name

  TCP/IP V3 MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R120 PSY UQ57386

     UP01/09/27 P F109 Ž

• R350 PSY UQ57387

     UP01/09/27 P F109 Ž

• R370 PSY UQ57388

     UP01/09/27 P F109 Ž

• R380 PSY UQ57389

     UP01/09/27 P F109 Ž

• R50A PSY UQ57390

     UP01/09/27 P F109 Ž

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.