As far as the ADAM parameter system is concerned, there are two aspects of instrumentation tasks which cause them to behave differently from standard data analysis tasks (A-tasks). The first is the way they are linked. The second is the form of the interface file declarations.
Whenever an A-task executes, the parameter system is started-up, the application is called, then the parameter system is closed-down. For an instrumentation task this continuous opening-closing of the parameter system does not happen. There are two obvious consequences of this. Firstly, parameters remain ACTIVE once they have been given a value. Secondly, global associations for WRITE never happen.
All the parameters of an instrumentation task are available to all the actions. In addition, a specific OBEY or CANCEL can specify that values of named parameters can be passed on the command line.
The order in which NEEDS declarations occur specifies the order in which the values are expected on the command-line.
An item of special interest to programmers of instrumentation systems is the value-search-path (VPATH) declaration INTERNAL. An INTERNAL parameter has the following properties which distinguish it from ordinary parameters.
If it is a scalar, it is stored as a variable inside the parameter system. All other parameter values are stored in HDS. This means that access to INTERNAL scalar parameters is much faster than access to ordinary parameters. This property may be of interest to instrumentation applications which make heavy use of the parameter system.
An INTERNAL parameter is not prompted for. All other parameters have an implicit PROMPT at the end of their VPATH declarations unless it is explicitly overridden by NOPROMPT.
The behaviour of PAR_PUTxx is different for an INTERNAL parameter. Putting an INTERNAL parameter simply puts the given value into the parameter. For an ordinary parameter, the parameter system expects to be told an existing HDS component into which the value should be put.