Difference between revisions of "PTP/designs/3.x/rm proxy"

Latest revision as of 12:40, 12 July 2010

Overview

This is a preliminary design for the PTP Resource Management proxy communication protocol. This protocol is used to communicate between the Resource Manager System in Eclipse, and a lightweight proxy agent running on a target system. The primary purpose of the protocol is for system monitoring, process launch, and process control activities.

Terminiology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]

Resource Manager System

The Resource Manager System (RMS) is an Eclipse plugin that manages interaction with arbitrary resource managers. A resource manager in this context, is anything that provides program launch and monitoring services on a target system. Typically, a resource manager will be a job scheduler (e.g. LSF, LoadLeveler, PBS, etc.) running on a large multi-user system. Other types of resource managers include the Open Runtime Environment (ORTE) which is part of the OpenMPI distribution, or the MPICH2 runtime system. The RMS is responsible for populating an internal model in Eclipse which provides a cached representation of the system and program state. Various user interface views are available to inspect and interact with this model. Details of the RMS are provided in a separate document PTP/designs/rms.

Proxy Agent

The RMS communicates with proxy agents to gather information about the state of a target system. The proxy agent may be located on either a local or remote machine.

Proxy Agent Launch

The RMS is responsible for launching the proxy agent. On a local machine, this just involves executing a local process. To launch on a remote machine, the RMS must use an authenticated command service, such as ssh. Current plans are to utilize the Remote System Explorer (RSE) system to provide this remote proxy launch capability.

Proxy Session

One instance of a communcation channel between the RMS and a proxy agent is known as a session. A session only supports communication to a single proxy agent at a time. The mechanism used to effect communcation between the RMS and a proxy agent is not defined in this document, but can be any bi-directional communications channel (e.g. TCP/IP sockets, etc.)

Proxy Protocol

The communication protocol used between the RMS and the proxy agent is a simple text-based asynchronous command/event protocol. The RMS sends one or more commands to the proxy agent, which in turn will generate events that are returned to the RMS. One command may generate multiple events, but an event is always associated with a particular command. A command is not completed until either a corresponding ERROR or OK event is received.

Transaction IDs

Transaction IDs (TIDs) are numbers that are used to match commands and events. Since one command may generate multiple events, TIDs are essential in order to determine which command generated an event. This means that every event MUST have a TID that matches a corresponding command.

TIDs are only unique for uncompleted commands, not necessarily for the whole session.

Proxy agents SHOULD assume that a particular TID MAY be reused.

Proxy agents SHOULD NOT assume anything about the numbering or ordering of TIDs.

Any events received with an invalid TID (i.e. with no corresponding command) SHALL be discarded.

Element IDs

Element IDs are key to communcation between the RMS and the proxy agent. Every element in the model (queue, node, job, etc.) has a unique ID. This ID is generated by the proxy agent. In order to ensure the ID is unique, the RMS supplies a base ID as part of the initialization sequence. This base ID is guaranteed to be unique, and is used by the proxy agent to "uniquify" its generated IDs. The base ID is itself an element ID, so cannot be used by the proxy. It is possible to re-use an element ID, provided that the model element has been removed from the model. However this is not recommended.

Proxy agents have two choices for the types of ID's it generates: numeric or string. The RMS doesn't care which is used. There are advantages and disadvantages for each type. Numeric and string IDs can be mixed.

Numeric Element IDs

Numeric IDs are typically used when the proxy agent is dealing with large numbers of objects (e.g. processes, nodes, etc.) They are more efficient to transmit, because the compact Range Set Notation can be used. When using numeric IDs proxy agent should try and generate "blocks" of IDs to make the range sets more efficient. A proxy agent might, for example, reserve a range of IDs for nodes, a different range for processes, etc.

Numeric IDs are computed using the base ID in such a way that the ID value will be unique. For example, one such computation would be to add the base ID to a monotonically increasing series of integers starting at 1.

String Element IDs

String IDs are an easy way to generate IDs, but are less efficient because they prevent using the Range Set Notation. These IDs are generated by creating a unique string and appending it to the base ID. The new ID is then guaranteed to be unique across the mode.

Range Set Notation

