Using System State Manager › How SSM Works › Auxiliary Tables

Auxiliary Tables

Auxiliary tables should be used as follows:

• To store status information about resources that reside outside of the local system, such as the status of started tasks on an external system

  The SSM engine can reference these statuses as needed without the complication and delay imposed by communicating with another system.

• When SSM requires the status of many external resources

  If you write an application that uses an auxiliary table, then you need to 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.

• To implement a global control and response feature under SSM
• To track status changes to non-local resources

Sample programs are available that make use of auxiliary tables; however, they are for example purposes only. We do not guarantee correct or useful results from tables created by these sample programs.

Note: There are no required columns in auxiliary tables and they are not listed in the directory table.

Important! Auxiliary tables should be used only 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 defined in the SSMAUXTBLPREFIX parameter, 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, executed by the SSM engine, can examine the contents of the SSM auxiliary tables at any time. Auxiliary tables are not SSM tables, and do not produce SSM global event activity. Specifically, ADD, DELETE, and UPDATE events are not generated for auxiliary tables.

SSM Resource Management Modes

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 listed in order of increasing restrictiveness:

• ACTIVE

  SSM functions fully, managing resources and tables and taking actions when the desired state of a resource differs from its current state. SSM can start and stop resources while in ACTIVE mode.

• NOPREREQ

  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 it can be applied to a table or an entire system if needed. An EMERGENCY shutdown procedure can set NOPREREQ mode for a table or system to quickly terminate resources.

• PASSIVE

  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 will take 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 want SSM to track its current state.

• INACTIVE

  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.