library home hp.com home products and services support and drivers solutions
cd-rom home
End of Jump to page title
HP OpenVMS Systems
Documentation

Jump to content


HP OpenVMS

HP OpenVMS
V8.2 リリース・ノート【翻訳版】


前へ 次へ 目次 索引


5.30 OpenVMS I64 Version 8.2 に含まれない PL/I ライブラリ

V8.2

PL/I ライブラリ (ネイティブ・ライブラリと変換されたライブラリ) は, OpenVMS Alpha には含まれていましたが OpenVMS I64 には含まれていません。 PL/I コア・イメージのうち OpenVMS I64 にないものは以下のとおりです。

[SYSLIB]DPLI$RTLSHR.EXE
[SYSMSG]PLI$MSG.EXE
[SYSLIB]PLIRTL.IIF
[SYSLIB]PLIRTL_D56_TV.EXE

PL/I ライブラリを参照するアプリケーションや共有イメージは, Integrity サーバ用の OpenVMS I64 では動作しません。 (一般的に,PL/I で記述したコードを含むアプリケーションや共有イメージがそうです。) この制約は,ネイティブ・コードにも,変換された VAX および Alpha イメージにも,適用されます。

第 2.8 節 の,関連する注意事項を参照してください。

5.31 POSIX スレッド・ライブラリ

ここでは,POSIX スレッド・ライブラリ (旧名称は,DECthreads) に関する注意事項について説明します。

付録 A.8 節 の関連する注意事項も参照してください。

5.31.1 例外処理中のスタック・オーバフロー (I64 のみ)

V8.2

I64 システムでの例外処理には, Alpha システムの場合よりもかなり大きなスタック領域が必要です。 OpenVMS からアプリケーションを移植するときに,例外処理を使用するスレッドに未使用スタック領域が十分にないと, I64 での例外処理中に,このスレッドでスタック・オーバフローが発生することがあります。通常は,次の操作のいずれかに関連する ACCVIO の処理が不適切であったように見えます。

このような問題が発生した場合は,スレッドに割り当てられるスタックのサイズを数ページずつ増やしてみてください。最初は,スタックのサイズを 24 KB 大きくすることをお勧めします。

デフォルトのスタック・サイズは, I64 システム上でのスタック使用量が多いことに対応するため, 24 KB 大きくされました。アプリケーションが多数のスレッドをデフォルトのスタック・サイズで作成している場合,アプリケーションのメモリ・リソースが不足することがあります。このような状況になった場合は,プロセス・クォータを大きくするか,アプリケーションを変更して同時に存在するスレッドの数を減らしてください。

5.31.2 I64 システムでの THREADCP コマンドの動作

V8.2

OpenVMS I64 システム上の DCL コマンド THREADCP は,スレッド関連の 2 つのメイン・イメージ・ヘッダ・フラグ, UPCALLS と MULTIPLE_KERNEL_THREADS の問い合わせや変更には使用できません。代わりに, I64 システムでのスレッド・ヘッダ・フラグの設定や参照を行うための DCL コマンド SET IMAGE および SHOW IMAGE を使用する必要があります。

Alpha システムのユーザは,引き続き THREADCP コマンドを使用してください。

5.31.3 浮動小数点のコンパイルと例外 (I64 のみ)

V8.2

次の 2 つの古い cma スレッド・ライブラリ・ルーチンのいずれかを呼び出すソース・モジュールは, OpenVMS I64 上で使用するために /FLOAT=G_FLOAT コンパイラ修飾子 (または,言語固有の同等の修飾子) を指定してコンパイルしなければなりません。


cma_delay() 
 
cma_time_get_expiration() 

これらのルーチンは, VAX 形式の浮動小数点数だけを引数として受け入れます。通常,OpenVMS I64 コンパイラは,デフォルトで VAX 形式を使用する OpenVMS Alpha コンパイラとは異なり,デフォルトで IEEE 形式の浮動小数点数を使用します。この 2 つの cma スレッド・ルーチンは,Alpha と I64 のどちらでも, VAX 形式の浮動小数点引数だけを受け入れます。これらのルーチンの呼び出しを適切にコンパイルしないと, IEEE 形式の浮動小数点数が実行時に誤って渡され,予期しない例外が発生することがあります。

