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.
midrange.com
