On Sun, 23 Mar 2008 14:42:51 -0400, Knutson, Sam <[EMAIL PROTECTED]> wrote:
> >We deal with large volumes of SMF data and sometimes get floods of SMF >data due to looping transactions, DB2 traces, or other diagnostic >captures or application errors. This is the part that concerns me most (regardless of the other dumping issues). I think I posted this before... In the past year or so there have been 3 instances of SMF collection / dumping problems. 1 was a CICS transaction looping, one was a MQ trigger for CICS transaction "looping", and the 3rd was in the last month or so - a DB2 accounting trace (the DB2 team had no clue what it was going to do to SMF so they didn't warn us - guess IBM should have warned them). > >I think SMF to LOGR solves more problems than it creates and I intend to >try it on our test Sysplex as soon as we have z/OS 1.9 up and running >stable there. > I agree that it has that potential. But it doesn't create any problems if you don't use it. :-) Seriously... in a smaller environment like a test sysplex I think it will be great. I plan on doing the same shortly and just managing it with RETPD like I do operlog and LOGREC. But I don't need to worry about archiving it and using it for production processes like billing. It's there in my sandbox to be only "as needed". >My biggest concern about SMF to LOGR is how I can easily detect sudden >changes in profile in data recording or flooding. Exactly. In all of the cases I mentioned above the SMF offloads had trouble keeping up with MANx data sets filling up and operations noticed all the contention messages and alerted us. If this data was all going to our SMS LOGR pool, the first call would go to our DASD storage group when the pool ran out of space (or when HSM ML1 ran out of space depending on how we might archive these logstreams). By they time they responded or figured out what was going on, it would probably be too late since this would of course affect all LOGR applications (this is not like a batch space abend that could wait to be addressed). That would not be a good thing - especially if RRS was affected. Many years ago we ran into that same situation when LOGREC went wild, but it was a much smaller environment and we hadn't planned as well for an abnormal situation. Here, I would probably have a hard time justifying "n" times the amount of needed DASD just sitting doing nothing most of the time in order to handle some abnormal situation should it come up. Today "n" doesn't matter much since the LOGR pool isn't that big (it's about 30% full as I look right now). I just keep trying to picture the 3 times we've had problems in the last year or so and what that would have looked like with SMF going to logger. In one of those cases I know we created about 200 tape GDGs when all was said and done. Looking at a few SMF virtual tapes right now, they are about 1G (uncompressed) each. I'm rambling now, but I think you can see why I'm not ready to jump on this. > I have requirements >against CA-SYSVIEW but I think this is an area IBM should address in a >similar way to what they have done with the WTO Flood processing and >what is being discussed in the statement of direction for autonomic >detection of common storage use out of profile. I would love to see IBM >provide an exit that could alert on out of profile SMF recording. At >the minimum IBM could provide a new record or exit on an interval with a >COUNT/RATE for active address spaces, system COUNT/RATE, SMF >type-subtype COUNT/RATE. This would allow an installation to more >easily become aware of flooding/looping conditions causing large volumes >of wasteful data to dump into SMF that will be a problem both in DASD >use by LOGR and in downstream processing. > Sounds like a great idea. You could try and use FULLTHRESHOLD(n) in the CFRM policy perhaps, but we already use FULLTHRESHOLD(0) for similar logstreams (logrec, operlog). See past rants... er.. I mean posts from Barabara Nitz on this subject. At any rete... this is all very new and I think we'll (us users and IBM) have to learn as we go along. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
