Can you explain why you would rather change the CL program and recompile it than remove the old trigger program and add a new one? How often do you change your trigger programs?
Unconfigured Ad Widget
Collapse
Front-ending trigger programs with CL
Collapse
X
-
Front-ending trigger programs with CL
I just did a little experiment. I added a variable to our Trigger program and assigned a value at Initialization then recompiled. So the program is different although not in any important respect. I then made a database change to a File that uses the Trigger program using our application software. The Trigger worked fine without having to remove and add it back to the Files (more than 1) that use the Trigger program. What you might be referring to is the fact that there can be no locks on any file that uses the Trigger Program at the time it is replaced. I did this in our Test environment and a single user had a lock on one of the Files that use the Trigger program. The program would not recompile until that lock was released. So by using a front-end CL you MIGHT be able to get away with recompiling the progam that's called from the CL even while you're Users are busily working away. But I would definitely test that assumption first. I would think that if the program remains in memory, you might have the same problem. Mike
Comment
-
-
Front-ending trigger programs with CL
Here's an additional reason to create a front end CLP: Suppose during the course of the day you have a program that waits for records to be added to a file and then processes those records. A trigger program cannot open a file that is being processed by the trigger. If you have a front end CLP, that can sense the firing of the trigger, and subsequently call another program that performs the actual processing. Dave
Comment
-
-
Front-ending trigger programs with CL
I don't use CL although you could. I use a simple RPG program as a front end. See http://archive.midrange.com/rpg400-l.../msg00501.html --buck
Comment
-
-
Front-ending trigger programs with CL
1) Call a CL program and pay the performance costs 2) Call a CLLE program in *CALLER activation group and pay less performance cost - have the program remain in memory for extended periods of time - also creating object locks. 3) Call a CLLE in a named activation group - same as previous except that certain things like ovrdbf may not work the same 4) Call an RPG program and pay the performance costs 5) Call an RPG program that ends without setting on LR and pay slightly less performance costs 6) call an RPGLE program and pay basically the same costs as a CLLE program. That's how I see it. Anyone else have any thoughts? Kevin
Comment
-
-
Front-ending trigger programs with CL
Kevin wrote: > 1) Call a CL program and pay the performance costs The costs may be very slight if there are no variables in the program. Only a benchmark will tell for sure. > 2) Call a CLLE program in *CALLER activation > group and pay less performance cost - have the > program remain in memory for extended periods > of time - also creating object locks. Why would there be object locks? The CL front end shouldn't be opening any files I wouldn't think. > 3) Call a CLLE in a named activation group - same > as previous except that certain things like ovrdbf > may not work the same Activation group strategy is always a design consideration more than a runtime consideration. Not that I would do this, but if I were to use a named AG, I'd put the RPGLE trigger program it calls in the same named AG which would take care of most of the OVRxxx concerns. > 4) Call an RPG program and pay the performance costs > 5) Call an RPG program that ends without setting > on LR and pay slightly less performance costs In this day and age, why would anybody deliberately write new code in RPG/400? > 6) call an RPGLE program and pay basically > the same costs as a CLLE program. This is how I do it. The ADDPFTRG refers to an RPGLE program that only checks a data area to see if the trigger should run or not. If it does not run, it does a RETURN and lets the DB manager complete the I/O. If it runs, it simply passes the buffers to the real trigger handling program (RPGLE) and lets that do it's thing. If the real trigger wants to deny the I/O, it passes a parameter back to the front end who then sends a message to cause the DB manager to abort the I/O. In general, one strives to keep the trigger itself very small and very fast. 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. The performance is not noticeably worse for interactive programs, but I strongly suggest benchmarking batch programs (I/O in the millions of records) before committing to this strategy of front-ending a trigger. Also try different 'flag' approaches - data area, user space, existence check and so on. There may be an optimal way for one company to indicate that the trigger should run and a different optimum for another company. As always, when talking about performance, benchmark on your machine with your dataset and your workload. What works great in my circumstances might bring your configuration to its knees. --buck
Comment
-
-
Front-ending trigger programs with CL
> 2) Call a CLLE program in *CALLER activation > group and pay less performance cost - have the > program remain in memory for extended periods > of time - also creating object locks.
Why would there be object locks? The CL front end shouldn't be opening any files I wouldn't think.
I concede that the only way there would be an object lock to worry about is if the CLLE made a procedure call to an RPG module. I don't think anyone is reccomending that as a solution.> 3) Call a CLLE in a named activation group - same > as previous except that certain things like ovrdbf > may not work the same
Activation group strategy is always a design consideration more than a runtime consideration. Not that I would do this, but if I were to use a named AG, I'd put the RPGLE trigger program it calls > in the same named AG which would take care of most of the OVRxxx concerns.
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.> 4) Call an RPG program and pay the performance costs > 5) Call an RPG program that ends without setting > on LR and pay slightly less performance costs
In this day and age, why would anybody deliberately write new code > in RPG/400?
I appologize for the lack of clarity. I meant an RPGIV program compiled as an OPM Program rather than an ILE program. Thanks for the comments Buck, you clearly have a lot of valuable experience in this area.
Comment
-
Comment