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



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


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.