>No, it wasn't. In the old system that usermod was there, too. See below.
Barbara, You mentioned that on your new system, that IMS module was in ADCD.Z113.LINKLIB, right? 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. Can it be that the module was in an LPA library on your previous Z/OS V1.10 system? Or, did you remove any library from the LPA list as part of your customization, and this library contains that IMS module as well? That would explain why ftp had not problem there: All LPA modules are considered to have been loaded from program controlled libraries. >> 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. 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. Assuming that the owner of the root file system is uid=0, then the owner permission (first digit) doesn't matter. An uid=0 process can access any file in the file system not matter permission is set. Assuming the group ownership (gid) of the root file system does not match any of the gids that you get through your group memberships, then the group permission (second digit) doesn't matter as well. You we'll need the be allowed to access the file system as "anyone in the world" (also called "world access"), i.e. the third digit is the one that matters. It must be 5 or 7, or you will be locked out. >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. Yes, this is how this works. I suggest you have a look at the z/OS V1.13 UNIX System Services Planning Guide. Chapter "5.6.4 What happens when file systems are mounted?" >That is a design change between 1.10 and 1.13. No, not at all. This has always been so. >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. You should really make sure you're z/OS UNIX is setup correctly. Again, the above mentioned books is worth reading. It still has some part that are, well, "wrong" IMHO. E.g. documentation on /etc/rc and /etc/inittab customization are still found in a chapter called "8.7 Customizing files for the z/OS **shell**" despite the fact that they have nothing to do with shells. The UNIXPRIV class profiles are there to allow privileged functions to different people in a more granular way than giving them access to uid=0. For a sysprog, I consider it better to permit her/him to BPX.SUPERUSER in class FACILITY *and* to define its userid with a non-zero uid. This way, you can verify your installation from a user's point of view, because you normally work as plain normal user. You can, however switch to (e)uid=0 when needed. Either in ISHELL or in a UNIX shell. 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. Also, there still are two IBM classes on this (OP05 and OP25, I liked to teach those). -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
