Re: Damaged QSYS2/SYSIXADV *FILE

On 17-Dec-2013 06:58 -0800, Jim Oberholtzer wrote:

Rob on 12/17/2013 09:02 AM wrote:

<<SNIP>> Had a drastic power failure Friday. <<SNIP>>

<<SNIP>> Looks like a RCLSTG *DBXREF is in your near future <<SNIP>>

While that may be an action one might take proactively in response to the /power failure/, or in response to a CPF32A1 logged in the history as a side effect of that power outage, [for the archives:] a reader should be aware that...

That reclaim _does *not* correct damage_ to database files; not even to the QADB* files in QSYS which would automatically be deleted and re-created by the *DBXREF feature [per messages CPF32D#]. Even a full Reclaim Storage request does not /correct/ damage, merely *notify* of the existence of previously existing or detected damage. The only valid recovery for a damaged object is to *delete* the damaged object; optionally having performed data-recovery actions.

The file named in the subject is not controlled nor its data maintained by the *DBXREF feature, so the request to reclaim the *DBXREF [or even a full reclaim] can not recover lost-data from having effected the /recovery/ from the damage; i.e. from having done: DROP QSYS2/SYSIXADV CASCADE

And *if* the reclaim request might magically recover the /object/ by that name, it is only an incidental side-effect from the feature having called the SQL catalog-creation routine(s)... and that they happen to process more than just the catalog VIEWs with based-on files of QADB* in QSYS.