OVRMSGF does not have OVRSCOPE -- MIDRANGE-L

Just to clarify a bit, here's the call stack just after PgmC does the call to QCMDEXC to OVRMSGF:

                          ------Activation Group------ Control
Program                  Name        Number Boundary
QCMD       QSYS          *DFTACTGRP 0000000000000001 Yes
INITC      GLCONVERT     *DFTACTGRP 0000000000000002 No
MNUDVRC    RMSMM##       *DFTACTGRP 0000000000000002 No
FX0010     RMSMM##       *DFTACTGRP 0000000000000002 No
FX0015     RMSMM##       *DFTACTGRP 0000000000000002 No
QCAEXEC    QSYS          *DFTACTGRP 0000000000000001 No
PGM1       GLCONVERT     *NEW        0000000000000016 Yes
PGM1       GLCONVERT     *NEW        0000000000000016 No
PGM2       GLCONVERT     *NEW        0000000000000016 No
PGM2       GLCONVERT     *NEW        0000000000000016 No
PGMA       GLCONVERT     *NEW        0000000000000016 No
PGMA       GLCONVERT     *NEW        0000000000000016 No
PGMC     GLCONVERT     *NEW        0000000000000016 No
PGMC     GLCONVERT     *NEW        0000000000000016 No
PGMC     GLCONVERT     *NEW        0000000000000016 No
QTEVIREF   QSYS          *DFTACTGRP 0000000000000001 No
QTESTOPH   QSYS          QTEDBGAG    0000000000000015 Yes
QTESTOPH   QSYS          QTEDBGAG    0000000000000015 No
QTENPTS    QSYS          QTEDBGAG    0000000000000015 No
QTENPTS    QSYS          QTEDBGAG    0000000000000015 No
QUIDSPP    QSYS          *DFTACTGRP 0000000000000001 No
QUIMGFLW   QSYS          *DFTACTGRP 0000000000000001 No
QUIEXFMT   QSYS          *DFTACTGRP 0000000000000001 No
QUIINMGR   QSYS          *DFTACTGRP 0000000000000001 No
QWSGET     QSYS          *DFTACTGRP 0000000000000001 No
QT3REQIO   QSYS          *DFTACTGRP 0000000000000001 No
QWTSEATN   QSYS          *DFTACTGRP 0000000000000001 No
QCMD       QSYS          *DFTACTGRP 0000000000000001 No

Here's the call stack at the time the CPF9841 error has been displayed but not responded to:

                          ------Activation Group------ Control
Program                  Name        Number Boundary
QCMD       QSYS          *DFTACTGRP 0000000000000001 Yes
INITC      GLCONVERT     *DFTACTGRP 0000000000000002 No
MNUDVRC    RMSMM##       *DFTACTGRP 0000000000000002 No
FX0010     RMSMM##       *DFTACTGRP 0000000000000002 No
FX0015     RMSMM##       *DFTACTGRP 0000000000000002 No
QCAEXEC    QSYS          *DFTACTGRP 0000000000000001 No
PGM1       GLCONVERT     *NEW        0000000000000016 Yes
PGM1       GLCONVERT     *NEW        0000000000000016 No
PGM2       GLCONVERT     *NEW        0000000000000016 No
PGM2       GLCONVERT     *NEW        0000000000000016 No
PGMA       GLCONVERT     *NEW        0000000000000016 No
PGMA       GLCONVERT     *NEW        0000000000000016 No
PGMC     GLCONVERT     *NEW        0000000000000016 No
PGMC     GLCONVERT     *NEW        0000000000000016 No
PGMC     GLCONVERT     *NEW        0000000000000016 No <== here's where QCMDEXC was called to do the DLTOVR
QMHPDEH    QSYS          *DFTACTGRP 0000000000000001 No
QMHUNMSG   QSYS          *DFTACTGRP 0000000000000001 No
QTEMDEBP   QSYS          *DFTACTGRP 0000000000000001 No
QTESTOPH   QSYS          QTEDBGAG    0000000000000015 Yes
QTESTOPH   QSYS          QTEDBGAG    0000000000000015 No
QTENPTS    QSYS          QTEDBGAG    0000000000000015 No
QTENPTS    QSYS          QTEDBGAG    0000000000000015 No
QUIDSPP    QSYS          *DFTACTGRP 0000000000000001 No
QUIMGFLW   QSYS          *DFTACTGRP 0000000000000001 No
QUIEXFMT   QSYS          *DFTACTGRP 0000000000000001 No
QUIINMGR   QSYS          *DFTACTGRP 0000000000000001 No
QWSGET     QSYS          *DFTACTGRP 0000000000000001 No
QT3REQIO   QSYS          *DFTACTGRP 0000000000000001 No
QWTSEATN   QSYS          *DFTACTGRP 0000000000000001 No
QCMD       QSYS          *DFTACTGRP 0000000000000001 No

All the call levels (under the Type column of the call stack display) are blank ("Blank = OPM or ILE invocation that is not a request processor.") which is why I didn't show it.

And the DSPJOB option 15 overrides shows:

File          Level   Type Keyword Specifications
QUSERMSG         15   MSG   TOMSGF(*LIBL/MLMESG)

The level of the override (as shown in DSPJOB option 15) appears to match the "Number" of the activation group, and when they are different (as in the above call stack) is when the DLTOVR fails.

So really the question boils down to - why is the activation group number / override level different when PgmA calls PgmC than when PgmB calls PgmC, all other things being equal? And in both cases, PgmC is the one doing both the OVRMSGF and DLTOVR via calls to QCMDEXC.

This has become a curiosity question rather than a need-to-know question. We will sidestep the problem by merging the message files and eliminating the OVRMSGF and DLTOVR.

-----

Here's a fun one.

On a v5r4 system, a procedure within an RPGLE program PgmC calls QCMDEXC to do an OVRMSGF followed by some processing then a call to QCMDEXC to do a DLTOVR of the same message file.

When PgmA calls PgmC, it works fine.

When PgmB calls PgmC, the DLTOVR fails with CPF9841 Override not found at specified level.

All 3 programs, PgmA, PgmB, and PgmC, are RPGLE programs with ACTGRP(*CALLER).

At the time of the error, the call stack shows that all 3 programs are in Activate Group *NEW number 0000000000000016. Stepping through with debug shows that no other program is called between the OVRMSGF and the DLTOVR.

The usual recommendation is to put OVRSCOPE(*JOB) on the OVR* command and LVL(*JOB) on the DLTOVR. However, at v5r4 and v7r3, the OVRMSGF command does not have the OVRSCOPE parameter.

Another possibility was that something else had deleted the override prior to the DLTOVR in question. Doing a DSPJOB option 15 to display overrides when the error occurs shows the override still exists.

Anyone have any ideas?

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>
pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx> /

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus