OA25526: IO00 BUFFER GROWTH BIND UNBIND RU STRANDED

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• IO00 IO buffer growth.  Buffers contain TSCBs with BIND /
  UNBIND RU.  The TSCB with the BIND RU has a TSCNEXT pointer
  that points to the TSCB with the UNBIND RU.  The BIND TSCB
  is not on the BSBQBIND queue - a search on the TSCB address
  shows nothing pointing to it.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All using VTAM boundary function.            *
  ****************************************************************
  * PROBLEM DESCRIPTION: IO buffer pool (IO00) fills up with     *
  *                      BIND and UNBIND TSCBs.                  *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem is summarized as follows:
  
  1) A local application is in session with a channel attached
     independent SNA LU.
  2) The session UNBINDs, but the BSB (boundary control block)
     is not deleted from the Rex hash table.  The local SNA LU
     must have issued an UNBIND cleanup ('320F'x) which allows
     the LFSID to be reused across the FID2 link.
  3) Meanwhile, the local independent LU sends another BIND to
     establish a session with the local application.
  4) Since the LFSID was reused, and the old BSB was still
     on the Rex hash table, the BIND TSCB (IO buffer) was
     queued to the BSBQBIND.  This is done since the BSB
     is in the process of cleaning up, but hasn't done so quite
     yet.
  5) It is assumed the local SNA LU UNBINDs the session at this
     point, and the UNBIND TSCB is also queued off the same
     BSBQBIND field.
  6) Should the local LU BIND the session one more time, the
     BIND and UNBIND IO buffers are lost, as the new BIND is
     stored directly in the BSBQBIND field without chaining
     the TSCBs together.  Storage for the previously queued
     BIND and UNBIND RUs are lost forever.  Eventually,
     the BSB will cleanup.  But during this window, IO
     buffers could be lost until the BSB is removed from the
     BSB Rex hash table.  Over time, if this process is
     repeated the IO buffer pool could grow consuming CSA
     resources.
  

Problem conclusion

• ISTBSCBQ - New segment FreQBIND has been created to free
             any BIND/UNBIND TSCBs that may be queued on the
             BSBQBIND queue upon receipt of a BIND for
             a BSB that is destined to be queued until the
             BSB is completely cleaned up.
  ISTBSCRT - Included for maintenance purposes.
  

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:

  UA42158 UA42159 UA42160 UA42161

Modules/Macros

• ISTBSCBQ ISTBSCRT
  

Fix information

• Fixed component name

  VTAM V4 MVS/ESA

• Fixed component ID

  569511701

Applicable component levels

• R1A0 PSY UA42158

     UP08/08/06 P F808 Ž

• R170 PSY UA42159

     UP08/08/06 P F808 Ž

• R180 PSY UA42160

     UP08/08/06 P F808 Ž

• R190 PSY UA42161

     UP08/08/06 P F808 Ž

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.