Here are some tips to ensure that you are dumping and clearing these critical data sets as fast as possible, and minimizing the overhead from SMF:

• Ensure that you only write the records you need. Consider avoiding types 4, 5, 14, 15, 34, 35, 40, 42 subtype 6, 60 thru 64, 89, and 99 if you aren't analyzing them. Check out your SMS, CICS and DB2 SMF recording options make sure you only generate data for what you need. Often a trace has been set on and never turned off. Remember, most often all this data is being created whether you use it or not, and it's only the writing of it that you get to control. Don't expect to see a great improvement in CPU busy values from turning off records, just a reduction in the speed at which SMF datasets fill up, and the subsequent effort and resources needed to deal with that data.
• Ensure that the CI size of the online SMF data sets are as big as possible; if you don't specify anything when you define them you will get a CI size of just 4096 bytes. Much better options are 26K (26,624) for a 3390 look-alike or 22K (22,528) for a 3380 look-alike. You must also set the logical record size to be 10 less than the CI size. Remember that ALL SMF data sets must have the same CI size so you must change them all at once - you can define them with a batch job then activate them dynamically using the SET SMF= command, or at the next IPL by updating the appropriate PARMLIB member. If you change the default CI size to a near-half-track value it should reduce the number of I/Os to SMF data sets, sometimes some of the busier systems data sets, by a factor of at least 6. Also, set a good value for BUFSP when defining your datasets, a multiple of at least 20 times the CI size will help to reduce the physical I/O rate.
• Make sure you have at least 3 SMF datasets. Look at your IFASMFDP output logs for a day and calculate how much data each one is dumping, and how much you generate in a day. Divide this total by 3 and see if you can allocate files big enough to hold that much data. It won't be exactly accurate as the data will appear in unevenly-sized lumps, so you may need to round up the allocations for some contingency.
• Make sure you have set the SMF recording options you really need. DDCONS(YES) is a favourite for costing a lot of CPU time to consolidate DD information at the expense of writing out more data with DDCONS(NO). Understand that if you use synchronized interval recording you will concentrate processing at those interval boundaries (e.g. with 15 minute synchronization at hour:00, hour:15, hour:30 and hour:45); if you can live with unsynchronized interval recording that processing will still occur, but be spread out over time. Check out what your SMF and RMF interval values are - unless you are actively pursuing some performance problems, and need the interval to be shorter for a while, set it to somewhere in the range of 15 minutes to an hour. This will cut down the amount of data being generated, and also cut down the amount of time used in creating and managing that data.
• Ensure that the data set that you are dumping SMF data to has a block size as big as possible; half track for 3380 or 3390 disks, 32760 for tape/cartridge/virtual tape devices.
• Ensure you buffer the dumping and clearing of SMF datasets efficiently. In your dump job, use AMP =('BUFND=<n>') on your SMF data set when processing it with IFASMFDP. This will give VSAM the ability to read in a whole cylinder's worth of data with a single I/O. Look at a LISTCAT for one of your SMF datasets and find how many Control Intervals fit into a Control Area (labeled CI/CA) - a Control Area in VSAM is a cylinder. Take that value and add 1. For datasets 3380 with the large CI size recommended above there will be 2 CI's per track, or 30 per cylinder (CA), so set BUFND=31. Finally, set BUFNO=20 on the sequential output data set to ensure double buffering of 5 tracks worth of output. That is the maximum that QSAM can cope with, so any more than 20 won't improve things.