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
midrange.com
