日本-日本語

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

OpenVMS マニュアル


≫ 

OpenVMS V8.3
ライブラリ

タイトルページ
目次
まえがき
第 1 章:移行プロセスの概要
第 2 章:移行方法の選択
第 3 章:アプリケーションの移行
第 4 章:再コンパイルと再リンクの概要
第 5 章:ページ・サイズの拡大に対するアプリケーションの対応
第 6 章:共有データの整合性の維持
第 7 章:アプリケーション・データ宣言の移植性の確認
第 8 章:アプリケーション内の条件処理コードの確認
第 9 章:アプリケーションのトランスレート
第 10 章: ネイティブなイメージとトランスレートされたイメージの間の相互操作性の確認
第 11 章:OpenVMS Alpha コンパイラ
付録 A :アプリケーション評価チェックリスト
用語集
索引
PDF
OpenVMS ホーム
OpenVMS Alpha オペレーティング・システム | HPE 日本(日本ヒューレット・パッカード株式会社)

OpenVMS Alpha
オペレーティング・システム
OpenVMS VAX から OpenVMS Alpha へのアプリケーションの移行


目次 索引

第 2 章
移行方法の選択

アプリケーションの評価を行えば,どのような作業が必要であるかを判断でき,移行計画を作成することができます。

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

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

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

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

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

2.1 移行のための棚卸し

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

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

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

    • 共有可能イメージ

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

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

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

    • メッセージ・ファイル

    • CLD ファイル

    • DECwindows サポートのための UIL ファイルと UID ファイル

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

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

    • 弊社のレイヤード・プロダクト

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

    他のコードへの依存関係を調べる場合には,VESTと/DEPENDENCY修飾子を使用してください。VEST/DEPENDENCYは,アプリケーションが依存している実行可能イメージや共有可能イメージを示します。たとえば,ランタイム・ライブラリやシステム・サービス,その他のアプリケーションを識別します。VEST/DEPENDENCYの使い方についての詳しい説明は,『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。

  • 必要な操作環境

    • システム属性
      アプリケーションを実行および管理するために,どのような種類のシステムが必要か。たとえば,必要なメモリ・サイズ,必要なディスク空間などです。

    • ビルド・プロシージャ
      このプロシージャは,Code Management System (CMS)や Module Management System (MMS)などの Digital tool を必要とします。

    • テスト・スーツ
      移行したアプリケーションが正しく動作するかどうかを確認し,その性能を評価するために,テストが必要です。

これらの多くは,すでにOpenVMS Alphaに移行されています。たとえば,次のソフトウェアやライブラリはすでに移行されています。

  • OpenVMSとともに提供される弊社のソフトウェア

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

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

  • 弊社のレイヤード・プロダクト

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

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

    • ネットワーク環境

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

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

2.2 移行方法の選択

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

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

注意

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

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

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

  2. 再コンパイルに影響を与える可能性のあるアーキテクチャへの依存部分を識別する
    アプリケーションが全般的には再コンパイルに適している場合でも,Alpha アーキテクチャと互換性のないVAXアーキテクチャの機能に依存するコードが含まれている可能性があります。
    第 2.4 節 では,これらの依存性について説明し,このような固有の機能に依存する部分を識別し,その問題を解決するのに必要な作業の種類と作業量を見積もるのに必要な情報を示します。
    第 2.6 節 では,アプリケーションの評価で発生した疑問点に答えるのに役立つツールと方法を説明します。

  3. 再コンパイルするのか,トランスレートするのかを決定する
    アプリケーションを評価した後,どの移行方法を使用するのかを決定しなければなりません。 第 2.7 節 では,各方法の利点と欠点のバランスをとることにより,どちらの方法を使用するのかを判断する処理について説明します。
    プログラムを再コンパイルおよび再リンクできない場合や,VAXイメージがVAX アーキテクチャ固有の機能を使用している場合には,そのイメージをトランスレートしなければなりません。 第 2.7.1 項 では,トランスレートされたイメージの互換性と性能を向上するための方法を説明しています。

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


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

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

  • 再コンパイルできないプログラム
    次のイメージはトランスレートしなければなりません。

    • OpenVMS Alphaコンパイラがまだ提供されていないプログラミング言語で作成された VAX SCAN や Dibol のようなソフトウェア

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

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

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

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

    • OpenVMS VAXバージョン5.5-2以降に作成されたイメージ。トランスレートされた RTLとシステム・サービスがそれ以来更新されていない場合

    • Ada で書かれたイメージ

    • Ada で書かれたイメージによって呼び出される/呼び出されたイメージ

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

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

    • VAXアーキテクチャ用のコーディング方式を使用しているイメージ。このようなコードとしては,次のコードがあります。

      • 内部アクセス・モードまたは高いIPLで実行されるコード (たとえば,VAX デバイス・ドライバなど)

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

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

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

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

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

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

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

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

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


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

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

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


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



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

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

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

  • 特権付きコード

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

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

