日本-日本語
日本HPホーム 製品 & サービス サポート & ドライバー ソリューション ご購入方法
≫  お問い合わせ

製品とサービス >  ソフトウェアとOS >  OpenVMS >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS
ライブラリ

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

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


目次 索引



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.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.9 DECwindows Motif ユーザ・インターフェイス

開発者がMotifユーザ・インターフェイスをテストできるように,Omegaはフィールド・テストの前にMotif開発ツール・キットを入手しておかなければなりません。

B.4.10 Omegaの品質保証とフィールド・テスト

Omegaは最終プロダクトを検証するために多くのテスト・ストリームを管理しています。これらのテストは,フィールド・テストを開始する直前に実行されます。これらのテストは完全なAXPシステムで実行しなければなりません。

この時点で,AXPシステムでのみ明らかになる性能上の特定の問題を解決するために,いくつかのテストと最適化が必要です。DECはこれらの作業を実行するために必要なエンジニアリング・サポートを提供します。

B.5 依存とリスク

Omega-1を正しく出荷できるかどうかを左右するおもなリスクは,品質保証とフィールド・テスト・プロセスに関係しています。開発者は通常,30〜40の顧客システムに対してフィールド・テストを実行し,これらのテストが終了するまでに約4ヵ月かかります。OmegaとDECアカウント・チームは,Omegaが最低限の条件を満足するテスト・プログラムを実行し,1992年12月までに終了できる方法を判断しなければなりません。

次のリストは,Omega-1基本プロダクトのソフトウェアが特定のアーキテクチャに依存する部分を示しています。

  • DEC C for OpenVMS AXPコンパイラ

  • VAX MACRO--32 Compiler for OpenVMS AXP

  • MACRO--64 Assembler for OpenVMS AXP

  • OpenVMS デバッガ

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

  • OpenVMSランタイム・ライブラリ(LIB$)

  • 画面管理ライブラリ(SMG$)

  • DECTPU

Omega-1アプリケーションはまた,DECまたはサード・パーティのデータ管理オプションまたはネットワーキング・オプションへのアクセスも提供します。次の例を参照してください。

  • Omega/Graphは,CDAツールを使用してDDIFフォーマットでグラフィック・イメージを作成できます。

  • Omega/AccessはRdb/VMSまたはORACLEデータベースをアクセスできます。

  • Omega/ShareとOmega/Connectionは,ULTRIX Connection(UCX)を使用してTCP/IPを介してリモート・データをアクセスできます。



B.6 必要な資源

付録 B.3 節 に示した計画をサポートするために使用されるDECの資源は,表 B-3 に示すとおりであり,この後の節で詳しく説明します。

表 B-3 DECサポートのまとめ
資源 時期 作業内容 作業レベル
訪問トレーニング 91年12月 トレーニング 1人の技術者が3日間
電話によるサポート 91年12月〜92年8月 一般サポート 1人の技術者が 1週間に8時間
技術支援 92年3月 コード・ジェネレータのテスト 1人のフルタイム技術者が2週間,ハーフタイム技術者が4週間
AXPハードウェア 92年3月 コード・ジェネレータのテスト 1週間に 5日間の割合で2週間,1週間に2日間の作業を4週間
技術支援 92年4月〜5月 アプリケーションのテスト 1人の技術者がハーフタイムで8週間
AXPハードウェア 92年4月〜5月 アプリケーションのテスト 1週間に 2日ずつの割合で8週間
訪問サポート 92年1月〜8月 Omega QA 1ヵ月間に1週間



B.6.1 ハードウェア

Omegaは通常の開発作業に影響を与えずに移行作業を終了するまでに,システムを DECから借りなければなりません。

Omega-1基本プロダクトは開発システム(VAX 6000 Model 550)でRA90ドライブを複数使用します。完全なアプリケーションを構築する場合,ディスク空間が問題になる可能性があります。

B.6.2 訪問トレーニング

DECは1991年12月に開始されたOmega移行プロジェクトを積極的にサポートするために,Omegaのアプリケーション層開発者とコア層開発者を対象にして3日間の AXP技術セミナーを開催します。

B.6.3 電話によるサポート

1992年1月から3月までに,Omegaの開発者はDECが提供するプラットフォームでクロス・ツールを使用して,ホスト層を移行する作業を行います。この期間だけでなく,移行作業全体にわたって,OmegaはDECのソフトウェア技術者から電話によるサポートを受けることができます。DECの担当技術者はOmegaの問題に関して1週間に約8時間費やし,バグの報告を処理し,クロース・ツールをサポートします。

B.6.4 テストの支援

DECはOmega-1アプリケーションの複数のテスト段階をサポートします。

コード・ジェネレータをテストするために,3月の最初の2週間に1人のフルタイムの DEC技術者が必要です。この期間に,Omegaの開発者がDECの技術者を教育し,初期テストを実行します。その後の4週間にDECの担当技術者は就業時間の50%を費やしてフォローアップ・テストを実行し,テスト結果をOmegaに報告します。

コード・ジェネレータのテストでは,最初の2週間にAXPシステムをほとんどフルタイムで使用しなければなりません。その後の4週間には,1週間に2日ずつの割合で AXPハードウェアを使用しなければなりません。

アプリケーションのテストは1992年4月と5月にDECで実行され,リグレッション・テストを実行し,テスト結果をOmegaに報告するために,1人の技術者の勤務時間の約50%を必要とします。この作業には,8週間のテスト期間中に1週間に2日ずつの割合でAXPハードウェアを使用しなければなりません。

DECの技術者はOmegaで訪問サポートを提供するために,1992年9月〜11月の期間中に 15日間,Omegaに出向します。

用語集


CISC: 複雑命令セット・コンピュータを参照。

IIF: VAXイメージ間のインターフェイスに関する情報を記述した ASCIIファイル。VEST は IIF を使って他のイメージに対する参照を解決し,適切なリンクを作成する。

PALcode: 特権付きアーキテクチャ・ライブラリを参照。

RISC: 縮小命令セット・コンピュータを参照。

Translated Image Environment(TIE): トランスレートされたイメージの実行をサポートするネイティブなAXP共有可能イメージ。TIEはトランスレートされたイメージとネイティブな AXPシステムとのすべてのやりとりを処理する。また,VAXの状態を管理し,例外処理やASTの実行要求,複雑なVAX命令など,VAXの機能をエミュレートし,トランスレートされていないVAX命令を解釈することにより,トランスレートされたイメージに対してOpenVMS VAXに類似した環境を提供する。

VAX Environment Software Translator(VEST): ソフトウェア移行用のツールであり,VAXの実行可能イメージと共有可能イメージを,AXPシステムで実行されるトランスレートされたイメージに変換する。トランスレートされたイメージを参照。

VEST: VAX Environment Software Translatorを参照。

アラインされたデータ(aligned data): アラインメントの用件を満たすデータを,アラインされたデータ と呼ぶ。

アラインメント(alignment): 自然なアラインメントを参照。

イメージ・セクション: イメージを仮想メモリに割り当てるときの単位となる,同じ属性を持つプログラム・セクションの集合。この場合属性とは,たとえば読み込み専用アクセス属性,読み込み/書き込みアクセス属性,固定アドレス属性,再配置可能属性などである。

インターロック命令: インターロック命令は,マルチプロセシング環境で1つの中断されない操作として完全な結果を保証できる方法で動作を実行する。インターロック命令が終了するまでの間,他の衝突する可能性のある操作はブロックされるため,インターロック命令は性能を低下させる可能性がある。

書き込み可能グローバル・セクション: プロセス間通信で使用するためにシステム内のすべてのプロセスが使用できるデータ構造(たとえばFORTRANのグローバル・コモン)や共有可能イメージ・セクション。

クォドワード: 任意のアドレッシング可能なバイト境界から始まる連続した4ワード(64ビット)。各ビットには右から左に0〜63の番号が付けられる。クォドワードのアドレスは下位ビット(ビット0)を含むワードのアドレスである。アドレスを8で割り切れる場合には,クォドワードは自然にアラインされる

クォドワード粒度: メモリ・システムの特性であり,隣接するクォドワードを異なるプロセスまたはプロセッサが同時に個別に書き込むことができる特性。

クロス開発: 1つのシステムで実行されるツールを使用して,別のシステムを対象としたソフトウェアを作成する処理。たとえば,VAXシステムで実行されるツールを使用して,AXPシステムのためのコードを作成する処理。

互換性: あるコンピュータ・システム(OpenVMS VAX)のために作成されたプログラムを別のシステム(たとえばOpenVMS AXP)で実行できる能力。

自然なアラインメント: データ・アドレスをデータ・サイズ(バイト数)で割り切れるメモリ内のデータ。たとえば,自然にアラインされたロングワードは4で割り切れるアドレスを持ち,自然にアラインされたクォドワードは8で割り切れるアドレスを持つ。構造のすべてのメンバが自然にアラインされている場合には,その構造も 自然にアラインされるという。

ジャケット・ルーチン: 1つの呼び出し規則から別の規則にプロシージャ呼び出しを変換するプロシージャ。たとえば,トランスレートされたVAXイメージ(VAX呼び出し規則を使用するイメージ)とネイティブなAXPイメージ(AXP呼び出し規則を使用するイメージ)との間で呼び出しを変換する。

縮小命令セット・コンピュータ(RISC): 複雑さが削減された命令セットを使用するコンピュータ。ただし,命令の数が必ずしも削減されているとは限らない。RISCアーキテクチャは通常,特定の操作を実行するためにCISCアーキテクチャより多くの命令を必要とする。これは,各命令がCISC命令より少ない作業しか実行しないからである。

同期: マルチプロセシング環境や共有データを使用するユニプロセシング環境で操作するときに,きちんと定義された予測可能な結果が得られるように,一部の共有資源に対するアクセスを制御する方法。

同時実行/並列処理: 複数のエージェントが共有オブジェクトに対して操作を同時に実行すること。

特権付きアーキテクチャ・ライブラリ(PAL): 特定のオペレーティング・システム固有の命令を実行するための呼び出し可能ルーチンを登録したライブラリ。特殊な命令がルーチンを呼び出し,これらは中断せずに実行される。

トランスレーション: VAXバイナリ・イメージをAXPイメージに変換する処理。変換されたイメージはAXPシステムでTIEの援助によって実行される。変換は静的処理であり,できるだけ多くのVAXコードがネイティブな Alpha AXP命令に変換される。実行時に変換されなかったVAXコードに対しては,TIE が最終的に解釈する。

トランスレートされたイメージ: VAXイメージのオブジェクト・コードのトランスレーション によって作成されたAXP上の実行可能イメージまたは共有可能イメージ。トランスレートされたイメージは,トランスレーションのもとになるVAXイメージと同じ機能を実行し,トランスレートされたコードとオリジナル・イメージの両方を含む。VAX Environment Software Translatorを参照。

トランスレートされたコード: トランスレートされたイメージ内の AXPオブジェクト・コード。トランスレートされたコードとしては,次のコードがある。

  • 元のイメージの対応するVAXコードの動作を再現するAXPコード

  • Translated Image Environment(TIE)の呼び出し


ネイティブなイメージ: OpenVMS AXP コンパイラ,OpenVMS AXP リンカを使用して作られたOpenVMS AXP 上の実行可能イメージ,または共有可能イメージを, トランスレートされたイメージに対してこう呼ぶ。

バイト粒度: メモリ・システムの特性であり,隣接するバイトを異なるプロセスまたはプロセッサが同時に独立して書き込むことができる特性。

不可分な操作: AST(非同期システム・トラップ)サービス・ルーチンなど,他のシステム・イベントによって中断することができない操作。不可分な操作 は他のプロセスにとって1つの操作であるかのように見える。不可分な操作が開始された後,その操作は中断されずに,必ず最後まで終了する。

読み込み/変更/書き込み(リード・モディファイ・ライト)操作は通常,RISCマシンの命令レベルでは不可分な操作ではない。

不可分な命令(atomic instruction): 単一の分割不能な操作で構成される命令であり,これらの操作は中断せずに1つの操作としてハードウェアで処理される。

複雑命令セット・コンピュータ(CISC): メモリ内の位置に対して直接実行される複雑な操作も含めて,複雑な操作を実行する命令を取り扱うコンピュータ。このような操作の例としては,複数バイトのデータ移動や部分文字列検索を実行する命令がある。CISCコンピュータは通常, RISC(縮小命令セット・コンピュータ)コンピュータの反対語である。

複数命令発行: 1つのクロック・サイクルで複数の命令を出すこと。

プログラム・カンウタ(PC): CPUの中で,次に実行される命令の仮想アドレスを含む部分。現在の大部分の CPUはプログラム・カウンタをレジスタとして実現している。プログラマは命令セットを通じてこのレジスタを確認できる。Alpha AXP システムでは,プログラム・カウンタはレジスタではないので注意が必要。

プロセッサ・ステータス(PS): AXPシステムでは,クォドワードの情報で構成される特権付きプロセッサ・レジスタであり,現在のアクセス・モード,現在の割り込み優先順位レベル(IPL),スタック・アラインメント,複数の予約フィールドなどを含む。

プロセッサ・ステータス・ロングワード(PSL): VAXシステムで,1ワードの特権付きプロセッサ・ステータスと,プロセッサ・ステータス・ワード自体で構成される特権付きプロセッサ・レジスタ。特権付きプロセッサ・ステータス情報には,現在の割り込み優先順位レベル(IPL),前のアクセス・モード,現在のアクセス・モード,割り込みスタック・ビット,トレース・トラップ・ペンディング・ビット,互換モード・ビットなどが含まれる。

プロセッサ・ステータス・ワード(PSW): VAXシステムでプロセッサ・ステータス・ロングワードの下位ワード。プロセッサ・ステータス情報には条件コード(キャリ,オーバーフロー,0,負),演算トラップ・イネーブル・ビット(整数オーバーフロー,10進オーバーフロー,浮動小数点アンダーフロー),およびトレース・イネーブル・ビットが含まれる。

ページ・サイズ: システムのハードウェアが補助記憶との間でアドレス・マッピング,共有,保護,および移動のための単位として取り扱うバイト数。

ページレット: AXP環境で,512バイトのメモリ・サイズを指す表現。AXPシステムでは,特定のDCLコマンドとユーティリティ・コマンド,システム・サービス,およびシステム・ルーチンは,必要なメモリとクォータをページレット単位で入力として受け付け,出力として提供する。この結果,これらの構成要素の外部インターフェイスはVAXシステムの外部インターフェイスと互換性を維持するが,OpenVMS AXPは内部的にはCPUメモリのページ・サイズの整数倍でのみ,メモリを管理する。

読み込み/書き込み(リード・ライト)の順序: 1つのCPUのメモリに対する読み込み,書き込みなどの操作を実行エージェント(密接に結合されたシステム内の別のCPUまたは装置)から確認できるようになる順序。

読み込み/変更/書き込み操作(リード・モディファイ・ライト操作): メイン・メモリのデータを1つの割り込み不可能な操作として読み込み,変更し,書き込むハードウェア操作。


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項 ウェブマスターに連絡