I haven't been following this thread entirely, but this statement caught my
eye given how direct it was. I have always thought of QTEMP being a great
way to have objects created that will never be shared across jobs (i.e. user
spaces, user indexes, etc), and necessary cleanup will happen when the job
ends.
I don't think I would call it poorly written software, but instead name it
"software written to the need and resources available". It can cut down on
the coding necessary to cleanup after ones self if they can stick objects in
QTEMP and allow the OS to clean it up. Is that approach so wrong?
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Sunday, January 13, 2008 4:31 PM
To: Midrange Systems Technical Discussion
Subject: Re: QTEMP not in library list
IMHO, it would be a very odd case where you'd want an application to
refer to QTEMP when it normally refers to a production library. In
fact, I'd wager it's a programmer trying to test code.
In that situation, the user (programmer) could easily use OVRDBF or add
QTEMP to the library list on the fly.
I don't think it's a good argument for having QTEMP in the QUSRLIBL
sysval or even in the JOBD.
Let's face it, folks... the only reason QTEMP needs to be in the library
list (aside from adding it on-the-fly for testing code) is because of
all the poorly written software out there. In this market space, poorly
written software absolutely ABOUNDS -- or, at least, that's been my
experience.
Crispin wrote:
In general, that's probably a good idea. But what if, for example, you
have
a (CL) program that does some processing on a file. The application may
want
to use that program for the QTEMP version of the file, or for an
Application
library version of the file.
midrange.com
