×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Crispin Bates wrote:
Implicit reliance on the library list is a base part of the machine
architecture. If you're saying everything should be qualified, then why have
a library list at all. Just qualify every reference and have no library
list.
Bruce covered it all well enough, and Chuck's comments were (as
always) well worth it.
I just want to add that the topic was about QTEMP and its position
in the library list specifically. The more general question about
"the library list itself" goes a long way beyond "QTEMP in *LIBL".
So, here's a scenario:
I write some function that creates a file named ABC in QTEMP and I
access it via *LIBL rather than by qualifying to QTEMP. Generally,
it doesn't matter if QTEMP is first, last or in the middle because
ABC _only_ exists in QTEMP.
Tomorrow, developer X creates production file ABC in library PAYROLL.
When my function runs the day after tomorrow, it better hope that
PAYROLL isn't in *LIBL ahead of QTEMP. I should've known better than
to create and use a 'temporary' object and not know where it was
supposed to be. For that 'temporary' object, there was no reason not
to grab the correct one explicitly.
And that begins to lead to the question -- Why have QTEMP in the
last part of *LIBL rather than the first? What good does it do that
outweighs the risk when unqualified accesses can accidentally get an
unintended object?
Keep in mind that having QTEMP in *LIBL has no bearing on whether or
not QTEMP exists nor on whether or not objects within it can be
accessed. AFAIK, the only reason to have it in *LIBL is
_unqualified_ references. And in those cases, isn't it prudent to
have it higher in the list?
If not, why not?
Tom Liotta
midrange.com