5.31.4 C 言語コンパイル・ヘッダ・ファイルの変更

V7.3-2

OpenVMS Version 7.3-2 では,次の変更が行われました。

5.31.5 新しい優先順位調整アルゴリズム

V7.3-2

OpenVMS Version 7.3-2 では,『Guide to the POSIX Threads Library』で説明されている適応型スレッド・スケジューリング動作が,新しい優先順位調整アルゴリズムとともに実装されました。場合によっては,新しいアルゴリズムでは,優先順位が異なる,スループット方針のスレッドが同期オブジェクトを共用することによる問題を回避できます。優先順位の調整により,アプリケーションのスループットや,システム全体の使用状況も改善できます。スループット・スケジューリング方針のスレッドの優先順位調整は,自動で,透過的に行われます。

5.31.6 プロセス・ダンプ

V7.3

POSIX スレッド・ライブラリで実行時に修正不能な重大エラー (アプリケーション内のデータ破損によって損傷したデータ構造など) が検出されると,ライブラリにより実行中のイメージが終了されることがあります。終了中に,ライブラリによりプロセス・ダンプ・ファイルの作成がトリガーされます (このファイルは, ANALYZE/PROCESS_DUMP によりエラー診断に使用されます)。このようなプロセス・ダンプ・ファイルのサイズは,エラー時のプロセスのアドレス空間に依存するため,非常に大きくなることがあります。

5.31.7 動的 CPU 構成の変更

V7.3

OpenVMS Version 7.3 以降,POSIX スレッド・ライブラリは,マルチプロセッサ Alpha システムを実行する CPU の数の動的変化に対応するようになりました。 1 つのイメージに対して,複数のカーネル・スレッドが使用できるように指定 (LINK/THREADS_ENABLE 修飾子または THREADCP コマンド動詞により) すると, POSIX スレッド・ライブラリが,アプリケーションの明白な並列処理を監視して,利用可能な CPU の数を最大とする数のカーネル・スレッドを作成します。それぞれのカーネルスレッドは,OpenVMS エグゼクティブによってスケジューリングされて別々の CPU で実行されるので,同時に実行することができます。

アプリケーションの実行中,オペレータは CPU を個別に停止または開始することができます。このような動的変化を反映して,これ以降にイメージがアクティブ化されたときに作成できるカーネル・スレッドの数が変化します。また,現在実行中のイメージにも反映されるようになりました。

CPU を追加または除去すると,スレッド・ライブラリは,追加,除去後のアクティブな CPU の数を照会し,プロセスが現在使用しているカーネル・スレッドの数と比較します。現在 CPU がカーネル・スレッドよりも多い場合,ライブラリは既存の POSIX スレッドを CPU まで延長します (必要に応じて,すぐに,または後に新しいカーネル・スレッドを作成します)。逆に CPU がカーネル・スレッドよりも少ない場合,ライブラリは余分のカーネル・スレッドを強制的にハイバネートさせ,残りのカーネル・スレッド上で POSIX スレッドを再度スケジューリングします。これにより,プロセスに関する限り,利用可能な数以上のカーネル・スレッドが, CPU リソースを奪い合うということがなくなります。

5.31.8 デバッガ計測機能は動作しない

V7.0

POSIX スレッド・デバッガの計測機能は動作しません。

『Guide to the POSIX Threads Library』の C.1.1 に記載されている,動作中のプログラムをデバッグする手順を使用すると,プロセスが ACCVIO メッセージで失敗する可能性があります。

5.32 RMS: グローバル・バッファ VA 管理の改善

V8.2

以前のリリースでは,アプリケーションが RMS グローバル・バッファを使用してファイルのオープンとクローズをあるパターンで繰り返すと, VASFUL (仮想アドレス空間満杯) エラーとなり,アプリケーションが失敗することがありました。

