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?
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?
That's the point ! I would never have to update the CL. But, if I ever needed to update the program that I would have attached to the file, I would need to remove the trigger and add it back for the change to become effective.
Are you sure that you have to detach and reattach the trigger if the program is recompiled? I don't remember having that issue when I played with triggers before.
It was certainly an issue in the past..... We are V5R1.
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
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
Does anyone have an example CL that will just receive the buffer and pass it to the RPG ?
I thought the Allow Repeated change made updating the same file and even the same record a valid (but confusing) option. Has anyone tried that recently?
Use two parameters and just pass them to the RPG program. It can parse the first one up into its parts. The second is a 4 byte binary length.
Code
Yes, ALWREPCHG(*YES) on a *BEFORE will let the trigger program update fields in the record before the system does the insert/update. Chris