RE: Activation Groups 102, the plot thickens....

>> While that seems desirable at first blush,
>> look at the  default value for OPNQRYF:
>> OPNSCOPE(*ACTGRPDFN).  This is exactly the
>> same default as OVRDBF, and has virtually
>> the same help text wording.
>
>But it isn't the _same_ default.  Any more than
>a default of *LIBL always means the exact same
>library list.  The option *ACTGRPDFN has
>no meaning in and of itself.

Good point Jon, but:

>It means - in all cases - "the default depends
>on where the command is issued".  If you look
>at the options for OPNQRYF there is no Call
>level option as such.  Only Job and AG scope.
>The only way to get call level is when the command
>is issued in the default.

Yes, and that's that I'm doing.  I have an OPM CL doing the OVRDBF
SHARE(*YES) and the OPNQRYF - this code hasn't changed at all (that'll be
important later <grin>.)  Then it calls an ILE RPG running in a named group.
The override (issued in the DAG) percolates to the ILE program.  The shared
open (also issued in the DAG) does not percolate.  Same parameter, same
program; different behaviour.

>When this stuff was being designed, the objective
>was to make it transparent to existing programs.
>That was the whole rationale behind the
>*ACTGRPDFN option.

And AMEN to that!  That's what makes this so puzzling.  I would have
expected the shared open to percolate from DAG to NAG, like the override.
That would have made a transitional 'mixed mode' OPM and ILE environment
easier to deal with when using OPNQRYF.

>I think (but can't remember for certain) that one of
>the reasons why call level wasn't supported for OPNQRYF
>was that scoping had always been a major problem with
>the command (i.e. a major cause of support calls) and
>making an expensive change to OPNQRYF to further support
>a problem area wasn't considered a good idea.

Well, it's certain that you can't please everyone!  But I thought I
understood the rules for *ACTGRPDFN.  The CL manual at:
http://publib.boulder.ibm.com/pubs/html/as400/v5r1/ic2924/info/cl/opnqryf.ht
m says:

"OPNSCOPE Specifies the extent of influence
 (scope) of the open operation.

 *ACTGRPDFN: The scope of the open operation
 is determined by the activation group of the program
 that called the OPNQRYF command processing program.

 If the activation group is the default activation group,
 the scope is the call level of the system program
 performing the open operation. If the activation
 group is a non-default activation group, the scope
 is that activation group. In a multi-threaded job,
 only those opens within the same thread and within
 the same activation group can share this ODP."

And OVRDBF's OVRSCOPE:
"OVRSCOPE Specifies the extent of
 influence (scope) of the override.

 *ACTGRPDFN: The scope of the override
 is determined by the activation group
 of the program that calls this command.

 When the activation group is the default
 activation group, the scope equals the
 call level of the calling program. When
 the activation group is not the default
 activation group, the scope equals the
 activation group of the calling program."

So I agree that the documentation says the same thing as you - that the
scope depends on where the command was issued.  What I don't understand is
why that differs between OVRDBF and OPNQRYF issued in the same OPM CL, same
job, same everything.  I'm not comparing two programs running in two jobs (a
la *LIBL reference above.)  Just as I expect *LIBL to be the same for those
two commands issued one after the other, I would expect the scoping rules to
be the same, but it's not.

I hope I didn't muddy things too terribly much.
  --buck