On 22-Mar-2012 09:05 , Victor Hunt wrote:
I ran the supplied DSPFD command and SQL script, it returned 16
The query returned just those with the mismatched TEXT field between
the output of the DSPFD and what is in QADBXREF? The given selection
allowed presentation of names in the list, for mismatches by other origins.
What I am trying to do is identify all of the files on the system
that have "Old name" as part of the file text. We are trying to
resolve the duplicate file issue on our system (as described in a
much earlier post).
Because the "Old name" issue is not limited to the database *FILE
objects, i.e. the *MEM database member object may also get renamed and
be reassigned with the "Old name" text. Thus the means to "identify"
what is in-error must drill-down to the members as well. To effect the
proper\corrected relations, any LF member must never be based-on a
renamed member; i.e. totally messes up expectations for CRTDUPOBJ and
RSTOBJ, even if the run-time that reference such a file.mbr might be
left unaware [and so appear to function normally].
Note also that the text prefix "Old name " is specific to the US
English installation; i.e. NLV2924 as primary language. The text comes
from the message CPX8105 in *NLVLIBL/QCPFMSG. When a restore is
performed with another language, e.g. German, the prefix may be
different such as "Alter Name ", and in other languages a similarly
constant portion of the text may even be embedded versus a prefix.
It appears that while the duplicate files are in the QADBXREF file,
none of them have any text associated with them, although they do
when using WRKF, DSPFD, etc.
The information in QADBXREF is refreshed by issuing the request to
RCLSTG SELECT(*DBXREF) while in restricted state. Even if that is
easily accomplished, I would use DSPFD output instead of the QADBXREF
There are other ways to get the information I want, I just thought
it odd the there was no text in the QADBXREF file.
A mismatch between the OIR and QADBXREF would not be the expected
outcome from the restore. If a file with TEXT() that has been renamed
due to CPI320A does not have the updated "Old name" text reflected in
the system database cross-reference, then that effect would be a defect.
Similarly for a member, per CPI320B; although because the member-level
details in the DBXREF are gathered dynamically at run\inquiry-time
versus maintained, that should not [be able to] be an issue by the same
Hmmm. Would be interesting to have a DMPOBJ of such a file, just to
see if the value in the OIR matches the value in the DBfile.
Perhaps this is due to the these files being duplicates as well as
system files, perhaps not.
Whether they are "system files" is irrelevant.