×
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.
Hello,
What you could do is read the parameters of the trigger program. If
the parameter which tells you what schema the table is in says
TESTLIB then hopefully your application has either a job description
or data area in that schema that it can read to set the library
list.
It's been my policy that a trigger program should _only_ update a file
if that file is in the same library (schema) as the one upon which the
event was triggered.
Thus, I have a CPTMAS (component master) file in which is the
bill-of-materials for the products we make. Each time it's updated, I
am required to log the change to another file called CPTLOG. My rule is
that CPTLOG and CPTMAS must be in the same library. So if I have a
development copy and a production copy, the dev copy of CPTMAS/CPTLOG
are in a "DEVFILES" library, and the prod copy of both files is in a
"PRODFILES" library... two different libraries, but the corresponding
files always match. Always in the same library as each other.
With that rule in place, it's really pretty easy to code. I don't
bother monkeying around with the library list, I just tell the trigger
to use that specific library.
In positions 11-20 of the trigger buffer (the first parameter to the
trigger) you'll find the library (schema) that triggered the event. So
my trigger does something like this:
FCPTLOG O A E K DISK EXTFILE(Logfile)
F USROPN
.
.
if Library <> LastLib;
if %open(CPTLOG);
close CPTLOG;
endif;
logfile = %trimr(Library) + '/CPTLOG';
open CPTLOG;
LastLib = Library;
endif;
(That's off the top of my head... I may have a detail wrong.)
The idea I'm trying to present here is that I don't use the library list
to get that file -- I always want to get the one that's in the same
library as the one that has the trigger attached, so I simply tell it to
use that library. That way, I don't need to adjust the library list,
plus I only need to reopen the log file when the library changes --
which performs a whole lot better than changing the library list and
opening the file on every call.
Furthermore, changing the library list has the chance to impact the
WHOLE JOB (not just my trigger program) whereas this approach only
impacts the trigger. The user can do whatever they like with the
library list, otherwise.
When you KNOW you want a very specific library, why force a program to
go through the library list to get there?
midrange.com
