日本-日本語

製品  >  ソフトウェア  >  OpenVMS  >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS V8.3
ライブラリ

タイトルページ
目次
まえがき
第 1 章:インストールに関する注意事項
第 2 章:関連製品に関する注意事項
第 3 章:一般ユーザ向けの注意事項
第 4 章:システム管理に関する注意事項
第 5 章:プログラミングに関する注意事項
第 6 章:ハードウェアに関する注意事項
付録 A:リタイア製品情報
付録 B:インターロックされたメモリ命令の使用
索引
PDF
OpenVMS ホーム

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


目次 索引



V8.3

OpenVMS Alpha および OpenVMS I64 の Version 8.2 から, DECC$*.OLB オブジェクト・ライブラリに新しいエントリ・ポイントが追加されなくなりました。これは,新しい C RTL エントリ・ポイントはこれらのライブラリを通じてプレフィックス付きのエントリにマッピングされないことを意味します。たとえば,新しい OpenVMS Version 8.3 のエントリ・ポイント cryptは, /PREFIX=NONE 付きでコンパイルすると, cryptから decc$cryptにマッピングされません。

5.10 呼び出し標準規則とローテートするレジスタ (I64 のみ)

V8.3

ここでの説明は『HP OpenVMS Calling Standard』の情報を補足するものです。

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

以前は,補足的なアクセス・ルーチン LIB$I64_GET_FR, LIB$I64_SET_FR, LIB$I64_GET_GR および LIB$I64_SET_GR (『HP OpenVMS Calling Standard』の第 4.8.4 項を参照) が,レジスタ・リネーム・ベース・レジスタとローテート・サイズ・レジスタの効果を調整しないで,不適切に,そのレジスタ番号パラメータを解釈していました。この誤りは修正されました。

5.11 Common Data Security Architecture (CDSA) に関する考慮

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

5.11.1 Secure Delivery

V8.3

インターネット経由でファイルをダウンロードすることは,手軽にソフトウェアのアップデートをしたいと思う OpenVMS ユーザにとっては,必須条件になりつつあります。一方で,これらのユーザは,セキュリティの脆弱性に用心深くなっています。 Secure Delivery は,公開鍵と電子署名技術を用いており, OpenVMS ユーザは HP および他社の OpenVMS ベンダーからダウンロードするファイルが本物であることを確認することができます。

Secure Delivery は,OpenVMS Version 8.3 では完全に機能します。詳細は,『HP OpenVMS V8.3 新機能説明書』を参照してください。

5.11.2 インストールと初期化に関する考慮

V7.3-2

CDSA は,オペレーティング・システムのインストール時に自動的にインストールされます。

  • 新しいバージョンの CDSA を,オペレーティング・システムのアップグレードとは別にインストールする場合は, CDSA のアップグレード・プロシージャを実行する必要があります。


    $ @SYS$STARTUP:CDSA$UPGRADE 
    


    アップグレード・プロシージャを実行する前に,すべての CDSA アプリケーションをシャットダウンしてください。
    システムをリブートするときに,アップグレード・プロシージャを再実行する必要はありません。また,OpenVMS スタートアップ・プロシージャにアップグレード・プロシージャを追加する必要もありません。

  • 使用中のシステムから CDSA を削除しないでください。 CDSA を削除するように見えるオプションがありますが, CDSA に対する PCSI コマンドの PRODUCT REMOVE はサポートされていません。 (このオプションはインストールに使用する PCSI ユーティリティの機能です)。 CDSA とオペレーティング・システムは,同時にインストールされ,密接に結合しているので,OpenVMS から CDSA を削除しようとすると,正常に動作しないで,望ましくない影響が発生する可能性があります。 CDSA を削除しようとすると,次のようなメッセージが表示されます。


    %PCSI-E-HRDREF, product CPQ AXPVMS CDSA V2.2 is referenced by DEC AXPVMS OPENVMS V8.3 
    -PCSI-E-HRDRF1, the two products are tightly bound by this software dependency 
    



5.12 デバッグ・モード: CPUSPINWAIT バグ・チェックの回避

永続的な条件

OpenVMS オペレーティング・システムには,複雑なハードウェアの問題やソフトウェアの問題をデバッグするのに役立つように,多くの特殊操作モードが準備されています。一般には,これらの特殊モードを使用すれば,特別なレベルでトレース,データの記録,一貫性チェックを行うことができ,このような機能は,問題があるハードウェア構成要素やソフトウェア構成要素を突き止めるのに役立ちます。これらの操作モードは,システム・パラメータ MULTIPROCESSING, POOLCHECK,BUGCHECKFATAL,SYSTEM_CHECK によって制御されます。

一般に I/O 負荷の高い特定の状況で,これらの特殊モードのいずれかを使用している場合は ( たとえば,デバイス・ドライバや他の複雑なアプリケーションをデバッグする場合など ),CPUSPINWAIT バグ・チェックが発生することがあります。特に,スピンロックのある状態で長期間実行する特権コードに対して CPUSPINWAIT バグ・チェックが発生します。スピンロックは,クリティカル・セクションのエントリ・ポイントとイグジット・ポイントを区切るために使われ,この場合のように連続的に使うことはできません。

CPUSPINWAIT バグ・チェックを防止するには,これらのシステム・パラメータに対して,システムのデフォルト設定を使用するか,またはシステムの負荷を低下させます。

何らかの理由でデフォルトの設定を変更しなければならない場合は, SMP_ LNGSPINWAIT システム・パラメータを 9000000 に設定することで,問題が発生する可能性を減らせます。

5.13 Delta/XDelta デバッガ

ここでは,OpenVMS Alpha および I64 システム上で動作する OpenVMS Delta および XDelta デバッガに関する注意事項について説明します。

OpenVMS Debugger に関する注意事項は 第 5.29 節 を参照してください。

5.13.1 XDelta のレジスタ表示に関する考慮 (I64 のみ)

V8.2

OpenVMS I64 上の XDelta は,あたかも,レジスタ・リネーム・ベース (CFM.rrb) とローテート・サイズ (CFM.sor) がいずれも 0 であるかのように,汎用レジスタ,浮動小数点レジスタ,およびプレディケート・レジスタを表示します。言い換えると,ローテートするレジスタを使用しているときには,ローテイションの効果は無視されます。この状況は,今後のリリースで修正される予定です。詳細は 第 5.10 節 を参照してください。

5.14 ファイル・アプリケーション: 『Guide to OpenVMS File Applications』の訂正

永続的な訂正

