On Sun, Dec 15, 2013 at 4:24 AM, venkat kulkarni <[email protected] > wrote:
> Hello, > We have 3 system in plex and out of three systems, two are > running with z/OS 1.11 and one with z/OS 1.13. commands ( whoami ,id ) > running on z/OS 1.11 running fine but on z/OS 1.13 system OMVS, these > command giving bad output. > > <snip> Based just on the above, is the z/OS 1.13 system in the same GRSplex as the other systems? Why? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza2c0/4.9 <quote> If your shared RACF database is at application identity mapping (*AIM*)level 1 or higher, all systems that update the OMVS segment of USER or GROUP profiles, or update the ALIAS segment of general resource profiles (for example, any SERVAUTH class profile), or run RACF utilities, should have global resource serialization connections between the systems, should be in the same global resource serialization complex, and should be running OS/390 release 10 or any z/OS release. Adding or deleting a profile that has any of these segments, altering these segments, or running RACF utilities from a system outside the global resource serialization complex might result in incorrect results; for example, an alias index entry for an OMVS UID or SERVAUTH alias might point to the wrong profile, or to one that does not exist. To prevent database sharing errors, it might be useful to use RACF program control to restrict access to all RACF commands that can update these segments, to ensure that they cannot be used from systems outside a single global resource serialization complex. </quote> Also, I found a "curious" phrase here, towards the bottom of the page : http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza7c0/17.2.1 <quote> For installations at *AIM* stage 2 or higher, you can list a set of users or groups with a specific UID or GID, for example using '223' for the UID value and '55' for the GID value, enter: SEARCH CLASS(USER) UID(223) SEARCH CLASS(GROUP) GID(55) </quote> This is in the z/OS 1.13 manual. And it says that you can do a SEARCH for a UID or GID at AIM level 2 or higher. But does not mention exactly what happens at AIM 1 (your level) or lower. I wonder it the z/OS UNIX command you are using has a similar restriction. I don't know. I'm still looking. Looking in the UNIX manuals, I would _guess_ that these commands use the UNIX program, BPX1GPU, to get the information. This, in turn, uses the RACF callable service IRRSUM00 (aka GetUMAP). If this has some problem, it writes a LOGREC record, per http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichzb2c0/2.4.1 . If worse comes to worse, you might want to dump and print an EREP report quickly after a failure to see if RACF has written any error information. I can't really figure out exactly what the problem is. But I will say that it would be __extremely advantageous__ for you to see about upgrading your RACF database from AIM 1 to AIM 3. Most of the new facilities and "speed ups", especially in UNIX, require an AIM level of 3. It was very easy for me. But that's because I had a very well controlled UNIX environment and few users when I went from AIM 0 to AIM 3. It only took me about 3 weeks, and that was only because I wanted to got to AIM level "n", then wait a week, before going to AIM level "n+1". I have no problem occur due to this. -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
