It is important to understand that RMS does not interact directly with "real-world" items such as machines, users' applications, or system resources - it interacts only with the objects in its virtual representation. The following figure illustrates the relationship between an actual user application in the operating system environment and the corresponding userApplication object in an RMS configuration.
Figure 1.2 Interface between RMS and the operating system
Note that the interface between the RMS virtual representation and the actual operating system depends entirely on the scripts and detectors provided by the configuration tools. The script in the figure represents any of the standard scripts discussed later in this chapter: it reports whether or not it completed its tasks successfully by returning a status code, and RMS combines this with the status code from the object's detector to determine the object's state. RMS has no other way to determine what actually happened to the user application in the operating system environment (the part of the figure below the dashed line).
For instance, if a userApplication object's Online script reports success, its detector reports that it is online, and all of its resources are online, then RMS considers that object to be online, regardless of the state of the actual user application. Similarly, if a resource object's detector reports an Offline state, it does not necessarily mean that the physical resource is unavailable.
Point
For reliable high availability operation, RMS requires scripts that properly control the corresponding real world items, and detectors that accurately reflect the items' states.
Configuration terminology
This manual discusses configuration procedures within the RMS context (represented by the part of figure above the dashed line). Strictly speaking, our principle concern is with SysNode objects, userApplication objects, and other RMS entities, and not the real-world items they represent.
However, it is intuitive to use terms such as "node" instead of "SysNode object" and "application" instead of "userApplication object," because the relationships are so close, and because it is always understood we are working from the RMS perspective. This also helps to simplify many of the technical discussions. Therefore, unless there is a need to distinguish between an RMS object and the actual item it represents, this manual and the configuration tools it describes use the following terms interchangeably:
"node" and "SysNode object" and "SysNode"
"application" and "userApplication object" and "userApplication"
"resource" and "gResource object" and "gResource"
The descriptions of object states and attributes are abbreviated similarly. For instance, instead of "the gResource object that monitors the mount point xyz is in the Offline state," it is customary to say, "the xyz file system is offline." It is also common to refer to a script by its attribute name, so "the script specified by the PreOnlineScript attribute" becomes simply "the PreOnlineScript."
All the objects that are managed by RMS are collectively described as "RMS resource."
