At 01:00 p.m. 13/01/2007, Tom wrote:


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

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.

Evan Harris

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page