At 01:00 p.m. 13/01/2007, Tom wrote:
Dave:
That's a reasonably good question that I'd be interested in hearing
someone answer.
The reason to have QTEMP in the library list in the first place is
so that unqualified references to objects could resolve to objects
in QTEMP. For QTEMP, this _should_ mean objects that have the same
names as production objects in later libraries when you want to
substitute a temporary version. If QTEMP is at the end of the list
and objects are all created by the job, why have QTEMP in the list
at all? Why not simply qualify the references to QTEMP in the first
place and avoid the *LIBL search?
There seems to be little reason for even having QTEMP in *LIBL if
it's at the bottom. Leave it out. If the purpose is to catch objects
that are known to be created in QTEMP, then don't use a library-list
search to find them -- explicitly qualify to QTEMP. With QTEMP at
the bottom, why is it in *LIBL at all? It doesn't have to be in
*LIBL in order to use it.
I can come up with reasons, but I'm not sure on how useful they'd be
in many production environments. If some people are actually
benefiting from the practice, I'd like to know how. Note that having
one library, such as a development library, ahead of QTEMP is not
the same as having QTEMP at the bottom unless those are the only two
libraries
Tom Liotta
Hi Tom
it seems to me that the rationale behind the existence of QTEMP is to
provide a scratchpad area for each job that runs in the system
without the inconvenience of having to create a temporary library
using some naming convention to avoid collisions between jobs. Sooner
or later jobs run by any meaningful system are going to require the
creation of temporary objects that are unique to that job and need to
exist for the duration of that job only. QTEMP handles these
requirements pretty well.
Whether at the bottom of the top of the library list - and I've seen
both standards in use over the years - I've heard a number of
arguments that QTEMP access should always be qualified, usually going
something along the lines that if the objects are created into a
specific library, then that library should also be specified in the
code. Given the different environments out there, you can't rely on
the job description having QTEMP in a certain relative place so this
seems a sensible precaution to adopt purely from a defensive coding
point of view. You also can't rely 100% on QTEMP staying at the same
relative position in the library list as things change over the years
- like fashions, sys admins come and go.
The only argument with any merit at all I have ever heard for putting
QTEMP at the bottom of the library list was that this made it more
difficult to accidentally access a copy or subset of a production
object and made it more obvious that a copy or override of an object
in QTEMP was being used by virtu of the hard coding. The example I
recall being cited at the time was of someone creating a spurious
copy of a payroll master file and this file being used instead of the
production one.
I'm not really convinced that this creates any more opportunity than
having QTEMP at the top of the library list (the person providing
this example was perversely anti peer code reviews and walkthroughs)
but as someone else said, having a standard and knowing the rules is
more important than the actual position of QTEMP in the library list.
Bad standard being better than no standards at all I guess. It is
fair to say that you can't secure an individual out of the QTEMP
allocated to their job and thus can't prevent them creating an copy
of any object or file they can read so I suppose there might be some
grain of truth to the theory that the "bottom is safer" as they would
have full rights to the copy of the object.
These days I tend to code anything that is being put on a customers
machine with a hard reference to QTEMP to avoid having to worry about
it. Kowing that QTEMP is available and will work to store my objects
is the most useful service it provides in my opinion,
Just another perspective anyway.
Regards
Evan Harris
