$ PASCAL/LIST [DIR]M

$ PASCAL/LIST A, B, C

$ PASCAL X + Y + Z

$ PASCAL A, B, C+D/LIST, F

$ PASCAL A + CIRC/NOOBJECT + X 

This command completely suppresses the object file; that is, source files A.PAS, CIRC.PAS, and X.PAS are concatenated and compiled, but no object file is produced.

This section describes the command and file qualifiers that you can use when compiling code.

For More Information:

A compilation listing file usually contains source code because the /SHOW=SOURCE qualifier is enabled by default. The /LIST qualifier does not initiate the printing of the listing file. To obtain a line printer copy of your listing file, use the PRINT command.

$ DEFINE SYS$LP_LINES 100
$ PASCAL/LIST [DIR]M

The following sections describe the contents of each part of the listing file.

For More Information:

IDC-PL-SL
     0  0             1 program hw(output);
     0  0             2 begin
  C  0  0             3 ! Comment line
     0  1             4  writeln('Built with ',%compiler_version);
     0  0             5 end.

$ LINK DANCE.OBJ, CHACHA.OBJ, SWING.OBJ

$ LINK/EXECUTABLE=TEST CIRCLE

$ LINK SCHEDULE,COURSES/INCLUDE=(HISTORY,ALGEBRA,PHILOSOPHY)

This example shows the use of the /INCLUDE qualifier with a library named COURSES. The linker extracts the modules HISTORY, ALGEBRA, and PHILOSOPHY from the library COURSES and includes them in the executable image SCHEDULE.EXE.

$ LINK SCHEDULE,COURSES/LIBRARY/INCLUDE=(HISTORY,ALGEBRA, PHILOSOPHY)

$ LINK UPDATE/EXE=[PROJECT.EXE]/MAP=[PROJECT.MAP]

For More Information:

The following are command and file qualifiers that you can use when linking object modules:

For More Information:

$ LINK GARDEN,VEGETABLES/INCLUDE=(EGGPLANT,TOMATO, BROCCOLI,ONION)

Besides program modules, an object module library can also contain a symbol table with the names of each global symbol in the library, and the name of the module in which they are defined. You specify the name of the object module library containing symbol definitions with the /LIBRARY qualifier. When you use the /LIBRARY qualifier during a link operation, the linker searches the specified library for all unresolved references found in the included modules during compilation.

Also, by default, the linker automatically searches the system-supplied shareable image library SYS$LIBRARY:IMAGELIB.OLB after searching any libraries you specify on the LINK command.

$ LINK BADMINTON, TENNIS, RACQUETBALL, RACQUETS/LIBRARY

For More Information:

For More Information:

a := b * c + e * f;

h := a + g - b * c;

IF ((b * c) - h) <> 0 THEN ...

t := b * c;

a := t + e * f;

h := a + g - t;

IF ((t) - h) <> 0 THEN ...

Two computations of b * c have been eliminated. In this case, you could have modified the source program itself for greater program optimization.

VAR
   a, b : ARRAY[1..25, 1..25] OF REAL;
{In the executable section:}
a[i,j] := b[i,j];

t1 := (j - 1) * 25 + i;
t2 := (j - 1) * 25 + i;
a[t1] := b[t2];

t = (j - 1) * 25 + i;
a[t] := b[t];

CONST
   Debug_Switch = FALSE;
{In the executable section:}
IF  Debug_Switch  THEN  WRITELN( 'Error found here' );

The IF statement is designed to write an error message if the value of the symbolic constant Debug_Switch is TRUE. Suppose that the error has been removed, and you change the definition of Debug_Switch to give it the value FALSE. When the program is recompiled, the compiler can determine that the THEN clause will never be executed because the IF condition is always FALSE; no machine code is generated for this clause. You need not remove the IF statement from the source program.

Code that is otherwise unreachable, but contains one or more labels, is not eliminated unless the GOTO statement and the label itself are located in the same block.

FOR j := 1 TO i + 23 DO
   BEGIN
   IF Selector THEN a[i + 23, j - 14] := 0
   ELSE b[i + 23, j - 14] := 1;
   END;

t := i + 23;
FOR j := 1 TO t DO
   BEGIN
   u := j - 14;
   IF Selector THEN a[t,u] := 0
   ELSE b[t,u] := 1;
   END;

This removes the calculation of j – 14 from the IF statement, and the calculation of i + 23 from both the IF statement and the loop.

Square := SQR( a );

Square := a * a;

The program executes faster because the algorithm for the SQR function has already been included in the machine code.

Inline code expansion for user-declared routines performs in the same manner as inline code expansion for predeclared functions: the compiler can often replace calls to user-declared routines with an inline expansion of the routine's executable code. Inline code expansion is useful on routines that are called only a few times. The overhead of an actual procedure call is avoided, which increases program execution. The size of the program, however, may increase due to the routine's expansion.

To determine whether or not it is desirable to inline expand a routine, compilers use a complex algorithm.

(-c) * (b - a)

c * (a - b)

These two operations produce the same result, but because the compiler has eliminated negation or complement operations, the machine code produced is more efficient.

WHILE ( i < 10 ) AND ( a[i] <> 0 ) DO
   BEGIN
   a[i] := a[i] + 1;
   i := i + 1;
   END;

In this WHILE statement, the order in which the two subexpressions ( i < 10 ) and ( a[i] <> 0 ) are evaluated is not specified; in fact, the compiler may evaluate them simultaneously. Regardless of which subexpression is evaluated first, if its value is FALSE the condition being tested in the WHILE statement is also FALSE. The other subexpression need not be evaluated at all. In this case, the body of the loop is never executed.

WHILE ( i < 10 ) AND_THEN ( a[i] <> 0 ) DO
   BEGIN
   a[i] := a[i] + 1;
   i := i + 1;
   END;

The compiler keeps track of the values assigned to variables and traces the values to most of the places that they are used. If it is more efficient to use the value rather than a reference to the variable, the compiler makes this change. This optimization is called value propagation. Value propagation causes the object code to be smaller, and may also improve run-time speed.

Strength reduction speeds computations by replacing a multiply operation with a more efficient add instruction when computing array addresses each time around a loop.

v:= 3.0 *q;
   .
   .
   .
x:= SIN(y)*v:
   .
   .
   .
v:= PI*x:
   .
   .
   .
y:= COS(y)*v;

This example shows that the variable v has two disjoint usage sections. The value of v in the first section does not affect the value of v in the second section. The compiler may use different registers for each section.

Code scheduling is a technique for reordering machine instructions to maximize the amount of overlap of the multiple execution units inside the CPU. The exact scheduling algorithms depend on the implementation of the target architecture.

