tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3018

 
 
 

Unified Memory Space Protocol Specification

Part 2 of 4, p. 21 to 43
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 21 
5  Jobs Management

   The jobs management includes the following functions:

   o  Initiation and completion of jobs;
   o  Initiation and completion of tasks;
   o  Opening and closing of session connections;
   o  Activity control of nodes.

   The instructions with OPCODE = 1 - 112 are used for jobs management.
   These instructions must be sent through TCP.  Use UDP is not allowed,
   even if the instructions do not demand response.

   UMSP bases on model with the centralized control of the separate job.
   The reason is that the pointers control is not obviously possible in
   the decentralized system.  Any task can be finished at any moment or
   the node can be reloaded.  There is no way guaranteeing the
   notification about in the decentralized system all other nodes, on
   which the job works.  As the job continues to exist - the task
   concerning the job can be initiated on the same node again.  This
   task can allocate new dynamic resources.  The addresses for the again
   allocated resources can be crossed with addresses of resources, which
   existed on the node before the task restart.  The old pointers can be
   kept on other nodes.  It may be the formally correct pointers, but
   they will actually specify other objects.  The uncontrollable work of
   the application can be consequence of such situation.

Top      Up      ToC       Page 22 
   UMSP solves this task as follows:

   o  It allows defining the node, on which the task was completed,
      precisely.
   o  If the task on the node is finished before end of the job, all
      nodes, on which the job is executed, are notified of it.
   o  The repeated task initialization on the node is allowed, while all
      nodes will receive the message about the first task end.

   The protocol does not control the pointers.  VM supervises the
   pointers correctness.  VM must have architecture, in which 128 - bit
   pointers are stored in special memory areas, for this purpose.  The
   protocol informs VM about the nodes, on which task have finished the
   work.  VM must make all pointers concerning such tasks, invalid.  It
   results in exclusive situations at the access under these pointers.
   If the application provides processing exceptions, it keeps the
   capacity for work, or it is finished emergency.  Such decision allows
   excluding unguided applications working.

   For the decision of the specified questions at UMSP level, the
   control job node is defined for each job.  It names Job Control Point
   (JCP).  It may be the same node, on which the job is initiated, or it
   can be another dedicated node.  The basic JCP function is to trace
   the initialization and the end of the job tasks.  Besides, the
   dedicated JCP node may be used for the centralized users
   identification and the attack protection.

   The following identifiers are definite for the jobs and tasks
   control:

   o  Locally Task Identifier (LTID) is assigned to each active task on
      the node.  LTID length is equal to the length of local memory
      address defined for the node.  All LTID on the node must give
      unique values at each moment of time.  It is allowed to establish
      LTID, used earlier in the already completed tasks, for the again
      initiated tasks.
   o  JCP assigned the Control Task Identifier (CTID) to each task of
      the job.  Its length is equal to length of the local address
      memory on the node JCP.  All CTID on the JCP must give unique
      values at each moment of time.  As against LTID, the CTID value is
      chosen with some restrictions.
   o  Globally Task Identifier (GTID) is assigned to each task.  GTID
      has the same format, as the 128 - bit address of node memory has.
      The address of local memory is replaced on LTID in it.
   o  Globally Job Identifier (GJID) is assigned to the each job.  GJID
      is defined on the JCP node.  It has the same format, as the 128 -
      bit address of node JCP memory has.  The address of local memory

Top      Up      ToC       Page 23 
      is replaced on CTID of the first (initial) task of the job in it.
      GJID is used in the procedure of session connection opening for
      the definition JCP, which controls the job.

   LTID and CTID are written at the instructions in the field of length
   2/4/8 octets.  If the allocated for identifier field in the
   instruction is longer than identifier, LTID (CTID) writes in the last
   octets.  In the initial octets, the value 0 must be written.  If
   received LTID (CTID) is shorter than the local memory address, it is
   necessary to pad it with the zero octets in the beginning.

   GTID and GJID are written at the instructions in the field of length
   4-16 octets.  The field FREE is not present at these identifiers (see
   section 2.1).  It is considered, that it contains the zero-value
   octets.  Length of the identifier is defined in header of the
   address.

   By sending of instructions CONTROL_REQ, TASK_REG and SESSION_OPEN,
   the protocol uses timeout.  The value of timeout is assigned by node
   and must be more than three intervals of the maximal time of delivery
   at the transport layer.  The timeout is not influenced the waiting
   period in queue to the transport layer.

5.1    Job Initiate

   The job concerns to the user application executed on VM.  The UMSP
   job initialization can be made simultaneously with the application
   user start or during its working.

   The task, appropriated to its job, is initialized on the node
   together with the job.  LTID is binding to this task.

   If the node, on which the user application was loaded, is chosen for
   JCP, the question of the job initialization lays beyond the scope of
   the network protocol.

   Other node can be chosen as JCP for the following reasons:

   o  The job initialization node is connected to network by slow-speed
      or overloaded channel.  It is undesirable to send the managing
      traffic.
   o  The node has no computing possibilities for conducting the
      managing tables.
   o  The authentication on the detailed node is necessary.

   If the other node is chosen for JCP, the node, that initiates the
   job, must register the job at JCP.

