II06856: OBJECTS NOT DELETED DURING OSMC - DIAGNOSTIC AID

APAR status

• Closed as canceled.

Error description

• SO, YOUR OBJECTS DON'T DELETE DURING OSMC!
  -
  If objects are not deleted during OSMC, one of two things has
  probably happened.
   1. The auto-delete installation-wide exit (CBRHADUX) is being
      invoked and fails with a return code not equal to 0 or 8.
  2. The object is not being selected for expiration processing
  by OSMC.
  -
  Diagnosis of this problem begins with an examination of the
  system console log from the time OSMC started processing the
  storage group containing the object until OSMC processing
  completed for the storage group. Look for any CBRxxxx messages
  that may indicate a problem. The CBRxxxxx messages are
  documented in MVS/ESA Message Library: System Messages.
  -
  Checking CBRHADUX
  -
  If you have not successfully deleted objects during OSMC in the
  past, or you have just moved to a new release of OAM, then
  examination of CBRHADUX is a good place to start.
   In order to allow objects to be deleted during OSMC you must:
   - Modify CBRHADUX to allow deletes
   - Refresh linklib
   - Stop and start OAM so that new copy of CBRHADUX is available
     to OAM
  In DFP 3.3.0 and later, CBRHADUX must be modified to allow
  deletes.
    CBRHADUX will fail with a return code 12 if the exit
  cannot dynamically allocate the groupX.OBJECT.DELETE.NOTIFY
  dataset. Check the syslog for CBR, IGD or IEF messages following
  the start of OSMC processing for the storage group.
  For additional information on modifying CBRHADUX, refer to
  "Modify the Installation Exit to Handle Deleted Objects" in
  the MVS/DFP Customization manual.
  -
   OBJECT NOT SELECTED FOR EXPIRATION PROCESSING BY OSMC
  -
  To begin the investigation of why OSMC did not select the
  object, examine the object directory table
  (GROUPxx.OSM_OBJ_DIR). The following SQL command will retreive
  the object's directory table entry:
     SELECT * FROM GROUPxx.OSM_OBJ_DIR
  WHERE ODNAME = 'object_name';
  -
  Verify that the pending action date (ODPENDDT) is today's date
  or earlier.
  -
  Verify that the object has expired. If the expiration date
  (ODEXPDT) in the object directory table is less than or equal to
  today's date, then the object should expire. If the expiration
  date is the special value 9999-12-31, the object will never
  expire. If the expiration date is 0001-01-01, OAM will use the
  management class attributes to determine the expiration date.
  -
  First, determine the management class name of the object. You
  can use the following SQL statement:
  SELECT * FROM OAMADMIN.CBR_MGT_CLASS_TBL M, GROUPxx.OSM_OBJ_DIR
  WHERE   ODNAME = 'object_name'
  AND     D.ODMCNUM = M.ODMCNUM;
  -
  List the ISMF definition of the management class. Be sure to
  specify 'ACTIVE' as the SCDS name. Examine the expiration
  attributes. If both EXPIRE AFTER DAYS NON-USAGE and EXPIRE AFTER
  DATE/DAYS are NOLIMIT, the object will never expire. The value
  of EXPIRE AFTER DAYS NON-USAGE will be added to the last
  referenced date (ODLREFDT) in the object directory table to
  calculate the expiration date. If the last referenced date has
  not been set, the creation date will be used. If the value of
  EXPIRE AFTER DATE/DAYS is an explicit date, that date will be
  used as the expiration date. If the value is a number of days,
  the expiration date will be calculated based on the number of
  days added to the creation date (ODCREATS) in the object
  directory table.
  -
  For additional information on expiration attribute processing,
  see "Defining Management Class Expiration Attributes" in the DFP
  Storage Administration Reference.
  -
  Another common cause of an object not being selected by OSMC is
  the collection entry is not found in collection table
  (OAMADMIN.OBJ_COLLECTION_TBL) for the collection id (ODCLID) in
  the object directory table for the storage group being
  processed.
  -
  You can verify that the collection table entry exists for the
  object with the following SQL statement:
  SELECT * FROM OAMADMIN.CBR_COLLECTION_TBL C, GROUPxx.OSM_OBJ_DIR
  WHERE   ODNAME = 'object_name'
  AND     D.ODCLID = C.ODCLID;
  -
  One row should be returned identifying the collection that you
  expect to be associated with the object.
  -
  Another possibility is that there is a mismatch between the
  collection id in the catalog and the collection id in the
  collection table. OAM checks for this condition when the OAM
  address space is started. Check you syslog during OAM address
  space initialization for message CBR9030I, or any other messages
  that might indicate a problem with the catalog.
  -
  The following TSO command will list the collection entry in the
  catalog:
  LISTCAT ENTRIES('collection_name') ALL
  -
  Verify that the DIRECTORYTOKEN matches the storage group name
  for qualifier GROUPxx on the ISMF storage group definition
  panel. Be sure to use 'ACTIVE' as the SCDS name when listing
  storage group information. The storage group name must also
  match storage group name (ODCLSGNM) in the collection table.
  -
  GATHER DOCUMENTATION FOR LEVEL 2
  -
  If you have not identified the reason for objects not being
  deleted during OSMC, you may wish to contact the IBM support
  center. Please have the following documentation available:
  1. Print the contents of the
       OAMADMIN.CBR_MGT_CLASS_TBL
       OAMADMIN.CBR_STO_CLASS_TBL
       OAMADMIN.CBR_COLLECTION_TBL
  2. Print the contents of the an object directory table entry for
     one of the objects that you expected to be deleted.
  3. Do LISTCAT ENTRIES('collection_name') ALL for the collection
     associated with the object directory table entry printed in
     step 2.
  4. Include a screen print of the Storage Class and Management
     Class definitions using 'ACTIVE' as the SCDS name.
  5. Management class and Storage class ACS routines.
  6. Please include the syslog from the time OSMC message
      CBR9200I is issued to indicate the start of processing for
      the storage group until message CBR9201I is issued
      indicating processing has completed.
  7. The modified version of CBRHADUX.
  Additional keywords: 566528481 5695df180
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• Additional info for compid 566528481       RPA93/04/09
  

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