Re: RUNSQLSTM drop/create alias error

[CRPence <CRPbottle@xxxxxxxxx>]

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