I don't think this is correct. It would be an odd situation where other pgms (jobs) would access a QTEMP file. Not sure its even possible unless one were to try really hard to mess it up somehow.
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Monday, September 09, 2013 9:05 AM
To: Midrange Systems Technical Discussion
Subject: Re: separate DEV, TEST, & PROD environments survey
Let's say your application does something like copy your item master into
qtemp, but only certain rows (perhaps for some printing program, etc).
Then the program forgets/aborts/etc and doesn't trash the temporary file.
Now all your programs that reference your item master are now using the
One philosophy on QTEMP is "I use that for testing programs and may stick
them into qtemp and have that high on the library list.".
Another philosophy on QTEMP is "I use that for temporary sort files, etc
and I always qualify the QTEMP library name in that case instead of use
the library list so I put that on the bottom of the library list.".
Our vendor application uses the second philosophy.
If you just have to TEST something on production, you can put that into
some funky library and change your current library list.
As a general rule, I would start qualifying your QTEMP references as such.
You don't know when you may get a vendor package that insists it be at
the bottom. Or, if you're a vendor, you get a customer that has a
conflicting package that insists it be at the bottom.