RE: QTEMP cleanup

["Elvis Budimlic" <ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx>]

My comments only pertained to usage of QTEMP in the commercial product.  I
don't see why we shouldn't explicitly qualify temporary objects with QTEMP.

As for non-QTEMP libraries... I don't know what the "perfect" answer is.
There probably isn't one single answer for all situations. 

If software is running in its own job or other type of controlled
environment, we definitely take advantage of the *LIBL.  It's very nice and
very useful.

But in situations where we run inside end-user job (i.e. exit point programs
and like) or can conflict with other 3rd party software, we've used all the
"tricks" in the book - production libraries for command invoked calls,
save/restore library list, unique naming convention and as a last resort
hardcoding library name when we had to be absolutely sure.

I don't think there is a single "right" answer.  It depends on situation,
performance requirements, severity of the potential "issue" etc.

Elvis

Celebrating 10-Years of SQL Performance Excellence on IBM i5/OS and OS/400
www.centerfieldtechnology.com
 

-----Original Message-----
Subject: RE: QTEMP cleanup

So do you hardcode every object reference?  Because if you don't, how can
you assume that the user will have your non-QTEMP libraries in their library
list?  I think the concern that you have absolutely no control over the
library list is perhaps a little overstated.

I suppose the use of QTEMP specifically could be a problem if two of your
packages somehow conflict, with one needing QTEMP at the end of the library
list and one needing it at the beginning.  However, there's no good reason
to require a library be at the END of the library list.  If its object names
conflict with other objects in the library list, then the objects wouldn't
be found anyway unless you were hardcoding the library name, at which point
you wouldn't need the library in your library list at all!  And if they
don't conflict, it doesn't matter where the library is in the library list.

Finally, if none of these points sway you and you insist that you must write
your software so that it can be installed in environments where the library
list cannot be pre-determined, then the obvious answer is to save the
current library list, change to what you need, and then restore the original
when you're done.  I've done that a lot in my time.

Joe