I reiterate my YMMV caveat since I can only speak for the secfile demand patterns of our shop. The numbers I cite have worked flawlessly for us since '99 and hopefully are conceptually correct in other environments. In other environments those same numbers may perform acceptably or give you worse headaches than you're suffering today. Our empirical "bad" experience did however leave us with one well performing lpar, unfortunately most of the other 10 in the sharing complex were gasping desperately for time slices that the offending lpar was hoarding.
Having "disclaimered" myself all the ways I can think of, let me offer..... More suggestions: 1. Double, triple, quadruple check that option 61 is on everywhere. 2. check dasd contention on the secfile volume. 3. review the caching value and frequency of cache flushes. 4. set up some form of DOS attack to simulate high usage logon volume. 5. double check the CF capacity and contenders there, who knows ? 6. analyze the size of popular profile acids, relative to secfile blocksize. 7. set your automation product to issue F TSS,STATS every few minutes, it's only a few SYSLOG lines and a handy basic set of stats. lastly: Keeping talking to CA, their lev 2 probably has more tuning tricks to offer. I realize I'm suggesting "curing your backache by ensuring there's not a knife in it" but what the heck, maybe we'll stumble on to something. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schramm, Rob Sent: Thursday, June 16, 2005 1:21 PM To: [email protected] Subject: Re: Top Secret TIMELOCK value Much thanks for your response Tony. I have to admit to being a bit disheartened. We have been having problems with response time with the TSS db in the CF .. but support never even suggested looking at the TIMELOCK or changing it. What we have noticed is that the system that is not local to the CF (if you are using internal CFs) converts about 2/3 of the messages to asynch .. .. but the system that is local to the CF does 100% synch. Curiously enough the system that converts to asynch performs much better than the TSS that is located on the system that has a local CF. |-----| |-----| | | | | |sys1 | |sys2 | |-----| |-----| | cf | | | |-----| |-----| In this drawing, sys2's TSS performs better than the one on sys1 due to IBM's synch-to-asynch conversion that happens. I am in the process of separating the databases to produce better responding systems.. since there was no offered way to steady the performance. I will take the suggestion of the TIMELOCK and work with it. -Rob <snip> This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