OpenVMS Version 8.2 からは, RMS が拡張仮想アドレス (VA) 空間管理を持つようになったため,これらの VASFUL エラーが発生する可能性が大幅に減少しました。

5.33 RMS Journaling

ここでは,RMS Journaling for OpenVMS に関する注意事項について説明します。

RMS Journaling の詳細は,『RMS Journaling for OpenVMS Manual』を参照してください。このマニュアルは,OpenVMS Documentation CD-ROM (アーカイブ・マニュアルのディレクトリ) に入っています。

5.33.1 カーネル・スレッドと互換性のないリカバリ・ユニット・ジャーナリング

V7.3

DECdtm Services は複数カーネル・スレッド環境でサポートされず, RMS リカバリ・ユニット・ジャーナリングは DECdtm Services に依存しているため,RMS リカバリ・ユニット・ジャーナリングは,複数カーネル・スレッドが有効になっているプロセスではサポートされません。

5.33.2 ジャーナル・ファイル作成の変更

V7.2

Version 7.2 より前には,リカバリ・ユニット(RU) ジャーナルは,ジャーナリングされるファイルと同じボリュームの [SYSJNL] ディレクトリに一時的に作成されていました。リカバリ・ユニット・ジャーナルのファイル名は RMS$process_id (process_id はプロセス ID の 16 進表現) という形式であり,ファイル・タイプは RMS$JOURNAL でした。

OpenVMS Version 7.2 では,RU ジャーナル・ファイルの作成に関して,次の点が変更されました。

これらの変更により,ジャーナル・ファイルの作成と削除で発生するディレクトリのオーバヘッドが減少します。

次の例に,以前のバージョンと現在のバージョンの両方のジャーナル・ファイルの作成を示します。

以前のバージョン: [SYSJNL]RMS$214003BC.RMS$JOURNAL;1
現在のバージョン: [SYSJNL.NODE1]CB300412.;1

RMS が [SYSJNL] ディレクトリまたはノード固有のディレクトリを見つけることができない場合は,RMS は自動的にそのディレクトリを作成します。

5.33.3 OSI 環境でのリカバリ・ユニット・ジャーナリングされたファイルへのリモート・アクセス

V6.1

ネットワーク内の他のノードからリモート・アクセスされるリカバリ・ユニット・ジャーナリング・ファイルのホストである OSI ノードでは,SYS$NODE をフェーズ IV 形式のノード名として定義しなければなりません。 SYS$NODE によって指定されるノード名は,ホスト・ノードのリカバリ・ユニット・ジャーナリング・ファイルにアクセスしようとするすべてのリモート・ノードから認識されなければなりません。また,リモート・ノードがこのノード名を使用して,ホスト・ノードとの間で DECnet 接続を確立できるように,ノード名は固有の名前でなければなりません。この制限は,OSI または複合 OSI 環境と非 OSI 環境でネットワークを介してアクセスされる,リカバリ・ユニット・ジャーナリング・ファイルにだけ適用されます。

5.33.4 順方向 (AI) ジャーナリング

V6.0

順方向 (AI) ジャーナリングを使用すれば,使用不能またはアクセス不能になったデータ・ファイルを回復することができます。AI リカバリでは,AI ジャーナル・ファイルを使用して,データ・ファイルのバックアップ・コピーをロール・フォワードすることで,障害が発生した時点でのデータ・ファイルの新しいコピーが作成されます。

プロセスが削除されたりシステム障害が発生した場合には,更新情報を AI ジャーナル・ファイルに書き込むことができますが,データ・ファイルに書き込むことはできません。 AI ジャーナリングだけが使用されている場合は,データ・ファイルとジャーナルの一貫性は自動的には維持されません。データ・ファイルに対して追加更新を行い,AI ジャーナルに記録すると,その後のロール・フォワード操作で一貫性のないデータ・ファイルが作成されることがあります。

