On Triggers and library lists.

As I alluded to in my question about recognising a particular job, I've
recently made my life more difficult than it needed to be by trying to
solve an efficiency problem before I had checked to see if it really
existed...

However, I've learned a fair bit about QTMHHTP and it's QTMHHTP1 threads
and the prestart jobs QRWTSRVR ( DRDA/DDM Server ) and QZDASOINIT (
Database Host Server ) along the way, so it's not all bad...

I digress, sorry.

This question is about how ( if at all ) people try to ensure that any
processing performed in a trigger program is applied to data in tables in
the same library of the file with the trigger. Ok, I'm not proud of how I
constructed that sentence but I hope the idea is clear enough.

My triggers in this application are currently all RPG. One file in
particular is kind of a gateway into the application from other
Applications ( including a web service on another LPAR ) and I have taken
pains to use the library in the trigger buffer to override the ( few )
files it inserts records into and qualify it's call to QSNDDTAQ. That way,
my servers in other Applications just have to qualify the one gateway file
and the trigger takes care of everything else.

But in general, it doesn't seem like you should have to go this amount of
effort to maintain integrity.

However I find myself worrying about scenarios like:
- A user logs into a Production System. For inexplicable reasons decides to
STRSQL and update some records in a Test version of the Application, ( by
qualifying the files ) while they still have a Production System library
list. The trigger program on the Test version of the file fires and updates
files in the Production data library... We all cry and gnash our teeth.

In my "gateway" trigger above, it would all work out, because I have
reasons and have taken pains to ensure that will be the case.

But as a general principle should the trigger just work with the library
list it is given and rely on the integrity of the caller, or should it try
to control it?

Forgive my ignorance, I'm not certain if this issue goes away if you use
SQL triggers and set the current schema. I've written SQL triggers before
but always been in a situation where I was using someone else's "standard"
and so never had to study the details of it. Of course I'd still have to be
careful with procedure calls and I believe there are some potential
differences in how static and dynamic SQL statements are handled.

I'd be grateful for any thoughts on controlling the trigger program's
environment..

Thanks as always,
Craig