日本-日本語

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

OpenVMS マニュアル


≫ 

OpenVMS
ライブラリ

タイトルページ
目次
まえがき
第 1 章:移行プロセスの概要
第 2 章:移行方法の選択
第 3 章:アプリケーションの移行
第 4 章:再コンパイルと再リンクの概要
第 5 章:ページサイズの拡大に対するアプリケーションの対応
第 6 章:共用データの整合性の維持
第 7 章:アプリケーションデータ宣言の移植性の確認
第 8 章:アプリケーション内の条件処理コードの確認
第 9 章:OpenVMS I64コンパイラ
付録 A :アプリケーション評価チェックリスト
用語集
索引
PDF
OpenVMS ホーム

HP OpenVMS
OpenVMS VAX から OpenVMS I64 への
アプリケーションの移行


目次 索引

第 2 章
移行方法の選択

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

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

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

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

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

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

2.1 移行のための棚卸し

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

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

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

    • 共有イメージ

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

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

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

    • メッセージ・ファイル

    • CLD ファイル

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

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

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

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

    • 他社製品

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

  • 必要なオペレーティング環境

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

    • ビルド・プロシージャ
      このプロシージャには,コード管理システム (CMS) やモジュール管理システム (MMS) などのツールが含まれます。

    • テスト・スイート
      テスト・スイートを使用することで,移行したアプリケーションが正しく動作するかどうかを確認し,その性能を評価することができます。

以下のように,これらの多くは,すでに OpenVMS I64 に移行されています。

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

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

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

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

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

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

    • ネットワーク環境

  • 他社製品
    現在多くの他社製アプリケーションが, OpenVMS I64 で実行可能です。アプリケーションが移行されているかどうかについては,各アプリケーション・ベンダーにお問い合わせください。

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

2.2 移行方法の選択

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

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

注意

以降のプロセスでは,可能なかぎりアプリケーションを再コンパイルすることとし,再コンパイルできない部分や,移行の過程で一時的な対処を目的にトランスレーションを用いるものと仮定しています。

以下の手順を実行して,アプリケーションの移行方法を選択してください。

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

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

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

図 2-1 プログラムの移行


図 2-1 に示すように,評価のプロセスは,一連の質問と,これらの質問に答えるのに役立つ作業で構成されています。弊社では,これらの質問に答えるのに役立ついくつかのツールを提供しています。これらのツールについては,移行プロセスの適切な時点で説明します。

ほとんど場合,アプリケーションを再コンパイルおよび再リンクすることも,トランスレートすることもできます。しかし,アプリケーションの設計によっては,以下に示すように, 2 種類の移行方法のどちらか一方だけしか使用できないことがあります。

  • 再コンパイルできないプログラム
    以下のイメージはトランスレートする必要があります。

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

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

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

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

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

    • OpenVMS VAX バージョン5.5 以降を使って作成されたイメージ。トランスレートされた 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 再コンパイルするかトランスレートするかの判断

イメージに対して 2 つの方法のどちらも使用できる場合には, I64 システム上でイメージのネイティブ・バージョンとトランスレートされたバージョンを実行した場合の性能と,イメージのトランスレートおよびネイティブ I64 イメージに変換するのに必要な作業を見積もり,これらのバランスを取る必要があります。

一般に,アプリケーションを構成する各イメージは異なるモードで実行できます。たとえば,ネイティブ I64 イメージからトランスレートされた共有イメージを呼び出したり,その逆に呼び出すことが可能です。 2 つのアーキテクチャが混在したアプリケーションについての詳細は, 第 2.4.2 項 を参照してください。

表 2-1 では,2 種類の移行方法を比較しています。

表 2-1 移行方法の比較
要素 再コンパイル/再リンク トランスレート
性能 完全な I64 の機能 通常,ネイティブ I64 の 25〜40% の性能; VAX での性能と同等
必要な作業 容易な場合も困難な場合もある 容易
スケジュールの制約 ネイティブ・コンパイラが提供されるかどうかに応じて異なる なし。ただちに可能
サポートされるプログラム    
--バージョン VAX VMS バージョン 4.0 以前のソースが受け付けられる VAX/VMS バージョン 5.5 またはそれ以降のイメージのみがサポートされる
--制約事項 特権コードがサポートされる ユーザ・モードのコードだけがサポートされる
VAX との互換性 高い。ほとんどのコードは問題なく再コンパイル/再リンクできる エミュレーションによって実現される
今後のサポートと保守 通常のソース・コードの保守 VAX のソース・コードの保守。各新バージョンの再コンパイルと再トランスレートがある

