Availability Guide for Application Design

Instrumenting an Application for Availability
Availability Guide for Application Design—525637-004
8-30
The DSM Subsystem Environment
How SPI Programming Works
At the highest level, the management interface server must:
1. Read SPI command messages from an SPI buffer and extract tokens from the
command message.
2. Execute the command according to the token values contained in the command
message.
3. Respond to the requester (the management application).
On reading an SPI message (typically, by reading from its $RECEIVE file), the server
must validate the message. You must then use a set of SPI procedures to extract the
tokens.
If the message contains a valid command, the server must find the target object, apply
the command to that object, and use SPI procedures to prepare a response describing
the outcome of the command. The response might be a simple acknowledgment that a
state change was successfully performed, an indication that the command failed along
with an error list, or the return of some requested status information. Finally, the server
returns the response to the requester.
As with event message generation, you need definitions of all the tokens that your
command-interface server might encounter. You can declare these definitions in a DDL
file from which you can create your token definitions in the language of your
application.
Generating Statistics on Application Resource Usage
User-defined Measure counters enable you to take statistical measurements of the
way your application resources are used. For example, you might update a counter
each time a transaction is processed, or you might use counters to determine message
queue usage or to determine error rates.
To use Measure counters, you must use Measure procedures to initialize each counter
and then alter its value when appropriate. You can define and use the following types
of counters:
•
Accumulating counters keep tallies. You can use Measure procedures to increment
an accumulating counter by one or by some specified value. You might, for
example, increment a count of transactions each time a transaction commits.
•
Busy counters measure the amount of time a resource is busy. You simply start
the counter and stop the counter. You might use this counter to measure, for
example, how much time your application spends in transaction mode.
•
Queue counters measure the amount of time elements spend on a queue. You
increment the counter when the element is placed on the queue and then
decrement it when the element is removed from the queue. You might, for
example, use a queue counter to measure how long requests take to get serviced.