SMF OPTIONS Statement

The SMF OPTIONS statement is required. You have the choice of specifying an OPTIONS ???? statement that applies to all system data processed, an OPTIONS statement for specific systems, or a combination of both.
micsrm140
The SMF OPTIONS statement is required. You have the choice of specifying an OPTIONS ???? statement that applies to all system data processed, an OPTIONS statement for specific systems, or a combination of both.
The OPTIONS statement is used to specify:
  • Whether or not to process TSO address space records
  • Whether or not to create the Workload Device Activity (BATWDA) file

Overview

OPTIONS parameter choices determine how certain fields and SMF record types are processed. You can code a generic OPTIONS ???? statement, as well as explicit OPTIONS statements for specific systems.
Each SMF record processed by the analyzer contains a four- byte character field that identifies the z/OS system that wrote the record. This is referred to as the original system name or ORGSYSID.
You should code an OPTIONS ???? statement that reflects the statement choices appropriate for the majority of systems processed by the unit's daily update job. Then code explicit OPTIONS statements for systems whose requirements are different.
If you do not code OPTIONS ???? statements, you must code a SYSLIST statement that lists all ORGSYSIDs to be processed, and additionally code explicit OPTIONS statements for each of the listed systems.
Generic OPTIONS ???? statement
OPTIONS ???? statements are required unless you code both a SYSLIST statement and explicit OPTIONS statements for all systems in the list. The SYSLIST statement is described in the next section.
One set of OPTIONS parameter choices is usually appropriate for all systems processed by the analyzer at your site. To reduce administrator effort, use the OPTIONS ???? statements to reflect these choices, rather than coding explicit OPTIONS and statements for each ORGSYSID.
Explicit OPTIONS STATEMENTS
Explicit OPTIONS statements are optional. Instead of ????, they specify an ORGSYSID value. Explicit OPTIONS statements are used to override the parameter settings specified with the OPTIONS ???? statements for specific systems.
As with most
MICS
PARMS members, the parameters are free-form, but positional. Comments are coded by beginning the statement with an asterisk (*). Blank statements are allowed. All parameters are required.

???? vs ORGSYSID

The first parameter specified in OPTIONS ???? statements is the generic identifier (????). ???? indicates the keyword values coded are to be used for all systems unless overridden with an explicit OPTIONS statement.
In explicit OPTIONS statements, the first parameter is the original system identifier (ORGSYSID). ORGSYSID refers to the four-byte character field that identifies the z/OS system identifier found in each SMF record processed by the analyzer. For more information on ORGSYSID, see Computing System Parameters (SYSID).

Statement Formats

The OPTIONS statement has the following formats:
  • Generic
OPTIONS ???? NOSMFTSO/SMFTSO NOWDA/WDA
  • Explicit
OPTIONS orgsysid NOSMFTSO/SMFTSO NOWDA/WDA
The keywords are described as follows:
SMFTSO/NOSMFTSO (SMF TSO Session Data Handling)
The analyzer processes SMF measurement data for all address spaces, or workloads, that execute on a z/OS environment, including TSO sessions. Another
Broadcom
product,
TPX
PM, creates measurement data for TSO sessions, and serves as a data feed for another analyzer, the
MICS
Analyzer for TSO.
The
MICS
Analyzer for TSO executes as DAY010 in a
MICS
daily update job, and creates unit-level database files for TSO sessions. It also can interface with the
MICS Accounting and Chargeback
Option to bill for TSO session usage.
If your data center wants to use the
MICS
Analyzer for TSO to collect, measure, and charge for TSO session usage, you can instruct the Batch and Operations Analyzer to ignore SMF records for TSO sessions.
MICS
uses TSO measurement data from
TPX
PM and from SMF type 30 and 26 records. This keyword specifies whether or not you want the
MICS Batch and Operations Analyzer
to store TSO data from SMF.
Standard SMF data on TSO is stored in the
MICS Batch and Operations Analyzer
's BAT_TS file.
TPX
PM data is supported by the
MICS
Analyzer for TSO and not in the
MICS Batch and Operations Analyzer
's files. Coding this statement does not affect the
MICS
Analyzer for TSO.
Code either of the following keywords for this statement:
SMFTSO
Use standard SMF TSO records and support the BAT_TS file. Keep TSO measurements from the following record types:
Type 30 Common Address Space Workload subtypes 1, 2, 3, 4, and 5.
NOSMFTSO
Use
TPX
PM data as the only input data source for TSO sessions; do not support the BAT_TS file. Do not keep TSO measurements from the following record types:
Type 30 Common Address Space Workload subtypes 1, 2, 3, 4, and 5.
WDA/NOWDA (Device Workload I/O Activity)
The Workload Device Activity File (BATWDA) organizes I/O- related activity of devices, by WLM Service Class. This information is used by capacity planners for modeling and forecasting. Be aware that creating and maintaining this file is expensive in terms of DASD space and processing time. The BATWDA file is supported only in the DAYS timespan.
The keywords for this statement are:
WDA
Extract device workload I/O activity and use it to build the BATWDA file.
NOWDA
Do not create or maintain the BATWDA file.
Modify the sample SMFOPS member distributed in the prefix.MICS.PARMS library rather than coding it from scratch to avoid syntax errors.
Use the following Installation Preparation Worksheet (SMF Processing Options (SMFOPS)) to collect the data:
+--------------------------------------------------------------------------+ | INSTALLATION PREPARATION WORKSHEET: SMF Processing Options | | | | PARMS Library Member is SMFOPS | | Reference: Section 7.3.1, CA MICS Batch and Operations Analyzer Guide | +--------------------------------------------------------------------------+ | | | | | PROCESSING OPTIONS .......POSITIONAL KEYWORDS......... | | | | ORIGINAL SMFTSO WDA | | SYSID NOSMFTSO NOWDA | | | | OPTIONS _____ _______ _____ | | | | OPTIONS _____ _______ _____ | | | | OPTIONS _____ _______ _____ | | | | OPTIONS _____ _______ _____ | | | | OPTIONS ???? _______ _____ | | | | | | | +--------------------------------------------------------------------------+ | ....5...10...15...20...25...30...35...40...45...50...55...60...65...70.. | +--------------------------------------------------------------------------+
Examples of SMFOPS Definitions and Expected Results
Shown in the examples below is the behavior of the ???? OPTIONS statement when used in combination with the individual OPTIONS statements.
Example 1
o OPTIONS SYSA SMFTSO NOWDA OPTIONS SYSB SMFTSO NOWDA OPTIONS ???? NOSMFTSO NOWDA o ORGSYSIDs from input data: SYSA, SYSB, SYSC o SYSA and SYSB: - Will use standard SMF TSO records and support the BAT_TS file
Example 2
o OPTIONS SYSA SMFTSO NOWDA OPTIONS ???? NOSMFTSO NOWDA o ORGSYSIDs from input data: SYSA, SYSB, SYSC o SYSA and SYSB: SYSA: - Will use standard SMF TSO records and support the BAT_TS file, and no BATWDA file will be created. SYSB: - Will use CA TSO/MON PM data as the only input data source for TSO sessions and will not create a BAT_TS, and no BATWDA will be created. o SYSC: - Will use CA TSO/MON PM data as the only input data source for TSO sessions and will not create a BAT_TS, and no BATWDA will be created.