Cluster Server 8.0.2 Agent Developer's Guide - Windows
- Introduction
 - Agent entry point overview
- About agent entry points
 - Agent entry points described
- About the open entry point
 - About the monitor entry point
 - About the online entry point
 - About the offline entry point
 - About the clean entry point
 - About the action entry point
 - About the info entry point
 - About the attr_changed entry point
 - About the close entry point
 - About the shutdown entry point
 - About the imf_init entry point
 - About the imf_register entry point
 - About the imf_getnotification entry point
 - About the migrate entry point
 - About the meter entry point
 
 - Return values for entry points
 - Considerations for using C++ or script entry points
 - About the agent information file
 - About the ArgList and ArgListValues attributes
 
 - Creating entry points in C++
- About creating entry points in C++
 - Data Structures
 - Syntax for C++ entry points
 - Agent framework primitives
- VCSAgGetMonitorLevel
 - VCSAgGetFwVersion
 - VCSAgGetRegVersion
 - VCSAgRegisterEPStruct
 - VCSAgSetCookie2
 - VCSAgRegister
 - VCSAgUnregister
 - VCSAgGetCookie
 - VCSAgStrlcpy
 - VCSAgStrlcat
 - VCSAgSnprintf
 - VCSAgCloseFile
 - VCSAgDelString
 - VCSAgExec
 - VCSAgExecWithTimeout
 - VCSAgGenSnmpTrap
 - VCSAgSendTrap
 - VCSAgLockFile
 - VCSAgInitEntryPointStruct
 - VCSAgSetStackSize
 - VCSAgUnlockFile
 - VCSAgValidateAndSetEntryPoint
 - VCSAgSetLogCategory
 - VCSAgGetProductName
 - VCSAgMonitorReturn
 - VCSAgSetResEPTimeout
 - VCSAgDecryptKey
 - VCSAgGetConfDir
 - VCSAgGetHomeDir
 - VCSAgGetLogDir
 - VCSAgGetSystemName
 - VCSAG_CONSOLE_LOG_MSG
 - VCSAG_LOG_MSG
 - VCSAG_LOGDBG_MSG
 - VCSAG_RES_LOG_MSG
 
 - Agent Framework primitives for container support
 
 - Creating entry points in scripts
- About creating entry points in scripts
 - Syntax for script entry points
- Syntax for the monitor script
 - Syntax for the online script
 - Syntax for the offline script
 - Syntax for the clean script
 - Syntax for the action script
 - Syntax for the attr_changed script
 - Syntax for the info script
 - Syntax for the open script
 - Syntax for the close script
 - Syntax for the shutdown script
 - Syntax for the imf_init script
 - Syntax for the imf_register script
 - Syntax for the imf_getnotification script
 - Syntax for migrate script
 - Syntax for meter script
 
 - Agent framework primitives
- VCSAG_GET_MONITOR_LEVEL
 - VCSAG_GET_AGFW_VERSION
 - VCSAG_GET_REG_VERSION
 - VCSAG_SET_RES_EP_TIMEOUT
 - VCSAG_GET_ATTR_VALUE
- To get number of keys in the key list attribute and the index of attribute in argument list
 - To get a particular key in the key list and vector attribute
 - To get the number of keys in the association attribute, and index of attribute in the argument list
 - To get a particular key or value in the association attribute:
 
 - VCSAG_SET_RESINFO
 - VCSAG_MONITOR_EXIT
 - VCSAG_SYSTEM
 - VCSAG_SU
 - VCSAG_RETURN_IMF_RESID
 - VCSAG_RETURN_IMF_EVENT
 - VCSAG_BLD_PSCOMM
 - VCSAG_PHANTOM_STATE
 - VCSAG_SET_ENVS
 - VCSAG_LOG_MSG
 - VCSAG_LOGDBG_MSG
 - VCSAG_SQUEEZE_SPACES
 
 - Agent Framework primitives with container support
 - Example script entry points
 
 - Logging agent messages
 - Building a custom agent
 - Building a script based IMF-aware custom agent
