HP OpenVMS Systems Documentation

A variant of the noncontiguous array descriptor is used to specify an array of unaligned bit strings. Each array element is an unaligned bit string data type (DSC$K_DTYPE_VU) that starts and ends on an arbitrary bit boundary. The length of each element is the same and is 0 to 2¹⁶ - 1 bits. You can access elements of the array directly by using the VAX variable bit field instructions. Therefore, the descriptor provides two components: a byte address, BASE, and a means to compute the signed bit offset, EB, with respect to BASE of an array element.

The unaligned bit array descriptor consists of four contiguous blocks that are always present. The first block contains the descriptor prototype information. Figure 5-12 shows the format of an unaligned bit array descriptor. Table 5-13 describes the fields of the descriptor.

Figure 5-12 Unaligned Bit Array Descriptor Format

The following formulas specify the signed effective bit offset, EB, of an array element:

The signed effective bit offset, EB, of A(I₁):

   EB = V0 + S1*I1
      = POS + S1*[I1 - L1]

The signed effective bit offset, EB, of A(I₁,I₂):

   EB = V0 + S1*I1 + S2*I2
      = POS + S1*[I1 - L1] + S2*[I2 - L2]

The signed effective bit offset, EB, of A(I₁, ... , I_n):

   EB = V0 + S1*I1 + ... + Sn*In
      = POS + S1*[I1 - L1] + ... + Sn*[In - Ln]

Note that EB is computed ignoring integer overflow.

On VAX systems, EB is used as the position operand, and the content of BASE is used as the base address operand in the VAX variable-length bit field instructions. Therefore, BASE must specify a byte within 2²⁸ bytes of all bytes of storage in the bit array.

For example, consider a single-origin, one-dimensional, five-element array consisting of 3-bit elements allocated adjacently (therefore, S1 = 3). Assume BASE is byte 1000 and the first actual element, A(1), starts at bit <4> of byte 1001.

The following dependent field values occur in the descriptor:

   POS = 12
   V0  = 12 - 3*1 = 9

A variant of the fixed-length string descriptor is used to specify strings where the string is viewed as a one-dimensional array with user-specified bounds. Figure 5-13 shows the format of a string with bounds descriptor. Table 5-14 describes the fields of the descriptor.

Figure 5-13 String with Bounds Descriptor Format

The following formula specifies the effective address, E, of a string element A(I):

   E = POINTER + [I - SB_L1]

If the string must be extended in a string comparison or assignment, the space character (hexadecimal 20 if ASCII) is used as the fill character.

5.13 Unaligned Bit String with Bounds Descriptor (CLASS_UBSB)

A variant of the unaligned bit string descriptor is used to specify bit strings where the string is viewed as a one-dimensional bit array with user-specified bounds. Figure 5-14 shows the format of an unaligned bit string with bounds descriptor. Table 5-15 describes the fields of the descriptor.

Figure 5-14 Unaligned Bit String with Bounds Descriptor Format

The following formula specifies the effective bit offset, EB, of a bit element A(I):

   EB = POS + [I - UBSB_L1]

All descriptor class codes from 0 through 191 not otherwise defined in this standard are reserved to Compaq. Classes 192 through 255 are reserved to Compaq's Computer Special Systems Group and customers.

Table 5-16 lists some specific descriptor classes and codes that are obsolete or reserved to Compaq.

Descriptor class codes 160 through 191 are reserved to Compaq for facility-specific purposes. These codes must not be passed between facilities, because different facilities might use the same code for different purposes. These codes can be used by compiler-generated code to pass parameters to the language-specific, run-time support procedures associated with that language or to the OpenVMS Debugger.

An OpenVMS condition is a hardware-generated synchronous exception or a software event that is to be processed in a manner similar to a VAX or an Alpha hardware exception.

Floating-point overflow exception, memory access violation exception, and reserved operation exception are examples of hardware-generated conditions. An output conversion error, an end of file, and the filling of an output buffer are examples of software events that might be treated as conditions.

Depending on the condition and on the program, you can exercise any of four types of action when a condition occurs:

• Ignore the condition.
  For example, if an underflow occurs in a floating-point operation, continuing from the point of the exception with a zero result might be sufficient.
• Take some special action and continue from the point at which the condition occurred.
  For example, if the end of a buffer is reached while a series of data items are being written, the special action is to start a new buffer.
• End the operation and branch from the sequential flow of control.
  For example, if the end of an input file is reached, the branch exits from a loop that is processing the input data.
• Treat the condition as an unrecoverable error.
  For example, when the floating divide-by-zero exception condition occurs, the program exits after writing (optionally) an appropriate error message.

When an unusual event or error occurs in a called procedure, the procedure can return a condition value to the caller indicating what has happened (see Section 6.1). The caller tests the condition value and takes the appropriate action.

When an exception is generated by the hardware, a branch out of the program's flow of control occurs automatically. In this case, and for certain software-generated events, it is more convenient to handle the condition as soon as it is detected rather than to program explicit tests.

6.1 Condition Values

Condition values are used in the OpenVMS operating system to provide the following functions:

• Indicate the success or failure of a called procedure as a function value
• Describe an exception condition when an exception is signaled
• Identify system messages
• Report program success or failure to the command language level

A condition value is a longword that includes fields to describe the software component that generates the value, the reason the value was generated, and severity status of the condition value. Figure 6-1 shows the format of a condition value. Table 6-1 describes the fields of a condition value.

Figure 6-1 Format of a Condition Value