Chapter 2. Components and functions 63
z/OS mainframe based objects can be either high-level or low-level. The
high-level objects, in order of top-down hierarchy, are:
? Complex
? Machine
? LPAR
? Operating system (OS)
The low-level objects are all the objects below the Operating System, as
described in the physical hierarchy. The low-level object is defined from dynamic
discovery from the subsystems, such as automation product or others.
The high-level bulk discovery involves processing a control file that contains the
structure of each z/OS or OS/390 system. This file usually is created manually.
Our definition is provided in “ITSO_Highlevel - Sample high-level load source” on
page 564. Each line in this file contains the hierarchy of each operating system.
For example, for SC66, we used the following line:
Mainframes/ITSO Enterprise/ITSO//SC66Machine//Primary//SC66/
Mainframes is the name of the enterprise, ITSO Enterprise is its description,
ITSO is the name of the Complex, SC66Machine is the machine, Primary is the
name of the LPARs, and SC66 is the Operating System.
The high-level load uses the ITSO_Highlevel input file. The format of each line is
simply the name and description of each of the high-level object types separated
by a backslash. When we have a blank descriptions field, it is shown as a double
backslash.
To load the high-level objects into IBM Tivoli Business Systems Manager, a Korn
Shell script was executed by entering the following command at the command
prompt:
sh ASILoad_Highlevel.ksh ITSO_Highlevel.txt
The contents of ASILoad_Highlevel.ksh are shown in “ASILoad_Highlevel.ksh”
on page 560. After the load completed, the Resources view looked like
Figure 2-18 on page 64.
64 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
Figure 2-18 The Resources view after the high-level object load
Subsystem bulk discovery
This process sends the files generated by the pre-discovery job to the MVS IP
listener. The OS/390 program GTMAOPE0 sends the file through TCP/IP to the
MVS IP listener process in Windows NT server. At the end of the file transfer, the
CreateDiscoveryBatch.ksh script is triggered to prepare the file loading into the
database.
The GTMAOPE0 program is controlled by the parameters in the SYSIN file. The
file to be downloaded is in the SYSUT1 file. A sample SYSIN for GTMAOPE0 is
shown in Figure 2-19 on page 65.
Chapter 2. Components and functions 65
Figure 2-19 Parameters of the GTMAOPE0
GTMAOPE0 functions similarly to FTP (File Transfer Protocol). These are some
of the acceptable parameters:
TCP/IP_ADDRESS The address of machine that runs the MVS IP listener.
TCP/IP_PORT Port number for the MVS IP listener; 1021 is the default.
CODEPAGE The codepage of the OS/390 prediscovery file. This
parameter is used when the conversion is needed.
COMMAND Command alias that will be translated by the MVS IP
listener to a certain Windows NT command.
CONVERT Whether to convert the data from the mainframe
codepage to the codepage of the MVS IP listener.
TEXT Whether the conversion is for binary data or text.
FORMAT The format code of the data, indicating what subsystem
the data belongs to.
The ASIMVSIPListenerSvc or Tivoli BSM MVS IP Listener service runs at the
Event Server. It receives the data from the GTMAOPE0. Some parameters have
to be customized in the Windows registry for the MVS IP listener as shown in
Figure 2-20 on page 66.
//SYSIN DD *
TCP/IP_ADDRESS=9.3.187.194
TCP/IP_PORT=1021
CODEPAGE=037
COMMAND=DB2DISCOVERY
CONVERT=NO
TEXT=NO
FORMAT=X'11'
/*
66 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
Figure 2-20 MVSIPListener registry definitions
The following information must be put in the registry:
? The IP port used for the file transfer must be defined in the Port value.
? All the OS/390 IP addresses that connect to the IP listener must be defined as
a value in the ValidClients sub-key.
? The translation of the COMMAND parameter of the GTMAOPE0 to Windows
NT commands must be provided in the CommandAliases sub-key.
The content of the current CommandAliases is shown in Figure 2-21 on page 67.
Chapter 2. Components and functions 67
Figure 2-21 Command aliases
For the CreateDiscoveryBatch command, the -C flag activates the CODEPAGE
parameter, and the -F flag activates the FORMAT parameter of the GTMAOPE0
parameters.
When a pre-discovery file is received by the database server, it is saved in the
Windows default temporary directory in a file called ~TVx.TMP, where x is a
hexadecimal sequence number.
This process is executed in three steps:
? The CreateDiscoveryBatch script is triggered at the end of the file transfer. It
prepares the required environment to allow the Discovery Load job. It
renames the temporary files as BCP files and creates a Batch record in the
DiscoveryBatch table.
? The Discovery Load job for each subsystem reads the pre-discovery file and
fills a temporary SQL table with the subsystem objects. These jobs should be
scheduled regularly using the SQL Server Agent. It will trigger the Microsoft
SQL Server BULK INSERT command.
? The Discovery Process job generates the required environment to create
each object in the temporary table. At the end of this process, the job state is
set to COMPLETED in the DiscoveryBatch table. This job can be started
manually or scheduled using the SQL Server Agent, similar to the Discovery
Load job. The Discovery Process job takes a long time to run and consumes a
lot of resources, so you should schedule it to run at off-peak time.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.