リカバリ・ユニット (RU) ジャーナリングを AI ジャーナリングと組み合わせて使用した場合には,自動的なトランザクション・リカバリにより,AI ジャーナルとデータ・ファイルの間の一貫性が復元されます。

特定の状況では,AI ジャーナリングだけを使用するアプリケーションは,プロセスの削除やシステム障害の後でデータの不整合が発生しないように,予防措置をとることができます。たとえば,AI ジャーナリングされているファイルの手動ロール・フォワードを行うと,非共有 AI アプリケーション (シングル・アクセッサ) やスタンドアロン・システムで実行中の共有AI アプリケーションなどが関連するシステム障害の発生後に,ファイルの一貫性を維持できます。

しかし,共有 AI アプリケーションでは,クラスタ内でプロセスの削除やシステム障害が発生した後で,AI ジャーナル・ファイルと同期のとれていないデータ・ファイルに対してこれ以上の操作が実行されないようにするための措置はとられません。このような状況では,データ・ファイルと AI ジャーナル・ファイルの間の一貫性は,AI ジャーナリングと RU ジャーナリングを組み合わせて使用することで維持できます。

5.33.5 VFC 形式の順編成ファイル

VAX V5.0
Alpha V1.0

逆方向ジャーナリングやリカバリ・ユニット・ジャーナリングを使用している場合,固定長制御部付可変長 (VFC) 順編成ファイルを更新することはできません。VFC 順編成ファイル形式は,FAB のFAB$B_RFM フィールドのシンボリック値 FAB$C_VFC によって示されます。

5.34 RTL ライブラリ (LIB$)

ここでは,LIB$ ランタイム・ライブラリに関する注意事項について説明します。

5.34.1 RTL ライブラリ (LIB$) のヘルプ

V8.2

OpenVMS Version 8.2 の LIB$ ランタイム・ライブラリのヘルプ・ファイルには, LIB$LOCK_IMAGE ルーチンのヘルプがありません。この問題は,今後のリリースで修正される予定です。当面は,このルーチンの詳細な説明は『OpenVMS RTL Library (LIB$) Manual』を参照してください。

5.34.2 RTL Library (LIB$): 呼び出し標準ルーチン (I64 のみ)

V8.2

この注意事項では,ローテートするレジスタが,以下の呼び出し標準ルーチンでどのように取り扱われるかを明確化します。

LIB$I64_GET_FR
LIB$I64_SET_FR
LIB$I64_GET_GR
LIB$I64_SET_GR
LIB$I64_PUT_INVO_REGISTERS

呼び出し標準規則の ICB (invocation context block) およびメカニズム・ベクタは常に,あたかも,レジスタ・リネーム・ベース (CFM.rrb) とローテート・サイズ (CFM.sor) がいずれも 0 であったかのように,汎用レジスタ,浮動小数点レジスタ,およびプレディケート・レジスタを記録しています。言い換えると,ローテートするレジスタを使用しているときに,ローテーションの効果が無視されます。このことは,LIB$I64_PUT_INVO_REGISTERS ルーチンが使用するレジスタ・マスクについても同様です。というのは,これらのマスクは, ICB 構造体のフィールドによって定義されるからです。

現在は,補足的なアクセス・ルーチン LIB$I64_GET_FR, LIB$I64_SET_FR, LIB$I64_GET_GR および LIB$I64_SET_GRが,レジスタ・リネーム・ベース・レジスタとローテート・サイズ・レジスタの効果を調整しないで,不適切に,そのレジスタ番号パラメータを解釈しています。これは,誤りであり今後のリリースで修正される予定です。

それまでは,ICB またはメカニズム・ベクタ内の汎用レジスタ,浮動小数点レジスタ,およびプレディケート・レジスタを調べるプログラムや,実行時に見えるレジスタを探して内容を解釈するプログラムでは,保存された CFM レジスタを調べて,自身で適切に調整する必要があります。

5.35 Screen Management (SMG$) のドキュメント

