日本-日本語

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

OpenVMS マニュアル


≫ 

OpenVMS
ライブラリ

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

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


目次 索引


付録 B
移行計画の例

この付録に示す移行計画は,現実のアプリケーションに対する計画ではありませんが,お客様のアプリケーションのために作成した,実際の移行計画にもとづいています。

Migration Plan for Omega-1

Omega Corporation



B.1 エグゼクティブ・サマリ

Omega-1はデータのアクセス,分析,管理,および報告のための,企業全体を網羅する情報システムです。

Omega-1のソース・コードは400万行以上のサイズです。ソース・コードの大部分は Cプログラミング言語で作成されており,多彩なプラットフォームで共通に使用でき,移植性がかなり高いと考えられます。

しかし,Omega-1には各プラットフォーム固有のルーチンが含まれており,VAXプラットフォームを対象として,VAX CとVAX MACROで実現されています(この部分は約350,000行のコードです)。これらのルーチンは,付録 B.2.4 項 で説明するように,VAXアーキテクチャ固有の機能に依存する多くの問題を抱えており,移行を成功に導くために解決しなければなりません。これらの問題を解決するには,設計変更も含めて,かなり大量の作業が必要ですが,これらの問題があるからといって,1992年12月にOmega-1の顧客への納品が遅れることはないと考えられます。

Omega-1は,多くのDECプロダクトとサード・パーティ・プロダクトへの接続をサポートします。これらのプロダクトの一部は,OpenVMS AXPが最初に出荷される時点では,AXPプラットフォームで提供されませんが,Omega-1を供給する業者である Omega Corporationは,そのときまでに基本的なOmega-1を移行することを約束しています。

DECサービスは,この計画の詳細記述に従って,移行プロジェクトの最初から最後まで,Omega Corporationにサポート・サービスを提供します。Omega Corporationに提供されるサポート計画をまとめると,次のようになります。

  • Omega CorporationでAXPアプリケーションを開発するためのハードウェア・ツールとソフトウェア・ツール

  • 品質保証テストのための技術的な支援

  • AXP Migration CenterでのAXPシステムのアクセス

  • DECの技術者への電話による連絡

    この技術者はAlpha AXPに関する技術情報を提供し,クロス開発ツールをサポートし,Omega Corporationが報告した DECソフトウェア・プロダクトに関する問題を解決する責任者となります。

  • Omega Corporationの開発者を対象とした3日間の技術セミナー(Omega Corporationでの訪問セミナー)

もう1つの問題として,出荷日より前にプロダクトに対して適切なフィールド・テストを実行するために,Omegaにハードウェアを提供しなければならないという問題があります。通常,Omegaの開発者は実際にプロダクトを出荷する前に,30〜40ヵ所の顧客システムで4ヵ月間,フィルード・テストを行います。しかし,この規模のフィールド・テストを実行するために必要な台数のAXPシステムを入手できるかどうかが不明です。

B.2 技術分析

Omega CorporationはDECサービスと協力して技術分析を行いました。

B.2.1 アプリケーションの特性

Omega-1は大部分のVAXプラットフォーム,および他社のプラットフォームで実行されます。このアプリケーションは3つの層で構成されており,各層は,VAX環境の固有の機能を利用する場合も,利用しない場合もあります。しかし,特定のハードウェア構成や装置に対する直接的な依存はありません。

大部分の機能はアプリケーション層で提供され,この層にはユーザ・インターフェイス,基本的なデータ管理ツール,およびOmegaの第4世代言語(4GL)が含まれています。Omega-1の基本プロダクトは,DECまたはサード・パーティのレイヤード・プロダクトに依存しません。

Omega-1の追加プロダクトは,基本プロダクトを基礎にしたレイヤード・プロダクトであり,拡張されたデータ管理機能または通信機能を備えています。これらのオプションは,DECまたはサード・パーティのレイヤード・プロダクトに依存し,基礎となるプロダクトがリリースされるときに提供されます。

B.2.2 ソフトウェア・アーキテクチャ