2.4.1 VAX MACROアセンブリ言語

Alphaシステムでは,VAX MACROはアセンブリ言語ではなく,コンパイラの1つでしかありません。しかし,高級言語のためのAlphaコンパイラと異なり,VAX MACRO--32 Compiler for OpenVMS Alphaは常に高度に最適化されたコードを生成するわけではありません。したがって,VAX MACRO--32 Compiler for OpenVMS Alpha は移行の補助手段としてのみ使用するようにし,新しいコードを作成する場合は使用しないでください。

VAXシステムでアセンブリ言語を使用しなければならなかった多くの理由は,次のように,Alphaシステムでは解消されました。

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

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

MACROコードの移行についての詳しい説明は,『OpenVMS MACRO-32 Porting and User's Guide』を参照してください。

2.4.2 特権付きコード

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

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

  • ユーザ作成システム・サービスや他の特権付き共有可能イメージ
    詳しくは,『HP OpenVMS Programming Concepts Manual』と『OpenVMS Linker Utility Manual』を参照してください。

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

  • 特殊な特権を使用するコード。たとえば,$CMEXECまたは$CMKRNLシステム・サービスを使用するコードや,PFNMAPオプションを選択して$CRMPSCシステム・サービスを使用するコード
    メモリ・マッピングの詳細については, 第 5 章 をご覧ください。

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

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

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

OpenVMSエグゼクティブを参照する内部モード・コードを移行する場合には,弊社のサービス窓口にご連絡ください。

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

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

この後の節では,一般的なアーキテクチャ固有の機能と,それらの機能を識別する方法および対処方法について簡単に説明します。これらのアーキテクチャ固有の機能の識別方法と対処方法についての詳しい説明は,第 4 章から第 8 章までを参照してください。

2.5 アプリケーションで VAX アーキテクチャに依存する部分の識別

ネイティブな Alpha コードを生成するコンパイラを使用して,アプリケーションを正しく再コンパイルできる場合でも,アプリケーションには VAX アーキテクチャに依存する部分が含まれている可能性があります。OpenVMS Alpha オペレーティング・システムは OpenVMS VAX と高度な互換性を維持するように設計されています。しかし,VAX アーキテクチャと Alpha アーキテクチャには基本的な違いがあるため,特定の VAX アーキテクチャ機能に依存するアプリケーションの場合は,問題が発生する可能性があります。以下の節では,アプリケーションで特に確認しなければならない分野を示しています。

2.5.1 データ・アラインメント

データ・アドレスがデータ・サイズ(バイト数)の整数倍である場合には,データは 自然なアラインメントになります。たとえば,ロングワードは4の倍数であるアドレスに自然なアラインメントになり,クォドワードは8の倍数であるアドレスに自然なアラインメントになります。構造体の場合も,すべてのメンバが自然なアラインメントになっているときは,その構造体も自然なアラインメントになります。

