----- Original Message -----
From: "Edward Jaffe" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
Sent: Friday, February 01, 2008 8:26 AM
Subject: Re: Managing system logger data
Skip Robinson wrote:
Here's the problem. IFASMFDL does most of what IFASMFDP does (and more),
but what it *doesn't* do is clear out the dumped SMF data.
You might recall, during a certain period of singing and drinking in which
you were present, this issue being pointed out to Mr. Jones as he
presented this (then) new function. It was also brought up each time Mr.
Jones presented at a certain TDM I regularly attend. Notes were taken.
But, each new iteration of the presentation seemed to confirm that no
change was ever made. Now that it's GA, perhaps someone will take an APAR?
What I did was take an IXGSLOGR exit we already had with the DELETE function
implemented), and modified it to handle the SMF buffer format. The format
isn't difficult. Writing the exit is an interesting exercise (they convert
all abends to a S001, I ended up debugging my usual 0C4 abends from the MVS
trace table entry.) Deleting data using the logger macros is easy, IXGBRWSE
will return the blockid for each block read, pass the blockid to IXGDELET to
delete everything less than the blockid. The blockid appears to be an RBA
(or something very similar).
I had written an etr about IFASMFDL reading the entire logstream. The
eventual response was that I was in error. Having unwisely deleted the doc,
I carefully reran my testing and was unable to recreate the problem.
Hate it when that happens.
The rest of this is some logger stuff I've learned. If you already know, or
don't care, this is a good place to punch out.
We have a policy of DASD changeout every five years, so every few months I
get
a call because a staging dataset won't move from an otherwise cleaned off
volume.
This normally involves me cycling an address space I wrote. But for SMF,
that
isn't going to be an option. Right now it looks like doing a switch back to
MAN dataset recording, and then switching back to logstream. If you do it
too
quickly, logger may not have gotten around to deleting the old staging
dataset,
and will go to using the old one all over again. So it needs to be a "stop
the
logstream"; "check if the staging dataset is gone", "start the logstream"
sort
of activity. System REXX comes to mind.
If you don't code DSEXTENTS in the logger couple dataset definition, then
you
can have 168 log datasets. LS_SIZE is in 4K blocks, so 4K * 168 * LS_SIZE
minus a fudge factor [1] is how much data you can get into the logstream.
Once
the logstream is full, a return/reason code goes back to the invoker of
IXGWRITE. So the results will depend on the invoker. In the case of SMF, I
would expect the same results as if the MAN datasets were full.
If you do code DSEXTENTS then sizing becomes a sysplex wide activity. Once
the 168 dataset slots dedicated to a logstream become filled, the logstream
can then use slots from the DSEXTENTS. Each slot is another 168 datasets,
but the DSEXTENTS are shared among all the logstreams defined in the couple
dataset.
So, even if you define each system in the sysplex as DASD-ONLY, once you
exceed 168 log datasets, you are now using slots from a sysplex wide pool.
Any logstream defined as GROUP(PRODUCTION) can use at least 75% of this
pool.
Any logstream defined as GROUP(TEST) can use at most 25% of this pool.
The only way to change DSEXTENTS is to format a new logger couple dataset
and
do the switching thing.
Since LS_SIZE will control the actual size of a dataset out in SMS land,
there
is a reason to keep it relatively small (about 75 cylinders in our shop.)
Having a small dataset size will cause the number of datasets to go up for
any
given amount of data. Which will then be a cause for coding DSEXTENTS.
Without DSEXTENTS, you can limit problems to whatever logstream that may
exceed
data expectations. With DSEXTENTS, you can happily propagate logstream
capacity
issues around your sysplex.
Given the SMF spikes I've seen when somebody makes a booboo, I would want a
lockdown method of getting data out of the SMF logstream now [2].
[1] Fudge factor is a scientific term meaning "I don't know"
[2] Now is a management term meaning "Is it done yet?"
Lance
----------------------------------------------------------------------
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
