Migrating an Application from OpenVMS VAX to OpenVMS Alpha

November 1996

Revision/Update Information: This manual supersedes Migrating an Application from OpenVMS VAX to OpenVMS Alpha, Version 7.0.

Software Version: OpenVMS Alpha Version 7.1 OpenVMS VAX Version 7.1

Digital Equipment Corporation Maynard, Massachusetts

Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description.

Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Digital or an authorized sublicensor.

Digital conducts its business in a manner that conserves the environment and protects the safety and health of its employees, customers, and the community.

© Digital Equipment Corporation 1996. All rights reserved.

The following are trademarks of Digital Equipment Corporation: ALL-IN-1, Bookreader, CI, DDIF, DEC, DEC Ada, DEC Fortran, DECdirect, DECforms, DECmigrate, DECnet, DECset, DECterm, DECthreads, DECwindows, Digital, Digital UNIX, OpenVMS, PATHWORKS, PDP-11, SPM, TURBOchannel, VAX, VAX 6000, VAX Ada, VAX C, VAX COBOL, VAX DOCUMENT, VAX FORTRAN, VAX MACRO, VAX Pascal, VAX SCAN, VAXft, VAXstation, VMS, XMI, XUI, and the DIGITAL logo.

The following are third-party trademarks:

Futurebus/Plus is a registered trademark of Force Computers GMBH, Fed. Rep. of Germany.

IEEE is a registered trademark of the Institute of Electrical and Electronics Engineers, Inc.

INGRES is a registered trademark of Ingres Corporation.

Motif is a registered trademark of Open Software Foundation, Incorporated.

Oracle Rdb, Oracle CODASYL DBMS are registered trademarks of Oracle Corporation.

UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Ltd.

Windows NT is a trademark of Microsoft Corporation.

X/Open is a trademark of X/Open Company Limited.

All other trademarks and registered trademarks are the property of their respective holders.

ZK6459

The OpenVMS documentation set is available on CD-ROM.

Preface

Migrating an Application from OpenVMS VAX to OpenVMS Alpha is designed to assist developers in moving OpenVMS VAX applications to an OpenVMS Alpha system or a mixed-architecture> cluster.

Intended Audience

This manual is intended for experienced software engineers responsible for migrating application code written in high- or mid-level programming languages.

Document Structure

• Chapter 1 provides an overview of the relationship of OpenVMS and the VAX and Alpha architectures, and of the process of migrating an application from a VAX to an Alpha system. It includes information on the following:
  • Areas in which OpenVMS Alpha is highly compatible with OpenVMS VAX
  • Comparison of the Alpha architecture with other RISC architectures and with the VAX architecture
  • Overview of the stages in the migration process
  • The two main migration paths---recompiling source code and translating VAX images
  • Migration support available from Digital
• Chapter 2 considers the differences between the two main migration paths and the issues involved in choosing which path to take in migrating your application. It also describes how to analyze the individual parts of your application to identify architectural differences that affect migration and how to assess what is involved in resolving those differences.
• Chapter 3 describes the steps in the actual migration, from setting up your migration environment to integrating the migrated application into a new environment.
• Chapter 4 provides an overview of converting your application by recompiling and relinking.
• Chapter 5 describes how to handle dependencies your application may have on the VAX page size.
• Chapter 6 describes how to handle dependencies your application may have on the synchronization provided by the VAX architecture with regard to data access by multiple processes.
• Chapter 7 describes the implications of data declarations on an Alpha system, including alignment concerns.
• Chapter 8 describes how to handle dependencies your application may contain on the VAX condition-handling facility.
• Chapter 9 discusses translating VAX images to run on Alpha systems.
• Chapter 10 describes how to create native Alpha images that can call and be called by translated VAX images.
• Chapter 11 contains brief summaries of the new and changed features supported by the Ada, C, COBOL, FORTRAN, and Pascal programming languages on Alpha systems.
• Appendix A contains a checklist that you can use to evaluate your application for migration from OpenVMS VAX to OpenVMS Alpha.

Related Documents

