ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Multiple overrides in RPGLE and DLTOVR fails with "Override not at specified level"

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

  • Multiple overrides in RPGLE and DLTOVR fails with "Override not at specified level"

    My RPGLE pgm1 has following command -

    OVRDBF FILE(File1) TOFILE(lib/File1) SECURE(*YES) OVRSCOPE(*CALLLVL) SHARE(*NO)

    There are 7-8 programs called after this. The last SQLRPGLE program has below statements -

    OVRDBF FILE(File1) TOFILE(lib/File1) // Second override of the same lib/file
    ....
    ....
    ....
    ....
    DLTOVR FILE1


    This particular DLTOVR statement fails with the message "override not found at specified level".

    I checked google and find that multiple overrides could cause the DLTOVR to fail with this message, unless an override is defined with *JOB level. I can handle this DLTOVR within monitor block to avoid program crash. However, is there any other alternative to fix this up?

  • #2
    You say that your RPGLE pgm has that CL command. Are you running it with the QCMDEXC API? With the QCMDEXC API, I always have to specify *JOB for the override level.

    HTH

    Comment


    • #3
      Yes i am running with QCMDEXC only. Is it mandatory to use *JOB for override level?

      Comment


      • #4
        *CALLLVL means the override applies to this program, and everything called by this program, and it will end when this program returns.
        So if program Y calls program X, and program X does the Override, then X and anything X calls will have the override, but when control returns to Y the override will be gone.

        Your program is not running the OVRDBF. Your program is calling QCMDEXC. If QCMDEXC counts as its own call level like any other program (as opposed to be counted as your program's call level) then it would be useless for overriding with *CALLLVL because the override will disappear as soon as QCMDEXC ends. So in this scenario your program is Y and QCMDEXC is X. I do not know for a fact this is how it works, but I suspect it.

        Comment


        • #5
          Originally posted by Vectorspace View Post
          Your program is not running the OVRDBF. Your program is calling QCMDEXC. If QCMDEXC counts as its own call level like any other program (as opposed to be counted as your program's call level) then it would be useless for overriding with *CALLLVL because the override will disappear as soon as QCMDEXC ends. So in this scenario your program is Y and QCMDEXC is X. I do not know for a fact this is how it works, but I suspect it.
          Actually, the system makes a provision for overrides called via QCMDEXC and puts the override at the call level of the program that called QCMDEXC. If it didn't do this, I'd have alot of programs that wouldn't work.

          Comment


          • #6
            I wasn't sure if QCMDEXC was an exception (that's why I said 'if'), so thanks for clarifying.

            Does the system also make an exception for the "System" C api?

            Comment


            • Brian Rusch
              Brian Rusch commented
              Editing a comment
              Sorry, I've never used the "System" api so I don't know for sure, but I suppose it would be easy enough to test.

            • Vectorspace
              Vectorspace commented
              Editing a comment
              The answer is Yes, there is an exception for the System C API - you can use it to apply a *CALLLVL override

          • #7
            (For others reading this thread, the message ID is CPF9841.)

            From googling, I see references to specifying *JOB, but I don't see why *CALLLVL shouldn't work. (But my expertise isn't in OVRDBF, so maybe there's a good reason for needing *JOB.)

            Anyway, I wonder if specifying SECURE(*YES) on the second OVRDBF would help.
            Secure from other overrides (SECURE) - Help

            Specifies whether this file is safe from the effects of previously
            called file override commands.

            *NO
            This file is not protected from other file overrides. Its values
            are overridden by the effects of any file override commands that
            were previously called.

            *YES
            This file is protected from the effects of any file override
            commands that were previously called.

            Comment

            Working...
            X