I'm searching some guidance to CA Top Secret performance, fruitless so far,
Are there some checklists, technote's etc. about performance relevant control-options, implemetation-best-practices, administration-best-practices, to check, whether everything is performing already well, or to get some recommendations for improvement? It's clear, every installation is different, but it would be great to have a checklist, on which items to look at ...
Thanks already in advance ...
Here are the things I know to control performance:
Turn on CACHE
Turn on SECCACHE
Have Separate Security files and use CPF to sync them.
Don’t put your Security file on the Same volume as your Audit File
Try to put your Security file on a unused DASD volume to maximize i/o performance.
If you are sharing the Security file, load it into the Coupling Facility if you have access to one.
I hope this helps.
And how! Thank you, Kevin!
What about sizing/setting these options CACHE, SECCACHE resp. CF-structure? Does much CACHE really help much? How to determine the most efficient CACHE-value.... etc.
From some support cases I know that the control-setting of "AUTH" influences behavior, but also performance, Also in the context of NOxxxCHK-privileges there was talk of performance reasons. I intend to remove such privileges, but do I then run the risk of perfomance disadvantages ...
I guess, there could be more control options or other attributes worth to be considered from the performance point of view....
Thanks for hints and info's ...
You can do the sizing of your cache and CF Structure by running the TSSFAR utility. I forget the option you run it with, but it will give you both recommended settings based on how your security file is currently used with regards to number of rules, profiles, and user IDs you currently have defined.
I also forgot that you can fine tune your security file allocation as well. If you run the TSSMAINT in Dummy mode it will tell you the recommended block size and other values for your file.
Your also correct that Auth setting does affect performance. I forget about that because all places I work at have the Auth setting at OVERRIDE,ALLOVER which is recommended. If you do choose to use one of the MERGE options then the TSS address space will use more CPU.
As for the NOxxxCHK bypass attributes, the theory of taking them away causing a noticeable system performance issue is total rubbish IMO. Your Goal should be to never use these attributes. Most companies are spending tons of money trying to remove these attributes from the environment because of the Audit implications. The reality is that the CACAHE and SECCACHE options will counter any performance problems from heavily used ID’s. The shorten code path that the Bypass attribute takes is not that much of a savings if you are properly tuned running on a Modern z Processor.
I have not found a tool for estimating the SECCACHE size. I usually turn it on at 1GB with the default index values and monitor it. You can check the status of the caches at any time, and can monitor if they are being flushed a lot or if your index is filling up a lot, and you can just keep tuning it until you get it to the spot you need. It is using Virtual Memory so I would not be afraid of starting at 1GB and see what they activity on your system does with it.
thanks again for your input and details,
I noticed, that TSS writes the cache-statistics to syslog at shutdown (usually at system-down). So I can analyze these values over a longer time-frame, by extracting the TSS13xxI Messages from the SYSLOG-Datasets.
ould you try to keep the number of CACHE CLEARED at 0000000 ?
I agree, that NOxxxCHK-bypass-attributes should never be used, and also CA Technologies note these attributes as "misuse" in Auditor's Guide. Therefore I try to get rid of these privileges and one of my discoveries resulted in Make OK+B audit records audit-adequate You might have a look there and comment and/or support the idea.
any additional performance-related hints are very welcome and appreciated ...
We had problems when moving to cicsts 4.2 - RO TCB time was rising for no apparent reason and resulted in performance problems
We activated option(61) lock in CF (if shared secfile used)
Also TIMELOCK had an influence to cics response time, we use TIMELOCK(5,320,640,6000) in production. Maybe even lower values for the first suboption make sense.
many thanks to bring my attention to TIMELOCK, I'll have to do some research for our particular circumstances.
ps.: I also asked CA support for guidance and earned a lot of info's
I'd like to thank you for sharing the info's and hints