On 2/8/11 5:42 AM, John Earl wrote:
On Feb 7, 2011, at 2:37 PM, CRPence wrote:
A SWAG... is that POSIX standards are the fault for the difference
in requirements. IIRC the object [operational] authority *OBJOPR
enables viewing\accessing the data rights [data authority] to the
object natively, which is the first requirement of *USE since that
object right must exist to even know\test of any data rights. The
object [management] authority *OBJMGT as a requirement for
displaying authority via an IFS [non-native naming] API is
presumably an attempt to mimic similar limitations that would be
imposed on a *nix system.?
This SWAG matches my experience - and kind of tracks with the way a
CRTDUPOBJ command works. You'll notice that you can CPYF a file with
just *USE, but you must have *USE + *OBJMGT in order to CRTDUPOBJ.
This is (at least in part) because CRTDUPOBJ must access the security
authorization description part of the file in order to completely
duplicate the object and a CPYF does not (because it does not
duplicate the authorities to the new file).
FWiW there was actually a "requirement" that for the effect of CPYF
CRTFILE(*YES) [and I think CPYFRMQRYF as well; from the first file named
in the OPNQRYF], the object authorities should be duplicated from the
FROMFILE just as how the existing authorities are duplicated from the
OBJ() to the NEWOBJ() on a CRTDUPOBJ request. I recall arguing against
that for a variety of reasons [since the intent is so easily defeated],
but as I recall the change was made long ago such that the authorities
were copied. Thus I expect you will find the authorities are indeed
being transferred\duplicated from the FROMFILE() to the TOFILE() when
the CRTFILE(*YES) actually effects a[n effective] CRTPF.
I believe several releases later a new requirement [reported as a
defect IIRC; I did not search for an APAR on the IBM site] came about to
prevent the CPYF from copying a file when the requesting user had no
ability [lacking the authority] to assign a private authority to another
user due to the current user [or its group profile] having become the
owner. With the prior revision to the CPYF, the granting of authority
had all been done via adopted authority, so a CRTDUPOBJ that would fail
would still complete using CPYF [and depending on the parameters
specified, be _equivalent_ to the CRTDUPOBJ]; effectively only the
ability to "read" the data and to create the target file were used as
the authority criteria to perform the copy, without any regard to the
ability to assign the authorities.
I do not recall the outcome from that scenario, being an "I told you
so" moment, I could best argue for continued use of adopted authority so
as to avoid rehashing the same arguments against ever having made the
earlier change to the CPYF [to duplicate the authorities]. I really
doubt that the outcome was a change to require *OBJMGT for the user on
the FROMFILE() for when creating a new file was the effect, but if it
had been, surely there would have been an entry in a MTU for having
changed the behavior such that copy file requests that had been working
since the S/38 would start failing. Avoiding that outcome of breaking
existing code, was the reason adopted authority was used to implement
the first change.
Regards, Chuck
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.