Migrating an Application from OpenVMS VAX to OpenVMS Alpha

These built-ins guarantee only that the operation completes without interruption. If you perform an atomic operation on a variable that might be subject to concurrent write access (for example, from an AST and mainline code or from two concurrent processes), you must still protect it with the volatile attribute.

In addition, DEC C for OpenVMS Alpha systems supports the following equivalents to the VAX interlocked instructions:

TESTBITSSI
TESTBITCCI

These built-ins use the retry_count parameter, as do the atomicity built-ins, to avoid getting stuck in an endless loop.

11.2.4 Differences Between the VAX C and DEC C for OpenVMS Alpha Systems Compilers

The following features, present in VAX C, have different default behavior in DEC C for OpenVMS Alpha systems. Note, however, that for some of these features, you can retain the VAX C behavior by using command-line qualifiers and pragma instructions.

11.2.4.1 Controlling Data Alignment

Because accesses to data that is not aligned on natural boundaries cause severe performance degradation on Alpha systems, DEC C for OpenVMS Alpha systems aligns data on natural boundaries by default. To override this feature and retain VAX (packed) alignment, specify the # pragma nomember_alignment preprocessor directive in your source file or use the /NOMEMBER_ALIGNMENT command line qualifier.

11.2.4.2 Accessing Argument Lists

Taking the address of an argument, such as &argv1, causes DEC C for OpenVMS Alpha systems to generate prologue code for the function that moves all the arguments onto the stack (called homing arguments), causing a performance degradation. Also, argument list "walking" can be accomplished only by using the functions in the <varargs.h> or <stdargs.h> include files.

11.2.4.3 Synchronizing Exceptions

Because the Alpha architecture does not provide for immediate reporting of arithmetic exceptions, do not expect an assignment to a static variable (even with the volatile attribute) to occur before a subsequent exception is signaled.

11.2.4.4 Dynamic Condition Handlers

Although DEC C and DEC C++ for OpenVMS Alpha systems treat LIB$ESTABLISH as a built-in function, using LIB$ESTABLISH is not recommended on OpenVMS VAX or OpenVMS Alpha systems. C and C++ programmers should call VAXC$ESTABLISH instead of LIB$ESTABLISH (VAXC$ESTABLISH is a built-in function on DEC C and DEC C++ for OpenVMS Alpha systems).

11.2.5 STARLET Data Structures and Definitions for C Programmers

OpenVMS Alpha Version 1.0 included a new file, SYS$STARLET_C.TLB, that contained all the .H files that provide STARLET functionality equivalent to STARLETSD.TLB. The file SYS$STARLET_C.TLB, together with DECC$RTLDEF.TLB now shipping with the DEC C Compiler, replaces VAXCDEF.TLB that previously shipped with the VAX C Compiler. DECC$RTLDEF.TLB contains all the .H files that support the compiler and RTL, such as STDIO.H.

The following differences may require source changes:

RMS structures
Previously, the RMS structures FAB, NAM, RAB, XABALL, and so forth, were defined in the appropriate .H files as "struct RAB {...", for example. The .H files supplied in OpenVMS Alpha Version 1.0 defined them as "struct rabdef {...". To compensate for this difference, lines of the form "#define RAB rabdef" were added. However, there is one situation where a source change is required because of this change. If you have a private structure that contains a pointer to one of these structures and your private structure is defined (but not used) before the RMS structure has been defined, you will receive compile-time errors similar to the following:
```
%CC-E-PASNOTMEM, In this statement, "rab$b_rac" is not a member of "rab". 
```
This error can be avoided by reordering your source file so that the RMS structure is defined before the private structure. Typically, this involves moving around "#include" statements.
LIB (privileged interface) structures
Historically, three structures from LIB (NFBDEF.H, FATDEF.H, and FCHDEF.H) have been made available as .H files. These files were shipped as .H files in OpenVMS Alpha Version 1.0 and 1.5 (not in the new SYS$STARLET_C.TLB). In OpenVMS Alpha 7.1, the file SYS$LIB_C.TLB, containing all LIB structures and definitions, has been added. These three .H files are now part of that .TLB and are no longer shipped separately. Source changes may be required, as no attempt has been made to preserve any existing anomalies in these files. The structures and definitions from LIB are for privileged interfaces only and are therefore subject to change.
Use of "variant_struct" and "variant_union" In the new .H files, variant_struct and variant_union are always used, whereas previously some structures used struct and union. Therefore, the intermediate structure names cannot be specified when referencing fields within data structures.
For example, the following statement:
```
AlignFaultItem.PC[0] = DataPtr->afr$r_pc_data_overlay.afr$q_fault_pc[0]; 
```
becomes:
```
AlignFaultItem.PC[0] = DataPtr->afr$q_fault_pc[0]; 
```
Member alignment
Each of the .H files in SYS$STARLET_C.TLB saves and restores the state of "#pragma member_alignment".
Conventions The .H files in SYS$STARLET_C.TLB adhere to some conventions that were only partly followed in VAXCDEF.TLB. All constants (#defines) have uppercase names. All identifiers (routines, structure members, and so forth) have lowercase names. Where there is a difference from VAXCDEF.TLB, the old symbol name is also included for compatibility, but users are encouraged to follow the new conventions.
Use of Librarian utility to access the .H files
During installation of OpenVMS Alpha, the contents of SYS$STARLET_C.TLB are not extracted into the separate .H files. The DEC C Compiler accesses these files from within SYS$STARLET_C.TLB, regardless of the format of the #include statement. If you want to inspect an individual .H file, you can use the Librarian utility, as in the following example:
```
$ LIBRARY /EXTRACT=AFRDEF /OUTPUT=AFRDEF.H SYS$LIBRARY:SYS$STARLET_C.TLB
```
Additional .H files included in SYS$STARLET_C.TLB
In addition to the .H files derived from STARLET sources, SYS$STARLET_C.TLB includes .H files that provide support for DECthreads, such as CMA.H.

11.2.6 VAX C Features Not Supported by /STANDARD=VAXC Mode

While most programming practices supported by VAX C are supported by DEC C for OpenVMS Alpha systems in /STANDARD=VAXC mode, certain programming practices that conflict with the ANSI standard are not supported. The following list highlights some of these differences; see the DEC C compiler documentation for more information.

The inclusion of text after an #endif statement, as in the following example:
```
#ifdef a 
   .
   .
   .
#endif a  
```
Delete the text or surround it with comment delimiters, as in the following:
```
#endif /* a */ 
```
Modification of string constants, while always a questionable programming practice, was accepted by VAX C. DEC C for OpenVMS Alpha systems places all string constants in a read-only program section so that they cannot be modified.

Structure-initialization values must be enclosed within braces ({}):

array[SIZE] = NULL;   /* accepted by VAX C */ 
array[SIZE] = {NULL}; /* required by DEC C */

Redefinitions of symbols are now flagged with a warning-level diagnostic message:
```
#define x  a 
#define x  b   /* generates a warning message in DEC C */ 
```
Use of text libraries is no longer recommended. While supported by VAX C, text libraries are not portable.
```
#include  stdio    
```
Instead, use the following syntax:
```
#include <stdio.h> 
```
You must have one, and only one, declaration of an external variable. This is the definition of this variable. Other modules can use it by declaring it with the extern semantics.
If you are recompiling VAX C code, either an entire application or one or more modules, you will want to pay particular attention to any external symbols that it contains. Unlike the VAX C compiler which supports one external symbol model, the DEC C compiler supports four models. The default external symbol produced by the DEC C compiler is not the same as the single VAX C external symbol.
Furthermore, when you link such code, due to changes in the linker, if you did not specify the /SHARE qualifier when you recompiled the C code module, you will need to specify a related linker qualifier.

11.3 VAX COBOL and DEC COBOL Compatibility and Migration

DEC COBOL is based on and is highly compatible with VAX COBOL, which runs on the OpenVMS VAX system. However, there are differences, which are summarized in the following sections. This information can help you develop COBOL applications that are compatible with both products and can help you migrate your VAX COBOL applications to DEC COBOL on the OpenVMS Alpha operating system.

11.3.1 DEC COBOL Extensions and Features Differences

DEC COBOL contains the following language extensions and other features that are not in VAX COBOL:

A choice of alignment on the compile command line or as a source directive for individual records; you can select Alpha data alignment to optimize performance or VAX COBOL data alignment for compatibility with VAX COBOL.
A qualifier that selects IEEE or VAX floating-point data types for single- and double-precision data items.
Aqualifier to generate code that allows native OpenVMS Alpha images to call translated VAX images and translated VAX images to call native OpenVMS Alpha images.
A qualifier to recognize additional COBOL reserved words defined by the X/Open Portability Guide.
A qualifier that changes all blanks to zeros in numeric display items.
COMP-5 and COMP-X as synonyms for COMP.
READ PRIOR and START LESS
Support for porting programs between other COBOL compilers and DEC COBOL (/RESERVED_WORDS=FOREIGN_EXTENSIONS)
X/Open ASSIGN TO, LINE SEQUENTIAL, RETURN-CODE, SCREEN SECTION, FILE-SHARING and RECORD-LOCKING

In addition, note that DEC COBOL includes the following:

Support for the relevant subset of the functionality in the VAX COBOL /STANDARD=V3 qualifier.
Support for file status values that are compatible with VAX COBOL Version 5.1, which differ from those of VAX COBOL Version 5.0 and previous versions.

DEC COBOL does not contain the following VAX COBOL features:

The DECset/LSE Program Design Facility, the /DESIGN qualifier, design comments, or pseudocode placeholders.
DEC COBOL does not support VFU-CHANNEL and thus provides no direct support for VFU and VFP (Vertical Forms Unit utilities and Vertical Forms Printing).
COPY FROM DICTIONARY

For additional information about DEC COBOL and VAX COBOL, refer to the product release notes and documentation. You can obtain an online version of the release notes for your installed compiler on the OpenVMS Alpha operating system by entering the HELP COBOL RELEASE_NOTES command at the system prompt.

11.3.2 Command Line Qualifiers

Sections 11.3.2.3 and 11.3.2.5 compare the DEC COBOL and VAX COBOL command line qualifiers. For complete information about DEC COBOL command line qualifiers on the OpenVMS Alpha operating system, invoke the online HELP facility: Type HELP COBOL at the OpenVMS Alpha system prompt. For information about VAX COBOL command line qualifiers, see the VAX COBOL User Manual.

11.3.2.1 /NATIONALITY={JAPAN|US}

When /NATIONALITY=JAPAN is specified, the yen sign (¥) is the default currency sign and symbol, and Japanese Language Support features are enabled. Also, in this case /NODIAGNOSTICS and /NOANALYSIS_DATA are specified implicitly.

Oracle CDD/Repository is not supported by DEC COBOL on OpenVMS Alpha when /NATIONALITY=JAPAN is used.

When /NATIONALITY=US is specified on the compile command line, the dollar sign ($) is the default currency sign and symbol, and Japanese Language Support features are disabled.

11.3.2.2 /STANDARD=MIA

If /STANDARD=MIA are present on the compile command line, the compiler will issue informational diagnostics for those language elements that do not conform to the MIA specifications:

Digital syntax extension from Base Standards (ANSI-85, JIS-88)
Two of four optional modules
All obsolete language elements of required modules in Base Standards
Language elements omitted from required modules in Base Standards due to the different implementation of the vendors
Digital-specific Japanese features out of MIA Extension Elements related to Japanese

To receive the diagnostics, the /WARNINGS=ALL qualifier or /WARNING=INFORMATION qualifier is required.

The default is NOMIA.

11.3.2.3 DEC COBOL-Specific Qualifiers

The following command line qualifiers are available only on DEC COBOL.

/ALIGNMENT
/CHECK=DECIMAL
/CONVERT=LEADING_BLANKS
/FLOAT=D_FLOAT
/FLOAT=G_FLOAT
/FLOAT=IEEE_FLOAT
/OPTIMIZE[=LEVEL=n]
/RESERVED_WORDS=FOREIGN_EXTENSIONS
/RESERVED_WORDS=[NO]XOPEN
/SEPARATE_COMPILATION¹
/TIE
/VFC¹

11.3.2.4 /ALIGNMENT=PADDING

The OpenVMS Calling Standard requires that data fields be aligned on specific addresses (shown in that standard). The same standard specifies that the lengths of all data records must be multiples of their alignments.

If /ALIGNMENT=PADDING is present on the compile command line, COBOL group data-items will be aligned on their natural boundaries and those group items will be padded out to multiples of their alignments. See the DEC COBOL Reference Manual for detailed information about elementary data item alignment with Alpha alignment and padding in effect.

11.3.2.5 VAX COBOL-Specific Qualifiers

Table 11-6 lists the command line qualifiers and qualifier-option combinations that are specific to VAX COBOL. These are not available in DEC COBOL.

Table 11-6 VAX COBOL-Specific Qualifiers
Qualifier Comments

/DESIGN Controls whether the compiler processes the input file as a detailed design.

/INSTRUCTION_SET[=option] Improves run-time performance on single-chip VAX processors, using different portions of the VAX instruction set.

/STANDARD=OPENVMS_AXP Produces informational messages on language features that are not supported by the DEC COBOL compiler. (See Section 11.3.2.7 and the VAX COBOL Version 5.1 release notes.)

/STANDARD=PDP11 Produces informational messages on language features that are not supported by the COBOL-81 compiler.

/WARNINGS=STANDARD Produces informational messages on language features that are Digital extensions. The DEC COBOL equivalent is the /STANDARD=SYNTAX qualifier.

**Table 11-6 VAX COBOL-Specific Qualifiers**
Qualifier	Comments
/DESIGN	Controls whether the compiler processes the input file as a detailed design.
/INSTRUCTION_SET[=option]	Improves run-time performance on single-chip VAX processors, using different portions of the VAX instruction set.
/STANDARD=OPENVMS_AXP	Produces informational messages on language features that are not supported by the DEC COBOL compiler. (See Section 11.3.2.7 and the VAX COBOL Version 5.1 release notes.)
/STANDARD=PDP11	Produces informational messages on language features that are not supported by the COBOL-81 compiler.
/WARNINGS=STANDARD	Produces informational messages on language features that are Digital extensions. The DEC COBOL equivalent is the /STANDARD=SYNTAX qualifier.

11.3.2.6 /STANDARD=V3

DEC COBOL does not support a number of features supported by the VAX COBOL implementation of the /STANDARD=V3 qualifier:

When subscripts are evaluated in STRING, UNSTRING, and INSPECT (Format 3) statements and the REMAINDER phrase of the DIVIDE statement
When reference modification is evaluated in STRING, UNSTRING, and INSPECT (Format 3) statements
When the variable associated with the VARYING phrase is augmented in PERFORM...VARYING...AFTER statements (Format 4)
How PIC P digits are interpreted in some moves
When the size of variable-length tables (OCCURS DEPENDING ON) is determined in the MOVE statement

The /WARNINGS=ALL qualifier can help you determine the effects of /STANDARD=V3; in particular, DEC COBOL generates the following informational messages if /STANDARD=V3 has been specified:

For items that may be affected by evaluation order in the INSPECT, STRING, UNSTRING, and DIVIDE statements:
```
        /STANDARD=V3 evaluation order not 
          supported for this construct 
```

For destinations where OCCURS DEPENDING ON requires different behavior in the MOVE statement:

        /STANDARD=V3 variable length item 
          rules not supported for this construct

For full information on the VAX COBOL implementation of the /STANDARD=V3 qualifier, see the appendix on qualifiers in the VAX COBOL User Manual.

11.3.2.7 /STANDARD=OPENVMS_AXP

VAX COBOL Version 5.1 (and higher) provides a new flagging system, via the /STANDARD=OPENVMS_AXP qualifier option, to identify language features in your existing VAX COBOL programs that are not available in DEC COBOL on the OpenVMS Alpha system.

When you specify /STANDARD=OPENVMS_AXP, the VAX COBOL compiler generates informational messages to alert you to language constructs that are not available in DEC COBOL. (You must also specify /WARNINGS=ALL or /WARNINGS=INFORMATIONAL to receive these messages.) You can use this information to modify your program before using DEC COBOL.

Specify /STANDARD=NOOPENVMS_AXP, which is the default, to suppress these informational messages.

11.3.3 DEC COBOL and VAX COBOL Behavior Differences

This section describes behavior differences between VAX COBOL and DEC COBOL, and also certain behavior that is specific to DEC COBOL.

11.3.3.1 Program Structure Messages

In some cases, the DEC COBOL compiler generates more complete messages about unreachable code or other logic errors than does the VAX COBOL compiler.

The following example illustrates a sample program and the messages issued by the DEC COBOL compiler:

Source file:

       IDENTIFICATION DIVISION. 
       PROGRAM-ID. T1. 
       ENVIRONMENT DIVISION. 
       PROCEDURE DIVISION. 
       P0. 
           GO TO P1. 
       P2. 
           DISPLAY "This is unreachable code". 
       P1. 
           STOP RUN.

On OpenVMS VAX systems:

$ COBOL /ANSI/WARNINGS=ALL T1.COB
$

The program compiles. The VAX COBOL compiler produces no messages.

On OpenVMS Alpha systems:

$ COBOL/ANSI/OPTIMIZE/WARNINGS=ALL T1.COB
       P2. 
.......^ 
%COBOL-I-UNREACH, code can never be executed at label P2 
at line number 7 in file DISK$YOURDISK:[TESTDIR]T1.COB;1

DEC COBOL on either operating system is an optimizing compiler. One use of optimization is to perform analysis for uncalled routines and unreachable paragraphs. The compiler performs the unreachable code analysis for all levels of optimization, including /NOOPTIMIZE. (Full optimization is the default, so it is not necessary to specify the qualifier or flag on the command line as in the examples.) VAX COBOL does not have an /OPTIMIZE qualifier.

11.3.3.2 Program Listing Differences

There are some differences that appear in program listings produced by the VAX COBOL compiler and the DEC COBOL compiler on the OpenVMS Alpha system.

11.3.3.2.1 Machine Code

With DEC COBOL, the /NOOBJECT qualifier causes the compiler to suppress code generation, so no machine code is produced either for the listing or for the object module.

With VAX COBOL, /NOOBJECT suppresses just the creation of the .OBJ. VAX COBOL still does all the work to generate the object code so it can be placed in the listing.

If you want the machine code to be included in the program listing, do not use /NOOBJECT.

11.3.3.2.2 Module Names

With DEC COBOL, the name of the first program is the module name throughout the compilation. With VAX COBOL, the module name changes as the various programs are encountered.

11.3.3.2.3 COPY and REPLACE Statements

The DEC COBOL compiler and the VAX COBOL compiler produce output in slightly different formats when listing annotations for the COPY statement in COBOL programs.

The following two compiler listing files illustrate the difference in the position of the listing annotations, represented by the letter "L," in a COBOL program using DEC COBOL and VAX COBOL.

DEC COBOL Listing File for COPY Statement:

 
              1 IDENTIFICATION DIVISION. 
              2 PROGRAM-ID. DCOP1B. 
              3 * 
              4 *       This program tests the copy library file. 
              5 *       with a comment in the middle of it. 
              6 *       It should not produce any diagnostics. 
              7         COPY 
              8 *       this is the comment in the middle 
              9                 LCOP1A. 
L            10 ENVIRONMENT DIVISION. 
L            11 INPUT-OUTPUT SECTION. 
L            12 FILE-CONTROL. 
L            13 SELECT FILE-1 
L            14         ASSIGN TO "FILE1.TMP". 
             15 DATA DIVISION. 
             16 FILE SECTION. 
             17 FD      FILE-1. 
             18 01      FILE1-REC       PIC X. 
             19 WORKING-STORAGE SECTION. 
             20 PROCEDURE DIVISION. 
             21 PE.     DISPLAY "***END***" 
             22         STOP RUN.

VAX COBOL Listing File for COPY Statement:

 
 
    1         IDENTIFICATION DIVISION. 
    2         PROGRAM-ID. DCOP1B. 
    3        * 
    4        *    This program tests the copy library file. 
    5        *    with a comment in the middle of it. 
    6        *    It should not produce any diagnostics. 
    7             COPY 
    8        *    this is the comment in the middle 
    9                     LCOP1A. 
   10L        ENVIRONMENT DIVISION. 
   11L        INPUT-OUTPUT SECTION. 
   12L        FILE-CONTROL. 
   13L        SELECT FILE-1 
   14L            ASSIGN TO "FILE1.TMP". 
   15         DATA DIVISION. 
   16         FILE SECTION. 
   17         FD  FILE-1. 
   18         01  FILE1-REC       PIC X. 
   19         WORKING-STORAGE SECTION. 
   20         PROCEDURE DIVISION. 
   21         PE. DISPLAY "***END***" 
   22             STOP RUN.

11.3.3.2.4 Multiple COPY Statements

The DEC COBOL and VAX COBOL compilers also produce output in slightly different formats when listing a COBOL program with multiple COPY statements on a single line.

The following two compiler listing files illustrate the difference in the position of the listing annotations, represented by the letter "L," for multiple COPY statements on a single line in a COBOL program using DEC COBOL and VAX COBOL.

DEC COBOL Listing File for Multiple COPY Statements:

 
 
              1 IDENTIFICATION DIVISION. 
              2 PROGRAM-ID. DCOP1J. 
              3 * 
              4 *       Tests copy with three copy statements on 1 line. 
              5 * 
              6 ENVIRONMENT DIVISION. 
              7 DATA DIVISION. 
              8 PROCEDURE DIVISION. 
              9 THE. 
             10         COPY LCOP1J. COPY LCOP1J. COPY LCOP1J. 
L            11         DISPLAY "POIUYTREWQ". 
L            12         DISPLAY "POIUYTREWQ". 
L            13         DISPLAY "POIUYTREWQ". 
             14         STOP RUN.

VAX COBOL Listing File for Multiple COPY Statements:

 
 
    1         IDENTIFICATION DIVISION. 
    2         PROGRAM-ID. DCOP1J. 
    3        * 
    4        *    Tests copy with three copy statements on 1 line. 
    5        * 
    6         ENVIRONMENT DIVISION. 
    7         DATA DIVISION. 
    8         PROCEDURE DIVISION. 
    9         THE. 
   10             COPY LCOP1J. 
   11L            DISPLAY "POIUYTREWQ". 
   12C                         COPY LCOP1J. 
   13L            DISPLAY "POIUYTREWQ". 
   14C                                      COPY LCOP1J. 
   15L            DISPLAY "POIUYTREWQ". 
   16             STOP RUN.

11.3.3.2.5 COPY Insert Statement

The compiler listing files for a DEC COBOL program and a VAX COBOL program differ when a COPY statement inserts text in the middle of a line.

In the following two compiler listing files, LCOP5D.LIB contains "O". The DEC COBOL compiler keeps the same line and inserts the COPY file contents below the source line. The VAX COBOL compiler splits the original source line into parts.

DEC COBOL Listing File for COPY Statement:

 
        ----------------------------------------------------------- 
           13 P0.     MOVE COPY LCOP5D. TO ALPHA. 
        L  14              "O"

VAX COBOL Listing File for COPY Statement:

 
        ----------------------------------------------------------- 
        13         P0. MOVE COPY LCOP5D. 
        14L                 "O" 
        15C                              TO ALPHA.

11.3.3.2.6 REPLACE Statement

The diagnostic messages for the COBOL source statements REPLACE and DATE-COMPILED result in compiler listing files that contain multiple instances of the source line.

Note

¹ The action of DEC COBOL with this qualifier is designed to closely match the default action with VAX COBOL.

  6459P012.HTM
  OSSG Documentation
  22-NOV-1996 13:07:22.95

Legal