Re: RUNSQLSTM drop/create alias error

Still not sure what release is being used. Regardless, there was at some point a defect whereby a ROLLBACK of a CREATE ALIAS left a 'CL' [claim] entry in the *DBXREF data, which presumably would cause exactly the illogical result that was described. Thus although the RUNSQLSTM COMMIT(*CHG) may have effected ROLLBACK, the actions may have been incomplete [leaving that ALIAS /name/ _claimed_ by that request] such that future requests outside of that commit definition or unit of work would have seen the ALIAS as existing. The condition can be verified by finding a condition of the file\alias name WHERE DBXATR='CL' in the QADBXREF data; of course it is now apparently resolved.

Regards, Chuck

Frances Denoncourt wrote:

Now, I'm trying to figure out what could have caused everything to haywire. I did attempt to run the RUNSQLSTM and forgot to use the go "*NONE" parameter which apparently defaults to *CHG. I didn't set ERRLVL. Could that have done something?

"A commitment-control level is specified on the RUNSQLSTM command. If a commitment-control level other than *NONE is specified, the SQL
statements are run under commitment control. If all of the statements
successfully execute, a COMMIT is done at the completion of the SQL statement processor. Otherwise, a ROLLBACK is done. A statement is
considered successful if its return code severity is less than or
equal to the value specified on the ERRLVL parameter of the RUNSQLSTM
command."

"Frances Denoncourt" wrote:
I just tried your QMQRY suggestion. Wow. Works. <<SNIP>>