TSS9122I/TSS9123A UNABLE TO OBTAIN SECURITY FILE ENQ
Article ID: 31662
Updated On:
Products
Issue/Introduction
The following messages occurred in the MVS SYSLOG:
==================================================
TSS9122I - TSSENQ: UNABLE TO ENQ ON ACID acid, ENQ HELD ON
SYSTEM ssss
*TSS9123A - UNABLE TO OBTAIN SECURITY FILE ENQ. nnn
SYSTEM ssss HAS HELD LOCK FOR 002 MINUTES
IF SYSTEM ssss IS NOT OPERATIONAL
REPLY 'RESET', OTHERWISE REPLY 'WAIT'.
WARNING: INDISCRIMINATELY REPLYING 'RESET'
MAY CAUSE CORRUPTION OF THE SECURITY FILE
==================================================
Environment
Component:
Resolution
The TSS9122I 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 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 TSS 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 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 TSS Address Space while the message is outstanding to go further with investigating the problem.
Basically, it is highly unlikely that this problem would not clear on its own.
Feedback