Loop unrolling is a technique for increasing the amount of code between branch instructions and labels by replicating the body of a loop. Increasing the code optimizes instruction scheduling. The following code shows such a transformation:

Original Code

FOR i:= 1 to 12 DO
    a[i]:= b[i] + c[i]

Unrolled Loop Code

i:= 1
WHILE i < 12 DO
    BEGIN
    a[i]:= b[i] + c[i];
    a[i+1]:= b[i+1] + c[i+1];
    a[i+2]:= b[i+2] + c[i+2];
    a[i+3]:= b[i+3] + c[i+3];
    i:= i+4;
    END;

In this example, the loop body was replicated four times, allowing the instruction scheduler to overlap the fetching of array elements with the addition of other array elements.

/OPTIMIZE=UNROLL="number"

Numbers larger than 4 may improve performance at a cost of additional code size. However, larger numbers may decrease performance due to cache requirements, register conflicts, and other factors.

The compiler aligns the labels it generates for the top of loops, the beginnings of ELSE branches, and others, on machine-specific boundaries by filling in unused bytes with NO-OP instructions.

A branch to a longword-aligned address is faster than a branch to an unaligned address. This optimization may increase the size of the generated code; however, it increases run-time speed.

a := x/y;

t := x/y;

b := x/y;

a := t;

FOR i := 1 TO 10 DO

b := t;

     c[i] := c[i] * x/y;

FOR i := 1 TO 10 DO
          c[i] := c[i] * t;

If the value of y is 0.0, the unoptimized program would produce 12 divide-by-zero errors at run time; the optimized program produces only one. (The variable t is a temporary variable created by the compiler.) Eliminating redundant calculations and removing invariant calculations from loops can affect the detection of such arithmetic errors. You should keep this in mind when you include error-detection routines in your program.

VSI Pascal provides support for generating code for specific Alpha processors and for tuning code for a preferred processor. The supported Alpha processors are EV4, EV5, EV56, EV6, EV7, EV67, and EV68.

The EV4 and EV5 processors are basically identical, with the only difference in the preferred instruction scheduling phase. The EV56 processor added byte and word opcodes. The EV6 processor added a SQRT instruction, instructions to move data directly between floating and integer registers, and a few other instructions. The EV7 processor is similar to the EV6 processor with differences only in the instruction scheduling phase.

The default architecture (see the /ARCHITECTURE qualifier) is for the EV4 processor. This restricts the compiler to instructions that exist on the EV4 processor. It essentially tells the compiler the earliest Alpha processor that will execute the code. If you run the code on earlier Alpha systems, you might get invalid opcode errors or OpenVMS might attempt to emulate the instructions at a severe performance penalty.

The default tuning (see the /OPTIMIZE=TUNE qualifier) is “generic.” The tuning is for an average Alpha processor. You can achieve better performance it you allow the compiler to tune the code for a specific processor.

Specifying an explicit /ARCHITECTURE setting also defaults the /OPTIMIZE=TUNE setting to the same processor.

For example, specifying /ARCHITECTURE=EV56/OPTIMIZE=TUNE=EV7 tells the compiler to use instructions that the generated code should be able to run on an EV56 system, but that it should tune the generated code for best performance on an EV7 system. In these situations, the compiler can actually generate multiple code sequences, one using only EV56 instructions, and the other using EV7 instructions and the AMASK instruction to dynamically execute the faster sequence based on the system executing the program.

Since most Alpha systems are EV56 or later, you might see a significant improvement by specifying /ARCHITECTURE=EV56 on the command line.

The following command lines will result in producing the fastest code from the compiler. Depending on the system, use one of the following:

PASCAL /NOZERO_HEAP /OPT=LEVEL=4 /NOCHECK

PASCAL /NOZERO_HEAP /MATH_LIBRARY=FAST /OPT=LEVEL=4 /NOCHECK /ARCH=HOST
/ASSUME=NOACCURACY_SENSITIVE

In both cases, you may also want to use the performance flagger to identify datatypes that could be modified for additional performance.

For More Information:

IF f( a ) AND f( b ) THEN ...

q := f( a ) + f( a );

Q := 2 * f( a )

If the compiler does so, and function f has side effects, the side effects would occur only once because the compiler has generated code that evaluates f( a ) only once.

If you wish to ensure left-to-right evaluation with short circuiting, use the AND_THEN and OR_ELSE Boolean operators.

For More Information:

The smallest possible value of the INTEGER type is represented by the predeclared constant −MAXINT. The largest possible value of the INTEGER type is represented by the predeclared constant MAXINT. However, the underlying architecture supports an additional integer value, which is (−MAXINT −1). If your program contains a subexpression with this value, the program's evaluation might result in an integer overflow trap. Therefore, a computation involving the value (−MAXINT −1) might not produce the expected result. To evaluate expressions that include (−MAXINT −1), you should disable either optimization or integer overflow checking.

Similarly, (−MAXINT64 −1) might not produce the expected results.

VAR
   x : INTEGER;
   p : ^INTEGER;
{In the executable section:}
NEW( p );
p^ := 0;
x  := 0;
IF p^ = x THEN  p^ := p^ + 1;

If a pointer variable in your program must refer to a variable with an explicit name, that variable must be declared VOLATILE or READONLY. The compiler makes no assumptions about the value of volatile variables and therefore performs no optimizations on them.

Use of the ADDRESS function, which creates a pointer to a variable, can result in a warning message because of optimization characteristics. By passing a nonread-only or nonvolatile static or automatic variable as the parameter to the ADDRESS function, you indicate to the compiler that the variable was not allocated by NEW but was declared with its own identifier. Because the compiler's assumptions are incorrect, a warning message occurs. You can also use IADDRESS, which functions similarly to the ADDRESS function except that IADDRESS returns an INTEGER_ADDRESS value and does not generate any warning messages. Use caution when using IADDRESS.

Similarly, when the parameter to ADDRESS is a formal VAR parameter or a component of a formal VAR parameter, the compiler issues a warning message that not all dynamic variables allocated by NEW may be passed to the function.

For More Information:

VAR
   x : INTEGER;
   a : RECORD
      CASE t : BOOLEAN OF
         TRUE   : ( b : INTEGER );
         FALSE  : ( c : REAL );
      END;
{In the executable section:}
x := a.b + 5;
a.c := 3.0;
x := a.b + 5;

Record a has two variants, b and c, which are located at the same storage address. When the assignment a.c := 3.0 is executed, the value of a.b becomes undefined because TRUE is no longer the currently valid variant. When the statement x := a.b + 5 is executed for the second time, the value of a.b is unknown. The compiler may choose not to evaluate a.b a second time because it has retained the field's previous value. To eliminate any misinterpretations caused by this assumption, variable a should be associated with the VOLATILE attribute. The compiler makes no assumptions about the value of VOLATILE objects.

