General SMF record type statement

This statement format applies to SMF 7, 14, 15, 17, 18, 42, 60, 61, 62, 64, 65, 66, 90, 92, 109, 119, BMC Defender and DIAG Statements.

You can find specific IBM SMF record layouts in the IBM z/OS MVS System Management Facilities (SMF) manual. For non-IBM SMF record layouts, refer to the specific vendor documentation.

For information about filter-specification, see FILTER-and-MATCH-parameters.

For information about default subtype severity, see the statement descriptions.

SMF 7 statement	SMF 7 records are written each time all SMF buffers become full (either a result of no available output data sets for SMF to write to or the system generating records at a rate faster than SMF can physically write them). Monitoring SMF 7 records helps to monitor system integrity.
SMF 14 statement	SMF Type 14 records are written each time that a non-VSAM direct access, VIO or tape data set that is defined by a DD statement or dynamic allocation and opened for INPUT or RDBACK is closed or processed by end-of-volume (EOV). PCI DSS and other regulatory standards require that you monitor access to certain data sets. Note Following restriction from the IBM Manual z/OS MVS System Management Facilities (SMF): When PDSs are concatenated the system treats the group as a single data set.That means, you are getting one SMF type 14 record for the open of the concatenated group rather than one for each data set. (This restriction applies only to PDSs and PDSEs, not to sequential data sets. You are receiving one SMF 14 record for each sequential data set in a concatenation.)
SMF 15 statement	SMF Type 15 records are written each time that a non-VSAM direct access, VIO or tape data set that is defined by a DD statement or dynamic allocation and opened for OUTPUT, UPDAT, INOUT, or OUTIN is closed or processed by end-of-volume (EOV). Monitoring SMF Type 15 records can be an important part of File Integrity Monitoring, as it records the modification (or potential modification) of non-VSAM data sets.
SMF 17 statement	SMF Type 17 records are written when a DASD data set (temporary or not) is scratched. Monitoring Type 17 records might play a part in File Integrity Monitoring.
SMF 18 statement	SMF Type 18 records are written each time that a non-VSAM data set defined by a DD statement (either explicitly or implicitly) is renamed.
SMF 42 statement	SMF Type 42 records are written each time that the DFSMS (the Data Facility Storage Management Subsystem of z/OS) macro STOW or DESERV is used to add, delete, rename, or replace a member of a PDS or PDSE, or that the STOW macro is used to initialize (delete all members of) a PDS or PDSE directory. Monitoring SMF Type 42 records can be an important part of File Integrity Monitoring, as most z/OS system parameter files are PDS or PDSE members. Default subtype severity: Subtypes 20, 21, 24 and 25 default to INFORMATIONAL. All other subtypes default to SUPPRESS.
SMF 60 statement	SMF Type 60 records are written when a VSAM Volume Record (VVR) or a Non-VSAM Volume Record (NVR) is inserted, updated, or deleted from a VSAM Volume Data Set (VVDS); Example When a VSAM cluster is defined, closed, or deleted, Monitoring Type 60 records might play a part in File Integrity Monitoring.
SMF 61 statement	SMF Type 61 records are written for any DEFINE requests to Catalog Management Services. Monitoring Type 61 records might play a part in File Integrity Monitoring.
SMF 62 Statement	SMF Type 62 records are written for every successful or unsuccessful opening of a VSAM component or cluster. The information in the SMF Type 62 records complements the File Integrity Monitoring information in SMF Type 64 records.
SMF 64 statement	SMF Type 64 records are written each time that a VSAM component or cluster (including catalogs) is closed, or VSAM attempts to switch to another volume for processing. Monitoring SMF Type 64 records can be an important part of File Integrity Monitoring, as it records the modification (or potential modification) of VSAM components and clusters.
SMF 65 statement	SMF Type 65 records are written for all DELETE requests to Catalog Management Services. Monitoring Type 65 records might play a part in File Integrity Monitoring.
SMF 66 statement	SMF Type 66 records are written for all ALTER request to Catalog Management Services. Monitoring Type 66 records might play a part in File Integrity Monitoring.
SMF 90 statement	SMF 90 records are written in response to certain operator commands. All of the subtypes of SMF 90 default to severity INFORMATIONAL.
SMF 92 statement	SMF Type 92 records are written to record activity (open and close) for mounted file systems and files (zFS and HFS). Type 92 records extend zDefender’s file integrity monitoring to UNIX file system files. Default subtype severity: Subtypes 10, 11, 14, 15 and 16 default to INFORMATIONAL. All other subtypes default to SUPPRESS.
SMF 109 Statement	SMF Type 109 records are written to log USS Syslogd messages.
SMF 119 Statement	If properly configured, TCP or IP writes activity records as SMF Type 119 records. You might want to monitor Type 119 records to maintain an audit trail where individuals and processes accessed resources through TCP or IP. Default subtype severity: Subtypes 2, 21 and 23 default to INFOrmational. Subtypes 1, 3, 20, 22 and 70 default to NOTICE. Subtype 72 defaults to ERROR. All other subtypes default to SUPPRESS.
SMF ABEND-AID statement	Compuware Abend-AID SMF records, by default SMF record type 205, might be written by the Compuware Abend-AID product. See the appropriate Compuware Abend-AID documentation.
SMF APP_AUDIT statement	Compuware Application Audit SMF records, by default SMF record type 220, might be written by the Compuware Application Audit product. See the appropriate Compuware Application Audit documentation.
SMF CORRELOG statement	BMC Defender SMF records, by default SMF record type 202, might be written by the IND$defender product. For more information, see IND-defender.
SMF DIAG statement	The SMF DIAG statement is intended for diagnostic purposes. It defaults to a severity of DEBUG.

