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

Buck,

You're confused because you're overlooking the fact that OpnQryF OPENS
the file itself! It is that open that the scoping information relates
to, not the open in the RPG program.

Put your CL in break mode and before executing the OpnQryF, issue DspJob
and look at open files. You'll see the file is not open. Also, set a
break point immediately after executing OpnQryF and before calling RPG,
and you'll see the file IS OPEN. Set a break point in RPG and DspJob and
you'll see 2 ODPs.

Gary Guthrie
Senior Technical Editor, iSeries NEWS



Buck Calabro wrote:
>
> >> 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
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.