アプリケーションをどのような方法で移行するかを決定するには,以下の事項を考慮してください。

  • アプリケーションをソース・コードから完全に再構築しますか,それとも一部の機能に対してはバイナリ・イメージを使用しますか?
    バイナリ・イメージを使用する場合には,それらをトランスレートしなければなりません。

  • アプリケーションを構成するすべてのイメージのソース・コードを入手できますか?
    ソース・コードを入手できないイメージは,トランスレートしなければなりません。

  • どのイメージがアプリケーションの性能に大きな影響を与えますか?
    I64 システムの速度を完全に利用したいイメージでは,再コンパイルしなければなりません。

    • 性能に大きな影響を与えるイメージを識別するには,PCA を使用します。

    • ネイティブ I64 コンパイラが作成するイメージでのみ,I64 の処理機能を効率よく使用し,最適な性能を実現できます。トランスレートされた VAX イメージはネイティブ I64 コードの 1/3 程度の速度,またはそれ以下の速度で実行されます。実際の速度は,使用するトランスレーション・オプションに応じて異なります。

  • 2 つの方法を使用した場合,各イメージを変換するのに要する作業量はどの程度ですか?

    • VAX イメージを I64 イメージにトランスレートするには,2 つの手順からなる処理を実行します。

      1. VEST ユーティリティを使用して,VAX イメージを Alpha イメージにトランスレートします。

      2. HP OpenVMS Migration Software for Alpha to Integrity Servers (OMSAI) ユーティリティを使用して,Alpha イメージを I64 イメージにトランスレートします。

    • VAX アーキテクチャ固有の機能に依存するコードや, VAX の呼び出し規則に依存しているコードは直接再コンパイルすることはできません。このようなコードはトランスレーションして実行するか,コードを変更して再コンパイルおよび再リンクしなければなりません。

アーキテクチャへの依存は,以下のようにいくつかの方法で取り除くことができます。

  • アーキテクチャに依存するコード・シーケンスは,プラットフォームから独立した方法で,同じ操作をサポートする高級言語のレキシカル要素に置き換えます。

  • プロセッサ・アーキテクチャに適した方法で作業を実行するために, OpenVMS システム・サービスに対する呼び出しを使用します。

  • ソース・コードの変更量をできるだけ少なくし,正しくプログラムが動作することを保証するために,高級言語のコンパイラ・スイッチを使用します。

表 2-2 は,各プログラムのアーキテクチャに依存する部分が,プログラムを I64 システムに移行するために使用する方法の選択に,どのような影響を与えるかを示しています。詳細は,次の章以降を参照してください。

表 2-2 移行方式の選択: アーキテクチャに依存する部分の取り扱い
再コンパイル/再リンクした VAX ソース トランスレートされた VAX イメージ
データ・アラインメント1  
デフォルトでは,大部分のコンパイラはデータを自然な境界にアラインする。 VAX アラインメントを維持するための修飾子についての説明は, 第 9 章 を参照。 アラインされていないデータもサポートされるが,/OPTIMIZE=ALIGNMENT 修飾子を使用すれば,データがロングワードにアラインされていることを仮定することにより,実行速度を向上できる。
データ型  
H 浮動小数点は X 浮動小数点に変更する。

D 浮動小数点の場合,D53 形式の 10 進 15 桁の精度で十分なときは, D 浮動小数点を G 浮動小数点に変更する。アプリケーションで 10 進 16 桁の精度 (D56 形式) が必要な場合には,トランスレートしなければならない。

COBOL のパック 10 進数は演算のために自動的にバイナリ形式に変換される。

データ型についての詳細は, 第 7 章 を参照。

D 浮動小数点の 10 進 16 桁の精度が必要な場合には,/FLOAT=D56_FLOAT 修飾子を使用する。この修飾子を使用した場合,性能は,デフォルトの /FLOAT=D53_FLOAT を使用した場合より低下する。
読み取り/変更/書き込み操作の不可分性  
サポートは各コンパイラが提供しているオプションに応じて異なる (詳細は 第 6 章 を参照)。 /PRESERVE=INSTRUCTION_ATOMICITY 修飾子を使用する。実行速度は半分に低下する。
ページ・サイズ  
デフォルトでは,OpenVMS リンカは大きい I64 スタイルのページを作成する。 512 バイト・ページのイメージの大部分はサポートされる。しかし,VEST はゆるやかな保護を割り当てるため,アクセス違反を生成するために厳しい保護に依存しているイメージをトランスレートした場合, I64 システムで正しく実行されない。
読み取り/書き込みの順序  
適切な同期命令 (MF) をソース・コードに追加することによりサポートされるが,性能は低下する (詳細は 第 6 章 を参照)。 /PRESERVE=READ_WRITE_ORDERING 修飾子を使用する。
VAX アーキテクチャおよび呼び出し規則への明示的な依存2  
サポートされない。依存する部分は削除しなければならない。 サポートされる。

1アラインされていないデータは性能上の問題となります。アラインされていないデータを参照した場合,VAX システムでは性能がある程度低下するだけですが, I64 システムでアラインされていないデータをメモリからロードしたり,アラインされていないデータをメモリに格納すると,アラインされた操作の場合より最高 1000 倍も時間がかかる可能性があります。
2VAX アーキテクチャ固有の機能や呼び出し規則への依存としては, VAX 呼び出し規則,VAX 例外処理,VAX AST パラメータ・リスト, VAX 命令の形式と動作,および VAX 命令の実行時作成への明示的な依存などがある。


目次 索引

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