guide of documentation - bmc software€¦ · web viewdb sdb uc4 server uc4 server primary standby...

USR-USG-005-UCSER-Patrol Date of Origin: 20.03.2003

UC4 KM for BMC Patrol

Author(s): Pogany Revision: 2.63J Status: Ready4Use Security: Public

Responsible for: A. Pogany Authentication: Unapproved Last Update: 20.03.2003

Product Version: 2.63

UC4 KM for BMC Patrol(User document, User’s Guide)

1. Scope

1.1 Identification

This document belongs to “UC4 KM for Patrol” product within the product family “External Connections to UC4”.

1.2 Changes

2.63J:

Chapter 3.8 has been revised and accomplished with the description of the new feature “Events Generated by UC4 KM”.

2.63J_01:

Chapter 2.1 has been revised to show the new relationship of the objects.

Chapter 3.2 has been modified to describe the new strategy for discovering of UC4 systems.

Chapter 3.6 contains new configuration variables.

Chapter 3.7 rearranged and supplemented with new commands

Chapter 3.8.2.2 newly added.

3.01C:

3.02B:

Chapter 5.7.2.2 Tuning: the description of “survival counter” has been added.

1.3 System Overview

“UC4 KM for Patrol” is the UC4 solution for integrating UC4 into Patrol management suite.

1.4 Document Overview

This user’s guide describes the installation, configuration and working of “UC4 KM for Patrol”.

2. Referenced Documents

Print Date: 2023. 05. 24. Page: 1


UC4 KM for BMC Patrol[1] UC4 KM for BMC Patrol revision 2.63J: UCSER-IFD-CON-Patrol-0005.doc

3. Introduction

This paper describes the capabilities of the UC4 KM for Patrol. UC4 KM is designed to achieve two goals. The first is to show the topology of UC4 system and the attributes of the components. The second is to provide a monitoring tool for signalling a warning and/or alarm situation, which has arisen in a component. When the UC4 KM monitoring system fires warning or alarm the topology view helps to find the relevant component.

4. Viewing UC4 Topology and Status

4.1 The Reflection of the Topology of UC4 system in the KM

UC4 UC4

DB SDB

UC4 Server UC4 Server

Primary Standby

UC4 Client Uc4 Client UC4 Client

. . . . . . . . Dialogue Executor Executor

UC4 System

The Topology of UC4 System.

Print Date: 2023. 05. 24. Page: 2



The UC4 KM mirrors the topology above in the following tree view structure:

UC4_SYST

System: “System Name” the 1st system to be monitored

Clients (GO) client group (all clients in GO status)

. “Client Number registered client

Blocked jobs group for all blocked jobs of this client

Blocked job a blocked job

CallOperators group for all CallOperators of this client

CallOp a CallOperator of this client

CallOp

User Trap group for all User traps of this client

UserTrap a User trap of this client

UserTrap

Clients (STOP) client group (all clients in STOP stat.)

Clients (PROD) client group (all Productivity clients)

Server: “Server Name” the 1st server of the system

UC4Database parameter with history

UC4SDB parameter with history

Kernel Errors Reports objects of UC4 kernel error

Executors: Online the group of executors currently active

“Executor Name” the 1st executor of the group

“Executor Name” the last executor of the group

Print Date: 2023. 05. 24. Page: 3



Executors: Offline executors currently not active


.

.


Executors: Productivity executors currently not active


.

.


Server: “Server Name” the 2nd server of the system

System: “System Name” the 2nd system to be monitored

The tree reflects the topology of the UC4 system as a snapshot. The snapshot is periodically updated.

Print Date: 2023. 05. 24. Page: 4



4.2 The Components of the Tree

There are two types of components represented on the tree.

- the applications: all UC4 systems, UC4 systems, servers, clients groups, clients, group of executors, executors, blocked jobs groups, blocked jobs, Call Operator groups, Call Operators, User trap groups, User traps, kernel errors

- the parameters: UC4Database and UC4SDB

All parameters have a history, which is represented as a graph. The graph shows the changes of the parameter values over a period of time.

The applications have attributes. The attributes are shown in the InfoBox of the application.

The attributes of applications are:

System: The name of the system

The starting time of the 1st server of the system

The product name of UC4 DB

The version of UC4 DB

The name of UC4 DB as it is returned by the DB management system

Server: The name of UC4 System the Server belongs to

The name of server

The timestamp of the last modification of attributes

The version of server

The status of server

Timestamp of starting the server

The number of servers connected to this server

The number of executors connected to this server

The number of dialogue clients connected to this server

Average load of the server during the last minute (before update)

Average load of the server during the last 10 minutes (before update)

Average load of the server during the last hour (before update)

The type of server (Primary, Standby)

Status of SRRC

Client: The name of UC4 System the Client belongs to

The numeric value of Client


The state of the Client

Print Date: 2023. 05. 24. Page: 5


UC4 KM for BMC PatrolExecutor: The name of UC4 System the Client belongs to

The name of server the executor is connected to

The name of the executor

The type of executor


The name of the host of the executor

The version of executor

CPU type of the host of the executor

OS type of the host of executor

Version of OS

The JCL type of executor

Timestamp of last connection set-up

State of executor

Timestamp of last ping for getting life-sign

Call Operator: The name of UC4 System the Call Operator belongs to

The numeric value of Client the Call Operator belongs to

The Run Number of the Call Operator

Timestamp of the last update

The symbolic name of the Call Operator

The type of the Call Operator

The explanation text in the Call Operator

The current state of the Call Operator

Blocked Job: The name of UC4 System the Call Operator belongs to

The numeric value of Client the Call Operator belongs to

The Run Number of the Jobplan the blocking job belongs to

The line number where the blocking occurred

Timestamp of the last update

The name of Jobplan the blocking job belongs to

The type of blocking job

The name of blocking job

The Run Number of blocking job

User Trap: The name of UC4 System the trap belongs to

Print Date: 2023. 05. 24. Page: 6