『OpenVMS RTL Screen Management (SMG$) Manual』の最後にある参照情報のトピックに,次の情報を追加します。

V7.2

V7.1

5.36 SORT32 ユーティリティ

ここでは,OpenVMS Alpha および OpenVMS I64 Version 8.2 用の, SORT32 V08-010 に関する注意事項について説明します。詳細は, 第 5.20.8 項第 5.20.1 項 を参照してください。

Hypersort で修正されていない問題を回避する場合,または Hypersort に実装されていない機能を使用する場合に SORT32 を使用することをお勧めします。 Hypersort の注意事項については, 第 5.20 節 を参照してください。

5.36.1 DFS サービス・ディスクでの CONVERT の問題

V8.2

SORT,MERGE,および CONVERT 操作は, UNIX がサービスする DFS マウント・ディスクが出力先になっている場合, %SORT-E-BAD_LRL エラーを返します。

この制約事項を回避するには,次のいずれかを実行します。

5.36.2 一時作業ファイルが削除されないことがある

V7.3-2

SORT32 は,一時作業ファイルを削除しないことがあります。 SYS$SCRATCH や, SORT32 の作業ファイルを置いている場所を定期的にチェックし,削除されていない作業ファイルを削除してディスク・スペースを空けることができないかを調べてください。

5.36.3 複合条件のある SORT/SPECIFICATION: 要件

V7.3-1

SORT32 では,キー指定ファイルの複合条件が括弧で囲まれていない場合,複合条件に対する診断メッセージを出力しません。例を次に示します。

誤り:


/CONDITION=(NAME=TEST1, TEST=(Field2 EQ "X") AND (Field3 EQ "A")) 

正しい:


/CONDITION=(NAME=TEST1, TEST=((Field2 EQ "X") AND (Field3 EQ "A"))) 

5.36.4 可変長レコードでの性能の問題

V7.3-1

SORT32 では,入力ファイル内の最大レコード長 (LRL) 情報に基づいて,ソート作業ファイルの固定長のスロットが割り当てられます。性能を向上させるには,実際の最大レコード長に最も近い LRL 情報を入力ファイルに設定します。初期性能が低い場合は,C プログラムによって作成されたファイルをソートしており, LRL が必要以上に大きく (32767 まで) 設定されていることが原因と考えられます。

5.36.5 作業ファイル・ディレクトリの制約事項

V7.3

SORT32 の作業ファイルは,必要な数の作業ファイルを複数のファイル・バージョンにわたって格納できるディレクトリに作成する必要があります。

5.37 System Code Debugger (SCD) はまだ I64 システムで使用できない

V8.2

『OpenVMS System Analysis Tools Manual』で System Code Debugger (SCD) は I64 および Alpha システムで使用できるとしています。実際には,SCD は Version 8.2 の I64 では使用できません。今後のリリースで使用可能になる予定です。

5.38 システム・サービス

ここでは,OpenVMS のシステム・サービスに関する注意事項について説明します。

5.38.1 $GETJPI の項目コード SCHED_CLASS_NAME の記述誤り

V8.2

Version 8.2 の『OpenVMS System Services Reference Manual』とオンライン・ヘルプで $GETJPI の項目コード SCHED_CLASS_NAME が,誤って CLASS_NAME と記載されています。この誤りは,次回のメジャー・リリースで訂正される予定です。

5.38.2 PFN マップ・セクションに必要となる新しい GETSYI 項目コード (I64 のみ)

V8.2

OpenVMS VAX および Alpha では, PFN は 32 ビット値 (ビット 0 〜 31) です。ビット 31 が設定されている場合は,キャッシュされない I/O 空間を示します。

OpenVMS I64 では,PFN は 64 ビット値です。 PFN マップ・セクションを使用する,I64 用のプログラムは,大きなデータ・サイズを認識するように変更済みであることを示さなければなりません。これを示すには,次のシステム・サービスの呼び出しで,新しいフラグ SEC$M_ARGS64 を設定します。

