× 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.



Rob,

I'm not disagreeing as far as QTEMP is concerned. It was this that got me...

Implicitly relying on the library list, to me anyway, opens up too many

possible exposures -- and I'm a control freak when it comes to
production
level code :-)

That seemed to me to a general statement rather than a specific reference to the use of QTEMP. Perhaps I misunderstood Bruce's meaning there.

Crispin.


----- Original Message ----- From: <rob@xxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Friday, January 11, 2008 9:26 AM
Subject: Re: QTEMP not in library list


Two different scenarios entirely, Crispin.
We actually have multiple databases where we do rely upon the library
list. However, that doesn't preclude qualifying the references to QTEMP.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Crispin Bates" <cbates@xxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
01/11/2008 07:44 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: QTEMP not in library list






Bruce,

I'm intrigued by your stance here.

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.

In an environment where you have multiple copies of the same data
partitioned by library, how would you recommend the code be written? Set
up
the library list, and then for every object being accessed retrieve that
objects library? Surely that's going to have a huge performance hit on an
application, especially when you're talking about thousands of files.

I'd like to understand what would be recommended in this kind of
environment, and what can be done to reduce the many possible exposures
you
believe exist.

Thanks,

Crispin.


----- Original Message ----- From: "Bruce Vining" <bvining@xxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Friday, January 11, 2008 7:30 AM
Subject: Re: QTEMP not in library list


In my production code I explicitly code the library qualifier for any
object reference with two exceptions:

1. The object is MRI (that is, potentially translated into various
languages) and will be used as part of the user interface

2. The object is selectable by the user (in which case the command
interface provides the ability to specify the qualified object name -- including of course *LIBL, *CURLIB, etc)

Implicitly relying on the library list, to me anyway, opens up too many

possible exposures -- and I'm a control freak when it comes to
production
level code :-)

Bruce

Jerry Adams <jerry@xxxxxxxxxxxxxxx> wrote:
I actually do both. That is, QTEMP is in the *USRLIBL, but, in my code
whenever I want to reference a table in QTEMP, I code QTEMP. I would
probably do the latter in any case, but it's doubly important here
because QTEMP is the last list entry. Personally, I think it should be
first, but that's the way it was set up when I started here so I live
with it.


* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx



Tom Liotta wrote:
James Lampert wrote:

I think I've seen at least one customer box that was set up in such a
way that QTEMP is not, by default, in the library list.

Not surprisingly, where I've seen (or suspected) this, it has been in
the context of problems this has caused.

Can anybody explain why (other than total ignorance of the nature of
QTEMP) anybody would set up a box to do this?


James:

AFAIK, the only technical reason to have QTEMP in a library list is
so that objects can be created by the job in QTEMP and later found
through unqualified references. (Or, of course, to meet shop
standards that say QTEMP must be in *LIBL or some similar
requirement whether it makes sense or not.)

I'd be interested in hearing other reasons for having QTEMP in *LIBL.

If a job creates QTEMP objects, then it's possible to wonder why the
objects would not be qualified when accessed. Jobs often are capable
of knowing what they've created.

Now, there are certainly many reasons to "override" to a QTEMP
object by way of unqualified reference when an object exists
elsewhere with the same name. If QTEMP is higher in *LIBL, an
unqualified reference will generally find the QTEMP version.

To me, the question comes down to what the expectations are for
unqualified references. Shop standards can make a difference.

Tom Liotta



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




Bruce
Bruce Vining Services
507-206-4178
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.