The TYPENAME keyword is used to specify a data type name that is not a VSI SDL data type. Depending on which back end is specified, this name may or may not override the VSI SDL data type. The Ada and PL/I back ends use these data type names as parameter data types, as return value data types, and as CONSTANT declaration data types. The TYPENAME keyword has the following syntax:

TYPENAME name 

The Ada language translation (as a result of processing the VSI SDL source file EXAMPLE.SDL in SDL$EXAMPLES) shows an example of the TYPENAME keyword. The following is an example of the TYPENAME keyword on each of the parameters in an ENTRY declaration:

ENTRY SYS$FAO
      ALIAS $FAO
      PARAMETER (CHARACTER DESCRIPTOR NAMED CTRSTR IN TYPENAME CHARDESC,
             WORD UNSIGNED NAMED OUTLEN OUT DEFAULT 0 TYPENAME NUMBER,
             CHARACTER DESCRIPTOR NAMED OUTBUF OUT TYPENAME CHARDESC,
             LONGWORD VALUE NAMED P1 OPTIONAL LIST TYPENAME VARIES)
      RETURNS LONGWORD TYPENAME CONDVALU;

User-defined prefixes, markers, and tags are optional character strings that help to uniquely identify the names associated with a particular facility or system. When the /SUPPRESS qualifier is specified on the command line, the inclusion of prefixes and/or tags on output symbol names is suppressed. See Section 2.1, ''Processing a VSI SDL Source File'' for a description of the /SUPPRESS qualifier.

PREFIX Keyword

The PREFIX option may be specified on an AGGREGATE, subaggregate, CONSTANT, or ITEM declaration to cause VSI SDL to concatenate a user-specified prefix and the name specified in the declaration.

When you specify a prefix for an aggregate, VSI SDL concatenates the prefix and the name of each member or named constant declared within the aggregate. The name of the aggregate itself is not altered by the use of the PREFIX option. The PREFIX option has the following syntax:

PREFIX prefix-string 

prefix-string

Is a 0- to 32-character string that can be any valid VSI SDL identifier.

If you specify the PREFIX option, VSI SDL constructs the identifier of each member by concatenating the prefix, a tag, an underscore, and the member name.

You can override a prefix that is currently in effect by specifying a new prefix for a particular aggregate member. If this member happens to be a subaggregate, the new prefix is applied to all the members of that subaggregate. Otherwise, if no prefix is specified for the subaggregate, all subaggregate members are assigned the same prefix as that specified on the level-1 aggregate.

MARKER Keyword

You can use the MARKER keyword to assign a user-defined prefix to the aggregate name. The MARKER option has the following syntax:

MARKER marker-string 

marker-string

Is a 0- to 32-character string that can be any valid VSI SDL name that may or may not be enclosed in quotation marks (" ") and may be null.

TAG Keyword

The TAG option overrides the default tags that VSI SDL uses in forming identifiers. You can specify tags for CONSTANT, ITEM, and AGGREGATE declarations and aggregate members. The tag that you specify, however, affects only the outer-level identifier. For example, a tag you supply in an AGGREGATE declaration affects only the aggregate name; if you wish to change all the tags in an aggregate, you must do it on a member-by-member basis. The TAG option has the following syntax:

TAG tag-string 

tag-string

Is a 0- to 32-character string specifying the tag to use in forming the name. If the TAG option is not specified, VSI SDL uses a default code based on the data type of the name.

If you specify the TAG option, VSI SDL appends the tag-string, which may be null (" "), and an underscore character (_) to the current prefix-string. A tag consisting of a single underscore character produces a single underscore character in any resulting identifier.

The following is an example of the PREFIX, TAG, and MARKER keywords:

AGGREGATE operator STRUCTURE MARKER doowop$ PREFIX beebop$ TAG shoo;
 flink ADDRESS;
 blink WORD; 
 END; 

Table 3.3, ''SDL Command Qualifiers and Their Defaults'' shows the default tags that VSI SDL uses when the TAG option is not specified on an aggregate member.

The following example shows the use of a user-specified prefix on an AGGREGATE declaration:

AGGREGATE operator STRUCTURE 
     PREFIX opr$; 
     id WORD; 
     "typename" CHARACTER; 
     CONSTANT (fixed_bin_,float_) EQUALS 0 INCREMENT 1;
     bits STRUCTURE; 
     variable_size BITFIELD; size_units BITFIELD LENGTH 3; 
     END bits; 
