|
System Management Facilities. Function within z/OS which
collects data on all system activities for use in accounting, performance
monitoring, capacity planning, etc. SMF creates log entries (SMF records) of
this data.
- by Edwin Handschuh
- Enterprise Systems Architect
- Independent Consultant
- SoftExcell, Inc.
- eth@softexcell.com
- (215) 783-2208 - cell
Narrative
I designed the SMF capture process to minimize the number of
times the weekly and monthly tapes are appended. I've kept it to once per day.
The trade off is that when we are doing weekly or monthly reporting, the
current day's SMF data will not be included in the weekly and monthly datasets.
However, a combination of the current ...SMF.DAILY(0) and the ...SMF.WEEKLY(0)
or ...SMF.MONTHLY(0) dataset would incorporate all of the available SMF data to
date. My guess is that there will be little need for SMF data as of this
moment, but if required, it is available. As we move through the month run
times will be longer for the SMFDAILY job. In that regard, I've placed the
creation of the new ...SMF.DAILY(+1) dataset in the beginning of the job so it
will not hold up any SMFDUMPs that may occur during the execution of SMFDAILY.
Regarding SMF data loss, I believe I've addressed the
problem by having a ...SMF.SAVEWORK(+1) dataset created each time I unload an
SMF dataset. The SMF data contained in each ...SMF.SAVEWORK(+1) dataset is an
exact copy of the SMF dataset prior to clearing it regardless of whether the
SMF dataset required dumping or not. The ...SMF.SAVEWORK(+1) dataset is not
used in data collection, but instead it is used in case an actual SMF dataset
is deleted or corrupted. Under normal circumstances the ...SMF.SAVEWORK(+1)
dataset would not be used and it will roll off after 100 generations. This will
allow us 33 SMFDUMP runs before we run the risk of any SMF data loss. I feel
this is adequate run-time coverage.
Initially I designed the system to generate a monthly
dataset per LPAR with the naming convention as: ...SMF.MONTHLY.Yccyy-mm, but
since this can't be cleaned up without having some form of REXX, CLIST, or
other program to figure out its expiration, I changed the naming convention to
a GDG dataset with a retention of 19 (18 months + current month).
On a final note, I wanted to create a solution that would be
clean, easily maintained, and problem free. I've utilized the VTS to eliminate
space problems. I've also created a solution that is 100% JCL driven so there
are no REXX, CLIST, or other program code to support. Aside from a few CA-7 and
AutoOps setup issues; there isn't any magic in this capture process. It should
be relatively problem free. For Operations to dump SMF data at any point in
time, all they need to do is issue:
I
SMF
This will automatically trigger an SMFDUMP task. Or if they do
not wish to switch the SMF datasets and just want to take a dump of the
existing datasets, they can issue:
S
SMFDUMP
FLOWCHART (JOBS and Started Tasks)
| |
SMF Switch |
|
At 00:00 or whenever a dataset fills
up. |
| |
|
|
|
| |
S SMFdump
by
Auto Ops |
|
Auto trigger based on SMF Switch Dataset
MSG IEE391A. Dumps all SMF datasets and MODs it to end of Daily tape. |
| |
|
|
|
| |
SMF Daily |
|
Copies DAILY(0) tape to .DAILY.COPY(+1)
tape. Creates new DAILY(+1) | MODs .DAILY.COPY(+1) to .WEEKLY(0) and
.MONTHLY(0) |
| |
|
|
|
| |
SMF Weekly |
|
Runs Sunday morning after SMFDAILY
completes. Creates a new .WEEKLY(+1) tape dataset. |
| |
|
|
|
| |
SMF Monthly |
|
Runs on the first of the month after
SMFDAILY completes. Creates a new .MONTHLY(+1) tape. |
System Documentation
| |
PROCS |
|
Description...
|
| |
|
|
|
| |
SMFSWITCH |
|
Executes IEFBR14 and issues an I SMF
command. This in fact will trigger an SMFDUMP via automation. |
| |
|
|
|
| |
SMFDUMP |
|
Executes the SMFWORK PROC and passes it
the MAN dataset number. The SMFWORK PROC is executed 4 times. Sorts
...SMF.WORK.MANx datasets and appends the output to the ...SMF.DAILY(0)
dataset. Deletes the ...SMF.WORK.MANx datasets. |
| |
|
|
|
| |
SMFWORK |
|
** Executed by SMFDUMP 4 times **
Allocates a ...SMF.WORK.MANx dataset. Dumps the related .SMF.MANx dataset to
...SMF.WORK.MANx. Copies the ...SMF.WORK.MANx to ...SMF.SAVEWORK(+1) regardless
of SMFDUMP condition code. Conditionally clears the ...SMF.WORK.MANx dataset.
If the SMFDUMP step returns a CC>4 then the related ...SMF.WORK.MANx dataset
is cleared. |
| |
|
|
|
| |
SMFDAILY |
|
Creates a new ...SMF.DAILY(+1) dataset.
Copies the ...SMF.DAILY(0) to ...SMF.DAILY.COPY(+1) - This frees the
SMF.DAILY(+1) for SMFDUMP. - ...SMF.DAILY.COPY(+1) can be used as input to MXG.
Appends the new ...SMF.DAILY.COPY(+1) dataset to the current ...SMF.WEEKLY(0)
dataset. Appends the new ...SMF.DAILY.COPY(+1) dataset to the current
...SMF.MONTHLY(0) dataset. |
| |
|
|
|
| |
SMFWEKLY |
|
Creates a new ...SMF.WEEKLY(+1) dataset.
|
| |
|
|
|
| |
SMFMTHLY |
|
Creates a new ...SMF.MONTHLY(+1) dataset.
|
SMF job stream
by
Edwin Handschuh |