RE: QTEMP cleanup

Don't stop using QTEMP. It think it's usage is invaluable. I write
commercial software and we use it all the time.

That said, I fully agree with Scott K.
I can tell you from experience that if you assume anything pertaining to the
system's environment, you'll inevitably be bitten in the ??? as some shop's
environment will differ. And since environmental types of issues are
usually discovered during evaluation phase, you're often out of a sale for
causing an "issue" with your software.
Assuming QTEMP is in the *LIBL is one of those environmental settings that I
have run into several times. There are more shops that don't have it in
their *USRLIBL than I ever imagined. There are a lot more that have it in
there, but obviously you can't write your software with that dependency.

To summarize, use QTEMP in commercial software but make sure you implicitly
qualify its usage.

Elvis

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


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

Rob, all good points and I think we are in agreement.

My main scenario of QTEMP is in the use of *USRSPC and *USRIDX objects to
have a single one per job/user. This keeps me from having to gen a unique
name for each object in a "global" library (like you were alluding to).
Though I am rethinking my approach with QTEMP *USRIDX usage, because with a
*USRIDX I really wouldn't need a QTEMP object. I could separate entries
within a single *USRIDX by qualifying the entries with the job number. That
would lessen the number of total *USRIDX objects and instead leave a single
big one on the system. I haven't ventured down that path much because QTEMP
has worked so good for me.

Thanks for your comments,
Aaron Bartell