On Wed, 26 Mar 2008 09:38:10 -0700, Skip Robinson <[EMAIL PROTECTED]> wrote:
>We've had occasional episodes of lost data. > >One case, which we think we've fixed via changes to automation, is the >other side of the event-driven nature of MANx management. A strength of >traditional SMF recording is that you dump and clear a MANx cluster in >response to a message saying that it needs dumping. That's why you don't >have to worry much about whether you've collected ten hours or ten minutes >worth of data. You dump whatever's there, clear the file, and move on. A >problem crops up when you IPL with all defined SMF data sets in need of >dumping. They're not necessarily 'full'; they just can't be opened because, >well, who knows why. I've seen MANx data sets at 1% that nonetheless >require dumping. Go figure. But if all MANx data sets are full at IPL, data >starts getting buffered. In our shop, the messages that should trigger >dumping come out before our automation product has hit the ground. Our >so-far-untested automation change is to trigger a dump when buffering has >reached a certain threshold. Without that additional check, you can lose >data when you run out of buffers. > >Another case is harder to deal with. We dump straight to tape. Once in a >while we have an extended tape outage for hardware or software maintenance. >Of course we could code for this situation by writing first to DASD, then >to tape. Heck, we could write a whole subsystem. Ad infinitum. > >System Logger in principle handles all these cases by its nature. As SMF >records flow, Logger captures them and writes them to DASD. A new offload >data set is allocated as often as necessary: once a day or once a minute. >The full-at-IPL condition simply goes away. Logger never gets full. If tape >is unavailable for some period of time, records simply accumulate until a >dump job can eventually be run. > >The worst fallout of SMF data loss is that all records are treated alike. >It's simple FIFO, records you need, records you might like to have, records >that may or may not prove crucial down the road. You capture them all until >recording is impaired, then you lose everything. The current complexity of >managing Logger offload data is presumably temporary, although no relief >has actually been announced. Given the well known historical problems with >MANx data sets, I still think Logger is worth the effort today. > >. >. >JO.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >626-302-7535 Office >323-715-0595 Mobile >[EMAIL PROTECTED] > > > > "Vernooy, C.P. - > SPLXM" > <[EMAIL PROTECTED] To > .COM> [email protected] > Sent by: IBM cc > Mainframe > Discussion List Subject > <[EMAIL PROTECTED] Re: SMF System Logger - limitations > .edu> of MANx > > > 03/26/2008 12:44 > AM > > > Please respond to > IBM Mainframe > Discussion List > <[EMAIL PROTECTED] > .edu> > > > > > > >"R.S." <[EMAIL PROTECTED]> wrote in message >news:<[EMAIL PROTECTED]>... >> Mark Zelden wrote: >> [...] >> > As mentioned... lots in the archives about this (even before the >recent >> > threads). >> > >> > 1) Speed of offloading (being able to keep up with records being >written). >> IMHO I can live with it (YMMV). In case of SMF (expected & accepted) >> flood I can use more MANx datasets as a spill. > >This is not the solution: I have seen occasions where records are >presented to SMF faster that SMF can write them to MANx. This will cause >SMF to run out of buffers with records lost as a consequence. > >Kees. > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html Two points for consideration: 1) a possible technique for avoiding SMF data loss (such as SMF 101s or 116s -- you can decide an approach and types considered non-critical) is to setup an automation rule that fires when the SYSLOG message occurs, stating "SMF is at 75% BUFFERS..." (message IEE986E). The SET SMF command would then enable an alternate SMFPRMxx member deactivating some subset of non-critical, large-volume contributor SMF record type(s), such as SMF 101s. At some point, the condition is relieved and the normal production SMFPRMxx member would be re-enabled in a similar fashion, or after some defined time-period. 2) the issue of duplicate SMF data occurring across IFASMFDL (SMF Logstream enabled) dumps (see note #1 below) still does not get addressed, without requiring a secondary data-filter pass (and/or sort with noduplicates). Some would say that this duplicate-data condition is unacceptable, given the extra data handling required. And it doesn't have to be linked to any accounting/chargeback scenario, either. Scott Barry SBBWorks, Inc. _________________________ Note #1: most concerning is intraday dumping, for example, using CA MICS Incremental Database Update feature -- although MICS will reject any data already processed. Links: BUFSIZMAX, BUFUSEWARN, and NOBUFFS - Specifying SMF buffer options (mind any broken URL): http://publib.boulder.ibm.com/infocenter/zos/v1r9/topic/com.ibm.zos.r9.ieag20 0/buffopt.htm ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
