Interpreting user domain statistics

The user domain attempts to minimize the number of times it calls the security domain to create user security blocks (such as the ACEE), because this operation is expensive in both processor time and input/output operations.

If possible, each unique representation of a user is shared between multiple transactions. A user-domain representation of a user can be shared if the following attributes are identical:
  • The user ID.
  • The group ID.
  • The applid, which is not necessarily the same for all the users in a region. The applid is shipped with the user ID across MRO links.
  • The port of entry, which can be the netname, for users signed on at z/OS® Communications Server terminals, or the console name, for users signed on at consoles. It is null for other terminal types and for users associated with nonterminal transactions.

The user domain keeps a count of the number of concurrent usages of a shared instance of a user. The count includes the number of times the instance has been associated with a CICS® resource, such as a transient data queue, and the number of active transactions that are using the instance.

Whenever CICS adds a new user instance to the user domain, the domain tries to locate that instance in its user directory. If the user instance exists with the parameters described, that instance is reused. The USGDRRC parameter records how many times reuse occurs. However, if the user instance does not exist, it must be added, requiring a call of the security domain and the external security manager. The USGDRNFC parameter records how many times this is necessary.

When the count associated with the instance is reduced to zero, the user instance is not immediately deleted; instead, it is placed in a timeout queue controlled by the USRDELAY system initialization parameter. While it is in the timeout queue, the user instance is still eligible to be reused. If it is reused, it is removed from the timeout queue. The USGTORC parameter records how many times a user instance is reused while it was being timed out, and the USGTOMRT parameter records the average time that user instances remain on the timeout queue until they are removed.

However, if a user instance remains on the timeout queue for a full USRDELAY interval without being reused, it is deleted. The USGTOEC parameter records how many times this happens.

If the value of USGTOEC is large compared to the value of USGTORC, consider increasing the value of USRDELAY. But if the value of USGTOMRT is much smaller than the value of USRDELAY, you might be able to reduce the value of USRDELAY without significant performance effect.

High values of USRDELAY can affect the ability of your security administrator to change the authorities and attributes of CICS users, because those changes are not reflected in CICS until the user instance is refreshed in CICS by being flushed from the timeout queue after the USRDELAY interval. Some security administrators might require you to specify USRDELAY=0, which still allows some sharing of user instances if the usage count is never reduced to zero. Generally, however, remote users are flushed out immediately after the transaction that they are running has ended, so that their user control blocks must be reconstructed frequently. This reconstruction results in poor performance.

If you specify a low value for the USRDELAY system initialization parameter to ensure that CICS detects changes to RACF® profiles promptly, you might want to increase this value, because for z/OS 1.11 and later, CICS is notified immediately if RACF profile changes occur. The primary impact of a high USRDELAY value is that the amount of storage used for RACF control blocks is increased.