Scott,
Hope you can still comment on this. I went with the approach that you
suggested below and everything worked fine until ...
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 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 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.
Thanks Stevie
Example code from trigger
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))
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: 16 December 2008 22:48
To: RPG programming on the IBM i / System i
Subject: Re: Trigger program - open / close file question
Stephen,
IMHO, the SHARE(*YES) is the part you're doing wrong. I would suggest
that you revisit SHARE(*YES) and really give some thought as to whether
it should or should not be enabled. Personally, I never use it, as I
don't *WANT* all of my programs to share the same ODP! It totally
destroys any hope of encapsulation. Now you can't make a change to any
program that uses your CTRFILE without re-testing it in conjunction with
every single program that uses CTRFILE -- otherwise you run the risk of
breaking stuff.
Sure, SHARE(*YES) offered a minor performance improvement. One that was
useful in the 1980's, and perhaps is useful once in a very great while
in today's applications -- but that's the exception, not the rule! In
most cases it does more harm than good. Furthermore, the majority of
folks I've found using SHARE(*YES) don't even really understand what it
does, and are using it do to some false assumption (like "if I don't use
share(*yes) other people can't use the file" -- bzzzt WRONG!)
In a trigger program, in particular, I'd say never, ever, ever, use
SHARE(*YES). Think about it... the program that updates/writes a file
has to KNOW that it's open data path on one file might be modified by
accessing a completely different file??? YUCK. That's just horrible
coding, fraught with unseen errors that are hard to test for.
So, my recommendation is that you take a hard look at whether you need
SHARE(*YES), and try to eliminate it EVERYWHERE.
If you really can't do that, then I suggest forcing it to be turned off
in the trigger, using OVRDBF SHARE(*NO) SECURE(*YES) OVRSCOPE(*CALLLVL),
then OPEN, then DLTOVR. Delete the override immediately after the
OPEN to guarantee it doesn't affect anyone else.
Brown, Stephen GRNRC wrote:
Yep SHARE(*YES) defined on logicals on CTRFiles.
midrange.com
