Limited supportBMC provides limited support for this version of the product. As a result, BMC no longer accepts comments in this space. If you encounter problems with the product version or the space, contact BMC Support.BMC recommends upgrading to the latest version of the product. To see documentation for that version, see BMC AMI Datastream for z/OS 7.1.

Defining fields

You can define your own fields, or modify existing fields, forBMC 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 the 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

fields. You need thorough knowledge of the concepts and facilities described in this documentation .

Using the 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

    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

. (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 the product start-up. Unlike the parameter file, there is no provision for rereading the field definition files without terminating and restarting the product. Any errors (but not warnings) detected while processing the fields definition files cause the product to terminate.

How the files are specified

By default, the Field Definition files begin with member CZDEFINE in the PDS(E) referenced by the CZAPARMSCZPAODD statement. You can override that default by specifying DEFS(filespec) in the PARM= parameter when the product 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 CZDEFINEmember 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 are not replaced during reinstallation. It is possible to redefine any of the specifications in CZDEFINEby 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.

Example

The DEF statement has a form REDEF; the MAP statement is a form REMAP, and so forth. The RE- forms might be used to override the specifications of a previous statement.

Related topic

Field-definition-file-statements

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*