Re: Trigger program - open / close file question

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

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?