How PSL Relates to PATROL Architecture
Managing objects in the PATROL environment requires an understanding of the naming conventions PATROL uses for objects, instances, parameters, and variables. (For more information on naming conventions, see PSL Naming Conventions.) You can access objects using their absolute name or their name relative to the PSL programming context.
The following figure shows how application objects can have variables and instances. In turn, the application instances can have variables and parameters that, in turn, can have variables.
Tree Structure of PATROL Applications and Objects
As shown in the following figure, the root of the hierarchy is the computer. The computer ( root) directory contains the applications. Each application directory contains all the application instances. Each instance directory contains all the parameters for each instance and so on.
The designation /RDB/Dev refers to the RDB database named Dev. Variables (such as name ) are analogous to files within a directory. The status of this database instance would be referenced as /RDB/Dev/status.
Conceivably, status could be the name of a parameter on Dev, in which case a conflict would exist. It is recommended that you begin all variable names with a lowercase letter and all object names (parameters, applications, and so on) with an uppercase letter to avoid name conflicts.
For more information on developing KMs that conform to PSL style guidelines, see PSL Naming Conventions.
The designation /RDB/Dev/Status is an object (a parameter) because it begins with a capital letter and /RDB/Dev/status is a variable for the Dev instance of the
The value of the parameter Logons on database Dev would be referenced as /RDB/Dev/Logons/value.
Once you define an object, you do not normally have to give the absolute name each time you reference it. You can make use of the context in which the script you are developing will run to construct shorter, relative names for most objects.
The context of a script is the name of the object to which the executing script belongs. For example, if you write a script for the discovery of the RDB application, its context will be the application class it is discovering.
Whenever you give the name of an object without a preceding
"/", the PATROL Agent prefixes the name with the current context. Using the previous example, if we gave the object name Dev, it would be expanded to /RDB/Dev automatically.
".." is reserved to mean the parent of the current context. For example, the reference
"../name" in an application discovery script refers to the name of the computer since the computer is the parent object of all application class objects. In a parameter, it refers to the application instance name since the parent of a parameter is its application instance.