Scott,
Has this something to do with fact my trigger program is compiled with
ACTGRP *CALLER.
Stevie
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: 07 January 2009 11:44
To: RPG programming on the IBM i / System i
Subject: 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?
midrange.com