This is a compact representation of sequences of numeric (unsigned integer) values. Ranges of consecutive values can be represented using the first and last values in the range, separated by a dash character (hex 2D). Ranges can then be grouped be separating them with commas (hex 2C). Spaces or other characters are not permitted in a range set.

For example, the range:

1,2,3,4,5,6,7,34,35,36,37,38,41,55,56,57

would be represented as:

1-7,34-38,55-57

Ranges in the set need not be in sorted order, and can be overlapping.

The range set:

1-10,4-12,3

represents the 12 consecutive numbers starting at 1.

Message Format

Commands and events consist of sequences of ASCII characters formatted into a message. A message is transmitted in the following format:

MESSAGE ⇒ LENGTH " " COMMAND_OR_EVENT

LENGTH and COMMAND_OR_EVENT are separated by a space (hex 20). The LENGTH is the length of the COMMAND_OR_EVENT portion of the message including the space. COMMAND_OR_EVENT is the actual text of the command or event.

COMMAND_OR_EVENT ⇒ COMMAND | EVENT

The COMMAND_OR_EVENT portion of the message contains a header part followed by a sequence of arguments separated by spaces. Each argument is a string formatted using the String Format described below. The command format is described in more detail in the Commands section. The event format is described in more detail in the Events section.

String Format

Strings are transmitted using the following format:

STRING ⇒ LENGTH ":" CHARACTERS

where LENGTH is a fixed length 8 digit hexadecimal representation of the length of the string, ':' is a colon character (hex 3A), and CHARACTERS are the actual ASCII characters in the string. No string terminating character (e.g. NULL) is ever transmitted.

For example, the string "A String" would be formatted as:

00000008:A String

A zero length string would be formatted as:

00000000:

Attributes

Attributes are used so that data sent between the RMS and proxy agent is self describing. Attributes are actually composed of two parts: an attribute definition ID, and the actual data. A unique attribute definition IDs is assigned to each Attribute Definition. Attribute definitions are either pre-defined by the RMS, or generated by the proxy agent during the DISCOVERY phase.

Attribute Definition

An attribute definition contains meta-data about the attribute. This meta-data includes:

ID: The attribute definition ID.

TYPE: The type of the attribute. Currently supported types are ARRAY, BOOLEAN, DATE, DOUBLE, ENUMERATED, INTEGER, and STRING.

NAME: The short name of the attribute. This is the name that is displayed in UI property views.

DESCRIPTION: A description of the attribute that is displayed when more information about the attribute is requested (e.g. tooltip popups.)

DEFAULT: The default value of the attribute.

The attribute definition is primarily used for data validation and displaying attributes in the user interface. There is currently no support for proxy agents to utilize the attribute definition information, although there is nothing to stop a proxy agent from validating against its own attribute definition information.

Attribute Value

An attribute value is always a key/value pair with an equals character (hex 3D) separating the key and value. The key is the attribute definition ID and the value is a string representation of the actual value of the attribute. All attributes support conversion to/from strings. It is assumed that once an attribute value is placed on the wire, it has been validated against the corresponding attribute definition.

An example attribute value is:

machineState=ALERT

In this example, the attribute definition ID is "machineState" and it's value is "ALERT". Because "machineState" is an enumerated attribute type, we know that ALERT must be a legal value, and that the string "ALERT" can be converted to the actual enumerated value.

Like any other arguments, the complete attribute value string is always converted to a STRING before being transmitted.

For example, the attribute value:

progArgs=-a 2 -b 4

would actually be transmitted as:

00000012:progArgs=-a 2 -b 4

Protocol Phases

The proxy protocol is divided into a number of phases. A phase determines the legal commands that can be sent to the proxy agent. During a particular phase, illegal commands SHOULD be discarded. Note: this may be changed to SHOULD generate an ERROR event.

Phases follow a strict ordering. Transition from one phase to the next occur when an OK event is received in response to a phase initiation command. A phase initiation command is a command that must be sent to initiate a particular phase. Once a phase has been initiated, any legal commands for that phase may be sent. The phase ordering is defined as follows:

INITIALIZE -> MODEL_DEF -> {START_EVENTS -> STOP_EVENTS}

The phases are defined in more detail in the following sections.

INITIALIZE

This is the first phase, and is used to initiate a communication session between the RMS and proxy agent, and agree on any protocol parameters that apply to this session.

