Creating Configuration Items for unique address spaces
Creating an object statement
You create an object statement for each unique object that you want to add to the MDZTTD00 member. You can comment out the default definitions for objects that you do not want to discover.
You enclose an object statement in the XML tags <object> and </object>.
The XML data in an object statement is case-sensitive. The XML tags (for example, <type> and </type>) must be lowercase, and the data itself (for example, CICS) must be uppercase.
The following table describes the various definitions in an object statement:
Definition | Description |
---|---|
<type>...</type> | Object (address space) type definition The following types are reserved in the default object members:
You can specify any new type to include the type value in the Discovery data. You cannot code the same type value twice. |
<class>...</class> | Address space definition
If the object you are defining does not clearly fit into any of these classes, define the class as APPLICATION. |
<sysplex>...</sysplex> | Address space affinity definition Valid values are as follows:
Default <sysplex> values for specific types of servers are listed in MDZTTD00 default values. |
<vendor>...</vendor> | Name of the vendor that provides the software that runs in the address space |
<pgmid>...</pgmid>1 | Program name that is specified in the PGM= statement of the JCL for the object that you want to discover The program name is a mask field that specifies which address spaces should generate an instance of this CI. The pgmid mask is matched to the value specified in the PGM= statement of the JCL. The mask uses a question mark (?) to represent any single character and an asterisk (*) to represent any number of characters. For example use IEB* for any program starting with the characters IEB, and ASMBLY?0 for a program such as ASMBLY10, ASMBLY20, ASMBLYA0, and so forth. |
<cmdnm>...</cmdnm>2 | USS command name that runs as a process under USS for the object you want to discover The command name is a mask field that specifies which processes should generate an instance of this CI. The mask uses a question mark (?) to represent any single character and an asterisk (*) to represent any number of characters. For example, the following cmdnm statement discovers all processes with the command names is "FTPD", "ftpd", or "/usr/sbin/ftpd". <cmdnm>FTPD</cmdnm> |
<include>...</include>1 | (Optional) Mask for the names of jobs or started tasks you do not want to discover The following example creates CIs only for started task PRODPAS running program MDZ9DZ00: <object> <type>PAS</type> <class>RESOURCE</class> <vendor>BMC</vendor> <pgmid>MDZ9DZ00</pgmid> <include>PRODPAS</include> </object> |
<exclude>...</exclude>1 | (Optional) Mask for the names of jobs or started tasks that you do not want to discover Normally, a CI is created for all CICS regions that are found. You can use an <exclude> statement to exclude a job or task. In the following example, the started task named TESTCICS is not discovered: <object> <type>CICS</type> <class>TRANSACTION</class> <vendor>IBM</vendor> <exclude>TESTCICS</exclude> </object> The following example creates CIs for any started task that is running the program MDZ9DZ00 except for the started task named TESTPAS. <object> <type>PAS</type> <class>RESOURCE</class> <vendor>BMC</vendor> <pgmid>MDZ9DZ00</pgmid> <exclude>TESTPAS</exclude> </object> |
<parm>...</parm> | (Optional) Mask of a command parameter used to start either an STC or USS process. You can specify more than one <parm>...</parm> sequence for a given object. The special mask characters are as follows:
To extract values from the command parameter, use the following current mask variables:
The returned version field is a combination of the $VER[.$REL][.$MOD] extracted strings. In the following example, the <parm> statement discovers all address spaces that have MjeJvmTestSuit.jar as part of its start command, such as /shrd/java/J8.0_64/bin/java -jar /shrd/HOME/lib/MjeJvmTestSuit.jar. It also extracts 8.0 for the version string. <parm>java/J$VER_$VAR/MjeJvmTestSuit.jar</parm> |
<subtask>...</subtask> | (Optional) Mask for a subtask name that is specified as running under the job or started task name that you want to discover. You can specify more than one <subtask>...</subtask> sequence for a given object so that you can have multiple subtasks represent a given object. The mask special characters are as follows:
In the following example, the subtask statement discovers all address spaces with a subtask name that begins with IWMWBBR. <subtask>IWMWBBR*</subtask> |
<addrtype>...</addrtype> | (Optional) Address space type of the object that identifies the type of work an address space contains For example, you can use STC for a Started Task address space: <addrtype>STC</addrtype>
The following address space types are available:
|
<dzs_parms>...</dzs_parms> | (Optional) BMC Discovery for z/OS input parameters |
<dzs_interval>...</dzs_interval> | (Optional) Defines the interval in minutes within which the discovery data collector runs |
<dzs_min_age>...</dzs_min_age> | (Optional) Defines the minimum age in minutes for an address space to be discoverable |
<dzs_max_swap>...</dzs_max_swap> | (Optional) Defines the maximum number of address spaces which will be swapped in during a discovery run |
</dzs_max_log>...</dzs_max_log> | (Optional) Defines the maximum number of 1,000 lines to read when processing an SDSF job log. Valid values are between 1 through 999999. The default value is 100, representing 100,000 lines. |
<dzs_rexxout>...</dzs_rexxout> | (Optional) Defines the data set name to be used to debug system REXX programs |
<dzs_rexx>...</dzs_rexx> | (Optional) Defines if system REXX programs can be executed during a discovery run
|
<xpgm>...</xpgm> | (Optional) Extensible program statement that you can be use to further qualify or obtain information about an address space You can specify more than one <xpgm>...</xpgm> sequence for a given object to combine multiple statements. For more information, see Using-the-xpgm-object-statement. |
<dzs_db2cmd> | (Optional) Specifies whether Db2 command can be processed during a discovery run. Valid values are YES and NO. The default value is NO for both MVI Discovery (CAS) and Discovery for z/OS (PAS). You can use this definition to process the Db2 command issued to retrieve the Db2 group name. To use this definition, you must grant the MVI Discovery (CAS) and Discovery for z/OS(PAS) userid with the authority to run the Db2 command. |
<dzs_db2prf> | (Optional) Defines the prefix value for the issued Db2 command. The default value is -. To update the Db2 command prefix, set this parameter to a value as defined in the Db2 system. You can use this definition to process the Db2 command to retrieve the Db2 group name. To use this definition, you must grant the MVI Discovery (CAS) and Discovery for z/OS (PAS) userid with the authority to run the Db2 command. |
1.Within a single object, you can have multiple exclude or include statements, but not both.
2.Within a single object, you can have multiple pgmid or cmdnm statements, but not both.
MDZTTD00 default values
Server class | Object type | Vendor | Object description | Sysplex value |
---|---|---|---|---|
TRANSACTION | CICS | IBM | CICS region | YES |
TRANSACTION | IMSTM | IBM | IMS Transaction Management | YES |
DATABASE | IMS | IBM | IMS Database server | YES |
DATABASE | DBCTL | IBM | DBCTL server | NO |
DATABASE | DB2 | IBM | Db2 server | YES |
APPLICATION | WASAPPS | IBM | MQ Application Server | YES |
APPLICATION | WASDMGR | IBM | MQ Deployment Manager | YES |
APPLICATION | WASNAGT | IBM | MQ Node Agent | YES |
APPLICATION | WAS | IBM | MQ Undetermined | YES |
APPLICATION | MVCAS | BMC | Coordinating Address Space | NO |
APPLICATION | MVLAS | BMC | Logon Address Space | NO |
APPLICATION | DZPAS | BMC | Discovery Agent Address Space | NO |
APPLICATION | MVPAS | BMC | Product Address Space (MVI) | NO |
APPLICATION | SSPAS | BMC | Product Address Space (BBI2) | NO |
APPLICATION | RTCS | BMC | Runtime Component System server | NO |
APPLICATION | TOM | BMC | Total Object Management server | NO |
APPLICATION | MVLOG | BMC | Logger server | NO |
APPLICATION | SYSLOG | IBM | SYSLOG server | NO |
APPLICATION | MVTA | BMC | Transaction Analyzer | NO |
MESSAGE | MQS | IBM | Runtime Component System server | YES |
MESSAGE | IMSCONN | IBM | IMS Connect server | YES |
MESSAGE | CICSGTWY | IBM | CICS Transaction Gateway server | NO |
SECURITY | RACF | IBM | RACF server | NO |
SECURITY | ACF2 | CA | ACF2 security server | NO |
SECURITY | TSS | CA | TSS security server | NO |
COMMUNICATION | VTAM | IBM | VTAM server | NO |
COMMUNICATION | TCP | IBM | TCP/IP server | NO |
COMMUNICATION | HTTP | IBM | HTTP server | YES |
COMMUNICATION | NETVIEW | IBM | NETVIEW server | NO |
COMMUNICATION | MVHTTP | BMC | Host server | NO |
RESOURCE | IRLM | IBM | IRLM server | NO |
RESOURCE | CQS | IBM | CQS server | YES |
RESOURCE | DBRC | IBM | DBRC server | YES |
RESOURCE | INETD | IBM | INETD server | NO |
RESOURCE | MIM | CA | MIM server | NO |
RESOURCE | HSM | IBM | HSM server | NO |
RESOURCE | USS | IBM | USS server | NO |
JES | IBM | JES server | NO | |
INFOPRNT | IBM | INFOPRNT server | NO |
Changing the <sysplex> value
For information about the <sysplex> values, see <sysplex></sysplex>. However, changing the scope also changes the attributes of the class that are stored in BMC CMDB. One of the attributes that is changed is BMC_ComponentAliases, which is used in the Service Impact Manager (SIM) product to ensure that events impact the correct CIs in a service impact model.
Therefore, changing the <sysplex>...</sysplex> value can affect whether events impact a CI or not, which could have serious operational ramifications. You create the following object values:
<type>CICS</type>
<class>TRANSACTION</class>
<sysplex>YES</sysplex>
<vendor>IBM</vendor>
<pgmid>DFHSIP</pgmid>
</object>
- This object statement results in a BMC_ComponentAliases value of CICS-BBPLEX01-BCVCD640.
<type>CICS</type>
<class>TRANSACTION</class>
<sysplex>NO</sysplex>
<vendor>IBM</vendor>
<pgmid>DFHSIP</pgmid>
</object>
- This object statement results in a BMC_ComponentAliases value of CICS-BBPLEX01-SJSC-BCVCD640.
The change in the BMC_ComponentAliases value means that events trapped in the BMC Impact Integration for z/OS (BMC II for z/OS) product with existing rules and sent over to the SIM might no longer cause the correct CI in a SIM model to be impacted. In the rule that traps an event in BMC II for z/OS, you might need to modify the new Component Alias value on the BA or AE panel if it is not provided by the QCA.QSERVER.serverName variables provided by BMC Discovery for z/OS. Therefore, if you change any default <sysplex> value in the MDZTTD00 member, you make sure that the Component Alias value is still valid in each rule for associated events that you are trapping in BMC II for z/OS.