日本-日本語

製品  >  ソフトウェア  >  OpenVMS  >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS
ライブラリ

タイトルページ
目次
まえがき
第 1 章:VAX, AlphaおよびOpenVMS
第 2 章:移行プロセスの概要
第 3 章:アプリケーションの評価: モジュールの調査
第 4 章:移行方法の選択
第 5 章:移行計画の作成
第 6 章:アプリケーションの移行
付録 A :アプリケーション評価チェックリスト
付録 B :移行計画の例
用語集
索引
PDF
OpenVMS ホーム
OpenVMS AXP オペレーティング・システム | HPE 日本

OpenVMS AXP
オペレーティング・システム
OpenVMS AXP オペレーティング・システムへの移行:システム移行の手引き


目次 索引


第 3 章
アプリケーションの評価: アプリケーション・モジュールの調査

アプリケーションの評価を行えば,どのような作業が必要であるかを判断でき,移行計画を作成できます。つまり,次の質問に対する解答が得られます。

  • どのようにアプリケーションを移行するか

  • 移行のために必要な作業量,時間,およびコストはどの程度か

  • DECサービス(Alpha AXP Resource Center)を使用するかどうか

評価のプロセスは,次の3つの段階に分けることができます。

  1. 一般的なモジュールの確認と,他のソフトウェアに依存する部分の確認

  2. 移行に影響するコーディングの様式を判断するためのソース分析

  3. 移行方式の選択,つまり,ソース・コードから再構築するのか,トランスレートするのか

これらの各段階の評価を終了すれば,効果的な移行計画を作成するのに必要な情報を入手できます。

移行のためのアプリケーションの評価の第1段階は,何を移行するかを正確に判断することです。この段階では,アプリケーション自体を評価するだけでなく,アプリケーションを正しく実行するために,何が必要であるかも判断しなければなりません。アプリケーションの評価を開始するには,次のことを確認してください。

  • アプリケーションの各モジュール

    • メイン・プログラムのソース・モジュール

    • 共有可能イメージ

    • オブジェクト・モジュール

    • ライブラリ(オブジェクト・モジュール,共有可能イメージ,テキスト,またはマクロ)

    • データ・ファイルとデータベース

    • メッセージ・ファイル

  • アプリケーションが依存する他のソフトウェア

    • ランタイム・ライブラリ

    • DECレイヤード・プロダクト

    • サード・パーティ・プロダクト

    他のコードへの依存関係を調べる場合には,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とともに提供されるDECソフトウェア

    • RTL(ランタイム・ライブラリ)

    • 他の共有可能ライブラリ(shareable library)。たとえば,呼び出し可能なユーティリティ・ルーチンやアプリケーション・ライブラリ・ルーチンを提供するライブラリなどです。

  • DECレイヤード・プロダクト

    • コンパイラとコンパイラRTL

    • データベース・マネージャ

    • ネットワーク環境

  • サード・パーティ・プロダクト

    現在多くのサード・パーティ・アプリケーションが,OpenVMS AXPで実行可能です。各アプリケーションが移行されているかどうかかについては,各アプリケーションの提供業者にお問い合わせください。

ビルド・プロシージャとテストも含めて,アプリケーションと開発環境を移行する作業は,お客様が実行しなければなりません。

アプリケーションの各モジュールを評価した後,各モジュールとイメージの詳しい評価が必要になります。第 4 章 を参照してください。

第 4 章
移行方法の選択

アプリケーションのモジュールを調査した後,アプリケーションの各部分を移行する方法を決定しなければなりません。つまり,再コンパイルと再リンクを実行するのか,トランスレートするのかを判断しなければなりません。大部分のアプリケーションは再コンパイルし,再リンクするだけで移行できます。アプリケーションがユーザ・モードだけで実行され,標準的な高級言語で作成されている場合には,おそらく再コンパイルと再リンクだけで十分です。主な例外については,第 4.2 節 を参照してください。

この章では,移行のために追加作業が必要となる一部のアプリケーションで移行方法をどのように選択すればよいかについて説明します。この判断を下すには,アプリケーションの各部分でどの方法が可能であるかということと,各方法でどれだけの作業量が必要となるかということを,知っておかなければなりません。

注意

この章では,アプリケーションを移行するにあたって,可能な限り再コンパイル,再リンクを行い,イメージのトランスレーションについては,再コンパイル,再リンクできない部分に用いるか,移行の過程での一時的な処理のみに用いると仮定しています。

