Half-track blocking blah blah

Half track blocking may or may not be correct.  Remember, it is a variable length record and VSAM does not do well with those.  The correct CISIZE is a function of what record types dominate the data. In the case of a heavy CICS shop it is usually 16K.  For others it may be half track or something less.  There are routines in MXG that will evaluate the data from a site and make recommendations on the best size to use.

Ken Williams seems to have a view (if I remember correctly - and I probably don't ) that one should block at 32KB for performance. I'd like his take on this here and will be goading him into contributing. I think this is,  BTW, one of the strengths of a wiki. I might even ask the question directly on MXG-L and see if we can get a consensus - even down to wording.

 Ken's View

The default SMF VSAM CISIZE is 4K This does badly, A CISIZEof 26K does much better in terms of reducing the number of IOs. But it does depend on the size of the reords you are writing. SOme sites do well with 16K or 18K CISIZE.

Once the data sets have been dumped they should be half track 27998 on disk and 32K (or 64K if your tapes allow it) on tape. Use DCB=BUFNO=20 whenever copying SMF Data sets. Use AMP=BUFND=64 when dumping VSAM SMF

One area Id like to hear about is keeping generations of daily weekly and monthly  tapes; it doesnt seem sensible at the end of a week to copy all the smf tapes together and throw away the dailies, which ive seen many people do, cos youd need to read a whole weekly just to find something on the dailies, so id expect something like a 30 day daily cycle and a 52 week weekly cycle. How many years SMF data is kep is another question - most people seem to have two years worth

Id also expect people to split up SMF data as early as possible, perhaps at the initial dump stage, so that CICS records go one way, DB2 fgo another, maybe RMF and SMF a third, and RACF a fourth, rather than splitting them later in the cycle.

z/OS Release 9

Not sure if this goes here but here's an extract from the z/OS R.9  Preview:

IBM plans to enhance SMF data management. SMF may be configured to use System Logger to write data to a log stream. This is expected to allow the system to support far higher data
write rates than can be supported when using SYS1.MAN data sets when the Coupling Facility (CF) is used. The use of DASDONLY log streams will also be supported. Also, this
design will allow you to specify that different SMF record types be written to separate log streams, for which different retention periods can be specified. This can help improve both
scalability and SMF data management.