Top      Up      ToC       Page 24 
5.1.1     CONTROL_REQ

   The instruction "To request a control" (CONTROL_REQ) is sending from
   the node, initial the job, to JCP of other node.  The instruction has
   the following values of fields:

      OPCODE = 3
      PCK = %b00
      CHN = 0
      ASK = 1
      EXT = 0/1
      OPR_LENGTH = 2/3  ; Depends on LTID length.
      REQ_ID - The value is assigned by the sender node protocol and
               then will be sent in the response.
      Operands:
         4 octets: The control parameters profile.  This field has the
                   following format:

            bits
             0     1     2     3     4     5     6     7
            +-----+-----+-----+-----+-----+-----+-----+-----+
            |                                               |
            +                 JOB_LIFE_TIME                 +
            |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
            | CMT |    Reserved     |        VERSION        |
            +-----+-----+-----+-----+-----+-----+-----+-----+
            |                   Reserved                    |
            +-----+-----+-----+-----+-----+-----+-----+-----+


            JOB_LIFE_TIME

               2 octets.  The job lifetime in seconds.  The zero-value
               signifies that the restriction of the job lifetime is
               unused.

            CMT

               1 bit.  The flag of several JCP using.  This field is
               reserved for the future expansion of the protocol.

            VERSION

               1 octet.  The number of the UMSP version.  It must
               contain the value 1.

Top      Up      ToC       Page 25 
            Reserved

               3 + 8 bits.  All bits must be set to 0.

         4/8 octet: LTID of task of the job, assigned on the node, which
                    initiate the job (by the sender of this
                    instruction).
      The optional extension headers:
         _JOB_NAME  -  This header contains the name of the Job.  Is
                       assigned once and must not change further.
         _INACT_TIME - This header contains the inaction time (see
                       section 5.7).

   At reception of the CONTROL_REQ instruction JCP checks the LTID value
   from the received instruction and makes the following:

   (1) If the node, which has sent CONTROL_REQ, already has registered
       on JCP the active job with such LTID, the notification about
       abnormality end of the registered job is sent, as is described in
       section 5.5.2 (it is considered, that the node was reloaded).
       After that, the sanction to an initiation of the new job is sent.
   (2) If the node has no registered job with received LTID, it allows
       the new job initiation at once.

   If JCP confirms the control, it will send the instruction
   CONTROL_CONFIRM, or else CONTROL_REJECT.

5.1.2     CONTROL_CONFIRM

   The instruction "To confirm the control" (CONTROL_CONFIRM) is sent
   from JCP as the positive response to CONTROL_REQ instruction.
   CONTROL_CONFIRM has the following values of fields:

      OPCODE = 4
      PCK = %b00
      CHN = 0
      ASK = 1 ; The instruction does not need to be responded.  This flag
                specifies presence of the REQ_ID field.
      EXT = 0/1
      OPR_LENGTH = 1-4 ; Depends of length of the GJID.
      REQ_ID - The value is taken from the instruction CONTROL_REQ
      Operands:
         4-16 octets: The GJID assigned to the job on the JCP.

   The sending of the instruction CONTROL_REQ means request of control
   and request of task initiation.  Assigned to the task CTID is part
   GJID (field of the local memory address).

Top      Up      ToC       Page 26 
5.1.3     CONTROL_REJECT

   The instruction "To reject the control" (CONTROL_REJECT) is sent from
   JCP as the negative response to CONTROL_REQ instruction.
   CONTROL_REJECT has the following values of fields:

      OPCODE = 4
      PCK = %b00
      CHN = 0
      ASK = 1.  The instruction does not need to be responded.  This flag
                specifies presence of the REQ_ID field.
      EXT = 0/1
      OPR_LENGTH = 1/2 ; Depends on presence of the control parameters
                         profile field.
      REQ_ID - The value is taken from the instruction CONTROL_REQ
      Operands:
         2 octets: The basic error code.  The zero-value is not
                   available.
         2 octets: The additional error code.
         4 octets: The control parameters profile (see section 5.1.1),
                   that is allowed by JCP.  This is optional field.
      The optional extension headers:
         _INACT_TIME - This header contains the inaction time (see
                       section 5.7).
         _MSG - contains the arbitrary error description.

5.2    Task Initiate

   The job is executed on several nodes simultaneously.  The task,
   appropriate to it, must be initialized on each node.  There is
   corresponding only one task to one job on the node.  Each task must
   be connected only with one job.

   The task is initiated together with the job on the node, which had
   created the job.  On the other nodes, the task is initiated during
   the receiving of the first request on the opening of the session
   connection, which is appropriate to the job.  The request about
   openings of session connection contains GJID.  GJID contains the JCP
   address.  It is necessary to receive the sanction from JCP for the
   task start.  If the request about the opening of session has been
   received from JCP node, it is not necessary to request the sanction.

