HP OpenVMS Systems Documentation
OpenVMS Programming Concepts Manual
17.2.2 JSB Call Format (VAX only)
The JSB call format indicates that the named routine is called using the VAX JSB instruction. The routine returns using Return from Subroutine (RSB). You can use the JSB call format with only the VAX MACRO and VAX BLISS languages.
Explanatory text might follow the procedure call format or the JSB call
format, or both. This text is present only when needed to clarify the
format. For example, in the call format, you indicate that arguments
are optional by enclosing them in brackets (). However, brackets
alone cannot convey all the important information that might apply to
optional arguments. For example, in some routines that have many
optional arguments, if you select one optional argument, you must also
select another optional argument. In such cases, text following the
format clarifies this.
The Returns heading contains a description of any information returned
by the routine to the caller. A routine can return information to the
caller in various ways. The following subsections discuss each
possibility and then describe how this returned information is
Most routines return a condition value in register R0. This condition value contains various kinds of information, the most important for the caller (in bits <3:0>) being the completion status of the operation. You test the condition value to determine whether the routine completed successfully.
On Alpha processors, a 32-bit condition value is represented in the Alpha register sign-extended to 64 bits.
If you program in high-level languages for OpenVMS environments, the fact that status information is returned by means of a condition value and that it is returned in a hardware register is of little importance because you receive this status information in the return (or status) variable. The run-time environment established for the high-level language program allows the status information in R0 to be moved automatically to the user's return variable.
Nevertheless, for routines that return a condition value, the Returns heading in the documentation contains the following information:
The OpenVMS usage entry specifies the OpenVMS data type of the information returned. Because a condition value in any OpenVMS operating system environment is returned in a specific condition value structure, the OpenVMS usage entry is cond_value.
The type entry specifies the standard data type of the information returned. Because the condition value structure is 32 bits, the type heading is longword (unsigned).
The access entry specifies the way in which the called routine accesses the object. Because the called routine is returning the condition value, the routine writes the value into R0, so the access heading is write only.
The mechanism heading specifies the passing mechanism used by the called routine in returning the condition value. Because the called routine is writing the condition value directly into R0, the mechanism heading is by value. (If the called routine had written the address of the condition value into R0, the passing mechanism would have been by reference.)
Note that if a routine returns a condition value, another main heading
in the documentation format (Condition Values Returned) describes the
possible condition values that the routine can return.
If a routine returns actual data, the Returns heading in the documentation of that routine contains the following information (for example, from a math routine):
In this mathematics routine notation, the OpenVMS data type is floating_point and the standard data type is G_floating point. The meaning of the contents of the access and mechanism headings is discussed in Sections 17.4.3 and 17.4.4.
The registers used to return values vary with the type of the result and the specific hardware environment. For more information, see the OpenVMS Calling Standard.
In addition, under the Returns heading, some text can be provided after the information about the type, access, and mechanism. This text explains other relevant information about what the routine is returning.
For example, because the routine is returning actual data in the VAX or
Alpha registers, the registers cannot be used to convey completion
status information. All routines that return actual data in VAX or
Alpha registers must signal the condition value, which
contains the completion status. Thus, the text under the Returns
heading points out that the routine signals its completion status.
Although most routines return condition values, some routines choose to signal their condition values using the OpenVMS signaling mechanism. Routines can signal their completion status whether or not they are returning actual data in the hardware registers, but all routines that return actual data in the hardware registers must signal their completion status if they are to return this status information at all.
If a routine signals its completion status, text under the Returns heading explains this, and the Condition Values Signaled heading in the documentation format describes the possible condition values that the routine can signal.
Compaq's system routines never signal condition values indicating
success. Only error condition values are signaled.
Detailed information about each argument is listed in the call format under the Arguments heading. Arguments are described in the order in which they appear in the call format. If the routine has no arguments, the word None appears.
The following format is used to describe each argument:
A paragraph of structured text describing the arguments follows the
argument format along with additional information, if needed.
The purpose of the OpenVMS usage entry is to facilitate the coding of source-language data type declarations in application programs. Ordinarily, the standard data type, discussed in Section 17.4.2, is sufficient to describe the type of data passed by an argument. However, within the OpenVMS operating system environment, many system routines contain arguments whose conceptual nature or complexity requires additional explanation. For instance, when an argument passes the name of an event flag, the type entry longword (unsigned) alone does not indicate the nature of the value. In this instance, an accompanying OpenVMS usage entry, denoting the OpenVMS data type ef_number, further explains the actual usage.
See Table E-1 for a list of the possible OpenVMS usage entries and their definitions. Refer to the appropriate language implementation table in Appendix E to determine the correct syntax of the type declaration in the language you are using.
Note that the OpenVMS usage entry is not a traditional data type (such
as the standard data types of byte, word, longword, and so on). It is
significant only within the context of the OpenVMS operating system and
is intended solely to expedite data declarations within application
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.
17.4.3 Access Entry
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.
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:
17.4.5 Explanatory Text
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:
17.5 Condition Values Returned Heading
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.