Re: Trigger program - open / close file question

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

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.