マニュアル『Guide to OpenVMS File Applications』が改訂されるときには,下記の訂正が盛り込まれます。

  • 表 1-4 は誤解を招く可能性があります。ファイル・フォーマットの比較表で,ODS-2 や ODS-5 のファイル・フォーマットでのディレクトリの制限として 256 としてあります。この説明は,256 ディレクトリ・レベル とし,ユーザが,ディレクトリ数が 256 に制限されているものと誤解しないようにする必要があります。
    『OpenVMS システム管理者マニュアル』の類似した表は Version 8.2 で訂正されました。

  • 第 6.6.3 項の第 4 パラグラフ (Note はカウントしない) を,以下の内容に置き換えます。
    「プログラム内で使用するルート・デバイス論理名を, SET DEFAULT コマンドで定義する際には,DCL コマンドの DEFINE または ASSIGN で /TRANSLATION_ATTRIBUTES=CONCEALED 修飾子を使用して,この論理名が隠し装置の論理名であることを指定します。隠し装置の論理名をルート・デバイス論理名として定義するためには,ルート・ディレクトリがピリオド (.) で終わっていなければなりません (例: DUA22:[ROOT.])。また,デバイスの指定が,物理デバイス名でなければなりません。ルート・デバイス論理名の等価名には,他の論理名を含めることはできません。ディレクトリを指定するときには,ルート・ディレクトリに対して,後のピリオドだけを使用することができます。」



5.15 RMS 構造体についての HP BLISS コンパイラの警告 (I64 のみ)

永続的な条件

RMS ユーザ構造体 (たとえば,FAB,RAB) の割り当てに使用できる BLISS マクロ ($xxx_DECL) に,クォドワード・アラインメントが追加されました。プロセッサが高速になるほど,アラインメント・フォルトは性能に悪影響を及ぼします。アラインメントをマクロ内に直接実装することにより,これらのマクロを使用する,BLISS で書かれた多数の OpenVMS ユーティリティおよびユーザ・アプリケーションは,性能が改善されます。

該当するマクロは,$FAB_DECL,$NAM_DECL,$NAML_DECL,$RAB_DECL, $RAB64_DECL,$XABALL_DECL,$XABDAT_DECL,$XABFHC_DECL,$XABITM_DECL, $XABJNL_DECL,$XABKEY_DECL,$XABPRO_DECL,$XABRDT_DECL,$XABRU_DECL, $XABTRM_DECL,および $XABSUM_DECL です。

RMS マクロに追加されたアラインメントにより,コンパイラがアラインメント競合の警告を出力することがあります。コンパイラの警告があるプログラムでも,正しくリンクして,実行することができます。ただし,ソースに簡単な変更を加えて,警告を取り除くことをお勧めします。

これらのマクロを BLISS アプリケーション内で使用し,宣言に ALIGN 属性が含まれている場合, BLISS コンパイラは "conflicting or multiply specified attribute" という警告を出力します。たとえば,FAB: $FAB_DECL ALIGN(2) という宣言に対して,警告が出力されます。この警告は,クォドワード・アラインメント (ALIGN(3)) を指定したとしても出力されます。これらのマクロに関連する明示的な ALIGN 属性を削除する必要があります。

さらに,これらの割り当てが, ALIGN(3) と競合する明示的なアラインメント (ALIGN(3) 未満のもの) を持つ PSECT に含まれている場合,BLISS コンパイラは, "align request negative or exceeds that of psect" という警告を出力します。たとえば,次の宣言に対して警告が出力されます。


 PSECT OWN = $OWN$ (..., ALIGN(2), ...) 
 
 OWN 
 
     FAB = $FAB_DECL, ... 

BLISS アプリケーションの再コンパイル時に PSECT のアラインメントに関する警告が表示された場合, PSECT のアラインメントを ALIGN(3) (またはそれ以上) に調整してください。まれに,PSECT 間でデータが隣接していると仮定しているアプリケーションが存在することがあります。この変更により,このような仮定が成り立たなくなることがあります。そのため,コードでこのうような仮定を行っていないかチェックし,必要な変更を行ってください。

多くの OpenVMS ユーティリティが BLISS で記述されていますが, OpenVMS 全体のビルドで発生した警告はわずかでした。この警告を取り除くために OpenVMS に加えた変更は他にはありませんでした。このため,修正が必要なユーザ・アプリケーションは,ほとんどないと考えられます。

5.16 RMS の Must-Be-Zero エラーの可能性: FAB 内に新しいファイル・オプション用の場所を確保

V8.3

RMS のユーザ・ファイル・アクセス・ブロック (FAB) には,未割り当ての領域がごくわずかしかありません。 FAB を通じて実装されるファイル処理オプションを将来拡張できるように, FAB (FAB$L_FOP)内のファイル処理オプション・フィールドの最後の未割り当てビットが, FAB$V_EXTEND_FOPオプションとして定義されました。このオプションは,FAB 内で以前使用されていなかった領域に置かれる以下の 2 つの新しい FAB フィールドへの割り当てを要求し検査するために,将来使用されます。

  • FAB$W_FOPEXT: ワード・フィールド FOPEXT は,将来実装が必要になる新しいファイル処理オプションの定義用として予約されています。

  • FAB$W_RESERVED_MBZ: ワード・フィールド RESERVED_MBZは,将来の使用のために予約されています。その用途は現在決定されておらず,将来定義されます。

将来のリリースで新しいファイル処理オプションを実装するときには, FOPEXTフィールドの新しいオプションを利用するために, FAB$L_FOPフィールドの FAB$V_EXTEND_FOPビットをオンにする必要があります。ただし,このビットをオンにすると, FOPEXTフィールドの未定義のビットがオフで, FAB$W_RESERVED_MBZにゼロが格納されていることも示します。この条件が満たされていない状態でこのビットをオンにすると, RMS のすべてのファイル・レベル・サービスで,回復不可能なエラー (RMS-F-FOPEXTMBZ)が返されます。

EXTEND_FOPオプションの追加は完全に上位互換性があります。ただし,ユーザが FAB$L_FOPフィールドのこの最後のビットを誤ってオンにし,この 2 つの新しい FAB フィールドのいずれかがゼロでない場合は例外です。以前は, FAB$L_FOPフィールドのこの最後のビットが誤ってオンになっていた場合でも,RMS はそれを無視していました。

RMS-F-FOPEXTMBZエラーが返される場合は, FAB$L_FOPフィールドの EXTEND_FOPオプションをオフにするか, 2 つの新しいフィールド FAB$W_FOPEXTおよび FAB$W_RESERVED_MBZをクリアする必要があります。

5.17 HP COBOL ランタイム・ライブラリ (RTL)

V8.3

OpenVMS Alpha および OpenVMS I64 Version 8.3 では,HP COBOL RTL (DEC$COBRTL) は V2.8-781 にアップデートされました。

5.18 I64 用の HP Fortran

V8.3

OpenVMS Integrity サーバ用の HP Fortran コンパイラは, OpenVMS Alpha の HP Fortran 90 を移植したものです。このコンパイラは OpenVMS I64 システム上で動作し, OpenVMS I64 システム用のオブジェクトを生成します。このオブジェクトは, OpenVMS I64 上の標準リンカを使用してリンクされます。このコンパイラは,OpenVMS I64 Version 8.2 以降を必要とします。

