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.