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
