前へ

次へ

目次

索引

クラッシュ・ログ・ユーティリティ・エクストラクタ (CLUE) は，クラッシュ・ダンプの履歴と，各クラッシュ・ダンプの重要なパラメータを記録し，重要な情報を抽出して，要約するためのツールです。クラッシュ・ダンプは，システム・クラッシュが発生するたびに上書きされるため，最新のクラッシュに対してだけしか使用できませんが，クラッシュ履歴ファイル (OpenVMS VAX) と，各クラッシュに対して個別のリスト・ファイルを持つ要約クラッシュ履歴ファイル (OpenVMS Alpha) は，システム・クラッシュを永久的に記録します。

OpenVMS VAX と OpenVMS Alpha でのインプリメント上の相違点は，表 3-1 に示すとおりです。

表 3-1 OpenVMS VAX と OpenVMS Alpha の CLUE の相違点

属性	OpenVMS VAX	OpenVMS Alpha
アクセス方式	独立したユーティリティとして起動される。	SDA を通じてアクセスされる。
履歴ファイル	各クラッシュのクラッシュ・ダンプ・ファイルから 1 行の要約情報と詳細情報を格納した累積ファイル。	各クラッシュ・ダンプに対して 1 行の要約だけを格納した累積ファイル。各クラッシュの詳細情報は別のリスト・ファイルに格納される。
クラッシュ・ダンプのデバッグの他の使い方	なし。	CLUE コマンドは会話方式で使用でき，実行中のシステムを確認できる。
ドキュメンテーション	『OpenVMS システム管理者マニュアル』と『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』の Bookreader バージョン。	『OpenVMS システム管理者マニュアル』と『OpenVMS Alpha System Dump Analyzer Utility Manual』の Bookreader バージョン。

3.3.3 テスト

移行したバージョンの性能と機能を元のVAXバージョンと比較するために，アプリケーションをテストしなければなりません。

テストではまず，VAXアプリケーションに対して一連のテストを実行することにより，アプリケーションに対して基準となる結果を設定します。

アプリケーションをAlphaシステムで実行した後，次の2種類のテストを実行できます。

• アプリケーションのVAXバージョンに対して使用される標準テスト

• アーキテクチャの変更による問題を特に確認するための新しいテスト

3.3.3.1 VAXテスト

新しいアーキテクチャを使用することにより，アプリケーションの一部が変更されるため，OpenVMS Alphaにアプリケーションを移行した後，そのアプリケーションをテストすることは特に重要です。アプリケーションの変更によってエラーが発生するだけでなく，新しい環境では，VAXバージョンで検出されなかった問題が発生する可能性があります。

移行されたアプリケーションをテストするには，次の操作が必要です。

1. 移行する前に，アプリケーションにとって必要な標準データを入手する

2. アプリケーションだけでなく，一連のテストも移行する(テストがAlphaでまだ準備されていない場合)。

3. Alphaシステムでテストを検証する

4. 移行したアプリケーションに対して移行したテストを実行する

ここでは，リグレッション・テストとストレス・テストが役立ちます。ストレス・テストは，同期に関するプラットフォームの相違点をテストするために特に重要です。特に，複数の実行スレッドを使用するアプリケーションの場合は，ストレス・テストが役立ちます。

3.3.3.2 Alphaテスト

標準テストは，移行したアプリケーションの機能を検証するためにかなり長くかかりますが，移行固有の問題を調べるためのテストをいくつか追加しなければなりません。特に次の点に注意してください。

• コンパイラの相違点

  最適化およびデータ・アラインメントの変更

• アーキテクチャの相違点

  たとえば命令の不可分性，メモリの不可分性，読み込み/書き込み順序などの変更

• 統合

  異なる言語で作成されたモジュールや，トランスレートしなければならなかったモジュールの統合

3.3.4 潜在的なバグの発見

作業方法に何も問題がなく，移行に関するすべての指示に従っているにもかかわらず，OpenVMS VAX システムでは問題が発生したことのないプログラムでバグを検出することがあります。たとえば，VAX コンピュータでは，プログラムで一部の変数を初期化しないエラーが発生しても問題になりませんが，Alpha コンピュータでは演算例外が発生します。2 つのアーキテクチャでは使用できる命令が違い，コンパイラが命令を最適化する方法も変更されているため，移行処理で同じような問題が発生する可能性があります。これまで隠れていたバグをすべて解決できるような新しい方法はありませんが，プログラムを移植した後，他のユーザが実際に使用を開始する前に，プログラムを徹底的にテストする必要があります。

3.4 移行したアプリケーションのソフトウェア・システムへの統合

再コンパイルまたはトランスレーションによってアプリケーションを移行した後，移行によって他のソフトウェアとのやりとりに問題が発生していないかどうかを確認しなければなりません。

VAX と Alpha システム間の相互操作性に関する問題の原因として，次のことが考えられます。

• VMSクラスタ環境のAlpha システムと VAX システムは，別々のシステム・ディスクを使用しなければなりません。アプリケーションが正しいシステム・ディスクを参照しているかどうか，確認する必要があります。