5.2.1     TASK_REG

   The instruction "To register a task" (TASK_REG) is sent from the
   node, which initials the task, to JCP of the remote node.  The
   instruction has the following values of fields:

Top      Up      ToC       Page 27 
      OPCODE = 6/7/8 ; For length CTID of 2/4/8 octets.
      PCK = %b00
      CHN = 0
      ASK = 1
      EXT = 0/1
      OPR_LENGTH = 2-8  ; Depends on length of the GTID and LTID.
      REQ_ID - The value is assigned by the sender node protocol and
               then will be sent in the response.
      Operands:
         2/4/8 octets: CTID of the task initiated the job.  It CTID is a
                       part GJID from the instruction SESSION_OPEN.
         4-16 octets: GTID, assigned on the node, initialed session
                      connection.  GTID is formed of sender addresses (at
                      transport layer) and field LTID of the instruction
                      SESSION_OPEN.
         2/4/8 octets:  LTID, assigned on the node, initialed the task
                        (by the sender of this instruction).
      The optional extension headers:
         _INACT_TIME - This header contains the inaction time (see
                       section 5.7).

   The instruction TASK_REG must be sent only if the task with given
   GJID was not initiated on the node.

   JCP confirms initiation of a task at observance of the following
   conditions:

   (1) Task with received GTID already has registered on JCP.
   (2) Task with LTID for the node requesting for initiation has not
       registered.

   In all other cases, JCP will not confirm a task.

   If JCP confirms the task, it will send the instruction TASK_CONFIRM,
   differently TASK_REJECT.

5.2.2     TASK_CONFIRM

   The instruction "To confirm the task" (TASK_CONFIRM) is sent from JCP
   as the positive response to TASK_REG.  TASK_CONFIRM has the following
   values of fields:

      OPCODE = 9
      PCK = %b00
      CHN = 0
      ASK = 1.  The instruction does not need to be responded.  This flag
                specifies the field REQ_ID presence.
      EXT = 0/1

Top      Up      ToC       Page 28 
      OPR_LENGTH = 1/2  ; Depends on length of the CTID.
      REQ_ID - The value is taken from the instruction TASK_REG.
      Operands:
         4/8 octets: The CTID assigned to the task on the JCP.
      The optional extension headers:
         _JOB_NAME - This header contains the name of the Job.

5.2.3     TASK_REJECT

   The instruction "To reject the task" (TASK_REJECT) is sent from JCP
   as the negative response to TASK_REG instruction.  TASK_REJECT has
   the following values of fields:

      OPCODE = 10
      PCK = %b00
      CHN = 0
      ASK = 1.  The instruction does not need to be responded.  This flag
                specifies presence of the REQ_ID field.
      EXT = 0/1
      OPR_LENGTH = 1
      REQ_ID - The value is taken from the instruction CONTROL_REQ
      Operands:
         2 octets: The basic error code.  The zero-value is not
                   available.
         2 octets: The additional error code.
      The optional extension headers:
         _INACT_TIME - This header contains the inaction time (see
                       section 5.7).
         _MSG - contains the arbitrary error description.

5.2.4     TASK_CHK

   With the purposes of a safety the node, which have received request
   about the opening of session connection, may check up at JCP the
   node, which has initialed connection, even if the task was already
   initiated.

   The instruction "To check up the task" (TASK_CHK) is sent from the
   node, which has received the instruction of the establishment of
   session connection SESSION_OPEN, to JCP.  The task with given GJID,
   must have existed on the node already.  The instruction TASK_CHK
   format coincides with TASK_REG.  OPCODE = 11.  The response to the
   instruction TASK_CHK JCP forms instructions TASK_REG similarly.

   JCP confirms the instruction TASK_CHK if a task with received GTID
   and LTID already has registered on JCP.

   The sending of the TASK_CHK is optional.

Top      Up      ToC       Page 29 
5.3    Establishment of session connection

   The session connection is established between two tasks of one job.
   The connection is established under the VM initiative and it is used
   for the exchange of the instructions between VM.

   One session connection must be connected only with one task on the
   node.  The task may have several connections with different nodes.
   Between two nodes must be only one session connection with one GJID.

   The request about the establishment of session connection contains
   the global identifier of the job GJID.  If the node receives the
   request about the establishment of connection with GJID, which is not
   presented on the given node, VM must create a new task.  If the task
   has been already initialized, the new task is not created.

   The session connection needs to be established over TCP.  After the
   connection is established, the sending of the instructions, which are
   not require of execution response, is possible through UDP.  One TCP
   connection may be used by several session connections.  One session
   connection may use several TCP connections.

   The protocol allows working without the establishment of session
   connection.  The node must have VM by default, which must execute the
   instructions without the establishment of connection.

   At the establishment of session connection, the sides agree about the
   used VM type and the subset of the protocol functions.  The session
   connection UMSP may be asymmetrical.  It means, that two sides of one
   connection can be connected with VM of the different type and provide
   the different subset of the protocol functions.

   If at an establishment of session connection the zero-type VM is
   used, it specifies group VM (see section 9).  The zero-value of
   realization VM is not allowed.

   The procedure of the establishment of session connection may contain
   from 2-way up to 8-way handshakes.

