| 前へ | 次へ | 目次 | 索引 |
この付録に示す移行計画は，現実のアプリケーションに対する計画ではありませんが，お客様のアプリケーションのために作成した，実際の移行計画にもとづいています。
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に提供されるサポート計画をまとめると，次のようになります。
この技術者はAlpha AXPに関する技術情報を提供し，クロス開発ツールをサポートし，Omega Corporationが報告した DECソフトウェア・プロダクトに関する問題を解決する責任者となります。
もう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で作成されています。この層は，移行プロジェクトが中心的に対処しなければならない，大部分の問題を含んでいます。
Omega-1は再コンパイルおよび再リンクされますが，ホスト層の26のイメージを分析するために，まずVAX Environment Software Translator(VEST)を使用しました。これらのイメージの多くには，D浮動小数点データ型に依存する命令が含まれています。このデータ型はVAX Cの省略時の設定です。Omegaの技術者がD浮動小数点を別の浮動小数点フォーマットに移行することを決定した場合には，VAXとAXPが混在する VMSクラスタ環境で，データ・ファイルの互換性に関する問題が発生することに注意しなければなりません。
表 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イメージを分析した結果，検出された主な要素を説明しています。
前に説明したように，アプリケーション層とコア層の移行はかなり簡単です。しかし，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の技術者とこの問題に関して検討し，解決方法を模索するためにコード・サンプルを調べました。その結果，共有データ宣言とコンパイラ・ディレクティブを使用することにより，コンパイラがこの種のアクセスを処理できると判断しました。
ホスト層には，アプリケーションのかわりにメモリ管理を処理するいくつかのルーチンがあります。既存のアルゴリズムでは，実際にページ・サイズが512バイトである必要はありませんが，それでもページ・サイズが512バイトとしてハード・コーディングされています。システム起動時にシステム・ページ・サイズを調べ，メモリ管理操作で必要な演算に対して正しいシステム・ページ・サイズを使用するようにモジュールを変更すれば，メモリ管理機能を正しく実行できます。
ユーザ割り込みが発生したときに呼び出し履歴を判断するために，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アーキテクチャでは，例外トラップはただちに報告されません。
ホスト層にはコード・ジェネレータがあり，プラットフオームにとってネイティブな命令をメモリに書き込み，それを4GL言語の一部として実行します。このコード・ジェネレータは多くの作業を実行しますが，特にデータベース入出力操作を実行するために「分散/収集」コードを生成します。移行プロジェクトの初期段階では，コード・ジェネレータとの間で「プラグ互換性」を維持した移植可能なインタプリタを使用できます。しかし，Alpha AXP命令を生成する新しいジェネレータ・バージョンを最終的に実現しなければなりません。
Omega-1の基本プロダクトの出荷予定日は1992年12月です。表 B-2 は，基本プロダクト・プロジェクトの主な中間目標と成果物を示しています。各成果物についての詳しい説明は，付録 B.4 節 を参照してください。
| 中間目標 | 責任者 | 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.1 ライン・モード・プロンプト
最初の中間目標はOmega-1にライン・モード・プロンプトを導入し，実行のために意味のある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月までに終了できます。
| 前へ | 次へ | 目次 | 索引 |