7 The ACTION Specification

 7.1 The Context Specification and NEEDS Field
 7.2 The Action KEYWORD Field
 7.3 The HELP Field

The concept of ACTION is specific to instrumentation tasks (see SUN/134). The task is capable of obeying or cancelling a number of distinct commands known as actions. It does this, for example, in response to the ICL command:

  SEND taskname context actionname parameter_list

where context is OBEY or CANCEL.

Actions have to be declared in the Interface File, following the parameter declarations. The Action Specification is of the form:

  ACTION actionname
     fieldname fieldvalue
     context specifications
        .
  ENDACTION

Where actionname is a character string specifying a valid action name. The same rules should be applied to action names as are applied to parameter names (see Appendix A.1).

7.1 The Context Specification and NEEDS Field

The Context Specifications allow command-line parameter positions to be allocated differently for different actions and contexts of the task. The Context Specification is of the form:

     context
        NEEDS parametername_1
        NEEDS parametername_2
         .
     ENDcontext

where context is OBEY or CANCEL.

The order of the NEEDS fields within the Context Specification defines the order in which parameters may be specified on the command line for this particular action and context.

If no NEEDS list is specified, positions will default to those specified in the Parameter Specification.

Example
  ACTION FIRST
     OBEY
        NEEDS PAR1
        NEEDS PAR2
        NEEDS PAR3
     ENDOBEY
     CANCEL
        NEEDS PAR2
     ENDCANCEL
  ENDACTION

For historical reasons, NEEDS specifications can have RANGE or IN constraints but these have no effect.

Example
  ACTION GET_FILTER
     OBEY
        NEEDS FILTER IN ’R’, ’I’, ’J’
        NEEDS DEAD_TIME RANGE 1.0, 5.5
     ENDOBEY
        .
  ENDACTION

7.2 The Action KEYWORD Field

This field specifies the name by which the action is known to the person running the I-task.

The field is of the form:

  KEYWORD  name

where name is a character string specifying a valid keyword. The same rules should be applied to action keywords as are applied to parameter keywords (see Appendix A.1).

Example
  INTERFACE FILTASK
        .
     ACTION GET_FILTER
        KEYWORD FIND_FILTER
        OBEY
           NEEDS FILTER IN ’R’, ’I’, ’J’
           NEEDS DEAD_TIME RANGE 1.0, 5.5
        ENDOBEY
           .
     ENDACTION
        .
  ENDINTERFACE

This field is used to specify the word that the user uses to communicate with a particular action. Thus the user could specify:

  ICL> send filtask obey find_filter

As can be seen, this completes the separation between the program’s view of actions and the user’s view of them. It is possible for the programmer to re-write the program using completely different action names, but the user command could be kept the same by just changing the ACTION statements in the Interface File. Similarly the user’s view of the program can be changed by just changing the action KEYWORD fields.

If the KEYWORD field is not specified for an action, then the system will use the action name as the keyword.

7.3 The HELP Field

This field is used to specify some help text for an action. No current user interfaces make use of this.

The field is of the form:

  HELP help-text

where help-text is a character string giving help information about the action.

Example
  ACTION GET_FILTER
     KEYWORD FIND_FILTER
     HELP ’This causes the filter to be selected’
     OBEY
        NEEDS FILTER IN ’R’, ’I’, ’J’
        NEEDS DEAD_TIME RANGE 1.0, 5.5
     ENDOBEY
        .
  ENDACTION