メモリ内で自然なアラインメントでないデータをアクセスすると,VAXシステムでもAlphaシステムでも性能が大幅に低下します。VAXシステムでは,大部分の言語は省略時の設定により,データを次の使用可能なバイト境界にアラインするため,VAXアーキテクチャでは,アラインされていないデータを参照したときに,性能の低下を最低限に抑えるためのハードウェア・サポートが準備されています。

しかし,Alphaシステムでは,各データを自然なアラインメントにすることが省略時の設定であるため,Alphaは他の典型的なRISCアーキテクチャと同様に,アラインされていないデータを使用することによって発生する性能の低下を最低限に抑えるためのハードウェア・サポートを準備していません。この結果, Alphaシステムで自然なアラインメントになっているデータを参照する操作は,アラインされていないデータを参照する操作より10〜100倍も速くなります。

Alphaコンパイラは,アラインメントに関する大部分の問題を自動的に修正し,修正できない問題には警告を発します。

問題の検出

アラインされていないデータを検出するには,次の方法が有効です。

  • 大部分のAlphaコンパイラが提供するスイッチを使用する方法。このスイッチを使用すれば,コンパイラはアラインされていないデータのコンパイル時参照を報告できます。たとえば,Digital Fortranプログラムの場合には, /WARNING=ALIGNMENT修飾子を使用してコンパイルします。

  • 実行時にアラインされていないデータを検出するために,OpenVMS デバッガ (SET BREAK/UNALIGNED コマンド) または DEC PCA (Performance and Coverage Analyzer)を使用する方法。

問題の対処方法

アラインされていないデータに対処するには,次に示す方法を用います。

  • データをクォドワード境界にアラインすることにより,性能を最大限に向上する方法。これは,Alphaシステムが一般にクォドワード粒度のみをサポートするからです( 第 2.5.4 項 を参照)。

  • 自然なアラインメントでコンパイルするか,または言語がこの機能を備えていない場合には,自然なアラインメントになるようにデータを移動する方法。データが確実にアラインされるように間隔をあけると,メモリ・サイズが拡大するという問題があります。メモリを節約すると同時に,確実にデータを自然にアラインするための方法として,サイズの大きい変数を最初に宣言する方法があります。

  • データ構造内で強制的に自然なアラインメントが実現されるように,高級言語命令を使用する方法。たとえば DEC Cでは,自然なアラインメントが省略時のオプションです。 VAX Cの省略時のアラインメントと一致しなければならないデータ構造(たとえばディスク上のデータ構造など)を定義するには, #PRAGMA NO_MEMBER_ALIGNMENT文を使用します。DEC Fortranの場合には,省略時の設定により,ローカル変数は自然なアラインメントになります。レコード構造とコモン・ブロックのアラインメントを制御するには,/ALIGN修飾子を使用します。

  • VAXと互換性のある,アラインされていない#PRAGMA NO_MEMBER_ALIGNMENT のようなコンパイラ・スイッチを使用する方法。これらのスイッチを使用すると,機能的には正しいものの,実行速度が遅くなる可能性のあるAlphaプログラムが作成されます。

注意

自然なアラインメントに変換されたソフトウェアは,同じOpenVMS Cluster環境内の VAX システム,またはネットワークによって接続された VAXシステムでトランスレートされた他のソフトウェアと互換性がなくなる可能性があります。次の例を参照してください。

  • 既存のファイル・フォーマットは,アラインされていないデータを含むレコードを指定する可能性があります。

  • トランスレートされたイメージは,アラインされていないデータをネイティブ・イメージに渡したり,ネイティブ・イメージからそのようなデータを渡されることを要求する可能性があります。

このような場合には,アプリケーションのすべての部分が同じデータ型,つまり,アラインされたデータ型またはアラインされていないデータ型を要求するように変更しなければなりません。


目次 索引

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