5.3.1     SESSION_OPEN

   The instruction "To open a session" (SESSION_OPEN) is used for the
   initiation of session connection and for the specification of
   connection parameters during handshake.  It has the following values
   of fields:

Top      Up      ToC       Page 30 
      OPCODE = 12
      PCK = %b00/11.  In the first instruction (initial) the value of
                       this field is set to %b00.  In all subsequent -
                       %b11.
      CHN = 0
      ASK = 1
      EXT = 0/1
      OPR_LENGTH = 6 - 10 ; Depends on length GJID and LTID.
      SESSION_ID - In the first instruction this field is absent.  In all
                   subsequent, it contains the identifier of sessions,
                   assigned by the instruction receiver.
      REQ_ID - This field contains the session connection identifier,
               assigned by the instruction sender.
      Operands:
         2 octets: The VM type required from the addressee.
         2 octets: The VM version required from the addressee.
         4 octets: The profile of connection required from the
                   instruction addressee.
         2 octets: The VM type of the sender.
         2 octets: The VM version of the sender.
         4 octets: The profile of connection given by the instruction
                   sender.
         2 octets: The number of 256 octet blocks in the buffer,
                   allocated for session ("window"), on the side of the
                   sender of this instruction (see section 7.4).  The
                   zero-value specifies absence of the buffer.
         4-16 octets: GJID.
         4/8 octets: LTID of the sender task, assigned on the node -
                     sender of the instruction.  It is used in the
                     instruction TASK_REG (as a part of the field GTID).

   If the VM type and version, required from the addressee, have the
   value 0, the receiving node independently chooses the VM type and
   reports it in the response.  The establishment of connection without
   binding to VM or VM group is not allowed.

   Totally, it can be transmitted up to 7 instructions SESSION_OPEN at
   the establishment of connection.  The instruction SESSION_ACCEPT is
   used for the response of the establishment of connection.  For the
   refusal of connection the instruction, SESSION_REJECT is used.

   It is possible to refuse connection on any step.  It is necessary
   either to confirm connections, or to refuse it on the eighth step.

   During the establishment of connection the following parameters may
   be changed:

Top      Up      ToC       Page 31 
   o  VM type and VM version;
   o  profiles of connection.

   If the repeated request about opening of session connection is
   received from the definite node, while one connection with received
   GJID have been already established, the following variants are
   possible:

   (1) If the request has arrived from the node JCP, it is necessary:
       o  To finish the existing task emergency and to deallocate all
          dynamic resources belong to it.
       o  To initiates a task without request of the JCP sanction again.
       o  To confirm the establishment of connection.
   (2) If the request arrived not from the JCP node, it is necessary to
       refuse the establishment of new session connection.  The existing
       task does not need to be changed.

5.3.2     SESSION_ACCEPT

   The instruction "To accept the session" (SESSION_ACCEPT) is used for
   positive response to the establishment of session connection.  It has
   the following values of fields:

      OPCODE = 13
      ASK = 1
      PCK = %11
      EXT = 0/1
      CHN = 0
      OPR_LENGTH = 0
      SESSION_ID - This field contains the session connection identifier
                   of assigned by the node of the addressee of the
                   instruction.
      REQ_ID - This field contains the session connection identifier,
               assigned by the instruction sender.

5.3.3     SESSION_REJECT

   The instruction "To reject the session" (SESSION_ACCEPT) is used for
   negative response to the establishment of session connection.  It has
   the following values of fields:

      OPCODE = 14
      ASK = 0
      PCK = %b11
      EXT = 0/1
      CHN = 0
      OPR_LENGTH = 1

Top      Up      ToC       Page 32 
      SESSION_ID - This field contains the session connection identifier
                   of assigned by the node of the addressee of the
                   instruction.
      Operands:
         2 octets: The basic error code.  The zero-value is not
                   available.
         2 octets: The additional error code.
      The optional extension headers:
         _MSG - contains the arbitrary error description.

5.3.4     Connection Profile

   The profile of connection is defined in 4-octet field of flags.  The
   flags have identifiers S0 - S31.  The number in the identifier is
   defining the serial number of bit.  If the flag is set to 1, the
   function, connected with it, is provided.  If the flag is set to 0,
   the function, connected with it, is not provided (not required).  The
   list of functions, determined at the establishment of session
   connection, are described further.

   Work with chains:

      S0 - Use of fragmented instructions.
      S1 - Use of sequences.
      S2 - Use of transactions.

   Establishment of connection:

      S3 - Use the exchange of the data without the establishment of
           connection.
      S4 - Use the exchange of the data with the establishment of
           connection.

   The instructions format:

      S5  - Reserved.  Must have set to 0.
      S6  - Use of 16-octet address in the exchange instructions.
      S7  - Use of the compressed form of header of the instruction
            (OPR_LENGTH < > %b111) is allowed
      S8  - Use of the extension form of header of the instruction
            (OPR_LENGTH = %b111) is allowed
      S9  - Use of the extension headers with the data field up to 254
            octets of length.
      S10 - Use of the extension headers with the data field up to 4 *
            10^9 octets of length.
      S11-S15  Maximal length of the data field in operands in the 4
               octet words.  These bits are the common field.  Maximal
               length in octets is computed under the formula:

Top      Up      ToC       Page 33 
                  <max length> = (<value of this field> + 1) * 4.
               If the value is equal %b1111, maximal length of the data
               is defined by the instruction format.
      S16-S19  These bits are the common field.  In the profile required
               from the addressee of the instruction, this field
               contains the version of the UMSP.  It must is set to the
               value %b0001.  In the profile given sender of the
               instruction, this field contains priority of the job.  The
               more is value of this field, the more priority.  The
               priority of the job is used:
               o In queues on sending to the transport layer for the
                 instructions of the job.
               o For set of sending priority of the transport layer.
               o For set of computing priority of the task.
      S20 - making the border multiple of 4 octets.  If S16 = 1:
         (1)  OPR_LENGTH = %b111
         (2)  Each extension header and the field of operands begin with
               the border multiple of four octets.
         (3)  The necessary number of zero octets is added in the end of
              each header.
      S21 - Use of the procedures name of objects.
      S22 - Use of the objects name.

   The permissible instructions:

      S23 - The response of the execution on VM (instruction RSP) is
            provided.
      S24 - Use of data reading and comparison instructions.
      S25 - Use of data writing instructions.
      S26 - Use of control transfer instructions.
      S27 - Use of synchronize instruction.
      S28 - Use of instructions of work witch objects.
      S29 - Use of the immediate access to memory of object.  If this
            flag is set to 0, the access to object is solved only
            through its procedures.  If S28=0, this flag must be set to
            0.
      S30 - Use of instruction MVRUN in zero-session.
      S31 - Reserved.  Must have set to 0.

5.4    Session Closing

   Initiate closing session connection the node must only, which has
   initiated its establishment.  It uses the SESSION_CLOSE instruction
   for this purpose.  The procedure of break of connection is 3-way
   handshake.  The procedure of unconditional emergency end of
   connection is stipulated.  It can be transmitted by any node.

Top      Up      ToC       Page 34 
   Let node A is the initiator of the establishment of a session, and
   the node B is the second side of connection.  The node A must send
   the instruction SESSION_CLOSE for closing session.  The node A may
   recommence sending of the instructions after sending of this
   instruction.  It means that it has refused closing connection.  The
   instructions of response (see section 6) does not influence on the
   closing of connection.  The node, which has sent SESSION_CLOSE, does
   not use the timeout and can be waiting for the response beyond all
   bounds long.

   The node B, after reception of the instruction SESSION_CLOSE, sends
   in the answer the instruction RSP_P.  The zero basic return code
   responds closing session.  The non-zero basic return code cancels
   closing session.  After sending of positive response, the node must
   not use connection during 30-second timeout.  If the instruction
   SESSION_ABEND or any other instruction, except response instruction,
   has not been received from the node A after the expiration of this
   time, the node send the instruction SESSION_ABEND and considers the
   session connection closed.

   The node A sends the instruction SESSION_ABEND after reception of
   positive response on the instruction SESSION_CLOSE.  After that, the
   connection is considered closed.  The node A may refuse closing of
   connection.  For this purpose, any instruction is sent, including
   NOP.  In this case, the procedure of end interrupts, and the session
   connection is translated in the working state.

5.4.1     SESSION_CLOSE

   The instruction "To close the session" (SESSION_CLOSE) initiates the
   end of session connection.  It has the following values of fields:

      OPCODE = 15
      PCK = %b01/11
      CHN = 0
      ASK = 0
      EXT = 0/1
      OPR_LENGTH = 0/1
      SESSION_ID - Contains the session identifier assigned by the
                   addressee.
      Operands:
         2 octets: The basic termination code.
         2 octets: The additional termination code.
      The optional extension header:
         _MSG - contains the arbitrary message.

   The operands may be absent.  It is equivalent to the zero exit code.

Top      Up      ToC       Page 35 
5.4.2     SESSION_ABEND

   The instruction "Abend of session" SESSION_ABEND is applied to
   unconditional end of session.  The node, which has sent this
   instruction, finishes the exchange of the data on connection at both
   sides, not waiting responses from other node.  The instruction has
   the following values of fields:

      OPCODE = 16
      PCK = %b01/11
      CHN = 0
      ASK = 0
      EXT = 0/1
      OPR_LENGTH = 0/1
      SESSION_ID - Contains the session identifier assigned by the
                   addressee.
      Operands:
         2 octets: The basic termination code.
         2 octets: The additional termination code.
      The optional extension header:
         _MSG - contains the arbitrary message.

   The operands may be absent.  It is equivalent to the zero termination
   codes.

