Re: How the SQL Server World Lives

Thanks Chuck; interesting stuff. Someday when I have a machine to play with...

On 1/31/2013 1:04 PM, CRPence wrote:

On 31 Jan 2013 11:44, Peter Dow wrote:

How can one determine what was actually damaged? It's been a long
time since I've seen a system with a damaged object, and all I can
recall is that it said it was damaged; there were no specifics.

Ignoring logical damage: The first time an object is damaged, a
message MCH16## is issued and a VLog with a major code of 03xx is
logged. With good retention settings, all damage for a long time can be
there for later review; recent messages indicate a STRWCH might be
possible to notify of damage from the VLogs rather than hoping whoever
first encountered damage will report the incident to someone. A message
CPF81## or CPF82## may be issued, at that moment to QHST and\or QSYSOPR,
and for later references to the object to the program making the
reference. But these CPF8... range of messages are for sure issued
during the "damage notification" portion of a RCLSTG. That damage
notification is to identify all permanent objects that should be deleted
and then optionally restored\recovered from a backup or re-created [from
source].

And assuming that some catastrophic disk failure damaged just the
*OIRS, what would DSPOBJD do when it tried to display the save
history for an undamaged object?

Whatever the LI (the OS Librarian) component deems appropriate :-/

I am sure the Display Object Description would not be happy about
encountering new or existing damage to the *OIRS, but I am not sure of
the effect; probably CPF2150 [or less likely CPF9809] preceded by some
unpleasant errors. There is a Reclaim Library (RCLLIB) CL command that
"rebuilds, where possible, internal objects of the library that were
damaged or destroyed." While that request could make the *LIB object
operational for a new DSPOBJD against that library, presumably every
object would have to have its OIR recovered; the most obvious being a
restore-over the existing objects from media. Thinking about that as
recovery, I have a feeling that Database Restore might actually require
instead that the currently object missing information be saved, a prior
media used to restore *NEW, and then do the restore-over using the more
recently saved media; i.e. I am not sure if DB Restore updates the OIR
for a *OLD restore... and I can not test because I have no access to the
restore feature.

The damage scenario could also be easily enough tested using STRSST
D/A/D to damage a *OIRS of a newly created library which has a simple
object like a *DTAARA; and to be complete, that object has been restored
and\or saved with UPDHST(*YES) to ensure that there is some
"Save\Restore information" to be seen before and after the damage.