Re: RUNSQLSTM drop/create alias error

Thanks for putting so much time in on this. I tried the other field. No 'CL'.
Went to the link and forwarded to my ops person. I think she is going to want me to get on the phone with IBM. According to everyone, we pay for top of the line support and should use it.

Looked at the circumvention text, too. Tried that, too.
Thanks again,

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 3:33 PM >>>

Searched: sql alias rollback cover letter iseries -cumulative site:ibm.com

Then at http://www-912.ibm.com/ImprovedSearch/searchoptions.jsp
searching for APAR SE20037 gives:
http://www-912.ibm.com/n_dir/nas4apar.nsf/c79815e083182fec862564c00079d117/4f444b5b6ce8f97a86256fee003c7f1a?OpenDocument&Highlight=2,SE20037
http://www-1.ibm.com/support/docview.wss?uid=nas3e1bc20f22b57bf8d8625702900479b00

See the "circumvention" text. I might have gotten the field name
wrong; i.e. perhaps not DBXATR, but instead DBXTYP ?

Regards, Chuck

Frances Denoncourt wrote:

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