Omega-1は 図 B-1 に示すように,層に分かれています。この層構造によって,高いレベルのソフトウェア移植性を実現しています。これは,システムの約10パーセントだけが特定の実現方法に依存し,このコードはすべて1つのモジュール群,つまりホスト層に含まれているからです。

アプリケーション層とコア層は,すべてのソース・ファイルを再コンパイルおよび再リンクするだけでAXPプラットフォームで実行できると考えられます。そのための前提条件は,Omegaソフトウェア開発ツールを正しく移行できることだけです。しかし,これらの開発ツールも移植可能であると考えられ,OpenVMS AXPのランタイム・ライブラリとCコンパイラにのみ依存します。

ホスト層では,VAXハードウェアに依存している一部のモジュールを再開発するなど,多くの変更が必要になります。

図 B-1 Omega-1の層構造


  • アプリケーション層

    この層はシステムの大部分を構成する層であり,多くのプラットフォームで類似した方法で実現されるため,移植可能であると,考えられます。

  • コア層

    この層は,Omegaが設計したサービス群を作成する層であり,これらのサービス群は,各プラットフォームでOmega-1の特殊な必要条件に準拠するように設計されています。特に,Omega-1の「仮想オペレーティング・システム」の各構成要素はこの層に存在します(各構成要素は移植可能な方法で作成できます)。構成要素としては,上位レベルの入出力,上位レベルのメモリ管理,文字ベースのウィンドウ・システム,実行環境も含む4GLコンパイラがあります。この層は移植可能です。

  • ホスト層

    この層は,固有のオペレーティング・システム要素に対するインターフェイスを提供し,ハードウェア・アーキテクチャに依存する可能性があります。この層の構成要素は次のとおりです。

    • 入出力操作

    • イメージのロードとアンロード

    • メモリ管理

    • 多少のスレッド管理

    • ターミナル・サービス

    • ウィンドウ・インターフェイス

    ホスト層は,各プラットフォームで異なります。VAXのホスト層は,VAX C と VAX MACROで作成されています。この層は,移行プロジェクトが中心的に対処しなければならない,大部分の問題を含んでいます。



B.2.3 イメージ分析の結果

Omega-1は再コンパイルおよび再リンクされますが,ホスト層の26のイメージを分析するために,まずVAX Environment Software Translator(VEST)を使用しました。これらのイメージの多くには,D浮動小数点データ型に依存する命令が含まれています。このデータ型はVAX Cの省略時の設定です。Omegaの技術者がD浮動小数点を別の浮動小数点フォーマットに移行することを決定した場合には,VAXとAXPが混在する VMSクラスタ環境で,データ・ファイルの互換性に関する問題が発生することに注意しなければなりません。

表 B-1 は,イメージ分析で各イメージによって生成されたエラー・メッセージを示しています。

表 B-1 イメージ分析の結果
イメージ名 VESTが検出した%コード 検出した主な要素
OMEGADEV60 -Fatal errors-
no code found
VEST-F-PROTISD
VEST-F-ISDALIGN
VEST-F-ISDMIXED
VEST-W-STACKMATCH
パック10進命令
OMECRTL 92% VEST-W-STACKMATCH
VEST-W-STKUNAL
パック10進命令
PSCN 64% VEST-W-STKUNAL
VEST-W-STACKMATCH
PVSN 65% VEST-W-STKUNAL
VEST-W-STACKMATCH

次のリストは,Omegaイメージを分析した結果,検出された主な要素を説明しています。

  • PROTISDは,ユーザ作成システム・サービス・ベクタであり,イメージに1つ以上のユーザ作成システム・サービスが含まれることを示します。この問題は,ネイティブな Alpha AXPコンパイラを使用して,コードをコンパイルするときに自動的に処理されます。

  • ISDALIGNは,イメージ・セクションが64KB境界にアラインされていないことを示します。別のVEST分析を実行する前に,64KBのページを使用してイメージを再リンクしなければなりません。リンカは移行プロセスでこの問題を処理します。

  • ISDMIXEDは,互換性のないVAXイメージ・セクションが,同じ64KBブロックにマッピングされたことを示します。リンカは移行処理でこの問題を処理します。

  • STKUNALは警告であり,コード・ブロックがロングワードでアラインされたスタックを,アラインされないスタックに変更したことを示します。この結果,性能が低下します。Omegaの技術者はVEST分析からログを調べます。

  • STACKMATCHは,スタックが特定の時点でバランスのとれない状態になる可能性のあることを示します。Omegaの技術者は,VEST分析からログを調べます。

  • パック10進命令はソフトウェアによってのみサポートされ,ハードウェアではサポートされません。これらの命令は,アプリケーションの性能を低下させる可能性があります。Omegaの技術者は,パック10進コードを調べます。