Phase initiation command:

INIT

Legal commands:

none

DISCOVERY

The discovery phase is used to allow the proxy agent to inform the RMS of any dynamic property information. This information currently consists of attribute definitions and filter definitions which are described in more detail below.

Phase initiation command:

MODEL_DEF

Legal commands:

none

NORMAL

The normal phase is entered once the initialize and discovery phases are completed. This is the normal command/event processing phase.

Phase initiation command:

START_EVENTS

Legal commands:

SUBMIT_JOB
TERMINATE_JOB
MOVE_JOB
CHANGE_JOB
LIST_FILTERS
SET_FILTERS
STOP_EVENTS
QUIT

SUSPENDED

The suspended phase is used when the RMS needs to prevent the proxy agent from sending additional events.

Phase initiation command:

STOP_EVENTS

Legal commands:

START_EVENTS
QUIT

Phase Example

The following provides a simple example of phase transitions. Commands go from left to right, events from right to left. The command tid is shown in ()'s after the command or event name.

-- intialize phase --
INIT(1)         ->
                <- OK(1)
-- definition phase --
MODEL_DEF(2)    ->
                <- ATTR_DEF(2)
                <- ATTR_DEF(2)
                <- OK(2)
-- normal phase --
START_EVENTS(3) ->
                <- NEW_MACHINE(3)
                <- NEW_NODE(3)
STOP_EVENTS(4)  ->
                <- OK(3)
-- suspended phase --
START_EVENTS(5) ->
                <- OK(4)
-- normal phase --
                <- NEW_QUEUE(5)
QUIT(6)         ->
                <- OK(5)
                <- SHUTDOWN(6)

Note that the first suspended phase is not entered until the OK event corresponding to the START_EVENTS command (tid 3) is received. Similarly, the second normal phase is not entered until after the OK event corresponding to the STOP_EVENTS command (tid 4) is received.

Commands

Commands are formatted as simple ASCII text strings. A proxy command consists of a header and a body, separated by a space (hex 20), as follows:

COMMAND ⇒ COMMAND_HEADER " " COMMAND_BODY

The command header consists of three fixed length hexadecimal numbers separated by colons (hex 3A), so it is itself fixed length. The format of the header is:

COMMAND_HEADER ⇒ COMMAND_ID ":" TID ":" NUM_ARGS

where

COMMAND_ID is a 4 digit hexadecimal number containing the command to be performed

TID is an 8 digit hexadecimal number containing the transaction ID assigned to this command

NUM_ARGS is an 8 digit hexadecimal number containing the number of space separated elements in the command body

The command body consists of NUM_ARGS strings separated by spaces.

COMMAND_BODY ⇒ STRING { " " STRING }

The following sections describe the currently defined commands.

QUIT

Message Format

QUIT_COMMAND ⇒ "0000:TID:00000000"

Description: Terminate the proxy agent. This command will cause the proxy agent to terminate as soon as possible.

Events: SHUTDOWN

INIT

Message Format

INIT_COMMAND ⇒ "0001:TID:00000002" " " VERSION " " BASE_ID

Description: Initialize proxy communication. After this command has been received, the proxy is ready to receive and process other commands from the RMS. Initialization data may be passed on the command line when the proxy is run.

Arguments

VERSION is the wire protocol version number.

BASE_ID is the base ID used by the proxy agent when allocating new element IDs.

Events: OK, ERROR

MODEL_DEF

Message Format

MODEL_DEF_COMMAND ⇒ "0002:TID:00000000"

Description: Start the proxy discovery phase. The proxy agent responds with a series of ATTR_DEF and FILTER_DEF events. Attributes (see Attributes) are meta-data describing data from the proxy agent that the RMS is expected to receive and possibly display in the UI.

Arguments

none

Events: ATTR_DEF, FILTER_DEF, OK, ERROR

START_EVENTS

Message Format

START_EVENTS_COMMAND ⇒ "0003:TID:00000000"

Description: Initiate normal event processing phase.

Arguments

none

