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. <[email protected]> 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:[email protected]] On >Behalf Of Scott Barry >Sent: Friday, February 09, 2018 10:27 AM >To: [email protected] >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. ><[email protected]> 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:[email protected]] >>On Behalf Of Scott Chapman >>Sent: Friday, February 09, 2018 7:31 AM >>To: [email protected] >>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 <[email protected]> >>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 [email protected] with the message: INFO IBM-MAIN >> >>---------------------------------------------------------------------- >>For IBM-MAIN subscribe / signoff / archive access instructions, send >>email to [email protected] with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >[email protected] with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