B.2.4 ソース分析の結果

前に説明したように,アプリケーション層とコア層の移行はかなり簡単です。しかし,Omega-1のホスト層にはVAXに依存する部分が数多く含まれています。Omegaの技術者と検討した結果,アーキテクチャに依存する部分は次のとおりであることがわかりました。

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

    Omega-1ソフトウェアには,アラインされていないパブリック・データ構造が含まれています。ソース・コードを移植可能にするために,Omegaの技術者は DEC Cコンパイラの/NOMEMBER_ALIGN修飾子を使用して,このコードをコンパイルします。

  • データ型

    Omega-1では,広範囲にわたって浮動小数点演算とデータ・ファイルを使用します。VAXバージョンでは,すべての操作に対してD-56フォーマットを使用しますが,このフォーマットはネイティブなAlpha AXP命令セットでは実現されていません。VAXと AXPが混在するクラスタを使用する顧客の場合,D浮動小数点フォーマットをそのまま使用することが適切です。Omegaでは,AXPで提供されるD浮動小数点の 53ビット・バージョン(56ビットではない)を使用した結果,浮動小数点の精度が少し失われるものの,特に問題がないと判断しました。

    しかし,他の大部分のOmega-1システムではIEEE浮動小数点フォーマットを使用しており,これらのフォーマットはAlpha AXP命令セットで完全にサポートされます。IEEEフォーマットを再度実現するには,異なる修飾子を使用して再コンパイルするだけですみますが,その後,OpenVMS VAXユーザは移行処理の一部として,ファイル内のすべての浮動小数点データを新しいフォーマットに変換しなければなりません。

  • 読み込み/書き込み/変更の不可分性

    共有変数に対する操作を明示的な同期方式によって保護しなければならないかどうかを判断するには,いくつかのASTルーチンを調べなければなりません。この部分には大きな問題はありません。

  • バイト操作とワード操作の粒度

    Omega-1ソフトウェアには,自然なクォドワード境界にアラインされないデータを保護するラッチがあります。DECの技術者はOmegaの技術者とこの問題に関して検討し,解決方法を模索するためにコード・サンプルを調べました。その結果,共有データ宣言とコンパイラ・ディレクティブを使用することにより,コンパイラがこの種のアクセスを処理できると判断しました。

  • VAXページ・サイズ

    ホスト層には,アプリケーションのかわりにメモリ管理を処理するいくつかのルーチンがあります。既存のアルゴリズムでは,実際にページ・サイズが512バイトである必要はありませんが,それでもページ・サイズが512バイトとしてハード・コーディングされています。システム起動時にシステム・ページ・サイズを調べ,メモリ管理操作で必要な演算に対して正しいシステム・ページ・サイズを使用するようにモジュールを変更すれば,メモリ管理機能を正しく実行できます。

  • VAXプロシージャ呼び出し規則

    ユーザ割り込みが発生したときに呼び出し履歴を判断するために,Omega-1は呼び出しフレーム・スタックを「追跡」します。Omega-1はコードの中で重要でない領域を処理しているときに,呼び出しフレームの1つの戻りアドレスを変更することにより,制御の流れを変更します。つまり,割り込みを受け付けます。この処理の大部分は,SYS$UNWINDが実行する処理によく似ていますが,Omega-1では例外ハンドラのかわりに ASTを使用します。

    Omega-1には,VAX呼び出し規則に依存する多くの機能が含まれています。たとえば,Omegaではsetjmp()とlongjmp()を独自の方法で実現しています。これらの関数は VAX MACROで作成されており,オペレーティング・システム・コード内で分離されています。OmegaはVAX呼び出し規則への依存に対処するために,これらの関数を再開発します。

  • 例外処理

    Omega-1は無効な,または例外をおこした浮動小数点演算に対し,統計的に値を補い修正します。ここで問題となるのは,Alpha AXPアーキテクチャで実際にフォルトが発生した命令を現在の設計でデコードできるかどうかということです。Alpha AXPアーキテクチャでは,例外トラップはただちに報告されません。

  • VAX命令セットとコード生成

    ホスト層にはコード・ジェネレータがあり,プラットフオームにとってネイティブな命令をメモリに書き込み,それを4GL言語の一部として実行します。このコード・ジェネレータは多くの作業を実行しますが,特にデータベース入出力操作を実行するために「分散/収集」コードを生成します。移行プロジェクトの初期段階では,コード・ジェネレータとの間で「プラグ互換性」を維持した移植可能なインタプリタを使用できます。しかし,Alpha AXP命令を生成する新しいジェネレータ・バージョンを最終的に実現しなければなりません。



