Re: How to find damaged objects

Thanks Chuck.

Few days back, we faced the damaged objects issue on one of our server. At
that time, IBM support advised to take the full system save to determine the
damaged object and we did that. We made a note of all the damaged object
reported during the save and after correcting them , ran the save again till
we get the clean save.

I have also created an outfile for all the objects on the system and ran a
sql query for ODOBDM paramter <> '0'




On Mon, May 23, 2011 at 10:17 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.