Re: RPG400-L digest, Vol 1 #962 - 9 msgs

[Ken Sims <mr2087@xxxxxxxxx>]

Hi Buck -

> >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.
>
>What criteria do you use to determine if the AG should be *NEW or *CALLER?

I have gotten a lot more aggressive in using *NEW than when I first started
using ILE functions.  Now my rules basically are:
1. service program = *CALLER
2. API type program = *CALLER
3. program called repeatedly or only from programs running in *NEW = *CALLER
4. about everything else = *NEW

This is for RPG only.  Other than the one ILE CL module that I have bound
into a service program, I don't see a need for ILE CL.

>Perfect example of a mixed environment!  I'm pretty sure that if the OPNQRYF
>is issued by OPM you need to OPNSCOPE(*JOB) in order to see the open in ILE.
>That's regardless of OVRDBF SHARE(*YES).  So in this case, the ILE solution
>would be to put the CL in the same AG as the ILE parent, and have the
>service program in it's own AG.  I need to test it to be certain, but I'm
>pretty sure I've encountered this.

You have hit on the one big disadvantage of non-ILE CL, that OPNQRYF opens
don't carry.  Since OVRDBFs do carry from the default activation group to a
*NEW activation group, I think it was a poor decision to make opens not
carry, but IBM isn't going to change it now.

For this we either use *CALLER for the RPG or OPNSCOPE(*JOB) on the
OPNQRYF.  I started with the *CALLER method but have since changed over to
the OPNSCOPE(*JOB) method and using *NEW for the RPG program.

Granted, using non-ILE CLs with *NEW RPGs does mean for a batch job that
has a CL that calls ten different ILE RPG programs with *NEW that ten
activation groups are created and destroyed, but with the fast machines of
today this is negligible.  Who cares if a batch job takes an extra second
or two to run.  And quite frankly, I'd rather have the cleanup for each
individual RPG program.

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