Using SNAplus2 in a High Availability Environment
Using SNAplus2 with MC/ServiceGuard
snapadmin start_ls, ls_name=HALS
LS details are:
Activation state = active
Port name = HAPORT
In this example, the state of the LS is active, which means the server is currently providing SNA network connectivity to a remote SNA system. The snapadmin start_ls command is not useful as a Service Command, however, because the command returns after displaying the state information. If snapadmin start_ls were used as a Service Command, ServiceGuard would interpret the termination of the snapadmin start_ls process as an indication that the SNAplus2 package had failed. For this reason, the snapmon utility has been provided for use as a Service command in an SNAplus2 package.
The snapmon utility continuously monitors the state of an SNAplus2 LS by querying SNAplus2 to determine if it is active. If the LS is ever reported to be in a state other than active, the program terminates. The only exception is during initialization, when certain errors can be ignored.
Usage:
snapmon
conname
identifies which SNAplus2 LS is being monitored
interval
specifies the number of seconds that snapmon waits between attempts to obtain the status of the LS . If this parameter is not specified, snapmon will pause 5 seconds between queries. Any number between 1 and 3600 (inclusive) can be specified.
retry_count
specifies how many times snapmon will allow the LS to be reported in a state other than active when snapmon is starting. This option is useful if the LS is configured to be initially active, and the SNAplus2 control daemon, node, port, LS , and snapmon are all started by ServiceGuard. It allows the LS enough time to establish communications with the remote system
370 | Appendix D |