UC4 KM for BMC PatrolThe numeric value of Client the trap belongs to

The type of trap

The severity of trap

The date and time when the trap has been generated

The lifetime of trap; counting from the time of generation

Wstr2, the 2nd string variable of the trap

Wstr3, the 3rd string variable of the trap

Wstr4, the 4th string variable of the trap

Wstr5, the 5th string variable of the trap

Wint3 the 3rd integer variable of the trap

Wint4 the 4th integer variable of the trap

Wint5 the 5th integer variable of the trap

4.3 How to Localise the Component, which is Responsible for a Warning or Alarm

Warnings and alarms are propagated to the upper levels. They appear at the topmost level as well. Starting at the topmost level the route of the signal can be followed downwards until the component that is responsible for the signal is found. The command InfoBox can be used to learn everything about the component.

5. Monitoring of UC4 Exception Status

5.1 Designing and Configuring of Warning and Alarm Strategy

UC4 and UC4 KM co-operate with each other closely to provide a very flexible platform for realising alarm management strategies. In the UC4 system components can be specified as being part of a special interest group named productivity group. Executors and clients can be designated as part of the productivity group. The productivity group is to be used to distinguish between production activities (job plans running to realise your enterprise management goals) and activities under construction (jobs and job plans in test phase). This distinction between a productivity and a non-productivity environment does not influence the behaviour of the UC4 system it only allows the definition of an individual alarm strategy for the productivity environment in the UC4 KM.

Besides the productivity group the Call Operators provide a very flexible tool to signal warning and/or alarm situation. The following attributes of a Call Operator are taken into consideration in the alarm strategy:

a. SNMP trap. If this attribute is not set the UC4 KM is not informed about the Call Operator. These kinds of Call Operators are completely excluded from alarm management.

b. An implicit attribute of the Call Operator is the productivity attribute (productivity or non-productivity) of its client.

Print Date: 2023. 05. 24. Page: 7


UC4 KM for BMC Patrolc. The type of Call Operator (Question, Message, Alarm). The UC4 KM warning and/or

alarm configuration enables the setting of different actions to different types.

d. The explanation text in Call Operators. The UC4 KM warning and/or alarm configuration enables the assigning of actions to explanation texts starting with a given string.

The alarm management decisions made in the UC4 system have to be accomplished in UC4 KM. The settings in the UC4 system provide only the base for alarm management. Please note that when the UC4 system does not provide enough information for UC4 KM then the KM is unable to provide an adequate warning and alarm signalling mechanism. The more information the better. By configuring the KM properly you always have the choice not to use some of the information.

In the UC4 KM configuration, selecting the appropriate parameters in the following statements completes the definition of the warning and/or alarm strategy:

a. When the Standby Server stops, signal as {NONE, OFFLINE, W_WARN, W_ALARM}

b. When there is no Primary Server for more than {int} seconds signal as {NONE, OFFLINE, W_WARN, W_ALARM}

c. UC4 Server kernel errors, signal as {NONE, WARN, ALARM}

d. When UC4 database is not available, signal as {NONE, WARN, ALARM, W_WARN, W_ALARM}

e. When UC4 SDB is dismounted, signal as {NONE, WARN, ALARM, W_WARN, W_ALARM }

f. When SDB, because of failure, unavailable, signal as {NONE, WARN, ALARM, W_WARN, W_ALARM }

g. When a job of a non productivity client is blocked, signal as {NONE, WARN, ALARM}

h. When a job of a productivity client is blocked, signal as {NONE, WARN, ALARM}

i. When a productivity executor is not online, signal as {NONE, WARN, ALARM, W_WARN, W_ALARM}

j. Signal all Call Operators where type is {ANY, QUEST, MESS, ALARM, QUEST|MESS, QUEST|ALARM, MESS|ALARM}{and, or} explanation text starts with string {*,string with wild chars} as {NONE, WARN, ALARM}

k. Signal productivity Call Operators where type is {ANY, QUEST, MESS, ALARM, QUEST|MESS, QUEST|ALARM, MESS|ALARM}{and, or} explanation text starts with string {*,string with wild chars} as {NONE, WARN, ALARM}

5.2 Specifying the Hosts and Host Discovery of UC4

Besides the warning and alarm strategy, the hosts of the UC4 servers should be defined as well as the strategy, which is to be followed when one or more UC4 systems are not available.

Print Date: 2023. 05. 24. Page: 8


UC4 KM for BMC PatrolOne UC4 KM is able to monitor more than one UC4 systems. Each UC4 system might

consist of one or two UC4 servers. If there are two servers the one is the Primary and the other is the Standby. Generally they reside on different hosts.

UC4 systems are defined by a five or three element list. The list contains 5 elements for systems with standby server and 3 elements when the system does not have a standby server.

UC4 system with standby server: [UC4SystemName,

Host1,

Host2,

Port1,

Port2]

UC4 system without standby server: [UC4SystemName,

Host1,

0

Port1

0]

The fields of the global configuration (valid for all monitored UC4 systems) are the following:

a. UC4 Systems: {UC4 SystemName },{ UC4 SystemName } …

Explanation: the name of UC4 system to be monitored. Omitting name or * instructs UC4 KM to discover every UC4 system of Host1 [Host2]. This automatic discovery is provided only for keeping compatibility with previous versions of KM. If there are more than one UC4 systems on the hosts the automatic discovery method might result improper assumption about standby servers. It is highly recommended to provide a separate definition for each UC4 system.

b. IP of 1st Host: {HostName, IP address},{HostName, IP address} …

Explanation: this is a list of host specifications separated by commas. Each specification designates a host where the 1st (or the only one) UC4 server resides. Duplications are not allowed, that is, the hosts should contain different UC4 systems. A host specification is either a symbolic name, in which case a DNS or a host table must exist to resolve name->IP address translation, or an IP address.

c. IP of 2nd Host: {HostName, IP address,0 },{HostName, IP address,0 } …

