PM04543: DFHDSAUT IS LOADED FOR EACH OPEN TCB, A SUDDEN INFLUX OF OPENS CAN CAUSE FRAGMENTATION OF LSQA STORAGE RESULTING IN 878 ABENDS.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• DFHDSAUT is being loaded for each OPEN TCB Request.  For
  example, a DB2 call will require an OPEN TCB which will then
  need to load DFHDSAUT.  So if we have a sudden influx of these
  calls then we are going to have a lot of concurrent Load
  Requests resulting in queueing to VSM.  This backup can cause
  fragmentation of the LSQA Storage which can result in receiving
  878 Abends.
  Additional Symptom(s) Search Keyword(s):
  ABEND878 ABENDS878 SOS Short on Storage
  LSQA subpool 255
  AQAT: Size 1000
   DFE: Size  E00 (for z/OS R1.10)
   DFE: Size  F00 (for z/OS R1.11) (see OA33234)
  In the storage still in use on these pages
  is the eyecatcher "TCB".
  In VSMDATA you can search on FBQE to see the fragmentation
  of storage in LSQA. You will see  x'1000' chunks. Here is an
  example:
  FBQE: Addr 008E8000 Size     1000
  FBQE: Addr 008EA000 Size     1000
  FBQE: Addr 008EC000 Size     1000
  FBQE: Addr 008EE000 Size     1000
  FBQE: Addr 008F0000 Size     1000
  FBQE: Addr 008F2000 Size     1000
  FBQE: Addr 008F4000 Size     1000
  FBQE: Addr 008F6000 Size     1000
  KIXREVDAM
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All.                                         *
  ****************************************************************
  * PROBLEM DESCRIPTION: Abend 878 at offset x'01DC' in module   *
  *                      DFHDSTCB.                               *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The CICS region suffered an abend878 in module DFHDSTCB. The
  cause of the 878 abend was fragmentation of LSQA storage which
  resulted in the LSQA hitting the CICS private storage area. The
  fragmentation occurred because the CICS region had issued a
  large number of attaches of open TCBs and each time a TCB is
  attached it will issue a LOAD of DFHDSAUT. DFHDSAUT can be
  placed in the LPA. If DFHDSAUT is in the LPA when the LOAD is
  handled by Contents Supervisor it contains logic which will
  queue any other requests to load DFHDSAUT until the first load
  has been completed. The queueing logic requires the obtaining of
  x'1E00' of working storage for each load request, however it is
  possible that only one page is freed and one page is still
  allocated. The CSV queueing logic requires x'1E00' of working
  storage for each load request. A separate process may obtain
  storage from within the remaining x'200' bytes of the first of
  these pages. This means that it is possible that only one page
  of the CSV working storage is freed at the end of the load
  request so the remaining page is still allocated.
  Keywords: CSVRBENQ AFDSP
  

Problem conclusion

• DFHCSVC has been changed. When the job step TCB loads DFHDSAUT,
  it saves its address in the job step TCB's AFCB. This address is
  propagated down to the QR TCB's AFCB and also to any immediate
  daughters of the QR TCB, such as the L8."
  

Temporary fix

•             *********
              * HIPER *
              *********
  FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

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

  PM05690 UK54544 UK54545

Modules/Macros

•    DFHCSVC
  

Fix information

• Fixed component name

  CICSTS V3 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R400 PSY UK54544

     UP10/02/26 P F002

• R500 PSY UK54545

     UP10/02/26 P F002

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.