Crispin,
I would like to start with a few general points:
1. I was only trying to describe how I do things and not how everyone should handle/support library lists. I can see however how my inital note might have been improved on in this regard :-)
2. I tend to work on tools and utilities that (hopefully!) complement i5/OS. I have never written (and in my mind hopefully never will) an application such as Payroll, General Ledger, Order Entry, etc. Those types of applications may very well need a more generalized approach. My type of work, as an example, would be to provide a tool which can automate the release of held registered licenses for a licensed product when the registered user(s) meet certain criteria (and avoid having an operator go through WRKLICINF to do this). As such I tend to not be working with user databases in any general application sense (though certainly could be from a general tool/utility point of view).
3. I do tend, as I mentioned earlier, to be a control freak when it comes to production level code. For instance, when using RPG it's very unusual for me to have RPG runtime implicitly open my files. I use USROPN and EXTFILE(file_variable) with explicit setting of file_variable prior to opening the file. This may in part also be due to my not using alot of CL programs either. My CPPs tend to be non-CL and I redirect as necessary within the utility. If I need a CL function, I use an API such as QCAPCMD. So for me changing the file at runtime is not that difficult. But I do realize that many developers do not do this.
4. My previous notes were indeed refering to the use of the library list in general and not QTEMP specificallym, so your "diatribe" is justified :-). I apologize for not clarifying this earlier -- I tend to forget what the subject line is when reading a note...
As to your note:
Indeed my concern is with someone putting something higher in the library list and overriding my processing. It is incredible how much time can be spent debugging a problem caused by this type of change. I saw this, at times in all too great of detail, while working in the lab and want to avoid such expenditures of time within my own company. Prior to my leaving IBM, IBM support was performing certain checks for this type of flow alteration when working on systems with particular applications installed -- just because of the time and expense involved just to determine "it's someone elses problem".
As to your bootstrap process, I use custom builds for my products (which sounds like it might be similiar). I do development and test in one environment, and then have a build process which recomplies everything into a production environment. Once there I have test suites which I run to confirm my build. Within the development environment I often utilize the library list to speed things along, and I certainly do in my build process, but in production I do not. But to stress again, the case of multiple languages and multiple databases fall into points 1 and 2 respectively of my first note in this thread. Here the library list is absolutely critical in production. As for PTFs, I'm not sure I follow that point. This may be due to packaging my products as licensed programs and using the IBM PTF support inherent to i5/OS.
I hope this helps. I certainly did not intend to be suggesting that the library list capability of the system not be used. I use it all the time -- but selectively :-)
Bruce Vining
Crispin Bates <cbates@xxxxxxxxxxx> wrote:
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"
To: "Midrange Systems Technical Discussion"
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 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.
midrange.com
