TPU is a high-performance, programmable utility. It provides two editing interfaces: the Extensible VAX Editor (EVE), described in the following section, and the TPU EDT Keypad Emulator. You can also create your own interfaces.

Like EDT, TPU provides you with an online help facility that you can access during your editing session. When you invoke TPU to create a file, a journal file is automatically created. You can use this journal file to recover your edits if the system fails during an editing session. To recover your edits, enter the EVE/RECOVER command.

Unlike EDT, TPU provides multiple windows. This feature allows you to view two files on your screen at the same time.

$ EDIT/TPU PROG_1.C

$ EVE == "EDIT/TPU"

After this command line is executed, you can type EVE at the DCL prompt followed by the name of the file you want to modify or create.

The /STANDARD qualifier causes the compiler to issue only those warnings appropriate for the dialect of C being compiled. For example, VAX C compatibility mode (/STANDARD=VAXC) does not issue warnings against VAX C extensions, while ANSI C mode does.

To generate a list of all messages that are in effect at the start of compilation, specify /LIST/SHOW=MESSAGES. For each message, the identifier, severity, and message text are shown. To also show the message description and user action for each message listed, specify /LIST/SHOW=MESSAGES/WARN=VERBOSE.

With one exception, the /STANDARD qualifier options are mutually exclusive. Do not combine them. The exception is that you can specify /STANDARD=ISOC94 with any other option except VAXC.

VSI C modules compiled in different modes can be linked and executed together.

The /STANDARD qualifier is further described in Section 1.3.4.

Also see the __HIDE_FORBIDDEN_NAMES predefined macro (Section 6.1.7).

The /STANDARD=MS qualifier instructs the VSI C compiler to interpret your source code according to certain language rules followed by the C compiler provided with the Microsoft Visual C++ compiler product. However, compatibility with this implementation is not complete. The following sections describe the compatibility situations that VSI C recognizes. In most cases, these situations consist of relaxing a standard behavior and suppressing a diagnostic message.

struct{
  struct{
      int a;
      int b;
  };  /*No name here */
  int c;
}d;  /* d.a, d.b, and d.c are valid member names. */

f(){
   static int a(int b);
}

int *a, *b;

f() {

  &*a=b;

}

signed char *a;
char *b;

f() {
b=a;
}

int a;;

b;

enum E {a, b, c,};    /*  Ignore the comma after "c". */

typedef struct { int a; };

#pragma code_seg
#pragma warning

The following list shows all the command qualifiers and their defaults available with the CC command. A description of each qualifier follows the list.

You can place command qualifiers either on the CC command line itself or on individual file specifications (with the exception of the /LIBRARY qualifier). If placed on a file specification, the qualifier affects only the compilation of the specified source file and all subsequent source files in the compilation unit. If placed on the CC command line, the qualifier affects all source files in all compilation units unless it is overridden by a qualifier on an individual file specification.

Allows the compiler to accept C language syntax that it might not normally accept.

VSI C accepts slightly different syntax depending upon the compilation mode specified with the /STANDARD qualifier. The /ACCEPT qualifier can fine tune the language syntax accepted by each /STANDARD mode.

Generates a file of source-code analysis information. The default file name is the file name of the primary source file; the default file type is .ANA. The .ANA file is reserved for use with VSI layered products. The default is /NOANALYSIS_DATA. For more information, see Appendix C.

Controls whether or not the source listing file is annotated with indications of specific optimizations performed or, in some cases, not performed. These annotations can be helpful in understanding the optimization process.

If annotations are requested (and the /LISTING qualifier appears on the command line), the source listing section is shifted to the right and annotation numbers are added to the left of source lines. These numbers refer to brief descriptions that appear later in the source listing file.

The default is /NOANNOTATIONS.

Specifying /ANNOTATIONS with no keywords is the same as specifying /ANNOTATIONS=(ALL,NODETAIL).

Directs the compiler to assume the standard C aliasing rules. By so doing, the compiler has the freedom to generate better optimized code.

The aliasing rules referred to are explained in the C Standard, reprinted as follows:

If your program does not access the same data through pointers of a different type (and for this purpose, signed and qualified versions of an otherwise same type are considered to be the same type), then assuming standard C aliasing rules allows the compiler to generate better optimized code.

If your program does access the same data through pointers of a different type (for example, by a "pointer to int" and a "pointer to float"), then you must not allow the compiler to assume standard C aliasing rules. Otherwise, incorrect code might be generated.

The default is /NOANSI_ALIAS for the /STANDARD=VAXC and /STANDARD=COMMON compiler modes. The default is /ANSI_ALIAS for all other modes.

Determines the Alpha or Intel processor instruction set to be used by the compiler. The /ARCHITECTURE qualifier uses the same keyword options (keywords) as the /OPTIMIZE=TUNE qualifier.

Where the /OPTIMIZE=TUNE qualifier is primarily used by certain higher-level optimizations for instruction scheduling purposes, the /ARCHITECTURE qualifier determines the type of code instructions generated for the program unit being compiled.

OpenVMS Version 7.1 and subsequent releases provide an operating system kernel that includes an instruction emulator. This emulator allows new instructions, not implemented on the host processor chip, to execute and produce correct results. Applications using emulated instructions will run correctly, but may incur significant software emulation overhead at runtime.

All Alpha processors implement a core set of instructions. Certain Alpha processor versions include additional instruction extensions.

The following sections describe these options in greater detail.

The default is ACCURACY_SENSITIVE.

If you specify NOACCURACY_SENSITIVE, the compiler is free to reorder floating-point operations based on algebraic identities (inverses, associativity, and distribution). This allows the compiler to move divide operations outside of loops, which improves performance.

The default, ACCURACY_SENSITIVE, directs the compiler to use only certain scalar rules for calculations. This setting can prevent some optimizations.

If you use the /ASSUME=NOACCURACY_SENSITIVE qualifier, VSI C might reorder code (based on algebraic identities) to improve performance. The results can be different from the default (/ASSUME=ACCURACY_SENSITIVE) because of how the intermediate results are rounded. However, the NOACCURACY_SENSITIVE results are not categorically less accurate than those gained by the default.

The default is /ASSUME=ALIGNED_OBJECTS.

On OpenVMS Alpha and I64 systems, dereferencing a pointer to a longword- or quadword-aligned object is more efficient than dereferencing a pointer to a byte- or word-aligned object. Therefore, the compiler can generate more optimized code if it makes the assumption that a pointer object of an aligned pointer type does point to an aligned object.

Since the compiler determines the alignment of the dereferenced object from the type of the pointer, and the program is allowed to compute a pointer that references an unaligned object (even though the pointer type indicates that it references an aligned object), the compiler must assume that the dereferenced object's alignment matches or exceeds the alignment indicated by the pointer type. Specifying /ASSUME=ALIGNED_OBJECTS (the default) allows the compiler to make such an assumption. With this assumption made, the compiler can generate more efficient code for pointer dereferences of aligned pointer types.

