Re: QADBXREF File Question

On 22-Mar-2012 09:05 , Victor Hunt wrote:

I ran the supplied DSPFD command and SQL script, it returned 16
rows.

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 anyway.

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 [mis]tracking origin.

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.

Regards, Chuck