Defining fields

You can define your own fields, or modify existing fields, for BMC AMI Defender for z/OS.

BMC AMI Defender field definitions are not required for normal installation, configuration, usage, and maintenance of the product. For information about installation, see Installing.

Note

BMC AMI Defender field definitions do not apply to BMC AMI Defender for Db2.

Who should use BMC AMI Defender for z/OS field definitions

As an advanced programmer, administrator, or security analyst, you can use BMC AMI Defender field definitions to create or modify the definition of BMC AMI Defender for z/OS fields. You need thorough knowledge of the concepts and facilities described in this documentation.

Using BMC AMI Defender field definitions, you can do the following:

Define additional event record types for the agent to process (subject to some limitations). For example, you can define the processing of SMF Record Type 4, which is not currently supported by the agent.
Define additional fields in new or existing event record types. For example, you can define the fields of SMF Record Type 4, or additional fields in SMF Record Type 80, which is already supported by the agent.
Change the characteristics of existing fields. For example, the SMFXXSID field, which is the system identifier common to all SMF records, is a character field with the tag SID. You can redefine the SMFXXSID as a hex field, or redefine its tag as SysID.
Change other information associated with fields. For example, for SMF Record Type 80, the X'01' bit of the SMF80REA field is displayed as GLOBALAUDIT. You can change the display to Audited (Global).

For information about DSECT-to-field-definition conversion, see CZADEFBL-parameters.

Working with field definition files

Most users need not be concerned with the field definition files. You might ignore this section unless you meet at least one of the three following criteria:

You are defining custom event fields.
You are using an ACF2 installation with more than 80 bytes of user LID fields. Even if you are an ACF2 installation with more than 80 bytes of user LID fields you might skip this section initially and deal with it later as an advanced topic.
You are using BMC AMI Defender for z/OS Application Program Interface (API) with event records longer than 32768 bytes. Unless you are defining custom events, BMC Support tells you if this criterion applies to you.

Purpose

The Fields Definitions files contain the specifications of most of the events processed and fields formatted by BMC AMI Defender for z/OS. (Some event types and field definitions, such as the Counters, are hard-coded.) The Fields Definition file is not processed by CZASEND.

When the files are processed

The files are processed at BMC AMI Defender for z/OS start-up. Unlike the parameter file, there is no provision for rereading the field definition files without terminating and restarting BMC AMI Defender for z/OS. Any errors (but not warnings) detected while processing the fields definition files cause BMC AMI Defender for z/OS to terminate.

How the files are specified

By default, the Field Definition files begin with member CZDEFINE in the PDS(E) referenced by the CZAPARMS DD statement. You can override that default by specifying DEFS(filespec) in the PARM= parameter when BMC AMI Defender for z/OS starts, or DEFINES=filespec in the z/OS START command.

Example

You could say S CZAGENT,DEFINES='DD:MYDEFS(DEF1)' to make the file be the DEF1 member of the PDS(E) referenced by DD MYDEFS.

The START command and filespec is fully documented in START-command.

Preserving your modifications across BMC maintenance

Do not edit the CZDEFINE member of your parameter file PDS(E), because it is replaced during reinstallation. Instead, make all of your local modifications to CZDUSER1, CZDUSER2 and CZDUSER3 that is not replaced during reinstallation. It is possible to redefine any of the specifications in CZDEFINE by using the RE- forms of the Field Definition statements as described.

See Format-of-parameter-and-field-definition-files.

RE- Forms of the Fields Definitions statements

All of the Fields Definitions statements except CONFIG have a RE- form.

If you code the normal form of a Fields Definitions statement that attempts to define a field that has already been defined, it is an error.

If you code the RE- form that attempts to redefine a field that has not previously been defined it is a warning condition.