Root cause of performance issues with TSS commands can sometimes be difficult to pinpoint.
I’d start with performing the TSS MODIFY ST command, and looking for some key items related to performance. Please run that, and then report back with a reply that includes the following components, and then I’ll comment further:
- SHRFILE (it will be either YES or NO)
- CACHE (it will be either ON or OFF).
- CACHE STATISTICS. These include numbers about the size of cache, and number of times cleared.
- COMMAND PROCESSOR WORKLOAD BALANCE. This shows how many command processors you have active (default is 5).
- STATISTICS BY COMMAND. This reports how many of each TSS command has been processed since TSS was last started.
- CPF (this will show as INACTIVE unless you are using CPF).
In case you are not comfortable with sharing your values, here is an overview of what I’d be looking for:
- SHRFILE. This is one of the biggest factors of TSS SECFILE performance in my experience. If you are sharing the TSS SECFILE across multiple LPARs, then pretty much every TSS LIST and WHOHAS command will result in secfile I/O – nearly 3x as compared to without it. This is true even if you are not really sharing the secfile across multiple systems but just have the setting set to YES.
- CACHE. Make sure you see CACHE(ON) (it appears early in the ST output). This ensures that TSS LIST and WHOHAS commands don’t cause physical I/O (except for the 1st time a given ACID is accessed). Generally, if you run a TSSCFILE during a batch cycle, during off hours, this results in all ACIDs being LISTed and therefore loaded into cache … subsequent TSS LIST/WHOHAS should require no I/O and perform extremely well.
- CACHE STATISTICS. This appears a couple of pages down in the MODIFY ST output. Look to see the value in the “Cleared” field. If your MAXSIZE is adequate, then the “Cleared” value should be 000000000. If it is not zero, increase your MAXSIZE to accommodate your entire TSS SECFILE contents. With today’s z/OS configurations, there’s almost never a reason *not* to do this.
- COMMAND PROCESSOR WORKLOAD BALANCE. This appears just below the Cache Statistics. You’ll see the total commands issued, and how many command processors are available. You’ll also see how much of the workload that each command processor has handled. Most local commands are accommodated by the “Cmd 03” processor, but can spill over to other command processors when more than one user is issuing a command at the same time. Also, CPF’d commands (even local ones if you specify a TARGET command) are always handled by the “Cmd 01” processor so that they can be single-threaded. Note that CPF’d commands are handled sequentially, and any number of them may be queued up to run via the CPF Recovery File, so it is also possible that when you enter a command, it may have to wait for other commands that are queued for processing. In that case, it’s possibly not your command that is taking a long time, but rather it is other commands that your commands are queued behind. (Note: these are just observations on my part … there may be other factors in play).
Note that the TSS WHOHAS TRACE (or WHOHAS on any attribute, facility, etc.) is a pretty resource-intensive function, as there are no indexes for these items. (that’s just my experience…possibly they have improved this??). So, the TSS address space needs to crunch through a lot of data to collect this information. And because of that, you’ll want to be sure that your TSS address space is in a service class that gives it adequate CPU resources to perform this processing. If you are running short on CPU capacity, that can be problematic and may cause other tasks to step out of the way for this to be completed. Another control option to check in your MODIFY ST output regarding this is SWAP … make sure this is set to SWAP(NO). I’ve never seen it set to SWAP(YES). Generally TSS is so critical to responding timely for system throughput that you’d want it to be running as non-swappable.
If you don’t find one of these items looking suspect on your system, please post the information that you’ve seen and I can give additional pointers.