Re: How the SQL Server World Lives

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.