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

[Ken Sims <mr2087@xxxxxxxxx>]

Hi Buck -

> >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).

Nope, nothing like that! <G>  We are running a hybrid mix of two different
software packages plus home-grown.  Though a lot of it is RPG IV, there was
only one program that was not DFTACTGRP(*YES) until I started using ILE
functions.

We use ILE CL very minimally, but all of my new RPG IV is ILE, either *NEW
or *CALLER, and I try to encourage the other programmers to do the same.  I
have H-spec /COPY members to make it easy.

> >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.

With one or two exceptions, all of the SHARE(*YES) is related to
OPNQRYFs.  But we do have a lot of that.  For example, a lot of my service
programs use our item master file.  There are also a lot of OPNQRYFs over
the item master.  If I didn't protect the files in my service programs from
sharing, it could cause a lot of "unpredictable results".

>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>

True as a rule but service programs, being "black boxes", are an exception.

> >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.)

It's not a performance implication nor to protect downstream programs.  (My
service programs only make dynamic calls to system programs, not to other
user programs.  They do make calls to procedures in other service programs,
but those service programs are responsible for their own ODPs.)  It's so
that looking at overrides via DSPJOB/WRKJOB doesn't have the service
program overrides to confuse other programmers who wouldn't necessarily
understand why they're there.  And so that I don't have to wade through
them myself either.  Some of my service programs open a lot of files.

Ken
Opinions expressed are my own and do not necessarily represent the views of
my employer or anyone in their right mind.