RE: IBM Cross Reference Files

["Jerry C. Adams" <midrange@xxxxxxxx>]

Chuck,

Could you elaborate what is meant by "jobs QDBSRVXR and QDBSRVXR2 must be
functional for a RCLSTG [that 
includes the *DBXREF] to be successful"?  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.

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

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                                  
    - Record Claim           : X'40404040404040404040404040404040' 
    - Request Claim          : X'00000000000000000000000000000000' 
    - Second Context         : *N 
    - Second Name            : *N 
    - Alternate Name         : *N 
    - Second Alternate Name  : *N 
    - Trigger Def Library    : *N 
    - Trigger Def Name       : *N



Jerry C. Adams
IBM i Programmer/Analyst
Is that the best game you ever pitched? -Reporter to Don Larsen after
pitching the only perfect game in World Series history.
--
A&K Wholesale
Murfreesboro, TN
615-867-5070


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, February 14, 2011 10:31 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: IBM Cross Reference Files

On 2/14/11 6:44 AM, Ketzes, Larry wrote:
> Anyone have any experience with having damaged IBM cross reference
> files that a reclaim storage did NOT correct?

   The system database cross-reference feature implemented as system 
jobs QDBSRVXR and QDBSRVXR2 must be functional for a RCLSTG [that 
includes the *DBXREF] to be successful.  Also pending database 
operations that can not be completed without an IPL will not be 
completed with RCLSTG SELECT(*DBXREF), but would be dismissed [if not 
actually corrected] by RCLSTG SELECT(*ALL).

   Thus any *functional* errors with the database XREF need to corrected 
prior to attempting to correct any data [often referred to as "damage"] 
errors.  Otherwise a RCLSTG request which includes the *DBXREF will 
simply enqueue a bunch of work pending correction of the functional 
issue; on some releases and\or systems, the queue may fill and "hang" 
the request because the job filling the queue must wait until the queue 
is no longer full... thus a "catch 22" situation.

Regards, Chuck