OpenVMS Integrity サーバ用の HP Fortran のコマンド行オプションと言語機能は,以下の例外を除いて,OpenVMS Alpha システム用の HP Fortran 90 のものと同じです。

  • 浮動小数点の計算
    要点は,ホワイト・ペーパー『Intel® Itanium® アーキテクチャにおける OpenVMS 浮動小数点演算について』を参照してください。このドキュメントは,次の Web サイトで参照できます。

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

  • デフォルトの浮動小数点データ型は IEEEです。 (つまり,/FLOAT=IEEE_FLOAT がデフォルトです)。

  • /IEEE_MODE 修飾子のデフォルト値は,/IEEE_MODE=DENORM_RESULTS です。

  • ユーザは /FLOAT の値を 1 つと,/IEEE_MODE の値を 1 つ選択し,アプリケーション全体でその値を維持しなければなりません。

  • F90 コンパイラだけがサポートされています。以前 /OLD_F77 修飾子で起動されていた F77 コンパイラは利用できません。 FDML や CDD のサポートなど, Alpha F77 コンパイラに含まれていて, Alpha F90 コンパイラでは利用できない一部の機能が, I64 F90 コンパイラに実装されています。詳細は,Fortran V8.0 または V8.1 製品のリリース・ノートを参照してください。

  • /ARCH 修飾子と /TUNE 修飾子での値 Alpha は,コンパイル・アンド・ゴーの互換性を保つために,コンパイラ起動コマンドで利用することができます。これらの値を無視したことを示す情報メッセージが表示されます。

インストール手順など,このリリースについての詳細は, Fortran V8.0 または V8.1 製品のリリース・ノートを参照してください。リリース・ノートを抽出するには, Fortran PCSI キットが置かれているディレクトリをデフォルトとして設定し,次のコマンドのいずれかを入力します。


$ PRODUCT EXTRACT RELEASE_NOTES FORTRAN ! For TXT file 
$ PRODUCT EXTRACT FILE FORTRAN/SELECT=FORTRAN_RELEASE_NOTES.PS ! For PS file 



5.19 OpenVMS 用 HP MACRO

OpenVMS MACRO コンパイラは,OpenVMS VAX システム用に記述された Macro-32 ソース・コード (VAX MACRO アセンブラ) をコンパイルし, OpenVMS Alpha および OpenVMS I64 システムで動作する機械語コードに変換します。ここでは,MACRO コンパイラに関する注意事項について説明します。

5.19.1 OpenVMS I64 用 HP MACRO

V8.3

HP MACRO for OpenVMS I64 コンパイラには,以下の注意事項があります。

  • OpenVMS Version 8.3 よりも前のバージョンでは,コンパイラは HALT 命令に対して誤ったコードを生成していました。 I64 プラットフォームでは, HALT 命令は Itanium の break命令と,予約リテラル値 BREAK$C_SYS_HALTを使用して実装されます。コンパイラの構築環境のバグにより, Macro-32 コンパイラが誤ったリテラル値を使用していました。この問題はバージョン 8.3 で修正されました。 HALT 命令を使用しているすべてのコードを,バージョン 8.3 のコンパイラで再コンパイルする必要があります。バージョン 8.3 よりも前のシステムでは,次のようにして正しい動作を実現することができます。


    $BREAKDEF 
    IA64_HALT #BREAK$C_SYS_HALT ; Issue break instruction with correct literal 
    HALT                        ; Use HALT builtin to inform compiler that this ends the flow of control 
    

  • コンパイラは, HALTBPT,および EVAX_BUGCHKの前の命令を最適化によって除去する可能性があります。オプティマイザは,これらの命令が,ダンプ・ファイルを書き出したり,デバッグ環境に制御を渡すことで,すべてのレジスタを暗黙に読み込む特殊な命令になっていることを認識しません。使用されていないように見える命令は,誤って削除されます。これらの命令の特殊な動作についてコンパイラに通知することができます。任意の命令を最終的なオブジェクト・ファイルに残すように指示する構文はありませんが, IA64_LD8_A ビルトインを回避策として使用できます。このビルトインについては,次の Macro-32 の段落を参照してください。また, /NOOPTIMIZEを指定すると,使用されていないように見える命令も残りますが,コードの実行速度が遅くなり,またコードのサイズが大きくなります。

  • コンパイラは,使用されていないように見えるメモリのロードを最適化によって除去することがあります。コンパイラのオプティマイザは,メモリのロード結果が使用されるかどうかを認識することができます。結果が使用されていないと判断されると,オプティマイザはメモリ・ロードを削除します。しかし,コードによっては,たとえば IPL を上げる前にページをメモリにページ・インさせるためにメモリのロードを使用している場合があります。そのような場合は,命令が除去されるとページがメモリにページ・インされなくなり,高い IPL での以降のコードで,高い IPL 例外での回復不可能なページ・フォルトが発生します。任意の命令を最終的なオブジェクト・ファイルに残すように指示する構文はありませんが, IA64_LD8_A ビルトインを回避策として使用できます。バージョン 8.3 で新たに追加された IA64_LD8_A ビルトインは,特別な形式の Itanium "ld8" 命令を生成し,フェッチされたアドレスを ALAT (Advanced Load Address Table) に格納します。コンパイラはこの特別な形式の "ld8" を,副作用を持ち,結果が使用されていないように見える場合でも最終的なオブジェクト・ファイルから削除できないものとして認識します。 ALAT にアドレスを挿入しても,問題が発生したり,他の変更が必要になることはありません。最終的なオブジェクト・ファイルに残す必要がある,使用されないメモリのロードについては,次のように変更します。


    MOVL (Rn),Rn 
    


    から


    IA64_LD8_A Rn,(Rn),#0 
    


    将来のリリースでは,最終的なオブジェクト・ファイルに残す必要がある命令を指定するための新しい構文がコンパイラに追加される予定です。
    バージョン 8.3 よりも前のシステムでは, IA64_LD8_A ビルトインはありません。唯一の回避策は, /NOOPTIMIZEを使用することです。



5.19.2 OpenVMS Alpha システム用の HP MACRO

V8.3

コンパイラは,使用されていないように見えるメモリのロードを最適化によって除去することがあります。コンパイラの新しいオプティマイザは,メモリのロード結果が使用されるかどうかを認識することができます。結果が使用されていないと判断されると,オプティマイザはメモリ・ロードを削除します。しかし,コードによっては,たとえば IPL を上げる前にページをメモリにページ・インさせるためにメモリのロードを使用している場合があります。そのような場合は,命令が除去されるとページがメモリにページ・インされなくなり,高い IPL での以降のコードで,高い IPL 例外での回復不可能なページ・フォルトが発生します。唯一の回避策は, /NOOPTIMIZEを使用するか,最適化機能を備えていない以前の Macro-32 コンパイラに戻ることです。

新しい Macro-32 コンパイラの名前は SYS$SYSTEM:MACRO.EXEであり, DCL MACROコマンドではこのイメージがデフォルトで起動されます。古いコンパイラは SYS$SYSTEM:ALPHA_MACRO.EXEにあります。 DCL コマンド MACRO で古いコンパイラを使用するには,論理名 MACRO を次のように定義します。


$ DEFINE MACRO SYS$SYSTEM:ALPHA_MACRO.EXE 



5.19.3 /TIE 修飾子のデフォルトは Alpha と I64 で異なる

