I _think_ your RACF problem was due to the fact that the first time the ZFS address space tried to open the VSAM file, it didn't have correct RACF access. So the open failed, as I would hope it would. This is like a CICS region doing the same type of thing. Now, in order to be efficient, RACF caches this result in the address space (IIRC, it caches the RACF rule it found). You then changed/created a RACF access profile so that the ZFS address space could open the data set. But the previous results are still cached. At this point, what should you do to invalidate the cache? You issue the RACF command: SETROPTS GENERIC(DATASET) REFRESH . Is this documented in a way that a mere mortal can understand? Of course not! How do I know? Walt (not a mere mortal, but an IBMer who worked on RACF internals) told me.
And you can read a 3rd party on this here: http://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__October_2008.pdf <quote> If a user does not have sufficient authority to access a dataset and a RACF administrator permits higher access to the associated profile while the user is logged on, the user may still not be able to access the dataset. RACF continues to use the prior copy of the profile in memory and not the updated profile on the database. To acquire the new permission, the copy of the profile in memory must be refreshed. One way to refresh the profile is to execute SETROPTS GENERIC(DATASET) REFRESH. This command causes RACF to discard all saved dataset profiles for every user. RACF then has to retrieve all the profiles again. We have encountered several sites where RACF administrators routinely issued this command every time they executed ADDSD or ALTDSD and have since ceased doing so on our advice. </quote> On Fri, May 31, 2013 at 5:51 AM, nitz-...@gmx.net <nitz-...@gmx.net> wrote: >> Barbara, I know you're not z/OS UNIX's biggest fan, however, this time >> the problem is related to the authorization to perform an "MVS OPEN" >> against an MVS data set. UNIX is only inside the data set. > I beg to differ. The UNIX implementation has clouded itself in such a bunch > of things - nothing is easy with anything OMVS-related. > > I am running in the *OMVS* shell, and the actual open is relegated to the ZFS > address space. That takes some getting used to, especially when an HFS would > have been opened by OMVS. I don't get a nice, understandable abend913, no, I > get a strange error number that doesn't tell me that there was/is a RACF > problem. Instead I am told: > Description: Error LOCATEing an HFS-compat aggregate. > Action: Ensure that the zFS file system named on the MOUNT command has the > same name as the VSAM Linear Data Set (and the HFS compatibility mode > aggregate) that contains the file system. > > For heavens' sake, I am trying to mount a ZFS, not an HFS! And the name was > specified correctly! > > To top it off, before I first posted, I *had* given the requested access to > that userid. I still was unable to mount the data set, when (nominally) all > RACF requirements were fulfilled. When I eventually restarted ZFS, of course > the shell broke. Actually, every spawn command broke, since the main OMVS > data set is a ZFS, and something didn't synchronize correctly at the restart. > And before you tell me that I should have restarted OMVS, no can do. Without > OMVS, I loose TN3270 and TCPIP, so effectively I have no way of accessing the > system anymore. (Local non-SNA didn't work, either, because a colleague had > pulled the plug on that system on Monday, crashing everything, and we were > unable to establish the remote server to even call the program that would > give me local non-SNA access). > > I was effectively *forced* to IPL the system to get ZFS/OMVS to mount a > filesystem! There is no way I know of that allows me to make ZFS 'forget' > that it ever asked about this specific data set and force it to go back to > RACF to check again fresh. Do you know of a way? (There must be a reason why > one has to logon/logoff whenever the RACF admin provided the access required > before it 'takes' for a TSO user.) > > I think being forced to IPL a system just because a data set profile is > missing is a bit harsh, to put it mildly. That doesn't occur in native z/OS. > Address spaces without OMVS do their own open, data sest access is fairly > straightforward and for a product installed later, the address space would > just terminate on a RACF error. Once the necessary access is provided, just > restart the address space. No IPL required. No contortions required. > > Most of all: For these data sets, I religiously had followed the IBM > recommendation what to define to make it work. I did all definitions that are > required according to the RDT installation manual. These definitions are > identical on both systems. And on one of them it still didn't work! > >> RACF allows the OPEN on your originating system. I trust there must be a >> difference in the setup not related to z/OS UNIX. > No, the only differences in the 2 data bases are obviously the date something > was defined and unix-related stuff. That's it. > >> On your originating system (I guesss you already verified): >> - Does profile MVSR.RDZ.V85.** have UACC(none) or something else? > UACC(NONE) - identical in both systems. > >> - Is OMVSUSR2 defined TRUSTED(NO) and PRIVILEGED(NO)? > TRUSTED(NO), PRIVILEDGED(NO). Identical on both systems. > >> - There is no SCHEDxx entry for BPXVCLNY? > PPT PGMNAME(BPXVCLNY) NOSWAP PRIV SYST NOPASS - identical on both systems. > >> - Nothing else that would allow an MVS OPEN is defined? > I am not sure I understand that question. What do you have in mind? > > I have unloaded and compared both RACF databases. The differences are: > Only on the system it doesn't work, I have BPX.Daemon defined in FACILITY, > with OMVSUS1/2 and another STCUser with READ access. > On the system it works, I have OMVSUS2 defined with READ access to > BPX.SUPERUSER. This definition is missing on the system it doesn't work. On > both systems, OMVSUS2 shares uid(0). The FEKRACF job (RACF customization for > RDT) doesn't touch either of these definitions. > > Having compared this, I guess the bpx.superuser definition makes it work on > one system. Which is quite obvious from the error I got. Right? WRONG! > > Peter, I am not picking on you! Have a great weekend instead! > > Best regards, Barbara > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
