sponsored links



No announcement yet.

Question about DLTOVR not performing as expected

  • Filter
  • Time
  • Show
Clear All
new posts

  • Question about DLTOVR not performing as expected

    We have discovered a DLTOVR is not working correctly.
    All the commands are basic:
    OVRDBF FILE(orgfile) TOFILE(newfile)

    Here is the basic setup


    call CLpgm1 parm1
    call CLpgm2 parm1
    call CLpgm3 parm1

    call CLpgm1 parm2
    call CLpgm2 parm2
    call CLpgm3 parm2

    Inside CLpgm1 we have ovrdbf to FILE1 based on the parm. there is no DLTOVR at the end of the CL.
    (this may be the problem)

    At the end of CLpgm1, it calls another program, CLPGM25.

    CLPGM25 has ovrdbf to file the same FILE1. It has a DLTOVR *ALL at the end.

    The second time CLPGM1 is called with parm2, the override from CLPGM25 is in effect, despite the fact CLPGM25 had DLTOVR *ALL at the end (no other parms on the DLTOVR command)

    So to recap, we have a level 1 program calling a level 2 program, which calls a level 3 program. The level 3 program had DLTOVR *ALL, but the second time the level 2 program runs, the override from the level 3 program remains in effect.

  • #2
    The OVRSCOPE parameter of OVRDBF controls the scope of the override. The default value for my system is *ACTGRPDFN - Activation Group Definition.
    DLTOVR will only delete overrides for a matching scope - only on that command the parameter is LVL. Again, that defaults to *ACTGRPDFN for me.

    What are those default values for you, and what are the activation groups for the programs involved? Are they the same or different? If the programs have different activation groups that may explain some of the odd behaviour.

    I like using scope *CALLLVL - Call Level (not that the value is "*CALLLVL" on OVRDBF, but simply "*" for DLTOVR). This means the override is only valid for this program, and subsequent calls descending from this program down the call stack (programs called by this program, programs called by them, and so on). When the program that created a *CALLLVL override returns to its calling program, which is higher in the call stack, the override is automatically no longer in effect. Though it's still good practice to do a DLTOVR. In your example, if CLPGM25 used *CALLLVL, then its override would be deleted when CLPGM25 returned regardless of if you did a DLTOVR at the end or not.

    I don't actually know what happens if yo do an OVRDBF for a file that is already overridden, as you are doing.


    • Vectorspace
      Vectorspace commented
      Editing a comment
      Sorry, typo. This: " *CALLLVL - Call Level (not that the value is "*CALLLVL" on OVRDBF, but simply "*" for DLTOVR)"
      Should be this: " *CALLLVL - Call Level (note that the value is "*CALLLVL" on OVRDBF, but simply "*" for DLTOVR)"

      I did not mean to imply that * = *ACTGRPDFN

  • #3
    well, in my case if you do an OVRDBF to a file that is overridden, it is ignored and the OVRDBF already in effect from lower in the call stack takes precedence.

    I understand the *calllvl would solve my problem. What I need to understand is what is the difference between DLTOVR *ALL and DLTOVR FILE(*ALL) LVL(*)


    • #4
      Is everything running in the same activation group? Different activation groups can cause things to work other than expected.


      • #5
        all in same (default) activation group. We do not use activation groups (yet).


        • #6
          I read it to say that *ACTGRPDFN means the same as * when the program doing the DLTOVR is running in the default activation group.

          ... When the activation group is the default activation group, the call level of the overrides to be deleted equals the call level of the calling program.

          The call level of the file overrides to be deleted is the call level of the program that called the DLTOVR command processing program. ...


          • #7
            Originally posted by Barbara Morris View Post
            I read it to say that *ACTGRPDFN means the same as * when the program doing the DLTOVR is running in the default activation group.
            does * in the DLTOVR command not match *CALLLVL in the OVRDBF command?


            • #8
              Sorry, there was a typo in my post. I meant to illustrate that call level on OVRDBF is OVRSCOPE(*CALLLVL), but on DLTOVR it's LVL(*)


              • #9
                Well, once your start digging deep enough, you start finding things. The override with OVRSCOPE(*CALLLVL) failed this morning.

                While I was concerend with the override on FILE1, the problem really is CLPGM25 was overrideing to FILE2, of which there was no override in any of the programs above in the call stack. But I really thought the OVRSCOPE(*CALLLVL) in CLPGM25 would release the override as well as the DLTOVR *all at the end. It did not. CLPGM1 used the overriede from CLPGM25.

                So I will add an override in CLPGM1, CLPGM2 and CLPGM3 for FILE2 and see what happens.

                I am just wondering if there is anyway to set an override for the duration of a CL program.
                Last edited by DaleJanus; January 10th, 2019, 08:39 AM.


                • #10
                  If your CL programs are CLP (as opposed to CLLE) then all overrides issued within that program that are specified as either OVRSCOPE(*ACTGRPDFN or *CALLLVL) are automatically deleted when the program ends. At this point, perhaps you should run the programs in a test environment and place DSPOVR commands at various places within the programs so you can see what overrides are in effect and where they came from at certain points in the program.


                  • #11
                    late follow up.
                    We got bit again by what we thought was failed DLTOVR. Instead, what we found was it doesn't matter if you DLTOVR to a file in QTEMP. if qtemp is at the top of the library list, it's gonna get used. Better to delete qtemp/workfile and you won't have to worry about it.