The way an application obtains a value from a parameter is to get the value. In simple terms, a get operation is the equivalent of a Fortran read, though it can do much more. In this example,
CALL PAR_GET0L( 'FLAG', VALUE, STATUS )
gets a logical value from the parameter FLAG and stores it in the logical variable VALUE. The data type is logical because of the L suffix in the routine's name. If VALUE were a character variable, you would use a similar routine, but this time with a C suffix as shown below.
CALL PAR_GET0C( 'STRING', VALUE, STATUS )
There are similar routines for the other primitive data types, each with
an appropriate suffix: D for double precision, I for integer and R for
real. By convention where a routine has variants for different data
types it has an ``x'' suffix, so in this case the routines are known
collectively as PAR_GET0x. Note that there are no routines for
obtaining byte and word values. These must be obtained using the
integer version of the routine. The variable STATUS is the inherited
status value adhering to the rules in
SUN/104,
and summarised in
Section . The 0 in the routine name indicates that the
routine passes a scalar (zero dimensions). Likewise a routine with a 1
in its name passes a vector, and with an N it passes an n-dimensional
array.
There is a maximum length for the parameter name (set by ADAM) of fifteen characters, but this is quite adequate except perhaps for lexicographers.
The actual value of the parameter supplied to the application at run time need not necessarily have the same data type as you have requested in your application. The parameter system will handle conversions between the type of the value and the type required by the application. So you only need to concern yourself with what your application requires.
What does the user see? This will depend on the implementation, but suppose the user is prompted for a value. If you had in your code
CALL PAR_GET0R( 'THRESHOLD', THRESH, STATUS )
The user might see
THRESHOLD - Give the intensity threshold >
with the parameter name first, followed by a prompt string briefly describing the function of the parameter. (In the ADAM implementation this string is usually defined within the interface file, but there is a PAR routine for setting it within the application itself.) Suppose the user enters 32768 in response to the above prompt. The next time the user ran the application there could be a suggested default of the last-used value like this,
THRESHOLD - Give the intensity threshold /32768/ >
which could be accepted merely by pressing the return key.
In the ADAM implementation the PAR_GET calls will (re-)prompt whenever the user gives too many values or an invalid value. Invalid values include supplying a character string where a number is required, and being outside the interface file range or in constraints.
PAR Interface to the ADAM Parameter System