Events: CHANGE_JOB, CHANGE_MACHINE, CHANGE_NODE, CHANGE_PROCESS, CHANGE_QUEUE, NEW_JOB, NEW_MACHINE, NEW_NODE, NEW_PROCESS, NEW_QUEUE, REMOVE_ALL, REMOVE_JOB, REMOVE_MACHINE, REMOVE_NODE, REMOVE_PROCESS, REMOVE_QUEUE, OK, ERROR

STOP_EVENTS

Message Format

STOP_EVENTS_COMMAND ⇒ "0004:TID:00000000"

Description: Suspend normal event processing phase.

Arguments

none

Events: OK, ERROR

SUBMIT_JOB

Message Format

SUBMIT_JOB_COMMAND ⇒ "0005:TID:NUM_ARGS" { " " JOB_ATTR }

Description: Submit a job to the resource manager for execution. The job submission ID is an RMS generated ID that is used to match the newly created job model element with the job submission. The proxy agent MUST include this attribute when the corresponding NEW_JOB event is sent to the RMS. Once this event has been transmitted, the job submission ID can be discarded.

Arguments

JOB_ATTR is a proxy specific job submission attribute. At least one of these attributes MUST be an attribute containing the job submission ID for the job.

Events: OK, ERROR

TERMINATE_JOB

Message Format

TERMINATE_JOB_COMMAND ⇒ "0006:TID:00000001" " " JOB_ID_ATTR

Description: Request the terminaton of an existing job. The meaning of 'termination' depends on the state of the job.

Arguments

JOB_ID_ATTR is a jobId attribute containing the model element ID of the job.

Events: OK, ERROR

MOVE_JOB

Message Format

MOVE_JOB_COMMAND ⇒ "0007:TID:00000002" " " JOB_ID_ATTR " " QUEUE_ID_ATTR

Description: Not yet implemented. This command is intended to allow jobs to be moved between queues.

Arguments

JOB_ID_ATTR is a jobId attribute containing the model element ID of the job.

QUEUE_ID_ATTR is a queueId attribute containing the model element ID of the destination queue.

Events: OK, ERROR

CHANGE_JOB

Message Format

CHANGE_JOB_COMMAND ⇒ "0008:TID:NUM_ARGS" " " JOB_ID_ATTR { " " ATTR }

Description: Not yet implemented. This command is intended to allow a job's status to be changed (e.g. place a hold on a job)

Arguments

JOB_ID_ATTR is a jobId attribute containing the model element ID of the job to change.

ATTR is a proxy agent specific job attribute to change.

Events: OK, ERROR

LIST_FILTERS

Message Format

LIST_FILTERS_COMMAND ⇒ "0009:TID:00000000"

Description: Not yet implemented. This command lists the filters that are currently enabled in the proxy agent.

Arguments

none

Events: OK, ERROR

SET_FILTERS

Message Format

SET_FILTERS_COMMAND ⇒ "000A:TID:NUM_ARGS" { " " ATTR }

Description: Not yet implemented. This command sets the filters in the proxy agent.

Arguments

ATTR is a filter attributes to set.

Events: OK, ERROR

Events

Events are used by the proxy agent to communicate the results of commands or other information back to the RMS. As mentioned previously, each event MUST contain a tid of a corresponding command.

Events, like commands, are formatted as simple ASCII text strings. A proxy event consists of a header and a body, separated by a space (hex 20), as follows:

EVENT ⇒ EVENT_HEADER " " EVENT_BODY

The event header consists of three fixed length hexadecimal numbers separated by colons (hex 3A), so it is itself fixed length. The format of the header is:

EVENT_HEADER ⇒ EVENT_ID ":" TID ":" NUM_ARGS

where

EVENT_ID is a 4 digit hexadecimal number representing the type of event

TID is an 8 digit hexadecimal number containing the transaction ID of the command that generated this event

NUM_ARGS is an 8 digit hexadecimal number containing the number of space separated elements in the event body

The event body consists of NUM_ARGS strings separated by spaces.

EVENT_BODY ⇒ STRING { " " STRING }

The following sections describe the currently defined events.

OK

Message Format

OK_EVENT ⇒ "0000:TID:00000000"

Description: Indicates that the command with corresponding TID has been completed successfully

Arguments: none

ERROR

Message Format

ERROR_EVENT ⇒ "0005:TID:00000002" " " ERROR_CODE_ATTRIBUTE " " ERROR_MSG_ATTRIBUTE

