58 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
Figure 2-14 Connection from z/OS to TBSM servers
For the SNA connection, the Tivoli BSM MVS Listener (or ASIMVSListenerSvc)
receives messages or exceptions from the z/OS system. Once the connection to
the z/OS system is established by the object pump, the SNA server and the
Source/390 object server attempt to allocate a conversation. When the
Source/390 object pump is started, it contacts the MVS Listener.
The MVS Listener is an auto-start transaction program. It is started automatically
by the TPSTART program when a message is sent by the object pump after the
connection between the IBM Tivoli Business Systems Manager and the SNA
server is established. It stops when the connection is lost. The transaction
program (TP) name for the MVS Listener is ACC1RCV.
For the IP connection, the Tivoli BSM MVS IP OS Listener
(ASIMVSIPOSListenerSvc) listens to its port, typically 1022. When a connection
is detected, it spawns a thread to handle the communication.
Event Server
SNA Server
SNA Client
MVS Event handler
MVS Listener
TP
Start
MVS Sender
Enqueue Proxy Server
MVS Upload Rule
Server
Upload queue
Receive
queue
Object Server
VTAM
Source/390
programs
(ksh)
Event Server
MVS Event handler
MVS IP OS ListenerMVS IP Sender
Enqueue Proxy Server
MVS Upload Rule
Server
Upload queue
Receive
queue
Object Server
TCPIP
Source/390
programs
(ksh)
Chapter 2. Components and functions 59
After the program is initialized, the MVS Listener begins to receive data from the
z/OS system and looks for the existence of a queue file that has the same
identifier as the z/OS system being monitored. For example, the queue file for
SC66 is SC66.que. If the queue file exists, it begins to insert data into the file. If
the file is not present, the MVS Listener then initializes a message queue file and
begins to insert data into it.
The Tivoli BSM MVS Event handler service (ASIMVSEventHandlerSvc)
periodically checks the message queue file for data. If the data is present, it
reads the message from the queue and inserts it into the database.
There are some commands executed automatically during the startup of
Source/390 following a system IPL or Source/390 restart. These commands
perform such tasks as initializing Source/390, registering objects, and requesting
file status. You can also use the Source/390 command from the IBM Tivoli
Business Systems Manager console using context menus of the operating
system object.
The automatic execution of these commands results in Source/390 sending state
information in the form of messages to the IBM Tivoli Business Systems
Manager servers. Upon receipt of these state messages, the Tivoli BSM MVS
Upload Rule Server service (ASIMVSUploadRuleSvc) evaluates the information,
formulates the proper commands to send, and finally uploads the proper
command or command set to Source/390, where they are executed. The MVS
Upload Rule Server service runs on the Event Server. Upload rule processing is
triggered by the event handler upon inserting the event into the database.
In addition to processing messages regarding the initialization of Source/390, the
MVS upload rule server evaluates other conditions that are of concern to the
proper execution of the Source/390 environment.
When the z/OS upload is enabled, the reply message is sent back to the Event
Server machine through the Tivoli BSM Enqueue Proxy Server
(ASIEnqueueProxyServer), which puts the events in an upload queue file. An
example of an upload queue file in our example environment is
SC66-Upload.que. The Tivoli BSM MVS Sender service (ASIMVSSenderSvc) or
Tivoli BSM MVS IP Sender service (ASIMVSIPSenderSvc) checks the queue
files and sends the message back to the Source/390. For the SNA connection, it
uses the ACC1RECV transaction program, which invokes the ACC1RECV
program in the object server address space. For the IP connection, it will connect
to the object server listening port, which typically is 1023.
60 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
2.4.3 Object registration process
In this section, we discuss in more detail the object registration process, which is
a conversational mechanism from the object pump to the IBM Tivoli Business
Systems Manager input component for getting an automated status of any z/OS
object.
Figure 2-15 shows a flow chart of the initial connection of the Source/390 to the
IBM Tivoli Business Systems Manager input component.
Figure 2-15 Initial conversation for TBSM connection
The message exchange is conducted in an internal form. You can peek on the
messages in the queue files that are used by the Listener and Sender services.
These queue files are stored in TivoliManagerDataQueues, and are named
after the z/OS system that they belong to. For example, SC66 has a listener
queue called SC66.que and a sender queue called SC66-Upload.que.
The message is separated into fields with the backslash character (, ASCII
x’5C’, EBCDIC x’E0’) and ended with a tilde character (~, ASCII x’7E’, EBCDIC
x’A1’). The first two fields are named the format type and action type fields. The
format type and action type fields uniquely differentiate the messages for usage
and field contents. A sample message is given in Figure 2-16 on page 61.
01/01
OS identification
02/12
Variable creation
ENT - COMP - MACH -
LPAR-OS
02/04
Request objects
02/05
TrapCreation
All object traps under
the OS (STC, batch,
DB2,IMS, CICS etc)
02/09
Omegamon
For each Omegemon
objects
02/10
Batch Registration
02/15
TDQ Registration
02/20
RMF Registration
including each metrics
in RMF profile
OS/390 -> WinNT
WinNT -> OS/390
Chapter 2. Components and functions 61
Figure 2-16 Sample message
In the case of an STC resource called NPM in our SC66 operating system, we
can see the data exchanged as shown in Figure 2-17.
Figure 2-17 Queue file contents
The object registration event occurs in the following sequence:
1. When the object pump is connected to the listener, it sends the identification
noting the timestamp of the event and that the operating system name is
SC66. The event is received by the MVS listener and stored to the database
through the MVS event handler.
2. The variable registration messages are sent by the MVS sender services.
3. Upon receiving the variables, the object pump sends the indication that it is
ready to receive the list of objects to be monitored using the 02 4 record by
sending the SC66 OS’s object ID.
4. ASIMVSUploadRuleSvc evaluates the message received by the listener and
puts the appropriate reply message into the upload queue.
ASIMVSSenderSvc reads the SC66-Upload.que file and sends it to the object
pump.
Format type - Action type fields
02 Functional command
05 Object monitoring
Tilde, end of messageA typical field
04 Field type object identification
rest data
data sent from OS/390
data sent to OS/390
1
2
3
4
5
62 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
5. When the event that is trapped occurs, the object pump initiates the 02 1
message to inform the status change of the affected object.
The following is a list of commonly used field identification:
00 Timestamp in the format of YYYYMMDDHH:MM:SS.UUUUUU
02 Object type ID, similar to the content of cid column in
obj_class table
03 Object name.
04 Native key. A unique 10-character object identification that
is constructed of the hexadecimal value of the object ID
and the class ID.
45 State. The value that will go to the state attribute of an
object.
46 Message ID that is trapped. This must also exist in the
MessageDescription table.
49 Description text.
By evaluating the queue files and the IBM Tivoli Business Systems Manager log
files, you may be able to determine the problem in the object registration process.
2.4.4 Bulk discovery
For z/OS operation, we explain two types of bulk discovery related to populating
the IBM Tivoli Business Systems Manager object hierarchy with resources:
? Bulk discovery of z/OS high-level resources from preformatted files to load to
the database.
? Bulk discovery using dynamic discovery of subsystems and sending the
information through the MVSIPListener
Bulk object discovery: high-level load
IBM Tivoli Business Systems Manager’s operation is based on the objects that
represent the relevant system resources within an enterprise. Therefore, an
exhaustive discovery of all system resources is a critical step in the successful
implementation of the product.
Initial object placement for the z/OS mainframe is critical. A set of hierarchy
resources must be defined in the IBM Tivoli Business Systems Manager
database, and the initial hierarchy that defines the Operating System object must
be present before any work can be performed. The high-level load presets this
hierarchy.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.