Re: IBM Cross Reference Files

On 2/14/11 9:28 AM, Jerry C. Adams wrote:

Could you elaborate what is meant by "jobs QDBSRVXR and QDBSRVXR2
must be functional for a RCLSTG [that includes the *DBXREF] to be
successful"?

If [either of] those jobs are issuing an effective "Help me! I am broken!" message [or hung, e.g. in a perpetual RUN status stuck in the LIC], then they are not "functional" and thus would be unable to refresh the data in their database files QADB* in QSYS; i.e. RCLSTG which includes the *DBXREF is a request "to refresh" the data in [most of] the system database cross-reference files.

I put our system into a restricted state (using the CHGIPLA option
followed by a PWRDWNSYS) and, when I ran RCLSTG SELECT(*DBXREF), I
recall that I still had to end 1-n additional subsystems (can't
recall what at this point) before it would allow the command to
execute.

AFaIK if correctly started in restricted state by the IPL attributes, the same as ENDSYS or ENDSBS *ALL, there should be no requirement to end anything else [except maybe a group job or alternate signon at the console] since success in each case implies QCTLSBSD in in END status and no other subsystems are active; only system jobs would remain, with the ENDing subsystem monitor job of the controlling subsystem.

Using WRKACTJOB I found the QDBSRVXR and QDBSRVXR2 jobs running on
our system.

The term "running" must be defined more specifically *if* the term "functional" is of interest. From the "data error" quoted below, I will infer that running and functional can be assumed. Note: IIRC before v5r4 job status DEQW was "normal" and since [on newer releases] the status CNDW is "normal" for both of those DBXREF system jobs.?

A sample of the messages I see (DSPMSG QSYSOPR) is:

Message ID . . . . . . : CPF32A6
Date sent . . . . . . : 02/14/11
Time sent . . . . . . : 11:06:42
Message . . . . : Cross-reference problem type 1
notification 6008 for request 1.
Cause . . . . . : A problem was detected while processing the
system cross-reference files. The problem type is 1.
The problem types and their meanings follow:
1 -- Inconsistent data was discovered in the cross-reference
files for library QS36F. The system may not allow operations
to objects in library QS36F. The SQL catalogs may not be up
to date. The system may not allow constraints to be added or
removed. The system may not allow triggers to be added or
removed.
2 -- An unexpected condition was encountered
Recovery . . . : If the problem type is 1, request a reclaim
storage (RCLSTG command specifying SELECT(*ALL)
or SELECT(*DBXREF) )
Technical description . . . . . . . . : Additional information:
- Problem Type : 1
- Failing Context : QS36F
- Object Context : QS36F
- Object Name : D.APPR01
- Cross-reference Context: QSYS
- Cross-reference File : QADBXREF
- Request : 1
- Instance : 6008
- Record Attribute : PF
<<SNIP>>

The above is a "data error" rather than a "functional error" issued by the DBXREF. Symptom string: msgCPF32A6 rqstyp1 rc1 ot1 ntfy6008 f/qdbsrvxr

Since that is v5r1, a circumvention is probably had by turning off "file caching" feature by CHGS36. There is likely also a preventive PTF for the error which is [I believe] described by effectively "A process requested to BLDFILE D.APPR01 but a file by that name already exists for that library according to the existence of that row WHERE DBXLIB='QS36F' AND DBXFIL='D.APPR01' FROM QSYS/QADBXREF"

Also verify by DSPFD QSYS/QADBXLFI *ACCPTH that the key is correctly maintained as UNIQUE.

FWiW all data errors can be ignored until such time that they cause a functional error in a user job; e.g. inability to delete an IDDU file definition.

There may be a utility program, effective API, similar to the function of RCLDBXREF *CHECK on later releases; QDBXRCTX for which a web search may find parameters and outputs, or so I implied in an old message:
http://archive.midrange.com/midrange-l/200805/msg00540.html

Regards, Chuck