PK07862: ABENDU3058 RC01 ISSUED FROM DFSBCB00 WHEN RELEASING A QSAV

APAR status

• Closed as program error.

Error description

• AbendU3058 with return code of 00000001 indicating "address
  type block to release was not found on any IPAGE."  It was
  issued by DFSBCB00 at label Abend99S.  Reg7 points to the block
  to be released and the eyecatcher is QSAV.  The savearea flow
  is DFSSDAB0, DFSSDA10, DFSCWU00, DFSCWU00-RELSAVE, UNK (may be
  more than one UNK).  In module DFSCWU00 at RELSAVE, we had
  issued a BCB release for GSAVs.  When the QSAV is encountered
  in the GSAV chain, that's when the abend is issued.  The QSAVs
  are in the chain residually.  There was a previous termination
  of a dependent region and the QSAVs were not cleaned up
  properly.
  This may occur after APAR PK01921.
  For the dependent region, there is an entry in LOGREC showing
  an ABEND0C4 in Term Thread processing.  The PSW is very close
  in proximity to the value in R2.  R13 points to the 15th Save
  Area (PSTSAV15).  This situation is caused when the Two Way
  ISWITCH leg the CTL Region runs before the leg under the
  Dependent Region.  The CTL Region leg runs using up to or beyond
  the 15th Save Area set, modifying the data in the 15th Save Area
  Set.  The Dependent Region leg subsequently expects the 15th
  Save Area set to contain data it had provided, but the CTL
  Region leg has overlaid this information.
  The dependent region shows the following in PSTSTRAC:
    9 - CREATE THREAD ENTERED
    A - CREATE THREAD EXIT
    B - TRM THREAD STARTED
    2 - TERM THREAD ABEND INDICATED
    B - TRM THREAD STARTED              (2nd term thread entry
    2 - TERM THREAD ABEND INDICATED      with ABEND indicated)
    C - TRM THREAD EXIT
    7 - SIGN OFF ENTERED
  Service for APAR PK01921 is not a complete fix.  Should there
  be an abend in Term Thread processing, the code provided by
  APAR PK01921 can allow a second QSAV area set to be obtained
  on entry to Term Thread which will lead to an ABENDU3058.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: IMS 910 customers with PK03503 / UK03678     *
  *                 installed.                                   *
  ****************************************************************
  * PROBLEM DESCRIPTION: ABEND3058 RC01 under the SDAB ITASK     *
  *                      after PK03503 resulting from a residual *
  *                      QSAV in a dependent region's PST during *
  *                      dependent region signoff processing.    *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  During Term Thread processing for a dependent region, a QSAV
  area is acquired and chained between GSAV4 and GSAV5. A bit is
  set to indicate that a QSAV was acquired and allows Term Thread
  to detect the QSAV and free it at the end of its process. A
  QSAV set is comprised of 8 save areas.
  
  The save chain appears as:
  PSTSAV1, PSTSAV2...PSTSAV19->GSAV1, GSAV2, GSAV3, GSAV4->QSAV1,
  QSAV2...QSAV8->GSAV5,GSAV6...GSAV10->PSTSAV20.
  
  PSTSKED7 in byte PSTSKED is turned on to indicate this save area
  chaining.
  
  If an ABEND during Term Thread occurs after PSTSKED7 has been
  set and the QSAV has been acquired, termination processing will
  attempt to complete Term Thread during ESTAE or EOT.
  
  When Term Thread is entered the second time, there is no check
  to determine if a QSAV has already been acquired, and a second
  QSAV will be chained between GSAV4 and QSAV1(of the 1st pass).
  
  PSTSKED7 (which is already on) will be turned on again and
  Term Thread will again be processed. At the end of Term Thread,
  PSTSKED7 is checked. Since it is on, the second QSAV will be
  released and PSTSKED7 is turned off. This leaves the first QSAV
  set chained between GSAV4 and GSAV5, with no indication that it
  is there (PSTSKED7 is now off).
  
  During Signoff processing for the dependent region, if the PST
  is to be released, the GSAV chain is removed from between
  PSTSAV19 and PSTSAV20. IMS storage management checks the
  GSAV forward and backward chaining and finds the stray QSAV.
  This occurs under the DFSSDAB0 ITASK in the IMS Control Region.
  ABENDU3058 RC01 occurs and brings IMS down.
  

Problem conclusion

• AIDS: RIDS/SYS RIDS/CNTRL SYS CNTRL
    DEP: NONE
    GEN:
  
  *** END IMS KEYWORDS ***
  Prior to obtaining a QSAV in Term Thread, a check is now made to
  determine if a QSAV has already been acquired by a previous
  iteration of Term Thread. PSTSKED7 indicates this situation, and
  if on, Term Thread will use the QSAV that already exists to
  complete its process.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

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

  PK06908

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

  UK05702

Modules/Macros

• DFSASK00
  

Fix information

• Fixed component name

  IMS V9

• Fixed component ID

  5655J3800

Applicable component levels

• R900 PSY UK05702

     UP05/08/03 P F508 «