Utilizing the OPS/MVS USS component to send messages to a distributed machine via the use of the ADDRESS USS command.
Article ID: 53431
Updated On:
Products
Issue/Introduction
Description:
Requirements, questions and answers regarding using OPS/MVS USS to send a message to a distributed machine.
Solution:
IMPORTANT: This article contains information about modifying the registry.
Before you modify the registry, make sure to create back up of the registry and ensure that you understand how to restore the registry if a problem may occur.
For more information about how to back up, restore, and edit the registry, please review the relevant Microsoft Knowledge Base articles on support.microsoft.com.
The interface between OPS/MVS and Event Management (EM) on z/OS and distributed NSM platforms.
The components to make this interface operational are the OPS/MVS USS component and the Event Manager component of z/OS Common Services. Both pieces need to be in installed to allow OPS/MVS to view and automate the messages that appear on the z/OS EM console and to send messages from OPS/MVS to EM on z/OS or distributed platforms.
The OPS/MVS USS component comes with the base install of the product, but it is not turned on. Refer to the Installation Guide chapter on Installing OPS/MVS ; Optional Installation Tasks; UNIX System Services Base Install to see what parameters need to be defined and details for the startup of USS feature. This feature will enable the OPS/MVS USS servers and subsequently allow the usage of ADDRESS USS commands. These Address USS commands interface with EM by sending messages, replying to outstanding WTORs, and sending commands to both z/OS and distributed EM platforms. OPS/MVS can also access messages that are on the z/OS EM console. This is the function of the OPS/MVS EM message exit called TNEMEVT2. A job called INSTUSEX is provided that will copy the OPS/MVS exit over to the EM directory. A recycle of the z/OS EM CAIOPR component is required to activate the new exit. The installation of the exit allows OPS/MVS to optionally view the z/OS EM messages in OPSLOG and automate these messages by using) USS rules.
The Event Manager component of CA Common Services (CCS) is currently installed under FMID CTN3000. There are several other FMIDs that need to be installed to make the feature operational. Refer to the Installation documentation for CCS for the details. One of the key pieces to the communication between EM's connection to the mainframe and to distribute NSM EM is the CCITCPGW task. This gateway started task coordinates all the CCI connections between the mainframe and distributed machines. There are other subcomponents to the Event Manager. CAIOPR is the one with which OPS/MVS interfaces. The DATACOM/TR Repository is not required for the OPS/MVS ? EM interface. The emstart script which is located in /cai/tngfw/opr/scripts, controls what processes are started for EM. The CA COMMON SERVICES COOKBOOK is an excellent resource for further information.
Questions and answers:
- When the ALERT leaves OPS/MVS and goes into Common Services Event Management, how/what does this?
OPS/MVS interfaces with Event Management using a subset of its ADDRESS USS commands. It does this by issuing API calls to the Event Management API. The OPS/MVS USS server contains settings defining the PATH and LIBPATH environment variables which point to where Event Management was installed. For details on the Address US S commands, see the OPS/MVS Command and Function Reference Guide. - There is a Store-And-Forward (SAF) function used in this process. Is this function part of Common Services Event Management?
Yes, the Store-And-Forward feature is part of Event Management. With this feature activated, any messages that cannot be delivered in real time will be stored for automatic delivery at some later time when the destination applications are once again reachable. Undeliverable messages are stored in a file located, by default, in the directory /cai/tngfw/opr/saf. Once all messages in this file have been sent, the file is automatically erased. By default, when Store and Forward is activated, all nodes are eligible for this feature. If you wish to limit SAF eligibility to specific nodes, you must create a configuration file that lists those node names. Subsequently, only those nodes listed are targeted for SAF. If the SAF configuration file exists but is empty, no nodes are eligible for SAF. Use a text editor to create a SAF.CFG file that meets your particular needs. Further information can be found in the Post-Installation tasks of the CA Common Services Getting Started Guide.
The Store and Forward feature (SAF) guarantees message delivery through the storage and eventual forwarding of messages that cannot be immediately delivered to target nodes (because of network problems, because the Event Manager is not running, and so on). When Store and Forward is activated, the Event Management guaranteed message delivery feature is activated. With this feature activated, any messages that cannot be delivered in real time will be stored for automatic delivery at some later time when the destination applications are once again reachable. Undeliverable messages are stored in a file located, by default, in the directory $CAIGLBL0000/opr/saf. Once all messages in this file have been sent, the file is automatically erased.
During the initial installation of Event Management, the environment variable for Store-and-Forward is set to Y by default. If this feature was not enabled during the installation, it can be enabled at any time by following the steps outlined in the CA Common Services Cookbook, chapter 4, under the section Using Store and Forward.
In order to enable Store-and-Forward in another task such as OPS/MVS, the following environment variables must be set and exported in the USS ENVFILE
CA_OPR_SAF=Y
CA_OPR_SAF_ROOT=/cai/tngfw/opr/saf - How does Common Services Event Management pass on the ALERTS to NSM ? Is this a function of SAF?
The Event Management API uses the information provided by the OPS/MVS ADDRESS USS command and processes it. In the case of a WTO a CCI SEND will be issued to the OPR task running on the distributed NSM machine. This process is not a function of SAF. As indicated above, SAF is an optional function of Event Management to provide additional capability.
Environment
Component: SOPMVS
Feedback