Explanation: this is a list of host specifications separated by commas. Each specification designates a host where the 2nd UC4 server resides. Duplications are not allowed, that is, the hosts should contain different UC4 systems. A host specification is either a symbolic name, in which case a DNS or a host table must exist to resolve name->IP address translation, or an IP address. If there is no Standby server 0 is to be used. The list should have as many elements as the list in point a. has.

Print Date: 2023. 05. 24. Page: 9


UC4 KM for BMC Patrold. Port on 1st Host: PortNumber, PortNumber ….

Explanation: this is a list of port numbers, separated by commas. It defines the port numbers where the SNMP master agents are listening (on the host of 1st server). This is normally the port 161. There should be a port number for each hostname (point a.).

e. Port on 2nd Host: PortNumber, PortNumber ….

Explanation: this is a list of port numbers, separated by commas. . It defines the port numbers where the SNMP master agents are listening (on the host of 2nd server). This is normally the port 161. There should be for each hostname (point a.) a port number.

In order to define the discovery strategy you should complete the following statements:

f. If no opened SNMP port is on host then {SKIP, POLL}

Explanation: when there is no active SNMP master agent on the host or the IP address of listening port has been incorrectly defined (in point b. or d.) then the opening of a channel to SNMP master agent fails. If the intention is to wait up until the SNMP master agent of the host becomes active, then POLL, otherwise SKIP is to be specified. Be careful with specifying POLL, it suspends the discovery of other hosts on the host list. Default is SKIP.

g. If no UC4 MIB is on host then {SKIP, POLL}

Explanation: when UC4 server has not been started or when the SNMP facility has not been correctly set or activated, then the MIB of UC4 is unavailable. If the intention is to wait up until the UC4 server is started, then POLL, otherwise SKIP is to be specified. Be careful with specifying POLL, it suspends the discovery of other hosts on the host list. Default is SKIP.

h. If any discovery has failed try it again {YES, NO}

Explanation: the strategy to follow when the discovery of one or more host failed, either because the SNMP port was not listening or because the UC4 MIB was unavailable. YES instructs KM to rediscover failed hosts while NO stops discovery. Default is NO.

5.3 Balancing Between Performance and Accuracy (Tuning)

The periodical polling of UC4 MIB, to discover changes, requires system resources, mainly CPU time. Even if, to avoid the performance degradation of the UC4 system, the patrol agent is not deployed on the host of the UC4 server (which is recommended), the processing in UC4 KM might slow down the agent’s host dramatically. The first thought that the more frequent polling provides more accurate status discovery is not always true. As described later, in many cases we use SNMP traps to give a kick for the MIB discovery. It is up to you to find a compromise between performance and accuracy. Accuracy means, in this case, the right in time detection of the alarm and/or warning situation. UC4 KM provides the means to selectively set the polling intervals for different kinds of discoveries.

UC4 fires trap to signal changes in system status or in job processing. If the host of UC4 server is configured properly to send traps to the host of the patrol agent, than the UC4 KM automatically catches these traps and uses them to trigger prompt discoveries. Before switching off the polling of those discoveries, which are triggered by traps, please note that the arrival of traps is never 100%.

Print Date: 2023. 05. 24. Page: 10


UC4 KM for BMC PatrolUC4 KM has the following discoveries:

a. Discovery of UC4 system. It discovers UC4 systems on hosts defined by the configuration variables. The polling frequency can not be changed the application discovery period of the patrol agent is used. Traps do not trigger the discovery.

b. Discovery of UC4 servers. It discovers the servers and the server status changes. This discovery detects if a Primary server goes offline or if a Standby becomes Primary and checks the status of databases as well. The configuration variable /UC4_SYST/PservDiscovery holds the polling period. Traps trigger the discovery.

c. Discovery of online executors. It discovers the online executors of a UC4 system. The online executors do not play any role in warnings and/or alarms they are only used to view the topology of the UC4 system. At start-up the discovery is disabled. The configuration variable /UC4_SYST/PAExeDiscovery holds the polling period. Traps trigger the discovery.

d. Discovery of offline executors. It discovers the offline executors of a UC4 system. The offline executors do not play any role in warnings and/or alarms they are only used to view the topology of the UC4 system. At start-up the discovery is disabled. The configuration variable /UC4_SYST/PSExeDiscovery holds the polling period. Traps trigger the discovery.

e. Discovery of productivity executors. It discovers the executors marked as productivity. The configuration variable /UC4_SYST/PPExeDiscovery holds the polling period. Traps trigger the discovery.

f. Discovery of new clients. The configuration variable /UC4_SYST/PClientDiscovery holds the polling period. Traps do not trigger the discovery.

g. Discovery of blocked jobs. The configuration variable /UC4_SYST/PjobDiscovery holds the polling period. Traps do not trigger the discovery.

h. Discovery of Call Operators. It looks for new Call Operators. The configuration variable /UC4_SYST/PsystCallOper holds the polling period. Traps do not trigger the discovery.

5.4 Specifying Additional Features

a. Output of Error messages: {SYSW, EVENT, POPUPW}

Explanation: the destination for error messages. SYSW means the patrol console output window, EVENT means the generation of a patrol event, POPUPW means a popup window on the patrol console.

5.5 Configuration Handling

Configuration data is stored in configuration files in the form of configuration variables. Patrol agent uses the structured name to designate configuration variables. All configuration variable of UC4 KM start with the prefix /UC4_SYST/. That is UC4_SYST is the root object of each UC4 configuration variable. Every configuration variable has two values, a default and a current. Patrol agent uses the config.default file to obtain the default values and the change file to obtain the current values. Config.default is an ASCII file and can be edited by any

Print Date: 2023. 05. 24. Page: 11


UC4 KM for BMC Patrolordinary text editor, while the change file has proprietary format and the wpconfig utility provides access to it.

In spite of that UC4 KM is able to work without any configuration setting the adding of the UC4 default configuration settings to the agent’s default configuration file is recommended. The only way to use other default values than which are set in UC4.default (shipped with the KM) is to use a text editor and change them. The defaults can be changed at any time but they are activated only after restarting the agent.

