× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.