When using Top Secret r15.0, you may come across the problem of being unable to obtain a SECFILE Lock. You may also see the following messages in the MVS SYSLOG:
===========================================================================
TSS9122I - TSSENQ: UNABLE TO ENQ ON ACID NWUW2323, ENQ HELD
*TSS9123A - UNABLE TO OBTAIN SECURITY FILE ENQ. 093
===========================================================================
...and the TSSCFILE Extract Job is more than likely to be running at the time these error messages occur. This means a SECFILE Lock was unobtainable.
So the questions this raises are:
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?
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~
Now, to answer all these questions and why this situation occurs, and the resolution to this problem...
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.