We are facing a problem with RACF security in DB2.
We are running DB2 V7.1 on zOS 1.4.
When a user logs on to TSO, we connect this user to a group to be able to
update DB2 tables, he starts SPUFI or QMF, he can not update the tables.
When this user logs off and on again, he can update the tables.
When we disconnect this user from this group, he still can update the
tables until he logs off and on again.
It seems the exit only "sees" the initial "RACF-list" and not the updates
during his session. A RACF refresh does not help.
In my opinion, the change to RACF should be active immediately (as is in
Does anyone know if my assumption is correct and (even better) a solution
to make it work as I think it should?
Based on what you've described I think you are using the exit called the "connection exit" - which is only invoked during connection. If you wade through the code for the sample exit (I presume you've replaced the default exit by the sample exit) you'll see that it actually copies RACF group names into a DB2 specific data area. It is that DB2 data area, not a RACF data area, that is used by DB2 for authorization processing. This is why RACF updates do not immediately affect DB2. (The reason the exit works this way is to provide a generic interface, usable by ACF-2 etc, and hence not violate IBM's Consent Decree of 1956.)
Maybe you saw this already in DB2-L, but maybe for other persons:
Our problem can not be solved easily.
We raised a PMR with IBM.
We use the standard connection exit with list of groups option.
The main problem is (according IBM):
RACF doesn't appear to support SETROPTS ... REFRESH for GRPLIST. So
you can't dynamically refresh the list of groups which a user is
connected to. The only way to refresh the list is to logoff/logon to
build a new ACEE.
I asked if a tool is available to achieve the same thing.
"No. We could send a FITS Design Change Requirement to the RACF Lab for
them to consider this for a future release."