Re: RUNSQLSTM drop/create alias error

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.