Re: QTEMP not in library list

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