For More Information:

When data is shared by multiple code streams (either multiple processes, multiple threads, or asynchronous events such as AST routines or condition handlers), you need to be aware of certain issues to guarantee correct sharing of data.

You must inform the compiler that the data being shared may change in an asynchronous fashion. By default, the compiler assumes that data is only modified by assignment statements, routine calls, etc. If the data is being changed in a way that the compiler does not know about you must use the VOLATILE attribute to tell the compiler that it must fetch the data in an atomic fashion from memory at each reference and the compiler must store the data in an atomic fashion back into memory at each assignment.

To accomplish atomic access on VSI OpenVMS x86-64 systems often requires no additional work by the compiler. The underlying x86-64 architecture's memory model provides atomic-like access in many situations. In other places, the compiler might have to use the x86-64 lock instruction prefix or the cmpxchg64 instruction.

To accomplish atomic access on VSI OpenVMS I64 systems for volatile objects 64 bits or smaller, fetches and stores are done with the normal ldn and stn instructions.

To accomplish atomic access on VSI OpenVMS Alpha systems for volatile objects smaller than 32 bits, fetches and stores are done with the LDx_L/STx_C instruction sequence. This pair of instructions ensures that the volatile data is accessed in an atomic fashion. Without the VOLATILE attribute, you will not get this special instruction sequence, and the data might become corrupted if two writers are trying to store to the shared data at the same time. Items of 32 bits or 64 bits are accessed with single longword and quadword instructions and do not use the LDx_L/STx_C sequence. Newer Alpha systems include byte and word instructions. See the /ARCHITECTURE qualifier for more information. Only aligned data objects are guaranteed to be accessed atomically. Larger objects that are manipulated with run-time routines are not atomic, as those routines may be interrupted.

Granularity is a term on Alpha machines to describe the situation where two threads update nearby data at the same time. Because the compiler on the older Alpha must fetch the surrounding longword or quadword, modify it, and store it back, the two threads could possibly overwrite each others data. For these situations, the nearby data should be moved to separate quadwords or use the /GRANULARITY qualifier to tell the compiler that you want longword or byte granularity at the expense of additional LDx_L/STx_C sequences. (See the /ARCHITECTURE qualifier for more information on the byte and word instructions available on newer Alpha systems.)

The Alpha, Itanium, and Intel-64 (x86-64) architectures do not guarantee that independent writes will complete in the order in which they were issued. These architectures provide a special instruction to serialize write operations. VSI Pascal provides the BARRIER built-in routine on these systems to generate the MB instruction on Alpha systems. The mf instruction on Itanium systems or the mfence instruction on x86-64 systems are used to preserve write ordering.

If your code uses a higher-level synchronization scheme to guard critical regions (such as a lock manager or a semaphore package), then using the VOLATILE attribute, the /GRANULARITY qualifier, and the INTERLOCKED/ATOMIC built-ins may not be necessary; you have already ensured that there are only single readers/writers in the critical section.

To prevent conflicts between optimization and debugging, you should always compile your program with a compilation switch that deactivates optimization until it is thoroughly debugged. Then you can recompile the program (which by default is optimized) to produce efficient code.

For More Information:

LSE accepts keywords, or tokens, for all languages with LSE support, but the specific tokens themselves are language-defined. For example, you can expand the %INCLUDE token only when using VSI Pascal.

Likewise, LSE provides placeholders, or prompt markers, for all languages with LSE support, but the specific text or choices these markers call for are language-defined. For example, you see the %{environ_name_string}% placeholder only when using VSI Pascal.

Some VSI Pascal keywords, like TYPE, VAR, IF, and FOR, can be placeholders as well as tokens. LSE supplies language constructs for these keywords when they appear on your screen as placeholders. You can also type the keywords into the buffer yourself, enter the EXPAND command, and see the same language constructs appear on your screen.

LSE> SHOW TOKEN IF        {lists the token IF}
LSE> SHOW TOKEN           {lists all tokens  }

LSE> GOTO BUFFER $SHOW
LSE> SAVE FILE filename.filetype

The CDD/Repository supports some data types that are not native to VSI Pascal. If a data definition contains a field declared with an unsupported data type, VSI Pascal replaces the field with one declared as a [BYTE(n)] RECORD END, where n is the appropriate length in bytes. By making the data addressable in this way, you are able to manipulate the data either by passing it to external routines as variables or by using the VSI Pascal type casting capabilities to perform an assignment.

However, because these empty records do not have fields, the size of the record is 0 bits. They should not be used in expressions or passed to formal value parameters. Recall that a size attribute used on a type definition has no effect on fetches. When fetching from these records, the compiler will fetch the actual size of the record, 0 bits.

Program Show_Keys(OUTPUT);

TYPE
    %DICTIONARY 'Mail_Order_Info/LIST'

VAR
    Old_Customer_File   : FILE OF Mail_Order;
    Order_Rec           : Mail_Order;
    Continue            : BOOLEAN;

BEGIN
OPEN( File_Variable := Old_Customer_File,
      File_Name     := 'Customers.Dat',
      History       := OLD,
      Organization  := Indexed,
      Access_Method := Keyed );
FINDK(Old_Customer_File, 1, '1000', NXTEQL);
Continue := TRUE;
WHILE Continue and NOT UFB(Old_Customer_File) DO
    BEGIN
    READ(Old_Customer_File, Order_Rec);
    IF Order_Rec.Zip_Code < '5000'
    THEN
        WRITELN('Order number', Order_Rec.Order_Num, 'has zip code',
        Order_Rec.Zip_Code)
    ELSE
        Continue := False;
    END;
END.

During the compilation of Show_Keys, the record definition Mail_Order_Info is extracted from the CDD/Repository. Show_Keys prints the order number and zip code of each file component that has a zip code greater than or equal to 1000 but less than 5000.

Each time a routine is called, the VSI Pascal compiler constructs a parameter list.

On VSI OpenVMS x86-64 systems, the parameters are a sequence of quadword (8-byte) entries. The first 6 integer parameters are located in integer registers designated as %rdi, %rsi, %rdx, %rcx, %r8, and %r9; the first 8 floating-pointer parameters are located in floating-point registers designated as %xmm0 to %xmm7. The packing of smaller values into these registers are further described in the VSI OpenVMS Calling Standard. Information about the parameter list is passed in the argument information register (%rax). The second byte of the register specifies the parameter count. Additional arguments are passed on the top of the stack.

On VSI OpenVMS I64 systems, the parameters are a sequence of quadword (8-byte) entries. The first 8 integer parameters are located in integer registers designated as R32 to R39; the first 8 floating-point parameters are located in floating-point registers designated as F8 to F15. Information about the parameter list is passed in the argument information register (R25). The first byte of the register specifies the parameter count. Arguments beyond 8 are passed on the stack starting at offset +16.

