ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

OVRPRTF scope in RPG programs

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

  • OVRPRTF scope in RPG programs

    I recently modified a program in our shop that has some OVRPRTF commands that are executed by the QCMDEXC. I modified this program and put a subprocedure at the end of the source for something unrelated to the OVRPRTF. I had to add the DFTACTGRP(*NO) entry in the H spec in order for the program to compile with the sub procedure included. I noticed that the OVRPRTF commands were not taking effect any more after I made this change. I changed one of the OVRPRTF commands to specify *JOB on the OVRSCOPE parameter and this remedied the problem. The problem is that there are a lot of hard coded OVRPRTF commands in the program and I would have to change all of them plus explicitly execute a DLTOVR FILE(*ALL) LVL(*JOB) command upon exiting the program.

    Any ideas how to get around this dilemma. One idea is to make a seperate program call out of the subprocedure but I would rather not do that, if possible'

    Thanks again

  • #2
    If the OVRs are issued within the program they should still have worked. Are you sure they are being issued by the same program?

    Comment


    • #3
      Originally posted by JonBoy View Post
      If the OVRs are issued within the program they should still have worked. Are you sure they are being issued by the same program?
      Yes, I am sure. What I did was, using the debugger, I put a break point right after the QCMDEXC(OVRPRTF) using the default value for OPNSCOPE, ran the program and then when it hit the break point, I did a WRKJOB to see if there were any overrides in force and there were not. Then I changed the OPNSCOPE to *JOB and repeated the previous steps stopping at the same breakpoint and voila the OVRPRTF was there in force. As I mentioned the only thing I changed from before when it worked using the default value for OPNSCOPE was I added a subprocedure at the end (it had nothing to with this issue) and changed the DFTACTGRP to (*NO) in the H spec.

      Comment


      • #4
        I added a subprocedure at the end (it had nothing to with this issue) and changed the DFTACTGRP to (*NO) in the H spec.
        Adding the subprocedure forced you to make it a "real" ILE program not a "pretend" old style program - so it has everything to do with it.

        What did you specify for Activation group? If you defaulted it then it will be QILE.

        I'm not convinced that the debugger shows you the true picture here but don't have time to play right now.

        What program is supposed to see the overrides? The one that puts them in place? In which case those files must have USROPN specified. If not, and the OVRs are required for subsequent program(s) in the call sequence, what activation group do those programs run in?

        My suspicion is that the program issuing the OVRs was not the one using them and that the programs in question are DftActGrp(*Yes) and therefore would not see the OVR. The OVR without specifying *JOB would have a scope of *ACTGRPDFN which means that no programs outside the calling program's AG would see it. *CALLLVL (which is the default for OVRs from the default AG) would have had the same effect.

        If I have guessed correctly then (much as I hate suggesting it**) then a possible simple fix is to specify ACTGRP(*CALLER) for the program issuing the OVRs. That will make it run in the default AG and you won't need to specify the OVR scope.

        But you should re3ally study up on ILE and Activation groups. There are lots of "cook book" approaches to using it that help you avoid pitfalls like this.

        ** There are problems that can arise when using Service Programs in this scenario - make sure that you have a good understanding of the issues before perusing this as a long term strategy. It is not a good idea.

        Comment


        • #5
          Greg,

          I had this issue years ago when I first encapsulated the ovrPrtF command inside a Service Program procedure.

          The issue, if I remember correctly, is that you cannot control the Activation Group of QCMDEXC().

          So, the only solution I could find at the time, and still have the ovrPrtF command encapsulated, is to use OVRSCOPE(*JOB) just as you have.


          Walt

          Comment


          • #6
            That's not really the issue Walt because QCMDEXC always actions the command at the current stack level.

            The issue is the default scope for OVRs. For an OPM program or a DFTACTGRP(*YES) they are scoped by default to the call level. For "real" ILE programs running in an activation Group (QILE by default) they are scoped to the Activation group. As I noted you can run your ILE program in the default by running *CALLER as the AG. But when you start using Service Programs as you have done that is a really bad idea.

            You might find reading our "Seven Deadly Sins" article http://archive.ibmsystemsmag.com/ibm...y-sins-of-ile/ where we talked about a lot of the issues of running real ILE programs in the default AG and why it can present problems. That remains to this day the only article we have ever written that got us a job. An IBM i customer read it and called asking if we could come and train them as they have discovered that they were committing all 7 sins!

            Comment


            • #7
              Thank you for your input JonBoy.

              I appreciate what you are saying as I have been using Activation Groups since they were available. I've also referred to your Seven Sin's article a number of times since it was written.


              Now, I don't remember exactly what I was told by IBM at the time (15 - 20 years ago), but it was along the lines of QCMDEXC is an OPM program, and therefore cannot be in an activation group. And, I believe I was trying to get the qcmdexc command to execute within the caller's activation group so that I didn't have to worry about scope issues; but the override kept disappearing as soon as the procedure exited.

              And, as I was fixated on getting the ovrPrtF wrapper working (I was tired of fighting all the bugs with everyone creating their own ovrprtf strings and then executing qcmdexc), I didn't worry about it any further.

              The wrapped qcmdexc() has performed its function well over the years since then, and I've never gone back to review it. Perhaps it is time to see if that issue with my service program procedure can be addressed.


              Thanks again!

              Walt



              Comment


              • #8
                OK that makes sense.

                QCMDEXC is an oddity - actually it always was but ... effectively the way it operates is to do its work not at the level of its own call but to sort of back off the action so that it seems to occur at the same invocation level as its caller. While technically true that it is an OPM program it is not that that caused your problem and in practice the information given to you by IBM was incorrect.

                I can see now the problem you were trying to address and it is not an easy one. The only potential downside to *JOB is, as you may have already discovered, that you have to clean up the OVR manually yourself - you can no longer rely on the call stack to clean it up.

                Comment


                • #9
                  Originally posted by JonBoy View Post
                  OK that makes sense.

                  QCMDEXC is an oddity - actually it always was but ... effectively the way it operates is to do its work not at the level of its own call but to sort of back off the action so that it seems to occur at the same invocation level as its caller. While technically true that it is an OPM program it is not that that caused your problem and in practice the information given to you by IBM was incorrect.

                  I can see now the problem you were trying to address and it is not an easy one. The only potential downside to *JOB is, as you may have already discovered, that you have to clean up the OVR manually yourself - you can no longer rely on the call stack to clean it up.

                  That is definitely a downside; fortunately, it was discovered while testing. And, most of the uses of the ovrPrtF() calls are for reports in Submitted Job streams, so the negative impact has been negligible.

                  Thanks again for your insights, Jon.

                  Walt


                  Comment

                  Working...
                  X