This page describes how you can manage SMF record production by z/OS and some of the subsystems.
z/OS
At the z/OS system level SMF record production is controlled using the SMFPRMxx member of SYS1.PARMLIB, and by the SET SMF and SETSMF operator commands. (To use the z/OS command SETSMF, either PROMPT(ALL) or PROMPT(LIST) must be specified in the SMFPRMxx member.) SMF can additionally be customised using installation-written exits.
SMFPRMxx
Here's a sample SMFPRMxx member (from Anonymous). This one specifies the records to include, rather than exclude
ACTIVE
DSNAME(SYS1.MAN1,SYS1.MAN2,SYS1.MAN3,SYS1.MAN4,SYS1.MAN5)
LISTDSN
SID(&SYSNAME(1:4))
DDCONS(NO)
REC(PERM)
INTVAL(15)
NOPROMPT
MAXDORM(1500)
JWT(0030)
SYNCVAL(00)SYS(TYPE(0,2:7,14:18,20,21,26,28,30,32,33,38,39,41,42(6,15:18),
44,50,61,62,64,65,66,70:79,80(67,75:76),81:83,85,88,89(1,2),
90(19:20,29),92(1:9),94,100:102,110,115,118:119,128,144,154,155,
200,201,202,208,217,220,221,230,231,234,235,248,249,250,255),
EXITS(IEFACTRT,IEFU83,IEFU84,IEFUJV,IEFUJI,IEFUSI),
INTERVAL(SMF,SYNC),NODETAIL)
SUBSYS(STC,EXITS(IEFACTRT,IEFU83,IEFU84,IEFUJV,IEFUJI),
INTERVAL(SMF,SYNC))
SUBPARM(IXFP(250,2,5,7))
SUBPARM(SLS0(SUBTYPE(1-8,10,11,13,14,16,17,18,19,26,27)))
STATUS(SMF,SYNC)
SET SMF and SETSMF Operator Commands
By specifying the SMF=xx parameter of the SET operator command you can change which SMFPRMxx member of SYS1.PARMLIB is in effect.
The SETSMF operator command is much more flexible, allowing an installation to add a SUBPARM parameter or replace any previously-specified parameter in the active SMF parmlib member except the ACTIVE, PROMPT, SID, or EXITS parameters. The SETSMF command cannot add a parameter to the active SMF parmlib member. (It is recommended you use the "SS" short form of "SETSMF" to avoid confusion with the SET SMF command.
Example:
This example sets the parameters for started tasks such that record types 0 to 127 are produced (deemed "System types") and that the SMF interval will be 30 minutes.
Installation-Written Exits
Further Reading
Comments from Ken Williams on what to collect and SMFPRMxx options. Needs splitting up and moving to the appropriate places.
I'd suggest the following SMF records are out of date - 4 5 34 35 - and the following are mostly voluminous and useless - 40, 99 - so in general all these should be switched off. One exception might be record 99/6 that is created on an interval basis and contains real dispatching priorities for all Service Classes.
The dataset open close 14 15s and activity 42a are useful, but voluminous, so if you arent using them then they can also be switched off.
Many people write the interval accounting records at 59 minutes after the hour so that there isn't contention between these and the device records.
If interval records are synchronized with RMF records it becomes much easier to calculate the uncaptured CPU time and hence the capture ratio
Most people have INTERVAL(15) although I have seen 30 and 60.
Careful if you have both DDCONS(NO) and DETAIL. Can cause storage creep especially with DB2
DDCONS(NO) recommended to avoid long delays at shut down of long running started tasks like DB2
Some zOS subsystems collect extensive performance measurements and create their own SMF records, for example:
- CICS - Type 110
- DB2 - Types 100, 101 and 102
- DFSORT - Type 16
- HTTP Server - Type 103
- MQSeries - Types 115 and 116
- Web Sphere Application Server - Type 120
These record format and content usually is described in one of the manuals for a particular subsystem, but SMF Manual has links to these manuals.
DB2
DB2-originated SMF records are written by the following trace types. These types are further refined into trace classes.
- Statistics - Types 100 and 102
- Accounting - Type 101
- Performance - Type 102
As you can see two different trace types can lead to the same SMF record type. In fact these are distinguishable by their IFCID (almost a record subtype, though the IFCID number field is not in the standard SMF record subtype position. Each trace type can write multiple distinct IFCIDs.
These traces and classes are enabled in a number of different ways:
- At DB2 subsystem initialisation the converted contents of the DSNZPARM member is read. The following parameters therein control Statistics and Accounting trace production:
| Parameter |
Description
|
| SMFSTAT |
Statistics Trace Classes
|
| SMFACCT |
Accounting Trace Classes
|
| STATIME |
Interval (in minutes) between writing Statistics Trace records
|
- Traces can be dynamically started and stopped...
STATIME And DB2 Statistics Trace
The STATIME DSNZPARM parameter determines the length (in minutes) of the Statistics Trace recording interval. The default is (a pretty useless) 30 minutes. For serious performance reporting purposes 5 minutes (or even 1 minute) is preferable...
Many fields in the Statistics Trace records are counters. These are initialised to 0 when the DB2 subsystem is started. They are not reset on the Statistics Trace interval.
In the following discussion it is assumed we're talking about a single DB2 subsystem, whether it's part of a Data Sharing group or not.
To calculate the number of occurrences in a (Statistics Trace) recording interval you subtract the values of the counter from neighbouring intervals. When summarising at an hourly level you subtract the value in the first record in the hour from the last.
With a STATIME of 30 minutes you get two records an hour of a given type. If you examine the timestamps of the two records you'll discover the difference between the first and last record is only 30 minutes. Hence the "counter subtraction" calculation misses approximately half the activity. With a STATIME of 5 minutes you capture 11/12 of the activity and with a STATIME of 1 minute you capture about 98% of the activity.
This loss of activity MIGHT not matter but consider two things:
- This is unnecessary loss of accuracy.
- You also lose the ability to see variation if your granularity is too coarse.
The disadvantage of a smaller STATIME is that more SMF records are cut. However Statistics Trace cuts very few records compared to Performance and Accounting Trace.
DFSORT
You can control DFSORT (SMF Type 16) record production at two levels:
- At the system level with the ICEMAC SMF parameter.
- At the invocation level with the SMF OPTIONS parameter.
In either case the options are
| Value |
Effect
|
| NONE |
No SMF 16 record is written
|
| SHORT |
Basic information is written |
| FULL |
Extensive information is written, including data set information
|
With this JCL (from Kjell Lundmark SEB Stockholm Sweden) you can find out which option is in effect for DFSORT:
