TSS9122I And TSS9123A Unable To Obtain A SECFILE Lock

Document ID : KB000019007
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

Messages seen in the SYSLOG:


 ===========================================================================
 TSS9122I - TSSENQ: UNABLE TO ENQ ON ACID NWUW2323, ENQ HELD
 *TSS9123A - UNABLE TO OBTAIN SECURITY FILE ENQ. 093
 ===========================================================================

...and the TSSCFILE Extract Job was running at the time the error messages occurred. This means a SECFILE Lock was unobtainable.

Solution:

  1. Why would a CFILE Extract result in ENQ LOCK errors?

  2. Is there any chance that the errors could have resulted in Security File corruption on the LPAR?

  3. Does this imply that the CFILE Extracts can't be run during business hours without these ENQ LOCK errors occurring?

    The TSS9122 variation of the TSS9123A message is used when two commands try to access the same ACID at the same time. This is normal and the problem usually clears up on its own.

    Occasionally, the command is executing in the TSS Address Space and we discover that we can no longer communicate with the original issuer of the command. This may be because the job issuing the command was cancelled or the TSO User hit 'ATTN'. Note: this does not stop the command from executing. The Command Processor is in the TSS Address Space and will continue until we need to send output back to the issuer or until the command ends.

    When we try to communicate with the issuer of the command, we may be able to detect immediately that the Issuer is no longer waiting. PTF RO21197 tries to expand the number of cases where this works, but we can't always detect this situation. If we can't, we will wait for 10 minutes before deciding that the Issuer is not waiting, then we will terminate the command. There are actually cases where after the 10 minutes that we will try a second time to communicate with the original Address Space, but anything longer than 20 minutes implies a more serious problem.

    If you look at the SYSLOG and look to determine if it cleared itself up in 10 minutes, it's probably normal processing. It is better not to cancel a job issuing TSS commands, or not to hit 'ATTN' under TSO if a command is executing, but we do have a process in place to keep the command processors executing properly.

    Only a dump taken while the problem is going on will be useful to go further with investigating such problems.

    The 10 minute wait only affects command processing, and has no lasting effect (assuming it does clear itself up). Once the problem clears itself up, there is no problem with any TSS Command Processor.

    The ENQ mentioned in the message is a TSS ENQ, not a GRS ENQ. It can be issued on any ACID that is used in a TSS command.

    The most common cause of this problem is a batch job doing a lot of CA Top Secret Administration, i.e. TSS LIST(ACIDS) DATA(ALL) or a bunch of TSS commands. Other causes are taking a backup at that time, running TSSXTEND or TSSFAR against the primary SECFILE, heavy 'signon processing' on systems sharing a security file, or cancelling a TSS command that is taking a long time to run. If no response is made after the message has been outstanding for a minute, TSS automatically responds WAIT. In the case of a TSS command cancelled, the ENQ will be released automatically after 10 minutes.

    If none of the above causes are found and the ENQ messages still exist longer than 10 minutes, we will need a dump of the CA Top Secret Address Space while the message is outstanding to further investigate the problem.

    Basically, it is highly unlikely that this problem would not clear on its own.