On VSI OpenVMS Alpha systems, the parameters are a sequence of quadword (8-byte) entries. The first 6 integer parameters are located in integer registers designated as R16 to R21; the first 6 floating-point parameters are located in floating-point registers designated as F16 to F21. Information about the parameter list is passed in the argument information register (R25). The first byte of the register specifies the parameter count. Arguments beyond 6 are passed on the top of the stack.

The form in which the parameters in the list are represented is determined by the passing mechanisms you specify in the formal parameter list and the values you pass in the actual parameter list. The parameter list contains the actual parameters passed to the routine.

In VSI Pascal, a function returns to the calling block the value that was assigned to its identifier during execution. VSI Pascal chooses one of three methods for returning this value. The method chosen depends on the amount of storage required for values of the type returned, as follows:

On VSI OpenVMS x86-64 Systems:

On VSI OpenVMS I64 Systems:

On VSI OpenVMS Alpha Systems:

Note that functions that require the use of an extra parameter can have no more than 254 parameters; functions that store their results in registers can have 255 parameters.

The VSI OpenVMS I64, VSI OpenVMS Alpha, and VSI OpenVMS x86-64 system conventions define three types of procedures. The calling process does not need to know what type it is calling; the compiler chooses which type to generate based on the requirements of the procedure.

On VSI OpenVMS x86-64 Systems:

On VSI OpenVMS x86-64 systems, the types of procedures are:

In order to provide accurate exception handling, the compiler always generates a frame pointer in the %rbp register. The compiler does not create routines without a frame pointer. The compiler also does not use the "red zone" as described in the OpenVMS Calling Standard.

On VSI OpenVMS x86-64 systems, the compiler determines the exact contents of the stack frame, but all stack frames have common characteristics:

On VSI OpenVMS I64 Systems:

On VSI OpenVMS Alpha Systems:

If a stack frame is required, it consists of a fixed part (which is known at compile time) and an optional variable part.

For More Information:

By default, routines declared at program or module level and all other routines declared with the INITIALIZE, GLOBAL, or EXTERNAL attributes have the characteristics of unbound routines. Routines passed by the immediate value mechanism must be UNBOUND.

Asynchronous system trap routines (ASTs) and RMS completion routines must have both the ASYNCHRONOUS and UNBOUND attributes. Because they are asynchronous, such routines can access only volatile variables, predeclared routines, and other asynchronous routines. Note that the VSI Pascal run-time system does not permit a program and an asynchronous routine (such as an AST) to access the same file simultaneously.

For More Information:

The by immediate value passing mechanism passes a copy of a value instead of the address. VSI Pascal provides the %IMMED foreign passing mechanism and the IMMEDIATE attribute in order to pass a parameter by immediate value. You cannot use variable semantics with the by immediate value passing mechanism.

Values that are less than or equal to 64 bits in size can be passed by immediate value.

On OpenVMS VAX systems, values that are less than or equal to 32 bits in size can be passed by immediate value.

The by reference mechanism passes the address of the parameter to the called routine. This is the default parameter-passing mechanism for non-conformant and non-schematic parameters.

When using the by reference mechanism, the type of passing semantics used depends on the use of the VAR keyword. If the formal parameter name is preceded by the reserved word VAR, variable semantics is used; otherwise, value semantics is used.

In addition to using the defaults, the VSI Pascal compiler provides the %REF foreign passing mechanism and the REFERENCE attribute, which has more than one interpretation for the passing semantics depending on the data item represented by the actual parameter. This allows you to have the called routine use either variable semantics or true foreign semantics. The mechanism specifier appears before the name of a formal parameter. The parameter passing attribute appears in the attribute list of the formal parameter.

There are several types of descriptors. Each descriptor contains a value that identifies the descriptor's type. The called routine then uses the information held in the descriptor to identify its type and size. This is the default parameter-passing mechanism for conformant and schematic parameters.

When you use one of the VSI Pascal by descriptor mechanisms, the compiler passes the address of a string, array, or scalar descriptor. The VSI Pascal compiler generates the descriptor supplying the necessary information.

VSI Pascal provides three attributes for the by descriptor passing mechanism: [CLASS_S], [CLASS_A], and [CLASS_NCA]. With these three attributes, the type of passing semantics used for the by descriptor argument depends on the use of the VAR keyword. If the formal parameter name is preceded by the reserved word VAR, variable semantics is used; otherwise, value semantics is used. The parameter-passing attribute appears in the attribute list of the formal parameters.

Sometimes you may want to choose either variable semantics or true foreign semantics. In these cases, the VSI Pascal compiler provides two foreign passing mechanism specifiers, %DESCR and %STDESCR. These specifiers have more than one interpretation for the passing semantics depending on the data type of the actual parameter. The mechanism specifier appears before the name of a formal parameter.

Table 5.3, “Parameter Descriptors” lists the class and type of descriptor generated for parameters that can be passed using the by descriptor mechanism.

[ASYNCHRONOUS,EXTERNAL(SYS$SETDDIR)] FUNCTION $SETDDIR
(%STDESCR New_Dir : PACKED ARRAY [$L1..$U1: INTEGER] OF CHAR;
VAR Old_Dir_Len : $UWORD := %IMMED 0;
VAR Old_Dir : [CLASS_S]PACKED ARRAY [$L2..$U2 : INTEGER] OF CHAR
:= %IMMED 0) : INTEGER; EXTERN;
.
.
.
Status := $SETDDIR(’[VSI_Pascal]’);

TYPE
   Vary = VARYING [30] OF CHAR;

VAR
   Obj_String  : Vary;
   Times_Found : INTEGER;

[EXTERNAL] FUNCTION Search_String( %DESCR String_Val : Vary )
   : BOOLEAN; EXTERNAL;

.
.
.
IF Search_String( Obj_String )
   THEN
   Times_Found := Times_Found + 1;

Table 5.4, “Summary of Passing Mechanisms and Passing Semantics” summarizes the passing semantics used when various mechanisms are specified on either the formal or the actual parameter. For example, if a variable is passed to a formal parameter that was declared without the keyword VAR and either %REF or [REFERENCE] was specified, then variable passing semantics will be used. Likewise, if a variable is passed to a formal parameter which was declared with the keyword VAR and either %REF or [REFERENCE] was specified, then an error will occur.