V8.2

/TIE 修飾子のデフォルトは Alpha システムと I64 システムで異なります。 Alpha では,デフォルトは /TIE です。 I64 では,デフォルトは /NOTIE です。

5.19.4 /OPTIMIZE=VAXREGS 修飾子は I64 ではサポートされない

V8.2

Alpha システムでサポートされていた /OPTIMIZE=VAXREGS 修飾子は, I64 システムではサポートされません。残念ながら,関連するコードすべてがコマンド行処理から削除されてはいません。 I64 システムで /OPTIMIZE=ALL を指定すると,サポートされていない VAXREGS 最適化を誤って起動することになります。今後のリリースで,コマンド行プロセスを修正して VAXREGS 最適化を起動しないようにする予定です。

5.19.5 浮動小数点数のゼロ除算エラーが検出されない (I64 のみ)

V8.2

Macro-32 浮動小数点数サポート・ルーチンは,浮動小数点数のゼロ除算を検出しません。サポート・ルーチンでは,VAX 浮動小数点数を IEEE 浮動小数点数に変換して除算を実行します。チェック処理無しで,除算で IEEE の NaN 値 (非数値) が生成されます。サポート・ルーチンは,次に NaN 値を VAX 浮動小数点数に戻そうとします。この操作で,不正浮動小数点数のエラーになります。今後のリリースで,サポート・ルーチンが修正され,正しく浮動小数点数のゼロ除算エラーを検出するようになります。

5.20 Hypersort ユーティリティ

ここでは,OpenVMS Alpha および OpenVMS I64 Version 8.2 用の Hypersort V08-006 に関する注意事項について説明します。

Hypersort で修正されていない問題を回避する場合,または Hypersort に実装されていない機能を使用する場合には,従来どおり SORT32 を使用してください。 SORT32 に関する注意事項は 第 5.35 節 を参照してください。

5.20.1 弊社への問題の報告

永続的な条件

SORT や MERGE で問題を発見した場合は,問題を報告する前に,次のコマンドを実行してください。


$ WRITE SYS$OUTPUT "WSEXTENT =''F$GETJPI("","WSEXTENT")'" 
$ WRITE SYS$OUTPUT "PGFLQUOTA=''F$GETJPI("","PGFLQUOTA")'" 
$ SHOW LOGICAL SORTSHR 
$ SORT/STATISTICS (or MERGE/STATISTICS) 

問題を再現する入力ファイルとともに,この出力を問題の報告に含めてください。

5.20.2 ラージ・ファイルの制限事項

V8.2

Hypersort V08-010 は,メモリ割り当てのアルゴリズムが改良されましたが,大規模な入力ファイルが使用されると,ハングアップしたり, ACCVIO が発生することがあります。ハングアップや ACCVIO が発生する可能性を低くするには, 第 5.20.8 項 に記載されているとおりにページ・ファイル・クォータとワーキング・セット・エクステントを設定します。 Hypersort でハングアップしたり ACCVIO が発生する場合は,代わりに SORT32 を使用してください。

5.20.3 Hypersort と VFC ファイルの制限事項

V7.3-2

Hypersort で VFC ファイルを使用するには,/FORMAT=RECORD_SIZE:n が必要です。

5.20.4 /FORMAT=RECORD_SIZE の制限事項

永続的な制限事項

Hypersort では, SORT と MERGE の両方で使用する /FORMAT=RECORD_SIZE:n がサポートされます。ただし,次の 2 つの制限事項があります。

  • すべての場合において,コマンドで指定した RECORD_SIZE の値が入力ファイル内の任意のレコードの最大レコード長 (LRL) よりも小さい場合,長すぎるレコードは,ソートされた出力ファイルで RECORD_SIZE のサイズまで切り捨てられ,診断メッセージ %SORT-E-BAD_LRL が発行されます。この場合は,出力ファイルを破棄し,ソートを再実行する必要があります。 SORT コマンドの RECORD_SIZE パラメータの値を,DIR/FULL コマンドを実行して表示される入力ファイルの最大レコードのサイズに合わせて修正してください。

  • SORT や MERGE によって,入力索引順編成ファイルから出力順編成ファイルが作成されます。この場合,%SORT-E-BAD_LRL 診断メッセージも発行される場合があります。



5.20.5 Hypersort と検索リスト,および論理名の使用

永続的な制限事項

Hypersort では,検索リスト,および入力ファイルと作業ファイルで使用される論理名のサポートが十分でありません。この問題を検出した場合は,SORT32 を使用してください。

5.20.6 作業ファイルの空き領域不足

永続的な制限事項

すべてのソート作業ファイルで空き領域が無くなると,Hypersort が正しく終了しません。この問題を防ぐには,次のいずれかの処理を実行してください。

  • ソートの作業ファイル用に使用するデバイスに,十分な空き領域を割り当てる。

  • SORT32 を使用して,作業ファイルの領域を使い果たしたことを検出する。



5.20.7 入力アスタリスク (*) の制限事項

永続的な制限事項

Hypersort では,入力ファイル指定にアスタリスク (*) を使用できません。

5.20.8 最適化されたワーキング・セット・エクステントとページ・ファイル・クォータの設定

永続的な制限事項

SORT32 と Hypersort は,異なるソート・アルゴリズムと作業ファイル・アルゴリズムを使用します。これらのユーティリティの相対的な速度は,入力ファイルと,メモリ,ディスク,および CPU の構成によって異なります。ワーキング・セット・エクステントが,ページ・ファイル・クォータの 3 分の 1 を超えないようにしてください。 SORT32 と Hypersort はいずれも,個々の入力ファイルに合ったワーキング・セット・エクステントを使用することで,最高の性能を発揮します。

5.21 Intel® アセンブラ (I64 のみ)

永続的な制限事項

Intel アセンブラ言語で記述されたすべてのモジュールには,-Xunwind フラグによる自動生成を行うか,ソース・モジュールに明示的に unwind ディレクティブを記述する方法で,適切な unwind ディレクティブが含まれていなければなりません。正確な unwind 情報なしでは,オペレーティング・システムの条件処理と例外ディスパッチが動作せず,予期しない状態でプログラムが失敗することがあります。正確な unwind 情報を持たないプログラムは, OpenVMS ではサポートされていません。この前提条件は,永続的な要件となります。

5.22 Librarian ユーティリティ

ここでは,Librarian ユーティリティと Library Service ルーチンに関する注意事項について説明します。

5.22.1 data-reduced ELF オブジェクト・ライブラリとのリンクは推奨できない (I64 のみ)

V8.2

DCX data-reduced ELF オブジェクト・ライブラリは,ライブラリ内の連続領域には格納されません。その結果,最初にデータの展開を行う必要があるため,モジュールをプロセスの P2 空間に直接マッピングすることはできません。 LBR$MAP_MODULE ライブラリ・サービスが,モジュールを展開しプロセスの P2 空間にコピーします。この動作により,結果としてできた P2 空間内のページが,プロセス・クォータとしてカウントされます。

