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



Bruce,

Using the library list for execution flow might be handy for development purposes, but opens up too many exposures (in my mind anyway) for production code.

What are these exposures, and what should I do to remove them?

Ok, I can see that someone could put something higher in the library list and override your processing. But...

I have to support multiple versions of the application, through a central bootstrap process (oversimplification of what is happening, but I digress) that builds the library list. With this processing I can run the same job through multiple releases of our code, and make sure that the results are the same. I have to rely on the library list to be able to get at the correct version of tables, data areas, etc. etc. Are you saying I should be qualifiying the references in my code, and if so, how should I do that so that my bootstrap process can access whichever version of the data it is currently running for (I may run the same process, with the same source data - EDI documents for example) through several releases of the application. Should I be retrieving the library where the objects should exist (I have to support PTF's as well, which introduce more libraries to the library list, and would be different for each release). And if that's the case, then what difference is it to using the library list?, because that's how I find out where the object is anyway.

I can understand this for Operating system code, where there is only one version of the operating system on a machine (well, depending on which side you IPL), but for an application that supports multiple release, PTF processing, multiple languages, multiple databases, I just can't see hard coding the library reference as useful. In fact, I see it as incredibly restrictive. It would mean I would need to change the code from my development machine, prior to a production install, because the libraries are not named the same. I have many different environments on the development machine, I have US production at one release, I have European Production at another release, I have to have both environments on my development machine, up and running so that I can test PTF's for both environments separately. I don't want to have to change the Production library names for every release, so the production libraries on the US machines are the same as the production release in Europe. But that's not the case on my development machine.

I could go into even more detail, but It seems to me that hard coded libraries are just too restrictive.

Maybe I'm missing the point. Perhaps you only mean in reference to QTEMP, but that isn't the impression I'm getting. If that is the case, then forgive my diatribe :-)

Crispin.


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


With the exception of exit points (which I tend to provide lots of in my code) I never use the library list for program calls. I also tend to library qualify my command usage, the main exception being commands if I'm prompting. Using the library list for execution flow might be handy for development purposes, but opens up too many exposures (in my mind anyway) for production code.

To an extent, this view may be a carry over from IBM development -- where library qualification is considered a key part of maintaining integrity and security. And certainly if your code is for in house use, as opposed to being marketed to others, one can relax a bit in terms of library qualification. But in general I don't want someone inserting their code into my execution stream unless it's done by way of a formal exit (where I can add additional checks on what comes back).

Bruce

Jerry Adams <jerry@xxxxxxxxxxxxxxx> wrote:
There are some places where one cannot qualify the library, such as the
36EE (although it does have the FLIB command). In a test environment
(single LPAR, multiple libraries - test/production) using the library
list is pretty much a "must have" for many situations. But I can still
do explicit overrides because I know if I am running in a test -vs-
production mode. But the programs (CALL's) I usually leave to the
library list. Only the tables, data areas, etc., get qualified.
Naturally, there are always exceptions to the rule .-)

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



Jeff Crosby wrote:
Crispin,

You took the words right out of my mouth. If the library is always
explicitly coded, why have the library list at all?



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





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.