OVRDBF in ILE (was: diff btw Procedures and Routines)

Hi Ken!  Good to hear from you again.  You have an interesting arrangement:

>All of my service programs run in *CALLER, which
>is either the default activation group or a *NEW
>activation group.

This sounds like a menu system where each option relates to a different
application, like 1=A/R, 2=G/L and so on.  Each option spawns a *NEW AG and
every program downstream inherits that with AG(*CALLER).

>I make all files in service programs to be
>USROPN and do an override with SECURE(*YES)
>and SHARE(*NO) to make sure that I don't end up
>inadvertantly sharing an open data path.

Respectfully, this sounds like overkill unless you have had several
programmers in your business with very different philosophies.  As you no
doubt know, the default behaviour is for each RPG program to open it's own
ODP unless explicitly told otherwise by OVRDBF or a SHARE(*YES) attribute on
the file itself.  So it sounds like some programmers are sharing ODPs while
others don't.

I only bring this up so that beginners understand that this is not
considered a typical environment, and that SECURE(*YES) is really more of an
'exception' than the rule.  Overrides in general are supposed to work from
the outside-in.  That is, the innermost override is NOT supposed to take
precedence to an outer override (which is what SECURE(*YES) does.)  I'll be
more than happy to continue this discussion if there's any interest, but in
the interest of list harmony I'll shut up now... <grin>

>I delete the override immediately after opening
>the file since it is no longer needed once the
>file is open and thus it doesn't clutter up the
>job's override list.

Another cautious move.  I have not seen performance implications from
leaving overrides, but it sounds like your environment may have had
programmers neglect to check for overrides before opening files (say in
another program farther downstream.)

This was a very interesting post; I'm a bit surprised that nobody else
chipped in.  Thanks Ken!
  --buck