| 前へ | 次へ | 目次 | 索引 |
アプリケーションを調査し，移行方法が決まったら，移行計画を作成します。移行計画では，移植性に関する問題と，ハードウェアおよびソフトウェアへの依存に関する問題も含めて，アプリケーションの技術的な分析結果を詳しく記述し，各移行段階の概要を示し，移行に関する各作業を誰が実行するかを指定します。移行計画に記述した情報は，アプリケーションの将来の移植性と，性能を向上するための最適化の可能性に関して，技術的およびビジネス的な判断を下すのに役立ちます。
この章では，典型的な移行計画の概要を示します。移行計画の具体的な例については，付録 B を参照してください。
移行の概要。移行作業の目標を記述し，機能，品質，納期，および性能上の目標を設定します。アプリケーションが現在実行されている主なプラットフォームを列記し，アプリケーションで使用されている言語も示します。また，アプリケーションの依存性やリスクが，移行目標や移行の完了にどのような影響を与えるかを記述します。最後に，必要となる資源と完了予定日も指定します。
名前，所有者
アプリケーションが何を実行するのか
他のリリース計画との関係も指定します。
トランスレーションの使用目的
この部分では，イメージ分析とソース分析の結果をもとに，アプリケーションを OpenVMS AXPに移行するための作業範囲を定義します。
これはアプリケーションの一般的な記述であり，アプリケーションに含まれるイメージの数，プロシージャの数，データ・ファイルの数，コードの行数とモジュール数，使用されている言語と各言語の割合および特定の機能，VAX MACROが使用されている場合はその理由，アプリケーションが一般に移植可能であるのか，VAXアーキテクチャに依存しているのか，アプリケーションを実行または変更するために特殊なハードウェアまたはソフトウェアが必要かも記述します。
どのようなソース分析を実行したかと，検出された問題点の一般的な説明。
付録 A に示した質問を使用してください。
次の各要素に対してアプリケーションが依存しているかどうかを記述してください。
移行の中間目標を示し，スケジュールを決定します。
移行の各段階で対処する問題を示し，これを前に示した中間目標と比較します。主な問題に対処する順序，それらの問題に対処する人，およびその場所を指定します。さらに DECの移行サービスを利用するかどうかも決定します。
次の例を参照してください。
必要に応じて次の情報も指定してください。
移行の各段階で必要となる作業量
他のソフトウェア，ハードウェア，他の組織からのサポート
アプリケーションを実際にAXPシステムに移行する作業は，次に示すように複数の段階に分かれています。
ネイティブなAXP環境は，VAXシステムと同様に完全な開発環境です(しかし，いくつかのDECのコンパイラは，現在のところAXPシステム上で使用できません)。
現在のところ，移行したアプリケーションのデバッグおよびテストは，AXPシステム上で行わなければなりません。
Alpha AXP移行環境の重要な要素はDECからサポートされ，DECはアプリケーションの変更，デバッグ，およびテストのために必要な支援を提供できます。
6.1.1 ハードウェア
移行のためにどのハードウェアが必要かを計画する場合，複数の問題を検討しなければなりません。まず，通常のVAX開発環境でどのような資源が必要であるかを検討してください。
AXP移行環境にとって必要な資源を見積もるには，次の問題を考慮しなければなりません。
VAXシステムとAXPシステムとの間で，コンパイルしたイメージとトランスレートしたイメージを比較してください。
VESTを使用すると，多くのCPU時間が必要となります(実際に必要なCPU時間を予測することは困難です。これは，必要なCPU時間は，アプリケーションのサイズよりもアプリケーションの複雑さに大きく依存するからです)。また，VESTを使用する場合，ログ・ファイルのためのディスク空間，AXPイメージのためのディスク空間，フローグラフのためのディスク空間などが大量に必要になります。新しいイメージには，元のVAX命令と新しい Alpha AXP命令の両方が含まれます。したがって，元のVAXイメージより必ず大きくなります。
望ましい構成は次のとおりです。
マルチプロセッサ・システムでは，各プロセッサが別々のアプリケーションのイメージ分析を行うことができます。
コンピユータ資源が不足する場合には，次のいずれかの処置で対処してください。
効率のよい移行環境を構築するには，次の要素を確認しなければなりません。
次のツールも含めて，互換性のある移行ツールが必要です。
VAXバージョンとAXPバージョンのツールとファイルをそれぞれ適切に指すように，論理名は矛盾のないように定義しなければなりません。詳しくは 第 6.4 節 を参照してください。
これらのプロシージャは新しいツールおよび新しい環境に適合するように調整しなければなりません。
VAXで使用できる標準的な開発ツールはすべて，AXPシステムでもネイティブ・ツールとして提供されています。
VESTソフトウェア・トランスレータはVAXシステムとAXPシステムの両方で実行されます。Translated Image Environment(TIE)はトランスレートされたイメージを実行するために必要な環境であり，OpenVMS AXPの一部です。したがって，トランスレートされたイメージの最終的なテストはAXPシステムで実行しなければなりません。
6.2 アプリケーションの変換
コードを完全に分析し，移行計画を適切に作成している場合には，この最終段階はかなり簡単に終了できます。多くのプログラムはまったく変更せずに再コンパイルまたはトランスレートできます。直接に再コンパイルまたはトランスレートできないプログラムでも，多くの場合，簡単な変更だけでAXPシステムで実行できるようになります。
コードの実際の変換についての詳しい説明は，OpenVMS AXPの移行に関する次の解説書を参照してください。
これらの各解説書についての説明は，本書のまえがきを参照してください。
2つの移行環境と，各環境で使用される基本的なツールは，図 6-1 に示すとおりです。
図 6-1 移行環境とツール
一般に，アプリケーションを移行する場合には，コードの変更，コンパイル，リンク，およびデバッグを繰り返し実行しなければなりません。これらの処理を実行することにより，開発ツールから指摘されたすべての構文エラーとロジック・エラーを解決します。通常，構文エラーは簡単に修正できますが，ロジック・エラーを修正するには，コードの大幅な変更が必要になります。
新しいコンパイラ・スイッチやリンカ・スイッチに対応するために，コンパイル・コマンドとリンク・コマンドは，ある程度変更しなければなりません。たとえば，複数のAXPプラットフォーム間で移植可能にするために，リンカは AXPシステムの省略時のページ・サイズを64KBとして設定します。この結果，各プロセッサのシステム・ページ・サイズとは無関係に，OpenVMS AXPイメージはどのAXPプロセッサでも実行可能になります。また，AXPの共有可能イメージは，普遍的なエントリ・ポイントとシンボルを宣言するために，VAX転送ベクタ・メカニズムではなく，リンカ・オプション・ファイル内のシンボル・ベクタ宣言を使用します。
AXPプラットフォームでソフトウェアを開発し，移行するために，多くのネイティブ・コンパイラとその他のツールが提供されます。
6.2.1.1 ネイティブなAXPコンパイラ
既存のVAXソースを再コンパイルおよび再リンクすると，ネイティブなAXPイメージが作成され，このイメージはRISCアーキテクチャの性能上の利点をすべて利用して，AXP環境で実行されます。AXPコードでは，一連の高度に最適化されたコンパイラを使用します。これらのコンパイラは共通の最適化コード・ジェネレータを備えています。しかし，各言語に対して異なるフロント・エンドを使用し，これらの各フロント・エンドは現在のVAXコンパイラと互換性があります。
OpenVMS AXPオペレーティング・システムバージョン6.1では，次の言語に対してネイティブなAXPコンパイラが提供されています。
OpenVMS AXPの将来のリリースでは，LISPも含めた他の言語のためのネイティブ・コンパイラも提供されます。
他の言語で作成されたユーザ・モードのVAXプログラムは，VESTを使用してトランスレートすることにより，AXPシステムで実行できます。また，サード・パーティからも他の言語のためのコンパイラが提供されます。
一般に，AXPコンパイラには，コマンド・ライン修飾子と言語セマンティックが準備されており，VAXアーキテクチャに依存するコードをほとんど変更せずに，AXPシステムでも実行できるようにしています。このようなVAXアーキテクチャへの依存のリストについては，表 4-2 を参照してください。詳しい説明は，『 OpenVMS AXP オペレーティング・システムへの移行：再コンパイルと再リンク』を参照してください。
VAXプログラムをAXPシステムに移行するために，AXPコンパイラを使用する方法についての説明は，『 OpenVMS AXP オペレーティング・システムへの移行：再コンパイルと再リンク』を参照してください。
6.2.1.2 その他の開発ツール
ネイティブなAXPイメージを作成するために，コンパイラの他にもいくつかのツールが提供されます。
OpenVMS リンカは，VAXオブジェクト・ファイルまたはAXPオブジェクト・ファイルを受け付け，VAXイメージまたはAXPイメージを作成できるようになりました。また，VAXハードウェアでAXPイメージを作成できるため，クロス・リンカとして機能します。
OpenVMS AXPで実行されるOpenVMS デバッガは，現在のOpenVMS VAXデバッガと同じコマンド・インターフェイスを使用します。OpenVMS AXPシステムでも，VAXシステム上のグラフィカル・インターフェイスが提供されています。
OpenVMS メッセージ・ユーティリティを使用すれば，OpenVMSシステム・メッセージに独自のメッセージを追加できます。
DECsetは包括的なCASEツール群であり，Language Sensitive Editor(LSE)，Source Code Analyzer(SCA)，Code Management System(CMS)，Module Management System(MMS)をはじめ，多くの要素で構成されます。
AXPシステムで実行するためにVAXイメージをトランスレートする処理については，『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。一般に，この処理は簡単ですが，エラーなしにトランスレートするには，コードを少し変更しなければならないことがあります。
6.2.2.1 VAX Environment Software Translator(VEST)と Translated Image Environment(TIE)
ユーザ・モードのVAXイメージをOpenVMS AXPに移行するための主なツールは，静的トランスレータと実行時サポート環境です。
VESTは，できるだけ多くのVAXコードをAXPコードにトランスレートします。TIEは，Alpha AXP命令に変換できなかったVAXコードを解釈します。たとえば，次のコードはTIEによって解釈されます。
命令の解釈は速度の遅い処理であり，おそらく平均的な1つのVAX命令に対して100前後の Alpha AXP命令が必要となるため，VESTは実行時にインタプリタを通じた解釈の必要性をできるだけ少なくするために，できるだけ多くのVAXコードをトランスレートしようとします。トランスレートされたイメージは，ネイティブなAXPイメージと比較すると，約3分の1の速度で実行されます。ただし，この速度はTIEがどれだけのVAXコードを解釈しなければならないかに応じて異なります。トランスレートされたVAXイメージは，少なくともVAXハードウェアと同じ速度で実行されます(同じレベルのプロセス技術を使用したCPUの場合)。
AXPシステムでVAXイメージの動的解釈を指定することはできません。イメージを OpenVMS AXPで実行するには，その前にVESTを使用してイメージをトランスレートしなければなりません。
VAXイメージをトランスレートすると，AXPハードウェアで実行されるイメージが作成されます。このようにして作成されるAXPイメージは，単にVAXイメージを解釈したバージョンやエミュレートしたバージョンではなく，元のVAXイメージ内の命令が実行する操作と同じ操作を実行するAlpha AXP命令を含むイメージです。AXPの .EXEファイルには，元のVAXイメージが完全に登録されているため，TIEはVESTがトランスレートできなかったコードを解釈できます。
VESTの分析機能は，トランスレートする場合だけでなく，再コンパイルする予定のプログラムを評価する場合も役立ちます。
VESTとTIEについての詳しい説明は，『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。このマニュアルでは，フローグラフなども含めて，VESTが作成するすべての出力とその解釈方法が詳しく説明されています。また，VESTが作成するイメージ情報ファイル(IIF)から提供される情報を利用して，トランスレートされたイメージの実行時の性能を向上する方法も説明されています。
| 前へ | 次へ | 目次 | 索引 |