Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Front-ending trigger programs with CL

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Front-ending trigger programs with CL

    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?

  • #2
    Front-ending trigger programs with CL

    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.

    Comment


    • #3
      Front-ending trigger programs with CL

      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.

      Comment


      • #4
        Front-ending trigger programs with CL

        It was certainly an issue in the past..... We are V5R1.

        Comment


        • #5
          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


          • #6
            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


            • #7
              Front-ending trigger programs with CL

              Does anyone have an example CL that will just receive the buffer and pass it to the RPG ?

              Comment


              • #8
                Front-ending trigger programs with CL

                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?

                Comment


                • #9
                  Front-ending trigger programs with CL

                  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

                  Comment


                  • #10
                    Front-ending trigger programs with CL

                    Yes, ALWREPCHG(*YES) on a *BEFORE will let the trigger program update fields in the record before the system does the insert/update. Chris

                    Comment


                    • #11
                      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


                      • #12
                        Front-ending trigger programs with CL

                        Using a CL could create performance problems. It would have to be initialized each time it is fired.

                        Comment


                        • #13
                          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


                          • #14
                            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


                            • #15
                              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

                              Working...
                              X