> Barbara will have to answer, but I suspect this was the only > difference and the root cause. She didn't realize that module > was in the LPA and even if her previous system was > ADCD it either wasn't included or was removed from > the "default" system. No, it wasn't. In the old system that usermod was there, too. See below.
> I assume you meant SHARED.IDS in the UNIXPRIV class not BPX.SHARED, > right? Yes. > None of the above has anything to do with daemon processing and the > problem you encountered with FTP. I dare to say that all you need to do > is to make sure module DFSMRCL0 (and any other module loaded into FTPs > address spaces) are loaded from a program controlled library. You should > then be safe to define BPX.DAEMON again. And, you don't need to give > your FTP userid any access to BPX.DAEMON. What still confuses me is that BPX.DAEMON comes defined in that ADCD RACF database, DFSMRCL0 is NOT program controlled, and in their setup ftp works. (If I got everything right, then it shouldn't have worked even in their setup due to the missing DFSMRCL0 program control.) I didn't (and still don't) see the difference to my definitions, and with my definitions, ftp did not work until I deleted BPX.DAEMON. I had made the same (RACF) definitions in the 1.10 system, and here my definitions worked for ftp. Same non-programcontrolled, obsolete usermod. I still don't know why they worked in 1.10. On the other hand, RDz should have worked, too, in the 1.13 system, due to bpx.daemon not being defined. RDz did NOT work until I defined DFSMRCL0 to program control. Common denominator for both: Changing the userid/uid once the password is known. > In what respect did it behave differently (except form the DFSMRCL0 > problem you described)? see above. I hate it when I don't know *what* broke it or why it worked when it shouldn't have. > Can it be your root file system had permission 700, which would lock out > anyone except uid=0 processes. No way to see that as that system is gone. All I know is that in the 1.10 system I had to explicitly make myself superuser and get a EUID of 0 to be able to traverse through any file system. If anything, then these permissions are set differently in the 1.13 system. I had mounted a user HFS for which I had defined a mountpoint with 755. Once the HFS was mounted, those permissions reverted to 700, getting me logon errors for TSO (that HFS is supposed to house /u/userautomountpoints). I had to chmod with the HFS mounted to make the thing accessible. That is a design change between 1.10 and 1.13. (I called it IBM forcing the users to go to zFS instead of HFS, with zFS being a real pain to move between non-related lpars. The permission change for the mount point does not happen for zFSs, because they can be formatted with permissions set.) And this did not happen in 1.10. for HFSs. I tested it. In the 1.13 system I can traverse just about anything now *without* being forced into superuser mode and EUID=0, possibly due to my having defined UNIXPRIV/SUPERUSER.FILESYS with READ access for all groups. Again, thanks for taking an interest in my OMVS woes. :-) Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