If UC4 KM does not find defaults to configuration variables it uses its built-in defaults. The values of built-in defaults are identical to the values in UC4.default. If UC4 KM does not find the current values of configuration variables it generates them from the built-in defaults.

There are two ways to change the values of current settings. One is to use wpconfig to change the values, the other is to use the interactive commands built in the UC4 KM. The only configuration variables which can not be changed interactively are the parameters described in section Specifying the Hosts and Host Discovery of UC4, in point a,b,c,d.

According to the scope of configuration variables there are two groups, the global group (scope is the whole UC4 KM, that is all UC4 systems monitored by the KM) and the UC4 system specific group (scope is only the UC4 system there are specified for). The global variables have the prefix /UC4_SYST/, while the UC4 system specific ones have the prefix /UC4_SYST/”UC4 system name”/.

5.6 Configuration Reference

Notations:

{choice1, choice2,…} : list of possible choices. You should use exactly one choice.

Bold is used to denote defaults.

“|” is used for “or-ing” the values. That is to denote the either-or relationship.

The definitions of the configuration variables are embedded into an explanation text. The explanation text is that, which appears in the commands, but they are not part of the configuration. The configuration contains only the variable names and their values. The variables appear as bold in the definition. Their possible values are at the right side of the “=” sign. For example in the definition:

Hosts of 1st servers /UC4_SYST/IpofFirstServer = {HostName, Ipaddress, localhost}, …

“Host of 1st servers” is the explanation text, “/UC4_SYST/IpofFirstServer” is the variable name as it appears in the configuration file while “{HostName, Ipaddress, localhost}, …” is the definition of the values permitted.

Symbolic constants:

Error Output:

SYSW : output for error messages is the system output window of the console

EVENT : on error a petrol event message is generated

POPUPW : a popup window is used to display the error message. The processing in the script is suspended until the message is acknowledged.

Print Date: 2023. 05. 24. Page: 12



Signal for exception condition:

NONE : no signalling for this alarm condition.

OFFLINE : signal exception condition by setting the object offline.

WARN : signal exception condition by setting the object into warning state.

ALARM : signal exception condition by setting the object into alarm state.

W_WARN : signal exception condition by setting the object into warning state but resume if the exception state is over.

W_ALARM: signal exception condition by setting the object into alarm state but resume if the exception state is over.

Discovery:

SKIP : when the discovery on a host, from any reason, fails jump to the next host on the list.

POLL : when the discovery on a host fails, then repeat discovery until successful.

Call Operator Types:

ANY : all Call Operator types

QUEST : only Call Operators with type Question

MESS : only Call Operators with type Message

ALARM : only Call Operators with type Alarm

NONE : no any Call Operator

UC4 KM global configuration variables:

Host Definitions:

1. Name of UC4 system /UC4_SYST/SystemOnHost = {UC4 system name,*, ””}, …

2. Hosts of 1st servers /UC4_SYST/IpofFirstHost = {HostName, Ipaddress, localhost}, …

3. Hosts of 2nd Servers /UC4_SYST/IpofSecondHost= {HostName,Ipaddress, 0},{HostName,Ipaddress, 0}, …

4. SNMP ports of Primary servers /UC4_SYST/PortofFirstHost= {PortNumber, 161},{PortNumber, 161}, …

5. SNMP ports of Standby servers /UC4_SYST/PortofSecondHost= {PortNumber, 161},{PortNumber, 161}, …

Print Date: 2023. 05. 24. Page: 13


UC4 KM for BMC PatrolError handling:

6. If no opened SNMP port on host then /UC4_SYST/noSNMPPort = {SKIP, POLL}

7. If no UC4 MIB on host then /UC4_SYST/noUC4MIB = {SKIP, POLL}

8. If any discovery has failed try it again /UC4_SYST/hostRestart = {YES, NO}

9. Output for error messages /UC4_SYST/errorDest = {SYSW, EVENT, POPUPW}

Event handling:

10. Generate this event when a blocked job is encountered:the catalogue of event is: /UC4_SYST/BJsetCatalogue = {name, STANDARD}the class of event is: /UC4_SYST/BJsetClass = {class name, 41}the origin in generated event is: /UC4_SYST/BJsetOrigin = {name, BJset}

11. Generate this event when a blocked job proceeds:the catalogue of event is: /UC4_SYST/BJresetCatalogue = {name, STANDARD}the class of event is: /UC4_SYST/BJresetClass = {class name, 41}the origin in generated event is: /UC4_SYST/BJresetOrigin = {name, BJreset}

12. Generate this event when a Call Operator is encountered:the catalogue of event is: /UC4_SYST/COsetCatalogue = {name, STANDARD}the class of event is: /UC4_SYST/COsetClass = {class name, 41}the origin in generated event is: /UC4_SYST/COsetOrigin = {name, COset}

13. Generate this event when a Call Operator has been acknowledged:the catalogue of event is: /UC4_SYST/COresetCatalogue = {name, STANDARD}the class of event is: /UC4_SYST/COresetClass = {class name, 41}the origin in generated event is: /UC4_SYST/COresetOrigin = {name, BCOreet}

14. Generate this event when a User Trap is encountered:the catalogue of event is: /UC4_SYST/UTCatalogue = {name, STANDARD}the origin in generated event is: /UC4_SYST/UTOrigin = {name, UserTrap }remarks: the class of event is UC4 system and trap number specific as defined in UC4 system specific configuration.

UC4 system specific variables:

Warning and alarm handling:

15. When the Standby Server stops signal as /UC4_SYST/"SystemName"/StandbyStopSign = {NONE, OFFLINE, W_WARN, W_ALARM}

16. When there is no Primary Server for more than /UC4_SYST/"SystemName"/PrimaryTimeout = {int} seconds signal as /UC4_SYST/"SystemName"/PrimaryStopSign = {NONE, OFFLINE, W_WARN, W_ALARM}