To prevent the compiler from assuming the pointer type's alignment for objects that it points to, use the /ASSUME=NOALIGNED_OBJECTS qualifier.

Before deciding whether to specify /ASSUME=NOALIGNED_OBJECTS or /ASSUME=ALIGNED_OBJECTS, you need to know what programming practices will affect your decision.

If your module breaks this rule, your program will suffer alignment faults at runtime that can seriously degrade performance. If you can identify the places in your code where the rule is broken, use the __unaligned type qualifier. Otherwise, the /ASSUME=NOALIGNED_OBJECTS qualifier effectively treats all dereferences as if they were unaligned.

On OpenVMS Alpha and I64 systems, VSI C aligns all nonmember declarations on natural boundaries, so by default all objects do comply with the previous assumption. Also, the standard library routine malloc on OpenVMS systems returns quadword-aligned heap memory.

#pragma nomember_alignment
struct foo {
    char C;
    int i; /* i is unaligned because of char C */
};

struct foo st;
int        *i_p;

i_p = &st.i;

... *i_p ...    /* An expression containing a dereferenced i_p */

int        *i_p;
char       *c_p;

.......
.......

i_p = (int *)c_p;

... *i_p ...    /* An expression containing a dereferenced i_p */

#pragma member_alignment
struct inside {
    int i;  /* this type asserts that its objects have at least
               longword alignment (int is a longword)... */
};

#pragma nomember_alignment
struct outside {
    char C;
    struct inside s; /* ...but foo_ptr -> s is only byte-aligned! */
} *foo_ptr;