The Pascal language provides three parameter semantics: “VAR parameters,” “value parameters,” and “routine parameters.” These models define what happens to the parameters, not how the compiler actually implements them. “VAR parameters” are parameters that represent the actual variable passed to the routine. Changes made to the VAR parameter are reflected back to the actual variable passed in to the routine. “Value parameters” are parameters that are local copies of the expression passed into the routine. Changes made to the value parameter are not reflected back to any actual parameter passed in to the routine. “Routine parameters” are parameters that represent entire routines that may be called from inside the called routine.

The VSI Pascal compiler provides three parameter mechanisms: “by immediate value,” “by reference,” and “by descriptor.” These forms represent the actual implementation used by the compiler for the parameter. These forms are denoted by the [IMMEDIATE], [CLASS_S], [CLASS_A], and [CLASS_NCA] attributes (note, the [REFERENCE] attribute doesn't just specify a parameter mechanism, but also specifies a parameter semantic model).

VSI Pascal also provides a fourth parameter model called “foreign parameters.” These parameters become either VAR or value parameters depending on the actual parameter. If the actual parameter is a variable, then the parameter is treated as a VAR parameter. If the actual parameter is an expression, then the parameter is treated as a value parameter. These parameters are denoted by the %REF, %DESCR, and %STDESCR foreign mechanism specifiers and the [REFERENCE] attribute (identical in behavior to the %REF foreign parameter specifier).

Be careful not to confuse the term “value parameter” with the “by immediate value” mechanism. The “value” in “value parameter” describes the semantics of the parameter where changes made to the parameter inside the called routine are not reflected back to the actual parameter. It is a common misconception that VSI Pascal uses the “by immediate value” mechanism for “value parameters.”

By default, VSI Pascal will use the “by reference” mechanism for the following VAR and value parameter types: Ordinal (integer, unsigned, char, Boolean, pointers, subranges, and enumerated types), Real (real, double, quadruple), Record, Array, Set, Varying, and File.

If you want to pass a parameter with the “by immediate value” mechanism, you can place the [IMMEDIATE] attribute on the definition of the formal parameter's definition or use the %IMMED foreign mechanism specifier on the actual parameter to override the default mechanism of the formal parameter. Only ordinal and real types may be passed with the “by immediate value” mechanism. Only value parameters may use the “by immediate value” mechanism.

If you want to accept a value parameter with the “by immediate value,” you can place the [IMMEDIATE] attribute on the definition of the formal parameter. Only ordinal and real types may be accepted with the “by immediate value” mechanism.

[external] procedure rtn( p : [immediate] integer ); external;

begin
rtn(3);
rtn(some-integer-expression);
end;

If you want to pass a parameter with the “by descriptor” mechanism, you can place the [CLASS_A], [CLASS_S], or [CLASS_NCA] attributes on the formal parameter's definition. You can also use the %DESCR and %STDESCR foreign mechanism specifiers, but be aware that these also imply parameter semantics as well as the parameter-passing mechanism.

When passing values to a subrange parameter in a Pascal routine, the argument must be large enough to hold a value of the subrange's base-type even if the formal parameter contained a size attribute.

When passing Boolean or enumerated-type values to a VAR parameter in a Pascal routine, the calling routine must ensure that the sizes of the Boolean or enumerated-type matches the setting of the /ENUMERATION_SIZE qualifier or [ENUMERATION_SIZE] attribute used in the Pascal routine. For value parameters, you can pass the address of a longword as that will work for either setting.

When passing arrays or records to a Pascal routine, the calling routine must ensure that the array and record has the same layout (including any alignment holes) as chosen by the VSI Pascal compiler. You may want to use the /SHOW=STRUCTURE_LAYOUT listing section to help you determine the layout chosen by the VSI Pascal compiler.

By default, VSI Pascal will use the “by descriptor” mechanism for VAR and value conformant parameters. For conformant-varying parameters, VSI Pascal uses a CLASS_VS desciptor. For conformant-array parameters, VSI Pascal uses a CLASS_NCA descriptor.

Using a conformant-varying parameter or STRING schema parameter with a routine not written in Pascal is not very common since the called routine does not know how to deal with these strings. If you just are passing a string expression to the non-Pascal routine, using a conformant PACKED ARRAY OF CHAR is the right solution.

Since VSI Pascal will use either a CLASS_A or CLASS_NCA descriptor for the conformant PACKED ARRAY OF CHAR, but other languages will expect either a CLASS_S descriptor or the string "by reference", you will need to use either the [CLASS_S] attribute or the %REF foreign mechanism specifier.

[external] procedure fortrtn(
            p : [class_s] packed array [l..u:integer] of char); external;

  begin
  fortrtn('string');
  fortrtn(some-string-expression);
  end;

[external] procedure crtn(
                %ref p : packed array [l..u:integer] of char); external;

  begin
  crtn('string'(0));
  crtn(some-string-expression+'0');
  end;

VSI Pascal has additional support to deal with null-terminated strings.

For More Information

When passing strings to an VSI Pascal routine from another language, you must use a descriptor if the Pascal formal parameter is a conformant parameter. VSI Pascal cannot accept a conformant parameter with the “by reference” mechanism. For conformant array parameters, you must generate a CLASS_NCA descriptor unless you select another descriptor class using the [CLASS_S], [CLASS_A], or [CLASS_NCA] attributes. For conformant varying parameters, you must generate a CLASS_VS descriptor on both platforms.

If you wish to use the "by reference" mechanism to pass strings into a Pascal routine, you must define a Pascal datatype that represents a fixed-length string (or varying-string with a maximum size) and use that datatype in the formal parameter definition.

The VSI Pascal schema type STRING is passed by CLASS_VS descriptor. Other VSI Pascal schema types use private data structures when passed between routines and cannot be accessed from routines written in other languages.

On VSI OpenVMS x86-64 Systems:

By default, VSI Pascal on VSI OpenVMS x86-64 systems passes the address of a BPV (Bound Procedure Value) routine PROCEDURE and FUNCTION parameters. This BPV routine is created at run-time and is allocated from special heap storage managed by the compiler. This routine is responsible for loading the static link into register %r10 and then calling the target routine. If you use the [UNBOUND] attribute on the PROCEDURE or FUNCTION parameter or the %IMMED foreign mechanism specifier, the compiler will pass the actual address of the target routine.

On VSI OpenVMS x86-64 systems, VSI Pascal expects the address of code for routine parameters. In all VSI OpenVMS x86-64 languages, asking for the address of a routine yields the address of executable code. The OpenVMS LINKER will create trampoline routines in 32-bit address space if the actual routine is loaded in 64-bit address space.

On VSI OpenVMS I64 Systems:

By default, VSI Pascal on VSI OpenVMS I64 systems passes the address of a function descriptor for PROCEDURE or FUNCTION parameters. The presence of the [UNBOUND] attribute or the %IMMED foreign mechanism specifier has no effect over the generated code since the function descriptors in the OpenVMS Calling Standard allow any combination of bound and unbound routines to be passed around and invoked.

On VSI OpenVMS I64 systems, VSI Pascal expects the address of a function descriptor for routine parameters. In all VSI OpenVMS I64 languages, asking for the address of a routine yields the address of its function descriptor, since the actual address of the instructions is not useful by itself.

On VSI OpenVMS Alpha Systems:

By default, VSI Pascal on VSI OpenVMS Alpha systems passes the address of a procedure descriptor for PROCEDURE or FUNCTION parameters. The presence of the [UNBOUND] attribute or the %IMMED foreign mechanism specifier has no effect over the generated code since the procedure descriptors in the OpenVMS Calling Standard allow any combination of bound and unbound routines to be passed around and invoked.

On VSI OpenVMS Alpha systems, VSI Pascal expects the address of a procedure descriptor for routine parameters. In all VSI OpenVMS Alpha languages, asking for the address of a routine yields the address of its procedure descriptor, since the actual address of the instructions is not useful by itself.

The data specified by a parameter has a data type. Several VSI OpenVMS standard data types exist. A system routine parameter must use one of these data types.

For More Information:

The way in which an argument specifies the actual data to be used by the called routine is defined in terms of the parameter-passing mechanism.

Parameters passed by reference and used solely as input to a system service should be declared with VSI Pascal value semantics; this allows actual parameters to be compile-time and run-time expressions. When a system service requires a formal parameter with a mechanism specifier, you should declare the formal parameter with the READONLY attribute to specify value semantics. Other parameters passed by reference should be declared with VSI Pascal variable semantics to ensure that the output data is interpreted correctly. In some cases, by reference parameters are used for both input and output and should also be declared with variable semantics.

TYPE
   $QUAD = [QUAD,UNSAFE] RECORD
              L0 : UNSIGNED;
              L1 : INTEGER;
           END;

VAR
   Ascii_Time  : VARYING[80] OF CHAR;
   Binary_Time : $QUAD;

[ASYNCHRONOUS,EXTERNAL(SYS$BINTIM)] FUNCTION $BINTIM
   (TIMBUF : [CLASS_S] PACKED ARRAY [$l1..$u1:INTEGER] OF CHAR;
   VAR TIMADR : [VOLATILE] $QUAD)
   : INTEGER; EXTERNAL;
{In the executable section:}
IF NOT ODD ($BINTIM(Ascii_Time, Binary_Time))
THEN
   BEGIN
      WRITELN ('Illegal format for time string');
      HALT;
   END;

The first formal parameter requires the address of a character-string descriptor with value semantics; the second requires an address and uses variable semantics to manipulate the parameter within the service. Because you can call $BINTIM from a condition handler or AST routine, you should declare it with the ASYNCHRONOUS attribute. Also, because you may want to pass a volatile variable to the TIMADR parameter, you should use the VOLATILE attribute to indicate that the argument is allowed to be volatile.

Some system services require a parameter to be the address of a data structure that indicates a function to be performed or that holds information to be returned. Such a structure can be described as a list, a control block, or a vector. The size and POS attributes provide an efficient method of laying out these data structures. The size attributes ensure that the fields of the data structure are of the size required by the system service, and the POS attribute allows you to position the fields correctly.

[INHERIT('SYS$LIBRARY:STARLET')] PROGRAM Userid( OUTPUT );

TYPE
   Uword       = [WORD] 0..65535;
   Itmlst_Cell = PACKED RECORD
                    CASE INTEGER OF
                       1 : (Buf_Len   : Uword;
                            Item_Code : Uword;
                            Buf_Addr  : INTEGER;
                            Len_Addr  : INTEGER);
                       2 : (Term      : INTEGER);
                 END;
VAR
   Username_String   : [VOLATILE] VARYING [12] OF CHAR;
   Itmlst            : ARRAY [1..2] OF Itmlst_Cell := ZERO;
BEGIN
Itmlst[1].Buf_Len := 12;                    { 12 bytes returned }
Itmlst[1].Item_Code := JPI$_USERNAME;       { return user name }
Itmlst[1].Buf_Addr :=                       { store returned name here }
   IADDRESS(Username_String.BODY);
Itmlst[1].Len_Addr :=                       { store returned length here }
   IADDRESS(Username_String.LENGTH);
Itmlst[2].Term := 0;                        { terminate item list }

IF NOT ODD( $GETJPIW(,,,Itmlst) )
THEN
   WRITELN('error')
ELSE
   WRITELN('user name is ',Username_String);
END.

For More Information:

In some cases, you do not have to supply actual parameters to correspond to all the formal parameters of a system service. In VSI Pascal, you can supply default values for such optional parameters when you declare the service. You can then omit the corresponding actual parameters from the routine call. If you choose not to supply an optional parameter, you should initialize the formal parameter with the appropriate value using the by immediate value (%IMMED) mechanism. The correct default value is usually 0.

[ASYNCHRONOUS,EXTERNAL(SYS$CANTIM)] FUNCTION $CANTIM (
        %IMMED REQIDT : UNSIGNED := %IMMED 0;
        %IMMED ACMODE : UNSIGNED := %IMMED 0) : INTEGER; EXTERNAL;

$CANTIM (, PSL$C_USER);
$CANTIM (I);
$CANTIM;

PSL$C_USER is a symbolic constant that represents the value of a user access mode, and I is an integer that identifies the timer request being canceled. If you call $CANTIM with both of its default parameters, you can omit the actual parameter list completely.

[ASYNCHRONOUS] FUNCTION LIB$GET_FOREIGN (
   VAR Resultant_String : [CLASS_S,VOLATILE]
           PACKED ARRAY [$l1..$u1:INTEGER] OF CHAR;
       Prompt_String    : [CLASS_S,TRUNCATE]
           PACKED ARRAY [$l2..$u2:INTEGER] OF CHAR := %IMMED 0;
   VAR Resultant_Length : [VOLATILE,TRUNCATE] $UWORD := %IMMED 0;
   VAR Flags            : [VOLATILE,TRUNCATE] UNSIGNED := %IMMED 0)
           : INTEGER; EXTERNAL;

With this declaration, it is possible to specify values for Resultant_String and Prompt_String and truncate the call list at that point. In this case, two parameters would be passed in the CALL instruction.

You may want to use a combination of the %IMMED 0 and TRUNCATE methods. This combination would allow you to skip the specification of intermediate optional parameters, as well as allow you to truncate the call list once all desired parameters have been specified.

Note that VSI OpenVMS system services require a value to be passed by parameters, including optional parameters; therefore, you should not use the TRUNCATE attribute when defining optional parameters to a system service. Instead, you should specify default values on the formal parameter declaration.

The TRUNCATE attribute is useful when calling routines for which the optional parameter is truly optional, for example, when calling run-time library routines.

For More Information:

[ASYNCHRONOUS] FUNCTION MTH$DMIN1 (
   D_FLOATING   : DOUBLE;
   EXTRA_PARAMS : [LIST] DOUBLE) : DOUBLE; EXTERNAL;

Because the function MTH$DMIN1 returns the D_floating minimum of an arbitrary number of D_floating parameters, the formal parameter EXTRA_PARAMS is declared with the LIST attribute. All actual parameters must be double-precision real numbers passed by reference with value semantics.

For More Information:

On the LIST attribute ( VSI Pascal Reference Manual)

For routines that have parameters that are 64-bit pointers, the Pascal definition uses a 64-bit record type. The definition files do not support either the INTEGER64 datatype or 64-bit pointers.

You can override the formal definition inside of definition files by using a foreign mechanism specifier (that is, %IMMED, %REF, %STDESCR, and %DESCR) on an actual parameter.

[inherit('sys$library:pascal$lib_routines')]
program p64(input,output);

const
     arr_size = (8192 * 10) div 4; ! Make each array be 10 pages

type
     arr = array [1..arr_size] of integer;
     arrptr = [quad] ^arr;

var
     ptr : arrptr;
     ptrarr : array [1..10] of arrptr;
     i,j,stat : integer;
     sum : integer64;

!  PASCAL$LIB_ROUTINES.PAS on a V7.1 system contains
!  the following definitions for LIB$GET_VM_64
!
!type
!     $QUAD = [QUAD,UNSAFE] RECORD
!                L0:UNSIGNED; L1:INTEGER; END;
!     $UQUAD = [QUAD,UNSAFE] RECORD
!                L0,L1:UNSIGNED; END;
!     lib$routines$$typ4 = ^$QUAD;
!
![ASYNCHRONOUS] FUNCTION lib$get_vm_64 (
!        number_of_bytes : $QUAD;
!        VAR base_address : [VOLATILE] lib$routines$$typ4;
!        zone_id : $UQUAD := %IMMED 0) : INTEGER; EXTERNAL;
!
! Note that the BASE_ADDRESS parameter is a 64-bit pointer
! that will be returned by LIB$GET_VM_64.  The definition
! incorrectly declared it as a pointer to a record that is
! quadword sized.
!

begin

! Allocate memory with lib$get_vm_64.  The definition of
! lib$get_vm_64 declares the return address parameter as
! a quadword-sized record since it doesn't have sufficient
! information to generate a INTEGER64 or other type.
!
! Use an explicit '%ref' foreign mechanism specifier to
! override the formal parameter's type definition and pass
! our pointer to lib$get_vm_64.
!

writeln('arr_size = ',arr_size:1);
for i := 1 to 10 do
  begin
  stat := lib$get_vm_64( size(arr), %ref ptrarr[i] );
  if not odd(stat)
  then
     begin
     writeln('Error from lib$get_vm_64: ',hex(stat));
     lib$signal(stat);
     end;
  writeln('ptrarr[',i:1,'] = ',hex(ptrarr[i]));
  end;

! Read/write all the memory locations to get some page faults
!
writeln('Initialize all memory');
for i := 1 to 10 do
  for j := 1 to arr_size do
    ptrarr[i]^[j] := i + j;

sum := 0;
writeln('Add up all memory in reverse direction');
for i := 10 downto 1 do
  for j := arr_size downto 1 do
    sum := sum + ptrarr[i]^[j];
writeln('Sum of array contents = ',sum:1);

end.

 var long_ptr : ^integer;
      quad_ptr : [quad] ^integer;

Both pointers point to integers, but long_ptr is 32 bits while quad_ptr is 64 bits.

The VSI Pascal I/O model allows you to use most of the features of RMS indexed files. However, if you wish to use segmented or null keys, you must write a user-action function.

When an existing indexed file is opened, the run-time library compares the keys in the file against the KEY attributes specified in the program. If no KEY attribute was specified for the corresponding key in the indexed file, then the comparison is bypassed and the open continues. The run-time library compares the position and the data type of the file's keys against the KEY attributes specified. If the KEY attribute explicitly specifies a collating sequence (ASCENDING or DESCENDING), then the specified sequence must match that of the key in the file. If no sequence is specified, either sequence is allowed. The CHANGES and DUPLICATES options are not checked.

For More Information:

In the VSI Pascal I/O model, data items in a file are called components. In RMS, these items are called records.

Each variable-length component contains a count field as a prefix. This count field contains the number of bytes in the rest of the component. For files on tape, this count field is 4 bytes in length; for files on disk, this count field is 2 bytes in length.

The VSI Pascal I/O model does not provide a direct means to create files of variable-length components with fixed-length control fields (VFC). If you open a file of this component format, VSI Pascal treats the file like a file of variable-length components. If you want to create files of this component format, you must write a user-action function.

For More Information:

The VSI Pascal I/O model does not allow random access by record file address. If you want to use this type of access, you must write a user-action function.

RMS supports random access by Record File Address (RFA) for relative and indexed files, and for sequential files only on disk. The RFA is a unique number supplied for files on disk. The RFA remains constant as long as the record is in the file. RMS makes the RFA available to your program every time the record is stored or retrieved. Your program can either ignore the RFA or it can keep it as a random-access pointer to the record for subsequent accesses.

If your disk file is sequential with variable-length records, the RFA provides the only method for randomly accessing records of that file.

For More Information:

When you use the OPEN procedure, RMS applies default values for OpenVMS file specifications, and assigns values to FAB, RAB, XAB, and Name Block data structures.

VAR
    My_File : VARYING [20] OF CHAR;
    My_File_Var : TEXT;
BEGIN
My_File := 'foo.bar';
OPEN( FILE_NAME := My_File,
      FILE_VARIABLE := My_File_Var,
      DEFAULT := '[another.dir]' );

VSI Pascal determines a default line limit for TEXT files by translating the logical name PAS$LINELIMIT as a string of decimal digits. If this logical name has not been defined, there is no default line limit. You can override the default by calling the LINELIMIT procedure.

For More Information:

A condition signal consists of a call to either LIB$SIGNAL or LIB$STOP, the two entry points to the signaling facility. These entry points can be inherited from SYS$LIBRARY:PASCAL$LIB_ROUTINES.PEN.

If a condition occurs in a routine that is not prepared to handle it, a signal is issued to notify other active routines. If the current routine can continue after the signal is propagated, you can call LIB$SIGNAL. A higher-level routine can then determine whether program execution should continue. If the nature of the condition does not allow the current routine to continue, you can call LIB$STOP.

The handler first determines whether the condition can be corrected. If so, it takes the appropriate action and execution continues. If the handler cannot correct the condition, the condition may be resignalled; that is, the handler requests that another condition handler be sought to process the condition.

To use a condition handler, you must first declare the handler as a routine in the declaration section of your program; then, within the executable section, you must call the predeclared procedure ESTABLISH. The ESTABLISH procedure sets up an VSI Pascal language-specific condition handler that in turn allows your handler to be called. User-written condition handlers set up by ESTABLISH must have the ASYNCHRONOUS attribute and two integer array formal parameters. Such routines can access only local, read-only, and volatile variables, and local, predeclared, and asynchronous routines.

External routines (including system services) that are called by a condition handler require the ASYNCHRONOUS attribute in their declaration.

You should set up a user-written condition handler with the predeclared procedure ESTABLISH rather than with the run-time library routine LIB$ESTABLISH. ESTABLISH follows the VSI Pascal procedure-calling rules and is able to handle VSI Pascal condition handlers more efficiently than LIB$ESTABLISH. A condition handler set up by LIB$ESTABLISH might interfere with the default error handling of the VSI Pascal run-time system, and cause unpredictable results.

[EXTERNAL,ASYNCHRONOUS] FUNCTION Handler
   (VAR Sigargs  : Sigarr;
    VAR Mechargs : Mecharr) : INTEGER;
   EXTERN;
   .
   .
   .
ESTABLISH (Handler);

REVERT;

As a result of this call, the condition handler established in the current stack frame is removed. When control passes from a routine, any condition handler established during the routine's activation is automatically removed.

For example, a condition handler can be defined as follows:

TYPE
   Sigarr  = ARRAY[0..9] OF INTEGER;
   Mecharr = ARRAY[0..(SIZE(CHF2$TYPE)-4) DIV 4] OF INTEGER;

[EXTERNAL,ASYNCHRONOUS] FUNCTION Handler
   (VAR Sigargs : Sigarr;
    VAR Mechargs : Mecharr)   : INTEGER;
   EXTERN;
      .
      .
      .
ESTABLISH (Handler);
      .
      .
      .

In addition, a condition handler can request a stack unwind by calling the $UNWIND system service routine. You can inherit $UNWIND from SYS$LIBRARY:STARLET.PEN.

When $UNWIND is called, the function return value of the condition handler is ignored. The handler modifies the saved registers R0 and R1 in the mechanism parameters to specify the called function's return value.

The VSI OpenVMS system uses condition values to indicate that a called routine has either executed successfully or failed, and to report exception conditions. Condition values are usually symbolic names that represent 32-bit packed records, consisting of fields (usually interpreted as integers) that indicate which system component generated the value, the reason the value was generated, and the severity of the condition.

A warning severity code (0) indicates that although output was produced, the results may be unpredictable. An error severity code (2) indicates that output was produced even though an error was detected. Execution can continue, but the results may not be correct. A severe error code (4) indicates that the error was of such severity that no output was produced.

A condition handler can alter the severity code of a condition value to allow execution to continue or to force an exit, depending on the circumstances.

Occasionally a condition handler may require a particular condition to be identified by an exact match; that is, each bit of the condition value bits (0..31) must match the specified condition. For example, you may want to process a floating overflow condition only if the severity code is still 4 (that is, if no previous condition handler has changed the severity code) and the control bits have not been modified. A typical condition handler response is to change the severity code and resignal.

In most cases, however, you want some response to a condition, regardless of the value of the severity code or control bits. To ignore the severity and control fields of a condition value, declare and call the LIB$MATCH_COND function.

When an exception occurs, the system calls a handler in the Pascal Run-Time Library that is established by the generated code. This handler in the RTL in turn calls the user condition handler that was established with the ESTABLISH built-in routine.

The RTL handler contains a check to prevent a user handler from returning SS$_CONTINUE for a certain class of Pascal Run-Time Errors that could cause an infinite loop if execution was to continue at the point of the error.

There is a situation in which this check may cause unexpected behavior:

The user handler called $UNWIND and then returned with SS$_CONTINUE. Because the $UNWIND service was called, execution will not resume at the point of the error even if SS$_CONTINUE is returned to the system. However, the RTL handler is not aware that $UNWIND has been called, and will report that program operation cannot continue for this type of error. The solution is to return SS$_RESIGNAL instead of SS$_CONTINUE after calling $UNWIND in the user handler.

However, this solution is not possible if you establish the LIB$SIG_TO_RET routine with the ESTABLISH built-in routine. LIB$SIG_TO_RET is a routine that can be used as a condition handler to convert a signal into a return to the caller of the routine that established LIB$SIG_TO_RET. Because LIB$SIG_TO_RET returns SS$_NORMAL, which in turn is the same value as SS$_CONTINUE, the handler in the Pascal RTL will report that program operation cannot continue for this type of error. The solution for this case is to establish your own handler with the ESTABLISH built-in routine that calls LIB$SIG_TO_RET and then returns SS$_RESIGNAL. You cannot establish LIB$SIG_TO_RET directly as a handler with the ESTABLISH built-in routine.

For More Information:

For aggregates such as arrays and records, the data type to be considered for purposes of alignment is not the aggregate itself, but rather the elements of which the aggregate is composed. Varying 8-bit character strings must, for example, start at addresses that are a multiple of 2 bytes (word alignment) because of the 16-bit count at the beginning of the string. For records, the size is rounded up to a multiple of their natural alignment (a record with natural alignment of longword has a size that is a multiple of longwords, for example).

The OpenVMS VAX and naturally aligned record formats are fully documented in the VSI OpenVMS Calling Standard.

For compatibility reasons, the size of all data types in PACKED records and arrays are the same for both VAX and natural alignment formats.

The /ALIGN qualifier option controls the default record format used by the compiler. The /ENUMERATION_SIZE qualifier option controls whether the compiler allocates Boolean and enumeration types as longwords or as 1 or 2 bytes.

The default alignment format is NATURAL and the default enumeration size is LONG. The other settings exist to aid in porting legacy code from OpenVMS VAX systems.

By using these attributes at the MODULE level, you can extract the records into a separate module and create an environment file with the desired alignment format. By using these attributes on VAR or TYPE sections, you can isolate the records in the same source file.

The optimal record layout is one where all the record's fields are naturally sized on naturally aligned boundaries and the overall record is as small as possible (for example, the fewest number of padding bytes required for proper alignment).

The compiler automatically places all fields of unpacked records on naturally aligned boundaries.

You may still need to use PACKED if you rely on the record for compatability with binary data files or when assuming that types like PACKED ARRAY OF BOOLEAN are implemented as bit strings.

type t1 = record
          f1 : char;
          f2 : integer;
          f3 : char;
          f4 : integer;
          end;