If you change attributes for an existing class in the dynamic CDT,
plan carefully to avoid unintended results. Before making changes
to the following particular class attributes, follow these guidelines
to help you consider the effect of your changes on existing applications
and RACF® processing.
After you change an attribute for a class, refresh the CDT class
on all systems that will use the changed class:
SETROPTS RACLIST(CDT) REFRESH
Guidelines for changing particular class attributes:
- CASE: Before you change CASE(ASIS) to CASE(UPPER),
review all profiles in the class and delete any profiles that contain
lowercase letters in the profile name.
- FIRST or OTHER: Before you change the FIRST and OTHER values
to make them more restrictive, review all profiles in the class and
delete those that contain the less restrictive characters. Example: Before
you change FIRST(ALPHA,NUMERIC) to FIRST(ALPHA),
delete any profiles that contain a number in the first character of
the profile name.
- GENERIC: Before you change GENERIC(ALLOWED) to GENERIC(DISALLOWED),
review Rules about disallowing generics when sharing a POSIT value and follow Steps for changing a dynamic class to disallow generic profiles.
- GENLIST: Before you change GENLIST(ALLOWED) to GENLIST(DISALLOWED),
remove any in-storage generic profiles in the class by issuing the
following command.
SETROPTS NOGENLIST(classname)
Do
not issue SETROPTS NOGENLIST for an existing class when it shares
a POSIT value with other classes that are active. This action might
impact authorization processing for the other classes.
- GROUP and MEMBER: Before you change the GROUP or
MEMBER attributes for a class, delete any member classes by issuing
the following command.
RALTER grouping-classname profile-name DELMEM(member-list)
Then,
be sure to update both the grouping class definition and the member
class definition in compatible ways. For example, if you change a
member class to a non-member class by changing GROUP(grouping-classname) to NOGROUP,
then you must change the corresponding grouping class to a non-grouping
class by changing MEMBER(member-classname) to NOMEMBER.After
you change the GROUP or MEMBER attribute for your class and refresh
the CDT class, refresh the in-storage profiles for your class. If
you do not refresh the in-storage profiles, RACF authorization checking for resources in
your class might return unpredictable results.
- MAXLENGTH and MAXLENX: Before you change the length
of profile names, review the following guidelines.
- Before you increase the length of profile names in a class,
examine existing applications to see if modifications are necessary.
When you increase the length attribute in a class, update only the
MAXLENX operand to specify the new length, leaving the existing MAXLENGTH
value. This might allow some applications using the RACROUTE macro
with the ENTITY operand to work properly with the previous maximum
length. These applications include those that use RACROUTE REQUEST=AUTH,
REQUEST=FASTAUTH, and REQUEST=EXTRACT with TYPE (other than EXTRACTN).
However, applications that use other RACF macros,
such as ICHEINTY and RACROUTE REQUEST=EXTRACT,TYPE=EXTRACTN, might
likely need modifications to process the new profile name length correctly.
Modify applications that use the RACROUTE macro to include the ENTITYX
operand to support the new maximum length.
- Before you decrease the length of profile names in a class,
examine existing applications that use the RACROUTE macro with ENTITY
or ENTITYX option, or the ICHEINTY macro with the ENTRY or ENTRYX
option, to see if modifications are necessary. Then, be sure to delete
any profiles in that class that have names longer than the new MAXLENGTH
or MAXLENX limits. If you do not delete the profiles with the longer
names before you decrease the MAXLENGTH or MAXLENX values for the
class, authorization checking for resources in the class might give
unpredictable results.
After you change the MAXLENGTH or MAXLENX attribute for your
class and refresh the CDT class, refresh the in-storage profiles for
your class. If you do not refresh the in-storage profiles, RACF authorization checking for
resources in your class might return unpredictable results.
- PROFILESALLOWED: Before you change PROFILESALLOWED(YES) to PROFILESALLOWED(NO),
delete all profiles from the class using the RDELETE command.
- RACLIST: Before you change RACLIST(REQUIRED) or RACLIST(ALLOWED) to RACLIST(DISALLOWED),
do both of the following.
- Remove any RACLISTed profiles in the class by issuing the following
command.
SETROPTS NORACLIST(classname)
Do
not issue SETROPTS NORACLIST for an existing class when it shares
a POSIT value with other classes that are active. This action might
impact authorization processing for the other classes.
- Modify any applications that process RACLISTed profiles in that
class.
Testing consideration: Consider how you can test your changes.
If you have a test system that does not share a RACF database with your production system, you
might be able to test the change with existing applications and RACF commands on your test system
before activating the change on a production system. If your test
system does share a RACF database
with your production system, you might need to create a class in the
dynamic CDT specifically for testing, and modify your applications
to use the test class.
RRSF consideration: If you are using RACF remote sharing facility (RRSF) and change
a dynamic CDT entry, consider updating the dynamic CDT entry on all
systems that use the dynamic class. Also, see RRSF considerations for the dynamic CDT.