Description: Indicates that the command with corresponding TID has not been completed successfully. The reason for the failure are provided in the attributes.

Arguments

ERROR_CODE_ATTRIBUTE is an attribute containing the error code

ERROR_MSG_ATTRIBUTE is an attribute containing a textual representation of the error

SHUTDOWN

Message Format

SHUTDOWN_EVENT ⇒ "0006:TID:00000000"

Description: Indicates that the proxy has shut down in response to a QUIT command.

Arguments: none

MESSAGE

Message Format

MESSAGE_EVENT ⇒ "00FA:TID:00000003" " " MSG_LEVEL_ATTRIBUTE " " MSG_CODE_ATTRIBUTE " " MSG_TEXT_ATTRIBUTE

Description: A log message that will be displayed by the user interface.

Arguments

MSG_LEVEL_ATTRIBUTE is an attribute containing the message level. Valid levels are '"FATAL'", '"ERROR", "WARNING", and "INFO".

MSG_CODE_ATTRIBUTE is an attribute containing the message code

MSG_TEXT_ATTRIBUTE is an attribute containing a textual representation of the message

ATTR_DEF

Message Format

ATTR_DEF_EVENT ⇒ "00FB:TID:NUM_ARGS" " " NUM_DEFS { " " ATTRIBUTE_DEF }

Description: Used to create new attribute definitions.

Arguments

NUM_DEFS is the number of attribute definitions to follow.

ATTRIBUTE_DEF is an attribute definition.

An attribute definition is defined as follows:

ATTRIBUTE_DEF ⇒ BOOLEAN_ATTR_DEF | DATE_ATTR_DEF | DOUBLE_ATTR_DEF | ENUM_ATTR_DEF | INT_ATTR_DEF | STR_ATTR_DEF

All attribute definitions begin with the following elements:

ATTR_DEF_START ⇒ NUM_ELEMENTS " " ID " " TYPE " " NAME " " DESCRIPTION " " DEFAULT

where:

NUM_ELEMENTS is the number of elements (separated by spaces) in this attribute definition.

ID is the unique definition ID.

TYPE is the type of the attribute. Legal values are: "ARRAY", "BOOLEAN", "DATE", "DOUBLE", "ENUMERATED", "INTEGER", and "STRING".

NAME is the short name of the attribute. This is displayed in property views as the name of the attribute.

DESCRIPTION is a description of the attribute. This is dispayed when more information about the attribute is requested.

DEFAULT is the default value of the attribute. There must be a legal conversion between this string and the actual attribute value.

A boolean attribute definition is simply:

BOOLEAN_ATTR_DEF ⇒ ATTR_DEF_START

A date attribute definition requires additional elements to be supplied for the definition:

DATE_ATTR_DEF ⇒ ATTR_DEF_START " " DATE_STYLE " " TIME_STYLE " " LOCALE [ " " MIN " " MAX ]

where:

DATE_STYLE is a Proxy String representing the date format. Legal values are: "SHORT", "MEDIUM", "LONG", and "FULL".

TIME_STYLE is a Proxy String representing the time format. Legal values are: "SHORT", "MEDIUM", "LONG", and "FULL".

LOCALE is a Proxy String represting a country code. See java.lang.Local for legal values.

MIN is the minimum date supported by the attribute.

MAX is the maximum date supported by the attribute.

A double attribute defintion has optional paramaters:

DOUBLE_ATTR_DEF ⇒ ATTR_DEF_START [ " " MIN " " MAX ]

where:

MIN is the minimum value supported by the attribute.

MAX is the maximum value supported by the attribute.

An enumerated attribute definition requires a sequence of enumerated values to be specified:

ENUM_ATTR_DEF ⇒ ATTR_DEF_START { " " VALUE }

where:

VALUE is a string representing an enumerated value.

Like double, integer attributes take optional parameters:

INT_ATTR_DEF ⇒ ATTR_DEF_START [ " " MIN " " MAX ]

where:

MIN is the minimum value supported by the attribute.

MAX is the maximum value supported by the attribute.

CHANGE_JOB

Message Format

CHANE_JOB_EVENT ⇒ "00E6:TID:NUM_ARGS" " " NUM_RANGES { " " JOB_RANGE }

