Based on my first-hand experience, the CA SMF DIRECTOR solution is nothing like 
any predecessor - has not been for nearly 10 years, possibly more.  Any sizable 
z/OS site looking at SMF Logstreams should consider this solution, as an 
opportunity to help with easing migration and also going forward with a 
simplified SMF data management process.

As for pricing, that's always negotiable between client/vendor, based on value, 
satisfaction, and longevity.

Scott Barry
SBBWorks, Inc.

On Fri, 9 Feb 2018 18:00:49 +0000, Richards, Robert B. 
<robert.richa...@opm.gov> wrote:

>Scott B.,
>
>All good points. However, has  CA-SMFiDirector, 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.
>
>Bob
>
>-----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
>To: IBM-MAIN@LISTSERV.UA.EDU
>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 
>follows:
>
>- 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, o e 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 managedyby 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).
>
>
>Regards,
>
>Scott Barry
>SBBWorks, Inc.
>
>
>On Fri, 9 Feb 2018 :3:16:59 +0000, Richards, Robert B. 
><robert.richa...@opm.gov> wrote:
>
>>Scott,
>>
>>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.
>>
>>Bob
>>
>>-----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
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>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 
>>interesting
>>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 <allan.stal...@hcl.com> 
>>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 
>>>disagree.
>>>
>>>My US$ $0.02 worth,
>>
>>----------------------------------------------------------------------
>>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>----------------------------------------------------------------------
>>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
>lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to