|
Oops. And I forgot to mention a critical point - overrides are applied at the time the file is opened, not when they are issued. Gary Gary Guthrie wrote: > > 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. > _______________________________________________ > 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