SYS$CRMPSC_PFN_64
SYS$CREATE_GPFN
SYS$CRMPSC_GPFN_64
SYS$MGBLSC_GPFN_64

SEC$M_ARGS64 フラグは OpenVMS Alpha では無視されますが, OpenVMS I64 では設定されていなければなりません。 OpenVMS I64 でこのフラグが設定されていない場合,エラー・コード SS$_IVSECFLG が返されます。

32 ビット用のサービス SYS$CRMPSC および SYS$MGBLSC を使用して, OpenVMS I64 上の PFN マップ・セクションを作成したり,マッピングすることはできません。

OpenVMS I64 上の PFN の大きいデータ・サイズに対応するために, SYS$GETSYI システム・サービスが,新しい項目コード SYI$_PFN_MEMORY_MAP_64 を認識するように拡張されました。この項目コードの詳細については『OpenVMS System Services Reference Manual』を参照してください。

SYI$_PFN_MEMORY_MAP_64 が指定されると,このサービスは物理メモリのレイアウトを, 64 ビットのデータ構造体に返します。 I64 システムでは,新しい項目コードと新しいレイアウトを使用しなければなりません。 OpenVMS Alpha は,新しい形式を受け付けるように拡張されていますが,古い形式も引き続きサポートしています。

5.38.3 PFN マップ・セクションとキャッシュされないメモリ (I64 のみ)

V8.2

OpenVMS I64 システムでのマップされた I/O 空間には,キャッシュなしのアクセスを行わなければなりません。 PFN マップ・セクションをキャッシュされないメモリとして扱う必要がある場合は,このセクションの作成時に SEC$M_UNCACHED フラグを設定しなければなりません。次のシステム・サービスが,SEC$M_UNCACHED フラグを受け入れるようになりました。

SYS$CRMPSC_PFN_64
SYS$CREATE_GPFN
SYS$CRMPSC_GPFN_64

SYS$MGBLSC_GPFN_64 サービスは,このフラグを受け入れますが,無視します。 CACHED/UNCACHED 特性は,セクション属性として格納され,システムはセクションのマッピング時にこの属性を使用します。

OpenVMS Alpha システムでは, 4 つのサービスすべてが SEC$M_UNCACHED フラグを受け入れますが,無視します。

古いサービス SYS$CRMPSC と SYS$MGBLSC はアップデートされていないため,この新しいフラグは受け入れません。

5.38.4 SYS$ACM: I64 システムでの使用

V8.2

OpenVMS I64 Version 8.2 システムでは, ACME_SERVER プロセスは手動で起動する必要があります。 ACME_SERVER は SYS$ACM 要求を処理します。 SYS$ACM システム・サービスを使用するアプリケーションがある場合は, SYS$ACM を使用するアプリケーションを起動する前に,以下のコマンドを SYS$STARTUP_VMS.COM プロシージャに追加してください。


$ SET SERVER ACME/START/LOG 
$ SET SERVER ACME/CONFIG=(NAME=VMS,CRED=VMS) 
$ SET SERVER ACME/ENABLE 

注意

Advanced Server で提供される LAN Manager 認証を使用する場合は,必要な I64 コンポーネントの入手と設定手順について, Advanced Server V7.3A ECO4 のリリース・ノートを参照してください。

ACME_SERVER プロセスは, OpenVMS I64 の今後のリリースでは自動起動になる予定です。

5.38.5 I64 では SYS$GOTO_UNWIND は利用できない

V8.2

SYS$GOTO_UNWIND システム・サービスは, OpenVMS I64 システムでは利用できません。新しいサービス SYS$GOTO_UNWIND_64 を使用するようにコーディングし直してください。

アプリケーションが正しく移植されるように, SYS$GOTO_UNWIND は削除されました。詳細は,『HP OpenVMS Alpha から OpenVMS I64 へのアプリケーション・ポーティング・ガイド』を参照してください。

