Re: RUNSQLSTM drop/create alias error

All of the File Attributes for these are AL. There are no 'CL' in the
file.
From a query
File Name LIbrary Owner Changed alias mbr
IMPACT TRSFDD APP 2008-05-08-16.17.26.727000 *FIRST IMPACTB TRSFDD APP 2008-05-08-16.41.05.627000 *FIRST
MASSFIX TRSFDD APP 2008-05-08-14.40.34.582000 *FIRST MASSFIXU TRSFDD APP 2008-05-08-14.50.13.158000 *FIRST TRIMPCPA TRSFDD APP 2008-05-08-15.33.31.389000 *FIRS

CRPence wrote:

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