Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
ICH15031I z/OS Security Server RACF Messages and Codes SA23-2291-00 |
|
ICH15031I ICHEINTY TYPE ERROR AGAINST PROFILE PROFILE-NAME IN
CLASS CLASS-NAME ON THE DATABASE WITH MASTER DATA
SET DSNAME. HEX RC=RC, AND REASON=REASON ExplanationThe ICHEINTY encountered a failing return or reason
code where:
If there is an ICHEINTY ALTER failure, then because the IRRPLEX_ profiles are used to shield the database from corruption caused by incorrect database sharing, there might be a gap in a future analysis. System actionIn both cases processing continues. Operator responseContact your system programmer. System programmer responseSee z/OS Security Server RACF Macros and Interfaces for the description of the return and reason codes for the ICHEINTY macro. If the RVARY DATASHARE, NODATASHARE, or ACTIVE command is successful then: If there is an ICHEINTY ALTER failure, issue an RLIST
command on the named profile. If this is successful issue an RVARY
LIST command:
If there is an ICHEINTY NEXT failure, issue a SEARCH command.
For example:
If
there are still failures, issue an RDELETE command on the profile.
If this is successful, re-create the profile by using the RDEFINE
command, and either enter “data sharing mode” or “non-data sharing
mode” in the APPLDATA field, as determined by the RVARY command.If
there is an ICHEINTY NEXT failure, then because the IRRPLEX_ profiles
are used to shield the database from corruption caused by incorrect
database sharing, there might be a gap in that analysis. The database
can become corrupted if:
You can issue an RVARY list command to determine the database names and volsers. This also indicates if the system is in data sharing mode. If the RACF database is incorrectly shared, run IRRUT200 against each data set and either move all sharing sysplexes out of data sharing mode into non-data sharing mode (RVARY NODATASHARE), or change your database sharing configuration. If the database is already corrupted, either restore an archived backup of the database, or contact your IBM® support center. If the message indicates
that the ICHEINTY NEXT was run against the backup database, and you
did not receive this message for the primary database, then if the
backup database is intended to be the same as the primary database,
resynchronize the primary and the backup databases by using "IRRUT200
PARM=ACTIVATE".
Note: Ensure that the database you are using as the
backup database is the correct database to be using with your primary
database. The "IRRUT200 PARM=ACTIVATE" overlays all the data within
the specified backup data set. See z/OS Security Server RACF System Programmer's Guide for
more information about IRRUT200.
If the problem persists, contact your IBM support center. Do not use RRSF to propagate the RDEFINE, RALTER, and RDELETE commands to other databases. If automatic command direction is enabled for the GXFACILI class, use the ONLYAT operand (on the RALTER, RDEFINE, and RDELETE commands) when you change IRRPLEX_sysplex-name profiles to prevent this propagation. You must use ONLYAT whether you are altering, creating, or deleting the class GXFACILI IRRPLEX_sysplex-name profiles on a local or remote node. Routing code2 and 9 Descriptor code4 |
Copyright IBM Corporation 1990, 2014
|