FEATURES

Event Monitoring

OperCon V2.0-5 has a powerful Event Monitoring facility which can be used to build a system capable of lights-out operation. Event monitoring can be performed by an interactive OperCon session, but is primarily intended for background operation, when OperCon runs as a detached process.

This facility is controlled by Event-Action Tables, which consist of events, actions and verbs. These are specified using a simple DCL-like syntax in text files created using any standard text editor such as EDT or TPU.

An event is triggered by an OPCOM broadcast having specific characteristics, which include:

• whether the broadcast is a request or not
• the source of the OPCOM broadcast (node::username); the nodename and/or username can be wildcarded
• the text of the OPCOM broadcast; as many lines as are necessary can be specified, the match can be based on entire lines or on substrings, and can be case-sensitive or case-insensitive

Thus an event can be as specific as a single OPCOM broadcast, or could be as generic as required, in fact, an event could be created which matches every OPCOM broadcast.

Also, events can be created which are triggered only once, on the first time OperCon encounters a matching OPCOM broadcast. Such events are useful for OPCOM requests, which typically are issued repeatedly until satisfied or cancelled.

Each event invokes a single action. An action is a set of tasks to perform (verbs); a given action can be invoked by multiple events.

A given OPCOM broadcast can trigger multiple events, each resulting in the execution of several verbs, giving the System Manager and Operator great flexibility in organising responses to system behaviour.

OPCOM Interface

When run interactively, OperCon divides the terminal screen into two windows, a message window which displays OPCOM messages, and a command window for command input and error messages. A third window, the request window, is displayed when OperCon detects an OPCOM request broadcast.

Requests are held in the request window at the top of the terminal screen where they remain until satisfied or cancelled. User and application requests are brought to the Operator's attention more reliably because the Operator does not have to pick the request out from among all the other OPCOM broadcasts which typically fill an operator console screen. OperCon's default operation further enhances OPCOM requests by only ringing the terminal bell when a request is detected; other OPCOM broadcasts are displayed silently.

OperCon is especially suitable to mixed MVS + OpenVMS environments, by making an OpenVMS operator console behave more like an MVS console.

REPLY and ABORT commands provide similar functionality to the DCL command REPLY, enabling the Operator to respond to any outstanding OPCOM requests. It is also possible to control which classes of OPCOM broadcast are processed by OperCon, and to show the OPCOM status of the OperCon terminal (similar to the DCL command REPLY/STATUS).

Commands are provided to control the following attributes of each window: jump or scroll, bell or silent, wrap or truncate at the right edge. Also, the screen width can be changed to suit situations where, for example, the majority of OPCOM broadcasts exceed 80 columns in width.

On-Line Help

Full on-line help is available with the HELP command. The help provided includes descriptions of OperCon commands, modes of operation, and hints on how to use OperCon and how to get the most out of the OPCOM interface, e.g. for the BACKUP Utility.

Client/Server Operation

OperCon V2.0-5 can communicate with other OpenVMS systems running OperCon.

OperCon clients receive OPCOM broadcasts from other systems; they can perform event monitoring on OPCOM broadcasts originating on the local cluster as well on those OPCOM broadcasts being received from one or more remote servers.

OperCon servers send OPCOM broadcasts to other systems; they can perform event monitoring on OPCOM broadcasts originating only on the local cluster (i.e. the VMScluster in which OperCon is running), but a single server can service multiple clients. OperCon servers can themselves be clients of other OperCon servers.

This functionality lets OPCOM broadcasts be distributed to any number of nodes on the network, with differing responses on each node, according to the Event- Action tables defined on that node.

Network Protocols

OperCon V2.0-5 has built-in support for DECnet and LAT for communication between OperCon clients and servers. TCP/IP is supported, provided that both client and server nodes are running unning DECnet-Plus with DECnet-over-IP enabled, or MultiNet TCP/IP with DECnet Services for IP enabled.

LICENSING

OperCon is licensed on a cluster-wide basis only (standalone nodes are considered to be a cluster of one node). One OperCon licence is issued for each VMScluster on which OperCon is to be run.

Licences are based on a four-tier structure: Single-user Workstations, Small Systems, Medium Systems, and Large Systems. Multi-user Workstations are considered to be Small Systems. Each node in the cluster is classified according to the 4-tier structure, and the largest licence rating determines the OperCon licence required for that cluster.

© VSM Software Services Pty.Ltd 2003/2004. All rights reserved.

Technical Overview