アプリケーションを実際にAlphaシステムに移行する作業は， 次に示すように複数の段階に分かれています。
ネイティブなAlpha環境は，VAXシステムと同様に完全な開発環境です
現在のところ，移行したアプリケーションのデバッグおよびテストは， Alphaシステム上で行わなければなりません。
Alpha移行環境の重要な要素はDECからサポートされ，DECはアプリケーションの変更， デバッグ，およびテストのために必要な支援を提供します。
移行のためにどのハードウェアが必要かを計画する場合， 複数の問題を検討しなければなりません。まず，通常の VAX開発環境でどのような資源が必要であるかを検討してください。
VAXシステムとAlphaシステムとの間で， コンパイルしたイメージとトランスレートしたイメージを比較してください。
望ましい構成は次のとおりです。
マルチプロセッサ・システムでは， 各プロセッサが別々のアプリケーションのイメージ分析を行うことができます。
コンピユータ資源が不足する場合には，次のいずれかの処置で対処してください。
効率のよい移行環境を構築するには，次の要素を確認しなければなりません。
VAXバージョンとAlphaバージョンのツールとファイルをそれぞれ適切に指すように， 論理名は矛盾のないように定義しなければなりません。詳しくは 第3.4節を参照してください。
これらのプロシージャは新しいツールおよび新しい環境に適合するように調整しなければなりません。
VAXで使用できる標準的な開発ツールはすべて， Alphaシステムでもネイティブ・ツールとして提供されています。
VESTソフトウェア・トランスレータはVAXシステムと Alphaシステムの両方で実行されます。 Translated Image Environment (TIE) はトランスレートされたイメージを実行するために必要な環境であり， OpenVMS Alphaの一部です。したがって， トランスレートされたイメージの最終的なテストは Alphaシステムで実行しなければなりません。
コードを完全に分析し，移行計画を適切に作成している場合には， この最終段階はかなり簡単に終了できます。 多くのプログラムはまったく変更せずに再コンパイルまたはトランスレートできます。 直接に再コンパイルまたはトランスレートできないプログラムでも，多くの場合， 簡単な変更だけでAlphaシステムで実行できるようになります。
コードの実際の変換についての詳しい説明は， OpenVMS Alphaの移行に関する次の解説書を参照してください。
これらの各解説書についての説明は，本書のまえがきを参照してください。
2つの移行環境と，各環境で使用される基本的なツールは， 図 3-1に示すとおりです。
一般に，アプリケーションを移行する場合には，コードの変更，コンパイル， リンク，およびデバッグを繰り返し実行しなければなりません。 これらの処理を実行することにより， 開発ツールから指摘されたすべての構文エラーとロジック・エラーを解決します。 通常，構文エラーは簡単に修正できますが，ロジック・エラーを修正するには， コードの大幅な変更が必要になります。
新しいコンパイラ・スイッチやリンカ・スイッチに対応するために， コンパイル・コマンドとリンク・コマンドは，ある程度変更しなければなりません。 たとえば，複数のAlphaプラットフォーム間で移植可能にするために，リンカは Alphaシステムの省略時のページ・サイズを64KBとして設定します。この結果， 各プロセッサのシステム・ページ・サイズとは無関係に， OpenVMS AlphaイメージはどのAlphaプロセッサでも実行可能になります。また， Alphaの共有可能イメージは， 普遍的なエントリ・ポイントとシンボルを宣言するために， VAX転送ベクタ・メカニズムではなく， リンカ・オプション・ファイル内のシンボル・ベクタ宣言を使用します。
Alphaプラットフォームでソフトウェアを開発し，移行するために， 多くのネイティブ・コンパイラとその他のツールが提供されます。
既存のVAXソースを再コンパイルおよび再リンクすると，ネイティブな Alphaイメージが作成され，このイメージは RISCアーキテクチャの性能上の利点をすべて利用して，Alpha環境で実行されます。 Alphaコードでは，一連の高度に最適化されたコンパイラを使用します。 これらのコンパイラは共通の最適化コード・ジェネレータを備えています。しかし， 各言語に対して異なるフロント・エンドを使用し， これらの各フロント・エンドは現在のVAXコンパイラと互換性があります。
OpenVMS Alphaオペレーティング・システムバージョン7.1では， 次の言語に対してネイティブなAlphaコンパイラが提供されています。
OpenVMS Alphaの将来のリリースでは， LISPも含めた他の言語のためのネイティブ・コンパイラも提供されます。
他の言語で作成されたユーザ・モードのVAXプログラムは， VESTを使用してトランスレートすることにより，Alphaシステムで実行できます。また， サード・パーティからも他の言語のためのコンパイラが提供されます。
一般に，Alphaコンパイラには， コマンド・ライン修飾子と言語セマンティックが準備されており， VAXアーキテクチャに依存するコードをほとんど変更せずに， Alphaシステムでも実行できるようにしています。このような VAXアーキテクチャへの依存のリストについては， 表 2-3を参照してください。
OpenVMS Alphaシステムの一部のコンパイラは， OpenVMS VAXシステムの対応するコンパイラでサポートされない新しい機能をサポートします。 互換性を維持するために，一部のコンパイラは互換性モードをサポートします。 たとえば，OpenVMS Alphaシステム用のDEC Cコンパイラでは， VAX C互換性モードをサポートし，このモードは /STANDARD=VAXC修飾子を指定することにより起動されます。
場合によっては，互換性が制限されます。たとえば，VAX Cでは，特殊な VAXハードウェア機能にアクセスできるようにするための組み込み関数をインプリメントしています。 VAXコンピュータのハードウェア・アーキテクチャは Alphaコンピュータのアーキテクチャと異なるため，これらの組み込み関数は， /STANDARD=VAXC修飾子を使用した場合でも，OpenVMS Alphaシステム用の DEC Cコンパイラでは使用できません。
また，コード内に存在する可能性のあるアーキテクチャに依存する部分をコンパイラである程度補正することもできます。 たとえば，MACRO-32コンパイラには/PRESERVE修飾子があり， 粒度と不可分性のどちらか一方または両方を維持できます。
DEC Cコンパイラにはヘッダ・ファイルがあり， 各データ型に対してマクロを定義しています。これらのマクロは， int64などの汎用データ型の名前を__int64などのマシン固有のデータ型に変換します。 たとえば，64ビットの長さのデータ型が必要な場合には，int64マクロを使用します。
移植性をサポートするすべての機能の詳細については， コンパイラのマニュアルを参照してください。
Alphaコンパイラを使用して，OpenVMS VAXプログラムを OpenVMS Alphaシステムに移行する処理の詳細については， 第11章を参照してください。
既存のVAX MACROコードをOpenVMS Alphaシステムで動作するマシン・コードに変換するには， MACRO-32 Compiler for OpenVMS Alphaを使用します。 OpenVMS Alphaにはその目的で，このコンパイラが含まれています。
一部のVAX MACROコードは変更せずにコンパイルできますが， 大部分のコード・モジュールでは，エントリ・ポイント指示文を追加する必要があります。 また，多くのコード・モジュールではその他の変更も必要です。
コンパイラはOpenVMS Alphaシステム用に最適化されたコードを生成しますが， 高レベルの制御機能をプログラマに提供するVAX MACRO言語の多くの機能は， OpenVMS Alphaシステム用の最適なコードを生成することを困難にします。 OpenVMS Alpha用に新たなプログラムを開発する場合には， 中級言語または高級言語を使用することをお勧めします。 MACRO-32コンパイラの詳細については， 『Porting VAX MACRO Code to OpenVMS Alpha』を参照してください。
- 注意
- MACRO-32コンパイラは，ソース・コードにLIB$ESTABLISHが含まれている場合には， それを呼び出そうとします。
MACRO-32プログラムが0(FP)のルーチン・アドレスを格納することにより， 動的ハンドラを確立する場合には，OpenVMS Alphaシステムでコンパイルしても， そのプログラムは正しく動作します。しかし， CALL_ENTRYルーチンの内部からでなければ，JSB (Jump to Subroutine) ルーチンの内部から条件ハンドラ・アドレスを設定することはできません。
ネイティブなAlphaイメージを作成するために， コンパイラの他にもいくつかのツールが提供されます。
OpenVMSリンカは，VAXオブジェクト・ファイルまたは Alphaオブジェクト・ファイルを受け付け，VAXイメージまたは Alphaイメージを作成できるようになりました。また，VAXハードウェアで Alphaイメージを作成できるため，クロス・リンカとして機能します。
OpenVMS Alphaで実行されるOpenVMSデバッガは，現在の OpenVMS VAXデバッガと同じコマンド・インターフェイスを使用します。 OpenVMS Alphaシステムでも， VAXシステム上のグラフィカル・インターフェイスが提供されています。
OpenVMSライブラリアン・ユーティリティは，VAXライブラリまたは Alphaライブラリを作成します。
OpenVMSメッセージ・ユーティリティを使用すれば， OpenVMSシステム・メッセージに独自のメッセージを追加できます。
OpenVMS Alphaシステム用のMACRO-64アセンブラは，すべての Alphaコンピュータを対象にしたネイティブ・アセンブラです。VAX MACROアセンブラは OpenVMS VAXオペレーティング・システムに含まれていますが，MACRO-64アセンブラは OpenVMS Alphaオペレーティング・システムに含まれていません。 このアセンブラは個別に購入できます。一般に， 中級言語および高級言語コンパイラは，MACRO-64アセンブラより性能の高いコードを OpenVMS Alphaシステム用に生成します。 OpenVMS Alphaシステム用に新たなプログラムを開発する場合には， 中級コンパイラまたは高級コンパイラのご使用をお勧めします。 MACRO-64アセンブラの詳細については， 『MACRO-64 Assembler for OpenVMS AXP Systems Reference Manual』 を参照してください。
ANALYZE/IMAGEユーティリティはVAXイメージまたはAlphaイメージを分析できます。
ANALYZE/OBJECTユーティリティはVAXオブジェクトまたは Alphaオブジェクトを分析できます。
DECsetは包括的なCASEツール群であり，Language Sensitive Editor (LSE)， Source Code Analyzer (SCA)，Code Management System (CMS)， Module Management System (MMS)をはじめ，多くの要素で構成されます。
Alphaシステムで実行するためにVAXイメージをトランスレートする処理については， 『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。 一般に，この処理は簡単ですが，エラーなしにトランスレートするには， コードを少し変更しなければならないことがあります。
ユーザ・モードのVAXイメージをOpenVMS Alphaに移行するための主なツールは， 静的トランスレータと実行時サポート環境です。
次の機能をサポートします。
トランスレートされたイメージを実行する場合には，TIEが自動的に起動されます。 TIEを呼び出す必要はありません。
VESTは，できるだけ多くのVAXコードをAlphaコードにトランスレートします。 TIEは，Alpha命令に変換できなかったVAXコードを解釈します。たとえば， 次のコードはTIEによって解釈されます。
命令の解釈は速度の遅い処理であり，おそらく平均的な1つのVAX命令に対して 100前後のAlpha命令が必要となるため， VESTは実行時にインタプリタを通じた解釈の必要性をできるだけ少なくするために， できるだけ多くのVAXコードをトランスレートしようとします。 トランスレートされたイメージは，ネイティブなAlphaイメージと比較すると，約 3分の1の速度で実行されます。ただし，この速度はTIEがどれだけの VAXコードを解釈しなければならないかに応じて異なります。トランスレートされた VAXイメージは，少なくともVAXハードウェアと同じ速度で実行されます (同じレベルのプロセス技術を使用したCPUの場合)。
AlphaシステムでVAXイメージの動的解釈を指定することはできません。 イメージをOpenVMS Alphaで実行するには，その前に VESTを使用してイメージをトランスレートしなければなりません。
VAXイメージをトランスレートすると， Alphaハードウェアで実行されるイメージが作成されます。このようにして作成される Alphaイメージは，単に VAXイメージを解釈したバージョンやエミュレートしたバージョンではなく，元の VAXイメージ内の命令が実行する操作と同じ操作を実行する Alpha命令を含むイメージです。Alphaの.EXEファイルには，元の VAXイメージが完全に登録されているため，TIEは VESTがトランスレートできなかったコードを解釈できます。
VESTの分析機能は，トランスレートする場合だけでなく， 再コンパイルする予定のプログラムを評価する場合も役立ちます。
VESTとTIEについての詳しい説明は，『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。このマニュアルでは， フローグラフなども含めて， VESTが作成するすべての出力とその解釈方法が詳しく説明されています。また， VESTが作成するイメージ情報ファイル(IIF)から提供される情報を利用して， トランスレートされたイメージの実行時の性能を向上する方法も説明されています。
アプリケーションをOpenVMS Alphaに移行した後，デバッグしなければなりません。
また，正しい操作が実行されるかどうかを調べるためにアプリケーションをテストすることも必要です。
OpenVMSオペレーティング・システムでは，次のデバッガが準備されています。
OpenVMSデバッガはシンボリック・デバッガです。つまり， このデバッガを使用する場合には，プログラムで使用しているシンボル (変数名やルーチン名，ラベルなど)によってプログラムの位置を参照できます。 プログラム位置を参照するために， メモリ・アドレスやマシン・レジスタを指定する必要はありません。ただし， メモリ・アドレスやマシン・レジスタを指定したい場合は，必要に応じて指定できます。
OpenVMSデバッガは通常，トランスレートされたイメージに対して動作しません。しかし， トランスレートされたイメージは内部でVAXレジスタをエミュレートしているので， SHOW CALLやSHOW STATEコマンドでデバッグに有用なVAXコンテキストを得ることができます。
Deltaデバッガはアドレス・ロケーション・デバッガです。つまり， このデバッガを使用する場合には， アドレス・ロケーションによってプログラム位置を参照しなければなりません。 このデバッガは主に，特権付きプロセッサ・ モードまたは高い割り込みレベルで実行されるプログラムをデバッグするために使用します。
デバッグはAlphaハードウェアで実行しなければなりません。
OpenVMS Alphaシステムでは，次の DEC言語で作成したプログラムに対してデバッガを使用できます。
OpenVMSデバッガには， OpenVMS Alphaコードのアーキテクチャ上の違いに対処する機能がいくつか含まれています。 これらの機能を使用すると， OpenVMS Alphaシステムに移植するコードを簡単にデバッグできるようになります。 たとえば，SETコマンドの/UNALIGNED_DATA修飾子を使用すると， アラインされていないデータにアクセスする命令(たとえば， ワード境界にないデータにアクセスするload word命令など)のすぐ後で， デバッガはブレークします。
どのルーチンでも，SETコマンドに/RETURN修飾子を指定できます。 OpenVMS VAXシステムの場合のように，CALLS命令や CALLG命令を使用して呼び出したルーチンに制限されません。 OpenVMS Alphaシステム固有の機能の詳細については，『OpenVMSデバッガ説明書』 を参照してください。
OpenVMSデバッガを使用して，移行したアプリケーションを Alphaシステムでデバッグする場合には，次のことを考慮しなければなりません。
DBG> %DEBUG-E-ACCESSR, no read access to address 00000000
OpenVMSデバッガによるデバッグについての詳しい説明は， 『OpenVMSデバッガ説明書』を参照してください。
Delta/XDeltaデバッガ(DELTA/XDELTA)はOpenVMS Alphaシステムで動作し， Alphaアーキテクチャで必要となる新しいコマンドを提供し，また， 既存のコマンドの一部も拡張しています。たとえば，ベース・レジスタの表示は 16進数ではなく，10進数で表示し，別のプロセスの内部プロセス識別 (PID)番号を確認する機能も追加されています。Delta/XDeltaデバッガが OpenVMS Alphaシステムでどのように動作するかについての詳しい説明は， 『OpenVMS Delta/XDelta Debugger Manual』を参照してください。
Deltaデバッガを使用すれば， 部分的または完全にトランスレートされたアプリケーションをデバッグできます。
トランスレートされたイメージをデバッグする場合には， 次のことを確認しなければなりません。
ネイティブなAlphaコードとトランスレートされたコードが混在するアプリケーションをデバッグするには， /TIE修飾子を使用してアプリケーションのネイティブな部分がコンパイルされているかどうかを確認しなければなりません。 さらに，/NONATIVE_ONLYリンカ・オプションを使用してアプリケーションをリンクしなければなりません。
Deltaデバッガによるデバッグについての詳しい説明は， 『OpenVMS Delta/XDelta Debugger Manual』を参照してください。
OpenVMS Alphaのシステムコード・デバッガは，任意の IPLで動作する非ページング・システム・コードとデバイス・ドライバをデバッグするために使用します。 OpenVMS Alphaのシステムコード・デバッガはシンボリック・デバッガです。 したがって，ソース・コードに指定するときと同様に，変数名， ルーチン名などを指定できます。また， ソフトウェアが実行しているソース・コードを表示し，ソース行を 1ステップずつ実行することもできます。
システムコード・デバッガを使用するには，2台のAlphaシステムが必要です。
このデバッガを使用すると，次の言語で作成されたコードをデバックできます。
OpenVMS Alphaのシステムコード・デバッガは，各言語の構文，データ型， 演算子，式，有効範囲に関する規則，その他の構造を認識します。 プログラムが複数の言語で作成されている場合には，デバッグ・セッションでデバッグ・ コンテキストを1つの言語から別の言語に変更できます。
- 注意
- BLISSコンパイラは，OpenVMS VAXバージョン7.1とOpenVMS Alphaバージョン 7.1に同梱されているOpenVMSフリーウェアCDに登録されています。
Step 2ドライバとOpenVMS Alphaシステムコード・デバッガの詳細については， 『Writing OpenVMS Alpha Device Drivers in C』を参照してください。
OpenVMSでは，システム・クラッシュを分析するために2つのツールを使用できます。 それはシステム・ダンプ・アナライザ (SDA)とクラッシュ・ダンプ・ユーティリティ・エクストラクタ(CLUE)です。
OpenVMS Alphaシステムのシステム・ダンプ・アナライザ(SDA)ユーティリティは， OpenVMS VAXシステムで提供されるユーティリティとほとんど同じです。 多くのコマンド，修飾子，表示は同一ですが， クラッシュ・ダンプ・ユーティリティ・エクストラクタ(CLUE) ユーティリティの機能にアクセスするためのいくつかのコマンドも含めて， コマンドと修飾子が追加されています。また， プロセッサ・レジスタやデータ構造体など OpenVMS Alphaシステム固有の情報を表示できるように， 一部の表示も変更されています。
SDAインタフェースは少しだけ変更されていますが，VAXとAlphaのダンプ・ファイルの内容と， ダンプからシステム・クラッシュを分析するための全体的な処理は， 2種類のコンピュータで少し違います。Alphaの実行パスは， VAXの実行パスの場合より複雑な構造体とパターンをスタックに残します。
VAXコンピュータでSDAを使用するには，まず，VAXシステムの OpenVMS呼び出し規則を十分理解しておく必要があります。同様に，Alphaシステムで SDAを使用するには，まず，Alphaシステムの OpenVMS呼び出し規則を十分理解しておかなければ， スタックでクラッシュのパターンを解読できるようになりません。
SDAは次のように変更されています。
クラッシュ・ログ・ユーティリティ・エクストラクタ(CLUE)は， クラッシュ・ダンプの履歴と，各クラッシュ・ダンプの重要なパラメータを記録し， 重要な情報を抽出して，要約するためのツールです。クラッシュ・ダンプは， システム・クラッシュが発生するたびに上書きされるため， 最新のクラッシュに対してだけしか使用できませんが，クラッシュ履歴ファイル (OpenVMS VAX)と， 各クラッシュに対して個別のリスト・ファイルを持つ要約クラッシュ履歴ファイル (OpenVMS Alpha)は，システム・クラッシュを永久的に記録します。
OpenVMS VAXとOpenVMS Alphaでのインプリメント上の相違点は， 表 3-1に示すとおりです。
| 属性 | OpenVMS VAX | OpenVMS Alpha |
|---|---|---|
| アクセス方式 | 独立したユーティリティとして起動される。 | SDAを通じてアクセスされる。 |
| 履歴ファイル | 各クラッシュのクラッシュ・ダンプ・ファイルから 1行の要約情報と詳細情報を格納した累積ファイル。 | 各クラッシュ・ダンプに対して 1行の要約だけを格納した累積ファイル。 各クラッシュの詳細情報は別のリスト・ファイルに格納される。 |
| クラッシュ・ダンプのデバッグの他の使い方 | なし。 | CLUEコマンドは会話方式で使用でき， 実行中のシステムを確認できる。 |
| ドキュメンテーション | 『OpenVMSシステム管理者マニュアル』と 『OpenVMSシステム管理ユーティリティ・リファレンス・マニュアル』の Bookreaderバージョン。 | 『OpenVMSシステム管理者マニュアル』 と『OpenVMS Alpha System Dump Analyzer Utility Manual』の Bookreaderバージョン。 |
移行されたアプリケーションをテストするには，次の操作が必要です。
ここでは，リグレッション・テストとストレス・テストが役立ちます。 ストレス・テストは， 同期に関するプラットフォームの相違点をテストするために特に重要です。特に， 複数の実行スレッドを使用するアプリケーションの場合は， ストレス・テストが役立ちます。
標準テストは， 移行したアプリケーションの機能を検証するためにかなり長くかかりますが， 移行固有の問題を調べるためのテストをいくつか追加しなければなりません。 特に次の点に注意してください。
最適化およびデータ・アラインメントの変更
たとえば命令の不可分性，メモリの不可分性，読み込み/書き込み順序などの変更
異なる言語で作成されたモジュールや， トランスレートしなければならなかったモジュールの統合
作業方法に何も問題がなく，移行に関するすべての指示に従っているにもかかわらず， OpenVMS VAXシステムでは問題が発生したことのないプログラムでバグを検出することがあります。 たとえば，VAXコンピュータでは， プログラムで一部の変数を初期化しないエラーが発生しても問題になりませんが， Alphaコンピュータでは演算例外が発生します。 2つのアーキテクチャでは使用できる命令が違い， コンパイラが命令を最適化する方法も変更されているため， 移行処理で同じような問題が発生する可能性があります。 これまで隠れていたバグをすべて解決できるような新しい方法はありませんが， プログラムを移植した後，他のユーザが実際に使用を開始する前に， プログラムを徹底的にテストする必要があります。
再コンパイルまたはトランスレーションによってアプリケーションを移行した後， 移行によって他のソフトウェアとのやりとりに問題が発生していないかどうかを確認しなければなりません。
VAXとAlphaシステム間の相互操作性に関する問題の原因として， 次のことが考えられます。
混在する環境では，アプリケーションが正しいバージョンを参照するかどうかに関して， 次のことを確認してください。