When using RACF to manage security settings for Datacom, there are several things that have to be set up correctly to allow you to make dynamic permission changes. These settings will allow you to refresh the security permissions without recycling the Datacom MUF or the user application.
Release : 15.1
Component : Datacom/DB
Component : Datacom/AD
Component : Common Components and Services
This explains the configuration and process necessary to make dynamic RACF security permission changes for Datacom users of External Security.
The short version for this setting is that using RACF FRACHECK (FASTAUTH=YES) causes the CCS processing to load these classes into memory, and to use the memory definition for any security test. Obviously, if you later change the database, these changes would not be reflected in this CCS-loaded memory entry, which would require CCS to delete and then re-list each class in order to rebuild the in-memory profiles (a large performance hit). Therefore, you need to use the standard RACF RACHECK processing (FASTAUTH=NO), which queries the RACF database directly, and which would pick up database changes you make.
Because you are already using so many of the Dx@TABLE entries, we would recommend your CAIRACF DD statement contain all of these Datacom definitions among your other CAIRACF definitions. The default settings for Datacom currently use FASTAUTH=YES, but NO is required if making dynamic changes (note that we also recommend using CICS=NO if dynamic changes could affect CICS processing):
Once these are in place and active, you will be able to refresh Datacom security. You should also add this to your CAS9 proc:
to report on the CAIRACF statements and their settings.
If these have not been defined when CAS9 was run at IPL time, you can run a command to refresh CCS security settings and add them. Note: Solution LU06243 (published August 2022) is needed to prevent Datacom MUFs from abending if this command is run while the MUF is active. To refresh CCS security (module SSF), issue this console command:
For more information about this customization of CCS module SSF for use with RACF, please see the Customize CAISSF for RACF or RACF-Compatible Products section of the Common Components and Services for z/OS 15.0 documentation.
2. With the CCS security settings active, you can now make changes to the RACF profiles as needed for the DT@DMIN, DT@TIL, DT@YSTEM, or Dx@ABLE classes. After the permissions have been made, be sure to refresh the RACF local memory definition with these changes. You can use one of these RACF commands:
Completion of this command will refresh the changes in the RACF environment by doing these steps:
Without the SETR commands, RACF will not be aware of the profile changes, because the local memory settings would have been loaded from the database at IPL time, and never again.
3. If the above RACF permission change was made to the Dx@ABLE class, you then need to refresh the Datacom security control blocks (SECURITY RESET command). This only applies to the Dx@ABLE class; changes to the other classes do not need Datacom refresh processing, and this command will not have any effect on security for those classes. To refresh Datacom Dx@ABLE class entries, use this console command (user is optional; specify one user name here, or leave blank to reset all active users):
If any one of these above three parts is skipped, the dynamic security change will not happen. However, if you have made the RACF change (step 2, above), it will have been made to the RACF database and then will have been RACLISTED at the next IPL, making the profile setting ready for use. Then, starting the MUF would enable all the Dx@ABLE changes, obviating the need for the RESET command for those entries.
For more information about using External Security with Datacom, please refer to the Security Overview section of the Datacom/DB Core documentation.
As always, please contact Broadcom support for Datacom if you have further questions. Note that when opening a new case, please provide the following:
The output from the Multi-User Facility;
The output from any failed jobs, or screen captures of any user online error;
The result of these RACF commands:
RLIST Dx@ABLE * ALL (for all the "TABLE" classes specified in the MUF SECURITY option)
RLIST DT@DMIN * ALL
RLIST DT@YSTEM * ALL
RLIST DT@TIL * ALL
LU uuuuuuuu ALL (for the Logon ID of the user or job receiving the error)