The class descriptor table (CDT)

The class descriptor table (CDT) contains information that directs the processing of general resources. RACF® references the class descriptor table whenever it receives a resource class name other than DATASET, USER or GROUP.

The class descriptor table has two parts:

The static class descriptor table.
If you make a change to the static class descriptor table, you must re-IPL to have the change take effect on your system. This part of the class descriptor table contains two load modules:
- ICHRRCDX contains the class entries supplied by IBM®. Each class supplied by IBM is a CSECT in load module ICHRRCDX.
  Note: Do not delete or modify any of the class entries in ICHRRCDX. For a list of the classes that IBM supplies, see z/OS Security Server RACF Security Administrator's Guide.
- ICHRRCDE is an optional module that contains installation-defined class entries. You define classes in ICHRRCDE using the ICHERCDE macro. For information about the macro, see the section on ICHERCDE in z/OS Security Server RACF Macros and Interfaces.
The dynamic class descriptor table.
This optional portion of the class descriptor table contains installation-defined class entries built from the CDT general resource class. You can define classes in the dynamic class descriptor table using RDEFINE and RALTER commands. If you make a change to the dynamic class descriptor table, you do not need to re-IPL to have the change take effect. Instead, issue the command SETROPTS RACLIST(CDT) REFRESH. For information about the dynamic class descriptor table, see z/OS Security Server RACF Security Administrator's Guide.

Restriction: If you have applications or vendor products that use dynamic classes, they must use the RACROUTE REQUEST=STAT interface to process information for dynamic classes (for example, to check if a class is active). If your application or vendor product uses the RACSTAT macro or the RCVTCDTP pointer in the RCVT control block to locate a dynamic class, it will not work properly.

RACF processing references the class descriptor table whenever a class name is received as input. Each class, if defined on multiple systems, must be defined identically on all systems using the class. If the classes are defined differently, unpredictable results can occur when you change the SETROPTS options for the class.

Installations sharing a database do not need identical class descriptor tables, but they must be compatible. If the same class is present on multiple systems, it must have the same attributes; for example, the POSIT numbers must be the same. Therefore, if systems X and Y are sharing a database, and system X has a class descriptor table with classes a, b, and c, and system Y has a class descriptor table with classes a, b, c, d, e, and f, the classes a, b, and c must be defined identically on both systems. However, system Y can have classes d, e, and f that are not defined on system X. Note that when RACF is enabled for sysplex communication, to allow flexibility when adding new classes to the class descriptor table, RACF does not enforce consistency in the class descriptor table as it does with the data set name table and the range table.

Beginning with z/OS® V1R8, you can define a class with an attribute that disallows generic profile processing. For information about using a class that does not allow generic profile processing when the database is shared by systems that do and do not support this attribute, see Considerations for classes that do not allow generic profile processing.

If you have systems at different releases of z/OS, you can share a database between them without adding the new classes for the higher-level system to the class descriptor table on the lower-level system. For example, if you are sharing a database between a z/OS V1R4 system and a z/OS V1R6 system, you do not have to add the new RACF classes to the class descriptor table on the z/OS V1R4 system.

If you are using sysplex communication, RACF propagates commands. If you choose to use class descriptor tables that are compatible but not identical, command propagation might be affected. If you issue a command against a class that is not defined on the issuing system, RACF does not propagate the command. On the other hand, if you issue a command against a class that is defined on the issuing system, but RACF propagates it and finds that the class is not defined on the peer system, the command does not run on the peer system.

Systems can share the same copy of the ICHRRCDE source.

Installation-defined names must be unique. They must not be identical to any names that IBM supplies or to other installation-defined names. The ICHERCDE macro and RACF initialization check for uniqueness.

The maximum number of entries you can have in the class descriptor table is 1024. There are 1024 POSIT numbers, of which numbers 19–56 and 128–527 are available for your installation's use. Numbers 0–18, 57–127, and 528–1023 are reserved for IBM's use. Classes requiring better performance should be placed towards the beginning of the table.