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



In my production code I explicitly code the library qualifier for any object reference with two exceptions:

1. The object is MRI (that is, potentially translated into various languages) and will be used as part of the user interface

2. The object is selectable by the user (in which case the command interface provides the ability to specify the qualified object name -- including of course *LIBL, *CURLIB, etc)

Implicitly relying on the library list, to me anyway, opens up too many possible exposures -- and I'm a control freak when it comes to production level code :-)

Bruce

Jerry Adams <jerry@xxxxxxxxxxxxxxx> wrote:
I actually do both. That is, QTEMP is in the *USRLIBL, but, in my code
whenever I want to reference a table in QTEMP, I code QTEMP. I would
probably do the latter in any case, but it's doubly important here
because QTEMP is the last list entry. Personally, I think it should be
first, but that's the way it was set up when I started here so I live
with it.


* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx



Tom Liotta wrote:
James Lampert wrote:

I think I've seen at least one customer box that was set up in such a
way that QTEMP is not, by default, in the library list.

Not surprisingly, where I've seen (or suspected) this, it has been in
the context of problems this has caused.

Can anybody explain why (other than total ignorance of the nature of
QTEMP) anybody would set up a box to do this?


James:

AFAIK, the only technical reason to have QTEMP in a library list is
so that objects can be created by the job in QTEMP and later found
through unqualified references. (Or, of course, to meet shop
standards that say QTEMP must be in *LIBL or some similar
requirement whether it makes sense or not.)

I'd be interested in hearing other reasons for having QTEMP in *LIBL.

If a job creates QTEMP objects, then it's possible to wonder why the
objects would not be qualified when accessed. Jobs often are capable
of knowing what they've created.

Now, there are certainly many reasons to "override" to a QTEMP
object by way of unqualified reference when an object exists
elsewhere with the same name. If QTEMP is higher in *LIBL, an
unqualified reference will generally find the QTEMP version.

To me, the question comes down to what the expectations are for
unqualified references. Shop standards can make a difference.

Tom Liotta




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.