5.5    Task Termination

   The task is finished during the process of the job finishing at the
   normal end of the user application working.  This procedure is
   described in the following item.  The following situations require
   finishing the task irrespective of the job:

   o  There are not enough of computing resources for maintenance of the
      task on the node;
   o  The node finishes the work;
   o  If VM has accepted such decision for the internal reasons.

   The references to the resources allocated by the task can be on any
   node, on which the job is carried out.  Therefore, all nodes must be
   notified of the end of the task.

   Node, finishing the task, must abnormally close all session
   connections joining the finished task (to send the instruction
   SESSION_ABEND).

Top      Up      ToC       Page 36 
5.5.1     TASK_TERMINATE

   The instruction "To terminate the task" (TASK_TERMINATE) is sent from
   the node, on which the task is finished, to JCP.  The instruction has
   the following values of fields:

      OPCODE = 17
      PCK = %b00
      CHN = 0
      ASK = 0
      EXT = 0/1
      OPR_LENGTH = 2/3  ; Depends on the length of CTID.
      Operands:
         2 octets: The basic termination code.
         2 octets: The additional termination code.
         4/8 octets: CTID.
      The optional extension header:
         _MSG - contains the arbitrary message.

   After sending of the instruction TASK_TERMINATE to JCP, the node
   sends the instruction of unconditional end of connection
   ABEND_SESSION on all session connections connected with a task.
   After that, the task is considered completed.

   If the basic return code in the instruction TASK_TERMINATE is equal
   to 0, it is not required to notify other nodes about the end of the
   task.  Such situation arises, if the task did not allocate dynamic
   resources.  If the basic return code is unequal to 0, JCP must notify
   about the task end the other nodes, on which the job is carried out,
   after reception of the instruction TASK_TERMINATE.  JCP responds for
   the notification of all nodes of the job about the task end.

5.5.2     TASK_TERMINATE_INFO

   The instruction "The information on terminating of the task"
   (TASK_TERMINATE_INFO) is used for the notification about the task
   end.  It is sent from JCP to other nodes, on which the job is carried
   out.  The instruction has the following values of fields:

      OPCODE = 18
      PCK = %b00
      CHN = 0
      ASK = 0
      EXT = 0/1
      OPR_LENGTH = 2-5 ; Depends on the length of GTID.
      Operands:
         2 octets: The basic termination code.
         2 octets: The additional termination code.

Top      Up      ToC       Page 37 
         4-16 octets: GTID of the terminated task.  JCP forms GTID from
                      LTID (from the instruction TASK_REG) and address
                      of transport layer of the task.
      The optional extension header:
         _MSG - contains the arbitrary message.

   The fields of termination codes are taken from the instruction
   TASK_TERMINATE.  The job must delete (to make invalid) all references
   to resources concerning the node, on which the completed task worked,
   at reception of the instruction TASK_TERMINATE_INFO.

5.6    Job Completion

   The job is finished, when the appropriated to it the user application
   on the node, on which it was initiated, is finished.  The end of the
   job occurs under the initiative of VM.  Besides, it can be completed
   under the JCP initiative at ending the lifetime of the job or at end
   of the JCP node working.

5.6.1     JOB_COMPLETED

   The instruction "The task is completed" (JOB_COMPLETED) is sent from
   the node, which initiated the job, in the JCP side.  It has the
   following values of fields:

      OPCODE = 19
      PCK = %b00
      CHN = 0
      ASK = 0
      EXT = 0/1
      OPR_LENGTH = 2/3 ; Depends on the CTID length.
      Operands:
         2 octets: The basic completion code.
         2 octets: The additional completion code.
         4/8 octets: CTID of the completed task of the job.  CTID is a
                     part GJID of the job.
      The optional extension header:
         _MSG - contains the arbitrary message.

   After sending of the instruction JOB_COMPLETED to JCP, the node sends
   on all connected with the session connections of the job the
   instruction of unconditional end of connection ABEND_SESSION.  After
   that, the job is considered completed.

   JCP must notify of the end of the job the nodes, on which the job is
   carried out, after reception of the instruction JOB_COMPLETED.  JCP
   responds for the notification of all nodes of the job about end of
   the job.

Top      Up      ToC       Page 38 
   The instruction TASK_TERMINATE_INFO may be transferred under the
   initiative JCP, if node of the task has abnormal terminated work.

5.6.2     JOB_COMPLETED_INFO

   The instruction "The information on completion of the job"
   (JOB_COMPLETED_INFO) is used for the notification about end of the
   job.  It is sent from JCP to other nodes, on which the job is carried
   out.  The instruction has the following values of fields:

      OPCODE = 20
      PCK = %b00
      CHN = 0
      ASK = 0
      EXT = 0/1 ;
      OPR_LENGTH = 2-5 ; Depends on the GJID length and presence of
                         fields completion code.
      Operands:
         2 octets: The basic completion code.
         2 octets: The additional completion code.
         4-16 octets: GJID of the completed job.
      The optional extension header:
         _MSG - contains the arbitrary message.

   The fields of completion codes are optional.

   The fields of completion codes are taken from the instruction
   JOB_COMPLETED.  At reception of the instruction, JOB_COMPLETED_INFO
   the node must make the following:

   (1)  To remove all session connections, connected to the task.  At
        that, it is not necessary to send network primitives.
   (2)  To abnormally finish the task of the job and to deallocate all
        dynamic resources of the task.

   The instruction JOB_COMPLETED_INFO is used for the end of the job
   under the JCP initiative at the end of lifetime or at end of the JCP
   node working.  In these cases, the node initiated the job is the
   first addressee of the instruction.

   JCP considers the job completed after sending of all instructions
   JOB_COMPLETED_INFO.

