Hi,
IBM certainly understands the requirement from customers to have
IFASMFDL include a delete or clear function. I think it is a serious
mistake to dismiss the entire facility waiting for this functionality.
We recently ordered z/OS 1.9 and I have plans to use SMF to LOGR rather
than MAN data sets on 1.9 without any further enhancements to IFASMFDL.
I will let you know how this works out here and at SHARE.
I think I can leverage what IBM has already provided to eliminate
several operational problems and daily redundant data movement. Maybe
you can too just take the time to consider how what is provided might
work for you.
We deal with large volumes of SMF data and sometimes get floods of SMF
data due to looping transactions, DB2 traces, or other diagnostic
captures or application errors. In order to insure that we don't lose
data of record every LPAR is provisioned with 8 large (49950 tracks) MAN
data sets. Normally we only toggle between 2 dumping and filling but 8
are available before we begin buffering data. Automation alerts and
then alerts louder if these start filling and finally if they fill too
many stop recording "tourist information". Performance data while of
interest to the performance analyst is not required for auditing or
sub-capacity billing. In 9 out of 10 instances shutting off everything
but core data required to recover catalog, report on data access,
process SCRT billing, etc. will prevent us from losing data while staff
intervene. All data is not created equal you need to distinguish between
data of record and data that is interesting but not business critical.
We dump each LPAR MAN data sets to a GDG for that LPAR that are
compressed and striped. Daily all of the LPARs are condensed to a days
worth of data separated into files of CICS, DB2, WLM, MQ, etc. So data
has been written and read twice before it is every used or even if it is
never used. For reasons previously explained I retain WLM type 99
records for at least 10 days in case we need them which means even
though I don't process them normally they are all written and read at
least twice. The daily job that reads all the LPAR data does not start
till 00:30 to make sure the last dumps for the data have completed.
Those dumps have to post the job scheduler to make sure that we get job
demanded in only when we actually get the last data.
This is a Rube Goldberg contraption though one that works well. The
single biggest benefit of SMF to LOGR as provided is reduction in
complexity. Let's look at what I am going to get just by using what IBM
has provided so far.
Today I have an IEFU29 exit and while IBM has provided a similar exit
point I believe that I will no longer need any equivalent exit. IEFU29
will be retired. This is a positive since the business prefers to have
as few user modifications and assembler exits as possible.
Today I write and read data that is only recorded in case it is required
several times wasting processing resources I/O and CPU. In the world of
LOGR I can place type 99 data in a separate logstream which will never
normally be read again unless we want to do an analysis or gather data
for IBM.
Today I write and read all data several times before it is read to be
processed. I can eliminate one read and write without changing any
upstream processes. Since we use compression to conserve DASD this saves
both CPU and I/O bandwidth that is being used just to move data from one
interim storage location to another without actually getting any
benefit.
Today I have to wait after midnight to allow for everything to normally
be ready. I can now start my daily processing of SMF data at 00:01
saving 29 minutes off the existing schedule.
I plan to allow a full day's worth of data to be recorded to LOGR then
read once just after midnight and written into a GDG just as today.
Only the data that is needed to begin processing MICS, MXG, CPExpert,
MVPA, SCRT, reports needs to be extracted before this scan begin. I
save lots of MQ type 115/116 data but MICS does not need it so the
extraction of that data can be uncoupled from the start of MICS
processing. So long as I extract once a day for the full days time the
lack of a clear/delete function is not a problem. I may even save DASD
since I no longer house the interim LPAR GDG and the mostly empty MAN
data sets (1 3390-27 @ LPAR) but instead only the actual data stays in
LOGR till expired which we will probably make 2 to 3 days to insure we
got the extract done. CA-SYSVIEW includes utility function to trim a
logstream which we can use if we need to cleanup after something writes
100 million bad records into SMF from a transaction loop.
I think SMF to LOGR solves more problems than it creates and I intend to
try it on our test Sysplex as soon as we have z/OS 1.9 up and running
stable there.
My biggest concern about SMF to LOGR is how I can easily detect sudden
changes in profile in data recording or flooding. I have requirements
against CA-SYSVIEW but I think this is an area IBM should address in a
similar way to what they have done with the WTO Flood processing and
what is being discussed in the statement of direction for autonomic
detection of common storage use out of profile. I would love to see IBM
provide an exit that could alert on out of profile SMF recording. At
the minimum IBM could provide a new record or exit on an interval with a
COUNT/RATE for active address spaces, system COUNT/RATE, SMF
type-subtype COUNT/RATE. This would allow an installation to more
easily become aware of flooding/looping conditions causing large volumes
of wasteful data to dump into SMF that will be a problem both in DASD
use by LOGR and in downstream processing.
I would also like to see SMF when recorded to LOGR provide access to the
meta data that LOGR provides with better granularity of the time
recorded and a truly unique system/time token. I think this could be
done if IBM documented at a release boundary sites could chose to
present/extract records with a new metadata header. Yes this would
require a lot of code to change but you could not use it or strip it off
if you had to feed one program that you could not update. Machines are
only going to get bigger and faster we need to deal with this sooner or
later.
Best Regards,
Sam Knutson, GEICO
System z Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office) 301.986.3574
Life... is like a grapefruit. It's orange and squishy, and has a few
pips in it, and some folks have half a one for breakfast.
Douglas Adams
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.
----------------------------------------------------------------------
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