END operator; 

In the previous example, the member name typename is enclosed in quotation marks because it is a VSI SDL keyword.

The previous declaration produces the following names, with the prefix opr$ and default tags, in the PL/I output file:

%replace opr$k_fixed_bin_ by 0; 
%replace opr$k_float_ by 1; 

%replace opr$s_operator by 4; 
dcl 1 operator based, 

    2 opr$w_id fixed binary(15),
    2 opr$t_typename character(1),
    2 opr$r_bits ,
       3 opr$v_variable_size bit(1),
       3 opr$v_size_units bit(3),
       3 opr$v_fill_0 bit(4); 

The name opr$v_fill_0 in the previous list is the result of a BITFIELD declaration that VSI SDL supplied because the subaggregate did not end on a byte boundary. The name (opr$v_ fill_0) ensures that the next aggregate begins on a byte boundary. Section 4.3.1.7, ''Forcing Data Alignment'' describes data alignment in detail. VSI SDL uses default codes followed by an underscore (_) for the tag portion of a prefix when the TAG option is not specified. You can override the default OpenVMS codes by specifying a tag, which may be null (" "). For example:

CONSTANT (abc,def,ghi) EQUALS 0 INCREMENT 1 
PREFIX new TAG ""; 

This declaration results in the names new_abc, new_def, and new_ghi.

Both the ALIGN and BASEALIGN keywords can ensure that items are properly aligned. The BASEALIGN keyword takes an argument, which specifies the alignment, whereas the ALIGN keyword uses the natural alignment of the item.

The size of the aggregate will be a multiple of 4 (2²), in this case 12, and neither i1 nor i2 will be aligned.

In the following example, the item will have a size of 8 (2³).

ITEM MyItem LONGWORD UNSIGNED BASEALIGN (3); 

Storage class refers to the way in which the target language compiler allocates storage for scalar items and aggregates. In general, declarations produce a template describing data for which the compiler allocates storage dynamically at run time, rather than at compile time. This type of storage is the default and is specified using the BASED option in some languages, although the default storage class option is language-dependent. The PL/I back end generates the BASED storage class option, which has the following syntax:

BASED (pointer-name) 

In languages that support the construct, you can use the BASED pointer-name option on an AGGREGATE declaration to bind a named pointer to that aggregate. In all target languages, the aggregate resulting from such a declaration has the default storage class (BASED).

A subaggregate always acquires the storage class of the aggregate to which it belongs.

The default storage class associated with any declaration is language-dependent. You can override the default storage class by specifying either of the following storage classes:

If COMMON and GLOBAL appear together in a declaration, a DUPCONATT (duplicate or conflicting attributes) error is given. The COMMON, GLOBAL and TYPEDEF storage classes are mutually exclusive.

Explicit SDL Storage classes are COMMON and GLOBAL. To maintain orthogonal syntax, TYPEDEF is permitted wherever COMMON and GLOBAL are permitted.

The Storage class definition in SDL is included as an option on an ITEM or AGGREGATE declaration. This means that an AGGREGATE TYPEDEF for the preceding example would be:

AGGREGATE MyStruct STRUCTURE TYPEDEF PREFIX jg$ ;
     i1 LONGWORD ;
     i2 LONGWORD ;
END ;

In most cases it is possible to refer to a user-defined Data Type where a standard built-in SDL Data Type (BYTE, LONGWORD etc.) can be referenced.

Reference to the type MyStruct defined in the preceding example is made as follows:

ITEM foo MyStruct ; 

You can apply a dimension to AGGREGATE (as well as members of aggregates and subaggregates) and ITEM declarations, which means that you can define an array of structures, a structure that contains one or more arrays, or an array of structures each of which contains one or more arrays. The DIMENSION option is valid when specified with any of the data types described in Section 3.2.3, ''Data Type Keywords'' and has the following syntax:

DIMENSION [lbound:]hbound 

The following is an example of the DIMENSION option specified on an AGGREGATE declaration:

AGGREGATE array_info STRUCTURE;
   bound STRUCTURE DIMENSION 8;
        lower LONGWORD;
        upper LONGWORD;
        multiplier LONGWORD;
        constant_lower BITFIELD LENGTH 1;
        constant_upper BITFIELD LENGTH 1;
        constant_multiplier BITFIELD LENGTH 1;
        reserved BITFIELD LENGTH 13;
   END bound;
END array_info;