SYS$GOTO_UNWIND_64 サービスは, OpenVMS Alpha Version 7.3-2 およびそれ以降にも存在します。このため,アプリケーションでは共通のコードを使用できます。 SYS$GOTO_UNWIND_64 の詳細は,オンライン・ヘルプ,または『OpenVMS System Services Reference Manual』を参照してください。

5.39 タイマ・キュー・エントリ (TQE)

V7.3-1

OpenVMS Alpha Version 7.3-1 では,タイマ・キュー・エントリの管理方法が変更され,多くの TQE を使用するシステムの性能が大きく向上しました。この変更は,非特権アプリケーションにとっては無関係です。

また,特権コードで TQE を直接操作することはできません。特に TQE キュー・ヘッダ (TQE$L_TQFL/TQE$L_TQBL) 内のポインタに直接アクセスすると,通常はアクセス違反になります。ただし,特権コードで内部ルーチン exe_std$instimq/exe$instimq と exe_std$rmvtimq/exe$rmvtimq を使用して,タイマ・キュー・エントリを入力または削除することは可能です。

5.40 Traceback 機能

ここでは,Traceback 機能 (TRACE) に関する注意事項について説明します。

5.40.1 API エラー (I64 のみ)

V8.2

ここでは,『HP OpenVMS Version 8.2 新機能説明書』で説明されている新しいトレースバック機能の API に関する注意事項について説明します。現在は,rel_pc (相対 PC 値) や image_desc (イメージ名記述子) の引数にゼロを指定すると,処理エラーになります。これらの引数がゼロの場合でも,トレースバック機能では,これらの引数を無視してトレースバック処理を継続する必要があります。ところがトレースバックでは,これらの引数がゼロだと,トレースバック処理を中断し,呼び出し元プログラムに失敗の戻り値を返します。この問題は,今後のリリースで修正される予定です。

5.40.2 問題の修正

V8.2

これまで,Traceback 機能は, /RESIDENT 修飾子または /SHARED=ADDRESS_DATA 修飾子を指定してインストールされたイメージを正しく処理しませんでした。この問題が修正されました。 TRACE は,/RESIDENT 修飾子または /SHARED=ADDRESS_DATA 修飾子を指定してインストールされたイメージにシンボル情報が含まれていれば (つまり,/TRACEBACK を指定してリンクされていれば),これらのイメージ内の位置をシンボルで表示するようになりました。

5.41 Watchpoint ユーティリティ (I64 のみ)

V8.2

Watchpoint ユーティリティは,まだ OpenVMS I64 に移植されていません。弊社では,このユーティリティを今後のリリースで移植する予定です。

5.42 プログラム全体の浮動小数点モード (I64 のみ)

V8.2

OpenVMS Alpha では,浮動小数点丸め動作,例外動作,および精度制御は,コンパイル時に定義されます。各モジュールは,それぞれの浮動小数点動作の設定で,個別にコンパイルされます。たとえば,計算のオーバフローでオーバフロー例外がシグナル通知されるディレクティブで 1 つのモジュールをコンパイルし,別のモジュールを,計算のオーバフローで例外をシグナル通知するのではなく,値を InfinityT とするディレクティブでコンパイルすることができます。これらの 2 つのモジュールがコンパイルされ実行された場合,モジュールのコードは,コンパイル時に指定されたオーバフロー動作をします。

OpenVMS I64 では,浮動小数点丸め動作,例外動作,および精度制御は実行時に定義され,プログラム全体の浮動小数点モードの概念で制御されます。プログラム全体の浮動小数点モードでは,プログラムのメイン・エントリ・ポイント (リンカが決定したもの) を含むモジュールが,デフォルトの浮動小数点丸め動作,例外動作,および精度制御を定義するモジュールです。

大半のプログラムには,この相違点の影響はありません。要点は,ホワイト・ペーパー『Intel® Itanium® アーキテクチャにおける OpenVMS 浮動小数点演算について』を参照してください。このドキュメントは,次の Web サイトで参照できます。

http://h71000.www7.hp.com/openvms/integrity/resources.html


前へ 次へ 目次 索引