This manual is part of a set of manuals that describes various aspects of migrating from OpenVMS VAX to OpenVMS Alpha systems. The other manuals in this set are as follows:

• Migrating an Environment from OpenVMS VAX to OpenVMS Alpha describes how to migrate a computing environment from an OpenVMS VAX system to an OpenVMS Alpha system or a Mixed-Architecture Cluster. It provides an overview of the VAX to Alpha migration process and describes the differences in system and network management on VAX and Alpha computers.
• Porting VAX MACRO Code to OpenVMS Alpha describes how to port VAX MACRO code to an Alpha system using the MACRO--32 compiler for OpenVMS Alpha. It describes the features of the compiler, presents a methodology for porting VAX MACRO code, identifies nonportable coding practices, and recommends alternatives to such practices. The manual also provides a reference section with detailed descriptions of the compiler's qualifiers, directives, and built-ins, and the system macros created for porting to Alpha systems.
• Creating an OpenVMS Alpha Device Driver from an OpenVMS VAX Device Driver describes how to convert an OpenVMS VAX device driver to run on an OpenVMS Alpha system. The book identifies the specific changes required to prepare an OpenVMS VAX device driver to be compiled, linked, loaded, and run as an OpenVMS Alpha device driver. It also contains reference material about the entry points, system routines, data structures, and macros used in OpenVMS Alpha device drivers.

In addition, the DECmigrate for OpenVMS AXP Systems Translating Images manual describes the VAX Environment Software Translator (VEST) utility. This manual is distributed with the optional layered product, DECmigrate for OpenVMS Alpha, which supports the migration of OpenVMS VAX applications to OpenVMS Alpha systems. The manual describes how to use VEST to convert most user-mode VAX images to translated images that can run on Alpha systems; how to improve the run-time performance of translated images; how to use VEST to trace Alpha incompatibilities in a VAX image back to the original source files; and how to use VEST to support compatibility among native and translated run-time libraries. The manual also includes complete VEST command reference information.

In addition, the following general programming manuals contain current information on issues discussed here:

• VAX Architecture Reference Manual
• Alpha Architecture Reference Manual
• VAX/VMS Internals and Data Structures
• OpenVMS AXP Internals and Data Structures
• OpenVMS Programming Concepts Manual
• OpenVMS Programming Interfaces: Calling a System Routine
• Guide to DECthreads

For additional information on the Open Systems Software Group (OSSG) products and services, access the Digital OpenVMS World Wide Web site. Use the following URL:

http://www.openvms.digital.com 

Reader's Comments

Digital welcomes your comments on this manual.

Print or edit the online form SYS$HELP:OPENVMSDOC_COMMENTS.TXT and send us your comments by:

Internet	openvmsdoc@zko.mts.dec.com
Fax	603 881-0120, Attention: OSSG Documentation, ZK03-4/U08
Mail	OSSG Documentation Group, ZKO3-4/U08 110 Spit Brook Rd. Nashua, NH 03062-2698

How To Order Additional Documentation

Use the following table to order additional documentation or information. If you need help deciding which documentation best meets your needs, call 800-DIGITAL (800-344-4825).

Conventions

The name of the OpenVMS AXP operating system has been changed to the OpenVMS Alpha operating system. Any references to OpenVMS AXP or AXP are synonymous with OpenVMS Alpha or Alpha.

VMScluster systems are now referred to as OpenVMS Cluster systems. Unless otherwise specified, references to OpenVMS Clusters or clusters in this document are synonymous with VMSclusters.

In this manual, every use of DECwindows and DECwindows Motif refers to DECwindows Motif for OpenVMS software.

The following conventions are also used in this manual:

Ctrl/ x	A sequence such as Ctrl/ x indicates that you must hold down the key labeled Ctrl while you press another key or a pointing device button.
[Return]	In examples, a key name enclosed in a box indicates that you press a key on the keyboard. (In text, a key name is not enclosed in a box.)
...	Horizontal ellipsis points in examples indicate one of the following possibilities: Additional optional arguments in a statement have been omitted. The preceding item or items can be repeated one or more times. Additional parameters, values, or other information can be entered.
. . .	Vertical ellipsis points indicate the omission of items from a code example or command format; the items are omitted because they are not important to the topic being discussed.
( )	In command format descriptions, parentheses indicate that, if you choose more than one option, you must enclose the choices in parentheses.
[ ]	In command format descriptions, brackets indicate optional elements. You can choose one, none, or all of the options. (Brackets are not optional, however, in the syntax of a directory name in an OpenVMS file specification or in the syntax of a substring specification in an assignment statement.)
{ }	In command format descriptions, braces indicate a required choice of options; you must choose one of the options listed.
text style	This text style represents the introduction of a new term or the name of an argument, an attribute, or a reason. This style is also used to show user input in Bookreader versions of the book.
italic text	Italic text emphasizes important information, complete titles of manuals, or variables. Variables include information that varies in system output (Internal error number), in command lines (/PRODUCER= name), and in command parameters in text (where device-name contains up to five alphanumeric characters).
UPPERCASE TEXT	Uppercase text indicates a command, the name of a routine, the name of a file, or the abbreviation for a system privilege.
Monospace type	Monospace type indicates code examples and interactive screen displays. In the C programming language, monospace type in text identifies the following elements: keywords, the names of independently compiled external functions and files, syntax summaries, and references to variables or identifiers introduced in an example.
-	A hyphen at the end of a command format description, command line, or code line indicates that the command or statement continues on the following line.
numbers	All numbers in text are assumed to be decimal unless otherwise noted. Nondecimal radixes---binary, octal, or hexadecimal---are explicitly indicated.

For many applications, migrating from OpenVMS VAX to OpenVMS Alpha is straightforward. If your application runs only in user mode and is written in a standard high-level language, you most likely can recompile it with a native Alpha compiler and relink it to produce a version that runs successfully on an Alpha system. This book is intended to help you evaluate your application and to handle the relatively few cases that are more complicated.

1.1 Compatibility of VAX and Alpha Systems

The OpenVMS Alpha operating system is designed to preserve as much compatibility with the OpenVMS VAX user, system management, and programming environments as possible. For general users and system managers, OpenVMS Alpha has the same interfaces as OpenVMS VAX. For programmers, the goal is to come as close as possible to a "recompile, relink, and run" model for migration.

Many aspects of an application running on an OpenVMS VAX system remain unchanged on an Alpha system:

User Interface

• DIGITAL Command Language (DCL)
  The DIGITAL Command Language (DCL), the standard user interface to OpenVMS, remains essentially unchanged with OpenVMS Alpha. All commands, qualifiers, and lexical functions available on OpenVMS VAX also work on OpenVMS Alpha.
• Command Procedures
  Command procedures written for earlier versions of OpenVMS VAX continue to work on an Alpha system without change. However, certain command procedures, such as build procedures, must be changed to accommodate new compiler qualifiers and linker switches. Linker options files will also require modification, especially for shareable images.
• DECwindows
  The window interface, DECwindows Motif, is unchanged.
• DECforms
  The DECforms interface is unchanged.
• Editors
  The two standard OpenVMS editors, EVE and EDT, are unchanged.

System Management Interface

• The system management utilities are mostly unchanged. One major exception is that device configuration functions, which appear in the System Generation utility (SYSGEN) on VAX systems, are provided in the System Management utility (SYSMAN) for OpenVMS Alpha.

Programming Interface