LBR$UNMAP_MODULE ライブラリ・サービスは,これらのページを回復しますが,これらのページはヒープ領域解放リストに残り,プロセス・クォータとしてカウントされ続けます。そのため,Linker 操作の前に,あらかじめ DCX data-reduced ELF オブジェクト・ライブラリを展開することをお勧めします。

5.22.2 I64 ライブラリへの .STB ファイルの挿入または置き換えの失敗 (I64 のみ)

V8.2

OpenVMS VAX および Alpha では, .STB ファイルをオブジェクト・ライブラリに格納することができます。 OpenVMS I64 では,Librarian はこの動作を行いません。例を次に示します。


 $ LIBR/CREATE OBJ$:SOME_LIBRARY OBJ$:SOME_FILE.STB 
 Librarian T01-23 
 %LIBRAR-E-NOTELFFILE, TPSSWRKD$:[TPSS.TRACE.IA64.LPIOBJ]TRACEMSG.STB;1 
  is not an ELF object or image file 

.STB ファイルはオブジェクトでもイメージでもないため,現在 Librarian は,このファイルを I64 システムの .OLB ファイルには格納しません。

ただし,Alpha と VAX では, .STB ファイルはオブジェクト・ファイルと同様の形式になっています。 VAX では,.STB ファイルを Linker への入力として使用することもできます。 Alpha では,.STB ファイルの形式は,.OBJ ファイルの形式と同じです (つまり,ファイル拡張子が .STB であること以外は,これらのファイルに違いはありません)。そのため,Alpha の Librarian はこのファイルを受け付けますが, Linker の入力として使用することはできません。

I64 では, .STB ファイルにファイル・タイプ (ET_VMS_LINK_STB) が埋め込まれます。これにより,Librarian と Linker が, .STB ファイルを処理できないことを判断できます。これは永続的な状態です。

5.22.3 プロセス・クォータが低すぎると Librarian がエラーを通知しない問題

永続的な制限事項

OpenVMS Alpha および I64 の Librarian は圧縮,データ・リダクション,データ拡張操作でエラーを通知しないことがあります。この問題が発生するのは,Librarian が動作しているアカウントまたはプロセスの PGFLQUOTA プロセス・クォータが低い場合です。 $PUTMSG システム・サービスは,エラーが発生した場合でも必ず SS$_NORMAL というステータスを返すので,操作エラーがただちに明らかになりません。しかし,エラーが発生した場合には, Librarian は Success 以外のステータスを返します。

この問題を回避するには,PGFLQUOTA を増加させてから圧縮,データ・リダクション,データ拡張操作を実行します。さらに,コマンド・プロシージャで LIBRARY コマンドからの戻りステータスを確認するようにしてください。

5.23 OpenVMS 用の Analyze ユーティリティ (I64 のみ)

ここでは,OpenVMS I64 上の Analyze ユーティリティに関する注意事項について説明します。

5.23.1 I64 Analyze イメージの /SELECT でのプロセス・リソースの解放についての修正

V8.3

I64 イメージ・ファイルに対する ANALYZE/SELECT でプロセス・リソースが解放されませんでした。ワイルド・カードを使用した場合は, SECTBLFUL (または他のクォータ超過のメッセージ) で失敗することがありました。

この問題は,バージョン 8.3 で修正されました。

5.23.2 デバッグ行情報の選択的出力の修正

V8.3

I64 イメージ・ファイルでは, ANALYZE/IMAGE/SELECT=DEBUG=LINE で対応するデバッグ行情報が出力されませんでした。行の選択は,/TRACE の場合だけ動作していました。

この問題は,バージョン 8.3 で修正されました。

5.24 Command Definition ユーティリティ (I64 のみ)

ここでは,OpenVMS I64 上の Command Definition ユーティリティに関する注意事項について説明します。

5.24.1 I64 イメージのレコード属性の修正

V8.3

I64 イメージ (コマンド・テーブル) では, Command Definition ユーティリティ (CDU) はレコード属性を設定しますが,それにより,イメージ・ファイルのコピーまたはアペンドの際に警告メッセージが表示されることがありました。警告メッセージが表示されても,コピーまたはアペンドされたファイルは正しい内容となっています。

バージョン 8.3 では,警告メッセージが表示されることなくこれらのファイル操作が完了するように, CDU は互換性のある属性を設定します。

5.25 OpenVMS Alpha 用 Linker ユーティリティ

ここでは,すべての OpenVMS プラットフォーム上での Alpha Linker ユーティリティに関する注意事項について説明します。 I64 Linker に関する注意事項は 第 5.26 節 を参照してください。

5.25.1 多数のファイルを指定した場合に Linker がハングアップしたように見える

V8.3

RMS_RELATED_CONTEXT リンカ・オプションがオン (デフォルトは RMS_RELATED_CONTEXT=YES) で,存在しないファイルが LINK コマンドのファイル・リストに指定されていた場合,リンカによる LIB$FIND_FILE の呼び出しは完了するまでに長時間かかり,リンカがハングアップしたように見えることがあります。リンクしているファイルの数と,ファイル指定での論理名の使用状況に応じて,リンカの処理が完了するまでに数時間かかることもあります。これは LIB$FIND_FILE が,不明ファイルについてプレフィックスの組み合わせをすべて探してから, "file not found" メッセージを表示するためです。リンカが LIB$FIND_FILE を呼び出した後は, Ctrl/Y を押してもリンカを終了させることはできません。

どのファイルが不明かを調べるには,『Linker Manual』の第 4 部「LINK Command Reference」の RMS_RELATED_CONTEXT= オプションの説明に記載されている手順を使用します。

5.25.2 ライブラリ・チェックにおける Linker のデフォルト動作の変更

V7.3-1

これまでの Linker では,ライブラリと共有イメージ間の一致条件が厳密に検証されていましたが ( 正確な日時を照合し,該当するものがない場合は, LINK-I-DATMISMCH シグナル通知を発行),このリリースでは,イメージ・アクティベータと同じ検証 (GSMATCH 条件を使用して互換性を検証) だけが実行されます。

以前の動作 (日時の照合) を実行する場合は, LINK$SHR_DATE_CHECK 論理名を設定してください。

詳細は,『Linker Manual』の第 4 部「LINK Command Reference」の /LIBRARY 修飾子を参照してください

共用可能イメージ・ライブラリには,イメージのコピーは格納されていません。格納されているのは,イメージの名前,イメージの識別情報,イメージのユニバーサル・シンボルが格納されたテーブルです。識別情報は,共用可能イメージをリンクする際に GSMATCH=オプションで指定します。詳細は,『Linker Manual』の第 4 部「LINK Command Reference」の GSMATCH=オプションを参照してください。

共用可能イメージを再リンクしても,ライブラリが更新されない場合があります。このような場合に対処するために,リンカは互換性を確認します。リンカは,イメージ・アクティベータが行うのと同じように, GSMATCH条件を使用して互換性を確認します。

VAX では,リンカは日付と時刻も比較し,違っている場合には LINK-I-DATMISMCHを生成します。

