Document revision date: 15 July 2002 | |
Previous | Contents | Index |
In actuality, an argument does not have a data type; rather, the data specified by an argument has a data type. The argument is merely the vehicle for passing data to the called routine. Nevertheless, the phrase argument data type is used to describe the standard data type of the data specified by the argument.
Procedure calls result in the construction of an argument list. (This process is described in the OpenVMS Calling Standard.) An argument list is a sequence of entries together with a count of the number of entries.
On VAX systems, an argument list is represented as a vector of longwords, where the first longword contains the count and each remaining longword contains one argument.
On Alpha systems, an argument list is represented as quadword entities that comprise an argument item sequence, partly in hardware registers and (when there are more than six arguments) partly on the stack. The argument information (AI) register contains the argument count that specifies the number of 64-bit argument items.
When arguments are passed by descriptors, these standard data types are defined with symbolic codes. Table 17-3 lists the standard data types for VAX and Alpha systems that can appear for the type entry in an argument description, along with their symbolic code (DTYPE) used in argument descriptors.
For a detailed description of each of the following symbolic codes, see the OpenVMS Calling Standard.
Data Type | Symbolic Code |
---|---|
Absolute date and time | DSC$K_DTYPE_ADT |
Byte integer (signed) | DSC$K_DTYPE_B |
Bound label value | DSC$K_DTYPE_BLV |
Bound procedure value 1 | DSC$K_DTYPE_BPV |
Byte (unsigned) | DSC$K_DTYPE_BU |
COBOL intermediate temporary | DSC$K_DTYPE_CIT |
D_floating | DSC$K_DTYPE_D |
D_floating complex | DSC$K_DTYPE_DC |
Descriptor | DSC$K_DTYPE_DSC |
F_floating | DSC$K_DTYPE_F |
F_floating complex | DSC$K_DTYPE_FC |
G_floating | DSC$K_DTYPE_G |
G_floating complex | DSC$K_DTYPE_GC |
H_floating 1 | DSC$K_DTYPE_H |
H_floating complex 1 | DSC$K_DTYPE_HC |
S_floating (32-bit IEEE) 2 | DSC$K_DTYPE_FS |
T_floating (64-bit IEEE) 2 | DSC$K_DTYPE_FT |
X_floating (128-bit IEEE) 2 | DSC$K_DTYPE_FX |
S_floating complex 2 | DSC$K_DTYPE_FSC |
T_floating complex 2 | DSC$K_DTYPE_FTC |
X_floating complex 2 | DSC$K_DTYPE_FXC |
Longword integer (signed) | DSC$K_DTYPE_L |
Longword (unsigned) | DSC$K_DTYPE_LU |
Numeric string, left separate sign | DSC$K_DTYPE_NL |
Numeric string, left overpunched sign | DSC$K_DTYPE_NLO |
Numeric string, right separate sign | DSC$K_DTYPE_NR |
Numeric string, right overpunched sign | DSC$K_DTYPE_NRO |
Numeric string, unsigned | DSC$K_DTYPE_NU |
Numeric string, zoned sign | DSC$K_DTYPE_NZ |
Octaword integer (signed) | DSC$K_DTYPE_O |
Octaword (unsigned) | DSC$K_DTYPE_OU |
Packed decimal string | DSC$K_DTYPE_P |
Quadword integer (signed) | DSC$K_DTYPE_Q |
Quadword (unsigned) | DSC$K_DTYPE_QU |
Character string | DSC$K_DTYPE_T |
Aligned bit string | DSC$K_DTYPE_V |
Varying character string | DSC$K_DTYPE_VT |
Unaligned bit string | DSC$K_DTYPE_VU |
Word integer (signed) | DSC$K_DTYPE_W |
Word (unsigned) | DSC$K_DTYPE_WU |
Unspecified | DSC$K_DTYPE_Z |
Procedure entry mask 1 | DSC$K_DTYPE_ZEM |
Sequence of instruction 1 | DSC$K_DTYPE_ZI |
The access entry describes the way in which the called routine accesses the data specified by the argument, or access method. The following methods of access are most common:
Following is a complete list of access methods that can appear under the access entry in an argument description:
For more information, see the OpenVMS Calling Standard.
17.4.4 Mechanism Entry
The way in which an argument specifies the actual data to be used by the called routine is defined in terms of the argument passing mechanism. There are three basic passing mechanism types:
Passing Mechanism | Descriptor Symbolic Code |
---|---|
By descriptor, fixed-length (scalar) | DSC$K_CLASS_S |
By descriptor, dynamic string | DSC$K_CLASS_D |
By descriptor, array | DSC$K_CLASS_A |
By descriptor, procedure | DSC$K_CLASS_P |
By descriptor, decimal string | DSC$K_CLASS_SD |
By descriptor, noncontiguous array | DSC$K_CLASS_NCA |
By descriptor, varying string | DSC$K_CLASS_VS |
By descriptor, varying string array | DSC$K_CLASS_VSA |
By descriptor, unaligned bit string | DSC$K_CLASS_UBS |
By descriptor, unaligned bit array | DSC$K_CLASS_UBA |
By descriptor, string with bounds | DSC$K_CLASS_SB |
By descriptor, unaligned bit string with bounds | DSC$K_CLASS_UBSB |
For each argument, one or more paragraphs of explanatory text follow the OpenVMS usage, type, access, and mechanism entries. The first paragraph is highly structured and always contains information in the following sequence:
A condition value is a longword that has the following uses on the OpenVMS VAX and OpenVMS Alpha systems:
The OpenVMS Calling Standard explains in detail the uses for the condition value and depicts its format and contents.
The Condition Values Returned heading describes the condition values that are returned by the routine when it completes execution without generating an exception condition. These condition values describe the completion status of the operation.
If a called routine generates an exception condition during execution, the exception condition is signaled; the exception condition is then handled by a condition handler (either user supplied or system supplied). Depending on the nature of the exception condition and on the condition handler, the called routine either continues normal execution or terminates abnormally.
If a called routine executes without generating an exception condition, the called routine returns a condition value in one or two of the following ways:
The method used to return the condition value is indicated under the Condition Values Returned heading in the documentation of each routine. These methods are discussed individually in the following subsections.
Under these headings, a two-column list shows the symbolic code for each condition value the routine can return and an accompanying description. The description explains whether the condition value indicates success or failure and, if failure, what user action might have caused the failure and what to do to correct it. Condition values that indicate success are listed first.
Symbolic codes for condition values are defined by the system. Though the condition value consists of several fields, each of which can be interpreted individually for specific information, the entire condition value itself can be interpreted as an integer, and this integer has an equivalent symbolic code.
The three sections that follow discuss the ways in which the called
routine returns condition values.
17.5.1 Condition Values Returned
The possible condition values that the called routine can return in general register R0 are listed under the Condition Values Returned heading in the documentation. Most routines return a condition value in this way.
In the documentation of system services that complete asynchronously,
both the Condition Values Returned and Condition Values Returned in the
I/O Status Block headings are used. Under the Condition Values Returned
heading, the condition values returned by the asynchronous service
refer to the success or failure of the system service request---that
is, to the status associated with the correctness of the syntax of the
call, in contrast to the final status associated with the completion of
the service operation. For asynchronous system services, condition
values describing the success or failure of the actual service
operation---that is, the final completion status---are listed under the
Condition Values Returned in the I/O Status Block heading.
17.5.2 Condition Values Returned in an I/O Status Block
The possible condition values that the called routine can return in an I/O status block are listed under the Condition Values Returned in the I/O Status Block heading.
The routines that return condition values in the I/O status block are the system services that are completed asynchronously. Each of these asynchronous system services returns to the caller as soon as the service call is queued. This allows the continued use of the calling program during the execution of the service operations. System services that are completed asynchronously all have arguments that specify an I/O status block. When the system service operation is completed, a condition value specifying the completion status of the operation is written in the first word of this I/O status block.
Representing a condition value in a word-length field is possible for
system services because the high-order segment of all system service
condition values is 0. See cond_value in Table E-1
or Section 18.11 for the field detail of the condition value structure.
17.5.3 Condition Values Returned in a Mailbox
The possible condition values that the called routine can return in a mailbox are listed under the Condition Values Returned in a Mailbox heading.
Routines such as SYS$SNDOPR that return condition values in a mailbox
send information to another process to perform a task. The receiving
process performs the action and returns the status of the task to the
mailbox of the sending process.
17.5.4 Condition Values Signaled
The possible condition values that the called routine can signal (instead of returning them in R0) are listed under the Condition Values Signaled heading.
Routines that signal condition values as a way of indicating the completion status do so because these routines are returning actual data as the value of the routine.
As mentioned, the signaling of condition values occurs whenever a routine generates an exception condition, regardless of how the routine returns its completion status under normal circumstances.
Previous | Next | Contents | Index |
privacy and legal statement | ||
5841PRO_049.HTML |