Re: Trigger program - open / close file question

Hi Stephen,

We have another application however that updates / writes to the file
with the associated trigger program. This application is separate from
our main system but does reference some of the files. This application
is build over a service program / activation group.

I don't understand what that has to do with the problem? You aren't doing the override (the one you show in the code sample below) in the service program, are you? That code SHOULD be in the trigger, not the service program.

There's no difference between the way a service program opens a file and the way a program opens a file, with the possible exception of timing. (Most srvpgms I've worked with open files when a certain procedure is called, whereas most programs open files automatically when they start... so the timing is different...)

I can't see why that timing would matter to your trigger -- unless of course the override isn't happening in the trigger as it's supposed to.

I seem to be getting an issue with the override I am setting in the
trigger, specifically the level that it is being set at (OVRDBF not
being set then the DLTOVR fails). I need this override to work for
standard OPM RPG programs and ones that run within the specific
activation group.

I don't understand. If the override is in the trigger it makes no sense for you to say it has to work with both OPM and ILE. After all, it's only affecting the trigger, right? And the trigger can't possibly be written in multiple languages, can it?

However, *CALLLVL should work fine -- in fact, that's what I'd recommend, because the override should apply only to the trigger, NOT to the whole activation group or to the whole job! So *CALLLVL is the right choice. The question is, why is the DLTOVR failing? Either the override was already deleted, or the OVRDBF is at a different call level than the DLTOVR.

I know I can change the OVRSCOPE to *ACTGRPDFN but I am not sure if
this will cause me further issues or if there is a better way.
Alternatively I can also use the error extension of the callp on the
ovrdbf and dltovr. Any pointers for me.

I would definitely stick with *CALLLVL. I would investigate further to see why the DLTOVR is failing. Verify that the override has been run successfully, and that the call stack entry containing the ovrdbf hasn't ended, and that the dltovr is issued at the same call stack level.

Eval wCmd = %Trim('OVRDBF File(HSCTLL) ' + 'SHARE(*NO) Secure(*Yes) ' + 'OVRSCOPE(*CALLLVL) ') CallP qCmdExc(wCmd : %Len(wCmd)) If not %Open(HSCTLL) Open HSCTLL Endif Eval wCmd = %Trim('DLTOVR File(HSCTLL)') CallP qCmdExc(wCmd : %Len(wCmd))

Is the OVRDBF and DLTOVR really back-to-back in the same routine, as you've shown here? If it is, then I really don't understand how the DLTOVR could fail! Or, in reality, are the OVRDBF and DLTOVR in separate procedures?