John, > 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. Well, that the open failed took me by surprise completely. It doesn't fail on the other system that is (almost) identical. There is certainly no access allowed on that system for the ZFS userid. In addition, nothing in the IBM installation docs for z/OS says to authorize the ZFS address space to the data set profiles for the ZFS that are explicitly defined by their customization (and their RACF job goes into ridiculous detail to make sure everything is covered). So it must be something else that causes this 'requirement' on my current system.
Is the rest of the world routinely defining at least READ access for the ZFS userid to each and every ZFS dataset that might get mounted? > 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. Believe it or not, I did a setropts refresh. And got an error on it (Invalid command or some such). I probably did not use the right incantation for the refresh. I'll put this into my store of RACF commands, to be taken out in future! Thanks. Peter, >Barbara, it took you some time to compose this reply. Bear with me, I'll need some, too. The reason it took some was 1. Thursday was a public holiday in most of Germany, so I took a day off. :-) 2. I had to do the migration of our user data from the old system (you know, where the mount worked) to the new system, and that was scheduled for this Friday, since almost no one was needing z/OS today. Given that deadline, following up on a problem that bugs me but is more or less 'solved' didn't have priority. 3. I can always be counted upon to fly into a rant against OMVS at the drop of a pin. Or hat. :-) But thanks for trying to puzzle this out with me. Now that the migration is behind me, I seem to remember that *I* deleted the BPX.DAEMON profile (on the system where it works without explicit access) back when we migrated from 1.10 to 1.13. In that case, ftp on the 1.13 system didn't work, and I had another incomprehensible error message. I got that to work by deleting the bpx.daemon profile (don't ask me why I did that - some convoluted thinking on my part after spending a long afternoon with the USS Planning manual.) In the same vein, the read access to bpx.superuser for OMVSUS2 was probably the result of that 'ftp error', too, when we did trial and error to get it to work. Since I am normally religiously keeping track of every RACF command ever issued against my data base (in case I have to rebuild it), I must not have been religious enough when we attempted to solve the puzzle, so that slipped by me and didn't make it to the new system. Best regards, Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
