Re: Damaged QSYS2/SYSIXADV *FILE

On 17-Dec-2013 08:02 -0800, rob@xxxxxxxxx wrote:

And, like many people know, a RCLSTG only attempts to fix stuff
that's already been flagged as damaged.

:-( For physical damage [hard\full or soft\partial], the Reclaim Storage (RCLSTG) merely performs one of its primary functions called *Damage Notification* which should *not* be confused with any implication that the feature will have performed any action to "fix stuff"; irrespective of its previously-detected or as-yet undetected physically-damaged status.

The Reclaim can not /fix/ physical damage; the only recovery available for physical damage is to delete the damaged object. The Reclaim feature will however perform some cleanup activity for a specific type of /logical-damage/ conditions, such as conditions that arose from *partially-completed* operations for which a permanent progress-tracking object [i.e. a recovery object] exists to inform of the pending recovery. Any other type of logical damage is likely to pend some recovery actions specific to the logical condition for which the object is deemed /broken/ by the owning-component of that object-type+atribute; e.g. for the Database *FILE object, the owning component would be the OS Database (DB) component for which its /recovery object/ is the *DBRCVR type x19D4.

We ran a full RCLSTG immediately before the STRBKUBRM.
Fat lot of good that 7 hours and 47 minutes did us.
Twas the following save that flagged it.

Because the reclaim merely notifies of damage rather than /correcting/ damage, the history log spanning the reclaim request must be reviewed to determine what objects were previously known or since-detected to be damaged, during that reclaim processing. The save will implicitly omit those /notified-as-damaged/ external objects from the save; I do not recall what transpires for damaged database members as an internal object type *MEM as subcomponent of the external object type *FILE. However any objects remaining /logically damaged/ [for other than the partial\pending work, for which that work was nullified by a full reclaim] may, as was encountered, still present a problem for the save [or other supported operations against that object]. As well, any object that is physically damaged but for which that damage is not-yet detected, will cause the save processing to fail; i.e. previously detected damage is avoided by the save, but damage detected during the save [i.e. encountering previously undetected damage] is deemed an unrecoverable error for the save processing.

The save is more likely to catch additional problems with either physical or logical damage, than the reclaim, because the object and data need to be sufficiently navigable to make a copy of both on the media. The reclaim does not need to navigate data portions of objects nor perform some other operations against the object that the save might need to. For example the reclaim needs to know of each member by name and association with a parent-object to perform context and owner\aut recovery, but navigating the member-chain is not required. The logical validation of the member-chain could be added [though not a good fit in the design] as part of the reclaim, but of course at a [potentially large] cost in clock-time for the request... and if in a DCR, would best request the ability _optionally_ to do so. Similarly if asking the reclaim to process\verify the data segments.