The subaggregate bound has eight elements. Each element consists of the members upper, lower, multiplier, and so on. Because bound is an array, each of its members (upper, lower, multiplier, and so on) can also be considered an array of eight elements.

When you specify a single value after the DIMENSION keyword, as in the previous example, the specified back end assumes that the value represents the high bound value and supplies a default low bound value of one. You can override this default by specifying both a low bound and a high bound value as follows:

ITEM node_pointers DIMENSION 0:255 ADDRESS; 

This declaration results in a declaration of the array node_pointers, whose low bound is 0 and whose high bound is 255. Only one dimension can be specified for an AGGREGATE or ITEM declaration. This restriction ensures that there is no interlanguage conflict in an array declaration.

You can see how VSI SDL translates the DIMENSION option for each output language by processing the VSI SDL source file EXAMPLE.SDL in SYS$EXAMPLES.

The ANY keyword specifies that the parameter being described in an ENTRY declaration can be of any data type. The ANY data type can be used only within the context of a parameter description and has the following syntax:

ANY 

The BITFIELD keyword specifies a bit field variable that must be a member of an AGGREGATE declaration. The BITFIELD data type has the following syntax:

BITFIELD [LENGTH n] [MASK] [SIGNED] 

Bitfields must be AGGREGATE declaration members. They cannot be scalar items, objects of ADDRESS declarations, parameters, or return data types of entries.

The following is an example of the BITFIELD keyword used in an AGGREGATE declaration that specifies a structure with two bitfield members:

AGGREGATE flags STRUCTURE PREFIX tst$;
          resolved BITFIELD MASK SIGNED;
          spare_bits BITFIELD LENGTH 5;
          END;

The declaration of resolved in the previous example results in two declarations in the output file: a declaration for the bitfield itself and a declaration of a constant mask whose value is 1. Because the PREFIX option is specified for this aggregate, the source output file identifiers produced for this declaration are tst$v_resolved and tst$m_resolved, where the tag v_ indicates the bitfield variable and the tag m_ indicates the mask. Prefixes and tags are described in more detail in Section 3.2.2.2, ''PREFIX, MARKER, and TAG Keywords''.

The BOOLEAN keyword specifies a Boolean data type that is a one-byte field that can have one of two values, 0 or 1. The BOOLEAN data type has the following syntax:

BOOLEAN

The CHARACTER keyword declares a character string of a given length. The CHARACTER data type has the following syntax:

 CHARACTER [LENGTH {n}] [VARYING] 
           [       {*}] 

The following is an example of the CHARACTER data type used in an AGGREGATE declaration. The aggregate msg_buffer contains a character-string member named message_text with a length of 256 characters.

AGGREGATE msg_buffer STRUCTURE;
    message_text CHARACTER LENGTH 256 VARYING;
    severity WORD;
    END;

The COMPLEX keyword immediately follows any of the four floating-point data type keywords to specify any of the four COMPLEX data types. The COMPLEX data types have the following syntax:

F_FLOATING COMPLEX 
D_FLOATING COMPLEX 
G_FLOATING COMPLEX 
H_FLOATING COMPLEX 

The following is an example of the F_FLOATING COMPLEX data type used in an ITEM declaration:

ITEM foo F_FLOATING COMPLEX; 

Section 3.2.3.8, ''Floating-Point Data Types'' describes floating-point data types.

The DECIMAL keyword specifies a packed decimal data type and the size of the data type. The DECIMAL data type has the following syntax:

DECIMAL PRECISION (precision,scale) 

The following is an example of the DECIMAL keyword used in an ITEM declaration that indicates a packed decimal data type consisting of three decimal digits, two of which are fractional:

ITEM percentage DECIMAL PRECISION (3,2); 

The floating-point keywords, F_FLOATING, D_FLOATING, G_FLOATING, and H_FLOATING, declare storage units for single-, double-, G-, and H-floating-point data, respectively. The floating-point data types have the following syntax:

F_FLOATING 
D_FLOATING 
G_FLOATING 
H_FLOATING 

The following is an example of the D_FLOATING data type used in an ITEM declaration:

ITEM foo D_FLOATING; 

Section 3.2.3.6, ''COMPLEX Data Types'' describes COMPLEX data types.

The keywords BYTE, WORD, LONGWORD, QUADWORD, and OCTAWORD declare storage units of 8, 16, 32, 64, and 128 bits, respectively, to represent signed integer data.

You may also specify the keyword UNSIGNED with any of these data types to indicate unsigned integer data.

