Barbara, I use ADCD all time we had 1.10 up through 1.13 on z/Pdt. Ours wasn't customized per se,we did it ourselves, actually I had to do it. Did you system come pre-configured ? It sounds like it did. Sorry your having such problems.
Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Dec 31, 2012, at 3:49 AM, ibmmain <nitz-...@gmx.net> wrote: >> 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
