Re: QTEMP not in library list

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