> 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
