From: Crispin
*LIBL is there for a reason. Why have two versions of a program just to
stick to your rule?
Crispin, you're absolutely correct. The library list happens to be one of
the most powerful concepts of the midrange platform, and is almost
non-existent in other environments -- and where it does exist, it tends to
be something of a hodgepodge of paths and environment variables that are
often more trouble than their worth.
But that's my opinion, and as the JP08 version is trying to be a bit less
opinion-oriented, rather than get into a debate I'd simply like to present a
case where *LIBL access to QTEMP objects is the best answer.
Specifically, some applications like to use either a data area to store some
control parameters. Typically there are system-wide defaults stored in an
application library, but occasionally you might need to override those
temporarily.
When you only want overrides for a specific situation, be it a user, a job,
or a workstation, it's nice for the initial program to be able to create a
copy of the data area in QTEMP and modify those settings specific to the
job. That way, the overrides are only in place for the duration of the job
(this is especially nice on batch submits) and they go away automagically
when the job ends.
The nice thing is that the application code doesn't have to check. It
simply uses the library list to open the data area, and it really doesn't
care where it's coming from.
Yes, there are other ways around this; each has its pros and cons. That's
not the point. The point is that in this particular case this particular
technique works perfectly. It is not poorly written code, it is code that
takes advantage of the unique characteristics of the machine.
As always, it's a business decision, and you should use the best tool for
the job.
Joe
midrange.com
