|
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 Tomit 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. RegardsEvan Harris
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