Alpha では,リンカの最初の動作は VAX のリンカと同じでした。しかし,このチェックは厳し過ぎると判断され,デフォルトでは GSMATCH 条件だけを使用するように変更されました。論理名 LINK$SHR_DATE_CHECKを定義すると, VAX と同じ以前の動作になります。

5.25.3 スタックのエレメント数は最大 25 に制限

永続的な制限事項

オブジェクト・ファイルを作成する開発者は,Linker の内部スタックのエレメント数が最大 25 に制限されていることに注意しなければなりません。どのような計算も,この制限の範囲内で実行しなければなりません。

5.26 OpenVMS I64 用 Linker ユーティリティ

V8.3

ここでは,I64 Linker ユーティリティに関する注意事項について説明します。

Alpha Linker に関する注意事項は, 第 5.25 節 を参照してください。

5.26.1 正しくないイメージ間デバッグ・フィックスアップをリンカがデバッグ・シンボル・ファイルに書き込む

V8.3

状況によっては,リンカは OpenVMS デバッガ用のイメージ間フィックスアップを作成します。イメージ間デバッグ・フィックスアップは,リンカが解決できない,コンパイラが生成したデバッグ再配置の結果です。つまり,共用可能イメージに格納されている値を実行時に調べるために,デバッガはこれらのフィックスアップを必要とします。デバッガ用にイメージ間フィックスアップをリンカに作成させることが必要となる頻度は,コンパイラによって異なります。 C コンパイラはイメージ間デバッグ・フィックスアップをめったに使用しませんが,C++ コンパイラは頻繁に使用します。このようなイメージを /DEBUG 付きでリンクすると,リンカはデバッグ情報の後にイメージ間デバッグ・フィックスアップを書き込みます。 /NODSF (省略時の指定) を使用すると,情報はイメージ・ファイルに正しく書き込まれますが, /DSF を指定すると,情報は誤って DSF ファイルに書き込まれることがあります。

たとえば,次の例の DEBUG 情報と DEBUG エラーは,リンカが誤って DSF ファイルへ書き込んだために表示されます。


$ RUN/DEBUG MINIREF 
%DEBUG-I-INFODWARF, error reading Dwarf info: Section 0a extends outside file 
%DEBUG-I-INFODWARF, error reading Dwarf info: Section 0c extends outside file 
%DEBUG-I-INFODWARF, error reading Dwarf info: SHT_VMS_FIXUP section 10 size 17eb 
e0 not multiple of 18 
%DEBUG-I-INFODWARF, error reading Dwarf info: SHT_VMS_FIXUP section 12 size 17ec 
30 not multiple of 18 
 
         OpenVMS I64 Debug64 Version V8.3-003 
 
%DEBUG-F-ACCVIO, access violation, reason mask=00, virtual address=000000000014A 
000, PC=000000007BD73100, PS=0000001B 
%DEBUG-I-INITIAL, Language: C, Module: MINIREF 
 
DBG> 

イメージファイルには影響がなく, RUN コマンドを使用して問題なく実行できます。


$ RUN MINIREF 

このエラーは I64 リンカの次回のリリースで修正される予定です。

5.26.2 OpenVMS I64 のオブジェクト・モジュールとイメージ・ファイルの情報が現在利用できない

V8.3

ELF (Executable and Linkable Format。 I64 でのオブジェクト・モジュールとイメージ・ファイルの形式) に対する OpenVMS I64 の拡張についての情報は,現時点では公開しておりません。将来のリリースで提供されます。

Alpha または VAX のオブジェクト言語形式についての詳細は,『OpenVMS Alpha/VAX Version 7.3 OpenVMS Linker Utility Manual』のそれぞれに対応した付録を参照してください。このこのマニュアルは,次の URL で入手できます。


http://h71000.www7.hp.com/doc/os732_index.html 



5.26.3 /SELECTIVE_SEARCH がトランスファー・アドレスを誤って無視することがある

V8.3

トランスファー・アドレスが含まれている I64 オブジェクト・モジュールがあり, /SELECTIVE_SEARCH 修飾子を指定したリンク操作にそのモジュールを含めると,リンカはそのトランスファー・アドレスを検出しません。

次の例では,オブジェクト・モジュール (MAIN.OBJ) にトランスファー・アドレスが含まれていますが,/SELECTIVE_SEARCH によって無視されます。


$ LINK MAIN/SELECTIVE_SEARCH 
%ILINK-W-USRTFR, image USER:[JOE]MAIN.EXE;1 has no user transfer address 

この状態になるのは,プログラムのトランスファー・アドレスを提供することを意図した I64 オブジェクト・モジュールが, SELECTIVE_SEARCH 属性を使用したリンク操作に含まれている場合だけです。次の例のように,LINK コマンドでオブジェクト・モジュールに /SELECTIVE_SEARCH 修飾子を指定すると, SELECTIVE_SEARCH 属性がオブジェクト・モジュールに与えられます。


$ LINK MAIN/SELECTIVE_SEARCH 

次のような LIBRARY と LINK コマンドの例も考えられます。


$ LIBRARY/INSERT LIB.OLB MAIN.OBJ/SELECTIVE_SEARCH 

このライブラリに含まれているモジュールを,リンク操作で参照を解決するために使用します。暗黙的に使用する例は次のとおりです。


$ LINK/EXECUTABLE=MAIN SUBROUTINES.OBJ, LIB.OLB/LIBRARY 

明示的に使用する例は次のとおりです。


$ LINK/EXECUTABLE=MAIN SUBROUTINES.OBJ, LIB.OLB/INCLUDE=MAIN 

この問題は,以下の 2 つのうちのどちらかの形で明らかになります。

  • 上記の例のように,リンカが警告メッセージを表示する場合。この状態になるのは,リンク操作の他のオブジェクト・モジュールが weak かどうかにかかわらずトランスファー・アドレスを提供しない場合です。

  • リンカがメッセージを表示しない場合。この状態になるのは,リンク操作の他のオブジェクト・モジュールが weak かどうかにかかわらずトランスファー・アドレスを提供する場合です。選択的に検索されたオブジェクト・モジュールからトランスファー・アドレスを見つけることができないと,リンカは他のオブジェクト・モジュールのトランスファー・アドレスを選択します。そのトランスファー・アドレスは,意図せずにそのイメージのメイン・エントリ・ポイントとなります。マップ・ファイルには,リンカが正しくない遷移モジュールとトランスファー・アドレスを割り当てたことが出力されますが,実際にアプリケーションを実行するまで問題に気づかない可能性があります。



5.26.4 I64 リンカと Alpha リンカの違い

V8.3

OpenVMS I64 Linker と OpenVMS Alpha Linker の違いに関する詳細な説明については,『HP OpenVMS V8.3 新機能説明書』を参照してください。『HP OpenVMS V8.3 新機能説明書』には,OpenVMS I64 Linker の新機能についての説明もあります。

5.26.5 LINK_ORDER セクション・ヘッダ・フラグはサポートされていない

V8.2

Linker は, ELF セクション・ヘッダ・フラグ LINK_ORDER をサポートしていません。ただし,このフラグが設定されている unwind セクションは,正しい順序で配置されます。