Print Date: 2023. 05. 24. Page: 14


UC4 KM for BMC Patrol17. UC4 Server kernel errors, signal as /UC4_SYST/"SystemName"/kernelErrorSign =

{NONE, WARN, ALARM}

18. When UC4 database is not available, signal as /UC4_SYST/"SystemName"/DBUnavail = {NONE, WARN, ALARM, W_WARN, W_ALARM}

19. When UC4 SDB is dismounted, signal as /UC4_SYST/"SystemName"/SDBDismountSign = {NONE, WARN, ALARM, W_WARN, W_ALARM}

20. When SDB, because of failure, unavailable signal as /UC4_SYST/"SystemName"/SDBUnavailSign = {NONE, WARN, ALARM, W_WARN, W_ALARM}

21. When a job of a non productivity client is blocked, signal as /UC4_SYST/"SystemName"/genBlockedSign = {NONE, WARN, ALARM}enable/disable event generation: /UC4_SYST/"SystemName"/genBJEvent = {0,1}

22. When a job of a productivity client is blocked, signal as /UC4_SYST/"SystemName"/prodBlockedSign = {NONE, WARN, ALARM}enable/disable event generation: /UC4_SYST/"SystemName"/prodBJEvent = {0,1}

23. When a productivity executor is not online, signal as /UC4_SYST/"SystemName"/prodExeOffSign = {NONE, WARN, ALARM, W_WARN, W_ALARM}

24. Signal all Call Operators where type is

/UC4_SYST/"SystemName"/genCOType = {ANY, QUEST, MESS, ALARM, QUEST|MESS, QUEST|ALARM, MESS|ALARM, NONE} /UC4_SYST/"SystemName"/genCOOper = {and, or} the first word of explanation text is /UC4_SYST/"SystemName"/genCOText = {*, string with wild chars} as /UC4_SYST/"SystemName"/genCOSign = {NONE, WARN, ALARM}enable/disable event generation: /UC4_SYST/"SystemName"/genCOEvent = {0,1}

25. Signal productivity Call Operators where type is /UC4_SYST/"SystemName"/prodCOType = {ANY, QUEST, MESS, ALARM, QUEST|MESS, QUEST|ALARM, MESS|ALARM, NONE} /UC4_SYST/"SystemName"/prodCOOper = {and, or} the first word of explanation text is /UC4_SYST/"SystemName"/prodCOText = {*, string with wild chars} as /UC4_SYST/"SystemName"/prodCOSign = {NONE, WARN, ALARM}enable/disable event generation: /UC4_SYST/"SystemName"/prodCOEvent = {0,1}

26. Signal User Traps where trap number is/UC4_SYST/"SystemName"/UTDefs = {TrapNumber,[eventclass],[lifetime];…}signal INFORMATION type as:/UC4_SYST/"SystemName"/UTISign = {NONE, WARN, ALARM}signal CHANGE_STATUS type as:/UC4_SYST/"SystemName"/UTCSign = {NONE, WARN, ALARM}signal ERROR type as:/UC4_SYST/"SystemName"/UTESign = {NONE, WARN, ALARM}

Print Date: 2023. 05. 24. Page: 15


UC4 KM for BMC Patrolsignal WARNING type as:/UC4_SYST/"SystemName"/UTWSign = {NONE, WARN, ALARM}signal ALARM type as:/UC4_SYST/"SystemName"/UTASign = {NONE, WARN, ALARM}enable/disable event generation: /UC4_SYST/"SystemName"/UTEvent = {0,1}

Polling intervals:

27. Discovery of Servers and databases /UC4_SYST/PservDiscovery = {int}

28. Discovery of Online Executors /UC4_SYST/PAExeDiscovery = {int}

29. Discovery of Offline Executors /UC4_SYST/PSExeDiscovery ={int}

30. Discovery of Productivity Executors /UC4_SYST/PPExeDiscovery = {int}

31. Discovery of Clients /UC4_SYST/PClientDiscovery = {int}

32. Discovery of Blocked Jobs /UC4_SYST/PjobDiscovery = {int}

33. Checking CallOperators /UC4_SYST/PsystCallOper = {int}

5.7 Commands

5.7.1 Commands Global to All UC4 Systems

5.7.1.1 Configuration

Configuration is a command of UC4_SYSTEMS object. Configuration is used to change the parameters of the error output and discovery strategy. The reset to defaults option loads the default values of the configuration file (if they exist) or uses the built in defaults. The reset to default option does not update the configuration file itself. The “make permanent” updates the current values of the configuration file. Please note that, in the configuration command, the settings for UC4 hosts are visible but can not be changed. The only way to change these values is by the editing of the default configuration file or setting the current values by using the wpconfig patrol utility program.

5.7.1.2 Event Configuration

EventConfig is a command of UC4_SYSTEMS object. Event Configuration is used to set and change the parameters of event outputs. The reset to defaults option loads the default values of the configuration file (if they exist) or uses the built in defaults. The reset to default option does not update the configuration file itself. The “make permanent” updates the current values of the configuration file.

5.7.1.3 Restart

Restart is a command of the UC4_SYSTEMS object. Restart is used to put the changes made in the configuration file into effect. To avoid inconsistency, UC4 KM reads the configuration file only once, when starting. Any changes made in the configuration file either manually or by commands, will got into effect only when the KM is restarted. The restart command destroys all UC4 System objects and rebuilds them according to the configuration file.

Print Date: 2023. 05. 24. Page: 16


UC4 KM for BMC Patrol5.7.1.4 Trace

Trace is a command of the UC4_SYSTEMS object. Trace is used to view information about the processing in different KM scripts. Output is the system output window of the patrol console. The trace settings can not be saved in the configuration file. Trace is to be used only to provide additional information for technical support when help is needed.

5.7.2 Commands Specific to a Given UC4 System

5.7.2.1 Configuration

