| 前へ | 次へ | 目次 | 索引 |
アプリケーションの評価を行えば，どのような作業が必要であるかを判断でき，移行計画を作成できます。つまり，次の質問に対する解答が得られます。
これらの各段階の評価を終了すれば，効果的な移行計画を作成するのに必要な情報を入手できます。
移行のためのアプリケーションの評価の第1段階は，何を移行するかを正確に判断することです。この段階では，アプリケーション自体を評価するだけでなく，アプリケーションを正しく実行するために，何が必要であるかも判断しなければなりません。アプリケーションの評価を開始するには，次のことを確認してください。
他のコードへの依存関係を調べる場合には，VESTと/DEPENDENCY修飾子を使用してください。VEST/DEPENDENCYは，アプリケーションが依存している実行可能イメージや共有可能イメージを示します。たとえば，ランタイム・ライブラリやシステム・サービス，その他のアプリケーションを識別します。VEST/DEPENDENCYの使い方についての詳しい説明は，『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。
アプリケーションを実行および管理するために，どのような種類のシステムが必要か。たとえば，必要なメモリ・サイズ，必要なディスク空間などです。
このプロシージャは，Code Management System(CMS)や Module Management System(MMS)などのDigital tools を必要とします。
移行したアプリケーションが正しく動作するかどうかを確認し，その性能を評価するために，テストが必要です。
これらの多くは，すでにOpenVMS AXPに移行されています。たとえば，次のソフトウェアやライブラリはすでに移行されています。
現在多くのサード・パーティ・アプリケーションが，OpenVMS AXPで実行可能です。各アプリケーションが移行されているかどうかかについては，各アプリケーションの提供業者にお問い合わせください。
ビルド・プロシージャとテストも含めて，アプリケーションと開発環境を移行する作業は，お客様が実行しなければなりません。
アプリケーションの各モジュールを評価した後，各モジュールとイメージの詳しい評価が必要になります。第 4 章 を参照してください。
アプリケーションのモジュールを調査した後，アプリケーションの各部分を移行する方法を決定しなければなりません。つまり，再コンパイルと再リンクを実行するのか，トランスレートするのかを判断しなければなりません。大部分のアプリケーションは再コンパイルし，再リンクするだけで移行できます。アプリケーションがユーザ・モードだけで実行され，標準的な高級言語で作成されている場合には，おそらく再コンパイルと再リンクだけで十分です。主な例外については，第 4.2 節 を参照してください。
この章では，移行のために追加作業が必要となる一部のアプリケーションで移行方法をどのように選択すればよいかについて説明します。この判断を下すには，アプリケーションの各部分でどの方法が可能であるかということと，各方法でどれだけの作業量が必要となるかということを，知っておかなければなりません。
この章では，アプリケーションを移行するにあたって，可能な限り再コンパイル，再リンクを行い，イメージのトランスレーションについては，再コンパイル，再リンクできない部分に用いるか，移行の過程での一時的な処理のみに用いると仮定しています。 |
この後の節では，移行方法を選択するプロセスについて，その概要を説明します。このプロセスでは，次のステップを踏んでください。
ほとんどの場合，プログラムを再コンパイルおよび再リンクするか，VAX イメージをトランスレートすることができます。どちらか一方の移行方法だけしか使用できないケースについては，第 4.1 節 を参照してください。
アプリケーションが全般的には再コンパイルに適している場合でも，Alpha AXPアーキテクチャと互換性のないVAXアーキテクチャの機能に依存するコードが含まれている可能性があります。
第 4.2 節 では，これらの依存性について説明し，このような固有の機能に依存する部分を識別し，その問題を解決するのに必要な作業の種類と作業量を見積もるのに必要な情報を示します。
第 4.3 節 では，アプリケーションの評価で発生した疑問点に答えるのに役立つツールと方法を説明します。
アプリケーションを評価した後，どの移行方法を使用するのかを決定しなければなりません。第 4.4 節 では，各方法の利点と欠点のバランスをとることにより，どちらの方法を使用するのかを判断する処理について説明します。
プログラムを再コンパイルおよび再リンクできない場合や，VAXイメージがVAXアーキテクチャ固有の機能を使用している場合には，そのイメージをトランスレートしなければなりません。第 4.4.1 項 では，トランスレートされたイメージの互換性と性能を向上するための方法を説明しています。
アプリケーションの評価のプロセスは，図 4-1 のように表わすことができます。DECでは，この図に示されたアプリケーションの評価に役立つツールを提供しています。これらのツールは，移行プロセスの各段階の説明で，必要に応じてふれます。
ほとんどのアプリケーションは，ソース・コードの再コンパイルおよび再リンクと，イメージのトランスレートのどちらの方法を用いても移行が可能です。しかし，アプリケーションの設計に応じて，次に示すように，2種類の移行方法のどちらか一方だけしか使用できないことがあります。
次のイメージはトランスレートしなければなりません。
Ada，BASIC，C，C++，COBOL，FORTRAN，Pascal，PL/I，およびVAX MACROのネイティブ・コンパイラは，OpenVMS AXPバージョン6.1で提供されます。LISPを含む他の言語は，将来のリリースで提供されます。
次のイメージのソース・コードは再コンパイルおよび再リンクしなければなりません(変更も必要となる可能性があります)。
(たとえば，デバイス・ドライバなど)
VESTは次のようなイメージもトランスレートできますが，トランスレートされたイメージの実行時の性能は，TIE が解釈しなければならないVAXコードの量が多いために低下します。
どのイメージをトランスレートできるかについての詳しい説明は，『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。
多くのアプリケーション，特に標準のコーディング様式のみを使用しているアプリケーションや，移植性(portability)を念頭において作成されているアプリケーションはほとんど問題なく，OpenVMS VAXから OpenVMS AXPに移行できます。しかし，VAX固有の機能に依存し，その機能がAlpha AXPアーキテクチャと互換性のないようなアプリケーションを再コンパイルする場合には，ソース・コードを変更しなければなりません。次の例は，典型的な互換性のない機能を示しています。
これらの互換性のない機能がアプリケーションでまったく使用されていない場合には，この章のこの後の部分を読む必要はありません。
4.2.1 VAX MACROアセンブリ言語
AXPシステムでは，VAX MACROはアセンブリ言語ではなく，コンパイラの1つでしかありません。しかし，高級言語のためのAlpha AXPコンパイラと異なり，VAX MACRO--32 Compiler for OpenVMS AXPは常に高度に最適化されたコードを生成するわけではありません。したがって，VAX MACRO--32 Compiler for OpenVMS AXPは移行の補助手段としてのみ使用するようにし，新しいコードを作成する場合は使用しないでください。
VAXシステムでアセンブリ言語を使用しなければならなかった多くの理由は，次のように，AXPシステムでは解消されました。
MACROコードの移行についての詳しい説明は，『Migrating to an OpenVMS AXP System: Porting VAX MACRO Code』を参照してください。
4.2.2 特権付きコード
内部アクセス・モード(カーネル，エグゼクティブ，またはスーパーバイザ・モード)で実行されたり，システム空間を参照するVAXコードは，VAXアーキテクチャに依存したコーディング様式を使用している可能性が高く，また，OpenVMS AXPには存在しないVAXデータ呼び出しを参照している可能性があります。このようなコードは，変更しなければ AXP システムに移行できません。これらのプログラムは再コーディング，再コンパイル，および再リンクが必要です。
この種類に分類されるコードは次のとおりです。
詳しくは，『OpenVMS Programming Concepts Manual』と『OpenVMS Linker Utility Manual』を参照してください。
詳しくは，『 OpenVMS AXP オペレーティング・システムへの移行：再コンパイルと再リンク』を参照してください。
OpenVMSエグゼクティブを参照する内部モード・コードを移行する場合には，DECサービス(Alpha AXP Resource Center)にご連絡ください。
4.2.3 VAXアーキテクチャ固有の特徴
高い性能を実現するために，Alpha AXPアーキテクチャはVAXアーキテクチャと大きく異なっています。したがって，VAXアーキテクチャ固有の特徴を利用してコードを作成することに慣れているソフトウェア開発者は，AXP システムに正しく移行するために，コードで使用しているアーキテクチャ固有の特徴を理解しておかなければなりません。
この後の節では，一般的なアーキテクチャ固有の特徴と，それらの特徴を識別する方法および対処方法について簡単に説明します。これらのアーキテクチャ固有の特徴の識別方法と対処方法についての詳しい説明は，『 OpenVMS AXP オペレーティング・システムへの移行：再コンパイルと再リンク』を参照してください。
4.2.3.1 性能に関する問題
VAXアーキテクチャとAlpha AXPアーキテクチャの相違点のうち，次の2つは VAXアプリケーションをOpenVMS AXPで実行不可能にするものではありませんが，性能に大きな影響を与えます。
| 前へ | 次へ | 目次 | 索引 |