Re: RUNSQLSTM drop/create alias error

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.