Refreshing RACF profiles for CICSPlex SM

CICSPlex® SM uses a cached copy of RACF® information in order to reduce unnecessary I/O to the RACF database. When you change a RACF definition, you will, in some situations, need to force the CMAS to refresh the cached information.

About this task

This includes refreshing general resource profiles and user profiles in the cache.

Procedure

Refreshing general resource profiles in the cache

A CMAS requests RACF to create a cached copy of its general resource profiles during initialization:

During CMAS initialization, global copies of the RACF profiles in the CPSMOBJ (including GCPSMOBJ) and CPSMXMP are created.
During MAS initialization, the MAS determines which CICS® security classes are in use, using the information specified in the XCMD, XDB2, XDCT, XFCT, XJCT, XPCT and XPPT system initialization parameters. This information is passed to the CMAS where it is used to create global copies of the relevant RACF profiles.

Perform the following steps to refresh the general resource profiles in the cache.

To identify the profiles for which global copies exist, issue the RACF command SETROPTS LIST.
The GLOBAL=YES RACLIST ONLY section of the output shows which general resource classes have been globally copied.
Whenever a change is made to one of these classes (for example, with the RALTER, RDEFINE, RDELETE or PERMIT commands), you must refresh the cache.
Use the following RACF command:
```
SETR RACLIST(classname) GENERIC(classname) REFRESH
```
In a multi-CMAS environment, this command will refresh the cache only on the MVS™ images that share the same RACF database.
If other CMASes run on other MVS images that do not share the same RACF database, repeat the SETR command on the other images.

Refreshing user profiles in the cache

A CMAS stores security information for a userid in the cache when it performs a security check. By default, the information is retained in the cache until the user has remained inactive in the CMAS for the time specified by the SECTIMEOUT CICSPlex SM parameter and the CMAS has performed a userid timeout check.

Whenever a change is made to a userid (for example, with the CONNECT, REMOVE, ALTUSER, or DELUSER commands), the change becomes visible when the CMAS discards security information for the user from the cache.

To force a CMAS to discard security information from the cache before timeout processing has occurred, use one the following actions:
- For a single CMAS, use the RESET USERID action on the CMAS object.
- For more than one CMAS, use the RESET USERID action on the CMASLIST object.
Both actions are available from the WUI and the API.
Perform the action when a user has previously used the CMAS and you do not want to wait for normal timeout processing to occur.
To force a CMAS to immediately check for userids that are eligible for timeout, use one of the following actions:
- For a single CMAS, use the PURGE action on the CMAS object.
- For more than one CMAS, use the PURGE action on the CMASLIST object.
Both actions are available from the WUI and the API.