Front-ending trigger programs with CL

[dmjae2004@yahoo.com]

Front-ending trigger programs with CL

The only reason I add a front end at all is because the triggered files are in constant use, and I can't replace the trigger processing program at all unless I go through this hoop. Buck/Ken, I am trying to understand how well this from a change management perspective. How do you get current users running their code to pick up the same new "trigger" program at the same time ? Thanks Dave

[K.Forsythe]

Front-ending trigger programs with CL

Simply replace the RPGIV (OPM) program that is doing the real work and immediately after that the CL front will call the new version of the RPG program whenever teh trigger is fired.

[buck.calabro@commsoft.net]

Front-ending trigger programs with CL

Hi Kevin, > While I agree with your suggestion, it fails to take into > account what activation group the application program > that caused the trigger to fire is running in. There is > certainly no one right or wrong answer for that situation, > but you must consider the behavior of things such as > commitment control and overrides - not only in the > trigger program(s) - but also the programs that cause > the triggers to run. Absolutely! That's why I say that activation group strategy is a design time decision. One can't simply slap multiple named activation groups into an application without reviewing your excellent summary above. > I appologize for the lack of clarity. I meant an > RPGIV program compiled as an OPM Program > rather than an ILE program. The naming scheme that Official IBM has left us with has caused more than one scratched head! --buck

[buck.calabro@commsoft.net]

Front-ending trigger programs with CL

Hi Dave, > I am trying to understand how well this from > a change management perspective. How do you > get current users running their code to pick up > the same new "trigger" program at the same time ? I had to refresh my memory so I did a test. On session A, I started upddta on my triggered file. I updated a record and it fired. On session B, I changed the trigger and recompiled it. Back to session A, I continued to update records. They show the changes reflected by the new code. I call the trigger processing program as a literal from the trigger front end. Both are ILE RPG programs running in the same named activation group, and the trigger processing program DOES set LR on. When I changed the trigger processing program to return instead of seton lr, it still worked as expected. That is, the changes to the trigger processing program were immediately reflected while the user was updating the file. --buck

[Absolutely_Nobody]

Front-ending trigger programs with CL

I read a post somewhere years ago that recommeded front-ending trigger programs using a very simple CL that passes the trigger buffer and length to the program that will perform the actions. It explained that this method of using a CL as a trigger driver was used to prevent having to remove the trigger from the file and add it back when the program that was actually doing the actions needed to be changed. Can someone provide me with an example of the CL to do this ? I know how to do the trigger programs in RPG.

[dmjae2004@yahoo.com]

Front-ending trigger programs with CL

Buck, Thanks for clarification. I would have thought if I had an ILE program running and an ILE trigger three options exist: a) Activation Group *CALLER. Which I would have expected the program to have remained active b) A named Activation Group I would expect the activation group to have remained active. Also this would seem to require commitment control be scoped at the job level. c) Activation Group *NEW In this case I would expect the behavior you observed with UPDDTA. Again it would require commitment control scoped at the job level. But also there would be a performance penanlty of both Activation Group start/end (including program initialization and file open/close) At the moment its academic for me, if I get an opportunity I'll setup a test along the above lines. Dave