When OTMA security is enabled, for performance purposes
OTMA caches in memory RACF® user
profiles as a RACF accessor
environment element (ACEE).
The ACEE is then used in subsequent calls to RACF to
determine the user ID's authorization to the IMS command or IMS transaction requested in the input message. Using the ACEE
reduces I/O to RACF.
When changes are made to a user profile in the RACF
database on DASD, the changes are not reflected in the cached ACEE if IMS fails to register with
RACF event notification facility (ENF), and the user's old access privileges might remain unchanged
in online memory until the ACEE is refreshed.
RACF ACEEs that are cached by OTMA can be
refreshed with one of the following methods:
-
Automatically by OTMA when the z/OS® ENF notifies IMS of the changes.
When changes are made to a user profile in the RACF
database on DASD, ENF notifies IMS of the changes with an ENF
event code 71. Upon receiving the notification, OTMA refreshes the ACEEs for the changed user
ID.
IMS automatically registers with ENF during startup to
receive the event code 71 notifications. If ENF registration fails for any reason, IMS issues message DFS3525E and OTMA cannot refresh ACEEs
automatically when changes are made in RACF.
To ensure that cached ACEEs reflect the latest RACF
security definitions even when IMS cannot register with ENF,
OTMA clients can specify an aging value that defines the length of time between automatic refreshes
of cached ACEEs.
If ENF registration failed during IMS startup and your RACF security administrator modifies a user's access privileges
for OTMA in RACF, you might need to refresh the ACEE for the
user ID by issuing the /SECURE OTMA REFRESH command. Otherwise, the user's old
access privileges might remain unchanged in online memory until the ACEE aging limit is reached.
-
You can specify an aging value for OTMA ACEEs. When the OTMA ACEE aging value is reached, OTMA
refreshes the ACEE before it processes the next input message that is received from an OTMA
client.
To define an ACEE aging value for IMS Connect to pass to
OTMA, use the OAAV= keyword in the DATASTORE configuration statement of the IMS Connect PROCLIB member, HWSCFGxx.
To define an ACEE aging value for IBM MQ, use the OTMACON= parameter in the CSQ6SYSP macro.
To define a global ACEE aging value for all OTMA
clients, issue the /SECURE OTMA ACEEAGE command. If you define a global ACEE
aging value for OTMA clients by issuing the /SECURE OTMA ACEEAGE command, the
aging value that you specify overrides the existing ACEE aging values for all OTMA clients. If you
specify the TMEMBER parameter with the /SECURE OTMA ACEEAGE
command, the ACEE aging value that you define overrides the existing value, if any, for the OTMA
client that you specify.
Each cached OTMA ACEE can have its own aging value that is based on the OTMA client (TMEMBER)
with the lowest aging value that accesses it. For example, IBM® MQ sets its ACEE aging value to five days
and IMS
Connect sets its ACEE aging value
to one day. Any ACEEs that only IBM MQ uses have an aging value of five days. Any ACEEs that only IMS
Connect uses have an aging value of one day. If
both IBM MQ and IMS
Connect use an ACEE, the aging value is one
day, which is the lowest value between five days and one day.
The ACEE expiration value is specified during the client-bid time.
-
You can issue the /SECURE OTMA REFRESH command to manually refresh the OTMA
ACEEs.
To refresh all OTMA ACEEs globally, issue the command /SECURE OTMA REFRESH. To
refresh the ACEE for an individual OTMA client, issue the command /SECURE OTMA REFRESH
TMEMBER
tmember_name. To refresh only those ACEEs for a specific user ID, issue the
command /SECURE OTMA REFRESH USER
user_id.
-
You can also rebuild the ACEE table by issuing the /STOP and /START
OTMA commands.