> We're talking about an end of task/AS resource manager module. I would have > expected this module to be placed in LPA not LinkLib. After all, it is loaded > for each terminating task. The ADCD developers in their infinite wisdom decided to put an obsolete usermod into ADCD.*.linklib.
> Without the possibility to check anything on the old system, it is very > difficult to prove the real cause. Anyway, I dare to say that if only a > superuser can traverse any path in the file system, then the only meaningful > explanation is that the root directory has the permission wrong, e.g. 700. Again, I blame the ADCD developers if they give out a system like that. But I think the root is defined right: EUID=5001 / Type Perm Permission Changed-CST6CDT Owner ------Size Filename _ Dir 755 rwxr-xr-x 2012-12-17 04:23 OMVSUS2 8192 . _ Dir 755 rwxr-xr-x 2012-12-17 04:23 OMVSUS2 8192 .. _ Dir 755 rwxr-xr-x 2011-11-03 08:56 OMVSUS2 8192 ... OMVSUS2 is uid(0). > >That is a design change between 1.10 and 1.13. > No, not at all. This has always been so. It was certainly different on the 1.10 system. I explicitly tested this on the 1.10 system because it took me a while to understand. And yes, I did read the book. And the root display at 1.10 looked identical to this one. In the 1.10 system permissions for the mount point did not change after I had mounted an HFS. > You should really make sure you're z/OS UNIX is setup correctly. Sorry Peter, you're barking up the wrong tree. I agree, it should be set up correctly. But this is a productive system and I have no way of testing in a safe environment, so now that 'everything works' I will not change things and possibly break something. The 'correct setup' should have come with the ADCD system. But judging from the things alone that I found, the delivered ADCD setup breaks just about every best practise IBM spend money to propagate. >Again, the above mentioned books is worth reading. I did read. Admittedly, mostly the relevant parts in a bid to understand why things didn't work anymore. That's how I determined that I need to delete the BPX.DAEMON profile to make ftp work again. Asking about it here (and eventually finding where DFSMRCL0 is located) helped me when I had to get RDz running. Which insisted on a program-controlled environment despite BPX.DAEMON not being defined. According to the books and your explanation, the need for a program-controlled environment should not have been there. This was true for ftp, but not for RDz. > I understand that an MVS guy or girl may hate UNIX but, there is no way > around getting a thorough understanding of it. It has long become an integral > part of z/OS. Both, the above mentioned manual, and the corresponding User's > Guide can help. I already know more about UNIX than I ever wanted to know. And believe me, I do read the books IBM provides. I still hate it because it feels fairly inconsistent. In any case, have a happy new year! Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