It is also possible to specify the keyword SIGNED.

The keywords INTEGER_BYTE, INTEGER_WORD, INTEGER_LONG and INTEGER_QUAD are synonyms for BYTE, WORD, LONGWORD, QUADWORD, respectively, although some back ends treat INTEGER_QUAD and QUADWORD different (C, Fortran and PL/I). The keyword INTEGER is also synonym for LONGWORD and INTEGER_LONG.

The keywords INTEGER_HW and HARDWARE_INTEGER describe integer data types whose size depends on the underlying hardware. If the qualifier /VAX is specified, they are 4 bytes wide, and if /ALPHA_AXP is specified, they are 8 bytes wide.

The integer data types have the following syntax:

BYTE              [ UNSIGNED | SIGNED ]
INTEGER_BYTE      [ UNSIGNED | SIGNED ]
WORD              [ UNSIGNED | SIGNED ]
INTEGER_WORD      [ UNSIGNED | SIGNED ]
LONGWORD          [ UNSIGNED | SIGNED ]
INTEGER_LONG      [ UNSIGNED | SIGNED ]
INTEGER           [ UNSIGNED | SIGNED ]
QUADWORD          [ UNSIGNED | SIGNED ]
INTEGER_QUAD      [ UNSIGNED | SIGNED ]
OCTAWORD          [ UNSIGNED | SIGNED ]
INTEGER_HW        [ UNSIGNED | SIGNED ]
HARDWARE_INTEGER  [ UNSIGNED | SIGNED ]

The following are examples of the LONGWORD and BYTE data types used in an ITEM declaration:

ITEM foo LONGWORD UNSIGNED; 
ITEM bar BYTE; 

Subaggregates are declared using the keyword STRUCTURE or UNION. Within an aggregate, subaggregates can be nested up to eight levels deep. For example:

AGGREGATE tree_node STRUCTURE;
  opcode WORD;
  lang_bits UNION;
   pli_bits STRUCTURE;
      resolved BITFIELD;
      psv BITFIELD;
      mark1 BITFIELD;
      spare_bits BITFIELD LENGTH 5;
      END pli_bits;
   c_bits STRUCTURE;
      value_variable_size BITFIELD;
      psv BITFIELD;
      expanded BITFIELD;
      resolved BITFIELD;
      reduced BITFIELD;
      spare_bits BITFIELD LENGTH 3;
      END c_bits;
   END lang_bits;
END tree_node;

In this example, the structures pli_bits and c_bits are both subaggregates of the union lang_ bits. Because lang_bits is a union, c_bits and pli_bits occupy the same storage.

The COMMON, GLOBAL, BASED pointer-name, and ORIGIN options are invalid for a subaggregate. All other AGGREGATE options are valid.

STRUCTURE declarations produce aggregate or subaggregate declarations that are structures. The members are not overlaid; each member has a unique offset from the beginning of the structure, which means that members occupy consecutive storage locations.

The following shows the syntax of a first-level STRUCTURE declaration:

AGGREGATE aggregate-name STRUCTURE [ options ]; 

The following shows the syntax of a STRUCTURE declaration as an aggregate member, that is, a subaggregate STRUCTURE declaration:

member-name STRUCTURE [ options ]; 

UNION declarations produce aggregate or subaggregate declarations that are unions. The first-level members are overlaid, which means that they occupy the same storage location. Each first-level member begins at the beginning of the union and, thus, has an offset of zero. A UNION declaration lets you represent the same storage location using different names and different data types.

The following shows the syntax of a first-level UNION declaration:

AGGREGATE aggregate-name UNION [ options ]; 

The following shows the syntax of a UNION declaration as an aggregate member, that is, a subaggregate UNION declaration:

member-name UNION [ options ] 

You may specify data types on an AGGREGATE declaration to cause the AGGREGATE declaration to become an implicit union declaration. An implicit union declaration has these features:

The following VSI SDL source code shows the syntax of an implicit union (structure B defines the implicit union declaration):

AGGREGATE A STRUCTURE;
   B STRUCTURE LONGWORD;
      bit_string1 BITFIELD LENGTH 1;
      bit_string2 BITFIELD LENGTH 4;
   END B;
   last_item WORD;
END A;

This implicit union declaration would be more cumbersome if represented as shown in the following STRUCTURE subaggregate:

