Re: Making Triggers Resilient

Maybe I can rephrase what others might have been saying.  Let's say your 
trigger parameters include the file and the library.  Now, take that 
library and do something like
FLIBPARM   ...                      useropn extname(LibFile)

and set the variable LibFile to what the trigger parameters were.  Read 
the file LIBPARM.  Maybe one would have a library for the program and one 
for the file.  Now if you're not calling a bunch of programs this would be 
ok.  However if you are really going deep into something (like someone 
modified the pricing so let's initiate a BPCS cost roll up) then you 
probably have to do what you're thinking and actually modify the library 
list.  But for simple ancillary files you could just open them with USROPN 
also.

I did read something awhile back of the benefits of storing your trigger 
programs in the same library as the file.  I think it had to do with a 
system restore not causing the link to be broken.  Like if your file 
library is TLADIVF and your program library is TLADIVO, a system restore 
would be TLADIVF on first and since the files couldn't link to the 
trigger, all hell would break loose.

Another alternative.  When a command executes you can do a CHGCMD 
PRODLIB(somelib) CURLIB(someotherlib).  Read the help on the command 
CHGCMD - it's pretty interesting.  For example, the PRODLIB on STRPDM is 
QPDA.  Do a DSPLIBL before and after executing STRPDM and notice the 
difference.  Other than CHGCMD is there a way to use this for your 
programs?

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





Glenn Melville <glennmelville@xxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
02/27/2005 08:25 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: Making Triggers Resilient






Hi Scott,

Thanks for the reply.

Just to clarify setting the library list, the thoughts were to save the 
library list before running the trigger then put it back at end of 
trigger.  We did have doubts over this technique, i.e. performance, but 
it would have been transparent to the user.

Regards

Scott Klement wrote:

>
> Hello,
>
>> (1) You must ensure that the triggered program has all objects it 
>> requires in the library list.
>
>
> If at all possible, eliminate the need for other objects. (Aside from 
> those that are part of the OS and therefore in the system portion of 
> the library list.)
>
> Personally, the triggers I've written don't use any other objects -- 
> but I guess it depends on what the trigger does.
>
> The next question that comes to mind is, "what objects are you having 
> problems with?" Does your trigger need to call other programs? Make 
> printouts? Reference other databases? Data queues?
>
> Perhaps the best solution is to stop using the library list to locate 
> the objects that your trigger depends on.  If it needs a file, have it 
> specify the library.  If it calls a program, have it specify the 
> library...  I wouldn't recommend hard-coding the library, but you 
> could create a configuration file or data area that the program could 
> load the libraries from.  Then, if you wanted to run on another 
> library for some reason, you could easily change it.
>
>> (2) What happens if someone use UPDDTA without file ABC being in the 
>> library list, i.e. UPDDTA MYLIB/ABC.
>
>
> As far as I can tell, this is the same question as (1).
>
>
>> (1) Placing the trigger program in the same library as the file it is 
>> triggered from.
>
>
> I don't see how that helps you. Sure, if you assume the database is 
> always accessed by library list, you'll be okay... but that's not 
> always the case.
>
>> (2) Using a generic trigger program that sets the correct library 
>> list using either a job description or library list held in a common 
>> file linked to the library/file/member/trigger type/trigger time.
>
>
> Nononono!  Don't change the library list in a trigger... that would be 
> really confusing for the user who sets her library list for a reason, 
> and it's suddenly, magically, reverted back to the default one.
>
> Just code your RPG program so that it doesn't use the library list to 
> locate things!  For example, on a program call, do this:
>
>       C                   eval      Program = 'MYLIB/MYPGM'
>       C                   CALL      Program
>       C                   PARM                    FOO
>
> Or, with a prototype:
>
>      D Program         s             21A
>
>      D MYPGM           PR                  EXTPGM('MYLIB/MYPGM')
>      D   Parm1                       10A
>
>       /free
>
>           Program = 'MYLIB/MYPGM';
>           callp MYPGM('FOO');
>       /end-free
>
> Or, with a file:
>
>      FMYFILE    UF   E           K DISK    EXTFILE(LibFile)
>      F                                     USROPN
>      D LibFile         s             21A
>
>      C                   eval      LibFile = 'MYLIB/MYFILE'
>      C                   open      MYFILE
>
>
> (Except, of course, load the library names from a configuration file 
> or data area or something...)
>
> That way, you don't have to change the library list (which affects 
> other things) your changes only affect the trigger.  You'll probably 
> want to put the code that does this in your *INZSR so that you only 
> have to do it once when the trigger first loads...  doing it on each 
> call could be expensive.
>
> HTH
>
-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.