• In general, the system service and run-time library (RTL) calling interfaces remain unchanged.¹ You do not need to change the definitions of arguments. The few differences fall into two categories:
  • Some system services and RTL routines (such as the memory management system and exception-handling services) operate somewhat differently on VAX and Alpha systems. See the OpenVMS System Services Reference Manual and the OpenVMS RTL Library (LIB$) Manual for further information.
  • A few RTL routines are so closely tied to the VAX architecture that their presence on an Alpha system would not be meaningful:

    Routine Name	Restriction
    LIB$DECODE_FAULT	Decodes VAX instructions.
    LIB$DEC_OVER	Applies to VAX Processor Status Longword (PSL) only.
    LIB$ESTABLISH	Similar functionality supported by compilers on Alpha systems.
    LIB$FIXUP_FLT	Applies to VAX PSL only.
    LIB$FLT_UNDER	Applies to VAX PSL only.
    LIB$INT_OVER	Applies to VAX PSL only.
    LIB$REVERT	Supported by compilers on Alpha systems.
    LIB$SIM_TRAP	Applies to VAX code.
    LIB$TPARSE	Requires action routine interface changes. Replaced by LIB$TABLE_PARSE.

  Most VAX images that call these services and routines will work when translated and run under the Translated Image Environment (TIE) on OpenVMS Alpha. For more information on TIE, see Section 3.2.2.1 and DECmigrate for OpenVMS AXP Systems Translating Images.

Data

• The on-disk format for ODS-2 data files is the same on VAX and Alpha systems. However, ODS-1 files are not supported on OpenVMS Alpha.
  Record Management Services (RMS) and file management interfaces are unchanged.
  The IEEE little-endian data types S_floating and T_floating have been added.
  Most VAX data types are retained in the Alpha architecture; however, support for H_floating and full-precision D_floating has been eliminated from hardware to improve overall system performance.
  Alpha hardware converts D_floating data to G_floating for processing. On VAX systems, D_floating has 56 fraction bits (D56) and 16 decimal digits of precision. On Alpha systems, D_floating has 53 fraction bits (D53) and 15 decimal digits of precision.
  The H_floating and D_floating data types can usually be replaced by G_floating or one of the IEEE formats. However, if you require H_floating or the extra precision of D56 (56-bit D_floating), you may have to translate part of your application.

Databases

• Standard Digital databases (such as Oracle Rdb) function the same on VAX and Alpha systems.

Network Interfaces

• VAX and Alpha systems both support the following interfaces:
  • Interconnects
    • Ethernet
    • X.25
    • FDDI
  • Protocols
    • DECnet (Phase IV in Version 7.1; Phase V in the optional DECnet-Plus kit)
    • TCP/IP
    • OSI
    • LAD/LAST
    • LAT (Local Area Transport)
  • Peripheral connections
    • TURBOchannel
    • SCSI
    • Ethernet
    • CI
    • DSSI
    • XMI
    • Futurebus/Plus
    • VME
    • PCI

Note

¹ Effective with Version 7.0, OpenVMS Alpha provided many system services and RTL routines to support 64-bit addressing. Because these are not available on VAX systems and are therefore not a VAX-to-Alpha migration issue, they are not discussed in this manual.

The VAX architecture is a robust, flexible, complex instruction set computer (CISC) architecture used across the entire family of VAX systems. The use of a single, integrated VAX architecture with the OpenVMS operating system permits an application to be developed on a VAXstation, prototyped on a small VAX system, and put into production on a large VAX processor or run on a fault-tolerant VAXft processor. The advantage of the VAX system approach is that it enables individual solutions to be tailored and fitted easily into a larger, enterprisewide solution. The hardware design of VAX processors is particularly suitable for high-availability applications, such as dependable applications for mission-critical business operations and server applications for a wide variety of distributed client/server environments.

The Alpha architecture implemented by Digital is a high-performance reduced instruction set computing (RISC) architecture that can provide 64-bit processing on a single chip. It processes 64-bit virtual and physical addresses and 64-bit integers and floating-point numbers. The 64-bit capability is especially useful for applications that require high-performance and very large addressing capacity. For example, Alpha processors are especially appropriate for graphics or numeric-intensive software applications such as econometric or weather forecasting that involve imaging, multimedia, visualization, simulation, and modeling.

The Alpha architecture is designed to be scalable and open. It can be implemented on a single chip in a palmtop system or with thousands of chips in a massively parallel supercomputer. The architecture is designed to support multiple operating systems, including OpenVMS Alpha.

Table 1-1 summarizes some major differences between the Alpha and VAX architectures.

Table 1-1 Comparison of Alpha and VAX Architectures

