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

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:19 AM >>>

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