B.3 中間目標と成果物

Omega-1の基本プロダクトの出荷予定日は1992年12月です。表 B-2 は,基本プロダクト・プロジェクトの主な中間目標と成果物を示しています。各成果物についての詳しい説明は,付録 B.4 節 を参照してください。

表 B-2 中間目標と成果物
中間目標 責任者 DECの役割 終了日
Omega-1ライン・モード・プロダクト Omega/Digital コンサルティング 1991年11月
新しいクロス・イメージ・ブリッジ Omega/Digital コンサルティング 1991年12月
浮動小数点に関する判断 Omega --- 1991年12月
Omega-1例外モジュール Omega/Digital コンサルティング 1992年1月
コード・ジェネレータの実現開始 Omega/Digital コンサルティング 1992年1月
アプリケーション層の構築 Omega/Digital コンサルティング 1992年1月
コード・ジェネレータのテスト Omega/Digital テスト・スクリプトの実行 1992年3月
アプリケーションのテスト Omega/Digital テスト・スクリプトの実行 1992年5月
Motifユーザ・インターフェイスの実現とテスト Omega/Digital テスト・スクリプトの実行 1992年7月
Omega QAとフィールド・テストの開始 Omega 訪問サポート 1992年12月
出荷日 Omega --- 1992年12月



B.4 技術的なアプローチ

この後の節では,この移行プロジェクトの各中間目標を実現するために採用したアプローチについて,詳しく説明します。

B.4.1 ライン・モード・プロンプト

最初の中間目標はOmega-1にライン・モード・プロンプトを導入し,実行のために意味のあるOmega-1プログラム名とコマンド・シーケンスを入力することです。この目標を達成すれば,開発ツールとランタイム・ライブラリの基本的な機能を示すことができます。この時点で,次の要素を除き,ホスト層は正しく機能します。

  • 4GL機能に対して,コード・ジェネレータのかわりにOmega-1インタプリタを使用します。

  • イメージ・ブリッジは一時的な実現です。

  • 例外処理は不完全です。

さらに,コア層も正しく機能し(ウィンドウ・ユーザ・インターフェイスを除く),少なくとも1つのOmega-1アプリケーションを試すことができます。この作業はDECからのサポートのもとに,Omega VMSホスト・グループが実行します。

B.4.2 イメージ・ブリッジ

Omega-1には,イメージ間ですべてのジャンプをディスパッチする,中心的なブリッジ・ルーチンがあります。このため,Omega-1はアンロードされているイメージ内のルーチンを呼び出し,これらのイメージを動的にロードすることができます。また,ブリッジ・ルーチンの採用により,Omega-1ではイメージをアンロードできます。

OpenVMS AXPオブジェクト・ファイルのフォーマットとイメージ起動ルーチンはすでに設定されており,OpenVMS AXPのブリッジの実現は,OpenVMS VAXの場合と同様の方法で実行できます。

この作業は,DECのサポートのもとにOmega VMSホスト・グループが実行し,必要な変更は 1991年12月までに終了できます。


目次 索引

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