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