On Wed, 20 Jun 2012 21:03:07 +0000, Campbell Jay <james.l.campb...@irs.gov> wrote: > >The solution in this case was stopping type 100 - 102 collection. >Changing the Workload Management Class of the copy job to STCHI. > >The DUMPXY process caught up with itself in about 20 minutes. >
My "SMFDUMP" jobs are also in STC SC with a high importance (2). Almost nothing is IMP=1 in my environment. This is one of those problems you don't have until you have it if you normally have spare cycles. WLM is funny that way. :-) We've never had a problem keeping up even during heavy periods, so I still haven't implemented SMF logger other than in sandbox systems (that and the initial support for the dump process etc. would have meant to many changes across a very large environment with many sysplexes). There have been a few occasions were a looping DB2 process or MQ trigger from a devl/qa region made it difficult to keep up, but we did. We really need PFA in place with the SMF flooding warning for those situations because no one realizes there is a problem most of the time until SMF processing happens at night since all the dumps are automatic vie IEFU29. A couple of times there were more than 255 daily GDGs created from offloads and we had to manually code the volsers in MXG JCL. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