Description: Used to update attributes in a range of job model elements. Multiple attributes in multiple jobs can be updated simultaneously with this event.

Arguments

NUM_RANGES is the number of job ranges contained in this event.

JOB_RANGE represents the attributes that have changed for a given range of jobs.

A JOB_RANGE is formatted as follows:

JOB_RANGE ⇒ ID_RANGE " " NUM_ATTRS { " " ATTR }

where:

ID_RANGE is a range of ID's in Range Set Notation

NUM_ATTRS is the number' of attributes associated with this range of jobs.

ATTR is an attribute that will be updated for each job in the range.

CHANGE_MACHINE

Message Format

CHANGE_MACHINE_EVENT ⇒ "00E7:TID:NUM_ARGS" " " NUM_RANGES { " " MACHINE_RANGE }

Description: Used to update attributes in a range of machine model elements. Multiple attributes in multiple machines can be updated simultaneously with this event.

Arguments

NUM_RANGES is the number of machine ranges contained in this event.

MACHINE_RANGE represents the attributes that have changed for a given range of machines.

A MACHINE_RANGE is formatted as follows:

MACHINE_RANGE ⇒ ID_RANGE " " NUM_ATTRS { " " ATTR }

where:

ID_RANGE is a range of ID's in Range Set Notation

NUM_ATTRS is the number of attributes associated with this range of machines.

ATTR is an attribute that will be updated for each machine in the range.

CHANGE_NODE

Message Format

CHANGE_NODE_EVENT ⇒ "00E8:TID:NUM_ARGS" NUM_RANGES { " " NODE_RANGE }

Description: Used to update attributes in a range of node model elements. Multiple attributes in multiple nodes can be updated simultaneously with this event.

Arguments

NUM_RANGES is the number of node ranges contained in this event.

NODE_RANGE represents the attributes that have changed for a given range of nodes.

A NODE_RANGE is formatted as follows:

NODE_RANGE ⇒ ID_RANGE " " NUM_ATTRS { " " ATTR }

where:

ID_RANGE is a range of ID's in Range Set Notation

NUM_ATTRS is the number of attributes associated with this range of nodes.

ATTR is an attribute that will be updated for each node in the range.

CHANGE_PROCESS

Message Format

CHANGE_PROCESS_EVENT ⇒ "00E9:TID:NUM_ARGS" " " NUM_RANGES { " " PROCESS_RANGE }

Description: Used to update attributes in a range of process model elements. Multiple attributes in multiple processes can be updated simultaneously with this event.

Arguments

NUM_RANGES is the number of process ranges contained in this event.

PROCESS_RANGE represents the attributes that have changed for a given range of processes.

A PROCESS_RANGE is formatted as follows:

PROCESS_RANGE ⇒ ID_RANGE " " NUM_ATTRS { " " ATTR }

where:

ID_RANGE is a range of ID's in Range Set Notation

NUM_ATTRS is the number of attributes associated with this range of processes.

ATTR is an attribute that will be updated for each process in the range.

CHANGE_QUEUE

Message Format

CHANGE_QUEUE_EVENT ⇒ "00EA:TID:NUM_ARGS" " " NUM_RANGES { " " QUEUE_RANGE }

Description: Used to update attributes in a range of queue model elements. Multiple attributes in multiple queues can be updated simultaneously with this event.

Arguments

NUM_RANGES is the number of queue ranges contained in this event.

QUEUE_RANGE represents the attributes that have changed for a given range of queues.

A QUEUE_RANGE is formatted as follows:

QUEUE_RANGE ⇒ ID_RANGE " " NUM_ATTRS { " " ATTR }

where:

ID_RANGE is a range of ID's in Range Set Notation

NUM_ATTRS is the number of attributes associated with this range of queues.

ATTR is an attribute that will be updated for each queue in the range.

NEW_JOB

Message Format

NEW_JOB_EVENT ⇒ "00DC:TID:NUM_ARGS" " " PARENT_ID " " NUM_JOB_DEFS { " " JOB_DEF }

Description: Define new job model elements. Multiple jobs can be defined simultaneously with this event.

Arguments

PARENT_ID is the ID of the parent queue of this job.

NUM_JOB_DEFS is the number of job definitions contained in this event.