The expression foo_ptr -> s has a type whose alignment is explicitly specified to be longword (because longword is the strictest alignment of the structure's members), but the expression type is only guaranteed to be byte-aligned.

Also note that just as the pointer type information can direct the compiler to generate the appropriate code to dereference the pointer (code that does not cause alignment faults), it can also direct the compiler to generate even better code if it indicates that the object is at least longword-aligned.

The default is /ASSUME=CLEAN_PARAMETERS.

The OpenVMS Alpha and I64 Calling Standards require integers less than 64 bits long that are passed by value to have their upper bits either zeroed or sign-extended to make full 64-bit values. These are referred to as clean parameters. Some old code does not follow this convention. This can cause problems if the called program assumes that the caller followed the Calling Standard by passing only clean parameters.

Specifying /ASSUME=NOCLEAN_PARAMETERS allows a program to be called by old code that might pass unclean integer parameters. It directs the compiler to generate run-time code to clean the short integers so they comply with the Calling Standard.

The default is /ASSUME=NOEXACT_CDD_OFFSETS.

If /ASSUME=EXACT_CDD_OFFSETS is specified, the records input from the CDD are given the exact alignment (relative to the start of the record) specified by the CDD definition. This alignment is independent of the current compiler member-alignment setting.

If /ASSUME=NOEXACT_CDD_OFFSETS is specified, the compiler may modify the offsets specified in a CDD record according to the current member-alignment setting.

The default is /ASSUME=HEADER_TYPE_DEFAULT.

In past versions of the C compiler, the #include directive always supplied a default file type of .h for C compilations. Similarly, the C++ compiler supplied a default file type of .hxx for C++ compilations.

However, the C++ standard requires that, for example, #include <iostream> be distinguishable from #include <iostream.hxx>. This is not possible with the header file-type default mechanism in effect.

You can disable the type default mechanism for either VSI C or VSI C++ by specifying /ASSUME=NOHEADER_TYPE_DEFAULT.

With /ASSUME=NOHEADER_TYPE_DEFAULT specified, an #include directive written with the standard syntax for header name (enclosed in quotes or angle brackets) will use the filename as specified, without supplying a default file type. More precisely stated, the default file type will be empty (just ".").

For example, a directory might contain three files named IOSTREAM., IOSTREAM.HXX, and IOSTREAM.H. By default, the C++ compiler processes #include <iostream> such that the file IOSTREAM.HXX is found, while the C compiler would find IOSTREAM.H.

However, if /ASSUME=NOHEADER_TYPE_DEFAULT is specified, the same directive causes the file IOSTREAM. to be found by both compilers, and the only way to include the file named IOSTREAM.HXX or IOSTREAM.H is to specify the .hxx or .h file type explicitly in the #include directive. Be aware that while the OpenVMS operating system treats filenames as case-insensitive and normally displays them in uppercase, filenames in #include directives should use lowercase for best portability. This is more in keeping with other C and C++ implementations.

The default is /ASSUME=MATH_ERRNO, which does not allow intrinsic code for such math functions to be generated, even if /OPTIMIZE=INTRINSICS is in effect. Their prototypes and call formats, however, are still checked.

The default is /ASSUME=POINTER_TO_GLOBALS, which directs the compiler to assume that global variables have had their addresses taken in separately compiled modules and that, in general, any pointer dereference could be accessing the same memory as any global variable. This is often a significant barrier to optimization.

The /ANSI_ALIAS command-line qualifier allows some resolution based on data type, but /ASSUME=NOPOINTER_TO_GLOBALS provides significant additional resolution and improved optimization in many cases.

/ASSUME=NOPOINTER_TO_GLOBALS tells the compiler that any global variable accessed through a pointer in the compilation must have had its address taken within that compilation. The compiler can see any code that takes the address of an extern variable. If it does not see the address of the variable being taken, the compiler can assume that no pointer points to the variable.

extern int x;
...
int *p;
...
*p = 3;

Under /ASSUME=NOPOINTERS_TO_GLOBALS, the compiler can assume that x is not changed by the assignment through p when generating code. This can lead to faster code.

In combination with the /PLUS_LIST_OPTIMIZE qualifier, several source modules can be treated as a single compilation for the purpose of this analysis. Because run-time libraries such as the VSI C RTL do not take the addresses of global variables defined in user programs, source modules can often be combined into a single compilation that allows /ASSUME=NOPOINTER_TO_GLOBALS to be used effectively.

Be aware that /ASSUME=NOPOINTERS_TO_GLOBALS does not tell the compiler that the compilation never uses pointers to access global variables (which is seldom true of real C programs).

This option affects the generation of code for assignments to objects that are less than or equal to 16 bits in size (for example: char, short) that have been declared as volatile.

Specifying /ASSUME=WEAK_VOLATILE directs the compiler to generate code for volatile assignments to single bytes or words without using the load-locked store-conditional sequences that, in general, are required to assure volatile data integrity when direct byte or word memory-access instructions are not being used.

This option is intended for use in special I/O hardware access situations, and should not generally be used.

The default is /ASSUME=NOWEAK_VOLATILE, which uses interlocked instructions for sub-longword volatile accesses when byte or word instructions are not enabled.

The default is /ASSUME=NOWHOLE_PROGRAM.

The optimizations enabled by /ASSUME=WHOLE_PROGRAM include all those enabled by /ASSUME=NOPOINTER_TO_GLOBALS, and possibly additional optimizations as well.

For /STANDARD=VAXC or /STANDARD=COMMON, the default is /ASSUME=WRITABLE_STRING_LITERALS.

For all other compiler modes, the default is /ASSUME=NOWRITABLE_STRING_LITERALS.

This qualifier is for use as a debugging aid.

/CHECK=UNINITIALIZED_VARIABLES initializes all automatic variables to the value 0xfffa5a5afffa5a5a. This value is a floating NaN and, if used, causes a floating-point trap. If used as a pointer, this value is likely to cause an ACCVIO.

/CHECK=POINTER_SIZE directs the compiler to generate code that checks 64-bit pointer values (used in certain contexts where 32-bit pointers are also present) to make sure they will fit in a 32-bit pointer. If such a value cannot be represented by a 32-bit pointer, the run-time code signals a range error (SS$_RANGEERR).

Specifying /CHECK=POINTER_SIZE defaults to /CHECK=POINTER_SIZE=(ASSIGNMENT,PARAMETER).

    #pragma required_pointer_size long
    int *a;
    char *b;
    typedef char * l_char_ptr;

    #pragma required_pointer_size short
    char *c;
    int *d;

    foo(int * e)              /* Check e if PARAMETER is specified. */
    {
        d = a;                /* Check a if ASSIGNMENT is specified. */
        c = (char *) a;       /* Check a if CAST is specified. */
        c = (char *) d;       /* No checking ever. */
        foo( a );             /* Check a if ASSIGNMENT is specified. */
        bar( a );             /* No checking ever - no prototype */
        b = (l_char_ptr) a;   /* No checking ever. */
        c = (l_char_ptr) a;   /* Check a if ASSIGNMENT is specified */
        b = (char *) a;       /* Check if CAST is specified. */
    }

/CHECK=FP_MODE generates code in the prologue of every function defined in the compilation to compare the current values of certain fields in the processor's floating-point status register (FPSR) with the values expected in those fields based on the command-line qualifiers with which the function was compiled.

Note that the checking code generated for /CHECK=FP_MODE includes a standard call to OTS$CHECK_FP_MODE within the prologue of each function, and OTS$CHECK_FP_MODE itself assumes the standard calling conventions (described in the OpenVMS Calling Standard). Because of this, it is not possible to use this checking option when compiling function definitions that have a nonstandard linkage (see #pragma linkage and #pragma use_linkage) specifying conventional scratch registers with the PRESERVED or NOTUSED attribute. Doing so will cause the compiler to issue the "REGCONFLICT" E-level diagnostic at the opening brace of such function definitions. To compile such functions successfully, the FP_MODE keyword must be removed from the list of /CHECK= keywords.

Defaults

Omitting this qualifier defaults to /NOCHECK, which equates to /CHECK=(NOUNINITIALIZED_VARIABLE,NOBOUNDS,NOPOINTER_SIZE,NOFP_MODE).

Specifying /CHECK defaults to /CHECK=(UNINITIALIZED_VARIABLES,BOUNDS, POINTER_SIZE=(ASSIGNMENT,PARAMETER),FP_MODE).

Governs whether or not comments appear in preprocess output files and, if they are to appear, whether they appear themselves or are replaced by a single space.

/NOCOMMENTS specifies that nothing replaces the comment in the output file. This can result in inadvertent token pasting.

The VSI C preprocessor might replace a comment at the end of a line or on a line by itself with nothing, even if /COMMENTS=SPACE is specified. Doing so does not change the meaning of the program.

The default is /COMMENTS=SPACE for the ANSI89, RELAXED, and MIA modes of the compiler. The default is /NOCOMMENTS for all other compiler modes.

Specifying /COMMENTS on the command line defaults to /COMMENTS=AS_IS.

Specifies whether the compiler generates cross-references for variable names.

If you specify /CROSS_REFERENCE, the compiler lists, for each variable referenced in the procedure, the line numbers of the lines on which the variable is referenced.

This qualifier has no effect unless you also specify /LIST and either /SHOW=SYMBOLS or /SHOW=BRIEF. The default is /NOCROSS_REFERENCE.

Includes information in the object module for use by the OpenVMS Debugger.

Specifying /DEBUG with no keywords is equivalent to specifying /DEBUG=ALL.

Invokes the VSI C compiler.

On OpenVMS VAX systems, the CC command is used to invoke either the VAX C or VSI C compiler. If your system has a VAX C compiler already installed on it, the VSI C installation procedure provides the option of specifying which compiler will be invoked by default when just the CC command is used. To invoke the compiler that is not the default, use the CC command with the appropriate qualifier: CC/DECC for the VSI C compiler, or CC/VAXC for the VAX C compiler. If your system does not have a VAX C compiler installed on it, the CC command will invoke the VSI C compiler.

On OpenVMS Alpha and I64 systems, specifying /DECC is equivalent to not specifying it; this qualifier is supported to provide compatibility with VSI C on OpenVMS VAX systems.

Performs the same functions as the #define and #undef preprocessor directives. The /DEFINE qualifier defines a macro to be substituted for every occurrence of a given identifier in the compilation unit or units. The /UNDEFINE qualifier cancels a previous definition (but not subsequent ones). When both /DEFINE and /UNDEFINE are present in a compilation unit or on the CC command line, /DEFINE is evaluated before /UNDEFINE.

Since /DEFINE and /UNDEFINE are not part of the source file, they are not associated with a listing line number or source line number. Therefore, when an error occurs in a command-line definition, the message displayed at the terminal does not indicate a line number. In the listing file, these diagnostic messages are placed before the source listing in the order that they were encountered. When the expansion of a definition causes an error at a specific source line in the program, the diagnostics—both at the terminal and in the listing file—are associated with that source line.

A command line containing the /DEFINE and the /UNDEFINE qualifiers can be long. Continuation characters cannot appear within quotes or they will be included in the macro stream. The length of a CC command line cannot exceed the maximum length allowed by DCL.

The /NODEFINE and /NOUNDEFINE qualifiers are provided for compatibility with other DCL qualifiers. You can use these qualifiers to cancel /DEFINE or /UNDEFINE qualifiers that you have specified in a symbol that you use to compile VSI C programs.

The defaults are /NODEFINE and /NOUNDEFINE.

Usage and Examples

$ CC/DEFINE=(EQU==,"equ =","equal==")

In the first definition, the first equal sign is removed by DCL as the delimiter; the second equal sign is passed to the compiler. In the second example, the space is recognized as a delimiter because the definition is inside quotes; therefore, only one equal sign is required. In the third definition, the first equal sign is recognized as the delimiter and is removed; the second equal sign is passed to the compiler.

$ CC/DEFINE=(QUOTES="""","funct(b)=printf(")")

In both examples, DCL removes the first and last quotation marks before passing the definition to the compiler.

$ CC/UNDEFINE=TRUE

main()
{
#if __DECC
printf("I'm being compiled with VSI C on an OpenVMS system.");
#else
printf("I'm being compiled on some other compiler.");
#endif
}

$ CC  EXAMPLE.C
$ LINK  EXAMPLE.OBJ
$ RUN  EXAMPLE.EXE
I'm being compiled with VSI C on an OpenVMS system.

$ CC/UNDEFINE="DECC" EXAMPLE

$ LINK  EXAMPLE.OBJ

$ RUN  EXAMPLE.EXE
I'm being compiled on some other compiler.

Creates a file containing compiler messages and diagnostic information. The default file extension for a diagnostics file is .DIA. The diagnostics file is used with the Language-Sensitive Editor (LSE). To display a diagnostics file, enter the command REVIEW/FILE=file-spec while in LSE. For more information, see Appendix C. The default is /NODIAGNOSTICS.

This qualifier takes the options BIG or LITTLE.

int foo = 'ABCD';

Specifying /ENDIAN=LITTLE places 'A' in the first byte, 'B' in the second byte, and so on.

Specifying /ENDIAN=BIG places 'D' in the first byte, 'C' in the second byte, and so on.

The default is /ENDIAN=LITTLE.

This qualifier limits the number of Error-level diagnostic messages that are acceptable during program compilation. Compilation terminates when the limit n is exceeded. /NOERROR_LIMIT specifies that there is no limit on error messages.

The default is /ERROR_LIMIT=30, which specifies that compilation terminates after 31 error messages.

In conjunction with the /[NO]SHARE_GLOBALS qualifier, controls the initial compiler model for external objects. Conceptually, the compiler behaves as if the first line of the program being compiled was a #pragma extern_model with the model and psect name, if any, specified by the /EXTERN_MODEL qualifier and with the shr or noshr keyword specified by the /[NO]SHARE_GLOBALS qualifier.

/EXTERN_MODEL=STRICT_REFDEF="MYDATA"/NOSHARE

#pragma extern_model strict_refdef "MYDATA" noshr

The default is /EXTERN_MODEL=RELAXED_REFDEF. This is different from VAX C, which uses the common block model for external objects.

Includes the specified files before any source files. This qualifier corresponds to the UNIX -FI switch.

This qualifier is useful if you have command lines to pass to the C compiler that are exceeding the DCL command-line length limit. Using the /FIRST_INCLUDE qualifier can help solve this problem by replacing lengthy /DEFINE and /WARNINGS qualifiers with #define and #pragma message preprocessor directives placed in a /FIRST_INCLUDE file.

#include "file"

If more than one file is specified, the files are included in their order of appearance on the command line.

The default is /NOFIRST_INCLUDE.

Controls the format of floating-point variables.

OpenVMS VAX Systems (VAX only)

On OpenVMS VAX systems, representation of double variables defaults toD_floating format if not overridden by another format specified with the /FLOAT or /[NO]G_FLOAT qualifier. There is one exception: if /STANDARD=MIA is specified, G_floating is the default. If you are linking against object-module libraries, a program compiled with G_floating format must be linked with the object library DECCRTLG.OLB. (VAX only)

OpenVMS Alpha Systems (Alpha only)

On OpenVMS Alpha systems, representation of double variables defaults to G_floating format if not overridden by another format specified with the /FLOAT or /[NO]G_FLOAT qualifier.

The VAXCRTLX.OLB, VAXCRTLDX.OLB, and VAXCRTLTX.OLB libraries are used for the same floating-point formats, respectively, but include support for X_FLOAT format (/L_DOUBLE_SIZE=128).

If /PREFIX=ALL is specified, then there is no need to link to the above-mentioned *.OLB object libraries. All the symbols you need are in STARLET.OLB.

I64 Systems (I64 only)

This section describes floating-point support and application porting considerations for I64 systems.

On OpenVMS I64 systems, /FLOAT=IEEE_FLOAT is the default floating-point representation. IEEE format data is assumed and IEEE floating-point instructions are used. There is no hardware support for floating-point representations other than IEEE, although you can specify the /FLOAT=D_FLOAT or /FLOAT=G_FLOAT compiler option. These VAX floating-point formats are supported in the I64 compiler by generating run-time code that converts VAX floating-point formats to IEEE format to perform arithmetic operations, and then converts the IEEE result back to the appropriate VAX floating-point format. This imposes additional run-time overhead and some loss of accuracy compared to performing the operations in hardware on Alpha and VAX systems. The software support for the VAX formats is provided to meet an important functional compatibility requirement for certain applications that need to deal with on-disk binary floating-point data.

On I64 systems, the default for /IEEE_MODE is DENORM_RESULTS, which is a change from the default of /IEEE_MODE=FAST on Alpha systems. This means that by default, floating-point operations may silently generate values that print as Infinity or Nan (the industry-standard behavior), instead of issuing a fatal run-time error as they would when using VAX floating-point format or /IEEE_MODE=FAST. Also, the smallest-magnitude nonzero value in this mode is much smaller because results are allowed to enter the denormal range instead of being flushed to zero as soon as the value is too small to represent with normalization.

The conversion of VAX floating-point formats to IEEE single and IEEE double floating-point types on the Intel Itanium architecture is a transparent process that will not impact most applications. All you need to do is recompile your application. Because IEEE floating-point format is the default, unless your build explicitly specifies VAX floating-point format options, a simple rebuild for I64 systems will use the native IEEE formats directly. For the large class of programs that do not directly depend on the VAX formats for correct operation, this is the most desirable way to build for I64 systems.

Where no arithmetic operations are performed (VAX float fetches followed by stores), no conversion will occur. The code handles such situations as moves.

VAX floating-point formats have the same number of bits and precision as their equivalent IEEE floating-point formats. For most applications the conversion process will be transparent and thus a non-issue.

You can test an application's behavior with IEEE floating-point values by compiling it on an OpenVMS Alpha system using /FLOAT=IEEE_FLOAT/IEEE_MODE=DENORM. If that produces acceptable results, then simply build the application on the OpenVMS I64 system using the same qualifier.

If you determine that simply recompiling with an /IEEE_MODE qualifier is not sufficient because your application depends on the binary representation of floating-point values, then first try building for your I64 system by specifying the VAX floating-point option that was in effect for your VAX or Alpha build. This causes the representation seen by your code and on disk to remain unchanged, with some additional run-time cost for the conversions generated by the compiler. If this is not an efficient approach for your application, you can convert VAX floating-point binary data in disk files to IEEE floating-point formats before moving the application to an I64 system.

Controls the size of shared data in memory that can be safely accessed from different threads. The possible size values are BYTE, LONGWORD, and QUADWORD.

Specifying BYTE allows single bytes to be accessed from different threads sharing data in memory without corrupting surrounding bytes. This option will slow run-time performance.

Specifying LONGWORD allows naturally aligned 4-byte longwords to be accessed safely from different threads sharing data in memory. Accessing data items of 3 bytes or less, or unaligned data, may result in data items written from multiple threads being inconsistently updated.

Specifying QUADWORD allows naturally aligned 8-byte quadwords to be accessed safely from different threads sharing data in memory. Accessing data items of 7 bytes or less, or unaligned data, might result in data items written from multiple threads being inconsistently updated. This is the default.

Selects the IEEE floating-point mode to be used if /FLOAT=IEEE_FLOAT is specified.

On Alpha systems, the default is /IEEE_MODE=FAST.

On I64 systems, the default is /IEEE_MODE=DENORM_RESULTS.

The INFINITY and NAN macros defined in <math.h> are available to programs compiled with /FLOAT=IEEE and /IEEE_MODE={anything other than FAST}, and in a compiler mode that enables C99 extensions in the headers (any mode other than COMMON or VAXC).

On Alpha systems, the /IEEE_MODE qualifier generally has its greatest effect on the generated code of a compilation. When calls are made between functions compiled with different /IEEE_MODE qualifiers, each function produces the /IEEE_MODE behavior with which it was compiled.

On I64 systems, the /IEEE_MODE qualifier primarily affects only the setting of a hardware register at program startup. In general, the /IEEE_MODE behavior for a given function is controlled by the /IEEE_MODE option specified on the compilation that produced the main program: the startup code for the main program sets the hardware register according the command-line qualifiers used to compile the main program.

When applied to a compilation that does not contain a main program, the /IEEE_MODE qualifier does have some effect: it might affect the evaluation of floating-point constant expressions, and it is used to set the EXCEPTION_MODE used by the math library for calls from that compilation. But the qualifier has no effect on the exceptional behavior of floating-point calculations generated as inline code for that compilation. Therefore, if floating-point exceptional behavior is important to an application, all of its compilations, including the one containing the main program, should be compiled with the same /IEEE_MODE setting.

Even on Alpha systems, the particular setting of /IEEE_MODE=UNDERFLOW_TO_ZERO has this characteristic: its primary effect requires the setting of a run-time status register, and so it needs to be specified on the compilation containing the main program in order to be effective in other compilations.

Instead, it searches only places specified explicitly on the command line by the /INCLUDE_DIRECTORY and /LIBRARY qualifiers (or by the location of the primary source file, depending on the /NESTED_INCLUDE_DIRECTORY qualifier). This behavior is similar to that obtained by specifying -I without a directory name to the UNIX cc command.

The basic search order depends on the form of the header-file name (after macro expansion). Additional aspects of the search order are controlled by other command-line qualifiers and the presence or absence of logical name definitions.

However, an empty string also affects the text-module form specific to OpenVMS systems (example: #include stdio).

Quoted Form

Angle-Bracketed Form

Text-Module Form

For the text-module (nonportable) form of inclusion, the name can only be an identifier. It, therefore, has no associated file type.

The default for this qualifier is /NOINCLUDE_DIRECTORY.

Determines how the compiler interprets the long double type. The qualifier options are 64 and 128.

Specifying /L_DOUBLE_SIZE=64 treats all long double references as G_FLOAT, D_FLOAT, or T_FLOAT, depending on the value of the /FLOAT qualifier.

Specifying /L_DOUBLE_SIZE=128 treats all long double references as X_FLOAT.

The default is /L_DOUBLE_SIZE=128.

$ CC  ONE + TWO + THREE/LIBRARY

$ CC  ONE + TWO + THREE/LIBRARY, FOUR

$ CC  THREE/LIBRARY + ONE + TWO
$ CC  ONE + THREE/LIBRARY + TWO
$ CC  ONE + TWO + THREE/LIBRARY

Governs whether or not #line directives appear in preprocess output files.

The default is /LINE_DIRECTIVES.

Produces a source program listing. You must specify this qualifier to get a listing. None of the other qualifiers use /LIST by default.

By default, /LIST creates a listing file with the same name as the source file and with a file extension of .LIS. If you include a file specification with the /LIST qualifier, the compiler uses that specification to name the listing file.

In interactive mode, the default is /NOLIST. In batch mode, the default is /LIST. See the descriptions of the qualifiers /[NO]MACHINE_CODE, and /SHOW for related information. (For example, to suppress compiler messages to the terminal or to a batch log file, use the /SHOW=NOTERMINAL qualifier.)

Lists the generated machine code in the listing file. To produce the listing file, you must also specify /LIST.

On OpenVMS Alpha systems, the format of the generated machine code listing is similar to what you would get using the AFTER keyword on OpenVMS VAX systems.

The default is /NOMACHINE_CODE.

Directs the compiler to call __posix_exit instead of exit when returning from main.

The default is /NOMAIN.

Controls whether the compiler naturally aligns data structure members. Natural alignment means that data structure members are aligned on the next boundary appropriate to the type of the member, rather than on the next byte. For instance, a long variable member is aligned on the next longword boundary; a short variable member is aligned on the next word boundary.

Any use of the #pragma member_alignment or #pragma nomember_alignment directives within the source code overrides the setting established by this qualifier. Specifying /NOMEMBER_ALIGNMENT causes data structure members to be byte-aligned (with the exception of bit-field members).

On OpenVMS Alpha systems, the default is /MEMBER_ALIGNMENT.

On OpenVMS VAX systems, the default is /NOMEMBER_ALIGNMENT.

See the description of #pragma [no]member_alignment in Section 5.4.13.

object_file_name :<tab><source file name>)
object_file_name :<tab><full path to first include file>)
object_file_name :<tab><full path to second include file>)

The default is /NOMMS_DEPENDENCY.

long       initial_crc = -1;
crc_result = lib$crc(good_crc_table,
                     &initial_crc,
                     <descriptor of string to CRC>);

where good_crc_table is:

/*
** Default CRC table:
**
**  This table was taken from Ada's
**  generalized name generation algorithm.
**  It represents a commonly used CRC
**  polynomial known as AUTODIN-II.
**  For more information see the VAX
**  Macro OpenVMS documentation under the
**  CRC VAX instruction.
*/

static const unsigned int good_crc_table[16] =
 {0x00000000, 0x1DB71064, 0x3B6E20C8, 0x26D930AC,
  0x76DC4190, 0x6B6B51F4, 0x4DB26158, 0x5005713C,
  0xEDB88320, 0xF00F9344, 0xD6D6A3E8, 0xCB61B38C,
  0x9B64C2B0, 0x86D3D2D4, 0xA00AE278, 0xBDBDF21C};

#include "file-spec"

The default is /NESTED_INCLUDE_DIRECTORY=INCLUDE_FILE.

Produces an object module. By default, /OBJECT creates an object module file with the same name as that of the first source file of a compilation unit and with the .OBJ file extension. If you include a file specification with /OBJECT, the compiler uses that specification instead.

The compiler executes faster if it does not have to produce an object module. Use the /NOOBJECT qualifier when you need only a listing of a program or when you want the compiler to check a source file for errors. The default is /OBJECT.

Note that the /OBJECT qualifier has no impact on the output file of the /MMS_DEPENDENCIES qualifier.

Determines whether VSI C performs code optimizations.

For OpenVMS VAX systems the default, /OPTIMIZE, is equivalent to /OPTIMIZE=(DISJOINT,INLINE).

For OpenVMS Alpha systems the default, /OPTIMIZE, is equivalent to /OPTIMIZE=(INLINE=AUTOMATIC,LEVEL=4,UNROLL=0,TUNE=GENERIC).

Use /NOOPTIMIZE or /OPTIMIZE=LEVEL=0 for a debugging session to ensure that the debugger has sufficient information to locate errors in the source program.

In most cases, using /OPTIMIZE will make the program execute faster. As a side effect of getting the fastest execution speeds, using /OPTIMIZE can produce larger object modules and longer compile times than /NOOPTIMIZE.

Loop Unrolling

At optimization level 3 or above, VSI C attempts to unroll certain loops to minimize the number of branches and group more instructions together to allow efficient overlapped instruction execution (instruction pipelining). The best candidates for loop unrolling are innermost loops with limited control flow.

As more loops are unrolled, the average size of basic blocks increases. Loop unrolling generates multiple loop code iterations in a manner that allows efficient instruction pipelining.

The loop body is replicated a certain number of times, substituting index expressions. An initialization loop may be created to align the first reference with the main series of loops. A remainder loop may be created for leftover work.

The number of times a loop is unrolled can be determined by the optimizer or the user can specify the limit for loop unrolling using the /OPTIMIZE=UNROLL qualifier. Unless the user specifies a value, the optimizer unrolls a loop 4 times for most loops or 2 times for certain loops (large estimated code size or branches out the loop).

Software Pipelining

Software pipelining and additional software dependence analysis are enabled by using /OPTIMIZE=LEVEL=5, which in certain cases improves run-time performance.

Loop unrolling (enabled at /OPTIMIZE=LEVEL=3 or higher) is constrained in that it cannot schedule across iterations of a loop. Because software pipelining can schedule across loop iterations, it can perform more efficient scheduling that eliminates instruction stalls within loops, by rearranging instructions between different unrolled loop iterations to improve performance.

For example, if software dependence analysis of data flow reveals that certain calculations can be done before or after that iteration of the unrolled loop, software pipelining reschedules those instructions ahead of or behind that loop iteration, at places where their execution can prevent instruction stalls or otherwise improve performance.

By modifying the unrolled loop and inserting instructions as needed before and/or after the unrolled loop, software pipelining generally improves run-time performance, except for cases where the loops contain a large number of instructions with many existing overlapped operations. In this case, software pipelining may not have enough registers available to effectively improve execution performance, and run-time performance using level 5 may not improve as compared to using level 4.

To determine whether using level 5 benefits your particular program, time program execution for the same program compiled at levels 4 and 5. For programs that contain loops that exhaust available registers, longer execution times may result with level 5.

In cases where performance does not improve, consider compiling using /OPTIMIZE=(UNROLL=1, LEVEL=5) to possibly improve the effects of software pipelining.

Forces the compiler to set the PDSC$V_EXCEPTION_MODE field of the procedure descriptor for each function in the compilation unit to the specified value, regardless of the setting of any other qualifiers.

Provides improved optimization and code generation across file boundaries that would not be available if the files were compiled separately.

When you specify /PLUS_LIST_OPTIMIZE on the command line in conjunction with a series of file specifications separated by plus signs, the compiler does not concatenate each of the specified source files together; such concatenation is generally not correct for C code because a C source file defines a scope.

Instead, each file is treated separately for purposes of parsing, except that the compiler issues diagnostics about conflicting external declarations and function definitions that occur in different files. For purposes of code generation, the compiler treats the files as one application and can perform optimizations across the source files.

The default is /NOPLUS_LIST_OPTIMIZE.

Controls whether or not pointer-size features are enabled and whether pointers are 32-bits or 64 bits.

The default is /NOPOINTER_SIZE, which disables pointer-size features, such as the ability to use #pragma pointer_size, and directs the compiler to assume that all pointers are 32-bit pointers. This default represents no change over previous versions of VSI C.

Specifying /POINTER_SIZE=32 enables pointer-size features and directs the compiler to assume that all pointers are 32-bit pointers.

Specifying /POINTER_SIZE=64 enables pointer-size features and directs the compiler to assume that all pointers are 64-bit pointers.

The /POINTER_SIZE qualifier must be specified for any program that uses 64-bit pointers.

Your code may execute faster if it contains float variables and is compiled with /PRECISION=SINGLE. However, the results of your floating-point operations will be less precise. See the VSI C Reference Manual for more information on floating-point variables.

The default is /PRECISION=DOUBLE for /STANDARD=VAXC and /STANDARD=COMMON compiler modes.

The default is /PRECISION=SINGLE for /STANDARD=ANSI89 and /STANDARD=RELAXED compiler modes.

The VSI C Run-Time Library (RTL) shareable image, DECC$SHR.EXE, resides in SYS$LIBRARY with a DECC$ prefix for its entry points. The linker searches IMAGELIB.OLB to locate the shareable image. Every external name in IMAGELIB.OLB has a DECC$ prefix, and, therefore, has an OpenVMS conformant name space (a requirement for inclusion in IMAGELIB).

If you want no names prefixed, specify /NOPREFIX_LIBRARY_ENTRIES.

For /STANDARD=ANSI89, the default is /PREFIX=ANSI_C89_ENTRIES.

For /STANDARD=C99, the default is /PREFIX=C99_ENTRIES.

For all other compiler modes, the default is /PREFIX=ALL.

Gives the same functionality as the -E qualifier on UNIX C compilers. When specified, it performs only the actions of the preprocessor phase and writes the resulting processed text to a file. No semantic or syntax processing is done. Furthermore, no object file, diagnostic file, listing file, or analysis data file is produced.

If you do not specify a file name for the preprocessor output, the name of the output file defaults to the file name of the input file with a .I file type.

The default is /NOPREPROCESS_ONLY.

Creates an output file containing function prototypes for all global functions defined in the module being compiled.

Standard-style prototypes are created even for functions defined with Kernighan and Ritchie style syntax.

This qualifier can be used to convert to Standard-sytle prototypes or just to ensure that every function definition has a compatible explicit declaration, thereby avoiding implicit declarations that can sometimes produce surprising results.

The default is /NOPROTOTYPES.

Controls whether the compiler allocates the size of overlaid psects to ensure compatibility when the psect is shared by code created by other VSI compilers.

The problem this switch solves can occur when a psect generated by a FORTRAN COMMON block is overlaid with a psect consisting of a C struct. Because FORTRAN COMMON blocks are not padded, if the C struct is padded, the inconsistent psect sizes can cause linker error messages.

Compiling with /PSECT_MODEL=MULTILANGUAGE ensures that VSI C uses a consistent psect size allocation scheme. The corresponding FORTRAN switch is /ALIGN=COMMON=[NO]MULTILANGUAGE.

The default is /PSECT=NOMULTILANGUAGE, which is the old default behavior of the compiler, and is sufficient for most applications.

Controls the type of reentrancy that reentrant VSI C RTL routines will exhibit. (See the decc$set_reentrancy RTL routine.)

This qualifier is for use only with a module containing the main routine.

The reentrancy level is set at runtime according to the /REENTRANCY qualifier specified while compiling the module containing the main routine.

The default is /REENTRANCY=TOLERANT.

Specifies a repository for the compiler to store shortened external name information. When /NAMES=SHORTENED is specified, the compiler stores to the repository any external names that were shortened. The demangler utility can then be used to map the shortened names back to the names used in the original C program.

By default, the qualifier is not active unless /NAMES=SHORTENED has been specified, in which case the default is /REPOSITORY=[.CXX_REPOSITORY].

The default name of the repository is the same as that used by the VSI C++ compiler for decoding mangled names. This is intentional. A C++ mangled name cannot match a shortened name, so a single repository can be used by both the VSI C and VSI C++ compilers.

If /FLOAT=G_FLOAT or /FLOAT=D_FLOAT is specified, then rounding defaults to /ROUNDING_MODE=NEAREST, with no other choice of rounding mode.

Controls whether the compiler will treat declarations of objects with the globaldef keyword as shared or not shared.

Also, in conjunction with the /EXTERN_MODEL qualifier, controls whether the initial extern_model is shared or not shared (for those extern_models where it is allowed). The initial extern_model of the compiler is a fictitious pragma constructed from the settings of the /EXTERN_MODEL and /SHARE_GLOBALS qualifiers.

Defines the compilation mode, directing the compiler to flag certain VSI C-specific constructs and VSI C relaxations of conventional C language constructs and rules. For example, the conversions from pointer to integer and back again are subject to more stringent tests when you specify /STANDARD=ANSI89.

The default is /NOSTANDARD, which is equivalent to /STANDARD=RELAXED.

If you specify /STANDARD, you must supply at least one option.

With one exception, the /STANDARD qualifier options are mutually exclusive. Do not combine them. The exception is that you can specify /STANDARD=ISOC94 with any other option except VAXC.

VSI C modules compiled in different modes can be linked and executed together.

Also see the __HIDE_FORBIDDEN_NAMES predefined macro (Section 6.1.7).

Enables the compiled code to be used in combination with translated images, either because the code might call into a translated image or might be called from a translated image. The default is /NOTIE.

See /[NO]DEFINE in this section.

By default, char is a signed character type. The /UNSIGNED_CHAR qualifier lets you change this default to an unsigned character type, which causes all plain char declarations to have the same representation and set of values as unsigned char declarations. The default is /NOUNSIGNED_CHAR.

Invokes the VAX C compiler.

The CC command is used to invoke either the VAX C or VSI C compiler. If your system has a VAX C compiler installed on it, the VSI C installation procedure provides the option of specifying which compiler will be invoked by default when just the CC command is used. To invoke the compiler that is not the default, use the CC command with the appropriate qualifier: CC/DECC for the VSI C compiler, or CC/VAXC for the VAX C compiler.

If your system does not have a VAX C compiler installed on it, the CC command will invoke the VSI C compiler, and the /VAXC qualifier is not supported.

Directs the compiler to print out the compiler version and platform. The compiler version is the same as in the listing file.

CC/DECC/VERSION NL:

Controls the issuance of compiler diagnostic messages or groups of messages. It also allows for the severity of messages to be modified. The default qualifier, /WARNINGS, enables all warning and informational messages for the compiler mode you are using. The /NOWARNINGS qualifier suppresses the warning and informational messages. Also see the #pragma message preprocessor directive.

Table 1.25 describes the /WARNING qualifier options.

The default is /WARNINGS=ENABLE=LEVEL3.

If there are errors in your source file when you compile your program, the VSI C compiler signals these errors and displays diagnostic messages. Reference the message, locate the error, and, if necessary, correct the error. See Appendix D or the online help for a description of all compiler diagnostic messages.

You can control the issuance of specific compiler diagnostic messages or groups of messages with the /[NO]WARNINGS command-line qualifier (Section 1.3.4) and the #pragma message preprocessor directive (Section 5.4.14).

$ HELP CC/DECC MESSAGE mnemonic    (VAX only)
$ HELP CC MESSAGE mnemonic    (Alpha, I64)

$ HELP /DECC MESSAGE    (VAX only)
$ HELP CC MESSAGE    (Alpha, I64)

%CC-s-ident, message-text
                Listing line number m
                At line number n in name

The facility or program name of the VSI C compiler. This portion indicates that the message is being issued by VSI C.

LINK[/command-qualifier]... {file-spec[/file-qualifier...]},...

Output file options.

The input files to be linked.

Input file options.

If you specify more than one input file, you must separate the input file specifications with a plus sign (+) or a comma (,).

By default, the linker creates an output file with the name of the first input file specified and the file type EXE. If you link more than one file, you should specify the file containing the main program first. Then, the name of your output file will have the same name as your main program module.

$ LINK MAINPROG.OBJ, SUBPROG1.OBJ, SUBPROG2.OBJ

You can use the LINK command qualifiers to modify the linker's output, as well as to invoke the debugging and traceback facilities. Linker output consists of an image file and an optional map file.

The following list summarizes some of the most commonly used LINK command qualifiers. A brief description of each qualifier follows this list. For a complete list of LINK qualifiers, see the VSI OpenVMS Linker Utility Manual.

Produces a summary of the image's characteristics and a list of contributing modules. This qualifier is mutually exclusive with /FULL.

Produces cross-reference information for global symbols; /NOCROSS_REFERENCE suppresses cross-reference information. The default is /NOCROSS_REFERENCE.

Includes the OpenVMS Debugger in the executable image and generates a symbol table; /NODEBUG causes the linker to prevent debugger control of the program. The default is /NODEBUG.

Produces an executable image. /NOEXECUTABLE suppresses production of an image file. The default is /EXECUTABLE.

Produces a summary of the image's characteristics, a list of contributing modules, listings of global symbols by name and by value, and a summary of characteristics of image sections in the linked image. This qualifier is mutually exclusive with /BRIEF.

Generates a map file; /NOMAP suppresses the map. The default is /MAP in batch mode and /NOMAP in interactive mode.

Creates a shareable image. /NOSHAREABLE generates an executable image. The default is /NOSHAREABLE.

Generates symbolic traceback information when error messages are produced; NOTRACEBACK suppresses traceback information. The default is /TRACEBACK.

When you enter the LINK command interactively and do not specify any qualifiers, the linker creates only an executable image file. By default, the resulting image file has the same file name as that of the first object module specified with a file type of EXE.

In a batch job, the linker creates both an executable image file and storage map file by default. The default file type for map files is MAP.

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

Linking against object modules (stored in object module libraries) or against shareable images are ways of allowing your program to access data and routines outside of your compilation units. You can either create the object module libraries and the shareable images or use the ones provided by VSI. To access data in object modules and shareable images, you can use LINK command qualifiers, OpenVMS logical names, and options files. For more information about object module libraries, see the VSI OpenVMS Linker Utility Manual.

The VSI C Run-Time Library (RTL) for OpenVMS systems also provides two formats for you to choose from: shareable images or object module libraries. Depending on which type of RTL you want to use and on which type of functions you plan on calling from your programs, you need to supply information to the linker that specifies which versions of the functions to access.

When you use the C RTL and its corresponding header files, remember that the C RTL ships with the OpenVMS operating system and the header files ship with the VSI C compiler. Since the releases of the compiler and of the operating system are not synchronized, there may be compatibility issues that you need to consider to use the RTL properly. See the VSI C release notes (by entering HELP CC/DECC RELEASE_NOTES on the DCL command line) for information that may pertain to this issue.

For a description of the various ways to link with the C RTL, see the VSI C Run-Time Library Reference Manual for OpenVMS Systems.

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

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 linking operation, the linker searches the specified library for all unresolved references found in the included modules during compilation.

$ LINK BADMINTON, TENNIS, RACQUETBALL, RACQUETS/LIBRARY

You can define an object module library to be your default library by using the DCL command DEFINE LNK$LIBRARY. The linker searches default user libraries for unresolved references after it searches modules and libraries specified in the LINK command. For more information about the DEFINE command, see the VSI OpenVMS DCL Dictionary.

For more information about object module libraries, see the VSI OpenVMS Linker Utility Manual.

If the linker detects any errors while linking object modules, it displays messages indicating the cause and severity of the error. If any error or fatal error conditions occur (that is, errors with severities of E or F), the linker does not produce an image file.

If an error occurs when you link modules, you can often correct it by reentering the command and specifying the correct modules or libraries. If an error indicates that a program module cannot be located, you may be linking the program with the wrong RTL.

For a complete list of linker messages, see the OpenVMS System Messages and Recovery Procedures Reference Manual.

The pointer-size qualifiers and pragmas affect only a limited number of constructs in the C language itself. At places where the syntax creates a pointer type, the pointer-size context determines the size of that type. Pointer-size context is defined by the most recent pragma (or command-line qualifier) affecting pointer size.

#pragma pointer_size 64
typedef int * j_ptr;    // * is 64-bit
#define J_PTR int *     // * is not analyzed

#pragma pointer_size 32
j_ptr j;   // j is a 64-bit pointer.
J_PTR J;   // J is a 32-bit pointer.

Be aware that pointer-size controls are not unique in the way they affect header files; other features that affect data layout have similar impact. For example, most header files should be compiled with 32-bit pointers regardless of pointer-size context. Also, most system header files (on OpenVMS Alpha and I64 systems) must be compiled with member_alignment regardless of user pragmas or qualifiers.

To address this issue more generally, the pragma environment directive can be used to save context and set header defaults at the beginning of each header file, and then to restore context at the end. See Section 5.4.4 for a description of pragma environment.

For header files that have not yet been upgraded to use #pragma environment, the /POINTER_SIZE=64 qualifier can be difficult to use effectively. For such header files that are not 64-bit aware, the compiler automatically applies user-defined prologue and epilogue files before and after the text of the included header file. See Section 1.7.4 for more information on prologue/epilogue files.

VSI C automatically processes user-supplied prologue and epilogue header files. This feature is an aid to using header files that are not 64-bit aware within an application that is built to exploit 64-bit addressing.

__DECC_INCLUDE_PROLOGUE.H:

#ifdef __PRAGMA_ENVIRONMENT
#pragma environment save
#pragma environment header_defaults
#else
#error "__DECC_INCLUDE_PROLOGUE.H: This compiler does not support
pragma environment"
#endif

__DECC_INCLUDE_EPILOGUE.H:

#ifdef __PRAGMA_ENVIRONMENT
#pragma __environment restore
#else
#error "__DECC_INCLUDE_EPILOGUE.H: This compiler does not support
pragma environment"
#endif

Sequential organization is the only kind permitted for magnetic tape files and other nondisk devices.

Relative file organization is possible only on disk devices.

Indexed files have records that contain, in addition to data and carriage-control information, one or more keys. Keys can be character strings, packed decimal numbers, and 16-bit, 32-bit, or 64-bit signed or unsigned integers. Every record has at least one key, the primary key, whose value in each record cannot be changed. Optionally, each record can have one or more alternate keys, whose key values can be changed.

Unlike relative record numbers used in relative files, key values in indexed files are not necessarily unique. When you create a file, you can specify that a particular key have the same value in different records (these keys are called duplicate keys). Keys are defined for the entire file in terms of their position within a record and their length.

Indexed organization is possible only on disk devices.

/*  This example shows how to initialize a file access block.   */

#include <rms.h>               /*  Declare all RMS data structs */

struct  FAB   fblock;          /*  Define a file access block   */


main()
{
   fblock = cc$rms_fab;        /*  Initialize the structure     */
      .
      .
      .
}

/* This program shows how to dynamically allocate RMS structures. */

#include <rms.h>                 /*  Declare all RMS data structs */


main()
{
                                 /*  Allocate dynamic storage     */
   struct  FAB     *fptr = malloc(sizeof (struct FAB));
   *fptr = cc$rms_fab;           /*  Initialize the structure     */
      .
      .
      .
}

fblock.fab$l_xab = &primary_key;

This statement assigns the address of the extended attribute block named primary_key to the fab$l_xab member of the file access block named fblock.

There is only one extended attribute block structure (XAB), but there are seven ways to initialize it. The extended attribute blocks define additional file attributes that are not defined elsewhere. For example, the key extended attribute block is used to define the keys of an indexed file.

/*  This example shows how to initialize the extended          *
 *  attribute block.                                           */

#include <rms.h>
struct  XABKEY  primary_key,alternate_key;


main()
{
   primary_key           = cc$rms_xabkey;
   alternate_key         = cc$rms_xabkey;
   primary_key.xab$l_nxt = &alternate_key;
      .
      .
      .
}

The name block contains default file name values, such as the directory or device specification, file name, or file type. If you do not specify one of the parts of the file specification when you open the file, RMS uses the values in the name block to complete the file specification and places the complete file specification in an array.

/*  This example shows how to initialize a name block.         */

#include <rms.h>

struct  NAM  nam;
struct  FAB  fab;


main()
{
   fab = cc$rms_fab;
   nam = cc$rms_nam;


                              /*  Define an array for the      *
                               *   expanded file specification */
   char expanded_name[NAM$C_MAXRSS];

                              /*  Initialize the appropriate   *
                               *   members                     */
   fab.fab$l_nam = &nam;
   nam.nam$l_esa = &expanded_name;
   nam.nam$b_ess =  sizeof  expanded_name;
      .
      .
      .
}