Re: RCLSTG

On 2/22/11 5:03 AM, Ketzes, Larry wrote:

Interesting. I have a system where there were damaged IBM cross
reference files. We ran a 'full RCLSTG' over the weekend, and I still
have damaged IBM cross reference files. I've never before had those
after the RCLSTG, but I usually only run the RCLSTG *DBXREF. I think
I'll try only that one and see what happens.

FWiW the RCLSTG has as one of its primary functions, "damage notification" but has no specific function of "damage fix". While some forms of "logical damage" [i.e. inconsistencies, with "logical" having nothing specifically to do with logical files] might be corrected by performing reclaim storage, the only recovery for physical damage is to delete the damaged object [to optionally have recovered some of the data first, if the data-portion of the object is "damaged"] and the recreate the object; the reclaim request will notify of the damage to QSYSOPR by a message CPF81## or CPF82##.

If a system database cross-reference file is "damaged", the OS should correct that automatically without any user intervention; i.e. the owning QDBSRVXR job should DLTF and re-create the file. Attempting to correct actual damage of the *DBXREF files by requesting to perform any of the reclaim requests [which include the *DBXREF] is a risky bet; the *DBXREF needs to be functional in order that the work enqueued to the *DBXREF can be processed, and a reclaim of the *DBXREF asks to enqueue the work of effectively every piece of database x-ref tracking on the system.

However most of the above is likely moot for the described, because the noted "damage" is likely not damage at all. Instead the issue is likely to have been just "error(s)" with the data of the *DBXREF. A full RCLSTG would generally not be required to correct just the data for the *DBXREF, and thus why there is RCLSTG SELECT(*DBXREF) to perform just the data-refresh of the *DBXREF for when the data has been reported as out-of-sync, or "in error". Such data errors alone are not "damage", irrespective of any use of the term in any messages. Please note however that for some releases there was an effective API in the form of a utility [*PGM QDBXRCTX], that IIRC was superseded by the CL command RCLDBXREF which allows identifying the library name(s) as source of data inconsistencies along with the capability to "reclaim" [i.e. refresh] the data only for that library as a possible means of correct.

Almost all cases of data inconsistencies arise from defects in either database recovery processing, normal but not-so-robust DDM device file processing, or errors in how the *DBXREF processes the work or data. Otherwise errors might arise from patches or other similar effects from terminations or failure scenarios; e.g. a database file becoming addressable [but not created] as part of a reclaim which omitted the *DBXREF would not be recorded in the *DBXREF but appear as an object in QRCL, so when the DLTF QRCL/TheFile transpired, the condition would be recognized and thus reported as a data inconsistency, but easily diagnosed as affecting only QRCL and easily correcting just the data from that library. Thus if there are actual data errors being reported [versus just inference from misreading messages from QHST], there is likely a defect that needs to be circumvented or for which a preventive fix should exist.

Regards, Chuck