Scott B.,

All good points. However, has  CA-SMF Director, nee CA-JARS SMF, nee ManageSMF 
come down in price? IIRC, it was less than $30K in 1985. Last I checked it was 
closer to 10 times that and that was 10 years ago. And it had basically the 
same functionality. For the record, I loved ManageSMF. That is until they 
embedded it into JARS and screwed those of us that had ManageSMF.

I do like the zEDC recommendation and the "frequency of reference" comments.

Thanks for taking the time to reply.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Scott Barry
Sent: Friday, February 09, 2018 10:27 AM
Subject: Re: SMF advice on additional logstreams

Also, for consideration, might there also be "frequency of reference", such as 
security (ACF2, RACF, etc.) and/or DB2 TRACE (SMF 102 types) -- both of which 
may require near real-time access directly from the SMF Logstream, as well as 
after the SMF historical offload occurs?  

Maintaining separate SMF recording/offloading by SMF type provides the 
opportunity for SMS-managed historical data-capture, as a retention-limit.

For a client/site we support, SMF Logstreams are defined/managed by CA SMF 
DIRECTOR using zEDC (8-to-1 compression typical) with DFHSM-managed historical 
(ML0->ML2 directly) data, for up to 5 years -- again, based on SMF type, as 

- DFLT -- all types other than below mentioned,
- CICS / SMFT110 -- includes both CICS CMF and STATISTICS,
- DB2 / T101 -- DB2 ACCOUNTING,
- DB2 / T102 -- DB2 TRACE,
- ACF2 -- security logging events,
- WAS / SMFT120 -- includes WAS and WAS/ODM subtypes,
- MQ / SMFT116 -- excludes SMF Types 115 and 117 (IIB),
- IDMS / T254

And with CA SMF DIRECTOR software deployed, one need not know where an SMF type 
/ recorded-date/time resides, only specify the EXTRACT statement with the 
system (or ALL), type/subtype, date/date/time-range) and the software takes 
care of finding the requested historical data (accomplished via dynamic 
allocation, no JCL-DD coding).  

SMF historical data retention limits are also managed by the software. The 
software also controls awareness with BEFORE/AFTER MAN-to-Logstream migration, 
again not requiring the end-user to know where to find SMF type/subtype, etc.  
Very effective with simplifying and streamlining SMF data management, while 
maintaining auditability and access-limit compliance -- tracking what SMF data 
was recorded, offloaded, when, and who has approved access (via 
program-limitation with security-rules).


Scott Barry
SBBWorks, Inc.

On Fri, 9 Feb 2018 13:16:59 +0000, Richards, Robert B. 
<> wrote:

>I am the OP.
>I definitely appreciate your comments (and everyone else's too), but no one 
>was commented on the other half of my questions. 
>At what point or percentage (records written/space used) would it be advisable 
>to split out 92s, 99s, 120s into their own logstreams? Right now they are all 
>in Default. A coworker tested turning on 120s in WebSphere for an hour and 
>then grew it into an estimated 2 million records that would use 48% of the 
>space after 8 hours. Not sure if  that was one WAS server or more, but that 
>certainly got his attention.
>I realize YMMV, but am canvassing for real world expeeiences here.
>-----Original Message-----
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Scott Chapman
>Sent: Friday, February 09, 2018 7:31 AM
>Subject: Re: SMF advice on additional logstreams
>Remember when looking at SMF volume, record counts are interesting, but the 
>bigger issue is the number of bytes written. 
>We (Peter Enrico and myself) recommend collecting at least 99 subtypes 6, 10, 
>11, 12, and 14. 
>6 is especially important as it's the summary service class period 
>information (every 10 seconds)
>10 is dynamic processor speed changes, which you hopefully don't see
>11 is for Group Capacity limits, and is written every 5 minutes
>12 is HiperDispatch interval (2 second) data which can show you 
>utilization information on a 2 second basis which can be quite 
>14 is HiperDispatch topology data written every 5 minutes or when a 
>change occurs
>The 6s and 12s are in fact high volume in terms of the number of records, but 
>the records themselves are relatively short. In terms of bytes, from what I've 
>seen the subtype 6 is somewhere between 40 and 100 MB of additional SMF data 
>per system per day. Subtype 12 seems to run around 40 to 50MB. I expect that's 
>not noticeable in most environments. Indeed, the type 30s can easily be more 
>data than that. Not to mention the 101s, 110s, and 120s. I actually have a 
>slide on this in an upcoming conference presentation. 
>The other 99 subtypes are used less often and some can be more voluminous than 
>the 6 summary records. If you don't want to record those subtypes all the 
>time, I'm ok with that. But OTOH, if you need them to do a deep dive on WLM to 
>try to understand why things worked the way they did, then having them handy 
>is better than having to turn them on and recreate the issue. We don't 
>formally recommend people keep them enabled, but if it was me, I'd probably 
>keep at least most of them enabled. 
>The 92s are file system information. The subtypes 10 and 11 are written every 
>time a file is opened/closed. In large Websphere Application Server 
>environments I've seen these being very voluminous. I haven't looked at them 
>lately, but my recollection from quite some time ago is that directory 
>traversal (at least in the HFS file systems) triggered these records as well. 
>I've seen the 92s in such an environment being much more voluminous than the 
>99s. In that environment, I did have the 92s turned off because of this.
>There are relatively new subtypes (at least 50-59) in the 92s, that may be why 
>the OP is seeing more 92s. It looks like possibly useful information if you're 
>tuning zFS performance, but I personally haven't spent any time yet 
>investigating them. 
>Scott Chapman
>On Thu, 8 Feb 2018 16717:47 +0000, Allan Staller <> wrote:
>>Not sure about SMF92, but SMF99 are "WLM decision records".
>>Yes they are large volume, but somewhat indispensable.
>>Generally when there is a WLM problem it is extremely difficult or impossible 
>>to reproduce.
>>If the SMF99's are not available "during the problem" it is virtually 
>>impossible to debug.
>>IMO, SMF99's should be recorded.  I know Cheryl Watson and others may 
>>My US$ $0.02 worth,
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to with the message: INFO IBM-MAIN
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to with the message: INFO IBM-MAIN

For IBM-MAIN subscribe / signoff / archive access instructions, send email to with the message: INFO IBM-MAIN

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to with the message: INFO IBM-MAIN

Reply via email to