Configuration is a command of the UC4 System object. Configuration is used to change the parameters of the warning and/or alarm strategy. This change effects only the UC4 system the command is started from. The reset to defaults option loads the default values of the configuration file (if they exist) or uses the built in defaults to set the warning and alarm option. The reset to default option does not update the configuration file itself. The “make permanent” updates the current values of the configuration file.

5.7.2.2 Tuning

Tuning is a command of UC4 System object. Tuning is used to change the polling intervals of different discoveries. The changes are local to the UC4 System the command has been started from. But, if the changes are made permanent then the current values of the corresponding configuration variables are updated. This means that after restarting the KM the new values are used for each UC System. The reset to defaults option loads the default values of the configuration file (if they exist) or uses the built in defaults to set the current polling intervals for the UC4 system the command has been started from. The reset to default option does not update the configuration file itself.

While most of the tunings sets the polling interval for different discoveries there is one exception the setting of “survival counter for blocked jobs”. Survival counter has been introduced to eliminate the problem of blocked job latency. During the update of the MIB table for blocked jobs it might happen that a block job is not returned in the answer for SNMP query even if the job is blocked. The survival counter determines the number of query poll cycles, resulting no output about the blocked job, before the job is considered as not being in blocking status anymore and can be removed (deleted) from the console. Every successful query resets the counter. The possible values are 0-3.

5.7.2.3 Prompt Discovery

Prompt discovery is a command of UC4 Server and UC4 System objects. Prompt discovery is used for immediate updating of UC4 view and status. The prompt discovery of a UC4 System can be applied for: servers, clients, call operators and blocked jobs, separately. The prompt discovery of a UC4 Server can be applied for: online executors, offline executors and productivity executors, separately.

5.7.3 Commands Specific to a Given Object

5.7.3.1 Enable/Disable

Print Date: 2023. 05. 24. Page: 17


UC4 KM for BMC PatrolDiscovery->Enable and Discovery->Disable are commands of the UC4 Online and

Offline Executors objects. Enable/disable is used to permit or to prohibit the discovery of executors. The online and offline executors (as opposed to the productivity executors) can never be the source of any warning or alarm signal. The monitoring system does not really need them. To decrease the resource requirements, each executor is an object in the patrol agent address space, and to increase performance required by the discovery of executors the discovery can be switch off. When starting they are switched off by default.

5.7.3.2 Delete

Delete is a command of the UC4 User trap object. The command is used to delete the object from viewing.

5.7.3.3 Delete All

Delete all is a command of the UC4 User trap container objects. The command is used to delete all User traps of the container.

5.7.4 InfoBox

This is a command of each object on the tree, which has a corresponding UC4 object in the UC4 system. These objects are: UC4 System, UC4 Server, Executors, Clients, Blocked jobs, Call Operators and User traps. InfoBox tells everything about the attributes and about the current status of the object.

5.8 Patrol Events Triggered by UC4 Monitoring

5.8.1 Events Generated by Patrol Agent Automatically

During monitoring UC4 activities, the UC4 KM generates Patrol objects and periodically changes their states. Patrol automatically generates Patrol events for these actions. The events are captured, viewed and archived by Patrol Event Manager. Examining these events provides further integration possibility. The most important two objects are the “CallOperator” object and the “BlockedJob” object. The generating of these objects and the status change of these objects can be easily tracked by examining Patrol events. The “origin” field in event refers to the “object ID” the event is derived from. The “object ID” of a “CallOperator” is composed as:

UC4_COP.”UC4 System name”|”Client ID”|”UC4 Object name”|”UC4 run number”

The “object ID” of a “BlockedJob” is composed as:

UC4_JOB.”UC4 System name”|”Client ID”|”UC4 Jobplan name”|”UC4 Job name”|”UC4 Jobplan run number”|”UC4 run number of blocking job”

5.8.2 Events Generated by UC4 KM

5.8.2.1 Blocked Job and Call Operator events

In order to support event based monitoring like Patrol Event Manager or Patrol Enterprise Manager UC4 KM can be requested to generate event in the following cases:

a. When a “BlockedJob” object is generated (a blocking job in UC4 is encountered)

Print Date: 2023. 05. 24. Page: 18


UC4 KM for BMC Patrolb. When a “BlockedJob” object is destroyed (the job in UC4 is not blocked anymore)

c. When a “CallOperator” object is generated (a Call Operator in UC4 is encountered)

d. When a “CallOperator” object is destroyed (Call Operator has been acknowledged)

The command “EventConf” of object UC4_SYSTEMS is to be used to configure the events for each case.

The “EventConf” command provides event reference section for each event type (see Figure 3.8.1). The definition of an event reference means:

a. To name the catalogue, which contains the event definitions (Catalogue).

b. To name the event within the catalogue (Class).

c. To provide a character string that the event will carry in the “origin” field.

The event definitions are completely independent from each other and there are no constraints, which Catalogue, Class or Origin is to be used. The catalogue can be the standard or a proprietary, the Class can be a predefined by Patrol or a new user defined, the Origin can be any ordinary string that a Patrol event can hold in the “origin” field. If you use user defined event (even in the standard catalogue) we suggest to set the “owner” to UC4.

Figure 3.8.1

The events carry the parameters of the setting (Catalogue, Class, Origin) that is current at the time when the event is generated.

The events generated by UC4 KM carry in the description field additional information about the object the event is generate for. This information contains the attributes of the UC4 object (Blocked job, Call Operator) that triggered the generation of that event. The form of how the information is provided depends on whether the default event (STANDARD, 41) special event (STANDARD, 9;11) or any other event is to be used. The content of the event depends on whether the event is generated for a “CallOperator” or for a “BlockedJob”.

a. “BlockedJob” set and reset event:

The attributes of a “BlockedJob” are: system name, client number, jobplan name, job name, jobplan number, job number

Print Date: 2023. 05. 24. Page: 19


UC4 KM for BMC Patrolaa. Event reference is STANDARD (STD, 0), 41:

The event 41 holds only one parameter in the description field that is filled with the concatenation of the attributes:

“system name”;”client number”;”jobplan name”;”job name”

ab. Event reference is special:

STANDARD (STD, 0), 11 used in set event:

Every field of this event is handled specially:

Origin: “jobplan name”.”client number”

Catalog: STD

Class: 11

Type: “ALARM”

Severity: “5”

Argumentn: The event 11 holds 7 parameters in the description field. The format of the field is:

%s of %s parameter '%s' triggered on '%s'. %d <= %f <= %d

Parameters provided: par1: Alarm #1

Par2: global

Par3: “job name”

Par4: “jobplan name”.”client number”

Par5: 0

Par6: “jobplan number”-“job number”

Par7: 0

STANDARD (STD, 0), 9 used in reset event:

Every field of this event is handled specially:

Origin: “jobplan name”.”client number”

Catalog: STD

Class: 9

Type: “CHANGE_STATUS”

Severity: “3”

Argumentn: The event 9 holds 3 parameters in the description field. The format of the field is:

Alert on '%s' from %s parameter '%s' cancelled; exception no longer exist.

Parameters provided: par1: “jobplan name”.”client number”.”job name”

Print Date: 2023. 05. 24. Page: 20


UC4 KM for BMC PatrolPar2: global

Par3: “job name”

ac. Any other event reference:

A user defined event is assumed, which contains appropriate format specification in description field, like:

System = '%s', Client = '%s', JobPlan = '%s', Job ='%s' .

The event is generated with 4 parameters: “system name”

“client number”

“jobplan name”

“job name”

b. “CallOperator” set and reset event:

The attributes of a “CallOperator” are: system name, client number, CallOperator name

aa. Event reference is STANDARD (STD, 0), 41:

The event 41 holds only one parameter in the description field that is filled with the concatenation of the attributes:

“system name”;”client number”;”CallOperator name”

ab. Any other event reference:


System = '%s', Client = '%s', Name = '%s'.

The event is generated with 3 parameters: “system name”

“client number”

“CallOperator name”

While the event definition is always global, valid for all UC4 systems managed by the KM, the switches, which enable or disable the event generation, are UC4 system specific. In the system specific configuration the sections for “Blocked jobs” and “Call Operators” contain check boxes named “Generate Event”. The setting of “Generate Event” enables or disables the event generation relevant for that section. The warning level (ALARM, WARN, NONE) of the section determines what is used in the type field of generated event:

Warning level of section Type field of event

WARN, W_WARN WARNING

ALARM, W_ALARM ALARM

NONE INFORMATION

Print Date: 2023. 05. 24. Page: 21


UC4 KM for BMC Patrol5.8.2.2 User Trap Events

UC4 KM can be requested to generate event also for irregular situations signalled by User traps.

UC4 KM has assumptions about the structure of User Traps. A User Trap should have the following structure:

TRAP NUMBER: TrapNumber

AgentWorkSysID : ”UC4 system name” AgentWorkObject: ”UC4 system name”.”UC4 Server name” AgentWorkString1: UC4 Client ID AgentWorkString2: “any string”AgentWorkString3: “any string”AgentWorkString4: “any string”AgentWorkString5: “any string”AgentWorkInteger1: Trap TypeAgentWorkInteger2: SeverityAgentWorkInteger3: “any integer”AgentWorkInteger4: “any integer”AgentWorkInteger5: “any integer”

TrapNumber: any number but system trap numbers. Suggested 10100-11000

UC4 Client ID: the ID (Client number) the trap is come from.

Trap Type: a field to classify the trap, possible values: INFORMATION (0)

CHANGE_STATUS (1)

ERROR (2)

WARNING (3)

ALARM (4)

Severity: additional information about the severity of event, possible values: any integer

For the sake of brevity the following substitutions are used:

AgentWorkString2 = wstirng2AgentWorkString3 = wstring3AgentWorkString4 = wstring4AgentWorkString5 = wstring5AgentWorkInteger3 = winteger3AgentWorkInteger4 = winteger4AgentWorkInteger5 = winteger5

The command “EventConf” of object UC4_SYSTEMS is to be used to configure the events for User traps.

The “EventConf” command provides event reference section for User traps. The definition of event reference means:

a. To name the catalogue, which contains the event definitions (Catalogue).

Print Date: 2023. 05. 24. Page: 22


UC4 KM for BMC Patrolb. To provide a character string that the event will carry in the “origin” field.

The catalogue can be the standard or a proprietary. Unlike Call Operator or Blocked Job definition User Trap event definition does not contain Class definition. Class is defined individually for each User trap in the UC4 system specific configuration command. The Origin can be any ordinary string that a Patrol event can hold in the “origin” field. If you use user defined event (even in the standard catalogue) we suggest to set the “owner” to UC4.

In order to generate an event UC4 KM collects information from 3 sources:

a. The event catalogue and origin from the event reference,

b. The event class from the trap definition,

c. Trap type and severity as well as the parameters from the trap itself.

The attributes of a “User trap” are: client number, trap type, severity and the parameters.

The parameters are: wstring2, wstring3, wstring4, wstring5, winteger3, winteger4, winteger5

Event generation acts event reference specific, namely when

aa. Event reference is STANDARD (STD, 0), 41:

The event 41 holds only one parameter in the description field that is filled with the concatenation of trap parameters:

wstring2;wstring3;wstring4;wstring5;winteger3;winteger4;winteger5

ab. Any other event reference:


Par1= '%s',Par2 = '%s',Par3 = '%s',Par4 ='%s',Par5 ='%s',Par6 ='%s',Par7 ='%s'

The event is generated with 7 parameters:wstring2

wstring3

wstring4

wstring5

winteger3

winteger4

winteger5

6. Miscellaneous

UC4 KM is applicable for UC4 systems from version 2.60.

7. Prerequisites of Using Patrol for Monitoring UC4

Print Date: 2023. 05. 24. Page: 23


UC4 KM for BMC Patrol1. SNMP services should have already been installed on the host before the installation of

