what are the pros/cons of using CA SMFDIR logstreams over MAN files?
There are many pros and not too many cons for going to SMF Logstream recording for the SMF data. I'll start with the cons first, because there aren't that many and one of them is a big one.
The main reason not to go to logstreams is a simple one. Most customers have a working SMF management scheme that works well for their situation. As long as you're not losing SMF data (which shows up with console messages and the presence of SMF Type 7 records) then the migration to SMF logstreams requires some time and effort to come up with a system that will replace and already working system. And in many cases, the existing SMF MAN file systems have been in place for decades and the person who set it up is no longer with the company.
The pros for logstream recording however, can far outweigh the cons in several respects. With the MAN files, only one SMF record is recorded at a time, due to the sequential nature of the MAN files. With logstreams, you can set up several logstreams for recording and record different record types to different logstreams, increasing the potential throughput for SMF data. And as we all know, the volume of SMF data only goes down if you turn off some record types in your system. There always seems to be more and more data. And, in terms of the performance, the I/Os for the logstream data sets are faster than the MAN file I/Os.
Some products do require their logstreams to be backed in the coupling facility, but SMF logstreams do not have this requirement if you are pressed for coupling facility space.
Additionally, logstream recording offers the capability for SMF Data Integrity, through the use of SMF Digital Signatures which are newly available with z/OS 2.2. The signature records can be produced while the data is being recorded so that when the data is processed it can also be validated.
Finally, new with z/OS 2.3 (and 2.1 and 2.2 with maintenance applied) there is a provided API for accessing the SMF logstream buffers on an application level. This is not available if SMF MAN file recording is being used.
In summary, there is a cost to getting to SMF logstream recording, but once the cost is paid, the benefits kick in immediately. The CA SMF Director product can help make the transition less painful as it supports both modes and can manage the SMF Data in similar fashion no matter the method of recording, and can even be set up for logstream recording on an LPAR before the transition is made. And SMF Director supports some systems using MAN files while other systems use logstreams.
Hope this helps in answering your questions. If you have other questions, or need more information, please reply to the thread.
Principal Software Engineer
CA SMF Director Development
Also, to add to Mike's response, you can leverage SMF DIRECTOR features to help with migrating to SMF LOGSTREAM mode, as well. With SMF DIRECTOR, JCL coding is simplified and further by using SMFD you really don't have to know where SMF history data resides, instead letting SMFD manage the information.
Where you have SUBSTREAMs available as well, SMFD SPLIT files can also help with "special interest" SMF extract files, if needed for studies or other analyses like SCRT, Security, DB2-TRACE, also special studies, for example.
To prepare for SMF LOGSTREAMs though, you will still need to use IFASMFDP to analyze your SMF daily recording behavior with each LPAR, in order to size your LOGSTREAMs, suggesting you go with DASDONLY most often -- IBM provides SMF data-analysis post-process, available on IBM.COM support site.
I'm always encouraging client sites to attempt to move away from native/VTS direct-allocated tape resources and determine if possible to use DFHSM (or other solution) with managing offloaded SMF history files, now that you can parcel the various SMF record types with SMF LOGSTREAMs (i.e., different than legacy MAN processing where all data gets recorded to one respository -- aside from SMFD and SUBSTREAMs) though. By leveraging SMF history migration, you are no longer dependent on "tape environment" to manage SMF data long-term -- allowing SMF DIRECTOR and your CONFIG setup to manage retentions.