II04712: ABENDC03 MSGIEC999I DEB ADDR = XXXXX REG15 = 00000004 APPLICATION DEBUG ASSISTANCE PROCEDURE

APAR status

• Closed as canceled.

Error description

• System C03 abends occur at task termination when a program opens
  a data set and DOESN'T CLOSE it before returning to the system.
  This can be verified with REG0 (REG 0) at the time of the CLOSE
  (SVC14) in the trace table.  If REG0 = E3C3F0C1, then the close
  was issued by IFG0TC0A and if there are no previous errors, the
  ERROR IS IN THE APPLICATION.
  ADDTIONAL SYMPTOMS:  ABEND0C4 IN IFG0T0CA+'C56'trying to verify
  if DCB for DEB that was still on debchain.  ABEND0C4 occurs
  because the storage where DCB resided had been freed prior to
  task terminating (regardless of ABTERM or normal termination).
  
  See also II02095 for additional information.
  *************************************************************
  NOTE:  OW00185 fixes problem where ABENDC03 is issued with NO
         IEC999I message
  *************************************************************
  .
  As part of task termination, RTM will free user subpool storage
  that was still allocated when the program terminated.  The DCB
  for the open data set can reside in that storage.  When the data
  management resource manager IFG0TC0A detects the open data set,
  it program checks when it attempts to access the DCB.
  IFG0TC0A returns to RTM with return code 4, who then issues
  the ABENDC03.
  -NOTE--
  RTM does nothing with datasets at all.  At task termination, RTM
  calls a DFP module, IFG0TC0A.  IFG0TC0A runs the DEB chain for a
  terminating task, closing each dataset as it comes to it.
  If any CLOSEs don't work, IFG0TC0A gives RTM back a bad return
  and RTM responds by issuing the abendC03.
  When the ENTIRE PAGE occupied by the DCB(or ACB) has been free'd
  CLOSE can't work and the abendC03 is inevitable.  If, however
  there is anything else still getmained on the same page as the
  DCB and the area the DCB is in hasn't been reused, the residual
  information on that page would be sufficient to close the
  dataset and the abendc03 does not get issued..
  In all events (even when the abendC03 is issued) the dataset is
  "cleaned up."  The difference is, when an abendC03 (and its
  corresponding msgIEC999I) is issued, you may not get the last
  buffer written to the dataset.  The dataset treatment itself is
  not inconsistent, but the environment in which this treatment
  is occurring may not be quite the same.
  ***************************************************************
  THE PURPOSE OF THIS APAR IS TO PROVIDE TRACES THAT CAN BE USED
  IDENTIFY THE APPLICATION THAT IS TERMINATING WITHOUT CLOSING
  ALL OF ITS OPEN DATA SETS AND TO IDENTIFY THE DATA SETS THAT
  HAVE BEEN LEFT OPEN.
  ***************************************************************
  

Local fix

• TO DEBUG AN ABENDC03:
  1). Find the program that is accessing the data set.
      The data set name will be in the IEC999I message.
  2). In this program, add WTOs after the opens (SVC 19,22) and
      the closes and verify that each DCB that gets opened also
      gets closed. (SVC 20)
  3). If you cannot find the program that is causing the failure,
      set the following slips to find the program, the DEB, and
      the DCB.
  A)  SLIP SET,SB,A=TRACE,TRDATA=(STD,REGS,2R%,+53,11R%,+3F),
      RANGE=XXXXXX,JOBNAME=JJJJ,ID=C03A,END
      where:
      XXXXXX = EPA of CSECT IFG0198N to be found in a LPAMAP.
               CSECT IFG0198N is in LMOD IGC0001I.
  
  B) Set a slip on the IEC999I message to get a dump.
     SLIP SET,IF,ACTION=SVCD,LPAMOD=(IGC0003E,0),JOBNAME=xxxxxxxx,
       DATA=(1R%+4,EQ,C9C5C3F9,1R%+8,EQ,F9F9C940),END
  
  
  
     Initialize GTF as follows:
     Start GTF with TRACE=SLIP,SVCP,JOBNAMEP
  
  Use trace event keywords SVC=(13,16,19,20,22,117),JOBNAME=JJJ,E
  For the DUMP dataset:  (IPCS)
  OPTION 4: VERBX MTRACE will give the IEC999I message
  Get the DEB address from the IEC999I message.
  
  For the TRACE dataset: (IPCS)
  OPTION 4: GTF SVC SLIP will initialize the trace
  
  There will be SLIP S+U records everytime IFG0198N is entered.
  This is the last module in OPEN processing, so we are assuming
  that this data set gets opened correctly.
  
  USR 0040 data will be the DEB in the associated slip USR record.
  USR 0054 data will be the DCB in the associated slip USR record.
  
  THE DCB + X'2D' points to a 3 byte DEB address.
  THE DEB + X'19' points to a 3 byte DCB address.
  THE DCB + X'28' for 2 bytes will point to the offset into TIOT
  
  Using the DEB address from the IEC999I message, issue find
  commands until the DEB address is found in the DCB + x'2D'
  (USR 0054).  Find the associated 3 byte DCB address in the
  DEB + x'19' (USR 0040).  Go to the top of the trace and issue
  a find command on the 3 byte DCB address until it appears in a
  PLIST of a SVC 19 or SVC 22.  The DCB will be the lower 3 bytes
  of the PLIST. The OPSW in this SVC entry will point to the
  APPLICATION that issued the open.
  ************************************************************
  **      The APPLICATION is in error and the owners        **
  **      should be contacted for problem resolution        **
  ************************************************************
  There will also be a MODN (module name) field in the SVC entry
  that may contain the module name that issued the open.  See if
  there is an SVC 20 with a PLIST (lower 3 bytes) that matches
  the DCB address.  If there is not an SVC 20 with a PLIST
  (lower 3 bytes = DCB address), then the dataset was not closed
  by the APPLICATION and before the TASK terminated, the DCB was
  either FREEMAINED or OVERLAYED.
  .
  The ABENDC03 usually occurs when task termination passes the
  TCBDEBs to task close for final clean-up.  If the DCBs are
  closed properly, then the DEBs are removed from the TCBDEB
  chain.
  .
  In order to maintain proper programming, it is recommended that
  all APPLICATIONS that open datasets, close them before task
  termination.  A good check is to put in WTOs before opens,
  SVC 19 or 22, and before the closes, SVC 20, to ensure that
  all datasets that get opened, get closed.
  

Problem summary

Problem conclusion

Temporary fix

Comments

• THIS IS AN INFORMATIONAL APAR.
  Following are some problems seen by L2:
  This ended up being a user error. A user is executing
  DB2 dsntiual in tso batch, the call is getting a sql -911
  resource timeout. The REXX code does not check return code back
  from sql call and temp data sets created earlier were not
  closed.  Symptoms: MSGIEC999I IEC999I IFG0TC0A MSGIEC161I
  IEC161I 056-084
  

APAR Information

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

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

Fix information

Applicable component levels