Common parameters

SMF 7, 14, 15, 17, 18, 42, 60, 61, 62, 64, 65, 66, 90, 92 or 119

Must be coded as shown.

SMF ABEND-AID(recordtype)

Must be coded as shown. Code a single numeric value between 128 and 255. If recordtype is omitted, it defaults to 205.

SMF APP_AUDIT(recordtype)

Must be coded as shown. Code a single numeric value between 128 and 255. If recordtype is omitted, it defaults to 220.

SMF CORRELOG(recordtype)

Must be coded as shown. Code a single numeric value between 128 and 255. If recordtype is omitted, it defaults to 202.

SMF DIAG(recordtype)

Must be specified as shown. There is no default for the SMF record type. For recordtype code a single numeric value between 0 and 255 indicating the SMF record type you want to monitor. If you code more than one SMF statement for the same record type, then a subsequent SMF statement for the same record type replaces any SMF statement(s) for that record type that came before.

FACILITY(facility-name)

Specifies the RFC 3164 facility that is to be indicated as the origin of the syslog messages corresponding to the indicated SMF records. If you omit this parameter, it defaults to LOGALERT or as shown in the table. If you would like a different facility indicated, code one of the RFC 3164 facility names as listed in Syslog-facilities-and-severities.

SMF Record Type	Default Facility
7	KERNEL
109	SYSLOGD
119	UUCP
CorreLog	LOCAL1
DIAG	SYSLOGD

FIELDs(fieldname…)

Specifies the names of the SMF record fields that are to be transmitted to the BMC Defender Server or other syslog console and the order where they are to appear in the message. Specify one or more of the fields as described in Fields. You might only specify fields appropriate to the SMF record type: that is, you might specify SMF18JBN for SMF 18, but not for SMF 14 or any other record type.

Filter-specification

See FILTER-and-MATCH-parameters.

INHibit

Specifies that the writing of the specified SMF record type to the SMF data sets or logstream is to be inhibited by BMC AMI Defender. The specified SMF record type is processed by BMC AMI Defender, but then inhibited from further processing by SMF.

LOG

LOG(HEX)

Specifies that the selected SMF records are to be logged on CZAPRINT and optionally dumped in hexadecimal and character format. This parameter is intended primarily for diagnostic purposes. Use care in specifying LOG(HEX) as it might generate a large volume of print records, especially if BMC AMI Defender is left running for several hours or more.

PROCess(‘process-tag’)

Specifies the tag that appears at the start of the syslog messages for the indicated SMF record type, following the priority, timestamp and hostname, and preceding the formatted fields. Specify the exact process tag that you want to include in syslog messages including any spaces and punctuation. Process-tag might be any length from the null string (‘’) to 32 characters. If PROCess is omitted, it defaults as indicated and followed by the leading delimiter from OPTIONS DELIM.

SMF record type	PROCess default
7	Data_Lost
14	DS_Input
15	DS_Output
17	DS_Scratch
18	Rename
42	DFSMS
60	VSAM_Volume
61	ICF_Define
62	VSAM_Open
64	VSAM_Status
65	ICF_Delete
66	ICF_Alter
90	System_Status
92	zFS
109	Syslogd
119	TCP/IP
ABEND-AID	Abend-AID
App_Audit	App_Audit
CorreLog	CorreLog
DIAG	Diag

SEVerity(severity)

Specifies the syslog severity (for record types without subtypes) or the default severity (for record types with subtypes). See Syslog-facilities-and-severities. You might also code SUPPRESS. SUPPRESS indicates that the default is that records are not to be formatted and forwarded to the syslog server at all. If you omit SEVerity, it defaults as described under each record type description.

SUBTypes

Specifies one or more SMF record subtypes and the syslog severity to be assigned to them. This parameter is only valid for SMF record types that include subtypes. Record types 7, 14, 15, 17, 18, 60, 61, 62, 64, 65 and 66 do not contain subtypes. BMC Defender SMF records are always written as subtype 1. The subtype defaults for each record type are listed under the description of that record type.

Specify the subtype or subtypes in one or more of the following formats.

subtype

Specifies a single record subtype.

Example

SUBT(1 SEV(NOTICE)) specifies that subtype 1 records are to be forwarded with a severity of notice.

subtype:subtype

Specifies a range of record subtypes.

Example

SUBT(5:9 SEV(SUP)) specifies that all subtype 5, 6, 7, 8, and 9 records are to be suppressed (not forwarded).

SEVerity(severity)

Specifies the syslog severity for the specified record subtypes. See Syslog-facilities-and-severities. You might also code DEFAULT or SUPPRESS. DEFAULT indicates that the severity is to default to the defined severity; SUPPRESS indicates that the specified event records are not to be forwarded to the syslog server at all.

If TRACE(PARM) is in effect, then the effect of any SUBTypes and SEVerity parameters is indicated by message CZA0069I, for instance:

CZA0069I SMF_T42 Maximum Subtype 30
CZA0069I Subtype 0 Severity DEFault
CZA0069I Subtype 1 Severity SUPpress
...

This section provides information about the following topics:

General SMF record type statement

Common parameters

On this page