• イメージ名

  混在する環境では，アプリケーションが正しいバージョンを参照するかどうかに関して，次のことを確認してください。

  • イメージのネイティブVAXバージョンとネイティブなAlphaバージョンが同じ名前を持つこと

  • イメージをトランスレートしたバージョンで名前の最後に"_TV"という文字列が追加されていること

• 再コンパイルしたイメージではデータが自然にアラインされていると考えられますが，トランスレートされたイメージでは，元のVAXイメージと同様にデータはアラインされていない可能性があります。

この章では，アプリケーションを構成するソース・ファイルを再コンパイルおよび再リンクすることにより，VAXシステム上で動くアプリケーションをAlphaシステムに移行する (migrate) プロセスについて，その概要を説明します。

一般に，アプリケーションが高級プログラミング言語で作成されている場合には，わずかな作業でAlphaシステムで実行できるようになります。高級言語では，アプリケーションをマシン・アーキテクチャから分離します。さらに，Alphaシステム上のプログラミング環境のほとんどの部分は，VAXシステムのプログラミング環境と同じです。したがって，Alpha版の各言語のコンパイラと OpenVMSリンカ・ユーティリティを使用すれば，アプリケーションを構成するソース・ファイルを再コンパイルおよび再リンクでき，ネイティブな Alphaイメージを作成できます。

アプリケーションがVAX MACROで作成されている場合は，最低限の作業だけで Alphaシステム上でも実行できる可能性があります。ただし一般には，VAXのアーキテクチャに依存する何らかの要素が含まれており，それに応じた変更を加えなければなりません。

内側のモードや高い割り込み優先順位レベル(IPL)で動作する特権アプリケーションは，コード内でオペレーティング・システムの内部的な動作に関するさまざまな仮定を行っているので，大幅な書き換えが必要になります。一般に，このようなアプリケーションは OpenVMS VAXオペレーティング・システムのメジャー・リリースのたびに大幅な変更を加える必要が生じます。

VAXシステムでサポートされる言語の多くは，Alphaシステムでもサポートされます。たとえば FORTRAN や C などです。Alphaシステムで共通に使用できるプログラミング言語のコンパイラについての詳しい説明は，第 11 章 を参照してください。

Alphaシステムで使用出来るコンパイラは，それぞれVAXシステムの対応するコンパイラと互換性を維持するように設計されています。各コンパイラは言語標準規格に準拠し，また，VAXの言語拡張機能の大部分をサポートします。コンパイラは，VAXシステムの場合と同じ省略時のファイル・タイプで，出力ファイルを作成します。たとえば，オブジェクト・モジュールのファイル・タイプは.OBJです。

しかし，VAXシステムのコンパイラがサポートする一部の機能は，Alphaシステムの同じコンパイラでサポートされません。さらに，Alphaシステムのいくつかのコンパイラは，VAXシステムの対応するコンパイラがサポートしない新しい機能をサポートします。また互換性を維持するために，一部のAlphaコンパイラは互換モードをサポートします。たとえば，DEC C for OpenVMS Alpha システムのコンパイラはVAX C互換モードをサポートし，このモードは /STANDARD=VAXC修飾子を指定することにより起動されます。

4.2 Alphaシステムでのアプリケーションの再リンク

ソース・ファイルを正しく再コンパイルした後，アプリケーションを再リンクしてネイティブなAlphaイメージを作成しなければなりません。リンカは現在の VAXシステムと同じファイル・タイプで，出力ファイルを作成します。たとえば，省略時の設定では，リンカはイメージ・ファイルのファイル・タイプとして .EXEを使用します。

Alphaシステムではある種のリンク作業を実行する方法が異なるため，アプリケーションを構築するために使用するLINKコマンドを変更しなければなりません。次のリストは，アプリケーションのビルド手順に影響を与える可能性のある，これらのリンカの変更点を説明しています。詳しくは『OpenVMS Linker Utility Manual』を参照してください。

• 共有可能イメージ内でのユニバーサル・シンボルの宣言--- アプリケーションが共有可能イメージを作成する場合には，おそらくアプリケーションのビルド・プロシージャにVAX MACROで作成された転送ベクタ・ファイルが含まれており，共有可能イメージ内のユニバーサル・シンボルが宣言されています。Alphaシステムでは，転送ベクタ・ファイルを作成するかわりに，SYMBOL_VECTORオプションを指定することにより，リンカ・オプション・ファイルでユニバーサル・シンボルを宣言しなければなりません。

• OpenVMSエグゼクティブに対するリンク--- VAXシステムでは，ビルド・プロシージャにシステム・シンボル・テーブル・ファイル(SYS.STB)をインクルードすることにより，OpenVMSエグゼクティブに対してリンクします。Alphaシステムでは，/SYSEXE修飾子を指定することにより，OpenVMSエグゼクティブに対してリンクします。

• イメージの性能の最適化--- Alphaシステムでは，リンカは作成したイメージの性能を向上させるために最適化を行います。さらにリンカは，常駐イメージとしてインストール可能な共有可能イメージを作成できます。この結果，さらに性能を向上できます。

