Override not found at specified level

645 pts.
Tags:
#AS400 #RPGLE #as400
RPGLE
My RPGLE pgm1 has following command - 

OVRDBF FILE(File1) TOFILE(&OVRLIB/File1) + WAITRCD(&LOCKWAIT) SECURE(*YES) + OVRSCOPE(*CALLLVL) SHARE(*NO)

There are 7-8 programs called after this. The last program has below statement -
DLTOVR FILE1

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

When override is initially completed at pgm1, i take Shift+Esc 3, and option 15 to verify overrides. The override is set on the file as expected, and i check again before DLTOVR is executed. The override is still in place. Hence, I am not sure why the DLTOVR command is failing.

Anything else to be checked on this? I tried chaning DLTOVR command to LVL(*) and it still fails. Would something else need to be checked in code in particular ? (As I stated, there are 7-8 programs in the middle)
0

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

Discuss This Question: 14  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TheRealRaven
    The override might indeed still be in place, but it's in place at OVRSCOPE(*CALLLVL).

    What level is specified for your DLTOVR? The default is LVL(*ACTGRPDFN) which doesn't match level *CALLLVL.
    36,420 pointsBadges:
    report
  • ToddN2000
    It might help to see the full set of CL code and how the other jobs are being called or submitted.
    135,495 pointsBadges:
    report
  • sri8707
    Hi @TheRealRaven,

    DLTOVR is specified as below - 

    DLTOVR FILE1

    So, i presume it takes the default level (*ACTGRPDFN). However, even if i change the command as DLTOVR FILE LVL(*), I still have the same issue. Before doing delete override, I take shift+Esc 3 -> 15 and see the override exist at call level. But, the delete override command fails. Anything else to check here?
    645 pointsBadges:
    report
  • sri8707
    Hi ToddN2000, override and delete overrides are executed at RPGLE, not CL program. The RPGLE has around 5000 lines and wouldnt be feasible to share entire code. Further, there are 8-10 programs getting executed in the middle. 

    Anything in particular you want me to check here?
    645 pointsBadges:
    report
  • rmb0707
    I was also thinking about the call level.  I assume the Override and the Delete Override command are done in the same program?
    135 pointsBadges:
    report
  • ToddN2000
    A bit tricky to manage all the overrides inside an RPG. Is the program  with the multiple subsequent calls run in batch mode or interactively? It may determine if the DLTOVR is even needed. If the file being overridden is ALWAYS going to be overridden to the same file in the job stream, why not do the override outside the RPG in a CL program? 
    135,495 pointsBadges:
    report
  • sri8707
    Hi rmb0707, no. Override happens in program1 and dltovr happens in program 7/8.

    When overriding is completed in pgm1, below is the details obtained by shift+esc-3-option15.

    File  . . . . . . . . . . . . . . :   File1
    Call level  . . . . . . . . . . . :   11                        
    Merged  . . . . . . . . . . . . . :   *NO                       
                                                                    
                                          Keyword     Value         
    File being overridden . . . . . . :   FILE        FILE1
    Overriding to data base file  . . :   TOFILE      FILE1
    Library . . . . . . . . . . . . . :               TEST         
    Maximum record wait time  . . . . :   WAITRCD     2             
    Secure from other overrides . . . :   SECURE      *YES          
    Share open data path  . . . . . . :   SHARE       *NO           

    I check the above again before DLTOVR command is executed, and it looks the same. But, DLTOVR command crashes.


    645 pointsBadges:
    report
  • sri8707
    Hi All, additionally i found that OVRDBF is specified one more time in another program. So, overall this is the flow -

    Program1 (RPGLE) - OVRDBF FILE OVRSCOPE(*CALLLVL)
    Program2 to Program7 performs some operations
    Program8 (RPGLE) - OVRDBF FILE and DLTOVR FILE

    This is the call stack. This works fine for some instances but fails with "override not valid at specified level" for other instances. I am not able to find exact scenario. I can handle DLTOVR within MONITOR block to handle this. But, any other way?
    645 pointsBadges:
    report
  • GregManzo
    The scope on the OVRDBF & DLTOVR need to match. Would it be feasible to change both the OVRDBF & DLTOVR to OVRSCOPE(*JOB) ?
    2,970 pointsBadges:
    report
  • sri8707
    In the last SQLRPGLE program, i can change override to *JOB. But, do you mean, even the initial RPGLE program needs to have it as *JOB?
    645 pointsBadges:
    report
  • ToddN2000
    I would say if program 8 is doing it's own OVRDBF ans DLTOVR then move your DLTOVR after the program 7 call.  You may be trying to remove the override that program 8 does if it was called in the main process depending on how it's override was configured.
    135,495 pointsBadges:
    report
  • sri8707
    Thanks ToddN2000. I will consider it. One final query - What if i just add a MONITOR block for DLTOVR in my last program? Any problems you see with that? 
    645 pointsBadges:
    report
  • ToddN2000
    Not sure on the monitor. In my 30+ years of coding, I never used a monitor in an RPG program. I did a quick search and found this link. It looks fairly simple enough.  For about the last 8 years I now code mainly in VB / SQL for web services that integrate to our RPG system for the same company. check it out if you are not sure. 
    135,495 pointsBadges:
    report
  • sri8707
    Thanks again Todd. This was a peculiar case, and still i couldnt trace out the exact reason for the error with DLTOVR.  I too dont use MONITOR that often in RPGLE, but was wondering if it makes sense in this case. 

    I have added OVRDBF with scope as CALLLVL and DLTOVR with LVL as * in my last SQLRPGLE program. Looks ok at the moment.
    645 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: