JRD-4989A イメージ
B.4 技術的なアプローチ
この後の節では，この移行プロジェクトの各中間目標を実現するために採用したア プローチについて，詳しく説明します。
B–10
移行計画の例 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
月までに終了できます。移行計画の例
B.4技術的なアプローチ
B.4.3 浮動小数点フォーマットに関する判断
Omega-1
とそれを利用する多くの顧客は，D-56
浮動小数点データ型に依存します。速度を向上するために
D-56
をIEEE
のT
浮動小数点に変更できますが，その ためにはすべてのデータに対して，1
つのフォーマットから別のフォーマットにデ ータを変換しなければなりません。この判断は，
Omega
がビジネス上の判断として下さなければならず，1991
年末 までに判断します。B.4.4 Omega-1 の完全な例外処理
次に解決しなければならない大きな問題は，
OpenVMS AXP
でOmega-1
の例外 処理をどのように実行するかということです。ファイルのオープン時に発生する実 行時アクセス違反など，一般的な例外処理はOmega-1
の例外ハンドラがトラップ し，その後，コール・フレームに対して「スタック追跡」を実行することにより処 理されます。Omega
の開発者はOpenVMS AXP
の新しい呼び出し規則に対応す るために必要な変更を行い，DEC C
の"setjmp"と "longjmp"機能を使用します。
浮動小数点例外処理に関しては，設計を変更し，再度実現することが必要です。正 しい機能を実現するために多くのオプションを選択できますが，さらに性能も考慮 して，最適な方法を判断しなければなりません。
Omega
の開発者は予定日までに この問題を解決できるでしょう。B.4.5 コード・ジェネレータの実現の開始
ホスト層を完全に実現するために必要な最後の構成要素はコード・ジェネレータ です。コード・ジェネレータを実現するために，
Omega
の開発者はネイティブなAlpha AXP
命令セットの完全な定義を必要とします。コード・ジェネレータの開発作業は，
Omega
のOpenVMS
ホスト・グループが完全に行います。DEC
は必 要に応じて電話によるサポートを提供します。B–12
移行計画の例 B.4技術的なアプローチ
B.4.6 アプリケーションの構築
ホスト層が完全な機能を実現した後，
1992
年1
月にアプリケーションを構築でき ます。これらのアプリケーションはきわめて厳密な移植標準規格に従ってC
で作 成されているため，再コンパイルするだけで実行できると考えられます。DEC
はOmega
の開発者に対して，ツールとコンパイラの問題点に関する電話によるサポートを提供します。
B.4.7 コード・ジェネレータのテスト
DEC
は1992
年3
月にAXP
システムでOmega-1
コード・ジェネレータをデバッ グし，機能テストを実行するために，必要な援助を提供します。Omega
の開発者 はAlpha AXP Migration Center
のAXP
システムでテスト環境を設定し，テスト の実行方法をDEC
の技術者に教育し，初期テストを監視します。その後，Omega
はDEC
の技術者がテストを実行できるように，テスト・スクリプトとデータを郵 送します。B.4.8 完全なアプリケーションのテスト
Omega
は数多くのリグレッション・テスト・ストリームを管理しており，移植が正しく実行されたかどうかを検証するために，
AXP
システムでこれらのテス トを実行しなければなりません。このテストを実行できる状態になったときに，Omega
がAXP
システムをまだ入手していない場合には，DEC
はDEC
のシステ ムを使用してOmega-1
基本システム・アプリケーションに対してリグレッショ ン・テストを実行しなければなりません。このために，
Omega
の開発者はDEC
ラボラトリのAXP
システムでテスト環境を 設定し，リグレッション・テストの実行方法に関してDEC
の技術者を教育し，初 期テストを監視します。その後，Omega
はDEC
の技術者がテストを実行できる ようにするために，テスト・スクリプトとデータを郵送します。DEC
はテスト結 果をOmega
に戻します。この作業は1992
年4
月に開始され，5
月末までに終了 します。移行計画の例
B.4技術的なアプローチ
B.4.9 DECwindows Motif ユーザ・インターフェイス
開発者が
Motif
ユーザ・インターフェイスをテストできるように，Omega
はフィールド・テストの前に
Motif
開発ツール・キットを入手しておかなければなりませ ん。B.4.10 Omega の品質保証とフィールド・テスト
Omega
は最終プロダクトを検証するために多くのテスト・ストリームを管理しています。これらのテストは，フィールド・テストを開始する直前に実行されます。
これらのテストは完全な
AXP
システムで実行しなければなりません。この時点で，
AXP
システムでのみ明らかになる性能上の特定の問題を解決するた めに，いくつかのテストと最適化が必要です。DEC
はこれらの作業を実行するた めに必要なエンジニアリング・サポートを提供します。
ドキュメント内
OpenVMS AXP オペレーティング・システムへの移行：システム移行の手引き
(ページ 106-110)