• 共有可能イメージの暗黙の処理---VAXシステムでは，リンク操作で共有可能イメージを指定した場合，リンカは共有可能イメージがリンクされる対象となるすべての共有可能イメージも処理します。Alphaシステムでは，ビルド・プロシージャがこれらの共有可能イメージを含む場合，これらのイメージを明示的に指定しなければなりません。

リンカは 表 4-1 にある Alphaシステム固有の修飾子とオプションをサポートします。表 4-2 は，VAX システムではサポートされ，Alphaシステムのリンカではサポートされないリンカ修飾子を示しています。

表 4-1 OpenVMS Alphaシステム固有のリンカ修飾子とオプション

修飾子	説明
/DEMAND_ZERO	リンカがデマンド・ゼロ・イメージ・セクションを作成する方法を制御する。
/DSF	OpenVMS Alpha システムコード・デバッガで使用するために，デバッグ・シンボル・ファイル (DSF) と呼ぶファイルを作成するようにリンカに要求する。
/GST	共有可能イメージに対してグローバル・シンボル・テーブル(GST) を作成することをリンカに要求する(省略時の設定)。ランタイム・キット用に共有可能イメージを作成する場合には，/NOGSTを指定する方が一般的である。
/INFORMATIONALS	リンク操作で情報メッセージを出力することをリンカに要求する(省略時の設定)。/NOINFORMATIONALSを指定する方が一般的であり，その場合には情報メッセージは出力されない。
/NATIVE_ONLY	作成しているイメージに，コンパイラが作成したプロシージャ・シグネチャ・ブロック (PSB) 情報を渡さない ようにリンカに要求する (省略時の設定)。 リンク中に /NONATIVE_ONLY を指定した場合には，イメージ・アクティベータは，ジャケット・ルーチンを起動するために，リンク操作に対する入力ファイルとして指定されたオブジェクト・モジュールで提供された PSB 情報を使用する。ネイティブな Alpha イメージが，トランスレートされた VAX イメージと連携動作するには，ジャケット・ルーチンが必要である。
/REPLACE	コンパイラによって要求された場合，作成中のイメージの性能を向上するための最適化を行うことをリンカに要求する(省略時の設定)。
/SECTION_BINDING	常駐イメージとしてインストール可能な共有可能イメージを作成することをリンカに要求する。
/SYSEXE	リンク操作で解釈されなかったシンボルを解釈するために OpenVMSエグゼクティブ・イメージ(SYS$BASE_IMAGE.EXE)を処理することをリンカに要求する。
オプション	説明
SYMBOL_TABLE=オプション	共有可能イメージに関連するシンボル・テーブル・ファイルにユニバーサル・シンボルだけでなく，グローバル・シンボルも登録することをリンカに要求する。省略時の設定では，リンカはユニバーサル・シンボルだけを登録する。
SYMBOL_VECTOR=オプション	Alpha共有可能イメージでユニバーサル・シンボルを宣言するために使用する。

表 4-2 OpenVMS VAX システム固有のリンカ・オプション

オプション	説明
BASE= オプション	リンカがイメージを割り当てるベース・アドレス (先頭アドレス) を指定する。
DZRO_MIN= オプション	リンカがイメージ・セクションからページを取り出し，それを新たに作成したデマンド・ゼロ・イメージ・セクションに配置する前に，リンカがイメージ・セクションで検出しなければならない連続した初期化されていないページの最小数を指定する。デマンド・ゼロ・イメージ・セクション (初期化されたデータを含まないイメージ・セクション) を作成すると，リンカはイメージのサイズを小さくできる。
ISD_MAX= オプション	イメージ内で認められるイメージ・セクションの最大数を指定する。
UNIVERSAL= オプション	共用可能イメージ内のシンボルをユニバーサルとして宣言し，リンカがそのシンボルを共用可能イメージのグローバル・シンボル・テーブルに登録するようにする。

4.3 VAXシステムとAlphaシステムの算術演算ライブラリ間の互換性

OpenVMS Mathematics (MTH$)ランタイム・ライブラリに対して標準的な VMS呼び出しインターフェイスを使用する算術演算アプリケーションを，Alphaシステムに移行するときには，MTH$ルーチンの呼び出しを変更する必要はありません。これは，MTH$ルーチンをDigital Portable Mathematics Library (DPML) for Alphaシステムの対応するmath$に変換するためのジャケット・ルーチンが準備されているからです。しかし，JSBエントリ・ポイントとベクタ・ルーチンに対して実行される呼び出しは，DPMLでサポートされません。DPMLルーチンはOpenVMS MTH$ RTL のルーチンと異なっており，算術演算の結果の精度にわずかな違いが発生する可能性があります。

将来のライブラリとの互換性を維持し，移植可能な算術演算アプリケーションを開発するには，この呼び出しインターフェイスを使用するのではなく，選択した高級言語 (たとえばDEC C やDEC FORTRANなど)を通じて提供されるDPMLルーチンを使用することが適切です。DPMLルーチンを使用すれば，性能と精度も大幅に向上できます。

DPMLルーチンについての詳しい説明は，『Digital Portable Mathematics Library』を参照してください。

前へ

次へ

目次

索引