On Thu, 28 Apr 2016 12:01:17 -0500, Mark Zelden wrote: >I'm applying z/OS 2.1 RSU1603 and came across this PTF. Is anyone running >with >it in production and has it caused you any grief? This seems to change a >behavior >that has been around "forever", so it concerns me a bit even though there >is a work around by defining a special RACF profile in the Facility class.
Ok, I finally looked at the actual HOLDDATA in PTF UA80147, the z/OS 2.2 PTF for OA49446. This PTF does not change the way access to a data set is granted when it an alias is used. It changes the access required to define the alias. The old way, which surprises me a little, DEFINE ALIAS required access to the data set to which the alias is related, but not to the alias name being defined. So, for example, if I have a data set TOM.DATA.SET, I can create an alias called FRED.DATA.SET, even though I do not have authority to create FRED data sets. The new code does not allow me to do that, because I do not have ALTER access to FRED.DATA.SET. OTOH, if I want to create alias TOM.DATA.SET that relates to FRED.DATA SET, I can do that because I have alter access to TOM.DATA.SET. However, that does not change the fact that when I try to access FRED.DATA.SET using my new alias, the access that is checked is to FRED.DATA.SET, so my access will fail. Without the PTF, if I am reading it correctly, there is no checking when defining an alias for a non-vsam data set. I can define either of the above aliases. I don't have a system without the PTF applied, so I can't test this. For DEFINE ALTERNATEINDEX and DEFINE PATH, it is a little different. The existing code checks for ALTER access to the cluster name for the DEFINE. The new code requires ALTER access to the new entry name (the PATH or AIX name). This is NOT a RACF PTF. It is a PTF to HDZ2220, DFSMS. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
