Some comments inline.
Lim Hock-Chai wrote:
Below are some not so traditional-RPG-programmer friendly things
about trigger (They are not problem, just stuffs that traditional
RPG programmer are not familiar with):
1) Commitment control issue. Programmer that creates trigger program
tends to not consider commitment control. If the file is under
commitment control and trigger is not, roll back will not rollback
what trigger has done. Well, depending on what the trigger is doing,
this might not be an easy fix.
That of course is a problem of the programmer, not of triggers. Such
a programmer would apparently have the same problem for any two programs
where the first running with CmtCtl, calls a program which does not
participate in the transaction. Either every step within the entire
transaction is properly isolated & ensures atomicity of the entire
transaction, or they do not. If the programmer is writing a program
that utilizes commitment control, yet does not understand or consider
that for all activity\calls, then they probably should not be writing
that program, nor those programs that it calls.
2) When use CRTDUPOBJ, the trigger get duplicate over to the To-File
also. Programmer sometime dup file to QTEMP to do some temporary
work. This could be dangerous if he does not intend to have trigger
fired on this QTEMP file.
CRTDUPOBJ and CPYLIB both have parameters to prevent duplicating
triggers if that is desired. The CHGCMDDFT can be used to set the
default to not copy triggers, implemented as part of system change
management controls, if that is perceived as the /safer/ default.
3) Speed (This could be a problem if the file gets update/add
frequently).
If the action to be activated is per row, then that activity could
either be triggered by the database I/O, called directly by the
application, or /batched/ at a later time. If the application does the
additional work, performed in another program where the call is dynamic,
consider that the trigger is called by address versus dynamically. Also
if the application performs the work instead of triggers, I/O outside of
that application [e.g. FTP, ODBC, etc.] would not have the per-row logic
applied, so that has potential drawbacks anyway [discussed starting with
first reply by Joe Pluta in this thread].
Note: SQL does offer statement-level trigger capability [FOR EACH
STATEMENT clause on CREATE TRIGGER DDL], since the SQL works with a set
versus single rows. Obviously moving away from RLA is required for that
to be effective to limit the per-row effect.
4) Can't easily remove trigger. Must have exclusive lock on the file
to do so. I know Alan has a mediator program that can "turn it off",
however, if speed is every important due to major issue, it might
not work well since the mediator program will still get call for
every update/add.
Triggers typically implement rules that are established with the
design [changes] of the database and the application(s). Much like
modifying the definition of a TABLE, changes to, removal of, and
addition of triggers on a TABLE would typically be performed only during
maintenance windows. Needs for dynamic changes would typically be for
defect fixes, since design changes would likely have a formal procedure
to activate the changes during maintenance versus dynamically. For
defect fixes, consider what would be the recovery if the defect was in
the application versus the trigger; that although dynamic calls may
ensure a REPLACE(*YES) compile would get the fix for the _next_
invocation, any case where either the call was static by address or the
dynamically called program is still in the stack would continue to have
the defect active for which dynamic changes are no less difficult than
for having to remove & add a corrected trigger. That triggers are a
static binding, is a consideration for implementing change, just as for
other scenarios.
The CHGPFTRG to disable a trigger would be used until such time that
a RMVPFTRG could be arranged in the maintenance window, when the intent
is simply removal of the trigger versus making code corrections. Much
like for routing programs in subsystems, the alternative is to have the
/mediator/ as suggested; not ideal, but impact to the /speed/ is a
trade-off, like with so many other options in programming. The
restriction serves as a reminder of the importance to carefully & fully
test the trigger programs, and to consider implementing capabilities to
enable either application shut-down or switch\fail-over features for
maintenance considerations; which also enables higher availability.
5) Can clear the file without removing trigger.
Perhaps this is a false impression that since CLRPFM truncates the
dataspace, effectively removing all rows without any row level I/O, the
actions of the trigger can be bypassed? Or perhaps this means to imply
that CLRPFM "Can not clear the file.mbr without removing" a DELETE
trigger.?
I'm not against using trigger, I just notice that above are things
that irritate traditional-RPG-programmer.
David FOXWELL wrote:
I hear there are occasional problems when a trigger program is
involved, although I don't have a lot of experience with these.
I've just created a new transaction file and the boss says no
trigger. The trigger on the master file already fires off all
over the place and can be a pain in the neck while developing.
David G wrote:
What kinds of problems have you heard about?
Did your boss say WHY he doesn't want you to use a trigger?
This is really a case of using the right tool for the job ...
and, for what you want, a trigger is the right tool. Perhaps
you can explain this to your boss.
midrange.com
