34 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
Tivoli BSM Console Server Version 2 (ASIConsoleServerV2)
The console server handles communication to the IBM Tivoli Business Systems
Manager Java console. It communicates with the database server for any
updates on events and objects, and applies them to all the open consoles.
It also helps maintain all active console sessions to the database server. The
console is a role-based user interface in which you set up roles to determine a
user’s access rights. The roles are: Restricted Operator, Operator, Administrator,
and Super Administrator. The console server in version 2 uses four Windows
groups to categorize the authentication of an operator. An operator who does not
belong to any of the IBM Tivoli Business Systems Manager groups cannot open
the console.
The console monitors resources for state changes and performance
characteristics that reflect availability. If the availability of a resource or resources
is threatened, an alert icon is placed next to the resource or subsystem.
Notification of alerts and events management are the console’s primary tasks. By
observing views, end users can see whether the system, subsystem, or resource
is available and performing correctly.
The Java console connects to the console server through port 80 (http), therefore
it most likely can go through firewalls.
Tivoli BSM Remote Execution (ASIRemoteExecutionServer)
The remote execution server is responsible for starting and stopping the
propagation agent at the request of the propagation agent dispatcher.
Tivoli BSM Enqueue Proxy Server (ASIEnqueueProxyServer)
The enqueue proxy server receives messages that are meant to be processed by
other components or services:
? For the MVS sender service in the event handler server, it puts the message
into the <SMFid>_Upload.que file
? For the propagation agent in the propagation server for events that need to be
propagated, the message is typically put into ROOT-0001.que
The queue file typically resides in the TivoliManagerdataQueues directory.
There are two important commands for queue files: dumpfqueue and dequeue. The
dumpfqueue checks the status of the queue file, while dequeue is used to clean up
the queue file.
Note: If backward compatablity is required for previous IBM Tivoli Business
Systems Manager consoles, you also should load Application Server services.
Chapter 2. Components and functions 35
The syntax for dumpfqueue command is dumpfqueue <queuefilename> as shown
in Example 2-2.
Example 2-2 Sample dumpfqueue result
C:TivoliManagerDataQueues>dumpfqueue AgentListener.que
Name=AGENTLISTENER.QUE CellSize=2048 MaxEntries=70000 HeadOffset=512
TailOffset=512 EnqueueCount=35287 DequeueCount=35287 FlushCount=0 FileEntries=0
SemaphoreEntries=0 Locked=No Empty=Yes
EnqueueCount and DequeueCount indicate queue activity. The EnqueueCount
number should equal the DequeueCount number. The result Empty=Yes indicates
that there is no data currently in the queue.
The syntax for dequeue command is
dequeue -t<timeout> -r<repeat_count> -p<pause_time> -s -v -x <queuepath>
where:
<queuepath> File path to queue (required).
-t<timeout> Dequeue timeout in milliseconds.
-r<repeat_count> Repeat count. Specify -1 for infinite repeat.
-p<pause_time> Pause between operations in milliseconds.
-s Silent operation. Will not output queue entries to stdout.
Useful with binary data.
-v Output all printable data. Useful with binary data. May be
used with -x.
-x Output all data in hexidecimal. Useful with binary data.
May be used with -v.
Propagation agent (ASIPAgent.exe)
The propagation agent calculates the propagation events that must be performed
and updates the database server. See 3.4, “Status propagation” on page 87 for
more on the propagation process.
Tivoli BSM MVS IP OS Listener (ASIMVSIPOSListener)
This is the new TCP/IP-based MVS OS Listener that listens to connection
requests from the Source/390 Object Server process from z/OS. It typically
listens at port 1022. When a connection is acheved, it spawns a listener thread to
communicate with the Source/390 object server. You can use the netstat -a |
grep 1022 command to check the connection from port 1022. Our listener is
connected to four z/OS systems as shown in Example 2-3 on page 36.
36 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
Example 2-3 MVS IP listener connection
C:>netstat -a | grep 1022
TCP 3c041:1022 3c041:0 LISTENING
TCP 3c041:1022 wtsc66.itso.ibm.com:1051 ESTABLISHED
TCP 3c041:1022 wtsc64.itso.ibm.com:1556 ESTABLISHED
TCP 3c041:1022 wtsc69.itso.ibm.com:3201 ESTABLISHED
TCP 3c041:1022 bldmvs1.boulder.ibm.com:1031 ESTABLISHED
Tivoli BSM MVS Listener (ASIMVSListenerSvc)
This is the SNA-based MVS listener that waits for the connection request from
the Source/390 object server. It is started as an LU6.2 transaction program by
the TPSTART utility.
The listener process writes in two log files. The first log has the prefix LS and
contains the listener initialization before it knows the z/OS image that contacted
it. The second log has the prefix MVSL and contains the SMF ID of the z/OS that
triggers the listener process. The MVS listener will put the messages it receives
into a queue file. The logs indicate whether TPStart has successfully launched
the listener process and will show whether an SNA session has been established
through the SNA server to the host.
Tivoli BSM MVS Event Handler (ASIMVSEventHandlerSvc-nnn)
The MVS event handler retrieves the queued MVS listener messages from a
queue file. The queue file name is the same as the SMF ID of the z/OS origin of
the message. It sends the message to the staged event loader in the database
server and notifies the MVS upload rule services to process the message.
Each connected z/OS image has a different event handler process.
Tivoli BSM MVS Upload Rule Server (ASIMVSUploadRuleSvc)
The MVS upload rule server processes the z/OS message and constructs the
appropriate responses to the z/OS components. It is responsible for starting the
various registration processes and starting the object initialization in the
database server.
The upload rule service is dependent on the rule database in ASIRuleSvc
database. The ASIRuleSvc contains shadow data from various z/OS objects in
the Object database for rule processing. This information is created the first time
the upload rule service is started and is recorded in the ObjectSync table. To
re-initiate the collection of information, delete the row in the ASIRuleSvc’s
ObjectSync table.
After creating a new operating system object, run the SQL statement delete
from ASIRuleSvc..ObjectSync and then restart the upload rule server.
Chapter 2. Components and functions 37
Tivoli BSM MVS IP Sender (ASIMVSIPSenderSvc-nnnn)
The replies that are constructed by the various scripts from the upload rule
service are put into the upload queue by the enqueue proxy server. The sender
service is responsible for actually sending them. This IP-based sender service
connects to the Source/390 object server through a typical port (usually 1023,
but in our setup 1023 is used for UNIX System Services login, so we configured
the sender to connect through port 1024).
Each z/OS image has a separate sender service and upload queue files.
Tivoli BSM MVS Sender Svc (ASIMVSSenderSvc-nnnn)
This is the SNA-based sender service that acts as an LU6.2 transaction program.
The behavior is similar to the IP-based sender service.
Tivoli BSM Agent Listener (ASIAgentListenerSvc)
The Agent Listener service is used to receive events from the Tivoli Enterprise
Console. It connects and registers itself to an event enablement process using
the gemeeconfig command for configuration. This component is discussed in
greater detail in Chapter 7, “TEC components integration” on page 209.
Tivoli BSM Health Monitor Server (ASIHealthMonitor)
This service runs the HMSQueries.ksh using the SRVANY.exe from the Windows
Resource Kit. The HMSQueries.ksh runs a set of predefined checks and then
sleeps for 60 seconds.
It retrieves availability data from a variety of sources and produces files that are
used as input to the interface, which the service makes available to health
monitor clients. The collection of input files from a single sample are
concatenated into a single output file called TotalSummary.txt (usually located in
the TivoliManagerMgmtHMSInput directory). Total summary files are
date-stamped and time-stamped and placed in a directory called Output
(TivoliManagerMgmtHMSOutput). This file, which can be viewed using a text
editor, contains a complete snapshot of the working system for that given time
stamp. It can be archived to provide a complete history of how IBM Tivoli
Business Systems Manager servers have performed over a given period.
Note: Chapter 10, “z/OS installation and configuration” on page 331 has more
information about these z/OS communication services.
38 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
The GUI displays these systems health monitor components:
? Database Blocking: Monitors the hosts and processes that cause database
blocks, and alerts system administrators to potentially harmful system
availability problems.
? Database Lock Summary: An adjunct-monitoring window to the Database
Blocking facility. Monitors what database processes are locking database
tables and pages at the time of the sampling interval.
? DB Queues: Monitors the status of the Tivoli Business Systems Manager
database queues, enabling you to determine whether the components
servicing those queues are operating correctly, and checks the status of
propagation and notification.
? MVS Status: Monitors the status of the MVS listener processes, event
handler, and sender services, and monitors the processing of data received
from hosts that are running the Source/390 program.
? PAgent Status: Monitors the status of Propagation Agent processes and the
processing of events by those Propagation Agents.
? Required Services: Monitors the status for all Tivoli Business Systems
Manager services required for Windows-based system availability.
? Server Disk Usage: Monitors the percentage of disk usage on Tivoli Business
Systems Manager production servers by host name and drive letter.
? SQL Response Time: Monitors the performance of key stored procedures that
Tivoli Business Systems Manager users execute on a regular basis.
? Staged Event Status: Monitors the depth and processing of Staged Event
Queues with the Tivoli Business Systems Manager database processing of
the message and exception queues in the database.
Tivoli BSM Common Listener (ASICommonListener)
The Common Listener provides a scalable infrastructure for the integration of
product instrumentation into IBM Tivoli Business Systems Manager. Data is sent
by monitoring product to the Common Listener, which updates the IBM Tivoli
Business Systems Manager database.
More discussion about the Common Listener with IBM Tivoli Monitoring is
provided in Chapter 8, “IBM Tivoli Monitoring integration” on page 249, and
discussion about the Common Listener with IBM Tivoli NetView is provided in
Chapter 9, “IBM Tivoli NetView integration” on page 279.
Conceptual discussion of the common listener process is given in 2.3,
“Distributed resource feeds” on page 45.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.