Contributed by Michael Livingston, Principal Software Engineer as CA Technologies
When I wrote the first article in this series about CA SMF Director Substreams, I posted a link to it on my Facebook page to help spread the word. And while it garnered some attention from mainframe co-workers, both past and present, it also got a response from a classmate of mine from high school. She’s very intelligent but she wondered what terms like these meant: DUMPOPTIONS, STREAMOPTIONS, RETPD.
It was then that I realized I was flying at about 5,000 feet over the product and there are probably more folks who want the 35,000 foot view. Yes, Substreams are very helpful, but unless there’s some context, the article means nothing.
So, for those of you who have CA SMF Director installed and running, thank you, and you can probably skip this article because you’re already familiar with what’s here. For those of you, who are not familiar with SMF Director, stick around. Things are going to get interesting.
SMF Data Management
Everyone who is involved in running a mainframe data center knows about SMF (System Management Facilities) data in some context or another. The performance analyst uses it as a tool for determining how things have been running and the data center manager uses it to determine who is accessing, using, or misusing the resources, etc. The folks who use the data need the SMF data on a timely basis for processing, and they need to be able to get to the data from yesterday and even further in the past. Of course, finding and accessing that older data can be complicated, even if you know exactly where it is, because locating one day’s worth of data in a monthly SMF file takes time.
Since the data is critical, and in some cases required, to be kept to meet auditing compliance guidelines, you need an effective method for managing it. Most data centers developed such methods many years ago and they run, and run, and run. All good, but what if something changes? Are the people who set up the SMF management system in the 1990s (or 1980s) still with the company?
If the solution was developed in the 1980s or 1990s, then it likely consists of dumping the SMF MAN files when they fill up, and probably once a day, copying all the dumps into a single dataset with all of the day’s SMF. When that’s done, there’s probably at least one future roll-up of the data (weekly, monthly, etc.). The data is written and rewritten over and over again.
The older solution is working but SMF is definitely changing. Over the past decade, more and more SMF data is being generated and SMF MAN files must be dumped more frequently. Larger records are being produced and more and more of them are being produced. It is possible that SMF data is being lost as well due to the heavy production of the data. IBM introduced SMF logstream recording to handle the load by allowing SMF to write to multiple logstreams at once, reducing the single record bottleneck that is present in traditional SMF MAN files.
I am sure that many data center managers are looking at SMF logstreams as a way to eliminate the bottleneck. And that means creating a very new, very different SMF management method. Meanwhile until then you’re going to have to keep all the older SMF data in the datasets created by the old methods, meaning that for a good length of time (years most likely) you will have two different SMF management solutions in the data center.
CA SMF Director as an SMF Management Solution
With all this change, a single solution would be nice. CA SMF Director can manage SMF data from systems using the traditional MAN files and systems using logstreams simultaneously. It also tracks the SMF data it is managing and knows where it is for easy retrieval. This way, people who need to access SMF data can do so without knowing where the data is, and they don’t need to write a program or complicated control statements for the IBM SMF Utility to get at the data.
An Example
Here is a typical job that will gather up RMF data out of CA SMF Director’s archive for a single system for the first seven days of 2014. This job is written assuming that SMF Director is installed in the system link list, and that the person submitting the job has access to the appropriate data sets:
This job obtains all of the RMF records (types 70 through 70) generated on SYS1 for the first seven days of 2014 and writes them to a dataset named OUTPUT.SMF.DATA. Whether the data is recorded to logstreams or to a MAN file, whether it is archived on virtual tape, real tape, or even DASD doesn’t matter. The only thing the performance analyst needs to know is the system (or systems), the time range, and the record types.
This is all good for the person needing the data, but additionally, there are other things going on behind the scenes. Since SMF Director has been keeping an index of all the data and where it is located, there are no large files to access and read through to get the data. SMF Director will efficiently access files in its archive that contain data from the time range indicated, and only those archive files that contain records of types 70 through 79 inclusive.
In Conclusion
SMF management is changing: changing in volume, changing in scope, changing in scale. Mainframe datacenters need to change as well to meet the changes that are coming. If CA SMF Director is your SMF management solution, then a large portion of the changes can be handled automatically, and there will be an increase in efficiency in managing the data. In the end, it will also save resources and money.