ICH584I

Explanation
The ICHEINTY encountered a failing return code
or reason code where: Type is the type of ICHEINTY (‘NEXT’ or ‘ALTER’)
Profile is the profile namefor ICHEINTY ALTER the profile name is 9 to 16 characters in length.
for ICHEINTY NEXT a profile name might be 247 characters in length.
A maximum of the first 20 characters of the profile name is presented
in the message.

Class is the General Resource class
The dsname and volser indicate
the database

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.
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.
If the master data set of a database is undefined, then
the message does not list a data base name dsname or
volser volser.

System action
Initialization continues and in both cases processing
continues.

Operator response
Contact your systems programmer.

System programmer response
See z/OS Security Server RACF Macros and Interfaces for
the description of the return and reason codes for the ICHEINTY macro.When the system is available:
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 the RVARY LIST command indicates that the system is in data
sharing mode, issue an RALTER command on the named profile and enter
“DATA SHARING MODE” into the APPLDATA field. 
If the RVARY LIST command indicates that the system is in read-only
mode and another system is using the database in data sharing mode,
issue an RALTER command from that system on the named profile and
enter “DATA SHARING MODE” into the APPLDATA field.
If the RVARY LIST command does not indicate data sharing mode
or read-only mode, issue an RALTER command on the named profile and
enter “NON-DATA SHARING MODE” into the APPLDATA field.

If there is an ICHEINTY NEXT failure, issue a SEARCH
command. For example:SEARCH CLASS(GXFACILI) MASK(IRRPLEX_)
If
there are still failures, issue an RDELETE command on the profile.
If this is successful re-create the profile 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:The RACF® database is shared
with systems that are outside the global resource serialization complex,
and any of the sharing systems are in data sharing mode. Or,
There are systems within the global resource serialization complex
that are in data sharing mode, and any other sharing systems are in
non-data sharing mode.

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 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. ONLYAT must be used whether you are altering,
creating, or deleting the class GXFACILI IRRPLEX_sysplex-name profiles
on a local or remote node.

Routing code
2 and 9

Descriptor code
4