Re: How to find damaged objects

On 23-May-2011 20:35 , ankush agrawal wrote:

Do we have any other way of checking the list of all the objects
that are damaged apart from checking the full system save logs.

Not sure to what "full system save logs" refers, but if joblog, then note that there is OUTFILE support for SAVxxx which should record which objects were omitted for what error(s).

One of the primary functions of Reclaim Storage [RCLSTG SELECT(*ALL) OMIT(*DBXREF)] is called "Damage Notification". While processing every entry in the permanent storage directory, every permanent object will be reviewed and if the object or data portion is damaged, a message will be sent to QSYSOPR. All messages sent to QSYSOPR are recorded in the history log. At least the messages in DSPLOG QHST MSGID(CPF82100 CPF8200) for the PERIOD(()) spanning from before the start of the reclaim until the request finished should record all objects that were found to be damaged; depending on the circumstances, the objects may already have been deleted by the reclaim processing.

The Retrieve Disk Information utility [RTVDSKINF] performs effectively the same initial processing of the RCLSTG, at least in that the entire permanent storage directory is processed. I do not recall if that also signals the damage messages, but I think that might also.

However even that processing may not help prevent failures during save processing due to damage. Save will omit objects already detected as damaged, but any object detected as damaged during the save processing will terminate the save in order to protect the integrity of the backup image to be stored on the media. Actions that the save will perform [methods invoked on the objects and data] may be more thorough than what is required for the reclaim instruction and the performing of aggregate for storage of objects and data, thus some incidents of damage could remain and still only be detected by save or some other actions against the object\data for which damage has not yet been detected.

For objects in the /QSYS.LIB file-system the request to DSPOBJD directed to an output file records a value '1' in column ODOBDM for an object which is either previously or marked damaged when processing. As with RTVDSKINF, a minimal amount of actions are performed against the objects for which damage would be detected, so that command is most beneficial in detecting which objects the save request would omit.

The only recovery for "damage" is to delete the object, optionally first to have recovered data; a database file member is an "object", as is the dataspace [the object that holds the data] of each member. Restore over or copy\duplicate of objects that are damaged is an improper attempt to recover from damage; the damaged object must first be _successfully_ deleted.

Regards, Chuck