この後の節では,移行方法を選択するプロセスについて,その概要を説明します。このプロセスでは,次のステップを踏んでください。

  1. 2種類の移行方法のどちらを使用できるかを判断する

    ほとんどの場合,プログラムを再コンパイルおよび再リンクするか,VAX イメージをトランスレートすることができます。どちらか一方の移行方法だけしか使用できないケースについては,第 4.1 節 を参照してください。

  2. 再コンパイルに影響を与える可能性のあるアーキテクチャへの依存部分を識別する

    アプリケーションが全般的には再コンパイルに適している場合でも,Alpha AXPアーキテクチャと互換性のないVAXアーキテクチャの機能に依存するコードが含まれている可能性があります。

    第 4.2 節 では,これらの依存性について説明し,このような固有の機能に依存する部分を識別し,その問題を解決するのに必要な作業の種類と作業量を見積もるのに必要な情報を示します。

    第 4.3 節 では,アプリケーションの評価で発生した疑問点に答えるのに役立つツールと方法を説明します。

  3. 再コンパイルするのか,トランスレートするのかを決定する

    アプリケーションを評価した後,どの移行方法を使用するのかを決定しなければなりません。第 4.4 節 では,各方法の利点と欠点のバランスをとることにより,どちらの方法を使用するのかを判断する処理について説明します。

    プログラムを再コンパイルおよび再リンクできない場合や,VAXイメージがVAXアーキテクチャ固有の機能を使用している場合には,そのイメージをトランスレートしなければなりません。第 4.4.1 項 では,トランスレートされたイメージの互換性と性能を向上するための方法を説明しています。

アプリケーションの評価のプロセスは,図 4-1 のように表わすことができます。DECでは,この図に示されたアプリケーションの評価に役立つツールを提供しています。これらのツールは,移行プロセスの各段階の説明で,必要に応じてふれます。

図 4-1 プログラム・イメージの移行




ほとんどのアプリケーションは,ソース・コードの再コンパイルおよび再リンクと,イメージのトランスレートのどちらの方法を用いても移行が可能です。しかし,アプリケーションの設計に応じて,次に示すように,2種類の移行方法のどちらか一方だけしか使用できないことがあります。

  • 再コンパイルできないプログラム

    次のイメージはトランスレートしなければなりません。

    • OpenVMS AXPコンパイラがまだ提供されていないプログラミング言語で作成されたソフトウェア

      Ada,BASIC,C,C++,COBOL,FORTRAN,Pascal,PL/I,およびVAX MACROのネイティブ・コンパイラは,OpenVMS AXPバージョン6.1で提供されます。LISPを含む他の言語は,将来のリリースで提供されます。

    • ソース・コードを入手できない実行可能イメージと共有可能イメージ

    • H浮動小数点または56ビットのD浮動小数点データを必要とするプログラム

  • トランスレートできないイメージ

    次のイメージのソース・コードは再コンパイルおよび再リンクしなければなりません(変更も必要となる可能性があります)。

    • OpenVMS VAXバージョン4.0以前に作成されたイメージ

    • PDP-11互換モードを使用するイメージ

    • リンカ・オプションでベースを指定したイメージ

    • 現在,Alpha AXPアーキテクチャでサポートされていないコーディング方式を使用しているイメージ。このようなコードとしては,次のコードがあります。

      1. 内部アクセス・モードまたは高いIPLで実行されるコード

        (たとえば,デバイス・ドライバなど)

      2. システム空間のアドレスを直接参照するコード

      3. 解説書に説明されていないシステム・サービスを直接参照するコード

      4. スレッド・コードを使用するコード,たとえば,スタックを切り換えるコード

      5. VAXベクタ命令を使用するコード

      6. 特権付きVAX命令を使用するコード

      7. リターン・アドレスを調べたり,変更するコードや,プログラム・カウンタ(PC)をもとに,他の判断を下すコード

      8. 512バイトのサイズのメモリ・ページに依存するため,正確なアクセス違反動作に依存するコード

      9. ページ境界以外の境界に,グローバル・セクションをアラインするコード(たとえば,512バイトのメモリ・ページ・サイズに依存するコード)

      10. 大部分のVAX P0空間またはP1空間を使用するコード,トランスレートされたイメージの実行時サポート・ルーチンが使用する空間に敏感に反応するコード


    VESTは次のようなイメージもトランスレートできますが,トランスレートされたイメージの実行時の性能は,TIE が解釈しなければならないVAXコードの量が多いために低下します。

    • TIEによって実行時に作成されるコードを除き,それ自体を変更するVAXコードまたは実行時に作成されるVAXコードを含むイメージ。

    • 命令ストリームを調べるコードを含むイメージ。ただし,TIEが実行時にこのようなコードを解釈する場合を除きます。


    どのイメージをトランスレートできるかについての詳しい説明は,『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。



