Use auxiliary tables as follows:
The SSM engine can reference these statuses as needed without the complication and can delay imposed by communicating with another system.
If you write an application that uses an auxiliary table, then you supply a task to manage communications and keep the table current. Using auxiliary tables in situations where SSM references only a low volume of external statuses is not justified. Changes to auxiliary tables cause the SSM engine to reevaluate the status of known resources, but do not provide any information about how the auxiliary table was changed.
Sample programs are available that use auxiliary tables. However, they are for example purposes only. We do not guarantee correct or useful results from tables that these sample programs create.
Note: Auxiliary tables do not have required columns. These tables are not listed in the directory table.
Important! Only use auxiliary tables for SSM-related activity because changes to these tables wake up SSM and cause it to check the status of all local resources. For this reason, overusing auxiliary tables creates unnecessary overhead.
The only way SSM can distinguish an auxiliary table from other tables is by its name. If the prefix of a table name matches the prefix that the SSMAUXTBLPREFIX parameter defines, then the table is an auxiliary table. This prefix can be one to six characters long.
When an auxiliary table is updated (except by the SSM engine), for example by adding, deleting, or updating a row, the SSM engine is posted, causing the engine to reevaluate all missing prerequisites. Updates to auxiliary tables by the SSM engine do not cause the engine to post. Auxiliary tables are loosely coupled with SSM since no data is transmitted to the SSM engine when activity wakens the engine. An action that the SSM engine executes can examine the contents of the SSM auxiliary tables at any time. Auxiliary tables are not SSM tables. They do not produce SSM global event activity. Specifically, ADD, DELETE, and UPDATE events are not generated for auxiliary tables.
SSM can operate in four resource management modes, ACTIVE, NOPREREQ, PASSIVE, and INACTIVE. These modes define how SSM responds to state changes in resources that it controls. Mode can be set individually for each resource, for all resources in a table, or for all resources in all tables on the local system. When settings conflict, the more restrictive setting applies. For example, if a table is set to PASSIVE mode and a resource in the table is set to ACTIVE mode, then the resources are managed in PASSIVE mode.
The following list describes the four management modes in the order of increasing restrictiveness:
SSM functions fully, managing resources and tables, and takes action when the desired state of a resource differs from its current state. SSM can start and stop resources while in ACTIVE mode.
SSM operates as it does in ACTIVE mode, except that it bypasses checking prerequisites or subrequisites. NOPREREQ is most often applied to an individual resource, but you can apply NOPREREQ to a table or an entire system if needed. An EMERGENCY shutdown procedure can set NOPREREQ mode for a table or system to terminate resources quickly.
SSM does not trigger any action for deviations between current state and desired state except when the current state is equal to the table-relative UNKNOWN state. If the current state is equal to the table-relative UP or DOWN states, then desired state is set to the current state. Otherwise, the desired state is set to the table-relative UNKNOWN state.
You can use MODE=PASSIVE when you are not sure what action SSM takes but you want to synchronize the current state and desired state values of managed resources with their actual state on your system. You can also use MODE=PASSIVE when you do not want to take control of a resource, but you want SSM to track its current state.
SSM does not react to deviation between the current state value and the desired state value for a resource.
Important! When a prerequisite resource is set to INACTIVE mode, it still affects the ability of its subrequisites to run.
|
Copyright © 2014 CA.
All rights reserved.
|
|