- About building a script based IMF-aware custom agent
 - Linking AMF plugins with script agent
 - Creating XML file required for AMF plugins to do resource registration for online and offline state monitoring
- Example of amfregister.xml for registration of process-based resource with AMF for online monitoring
 - Example of amfregister.xml for registration of process-based resource with AMF for offline monitoring
 - Example of amfregister.xml for online and offline IMF monitoring for a given process
 - Examples for adding RepearName tag in amfregister.xml
 
 - Adding IMF and IMFRegList attributes in configuration
 - Monitor without IMF integration
 - Monitor without IMF but with LevelTwo monitor frequency
 - Monitor with IMF integration
 - Monitor with IMF but with LevelTwo monitor frequency
 - Installing the IMF-aware script-based custom agent
 
 - Testing agents
 - Static type attributes
- About static attributes
 - Static type attribute definitions
- ActionTimeout
 - AdvDbg
 - AEPTimeout
 - AgentClass
 - AgentDirectory
 - AgentFailedOn
 - AgentFile
 - AgentPriority
 - AgentReplyTimeout
 - AgentStartTimeout
 - AlertOnMonitorTimeouts
 - ArgList
 - AttrChangedTimeout
 - AvailableMeters
 - CleanRetryLimit
 - CleanTimeout
 - CloseTimeout
 - ContainerOpts
 - ConfInterval
 - EPClass
 - EPPriority
 - ExternalStateChange
 - FaultOnMonitorTimeouts
 - FaultPropagation
 - FireDrill
 - IMF
 - IMFRegList
 - InfoInterval
 - InfoTimeout
 - IntentionalOffline
 - LevelTwoMonitorFreq
 - LogDbg
 - LogFileSize
 - LogViaHalog
 - ManageFaults
 - Meters
 - MeterControl
 - MeterRegList
 - MeterRetryLimit
 - MeterTimeout
 - MonitorInterval
 - MonitorStatsParam
 - MonitorTimeout
 - MigrateTimeout
 - MigrateWaitLimit
 - NumThreads
 - OfflineMonitorInterval
 - OfflineTimeout
 - OfflineWaitLimit
 - OnlineClass
 - OnlinePriority
 - OnlineRetryLimit
 - OnlineTimeout
 - OnlineWaitLimit
 - OpenTimeout
 - Operations
 - RegList
 - RestartLimit
 - ScriptClass
 - ScriptPriority
 - SourceFile
 - SupportedActions
 - SupportedOperations
 - ToleranceLimit
 
 
 - State transition diagram
 - Internationalized messages
 - Troubleshooting VCS resource's unexpected behavior using First Failure Data Capture (FFDC)
 - Appendix A. Using pre-5.0 VCS agents
 
Considerations for the application
The application for which an agent for VCS is developed must lend itself to being controlled by the agent and be able to operate in a cluster environment. The following criteria describe an application that can successfully operate in a cluster:
The application must be capable of being started by a defined procedure if new agent is of type OnOff or OnOnly. There must be some means of starting the application's external resources such as file systems that store databases, or IP addresses used for listener processes, and so on.
Each instance of an application must be capable of being stopped by a defined procedure if new agent is of type OnOff. Other instances of the application must not be affected.
The application must be capable of being stopped cleanly, by forcible means if necessary.
Each instance of an application must be capable of being monitored uniquely. Monitoring can be simple or in-depth so as to achieve a high level of confidence in the operation of the application. Monitoring an application becomes more effective when the monitoring procedure resembles the actual activity of the application's user.
For failover capability, the application must be capable of storing data on shared disks rather than locally or in memory, and each system must be capable of accessing the data and all information required to run the application.
The application must be crash-tolerant. It must be capable of being run on a system that crashes and of being started on a failover node in a known state. This typically means that data is regularly written to shared storage rather than stored in memory.
The application must be host-independent within a cluster; that is, there are no licensing requirements or host name dependencies that prevent successful failover.
The application must run properly with other applications in the cluster.
The applications configured under VCS control must not write data on stdout and stderr stream. This may interfere with VCS agent functionality. For such applications to run under VCS control, you must redirect the application's stdout and stderr stream.