UC4. UC4 should be installed with SNMP option.

2. If one of the prerequisites in point 1 is not fulfilled then a manual setting of the registry and the .ini file of UC4 is required (please call for technical support).

3. The Trap property of SNMP services should be set as community: public, trap destination: the name or IP address of the Patrol Agent that executes the UC4 KM.

4. Patrol Agent should be SNMP enabled and correctly configured.

5. The communication, between the host of the Patrol Agent and the host of the UC4 server, should be permitted for both SNMP trap and query (take care of firewalls).

6. The UC4.defaults (configuration file for defaults) has to be completed with the parameters specific to the working environment and requirements. Please follow the instructions and explanations given in the file itself.

7. The default UC4 KM configuration should be added to the default configuration of the Patrol agent. Placing the accomplished UC4.default before the last line in config.default file can carry this out.

8. Content of Installation Set

- The following knowledge modules and knowledge module list:

"UC_MONIT.kml"

"UC4_SYST.km"

"UC4_SERV.km"

"UC4_DLGS.km"

"UC4_DLG.km"

"UC4_AEXS.km"

"UC4_AEX.km"

"UC4_PEXS.km"

"UC4_PEX.km"

"UC4_SEXS.km"

"UC4_SEX.km"

"UC4_JOB.km"

"UC4_COP.km"

"UC4_KER.km"

"UC4_GLOB.km"

"UC4_JOBS.km"

"UC4_COPS.km"

"UC4_DSERV.km"

Print Date: 2023. 05. 24. Page: 24


UC4 KM for BMC Patrol"UC4_UTRAP.km"

"UC4_UTRAPS.km"

- The default configuration: UC4KMConfig.default

- The documentation you are reading now.

Print Date: 2023. 05. 24. Page: 25



9. Changes in UC4 Global (3.0x)

PatrolKM for UC4 Global is able to monitor systems 2.6x and UC4 Global, at the same time. The changes listed in the next sections are relevant for UC4 Global only. The number in braces is the number of section that has been modified.

(4.1) The Reflection of UC4 Topology in KM

UC4

DB

UC4 CP UC4 CP UC4 WP UC4 WP

Primary

UC4 Client Uc4 Client UC4 Client

. . . . . . . . Dialogue Executor Executor

UC4 System

The Topology of UC4 System.

Print Date: 2023. 05. 24. Page: 26



The UC4 KM mirrors the topology above in the following tree view structure:

There is no SDB anymore. Anything concerning SDB has been removed:

Executors belong to UC4 System not to a Sever of the System:

UC4_SYST

System: “System Name” the 1st system to be monitored

Clients (GO) client group (all clients in GO status)

. “Client Number registered client

Blocked jobs group for all blocked jobs of this client

Blocked job a blocked job

CallOperators group for all CallOperators of this client

CallOp a CallOperator of this client

CallOp

User Trap group for all User traps of this client

UserTrap a User trap of this client

UserTrap

Clients (STOP) client group (all clients in STOP stat.)

Clients (PROD) client group (all Productivity clients)

Executors: Online the group of executors currently active



Print Date: 2023. 05. 24. Page: 27



Executors: Offline executors currently not active


.

.


Executors: Productivity executors currently not active


.


.

.

Server: “Server Name” the 1st server of the system

UC4Database parameter with history

Kernel Errors Reports objects of UC4 kernel error

Server: “Server Name” the 2nd server of the system

System: “System Name” the 2nd system to be monitored

The tree reflects the topology of the UC4 system as a snapshot. The snapshot is periodically updated.

(4.2) The Components of the Tree


- parameter UC4SDB

- Server attribute: Status of SRRC

There are new server types CP, WP and PWP; no standby anymore:

- Server attribute: The type of server (CP, WP, Primary WP)

Print Date: 2023. 05. 24. Page: 28


UC4 KM for BMC Patrol(5.1) Designing and Configuring of Warning and Alarm Strategy

There is no Standby Server anymore. Anything concerning Standby has been removed:

l. When the Standby Server stops, signal as {NONE, OFFLINE, W_WARN, W_ALARM}


m. When UC4 SDB is dismounted, signal as {NONE, WARN, ALARM, W_WARN, W_ALARM }

n. When SDB, because of failure, unavailable, signal as {NONE, WARN, ALARM, W_WARN, W_ALARM }

(5.2) Specifying the Hosts and Host Discovery of UC4

There is no Standby Server anymore. Anything concerning the 2nd Server (Standby) has no relevance anymore:

i. IP of 2nd Host: {HostName, IP address,0 },{HostName, IP address,0 } …

j. Port on 2nd Host: PortNumber, PortNumber ….

(5.6) Configuration Reference

There is no Standby Server anymore. Anything concerning Standby has been removed:

UC4 system specific variables:

Warning and alarm handling:

34. When the Standby Server stops signal as /UC4_SYST/"SystemName"/StandbyStopSign = {NONE, OFFLINE, W_WARN, W_ALARM}


35. When UC4 SDB is dismounted, signal as /UC4_SYST/"SystemName"/SDBDismountSign = {NONE, WARN, ALARM, W_WARN, W_ALARM}

36. When SDB, because of failure, unavailable signal as /UC4_SYST/"SystemName"/SDBUnavailSign = {NONE, WARN, ALARM, W_WARN, W_ALARM}

(5.7) Commands

(5.7.2) Commands Specific to a Given UC4 System

Executors belong not to a UC4 Server but to UC4 System:

(5.7.2.3) Prompt Discovery

Prompt discovery is a command of UC4 Server and UC4 System objects. Prompt discovery is used for immediate updating of UC4 view and status. The prompt discovery

Print Date: 2023. 05. 24. Page: 29


UC4 KM for BMC Patrolof a UC4 System can be applied for: servers, clients, call operators and blocked jobs, separately. The prompt discovery of a UC4 Server can be applied for: online executors, offline executors and productivity executors, separately.

Print Date: 2023. 05. 24. Page: 30