4.2 再コンパイルに影響を与えるコーディングの様式

多くのアプリケーション,特に標準のコーディング様式のみを使用しているアプリケーションや,移植性(portability)を念頭において作成されているアプリケーションはほとんど問題なく,OpenVMS VAXから OpenVMS AXPに移行できます。しかし,VAX固有の機能に依存し,その機能がAlpha AXPアーキテクチャと互換性のないようなアプリケーションを再コンパイルする場合には,ソース・コードを変更しなければなりません。次の例は,典型的な互換性のない機能を示しています。

  • VAXシステムで高い性能を実現したり,VAXアーキテクチャ固有の機能を利用するために使用されているVAX MACROアセンブリ言語

  • 特権付きコード

  • VAXアーキテクチャ固有の機能

これらの互換性のない機能がアプリケーションでまったく使用されていない場合には,この章のこの後の部分を読む必要はありません。

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システムでは解消されました。

  • RISCプロセッサでは,アセンブリ言語を使用しても性能が向上するわけではありません。Alpha AXPコンパイラ・セットに含まれているコンパイラなどのRISCコンパイラは,プログラマが手作業で最適化するより効率よく,もっと容易にアーキテクチャやインプリメントの特徴を利用して,最適化されたコードを生成できます。

  • 新しいシステム・サービスは,これまでアセンブリ言語を必要としていた一部の機能を実行できます。

MACROコードの移行についての詳しい説明は,『Migrating to an OpenVMS AXP System: Porting VAX MACRO Code』を参照してください。

4.2.2 特権付きコード

内部アクセス・モード(カーネル,エグゼクティブ,またはスーパーバイザ・モード)で実行されたり,システム空間を参照するVAXコードは,VAXアーキテクチャに依存したコーディング様式を使用している可能性が高く,また,OpenVMS AXPには存在しないVAXデータ呼び出しを参照している可能性があります。このようなコードは,変更しなければ AXP システムに移行できません。これらのプログラムは再コーディング,再コンパイル,および再リンクが必要です。

この種類に分類されるコードは次のとおりです。

  • ユーザ作成システム・サービスや他の特権付き共有可能イメージ(privileged shareable image)

    詳しくは,『OpenVMS Programming Concepts Manual』と『OpenVMS Linker Utility Manual』を参照してください。

  • DEC以外から提供されたデバイス・ドライバとパフォーマンス・モニタ

  • 特殊な特権を使用するコード。たとえば,$CMEXECまたは$CMKRNLシステム・サービスを使用するコードや,PFNMAPオプションを選択して$CRMPSCシステム・サービスを使用するコード

    詳しくは,『 OpenVMS AXP オペレーティング・システムへの移行:再コンパイルと再リンク』を参照してください。

  • 次のように,OpenVMSの内部ルーチンまたはデータを使用するコード

    • システム・アドレス空間をアクセスするためにシステム・シンボル・テーブル(SYS.STB)に対してリンクするコード

    • SYS$LIBRARY:LIBを用いてコンパイルするコード

OpenVMSエグゼクティブを参照する内部モード・コードを移行する場合には,DECサービス(Alpha AXP Resource Center)にご連絡ください。

4.2.3 VAXアーキテクチャ固有の特徴

高い性能を実現するために,Alpha AXPアーキテクチャはVAXアーキテクチャと大きく異なっています。したがって,VAXアーキテクチャ固有の特徴を利用してコードを作成することに慣れているソフトウェア開発者は,AXP システムに正しく移行するために,コードで使用しているアーキテクチャ固有の特徴を理解しておかなければなりません。

この後の節では,一般的なアーキテクチャ固有の特徴と,それらの特徴を識別する方法および対処方法について簡単に説明します。これらのアーキテクチャ固有の特徴の識別方法と対処方法についての詳しい説明は,『 OpenVMS AXP オペレーティング・システムへの移行:再コンパイルと再リンク』を参照してください。

VAXアーキテクチャとAlpha AXPアーキテクチャの相違点のうち,次の2つは VAXアプリケーションをOpenVMS AXPで実行不可能にするものではありませんが,性能に大きな影響を与えます。

  • データ・アラインメント(alignment)

  • データ型の選択


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項