5.7    Activity Control of Nodes

   UMSP unites nodes, which have any arrangement in the network and
   which are not having uniform controls.  Each of nodes can be
   disconnected or reloaded at any moment of time.  However, other nodes

Top      Up      ToC       Page 39 
   can be not notified about it.  The fact of breaking or repeated
   establishment of transport connection cannot be the indicator of
   disconnect or restart of the node.  The control of transport
   connections is not the part of the UMSP protocol and the presence of
   transport connection is not obligatory.

   Besides the separate task on the node can be finished emergency.
   Procedure described in section 5.5.1 in this case must be executed.
   If this procedure cannot be executed, must is abnormally finished
   work of the node.

   The JCP executes the functions of the control of nodes activity.  The
   instruction of request of the status TASK_REQ is sent periodically
   between tasks on nodes and JCP for this purpose.

   The following actions JCP are possible at detection of deactivating
   of the node:

   (1)  If the task initiated the job was finished, it is considered,
        that the job is completed.  JCP sends the instruction
        JOB_COMPLETED_INFO to all other nodes, on which the job was
        executed.
   (2)  JCP sends the instruction TASK_TERMINATE_INFO to all other nodes
        of the job, if the task, which has not initiated the job, is
        finished.

   The deactivating of the JCP node imposes the restriction on GJID
   appropriated by it after reloading.  The following variants are
   probable:

   (1)  The disconnection of the JCP node passed normally.  It
        transferred to all nodes, which it has controlled, instruction
        JOB_COMPLETED_INFO.  In this case, it can appropriate anyone
        GJID after reloading.
   (2)  There is the emergency disconnect of the JCP node.  It has not
        informed all nodes about the deactivating.  In this case, it
        must guarantee after reloading, that new GJID will not concur
        witch the GJID, existing up to the reload, during two maximal
        intervals of inactivity time (which sets this JCP).

   The reload of nodes, which are not being JCP, does not impose
   restrictions on LTID established on these nodes.

5.7.1     _INACTION_TIME

   The extension header "The time of inaction" (_INACTION_TIME) allows
   setting the inaction time of the node (non JCP).  It has the
   following values of fields:

Top      Up      ToC       Page 40 
      HEAD_CODE = 2
      HEAD_LENGTH = 1;
      HOB = 1
      DATA contains:
         2 octets: The inaction period.  The number of 0,5 second
         intervals, through which the activity of the node - sender of
         the instruction from the side JCP - will be checked.

   The inaction period must be more than three intervals of the maximal
   time of delivery at the transport layer.  The waiting period in queue
   to the transport layer does not influence on timeout.

   The header _INACTION_TIME may be attached to the following
   instructions:

   (1)  To the instruction TASK_REG.  In this case must be satisfied
        condition - on node there must not be other active tasks, which
        are controlled the JCP of addressee.  The zero-value specifies
        that the activity checking is unused.  The absence of the header
        specifies that the inaction period must be set on the JCP.
   (2)  To the instruction TASK_REJECT, if the time from the instruction
        TASK_REG does not fit for JCP.
   (3)  To the instruction TASK_CONFIRM, if instruction TASK_REG had no
        this header.

   If JCP receives the instruction TASK_REG with the attached heading
   _INACTION_TIME, it must check up presence of active tasks with sender
   node (as it can mean, that the node was reloaded).  If such tasks
   exist, for each of them it is necessary to execute procedure of end
   of the task described in section 5.6.2.  The instruction TASK_CONFIRM
   must be sent only after that.

5.7.2     STATE_REQ

   The instruction "State Request" (STATE_REQ) is sent from JCP to the
   definite task of other node.  The instruction has the following
   values of fields:

      OPCODE = 21
      PCK = %b00
      CHN = 0
      ASK = 0
      EXT = 0
      OPR_LENGTH = 1/2 ; Depends on the LTID length.
      Operand:
         4/8 octets: LTID, established on the node of the instruction
                     addressee.

Top      Up      ToC       Page 41 
   The instruction STATE_REQ will be sent in the defined task but it has
   concern with node.  It is sent, if between the node and JCP was not
   sending of the instruction during inactive time.  The task activated
   after sending of last instruction STATE_REQ does not influence the
   control of activity.

   The instruction TASK_STATE is sent in reply to STATE_REQ.  At
   expectation of the response, the timeout equal to one inaction period
   is used.  After the expiration of the timeout the node is considered
   switched - off.

   If the node not receives of any instructions from JCP during two
   intervals of inaction time, it is considered, that JCP has finished
   the work.  The actions of the node in this case are described in
   section 5.6.2 at receiving the instruction JOB_COMPLETED_INFO.  The
   check of this condition is optional for the node.

   If at JCP there are no active tasks connected with the defined node,
   the control of activity of this node will not be carried out.

