Re: Fw: On Triggers and library lists.

Art - thanks for replying, it's always good to hear of people's experiences
in order by better informed to make the right decision.

Deiter - thanks also for taking the time to reply and add so much detail.

I agree that as you say, once added, the trigger program is qualified it
will always be located when the trigger on the table fires.
I was really only asking about whether it's usual to force the trigger to
use files in the same library the file triggers from, and if there was a
simpler way in SQL triggers than doing what I'm doing with an RPGLE program
trigger - either overriding or qualifying all file access )
( for example, I wondered if the more SQL-Trigger savvy would start
shouting at me, something like: USE AN SQL TRIGGER AND SET SCHEMA YOU
MUPPET! )
So far that hasn't happened...

I can see that in general the problem is bigger than just the data - as you
point out - if the trigger program had a requirement to call other programs
then that would be an additional concern but thankfully in my case it is
not required.

So I guess your last sentence is the one that interests me the most - "use
SQL for all I/O operations and qualify in all statements"

Given that I will mostly ( I hope ) only be dealing with 4 or 5 files in
each trigger I think for safety I will qualify all file access.

best regards,
Craig


On 23 February 2018 at 06:18, D*B <dieter.bender@xxxxxxxxxxxx> wrote:

second try to the right list.

--------------------------------------------------
From: "D*B" <dieter.bender@xxxxxxxxxxxx>
Sent: Friday, February 23, 2018 7:16 AM
To: "RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx>
Subject: Re: On Triggers and library lists.


Hi Craig,

locating database ressources by library list isn't a good idea at all...
In your case there are good news at the starting point: trigger programms
are located by their qualified name! If you specify *LIBL at ADDPFTRG, the
lib is resolved and the quaified programm is addded (you could verify this
by DSPFD). One easy strategy to follow (I'm going this route with ArdGate,
where I can't controll the libl at all) is make it all selfcontained:
- put the trigger programm in the same lib as the file it is added to
- put all ressources the trigger needs, in the same library (programms to
call, SRVPGMS it's using...), the files it's writing to
- write the trigger in RPG (as it's runtime knows where it's coming from
=> programm status datastructure PSDS is your friend)
- it's enough to look once at beginning where you are coming from
(minimal overhead!!!)
- call all dependent programms qualified
- SRVPGMs are a little bit tricky to handle, if you are binding
qualified, you would need diffrent bindings for prod and test and ..., if
youu bind by libl, it could be corrupted by environment. Best is, to bind
qualified at runtime, it's done by some APIs, you could have a look to
ArdGate how it is done (it's open source, available at SourceForge - look
at PROCP4NAME and how it is used in JDBCGATE)
- use SQL for all I/O operations and qualify in all statements.

D*B

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD