Re: RUNSQLSTM drop/create alias error

["Frances Denoncourt" <Frances.Denoncourt@xxxxxxxxxxxxxx>]

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