AGGREGATE A STRUCTURE;
   X UNION ;
     B LONGWORD;
     Y STRUCTURE ;
        bit_string1 BITFIELD LENGTH 1;
        bit_string2 BITFIELD LENGTH 4;
     END Y;
   END X;
   last_item WORD;
END A;

In the previous example, the names X and Y become VSI SDL generated filler names in the implicit union case.

You do not have to define the union X and the structure Y if an implicit union declaration is used. By giving the structure Y a type, VSI SDL creates a union of field Y with the specified type overlaid with a structure containing the fields in Y. In some language translations, such as VSI BLISS and VSI MACRO, the VSI SDL-generated union and structure (X and Y above) can be suppressed in the output because they are considered extraneous fields. In other languages, such as PL/I and VSI C, it is necessary to use the VSI SDL-generated union and structure to generate the correct offsets within a structure. Because the union is of the length specified in the structure type, no filler is necessary to ensure that subsequent fields (for example, last_item) are at the correct offset. If the fields of a structure extend past the size specified, VSI SDL flags the overflow. The PL/I translation for the previous implicit union declaration example is as follows:

DCL 1 A BASED ,
     2 fill_0 union,
      3 B fixed binary(31),
      3 fill_1 ,
       4 bit_string1 bit(1),
       4 bit_string2 bit(4),
       4 fill_1$$v_fill_2 bit(3),
     2 last_item fixed binary(15);

The VSI SDL source file EXAMPLE.SDL in SDL$EXAMPLES shows an example of an implicit union declaration.

The following is an example of a VSI SDL structure defined with a data type and the DIMENSION keyword:

AGGREGATE fid STRUCTURE WORD DIMENSION 3;
     first WORD;
     second WORD;
     third WORD;
END fid;

In the previous example, a single structure is overlaid by an array of elements of the type specified by the structure type.

The fid structure is a three-word field that can be addressed as a single field or by each individual word so that it is easily defined in VSI SDL as represented above. The following is the PL/I translation for the VSI SDL source code in the previous example:

DCL 1 fill_0 union BASED ,
     2 fid (1:3) fixed binary(15),
     2 fill_1 ,
      3 first fixed binary(15),
      3 second fixed binary(15);
      3 third fixed binary(15);

The implicit union declaration allows structures to grow without the need to modify any trailing fillers. VSI SDL detects any overflow that may occur if the structure grows past the size of its data type. The size of the aggregate (in bytes) is equal to the size of the data type (in bytes) multiplied by the upper dimension (if any). If the size of the aggregate is greater than the sum of the size of all its members, VSI SDL still translates the declaration. However, if the size of the members exceeds the size of the aggregate, VSI SDL issues a message that has the following format:

%SDL-E-TOOMANYFIELDS, Structure fill_0 has too many fields [Line ?] 

In the previous example, fill_0 is the VSI SDL-generated name for the first union aggregate.

The default origin of an aggregate is the beginning of the first aggregate member. You may specify the ORIGIN option on a level-1 AGGREGATE declaration to indicate that the origin is located at the beginning of any aggregate member. The resulting declaration forces all aggregate members declared before the specified origin to be located at negative offsets from the origin. For example:

AGGREGATE nodes STRUCTURE ORIGIN qflink;
   flink ADDRESS;
   blink ADDRESS;
   qflink ADDRESS;
   qblink ADDRESS;
END;

This declaration defines the origin of the structure nodes to be at the member qflink, so you may address flink and blink as negative offsets from qflink. Specifying an origin does not change the values of the current bit and byte offset symbols (^ and :). These are always calculated as being relative to the beginning of the aggregate.

VSI SDL forces all AGGREGATE and subaggregate declarations to begin on byte boundaries. Thus, if an aggregate or subaggregate ends with BITFIELD declarations that do not end on byte boundaries, VSI SDL ensures that the next aggregate begins on a byte boundary by supplying BITFIELD declarations as fillers, if necessary.

When VSI SDL adds BITFIELD declarations, it determines the length required and provides a unique name of the form string$V_FILL_n. The string is the prefix supplied in the AGGREGATE declaration, or the aggregate name if no prefix was supplied. Within an aggregate, n begins at 0 and is incremented for each filler required.

The subaggregate declarations shown in the following example declare filler bitfields to force byte alignment at the end of each subaggregate; this programming practice makes it unnecessary for VSI SDL to perform the alignment.