5.7.3     TASK_STATE

   The instruction "Task State" (TASK_STATE) is sent from the definite
   task to JCP.  It serves for the response of the instruction
   STATE_REQ.  The instruction has the following values of fields:

      OPCODE = 22
      PCK = %b00
      CHN = 0
      ASK = 0
      EXT = 0
      OPR_LENGTH = 1/2/3 ; Depends on the CTID length.
      Operands:
         1 octet:  The state code of task.  The following values are
                   defined for this field:
            %x01 - The task is active and has active session
                   connections.
            %x02 - The task is active and have no session connections.
            %x03 - The task is active, have no session connections and
                   have no resources, allocated on the node.
            %x04 - The task is completed.
         1/3 octets: Reserved.  If OPR_LENGTH = 1, then this field has
                     length 1 octet, else 3 octets. JCP must not check
                     the value of this field.  It is established in zero
                     value by sending.
         2/4/8 octets: CTID connected with LTID from the instruction
                       STATE_REQ.

Top      Up      ToC       Page 42 
   If OPR_LENGTH = 1 that length of the reserved field is equal to one
   octet and length CTID makes two octets.  In all other cases, length
   of the reserved field is equal 3 octets and length CTID - not less
   than 4 octets.

5.7.4     NODE_RELOAD

   The instruction "The node was reloaded" (NODE_RELOAD) is sent to JCP
   as the negative response to STATE_REQ instruction.  NODE_RELOAD has
   the following values of fields:

      OPCODE = 23
      PCK = %b00
      CHN = 0
      ASK = 0
      EXT = 0
      OPR_LENGTH = 1/2 ; Depends on the LTID length.
      Operands:
         4/8 octets: LTID.  The value is taken from the instruction
                     STATE_REQ.

   The instruction RELOAD_NODE indicates, that the task with given LTID
   for given JCP on the node is absent.  At reception of this
   instruction, JCP must make the following:

   (1)  To send the instruction STATE_REQ to all tasks of the node,
        which were initiated before a sending of the penultimate
        instruction STATE_REQ.
   (2)  To wait for ending of one inaction interval after sending of the
        last instruction STATE_REQ (on which the negative response is
        received).
   (3)  To send the instructions STATE_REQ to all tasks of the node,
        which were initiated between last and penultimate instructions
        STATE_REQ (not including instructions from item 1).

   For all instructions STATE_REQ the positive response (TASK_STATE) or
   negative response (RELOAD_NODE) must be transmitted.

5.8    Work without session connection

   The protocol provides the data exchange between nodes without an
   establishment of session connection.  In this case, initialization of
   the job and tasks is not made and JCP is not used.

   The format of the instructions, transmitted without the establishment
   of connection, is completely correspond to the instructions
   transmitted by session connections.  The difference is that the field
   SESSION_ID has zero value or PCK = %b00.

Top      Up      ToC       Page 43 
   The node, supporting work without the establishment of session
   connection, must have VM, which executes by default the instructions
   transmitted without the establishment of connection.  In fact, these
   instructions are executed within the framework of a so-called zero-
   session (or zero-task) of this VM.  The memory address space of this
   VM is accessible without a connection establishment.

   The instruction SESSION_INIT with SESSION_ID = 0 and REQ_ID = 0
   allows to specify parameters of its zero-session and to request the
   zero-session parameters of the addressee node.  If the node, which
   has received such instruction, provides the requiring profile, it
   sends the instruction SESSION_ACCEPT.  If the profile is not
   provided, the answerback instruction SESSION_INIT will send, in which
   the field SESSION_ID and REQ_ID also have the value 0.  Actually,
   such instructions of session initialization do not establish
   connection, but have the information meaning.  The exchange of the
   data by zero-session can occur irrespective of its.

   There are the following restrictions at working without connection:

   o  The chain must be sent, only if it is completely located in one
      segment of the transport layer.
   o  It is impossible to request an allocation of memory and to create
      objects (except instruction MVRUN).  This objects is not adhered
      to the definite job and is not automatically release the resources
      at the end of the job, which has created them.
   o  Parameters of functions and the returned values must not contain
      the pointers, because the node can be reloaded at any moment.  It
      will result that the pointers will become invalid or will address
      other objects.

   The protocol cannot check those conditions.  Their realization lays
   on VM wholly.

   The work without establishment of session connection may be used in
   the following systems:

   o  In simple devices, which do not have the operational system;
   o  On servers which are executed a plenty of requests (for work
      without connection of resources is used less);
   o  In systems requiring the fast response to rare requests (if
      keeping of connection is inexpedient).


Next RFC Part