× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Yep, have run into the same thing. Only way to fix was to restore the
library from a backup. Big problem with referential integrity. Cross
reference tables always getting hosed.

On Mon, Feb 14, 2011 at 10:28 AM, Jerry C. Adams <midrange@xxxxxxxx> wrote:

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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.