このフラグは,セクションがイメージ・ファイル内の他のセクションと結合される場合,参照先のセクションが結合される順序と同じ順序で結合しなければならないことを示します。 unwind セクションは,特別なケースとして扱われ,正しい順序で現れます。

次の図に,この概念を図示します。




V8.2

DCX data-reduced ELF オブジェクト・ライブラリは,ライブラリ内の連続領域には格納されません。その結果,最初にデータの展開を行う必要があるため,モジュールをプロセスの P2 空間に直接マッピングすることはできません。 LBR$MAP_MODULE ライブラリ・サービスが,モジュールを展開しプロセスの P2 空間にコピーします。この動作により,結果としてできた P2 空間内のページが,プロセス・クォータとしてカウントされます。

LBR$UNMAP_MODULE ライブラリ・サービスは,これらのページを回復しますが,これらのページはヒープ領域解放リストに残り,プロセス・クォータとしてカウントされ続けます。そのため,Linker 操作の前に,あらかじめ DCX data-reduced ELF オブジェクト・ライブラリを展開することをお勧めします。これは永続的な状態です。

5.26.7 初期化されたオーバレイ・プログラム・セクションの取り扱いについての誤りの修正

V8.3

以前のバージョンの I64 Linker では, 0 で初期化されたオーバレイ・プログラム・セクションは,誤って,互換性のある初期化と見なされていました。 OpenVMS Version 8.2 と Version 8.2-1 の I64 Linker では 0 で初期化されたセクションは 0 以外の初期値を持つセクションと互換性があると見なされます。そのため,リンク操作時のモジュールの順番によっては,イメージに異なる初期値が設定されることがあります。

この問題は,Version 8.3 で修正されました。

5.26.8 リンカの修飾子 /EXPORT_SYMBOL_VECTOR と /PUBLISH_GLOBAL_SYMBOLS の削除

V8.3

すべてのグローバル・シンボルをエクスポートするだけで共用可能イメージを作成しても,それだけではうまくいきません。以前のバージョンの I64 Linker は, /EXPORT_SYMBOL_VECTOR 修飾子と /PUBLISH_GLOBAL_SYMBOLS 修飾子を提供しており,すべてのグローバル・シンボルのシンボル・ベクタ・オプションをモジュール単位に作成できました。ただし,これらの修飾子を使用すると,異なるイメージに格納されている同じユニバーサル・シンボルがエクスポートされます。異なるイメージに格納されている同じ C++ テンプレートがエクスポートされてしまうことを除外できないため,これは問題になります。

どちらの修飾子も Version 8.3 から削除されました。

この問題は,OpenVMS for I64 の将来のリリースの I64 Linker で修正される予定です。

5.26.9 オプションでの長いシンボル名のサポート

V8.3

オプション用として,リンカの内部ライン・バッファが,2048 文字に拡大されました。これにより,最大サポート長が 1024 文字のシンボル名とともにオプションを指定できるようになりました。

5.26.10 リンカが作成したコード・スタブのメモリの使用方法の改善

V8.3

I64 Linker は, OpenVMS Debugger でのコードのステップ実行でも参照可能であるコード・スタブを生成します。コードはルーチン呼び出しに対して挿入され,そのサイズは異なることがあります。しかし,以前のリンカは,必要となりうる最大コード・サイズを使用して,固定サイズのコード・セクションとしてコードを追加していました。

バージョン 8.3 のリンカは,コード・スタブを実サイズで書き込みます。これにより,スタブ間の未使用スペースが無くなるため,未使用のメモリが解放される可能性があります。

5.26.11 コンパイラでのデマングル化されたシンボル名のサポート

V8.3

シンボル名を固有のものにするために,一部のプログラミング言語では名前のマングル化が使用されています。バージョン 8.3 からは,リンカはソース・コード名と呼ばれる,デマングル化された名前を表示しようとします。これらの名前は,リンカのメッセージに使用されます。また,要求によって,リンカ・マップに表示されるマングル化されたグローバル・シンボルの変換テーブルでも使用されます ( 『HP OpenVMS V8.3 新機能説明書』を参照)。この機能は,コンパイラでの名前のデマングル化のサポートに依存しています。

5.26.12 最大セクション数

V8.3

65280 を超えるセクションに対しては, ELF 形式は拡張された番号付け方式を使用します。これは,現在の I64 リンカでは実装されていません。そのため,単一の入力オブジェクト・モジュールまたは共用可能イメージが持つことのできるセクションの数が制限されます。通常リンカは複数のセクションを持つ共用可能イメージを作成するため,この制限は共用可能イメージを作成する際にも適用されます。ここで,ELF セクションは,C++ テンプレートや共用セクションをエクスポートするために使用されます。つまり,共用可能イメージ中のそのようなインタフェースの数は 65280 未満でなければなりません。

5.26.13 マップ・ファイル中の共用可能イメージの作成日が正しくない

V8.2

OpenVMS I64 プラットフォームでは,リンカ・マップ中の共用可能イメージの作成日が正しくない場合があります。誤った日付は,通常 3686 と表示されます。この状態になるのは,リンカが共用可能イメージを入力ファイルとして処理し,日付フィールドを抽出してマップに出力した場合です。 ANALYZE/IMAGE で表示されるイメージ自体の日付は正しい内容になっています。

この問題は,I64 Linker の将来のリリースで修正されます。

5.27 LTDRIVER: CANCEL SELECTIVE の制限事項

永続的な制限事項

OpenVMS Version 6.1 より前のリリースでは,LTDRIVER は「拡張 DDT」ビットをセットしていませんでした。したがって,POSIX 関数 CANCEL SELECTIVE は LTDRIVER で動作しませんでした。この問題は解決されましたが,まだ制限事項が残っています。

この修正により,$QIO 読み込みと書き込みを選択的に取り消すことができるようになりましたが,ポート・ドライバに対して行った $QIO (つまり, LAT 接続 $QIO などのように IO$_TTY_PORT 関数修飾子を使用して行ったもの) は, CANCEL SELECTIVE によって取り消すことができません

5.28 Mail ユーティリティ: 呼び出し可能メールのスレッドの制限事項

V7.1

OpenVMS 呼び出し可能メール・ルーチンはスレッド・セーフでは ありません。スレッド化されたアプリケーション内での非スレッド・セーフ・ルーチンの呼び出しの詳細については,『Guide to the POSIX Threads Library』を参照してください。

呼び出し可能メールのコンテキスト情報は,プロセス単位(スレッド単位ではない) で管理されるので,コンテキスト・ベースの処理を実行する複数のスレッドは相互に同期をとり,特定のタイプのメール・コンテキストが一度に 1 つ だけアクティブになるようにしなければなりません。この条件が満たされないと,1 つのスレッドが他のスレッドのメール操作を妨害する可能性があります。

OpenVMS Alpha システムでは,マルチスレッド環境でカーネル・スレッドが有効に設定されている場合,この他にも追加制限事項があります。この環境では,呼び出し可能メールは初期スレッドでのみ使用しなければなりません。

