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



I called IBM Friday. Tracy had me GO LICPGM/option #5 [prepare for
install]. Didn't know where this was taking me, but sure enough, got
this message:
*Database cross-reference files are in error*

Tracy said that this is much quicker when diagnosing that particular
error. She said the RCLSTG dbxref should only take 20 minutes to one
hour.

Operations ran the RCLSTG over the weekend along with the latest PTFs.

I tested the RUNSQLSTM this morning and we are back in business.
Thanks for all of your help.



Fran Denoncourt
Sr. Programmer/Analyst
Pinal County Treasurer's Office
Florence, AZ 85232
(520) 866-6404

Receipt of this message does not grant you permission to send me
Unsolicited Commercial Email


"Frances Denoncourt" <Frances.Denoncourt@xxxxxxxxxxxxxx> 05/13/2008
3:32 PM >>>
Chuck,
Thanks - I think. I've forwarded this to the ops person who says she
has done a few RCLSTG. She plans it for the weekend.
Now, I don't know what to do.

Fran Denoncourt
Sr. Programmer/Analyst
Pinal County Treasurer's Office
Florence, AZ 85232
(520) 866-6404

Receipt of this message does not grant you permission to send me
Unsolicited Commercial Email


CRPence <CRPbottle@xxxxxxxxx> 05/13/2008 10:46 AM >>>
If the CREATE worked, then the error condition was already resolved.

Thus there would be no cause to refresh the *DBXREF data for that
already resolved issue. If the status of the database cross-reference

were already diagnosed as being _in error_ [not /damaged/], then using

QMQRY versus RUNSQLSTM would not have bypassed the problem. Note: The

additional invocations I mentioned before, to assist with diagnostics
and/or resolution of data errors with the *DBXREF, do not require
restricted state; search tokens: QDBXRCTX RCLDBXREF.

The RCLSTG SELECT(*DBXREF) could be [but I personally do not
recommend it] activated in the /run in restricted/ API; sorry, I do not

recall the API name. Instead the request could be invoked at the
console and left unattended after which the controlling subsystem would

be [re]started. However the reclaim of the *DBXREF is easily inserted

on either end of a full system save, so could be done by whomever does

the saves.

FWiW: The term 'damaged' is IMO a poor choice to describe a
condition
whereby a row\object relationship may not be in-sync. And to be sure
that if there was some 'damage' for the database cross-reference files,

then requesting to perform a RCLSTG SELECT(*DBXREF) might be the
*worst*
action possible. That is because in order for the data to be
refreshed,
the *DBXREF system jobs must already be functional which may not be the

case if there is /damage/.

Regards, Chuck

Frances Denoncourt wrote:
Elvis,
Is this something our operations staff would do?

We don't really have one. We have a supervisor at the help desk who
is the only one who does anything like this. The staff is made up
of PC people who do our backups for us and let us know if there
are hung messages. That's about it. AFAIK IBM handles the upgrades
and anything else like that.

If RCLSTG done in a restricted state, even if I got permission and
had authority, we are strictly 8-5 here. We kick out the public (and
ourselves) at 5:00 PM, arm the alarms and dash out. This is a
requirement of the Treasurer's office. No one can come in alone.
I cannot access the machine from home.

And, from what I saw, it takes hours to run. Don't know if we ever
have.

I'll shoot an email to that one person - out on flex I think.

"Elvis Budimlic" wrote:
Fran, I think it's time for RCLSTG SELECT(*DBXREF).
Your cross reference files must be damaged. I don't what else could

explain this behavior.

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.