JOB_DEF represents the definition of a range of jobs and associated attributes.

A JOB_DEF is formatted as follows:

JOB_DEF ⇒ ID_RANGE " " NUM_ATTRS { " " ATTR }

where:

ID_RANGE is a range of ID's in Range Set Notation

NUM_ATTRS is the number' of attributes associated with this job definition.

ATTR is an attribute that will be set for each newly created job.

NEW_MACHINE

Message Format

NEW_MACHINE_EVENT ⇒ "00DD:TID:NUM_ARGS" " " PARENT_ID " " NUM_MACHINE_DEFS { " " MACHINE_DEF }

Description: Define new machine model elements. Multiple machines can be defined simultaneously with this event.

Arguments

PARENT_ID is the ID of the parent resource manager of this machine.

NUM_MACHINE_DEFS is the number of machine definitions contained in this event.

MACHINE_DEF represents the definition of a range of machines and associated attributes.

A MACHINE_DEF is formatted as follows:

MACHINE_DEF ⇒ ID_RANGE " " NUM_ATTRS { " " ATTR }

where:

ID_RANGE is a range of ID's in Range Set Notation

NUM_ATTRS is the number of attributes associated with this machine definition.

ATTR is an attribute that will be set for each newly created machine.

NEW_NODE

Message Format

NEW_NODE_EVENT ⇒ "00DE:TID:NUM_ARGS" " " PARENT_ID " " NUM_NODE_DEFS { " " NODE_DEF }

Description: Define new node model elements. Multiple nodes can be defined simultaneously with this event.

Arguments

PARENT_ID is the ID of the parent machine of this node.

NUM_NODE_DEFS is the number of node definitions contained in this event.

NODE_DEF represents the definition of a range of nodes and associated attributes.

A NODE_DEF is formatted as follows:

NODE_DEF ⇒ ID_RANGE " " NUM_ATTRS { " " ATTR }

where:

ID_RANGE is a range of ID's in Range Set Notation

NUM_ATTRS is the number of attributes associated with this node definition.

ATTR is an attribute that will be set for each newly created node.

NEW_PROCESS

Message Format

NEW_PROCESS_EVENT ⇒ "00DF:TID:NUM_ARGS" " " PARENT_ID " " NUM_PROCESS_DEFS { " " PROCESS_DEF }

Description: Define new process model elements. Multiple processes can be defined simultaneously with this event.

Arguments

PARENT_ID is the ID of the parent job of this processs.

NUM_PROCESS_DEFS is the number of process definitions contained in this event.

PROCESS_DEF represents the definition of a range of processes and associated attributes.

A PROCESS_DEF is formatted as follows:

PROCESS_DEF ⇒ ID_RANGE " " NUM_ATTRS { " " ATTR }

where:

ID_RANGE is a range of ID's in Range Set Notation

NUM_ATTRS is the number of attributes associated with this process definition.

ATTR is an attribute that will be set for each newly created process.

NEW_QUEUE

Message Format

NEW_QUEUE_EVENT ⇒ "00E0:TID:NUM_ARGS" " " PARENT_ID " " NUM_QUEUE_DEFS { " " QUEUE_DEF }

Description: Define new queue model elements. Multiple queues can be defined simultaneously with this event.

Arguments

PARENT_ID is the ID of the parent resource manager of this queue.

NUM_QUEUE_DEFS is the number of queue definitions contained in this event.

QUEUE_DEF represents the definition of a range of queues and associated attributes.

A QUEUE_DEF is formatted as follows:

QUEUE_DEF ⇒ ID_RANGE " " NUM_ATTRS { " " ATTR }

where:

ID_RANGE is a range of ID's in Range Set Notation

NUM_ATTRS is the number of attributes associated with this queue definition.

ATTR is an attribute that will be set for each newly created queue.

REMOVE_ALL

Message Format

REMOVE_ALL_EVENT ⇒ "00F0:TID:00000000"

Description: Remove all model elements know by the RMS for this session.

Arguments

none

REMOVE_JOB

Message Format

REMOVE_JOB_EVENT ⇒ "00F1:TID:00000001" " " ID_RANGE

Description: Remove job model elements from the model. Multiple jobs can be remove simultaneously with this event. All children of the jobs will also be removed from the model.

Arguments