5.29 OpenVMS Debugger

以降の注意事項では, OpenVMS I64 システムと OpenVMS Alpha システムでの, OpenVMS Debugger に固有の注意事項について説明しています。

DELTA デバッガと XDELTA デバッガの注意事項については, 第 5.13 節 を参照してください。

5.29.1 デバッガのコマンド行ヘルプに STEP/SEMANTIC_EVENT に関する情報がない

V8.3

デバッガのコマンド行ヘルプの STEPコマンドの下に /SEMANTIC_EVENT 修飾子に関する情報が正しく表示されません。この修飾子の情報は,『HP OpenVMS デバッガ説明書』のコマンド・リファレンスのセクションの, STEPコマンドの下にあります。

5.29.2 このリリースで修正された状況と問題点 (I64 のみ)

V8.3

次のリストは,このリリースで修正された問題点です。

全般的な問題点: 以前は,境界にアラインされていない要素が存在する配列は,正しく表示されませんでした。この問題は,プログラミング言語の構文を使用して不自然なデータ・アラインメントを強制した (たとえば,C の #pragma nomember_alignや, Pascal の PACKEDキーワード) 場合に発生していました。この問題は修正されました。

COBOL 言語での問題: EDIT picture 節で宣言したデータは,部分的にしかサポートされていませんでした。この問題は修正されました。

Fortran 言語での問題: REAL*16 型のデータ項目に値を保存すると,実際の値ではなくゼロが格納されていました。この問題は修正されました。

Pascal 言語での問題: 動的境界で宣言された配列 (たとえば "array [1..n]") が,正しく処理されないことがありました。この問題は修正されました。


V8.2

次に,確認されている全般的な状況と,ユーザの回避方法を示します。

問題点: 要素が境界にアラインされていない配列は,正しく表示されません。これは,プログラミング言語の構文を使用して,不自然なデータ・アラインメントを強制した場合に発生します (たとえば,C 言語での #pragma nomember_align, Pascal での PACKEDキーワード)。

回避方法: ありません。

問題点: 添字がスカラ (整数) の配列を調べるとき,デバッガは配列のインデックス値を10進数ではなく,現在定義されている基数で出力します。

回避方法: SET RADIX DECIMAL コマンドを実行します。

問題点: I64 システムの OpenVMS Debugger は,あたかもレジスタ・リネーム・ベース (CFM.rrb) とローテート・サイズ (CFM.sor) がいずれも 0 であるかのように,汎用レジスタ,浮動小数点レジスタ,およびプレディケート・レジスタを表示します。言い換えると,ローテートするレジスタを使用しているときは,ローテイションの効果は無視されます。この問題は,今後のリリースで修正される予定です。さらに詳細な説明は 第 5.10 節 を参照してください。

注意

この現象は,C++ およびアセンブラ言語のプログラムの,特殊な状況でまれに発生します。多くのプログラムは,この問題の影響を受けません。

回避方法: CFM レジスタを調べ,(ゼロでない) CFM.rrb フィールドと CFM.sor フィールドの値を考慮して,手作業で EXAMINE コマンドを調整します。

5.29.4 Basic 言語での問題 (I64 のみ)

V8.2

問題点: 多次元配列の範囲を調べるとき,デバッガは要素のアドレスを適切にシンボル化できません。つまり,配列の行と列の値が正しくありません。

回避方法: ありません。

5.29.5 C++ 言語での問題 (I64 のみ)

V8.2

問題点: SHOW CALLS コマンドが, C++ のマングル化されていない名前ではなく,マングル化された名前を表示することがあります。

回避方法: ありません。

5.29.6 COBOL 言語での問題 (I64 のみ)

V8.2

問題点: EDIT picture 節で宣言したデータは,部分的にしかサポートされません。 EXAMINE コマンドを使用して項目を調べると,位取りなどの調整なしに生データが表示されます。整数や 10 進数の定数を保存することで項目を変更しようとする (DEPOSIT コマンドを使用) とエラーになります。

回避方法: 適切な位取り因数を設定し,表示される値を手作業で調整します。値を変更する必要がある場合は,別の変数または引用符付きの文字列をソースとして DEPOSIT コマンドを実行します。

5.29.7 Fortran 言語での問題 (I64 のみ)

V8.2

問題点: REAL*16 型のデータ項目に値を保存すると,実際の値ではなく常にゼロが格納されます。

回避方法: ありません。

5.29.8 Pascal 言語での問題 (I64 のみ)

V8.2

問題点: 動的境界で宣言された配列 (たとえば "array [1..n]") が,正しく処理されないことがあります。配列を調べている際に,デバッガが INVARRDSC や IVALOUTBNDS のエラーを表示することがあり, SHOW SYMBOL/TYPE で配列境界が正しく表示されないことがあります。

回避方法: ありません。

5.29.9 SET SCOPE コマンド: 動作の変更

V8.2

SET SCOPE コマンドの動作は,このリリースで変更されました。 SET SCOPE では,デバッガの言語設定を,指定されたスコープの言語に変更するようになりました。以前は,SET SCOPE は言語設定に影響を与えませんでした。 SET LANGUAGE NODYNAMIC コマンドを実行することで,この機能を無効にできます。

5.29.10 SHOW IMAGE コマンドの変更

V8.2

SHOW IMAGE コマンドは,プロセスのイメージが占めるアドレス空間の概要を表示するようになりました。イメージ・セクション情報をすべて表示するには, SHOW IMAGE/FULL を使用するか,イメージ名を指定します (たとえば,SHOW IMAGE FOO)。

5.29.11 クライアント/サーバ・インタフェース: 以前のバージョンはサポートされない (Alpha のみ)

V7.3

OpenVMS Alpha Version 7.3 およびそれ以降の Debugger では,以前のバージョンのクライアント/サーバ・インタフェースをサポートしません。次の表に従って,配布メディアのキットにあるクライアント/サーバ・インタフェースをインストールしてください。

CPU オペレーティング・システム クライアント・キット
Intel Microsoft Windows 95,98,NT,Me,2000,XP [DEBUG_CLIENTS011.KIT]
DEBUGX86011.EXE
Alpha Microsoft Windows NT [DEBUG_CLIENTS011.KIT]
DEBUGALPHA011.EXE

これらのクライアント・キットは,自己解凍形式の .EXE ファイルです。

適切な実行形式ファイルを PC に転送したら,そのファイルを実行して, PC 上にデバッグ・クライアントをインストールすることができます。 InstallShield インストール・プロシージャのガイドに従ってインストールを行います。

5.30 OpenVMS のシステム・ダンプ・アナライザ (SDA)

ここでは,システム・ダンプ・アナライザ (SDA) に関する注意事項について説明します。

5.30.1 CLUE コマンドは OpenVMS I64 に移植されていない

V8.2

次の CLUE コマンドは,OpenVMS I64 にはまだ移植されていないため,その旨のメッセージを返します。

CLUE CALL
CLUE ERRLOG
CLUE FRU
CLUE REGISTER


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項