AGGREGATE tree_node STRUCTURE;
  opcode WORD;
  lang_bits UNION;
   pli_bits STRUCTURE;
      resolved BITFIELD;
      psv BITFIELD;
      mark1 BITFIELD;
      spare_bits BITFIELD LENGTH 5;
      END pli_bits;
   c_bits STRUCTURE;
     value_variable_size BITFIELD;
     psv BITFIELD;
     expanded BITFIELD;
     resolved BITFIELD;
     reduced BITFIELD;
     spare_bits BITFIELD LENGTH 3;
     END c_bits;
   END lang_bits;
END tree_node;

The current bit offset is set at 0 at the beginning of each aggregate and is incremented by the bit lengths of each structure member in the aggregate at that level. In the following example, VSI SDL forces the structure flags to be aligned on a byte boundary.

AGGREGATE dcb STRUCTURE PREFIX dcb$;
  .
  .
  .
uflags STRUCTURE;
   context BITFIELD LENGTH 3;
   local BITFIELD;
   END uflags;
flags STRUCTURE;
   extern BITFIELD;
   relo BITFIELD;
   END flags;

The PL/I translation of the VSI SDL AGGREGATE declaration in the previous example is as follows:

%replace dcb$s_dcb by 2;
dcl 1 dcb based,
     2 dcb$r_uflags ,
      3 dcb$v_context bit(3),
      3 dcb$v_local bit(1),
      3 dcb$v_fill_0 bit(4),
     2 dcb$r_flags ,
      3 dcb$v_extern bit(1),
      3 dcb$v_relo bit(1),
      3 dcb$v_fill_1 bit(6);

The bit offsets of the members of the structures in the previous VSI SDL example are shown in the following table.

The period (.) represents the current byte offset from the origin in an AGGREGATE declaration. If the ORIGIN option is specified, the value of the period is equal to the byte offset from the member specified using the ORIGIN option. The current byte offset is useful for capturing the size of an aggregate or a portion of it. For example, in the declaration of a variable-length data structure, you can capture the size of the fixed-length portion.

The colon (:) represents the current byte offset relative to the first member in an AGGREGATE declaration. The value is not affected by the presence of an ORIGIN option.

The circumflex (^) represents the current bit offset relative to the most recently declared aggregate or byte-aligned element.

The following example shows the use of the byte offset symbols.

AGGREGATE operator STRUCTURE PREFIX opr_;
   flink ADDRESS;
   blink ADDRESS;
   opcount WORD;
   optype CHARACTER LENGTH 1;
   id WORD;
   flags STRUCTURE;
      is_constant_size BITFIELD LENGTH 1;
      is_terminator BITFIELD LENGTH 1;
      context BITFIELD LENGTH 3;
      filler BITFIELD LENGTH 8-^;
      END;
   #opsize = .;
   operands LONGWORD DIMENSION(#max_args);
   #instruction_size = :;
   END;
CONSTANT node_size EQUALS #opsize / 2;
CONSTANT inst_size EQUALS #instruction_size;

In the previous example, the local symbol #opsize captures the byte offset following the fixed-length portion of the structure operator. This value is subsequently used in the CONSTANT declaration, which defines the size of the constant portion of the structure in words.

The flags structure is byte aligned by the field filler, which makes use of the current bit offset symbol to compute the size of this field.

The CONSTANT inst_size defines the size of the entire structure.

VSI SDL does not directly generate definitions for global symbols (constants), but instead generates local constant definitions. The VSI MACRO back end, however, generates all declarations within macros so that they can be invoked with arguments that will produce global definitions.

VSI SDL also produces VSI MACRO output declarations that can generate global definitions when an invocation of the macro is assembled. In the following example, the VSI SDL module $IODEF contains the following constant declarations:

CONSTANT (
   nop,
   unload,
   loadmcode,
   seek,
   spacefile,
   startmproc,
   recal,
   stop,
   drvclr,
   initialize) EQUALS 0 INCREMENT 1 PREFIX "io$";

The VSI MACRO output generated by this declaration is a macro definition that must be invoked as follows in order to result in global rather than local constant definitions:

$IODEF <= => 

This argument results in global constant definitions rather than local constant definitions. To request that the locations of data fields be defined globally, add the argument <::> following <= =>.

An ENTRY declaration has the following syntax:

 ENTRY entry-name [ ALIAS internal-name ] 
 [ PARAMETER (param-desc,...) ] 
 [ LINKAGE link-name ]; 
 [ VARIABLE ] 
 [ RETURNS return-data-type [ NAMED param-name ] ] 
 [ TYPENAME type-name ];