Alpha	VAX
64-bit addresses+ 64-bit processing Instructions Simple All same length (32 bits) Load/store memory access Severe penalty for unaligned data Many registers Out-of-order instruction completion Deep pipelines and branch prediction Large page size (which varies from 8 KB to 64 KB, depending on hardware)	32-bit addresses 32-bit processing Instructions Some complex Variable length Permits combining operations and memory access in a single instruction Moderate penalty for unaligned data Relatively few registers Instructions completed in order issued Limited use of pipelines Smaller page size (512 bytes)

General RISC Characteristics

Some features of the Alpha architecture are typical of newer RISC architectures in general. The following features are especially important:

• A simplified instruction set
  The Alpha architecture uses relatively simple instructions, all of which are 32 bits long. Common instructions require only one clock cycle. Uniformly sized simple instructions allow a RISC implementation to achieve high performance goals by adopting techniques such as multiple instruction issue and optimized instruction scheduling.
• Multiple instruction issue
  The earliest Alpha platform issued two instructions per clock cycle. Current machines (EV5 or higher) issue four instructions per clock cycle.
• A load/store operation model
  The Alpha architecture defines 32 64-bit integer registers and 32 64-bit floating-point registers. Most data manipulation occurs between registers. Typically, operands are loaded from memory into registers before an operation; after the operation, the results are stored in memory from a result register.
  Restricting operations to register operands allows the use of a simple, uniform instruction set. Moreover, the separation of memory access from arithmetic operations results in a large performance gain in a system that can fully exploit pipelining, instruction scheduling, and parallel operational units.
• Elimination of microcode
  Because the Alpha architecture does not use microcode, Alpha processors are saved the time required to fetch microcode instructions from random-access memory (RAM) in order to execute a machine instruction.
• Out-of-order completion of instructions
  The Alpha architecture does not require that instructions always complete in the order in which they are issued. As a result, an Alpha processor can improve performance by delaying the reporting of an arithmetic or floating-point exception until the execution stream allows the reporting without a performance penalty.

Alpha Specific Characteristics

Besides these generic RISC characteristics, the Alpha architecture offers features that promote running migrated VAX applications on an Alpha system. These features include:

• Hardware support for all VAX data types except packed decimal, H_floating, and D_floating. (For information on what to do if your application uses H_floating or D_floating data, see Section 2.5.2.)
• Certain privileged architecture features, such as four processor modes (user, supervisor, executive, and kernel), 32 interrupt priority levels (IPLs), and asynchronous system traps (ASTs).
• A privileged architecture library (PAL), part of an environment known as PALcode, that supports the atomic execution of certain VAX operations, such as Change Mode (CHMx), Probe (PROBEx), queue instructions, and REI.
  The Alpha architecture does not favor a particular operating system. To accommodate different operating systems, it enables the creation of privileged architecture library code (PALcode).
  Furthermore, certain OpenVMS Alpha compilers, such as C and the MACRO--32 compiler, provide PALcode built-ins that supplement the instructions available in the Alpha instruction set. For example, the MACRO--32 compiler provides built-ins that emulate those VAX instructions for which there are no Alpha equivalents.
  PALcode can be used to access internal hardware registers and physical memory. PALcode can provide direct correspondence of physical and virtual memory. For more information about PALcode, see the Alpha Architecture Reference Manual.

Formal support for user-written device drivers and a new interface known as the Step 2 driver interface were introduced in OpenVMS Alpha Version 6.1. The Step 2 driver interface supports user-written device drivers in the C programming language (as well as MACRO and BLISS). It replaced the temporary Step 1 driver interface that was provided in OpenVMS Alpha Versions 1.0 and 1.5. If you have an existing OpenVMS VAX device driver that you want to run on an Alpha system, and you have not made the changes required for OpenVMS Alpha Version 6.1, see Creating an OpenVMS Alpha Device Driver from an OpenVMS VAX Device Driver.

  6459P.HTM
  OSSG Documentation
  22-NOV-1996 13:07:01.12

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal