Recently I was asked if I knew anything about AIM (Application Identity Mapping), specifically if CMOD was affected by converting to the current level.
A group I worked with was involved in an AIM migration project many moons ago and dug up the following:
http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.icha200%2Fichza2b095.htm
Any database created earlier than OS/390? Release 10 exists in stage 0 automatically until you convert it with IRRIRA00.
A database created in OS/390 Release 10 or later is automatically set to stage 3.
Stick a jobcard on these two lines of JCL and it'll tell you what AIM level your RACF database is in the SYSOUT.
//STEP EXEC PGM=IRRIRA00
//SYSPRINT DD SYSOUT=*
That job when run on our current systems displays this:
IRR66017I The system is currently operating in stage 3.
If you get that RACF is at a level lower than stage 3, you'll probably want to investigate.
Found this in a PMR and thought it was a great write-up. (In other words, don't give me credit for this. ;D )
Let me discuss the issue of file ownership in USS.
This is an issue that can be a little confusing as it
has to deal with how ownership information is stored in USS.
.
Ownership in the USS filesystem is stored as the numeric
UID and GID values. When you do an ls command (or view the file
ownership in ISHELL), for each file a SAF EXTRACT is done to
RACF to map the numeric UID (or GID) to a RACF userid or groupname.
.
When the owner UID of a file is 0 (or is a UID that is defined
to more then one userid), this can create some ambiguity in the UID
to userid resolution.
.
What happens when the SAF EXTRACT for UID 0 occurs is that
RACF will search its database for the first UID 0 that maps to a
userid and then returns that userid to USS.
.
Where the ambiguity in the UID 0 to userid resolution comes in
is the RACF cache. RACF will check its cache first to see if it can
satisfy the request. Because cache contents are always in a state
of flux, the outcome of the UID 0 to userid request might not produce
the same match each time the lookup is done.
.
To be clear, the file is owned by UID 0 and security checks are
based on the file's owning UID value. The displayed userid values in
ls or in ISHELL are for DISPLAY PURPOSES ONLY.
.
I hope that helps. It can be a little confusing, but the
bottom line is the the numeric UID or GID is what is used for
access checking in USS. The displayed userid/group is just done
for our benefit (as us humans like names instead of numbers),
but is not used for access checking.
.
This is really only an issue for UIDs that have been assigned
to more then one userid.
To do a Direct Load one of the conditions is the userid must match between the load job and arssockd.
What exactly is getting used?
If you look at a trace for arsload, for example:
83888142:4197548366755790848 06/25/2014 16:57:33:946476 INFO
SYS13344.T124629.RA000.ARNLOAD.SRCCMS.H01(ARNLOAD)(2203)
ArcLOADP_startup _390:Running TCPIP Instance
HOST=ARSAA00A rsn_text_u=Ident failed for
ARSAA00A.3009.ARSSERVR.OD390SA
Then:
ARSAA00A - instance
3009 - port
ARSSERVR - RACF user
OD390SA - RACF group
for the arsload.
That RACF user has to match the what is used by the server.
________________________
If you want to find out what the server is using all you have to do is issue the GRS command:
D GRS,RES=(SYSZARSI,*)
This is the result from my system:
RESPONSE=MVS222
ISG343I 14.35.44 GRS STATUS 765
S=SYSTEM SYSZARSI ARCH950.11449.ARSSV950.ODCMARS
SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS
MVS222 ARSSOC95 003E 008F8588 SHARE OWN
Note the ARCH950.11449.ARSSV950.ODCMARS.
Ed