This section contains the following topics:
Ensure that CA OPS/MVS Is Enabled for Capturing These Events
CA 1 provides seamless integration with CA OPS/MVS by automatically communicating both active status events and heart beat events to CA OPS/MVS. The enabling technology for this is through a generic event API call that CA OPS/MVS provides the other mainframe products so that they can communicate events to CA OPS/MVS.
You do not need to do anything for CA 1 to enable this event communication interface to CA OPS/MVS. If CA 1 and CA OPS/MVS are active in the same z/OS image, CA 1 automatically communicates these automation events to CA OPS/MVS.
By generating active status events CA 1 and other CA products are able to communicate to CA OPS/MVS’s System State Manager (SSM) component when they are starting, up, stopping or down.
SSM is a built-in feature that uses an internal relational data framework to proactively monitor and manage started tasks, online applications, subsystems, JES initiators, and other z/OS resources including your CA mainframe products. SSM compares the current state of online systems, hardware devices, and the other resources with their desired state, and then automatically makes the necessary corrections when a resource is not in its desired state. This provides proactive and reactive state management of critical resources.
Before the CA OPS/MVS interface existed, CA OPS/MVS could automate active status events for your CA products; however this typically required monitoring unique messages for each CA product. With this interface, CA OPS/MVS can capture these events for any of your CA products with a single automation event rule.
With the heart beat event, CA 1 can communicate a normal, warning, or problem overall health status and reasoning to CA OPS/MVS on a regular interval. Once CA 1 begins generating heart beat events for CA OPS/MVS, CA OPS/MVS can also react to the lack of a heart beat event from CA 1, treating this as an indication that there is either a potential problem with CA 1, or there is a larger system-level problem that is taking place.
When the TMSINIT procedure is run CA 1 issues an UP command. When TMSINIT terminates OPS/MVS is notified that CA 1 is up.
When the TMSINIT procedure is run and a password is supplied to bring CA 1 down, CA 1 issues a DOWN command. When executed in this mode, OPS/MVS is notified that CA 1 has terminated.
In most cases TMSINIT is executed to start CA 1 after an IPL or to refresh executable modules in common storage.
TMSINIT notifies OPS/MVS that it is UP and continues in this state for the life of the IPL with heartbeat events to confirm that it is active. CA 1 performs internal checks to verify its status based on a 30 minute timer and tape OPEN events. During the internal check CA 1 issues a heartbeat to report its condition to OPS/MVS. The first tape job and all subsequent tape jobs running 30 minutes after the prior heartbeat issue either a NORMAL or a PROBLEM heartbeat to OPS/MVS. This prevents CA 1 from flooding OPS/MVS with heartbeat commands during high tape OCEOV activity.
To ensure that this CA OPS/MVS interface is active, make sure the CA OPS/MVS parameter APIACTIVE is set to its default of ON. This allows CA OPS/MVS to acknowledge and process the events generated by CA 1 and other CA products through this interface.
CA 1 provides a direct interface to the CA OPS/MVS System State Manager (SSM) application to notify CA OPS/MVS of the current operating state of the given CA 1 address space. The CA OPS/MVS SSM application can use this information to automatically control the operation of the CA 1 address space, as well as any other address space that is dependent upon the CA 1 address space being active. For more information on using CA OPS/MVS SSM see the CA OPS/MVS User Guide.
The CA 1 product active state is presented to CA OPS/MVS and can be processed by the following rule:
)API CASTATE
The available OPS/REXX variables for CA 1 product state management are:
OPS/REXX Variable Value
API.APPLICATION CA 1 API.VERSION Current release API.LEVEL 00000 API.EVENTID CASTATE API.MSGID CASTATE API.TEXT State of CA 1
The API.TEXT variable has the following format:
State of appl_id is current_state'
Specifies the same value as the API.APPLICATION variable
Indicates that CA 1 is initializing
Indicates that CA 1 is active
Indicates that CA 1 is terminating
Indicates that CA 1 is exiting the system
For more information on how to use the CASTATE API, see the member SSMCAAPI of opsmvsHLQ.STATEMAN.RULES.
CA 1 provides a continuous heartbeat event directly to CA OPS/MVS. CA OPS/MVS can use this information in several ways to determine the operational health of the CA 1 product.
CA 1 issues a heartbeat update every nnnn seconds that notifies CA OPS/MVS of the current operational health of the CA 1 product.
If CA 1 detects a health state change, it immediately generates a heartbeat update without waiting for the nnnn second heartbeat interval to expire. In this way, CA 1 provides CA OPS/MVS with a constant operational health state view of the CA 1 product.
CA OPS/MVS can also react to the lack of a heartbeat update from CA 1 and an indication that there is either a potential problem with CA 1, or there is a larger system level problem that is taking place.
The CA 1 product heartbeat event is presented to CA OPS/MVS and can be processed by the following rule:
)API CAHEARTBT
The available OPS/REXX variables for CA 1 state management are:
OPS/REXX Variable Value
API.APPLICATION CA 1 API.VERSION Current release API.LEVEL 00000 API.EVENTID CAHEARTBT API.MSGID CAHEARTBT API.TEXT State of CA 1
The API.TEXT variable has the following format:
appl_id Status: heartbeat_state Reason: reason_text
Specifies the value of the API.APPLICATION variable.
Heart_beat_state can be one of the following:
Indicates that CA 1 is operating normally, without any detected problems.
reason_text explains the problem as reported by the event API call.
For information on how you use the CAHEARTBT API, see members APIHRTB1, APIHRTB2, and APIHRTB3 of opsmvsHLQ.SAMPLE.RULES.
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|