[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ] [ DOC Home ]

5 プログラミングに関するリリース・ノート

この章では，OpenVMSシステムでのアプリケーション・プログラミングとシステム・ プログラミングの両方に関するリリース・ノートをまとめます。

OpenVMSバージョン7.2の新しいプログラミング機能の詳細については，『OpenVMS V 7.2 新機能説明書』を参照してください。

5.1 Backup API

ここでは，Backupアプリケーション・プログラミング・インタフェース(API) のリリース・ノートをまとめます。Backupユーティリティのリリース・ ノートについては，第4.2節を参照してください。

5.1.1 変更点と強化された機能

ここでは，BCK_OPT_K_IGNORE_TYPESオプション構造に対する新しいフラグについて説明します。

5.1.1.1 新しいフラグBCK_OPTYP_IGNORE_K_STRUCTURE

V7.2

BCK_OPT_K_IGNORE_TYPESオプション構造に，新しいフラグBCK_OPTYP_ IGNORE_K_STRUCTUREが追加されました。

このフラグをセットすると，ODS-5からODS-2への構造レベル・ファイル変換が可能です。 このフラグがセットされていない場合は，ファイル変換はできません。BACKUP オプション構造タイプの使用の詳細については， 『OpenVMS Utility Routines Manual』を参照してください。

5.1.2 問題点と制限事項

ここでは，Backup APIの問題点と制限事項について説明します。

5.1.2.1 予測されない情報メッセージ

V7.2

Backup APIは，バックアップが完了した後，不正な終了ステータスBACKUP-I-INCONQUALS を返し，情報メッセージを表示することがあります。 しかし，バックアップは正常に行われます。

次のBCK_OPT_K_BEFORE_TYPEフラグとBCK_OPT_K_SINCE_TYPEフラグは削除されています。 これらのフラグを1つ以上使用すると，情報メッセージが表示されることがあります。


BCK_OPTYP_BEFORE_K_CREATED
BCK_OPTYP_BEFORE_K_EXPIRED
BCK_OPTYP_BEFORE_K_MODIFIED
BCK_OPTYP_BEFORE_K_SPECIFIED


BCK_OPTYP_SINCE_K_CREATED
BCK_OPTYP_SINCE_K_EXPIRED
BCK_OPTYP_SINCE_K_MODIFIED
BCK_OPTYP_SINCE_K_SPECIFIED

5.1.2.2 ジャーナリング・コールバック・イベントの制限事項

V7.1

アプリケーションがジャーナリング・イベントのいずれかに対してコールバック・ ルーチンを登録する場合は，すべてのジャーナリング・コールバック・ イベントに対してコールバック・ルーチンを登録しなければなりません。 ジャーナリング・コールバック・イベントは次のとおりです。


BCK_EVENT_K_JOURNAL_OPEN
BCK_EVENT_K_JOURNAL_WRITE
BCK_EVENT_K_JOURNAL_CLOSE

これは永久的な制限事項であり，今後も変更されません。

コールバック・ルーチンの登録の詳細については，『OpenVMS Utility Routines Manual』のBackup APIに関する章を参照してください。

5.1.2.3 BACKUP$STARTを繰り返し呼び出すとエラーが発生することがある

V7.1

BACKUP$STARTを繰り返し呼び出すと，次のエラーが発生することがあります。 

     %BACKUP-F-INSBUFSPACE, insufficient buffer space

このエラーが発生するまでの呼び出しの繰り返し回数は，それまで実行したバックアップ操作に応じて異なります。

アプリケーションでこのエラーが発生した場合は，操作をいったん終了し， 再起動しなければなりません。

この問題は将来のリリースで解決される予定です。

5.2 バッチ・キューとプリント・キュー

ここでは，バッチ・キューとプリント・キューに関するリリース・ノートをまとめます。

5.2.1 問題点と制限事項

ここでは，バッチ・キューとプリント・キューの問題点と制限事項について説明します。

5.2.1.1 バッチ・ジョブの実行の終了

V6.2

次の状況では，DELETE/ENTRYコマンドは実行中のバッチ・ジョブを停止できないことがあります。

DELETE/ENTRYコマンドを実行すると，ジョブは各フェーズごとに終了します。delete_process AST ルーチンはユーザ・モード，スーパーバイザ・モード， エグゼクティブ・モードで実行されます。各モードの切り換えに少し時間がかかるため， バッチ・ジョブでユーザ・モード・イメージが終了した後， スーパーバイザ・モードのdelete_process ASTルーチンが実行されるまでに， コマンド・プロシージャの実行が続行されることがあります。

SYNCHRONIZEコマンドの戻りステータスには，ターゲット・バッチ・ジョブの終了ステータスが含まれているものと解釈されます。 さらに， コマンド・プロシージャは通常，SYNCHRONIZEコマンドを実行する前に，$ON ERROR THEN CONTINUE や$SET NOONなどのコマンドを実行します。 SYNCHRONIZEコマンドを実行しているジョブに対して，DELETE/ENTRYコマンドが実行された場合，JBC$_JOBABORT は，SYNCHRONIZEコマンドの戻りステータスではなく， ターゲット・バッチ・ジョブの終了ステータスであると解釈されます。 この結果，コマンド・プロシージャはこの誤った仮定のもとに， 実行を短時間続行し，ターゲット・バッチ・ジョブをキューに再登録したり， ターゲット・バッチ・ジョブの障害を誤って報告するなどの操作を行います。

この問題を解決するために，SYNCHRONIZEコマンドに対して，この状況を検出し， ユーザ・モードの実行が終了してからスーパーバイザ・モードの実行が終了するまでの遅延時間より長い時間， 終了ハンドラを待機させるようにしています。

プログラムの戻りステータスとして，$SNDJBCシステム・サービスのSJC$_ SYNCHRONIZE_JOBファンクション・コードによって取得されたジョブ終了ステータスを報告する他のイメージは， 次のようなロジックを実装しなければなりません。

  1. 終了ハンドラを宣言します。

  2. 終了ハンドラで次のロジックを実装します。 
         IF (exit status is JBC$_JOBABORT)
     THEN
         Wait 10 seconds
     ENDIF

5.3 COM for OpenVMS (Alphaのみ)

COM for OpenVMSのリリース・ノートについては，『OpenVMS Connectivity Developer's Guide』を参照してください。このドキュメントは，COM for OpenVMS のインストール・プロセスの一部としてインストールされ，PostScript形式，HTML 形式，PDF形式で提供されます。

また，『OpenVMS Connectivity Developer's Guide』は，次の場所にあるOpenVMS webサイトから入手することもできます。 

     http://www.openvms.digital.com/openvms/products/dcom/

COM for OpenVMSのフィールド・テスト・カスタマは，第3.1.1.1項の注意事項も参照してください。

5.4 デバッグ・モード

ここでは，特殊なデバッグ・モードに関するリリース・ノートをまとめます。

5.4.1 問題点と制限事項

ここでは，CPUSPINWAITバグチェックを回避する方法について説明します。

5.4.1.1 CPUSPINWAITバグチェックの回避

V7.1

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

一般にI/O負荷の高い特定の状況で，これらの特殊モードのいずれかを使用している場合は( たとえば，デバイス・ドライバや他の複雑なアプリケーションをデバッグする場合など) ，CPUSPINWAITバグチェックが発生することがあります。CPUSPINWAIT バグチェックを防止するには，これらのシステム・ パラメータに対して，システムのデフォルト設定を使用するか， またはシステムの負荷を低下させます。

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

5.5 DEC Ada実行時ライブラリ

ここでは，DEC Ada実行時ライブラリに関するリリース・ノートをまとめます。

5.5.1 変更点と強化された機能

ここでは，高度なAdaプログラマが利用できるリソースについて説明します。

5.5.1.1 Ada宣言が登録されているOpenVMSテキスト・ ライブラリ

V7.2

次のファイルは，オプションとして提供されるOpenVMSテキスト・ライブラリであり，Ada 宣言が格納されています。


SYS$LIBRARY:STARLET_RECENT_ADA_SUBSET.TLB
SYS$LIBRARY:LIB_ADA_SUBSET.TLB

これらのファイルは，OpenVMSオペレーティング・システムと明示的に会話しなければならないプログラムを作成する高度なAda プログラマを対象にしています。 これらのファイルは，DEC Adaコンパイラに添付されている， あらかじめコンパイルされたライブラリと異なり，このようなプログラムのための基礎を提供します。

STARLETライブラリには，最新のDEC Adaコンパイラのキットにまだ盛り込まれていない最新のコンポーネントの宣言が格納されています。DEC Ada の新しいバージョンでこれらのコンポーネントの宣言が追加されれば，今後のオペレーティング・ システムのリリースでは，このテキスト・ライブラリからこれらの宣言が削除されます。

LIBライブラリの宣言は特殊な目的で使用されるものであり，他の言語の対応するファイルと同様に， 将来のオペレーティング・システム・リリースでは， 互換性に関する問題が発生する可能性があります。

5.5.2 問題点と制限事項

ここでは，問題点について説明します。

5.5.2.1 予測されないストレージ・エラー(Alpha のみ)

V7.0

OpenVMS Alphaバージョン7.0以上では，DEC Adaタスクが使用するタスク空間のサイズに関して， 誤った仮定を行う一部のDEC Adaプログラムで， バイナリの互換性が正しくとられていません。これまで発生していなかったストレージ・ エラーがタスクで発生した場合は，タスクに対してストレージ・ サイズを指定するlength句を追加しなければならない可能性があります。 すでにlength句を使用している場合は，指定するストレージのサイズを大きくしなければなりません。 この処理が必要なのは，指定したサイズ( またはデフォルト・サイズ)がタスクの実行にとって十分な大きさでない場合だけです。

5.5.3 修正点

ここでは，これまでのリリースで発生していた問題のうち，解決された問題について説明します。

5.5.3.1 ASTプロシージャでアクセス違反は発生しない

V7.2

DEC Adaで作成されたASTプロシージャは，ヌル・スレッドやDEC Ada以外のスレッドが実行されているときに， そのプロシージャを起動するASTが発生すると， アクセス違反になっていました。

この問題への対処(プラグマAST_ENTRYが設定されているタスク・エントリ・ ポイントを使用するようにプログラムを書き直すこと)は不要になりました。

5.6 DEC C実行時ライブラリ

ここでは，DEC C実行時ライブラリ(RTL)に関するリリース・ノートをまとめます。

5.6.1 変更点と強化された機能

ここでは，DEC C RTLソフトウェアのバージョン6.0以上で行われた変更点と強化された機能について説明します。 詳細については，DEC Cバージョン6.0 以上に添付されている『DEC C Run-Time Library Reference Manual for OpenVMS Systems』のリビジョンを参照してください。

5.6.1.1 各国対応機能のサポート

V7.2

DEC C RTLでは，アプリケーション開発者が各国対応ソフトウェアを作成できるように， 機能が追加されました。DEC C RTLはロケール・ファイルからこの情報を読み込むことにより， 言語とカルチャーに関する情報を取得します。

これらのDEC C RTL機能を使用している場合は，システムにこれらのファイルを提供するために， 別のキットをインストールする必要があります。 セーブ・セットVMSI18N072はOpenVMSオペレーティング・システムと同じメディアに格納されています。

このセーブ・セットをインストールするには，標準のOpenVMSインストール手順を実行し， キットの名前として，このセーブ・セット名を指定します。 インストールできるロケールには複数のカテゴリがあります。次のプロンプトに応答することで， 必要な数だけロケールを選択できます。 

        Do you want European and US support?
        Do you want Chinese support?
        Do you want Japanese support?
        Do you want Korean support?
        Do you want Thai support?
        Do you want the Unicode converters?

このキットにはInstallation Verification Procedureも含まれています。 キットが正しくインストールされたかどうか確認するために，なるべくこのプロシージャを実行するようにしてください。

OpenVMSバージョン7.2では，DEC C RTLにユニバーサルUnicodeロケールが追加されています。 このロケールは，マルチバイト文字エンコーディングとしてUTF-8 ，ワイド文字エンコーディングとしてUCS-4を採用しています。 ロケールの名前はUTF8-20です。このロケールはUnicode標準規格のバージョン2.0 をもとにしています。他のロケールと異なり，UTF8-20ロケールはオペレーティング・ システムとともに配布され，VMSI18N072キットには含まれていません。

OpenVMSバージョン7.2では，DEC C RTLにMicrosoft Code Page 437 (CP437)用のUnicodeコードセット・コンバータが追加されています。 これらのコードセット・コンバータもオペレーティング・システムとともに配布されます。

5.6.1.2 ユーロのサポート

V7.2

現在，ISO8859-1文字セットを使用しているアプリケーションで，ユーロ記号を簡単に使用できるように，DEC C RTL にISO8859-1-EUROコードセットが追加されました。 このコードセットはISO8859-1コードセットと基本的に同じですが，0xa4 コードポイントだけが異なっています。このコードポイントは，ISO8859-1 では国際通貨記号として定義されていますが，ISO8859-1-Euro ではユーロ記号(UnicodeコードポイントU+20AC)として定義されています。ISO8859-1 を基礎にしたすべてのロケールに対して，DEC C RTL ではISO8859-1-EUROをもとにした"Euro"ロケールが追加されています。

DEC C RTLでは，ISO8859-1-EUROコードセットとISO8859-15コードセット(Latin-9 とも呼びます)用のUnicodeコードセット・コンバータも追加されています。 ユーロ・ロケールと新しいコードセット・コンバータはVMSI18N072 キットとともに配布されます。

5.6.1.3 新しい関数

V7.2

OpenVMSバージョン7.2では，DEC C RTLに次の関数が追加されました。 

     asctime_r
     ctime_r
     gmtime_r
     localtime_r
     dlclose
     dlerror
     dlopen
     dlsym
     fcntl (a subset of commands)
     decc$set_child_standard_streams
     decc$write_eof_to_mbx
     decc$validate_wchar

詳細については，DEC C Version 6.0の『DEC C Run-Time Library Reference Manual for OpenVMS Systems』を参照してください。

5.6.1.4 OpenVMS環境のキャッシュ

V7.2

OpenVMSバージョン7.2では，論理名の変換やDCLシンボルの値の取得のために， ライブラリが繰り返し呼び出されるのを回避するために，OpenVMS 環境変数(つまり論理名とDCLシンボル)のキャッシュが getenv 関数に追加されました。デフォルトでは，キャッシュは無効に設定されます。 アプリケーションの実行時に発生する可能性のあるOpenVMS 環境変数の変化をアプリケーションで追跡しなければならない場合は， アプリケーションを起動する前にDECC$ENABLE_GETENV_ CACHE論理名に任意の文字列を設定することで，キャッシュを有効に設定できます。

5.6.1.5 mmap関数ではグローバル・セクションとパーマネント・ セクションの作成が可能

V7.2

OpenVMSバージョン7.2では，mmap 関数の機能が強化され，MAP_SHARED 要求を処理するときにSYS$CRMPSCサービスに渡される追加引数が受け付けられるようになりました。 この追加引数を使用するアプリケーションは，DEC C バージョン6.0以上でコンパイルしなければなりません。 詳細については，DEC C Version 6.0の『DEC C Run-Time Library Reference Manual for OpenVMS Systems』を参照してください。

5.6.1.6 wait関数は子プロセスの終了コードを戻すことがある

V7.2

OpenVMSバージョン7.2では，_VMS_WAITマクロを定義した状態で waitpid，wait3，wait4 関数をコンパイルした場合，子プロセスのOpenVMS終了コードが status_location引数に指定されたアドレスに格納されます。_VMS_WAIT マクロを定義せずにコンパイルした場合，これらの関数は wait.h ヘッダのプロセス・ステータスを分析するために， 子プロセスのOpenVMS終了コードをマクロと一貫性のある値に変換します。 これはwait関数の標準的な動作です。

非標準のwait関数を使用するアプリケーションの場合は，DEC Cバージョン5.7 以上を使用してコンパイルしなければなりません。

5.7 DECthreads

ここでは，DECthreadsに関連するリリース・ノートをまとめます。

5.7.1 変更点と強化された機能

ここでは，DECthreadsの重要な変更点と強化された機能を要約します。DECthreads の使用の詳細については，『Guide to DECthreads』を参照してください。

5.7.1.1 スレッド・スタックのサイズ

V7.2

OpenVMSバージョン7.2より以前には，特定の絶対サイズのスレッド・スタックを割り当てるようにアプリケーションが要求した場合，DECthreads は要求された値だけサイズを拡大し， ページ数が整数になるように合計を切り上げていました。 この結果，実際のスタック・サイズは呼び出し側の要求よりかなり大きくなり，1 ページ以上大きくなることがありました。

OpenVMSバージョン7.2以降，アプリケーションで特定の絶対サイズのスレッド・ スタックを割り当てるようにDECthreadsに要求した場合，追加空間は発生しませんが， 割り当てはページ数が整数になるように切り上げられます。

デフォルト・サイズのスタックを使用しているアプリケーションの場合は， この変更によって問題は発生しないと考えられます。同様に， DECthreadsのデフォルトまたは可能な最小スタック・サイズをもとに，スレッド・ スタックの割り当てを設定しているアプリケーションの場合も， この変更によって問題が発生する可能性はありません。しかし，使用している割り当てサイズの計算方法に応じて， スレッド・スタック用のメモリとして， アプリケーションに要求したサイズより大きなメモリが与えられることがあります。

OpenVMSバージョン7.2以降，特定の絶対サイズのスタック割り当てを指定して作成されたスレッドは， スタック空間が不十分なために，実行時にエラーになることがあります。 このエラーは，DECthreadsの変更によって， アプリケーションの既存のバグが明らかになったことを示します。

アプリケーションが特定のサイズのスレッド・スタックの割り当てを要求する場合は， アプリケーションが要求した空間だけでなく，コンテキスト切り換えや他のDECthreads アクティビティのための十分なスタック空間も必要です。DECthreads はタイムスライス割り込みの場合などに，この追加スタック空間を使用することがあります。 スレッドのスタック空間が不適切であっても， タイミングによっては，開発時やテスト時にまったく問題が発生しないことがあります。 たとえば，スレッドがスタックを最大限に利用しているときに， タイムスライスが発生するまで，スレッドで問題が発生することはありません。 さらに社内テスト時には，この問題が発生することはまずありません。 プロダクション環境など，別のシステム環境ではタイミングが変化するため， 特定の条件が満たされたときにエラーが発生することがあります。

OpenVMSバージョン7.2で，DECthreadsはOpenVMS AlphaとOpenVMS VAXの両方のデフォルト・ スレッド・スタック・サイズを拡大しています。デフォルト・ スタック・サイズ(またはデフォルトから計算されたサイズ)を使用するスレッドを作成するアプリケーションは， この変更の影響を受けません。

OpenVMSバージョン7.2では，DECthreadsはOpenVMS VAXの場合にだけ，最小スレッド・ スタック・サイズ(PTHREAD_STACK_MIN 定数をもとにした値) を拡大しました。この最小値をもとにスレッド・スタック・ サイズを決定するアプリケーションは，再コンパイルしなければなりません。

5.7.1.2 スタック・ベースの同期化オブジェクトに対して静的初期化は不適切

V7.2

スタックに割り当てられたDECthreads同期化オブジェクトを初期化するために， 次のマクロを使用しても，コンパイラでエラーは発生しませんが， このような使い方は不適切です。


PTHREAD_MUTEX_INITIALIZER
PTHREAD_COND_INITIALIZER
PTHREAD_RWLOCK_INITIALIZER

各スレッド同期化オブジェクトは，プログラムのスレッド間で共有されます。 このようなオブジェクトがスタックに割り当てられると，スレッドから戻るときや終了するときに， アドレスが非同期的に無効になることがあります。 この理由から，スレッド同期化オブジェクトをスタックに割り当てることは望ましくありません。

OpenVMSバージョン7.2では，DECthreadsは，自動的に割り当てられた(スタック・ ベースの)スレッド同期化オブジェクトの静的初期化の誤った使い方の一部を検出します。 たとえば，静的に初期化されたミューテックスが割り当てられているスタックを持つスレッドが， そのミューテックスにアクセスしようとすると， 操作は失敗し，EINVALが返されます。アプリケーションでDECthreads ルーチンからの戻りステータスを確認しないと， このエラーは確認されないままになり，(操作が"ロック・ミューテックス" の場合は)プログラムでスレッド同期化エラーが検出され，その結果， メモリの破壊も含めて，予測できないプログラム動作が発生してしまいます( 性能上の理由から，オブジェクトがスタックに自動的に割り当てられているスレッド以外のスレッドからミューテックスがアクセスされる場合，DECthreads は現在，このエラーを検出しません)。

アプリケーションがスレッド同期化オブジェクトをスタックに割り当てなければならない場合は， アプリケーションはそのオブジェクトを使用する前に， pthread_mutex_init()，pthread_cond_ init()，pthread_rwlock_init() ルーチンのうち， オブジェクトにとって適切なルーチンを呼び出すことで，オブジェクトを初期化しなければなりません。 また，アプリケーションは，スレッド同期化オブジェクトがスコープから外れる前に( たとえば，ルーチンが制御を返したり， 例外が発生するため)，pthread_mutex_ destroy()，pthread_cond_destroy()， pthread_rwlock_destroy() ルーチンのうち，オブジェクトにとって適切なルーチンを呼び出すことで， スレッド同期化オブジェクトを破棄しなければなりません。

5.7.1.3 POSIX 1003.4a Draft 4インタフェースの廃止

V7.0

DECthreadsのPOSIX 1003.4a，Draft 4 ("d4")インタフェースは，将来のリリースで廃止される予定です。POSIX 1003.4a ，Draft 4インタフェースを使用して作成されたアプリケーションは，DECthreads で提供される新しいPOSIX 1003.1c 標準("pthread")インタフェースに移行しなければなりません。 移行に役立つように，このリリースでDraft 4 POSIX 1003.4aインタフェースの互換性モードが提供されます。 互換性モードは，将来のリリースでは削除されます。

5.7.2 問題点と制限事項

ここでは，DECthreadsの問題点と制限事項について説明します。

5.7.2.1 不正な正常終了ステータス値が返される

V7.2

OpenVMSバージョン7.2のDECthreadsには問題があり，次の場合，プロセスまたはイメージが終了し， 不正な正常終了ステータス値が返されます。

たとえば，この問題があるために，コンパイルやリンクでエラーが検出されたかどうかとは無関係に，DEC Ada Compilation System (ACS) は常にSS$_NORMAL を返します。この問題は修正キットで解決される予定です。

5.7.2.2 言語のサポート

V7.0

このリリースには，DECthreadsに対するPOSIX 1003.1c標準スタイル・インタフェースに対して，C 言語以外の言語のインタフェース定義が含まれていません。 すべてのDECthreadsルーチンはC以外の言語から使用できますが， アプリケーションでルーチン宣言を指定しなければなりません。これらの自己定義宣言は，pthread.h でC言語宣言の後にモデリングしなければなりません。

5.7.2.3 DECthreadsデバッガの評価機能

V7.0

DECthreadsデバッガの評価機能は，このリリースでは動作しません。

5.7.2.4 C実行時ライブラリerrnoの値

V7.0

errnoがOpenVMSデバッガからアクセスされると，グローバルerrno ( 各スレッドのerrnoではない)の値が返されます(これは新たに発生した問題ではなく， 以前からあった問題ですが，ドキュメントに示されていなかっただけです) 。

5.7.2.5 SET TASK/ACTIVEコマンド

V6.2

OpenVMSデバッガ・コマンドSET TASK/ACTIVEは，DECthreadsに対して動作せず(OpenVMS Alpha システムとVAXシステムの両方)，DECthreadsを使用して実装されているOpenVMS Alpha システム用のDEC Adaに対しても動作しません。

このような場合は，DECthreadsに対して次の方法を有効に使用できます。

5.8 DECTPU for DECwindows Motif

ここでは，DECTPU for DECwindows Motifのリリース・ノートをまとめます。

5.8.1 問題点と制限事項

ここでは，DECTPU for DECwindows Motifの問題点と制限事項について説明します。

5.8.1.1 小さい表示モニタとDECwindows Motifアプリケーション

V6.0

DECwindows Motif DECTPUを小さい表示モニタで実行すると，メイン・ウィンドウが部分的に表示されなくなることがあります。

この状態を修正するには，次の操作を実行してください。

  1. 次のリソースをDECTPU Xリソース・ファイルに追加します。 
         Tpu.Tpu$MainWindow.X:                           0
     Tpu.Tpu$MainWindow.Y:                           0
     Tpu.Tpu$Mainwindow.Rows:                        21
     Tpu*condensedFont:                              on
     Tpu*fontSetSelection:                           1

  2. リソース・ファイルをSYS$LIBRARY:EVE.DAT からコピーし， 上記の行を追加します。

  3. 論理名TPU$DEFAULTSを使用して，新しいリソース・ファイルを指定します。

    ログイン・ディレクトリでeve_small_window.datというXリソース・ファイルを使用して，EVE DECwindows Motif ユーザ・インタフェースを起動して，LOGIN.COM ファイルを編集します。 

         $ DEFINE TPU$DEFAULTS SYS$LOGIN:EVE_SMALL_WINDOW.DAT
     $ EDIT/TPU/INTER=DECWINDOWS LOGIN.COM

5.9 高性能Sort/Mergeユーティリティ(Alphaのみ)

OpenVMS Alphaの高性能Sort/Mergeユーティリティの呼び出し可能インタフェース(SOR ルーチン)に関連するプログラミング・リリース・ノートついては， 第3.4節を参照してください。

OpenVMS Alphaの高性能Sort/Mergeユーティリティの使用に関する詳細については， 『OpenVMS Utility Routines Manual』と『OpenVMSユーザーズ・ マニュアル』を参照してください。

5.10 レキシカル関数

ここでは，レキシカル関数に関するリリース・ノートをまとめます。

5.10.1 変更点と強化された機能

ここでは，廃止されたアイテムについて説明します。

5.10.1.1 F$GETSYIレキシカル:アイテムNODE_HWTYPE は廃止

V7.2

NODE_HWTYPEアイテムは廃止されました。代わりにHW_NAMEアイテムを使用してください。.

NODE_HWTYPEアイテムは削除されていません。したがって，このアイテムを使用するプログラムは今後も動作します。 しかし，新しい機能を利用できる場合は， このようなプログラムを移行して，HW_NAMEアイテムを使用するようにしてください。

OpenVMS VAXシステムでは，NODE_HWTYPEを使用するアプリケーションに対して， すべてのVAXシステムの場合は4文字の秘密のシステム・モデル名が与えられ， すべてのAlphaシステムの場合はALPHという文字列が与えられます。 一方，HW_NAMEアイテムはOpenVMS VAXシステムとOpenVMS Alphaシステムの両方で動作し， これまでより長くてわかりやすい名前を返します。 たとえば，HW_NAMEは"VAXstation II"を返しますが，NODE_HWTYPEは同じシステムに対して"VUV2" を返します。

5.11 Librarianユーティリティ

ここでは，Librarianユーティリティ(LIBRARIAN)に関連するリリース・ノートをまとめます。

5.11.1 問題点と制限事項

ここでは，LIBRARIANの問題点と制限事項について説明します。

5.11.1.1 PGFLQUOTAは23000以上でなければならない(Alpha のみ)

V1.5

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

この問題を回避するには，PGFLQUOTAプロセス・クォータが23000より大きい値に設定されたアカウントで， 圧縮，データ・リダクション，データ拡張操作を実行します。 さらに，コマンド・プロシージャでLIBRARYコマンドからの戻りステータスを確認するようにしてください。

5.12 Linkerユーティリティ

ここでは，OpenVMS Linkerユーティリティ(linker)に関連するリリース・ ノートをまとめます。

5.12.1 問題点と制限事項

ここでは，Linkerの制限事項について説明します。

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

V7.2

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

5.12.2 ドキュメントの変更点と修正点

ここでは，Linkerのドキュメントの修正点について説明します。

5.12.2.1 『OpenVMS Linker Utility Manual』

V7.2

付録Aで，エンド・オブ・モジュール・レコードのTRANSFER FLAGSフィールドはEOM$L_TFRFLG として示されていますが，これは誤りです。このフィールドはロングワードではなく， バイトです。したがって，フィールドの正しい名前はEOM$B_TFRFLG です。

5.13 LTDRIVER

ここではLTDRIVERに関連するリリース・ノートをまとめます。

5.13.1 問題点と制限事項

ここでは，LTDRIVERの問題点と制限事項について説明します。

5.13.1.1 CANCEL SELECTIVEはIO$_TTY_PORT関数を取り消すことができない

V6.1

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

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

5.14 MACRO-32 Compiler for OpenVMS Alpha (Alphaのみ)

MACRO-32コンパイラに関する注意事項については，第7 章を参照してください。

5.15 Mailユーティリティ

ここでは，Mailユーティリティに関して，特にプログラマにとって関心のあるリリース・ ノートをまとめます。

5.15.1 問題点と制限事項

ここでは，呼び出し可能メールの制限事項について説明します。

5.15.1.1 呼び出し可能メールのスレッドの制限事項

V7.1

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

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

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

5.16 Mathematics (MTH$)実行時ライブラリ

ここでは，実行時Mathematicsライブラリ(MTH$)に関連するリリース・ノートをまとめます。

5.16.1 問題点と制限事項

ここでは，MTH$の問題点と制限事項について説明します。

5.16.1.1 以前のOpenVMS VAXバージョンで実行するためのイメージのリンク(VAX のみ)

V6.1

OpenVMS VAXのこのバージョンでは，Mathematics実行時ライブラリ(RTL) イメージMTHRTL.EXE，UVMTHRTL.EXE，VMTHRTL.EXEの更新されたバージョンが提供されます。 これらのイメージには，DEC Fortranバージョン6.0のサポートの新しいエントリ・ ポイントが含まれています(UVMTHRTL.EXEはMTHRTL.EXE の代替形式であり，次の段落でMTHRTL.EXEについて説明している部分は，UVMTHRTL.EXE にも適用されます)。

MTHRTL.EXEに多くのエントリ・ポイントが追加されたため，そのイメージの転送ベクタが拡張され， グローバル・セクション照合識別子が増分されました。 つまり，MTHRTL.EXEの新しいバージョンに対してリンクされたイメージは， システムにDEC Fortranバージョン6.0もインストールされていない限り，OpenVMS VAX の以前のバージョンを稼動しているシステムで実行できません。 さらに，新しいMTHRTL.EXEに対してリンクされたイメージは，DECmigrate を使用してOpenVMS Alphaで実行できるように変換することができません。

OpenVMS VAXの以前のバージョンで動作するようにイメージをリンクするには， サポートする最も古いバージョンのSYS$LIBRARYディレクトリから.EXE ファイルと.OLBファイルの保存されているコピーを格納したディレクトリを作成し， リンクの前に，そのディレクトリを指すように論理名SYS$LIBRARY を定義します。OpenVMS VAXは，MTHRTL.EXEまたはUVMTHRTL.EXE を参照するためにシステム論理名MTHRTLも定義するので，以前のイメージのディレクトリのコピーを指すように， プロセス・テーブルまたはジョブ・ テーブルで論理名としてMTHRTLを定義しなければなりません。 

     $ DEFINE/USER SYS$LIBRARY disk:[OLD_SYSLIB]
     $ DEFINE/USER MTHRTL SYS$LIBRARY:MTHRTL.EXE
     $ LINK ...

DECmigrateを使用して変換されるイメージは，OpenVMS VAXバージョン5.5-2 以前のSYS$LIBRARYファイルに対してリンクしなければなりません。

5.17 OpenVMSレジストリ(Alphaのみ)

OpenVMSレジストリのリリース・ノートについては，『OpenVMS Connectivity Developer's Guide』を参照してください。このドキュメントは，COM for OpenVMS のインストールの一部としてインストールされ，PostScript，HTML，PDF 形式で提供されます。

『OpenVMS Connectivity Developer's Guide』は，次の場所にあるOpenVMS Webサイトから入手することもできます。 

     http://www.openvms.digital.com/openvms/products/dcom/

5.18 POLYCENTER Software Installationユーティリティ

ここでは，POLYCENTER Software Installationユーティリティのリリース・ ノートをまとめます。システム管理者にとって特に関心のあるこのユーティリティの注意事項については， 第4.16 節も参照してください。

5.18.1 問題点と制限事項

ここでは，POLYCENTER Software Installationユーティリティを使用してソフトウェア・ キットを作成する場合の問題点について説明します。 システム管理者にとって関心のある問題点と制限事項については，第4.16.2項を参照してください。

5.18.1.1 File文のGenerationオプション

V7.1

file文のgenerationオプションは，製品の削除時に正しく動作しません。

たとえば，製品TEST1とTEST2の製品記述ファイルが次のように指定されているとしましょう。 

     product DEC VAXVMS TEST1 V1.0 full ;
         file [SYSEXE]TEST.EXE generation 1 ;
     end product ;

     product DEC VAXVMS TEST2 V1.0 full ;
         file [SYSEXE]TEST.EXE generation 2 ;
     end product ;

製品TEST1をインストールした後，製品TEST2をインストールすると，インストールは正しく動作します。 ファイルTEST.EXEのgeneration 2がファイルTEST.EXE のgeneration 1と置き換えられます。しかし，製品TEST2を削除すると， ファイルTEST.EXEのgeneration 1は復元されず，ファイルのgeneration 2 がシステムにそのまま残されます。

この問題を回避するには，製品TEST2でexecute install...remove文を使用します。この文のexecute installで起動されるコマンド・プロシージャは，ファイルの以前のバージョンを保存します。 後でこの文のexecute removeの部分は， 保存されているファイルのバージョンを復元します。

この問題は将来のリリースで解決される予定です。

5.19 特権付きインタフェースと構造体(Alphaのみ)

ここでは，特権付きコードと構造体に関するリリース・ノートをまとめます。

5.19.1 変更点と強化された機能

ここでは，特権付きコードに影響を与える変更点について説明します。

5.19.1.1 スレッド単位のセキュリティと下位互換性

V7.2

複数の構造体にこれまで格納されていたセキュリティ情報は，新しいPersona Security Block (PSB) 構造体に移動され，これらの構造の関連フィールドはOpenVMS バージョン7.2で廃止されました。影響のある構造としてはAccess Rights Block (ARB) ，Process Control Block (PCB)， Process Header Descriptor (PHD)，Job Information Block (JIB)， Process Control (CTL)領域フィールドがあります。

表 5-1に，廃止されたデータ・セルと， これらのセルの情報の移動先を示します。

プロセス内で1つのペルソナが実行される場合は，下位互換性を維持するために， 廃止されたデータ・セル[1]が管理されます。プロセスが多重ユーザ・ レベル・ペルソナで実行されている間，セルは管理されません( 以前のセルをチェックするコードは，セキュリティに関して誤った判断を下す可能性があるため) 。

注意
プロセスは，ナチュラル・ペルソナという1 つのユーザ・モード・セキュリティ・プロファイルを使用して作成されます。 廃止されたセルと新しいPSB構造体の間の下位互換性のレベルを定義する新しいSYSGEN パラメータARB_SUPPORTの現在の値をもとに， 下位互換性が維持されますが，プロセスはこのユーザ・モード・ ペルソナ状態のままです(ARB_SUPPORTパラメータの詳細については，『OpenVMSシステム管理ユーティリティ・ リファレンス・マニュアル』を参照してください)。

多重ユーザ・モード・ペルソナが存在する場合は，下位互換性はサポートされません。 多重ユーザ・モード・ペルソナは，$PERSONA_CREATEシステム・ サービスを使用して作成されます。

廃止されたデータ・セルの下位互換性は，OpenVMSの将来のリリースでは維持されません。 特権付きコードを作成するプログラマは，コード内で廃止されたシンボルを検索し， コードの中で廃止されたセルに依存する部分を削除し， 新しい場所から情報を取得するように，必要な変更を行ってください。

表 5-1 廃止されたデータ・セルとセキュリティ情報の新しい場所

廃止されたデータ・セル 新しい場所
ARB$L_CLASS PSB$AR_ CLASS (サポートされない[1])
ARB$L_ RIGHTSLIST PSB$AR_RIGHTS (ライト・チェーン・ ポインタの配列)
-ペルソナ，イメージ，システム・ライト・ チェーン
ARB$L_UIC PSB$L_UIC
ARB$Q_PRIV
(動作特権とイメージ特権の論理和) 		PSB$Q_WORKPRIV, PSB$Q_IMAGE_WORKPRIV
CTL$GQ_ PROCPRIV PSB$Q_PERMPRIV
CTL$T_ACCOUNT PSB$T_ACCOUNT
CTL$T_USERNAME PSB$T_USERNAME
EXE$GL_RIGHTSLIST EXE$AR_ SYSTEM_RIGHTS (ライト・チェーン・ポインタ)
JIB$T_ACCOUNT[2] PSB$T_ ACCOUNT
JIB$T_USERNAME PSB$T_USERNAME
PCB$L_ NOAUDIT PSB$L_NOAUDIT
PCB$V_SECAUDIT PSB$L_SECAUDIT
PHD$Q_AUTHPRIV PSB$Q_AUTHPRIV
PHD$Q_IMAGPRIV PSB$Q_IMAGE_ WORKPRIV
PHD$Q_PRIVMSK PSB$Q_WORKPRIV, PSB$Q_IMAGE_WORKPRIV
-動作特権とイメージ特権の論理和(PSB)
PHD$R_MAX_CLASS PSB$AR_CLASS (サポートされない[1])
PHD$R_MIN_CLASS PSB$AR_CLASS (サポートされない [1])

[1] OpenVMSバージョン7.2では，レベルB1セキュリティ環境でMAC (必須アクセス・チェック)をサポートするための構造は管理されない。

[2] JIBがジョブ・ツリー内のすべてのプロセスで共有されるので， このセルのセキュリティ情報は下位互換性を維持しない。

[1] JIB内のセキュリティ情報(JIB$T_ACCOUNT，アカウント・セル) には下位互換性がありません。これは，JIBがジョブ・ツリー内のすべてのプロセス間で共有されるからです。 マルチプロセス・ジョブ・ツリー内でJIB ユーザ名セル(JIB$T_USERNAME)を変更すると，そのジョブ・ツリー内のほかのプロセスに悪影響を与えることがあります。

5.19.1.2 バージョン7.0での特権付きコードの変更

V7.0

OpenVMS Alphaバージョン7.0で動作するように再コンパイルおよび再リンクされた特権付きコード・ アプリケーションでは，OpenVMS Alphaバージョン7.1 以上で動作するようにソース・コードを変更したり，再コンパイルや再リンクする必要はありません。

OpenVMS Alphaバージョン7.0より以前のリリースで作成された特権付きコード・ アプリケーションで，OpenVMS Alphaバージョン7.0用に再コンパイルおよび再リンクされていないアプリケーションは，OpenVMS Alpha バージョン7.1 以上で動作するように再コンパイルおよび再リンクしなければなりません。

OpenVMS Alphaバージョン7.0で，OpenVMS Alpha特権付きインタフェースと構造体に対して重要な変更が行われました。 これらの変更の結果， OpenVMS Alphaバージョン7.0より以前のリリースで作成された特権付きコード・ アプリケーションは，OpenVMS Alphaバージョン7.0以上で正しく動作するようにソース・ コードを変更しなければならない可能性があります。OpenVMS Alpha バージョン7.0で行われた変更のうち，特権付きコード・ アプリケーションのソース・コードの変更が必要になる変更点の詳細については， 『OpenVMS Alpha Guide to Upgrading Privileged-Code Applications』を参照してください。

デバイス・ドライバの再コンパイルと再リンクの詳細については，第6章を参照してください。

5.19.2 問題点と制限事項

次のリリース・ノートでは，スレッド単位のセキュリティが特権付きコードおよびデバイス・ ドライバにどのような影響を与えるかについて説明します。

5.19.2.1 スレッド単位のセキュリティは特権付きコードとデバイス・ ドライバに影響する

V7.2

セキュリティ・プロファイルをI/O Request Packet (IRP)に添付するために使用される方法が変更されました。

OpenVMSの以前のバージョンでは，プロセス単位のAccess Rights Block (ARB)セキュリティ構造のアドレスはIRPに直接コピーされていました。 OpenVMS Alphaバージョン7.2以降，I/O要求を出すスレッドの新しいセキュリティ・ プロファイル構造(Persona Security Block，PSB)のアドレスはIRP に移動されました。

I/Oサブシステムは参照カウンタを介して，PSBへのアクセスを管理します。I/O サブシステムはIRPの作成時にこの参照カウンタを増分し，I/Oの終了時にカウンタを減分します。 カウンタが0になると，PSBはシステムから削除されます。

1つの要求に対して複数のI/O操作を行うためにIRPのコピーを作成し，コピーしたIRP を後処理のためにI/Oサブシステムに渡すデバイス・ドライバは，PSB への特別なデリファレンスを明らかにするために，コードを変更しなければなりません。 このような変更は，IRPコピーのI/O後処理の前に，NSA_STD$REFERENCE_PSB を呼び出し，コピーされたIRPにあるPSBアドレスを渡すことで行います。NSA_STD$REFERENCE_PSB のインクルード・ファイルとルーチン呼び出しは次のとおりです。 

     #include <security-macros.h>

     /* Increment REFCNT of PSB that is now shared by both IRPs  */

     nsa_std$reference_psb( irp->irp$ar_psb );

デバイス・ドライバは，次の状況でこの変更を行わなければなりません。

このような状況でNSA_STD$REFERENCE_PSBを呼び出さないと，PSB内の追跡情報が破壊され， システム・クラッシュが発生する可能性があります。

NSA_STD$REFERENCE_PSBを呼び出すようにデバイス・ドライバのコードを変更する場合は，OpenVMS バージョン7.2で動作するように，ドライバを再コンパイルおよび再リンクしなければなりません。

5.20 Record Management Services (RMS)

ここでは，RMSに関するリリース・ノートをまとめます。

5.20.1 変更点と強化された機能

ここでは，RMSの強化された機能について説明します。

5.20.1.1 [000000...]の反復処理はすべてのファイルを検索

V7.2

OpenVMSバージョン7.2より以前には，マスタ・ファイル・ディレクトリ(MFD) ( つまり[000000...])から始まる反復検索指定を実行すると，RMS はMFD内のすべてのファイルを返した後，名前のソート順が000000.DIR の後のサブディレクトリから反復処理を開始します。名前のソート順が000000.DIR より前になるディレクトリから始まるサブディレクトリ・ツリーは検索されません。

Extended File Specificationsがサポートされるようになった結果，このようなディレクトリ名の作成が以前より一般的なイベントになったため， RMSはソート順がMFDの前にある最初のディレクトリではなく，最初に検索されたディレクトリから[000000...] の反復処理を開始するようになりました。 したがって，この検索指定を使用して指定された装置にあるすべてのファイルを返すことができるようになりました。

5.20.1.2 循環ディレクトリ・パスの検出(Alphaのみ)

V7.2

SET FILE/ENTERコマンドでサブディレクトリ・ツリーの下位ディレクトリに上位ディレクトリのディレクトリ名を入力すると， 循環ディレクトリ・ パスが発生します。バージョン7.2より以前には，このようなディレクトリ・ ツリーは反復処理でRMSにとって循環パスとして表示されていました( たとえば，[A...]などの指定を処理するとき)。これは，SET FILE/ENTER コマンドから返されたディレクトリのディレクトリID (DID)がパスの上位ですでに検出されていることをRMS が検出しないからです。

以前のリリースでは，ディレクトリ・レベルを8レベルに制限することで，RMS がループしないようにしていましたが，DIDの無限循環が発生する可能性がありました。OpenVMS バージョン7.2で深いディレクトリ構造が導入された結果，8 レベルというディレクトリの制限は回避されました。 このリリースでは，パス内のノードが循環を開始するときに，RMSがそのことを検出するように機能が強化されています。RMS はループする代わりに， パスの現在の分岐内の再開要素であるかのように，このようなノードを取り扱うようになりました。

5.20.1.3 ディレクトリ・キャッシュの上限の解除

V7.2

ほとんどのワイルドカード検索では，RMSはファイル・システムへの呼び出しを最適化するために， ターゲット・ディレクトリ・ファイルをメモリ・ キャッシュに格納します。このリリースより以前には，RMSがキャッシュに格納するディレクトリ・ ファイルの最大サイズは127ブロックでした。 これより大きなディレクトリに対するワイルドカード・ルックアップはファイル・ システムに直接アクセスしていました。

バージョン7.2以降，RMSはどのサイズのディレクトリもキャッシュに格納しようとします。 ファイルをキャッシュに格納するために，メモリや他のリソースを使用できない場合は， ワイルドカード・ルックアップはファイル・ システムに対して行われます。

5.21 実行時ライブラリ(LIB$)

ここでは，実行時ライブラリ(LIB$)のリリース・ノートをまとめます。

5.21.1 問題点と制限事項

ここでは，LIB$ RTLの問題点と制限事項について説明します。

5.21.1.1 LIB$FIND_IMAGE_SYMBOLはコンパイル・ エラーのあるモジュールに対して警告を通知する

V7.1

LIB$FIND_IMAGE_SYMBOLは，起動されているイメージにコンパイル警告が発生するモジュールが含まれていることを示すために， 警告(LIB$_ EOMWARN)を通知することがあります。LIB$FIND_IMAGE_SYMBOLで使用される条件ハンドラは， この状況を特殊な場合として取り扱わなければなりません。

LIB$_EOMWARNが通知された後，LIB$FIND_IMAGE_SYMBOLが実行を続行するには， 条件ハンドラがSS$_CONTINUEで終了しなければなりません。この理由から，LIB$FIND_IMAGE_SYMBOL の条件ハンドラとしてLIB$SIG_TO_RETを使用することは適切ではありません。

5.21.2 ドキュメントの変更点と修正点

ここでは，LIB$実行時ライブラリのドキュメントの修正点について説明します。

5.21.2.1 『OpenVMS RTL Library (LIB$) Manual』

V7.2

『OpenVMS RTL Library (LIB$) Manual』で，次の修正が必要です。

5.22 Screen Management (SMG$)機能

ここでは，Screen Management (SMG$)機能のリリース・ノートをまとめます。

5.22.1 ドキュメントの変更点と修正点

ここでは，SMG$実行時ライブラリのドキュメントの修正点について説明します。

5.22.1.1 『OpenVMS RTL Screen Management (SMG$) Manual』

『OpenVMS RTL Screen Management (SMG$) Manual』の最後にある参照情報のトピックに，次の情報を追加してください。

V7.2

V7.1

5.23 String Manipulation (STR$)機能

ここでは，String Manipulation (STR$)機能のリリース・ノートをまとめます。

5.23.1 ドキュメントの変更点と修正点

ここでは，STR$実行時ライブラリのドキュメントの修正点について説明します。

5.23.1.1 『OpenVMS RTL String Manipulation (STR$) Manual』

V7.2

『OpenVMS RTL String Manipulation (STR$) Manual』を次回更新するときに，次の誤りを修正する予定です。

5.24 システム・サービス

ここでは，システム・サービスに関するリリース・ノートをまとめます。

すべてのシステム・サービスは『OpenVMS System Services Reference Manual』に説明されています。

5.24.1 変更点と強化された機能

ここでは，システム・サービスの変更点について説明します。

5.24.1.1 $PERSONAシステム・サービス:無視されるフラグ(Alpha のみ)

V7.2

OpenVMSの以前のバージョンでは，$PERSONA_ASSUMEシステム・サービスと$PERSONA_CREATE システム・サービスが提供されていました。これらのサービスには， ペルソナが仮定または作成されるときに，どのペルソナ・ サービス・オプションが採用されたかを指定するフラグ引数が含まれていました。

OpenVMSバージョン7.2では，これらのフラグは無視されます。

OpenVMSのこのバージョンでフラグが無視されるのは，スレッド単位のセキュリティの導入により， 偽装の処理が，プロセス単位のセキュリティ構造を変更することから， プロセス内の個別のセキュリティ・プロファイルを変更することに変わったからです。 この結果，ジョブ単位のセキュリティ構造に影響を与えずに， プロファイル内のすべてのセキュリティ情報を変更できるようになりました。 これにより，セキュリティ構造を選択的に変更することを指定するために， ペルソナ・フラグを使用する必要がなくなりました。

表 5-2と表 5-3 に，OpenVMSバージョン7.2で無視されるフラグ引数の値を示します。

表 5-2 無視される$PERSONA_ASSUMEフラグ

フラグ 説明
IMP$M_ASSUME_SECURITY アクセス・ライト， UIC，登録されている特権，ユーザ名，セキュリティ監査フラグを仮定する。
IMP$M_ASSUME_ACCOUNT OpenVMSアカウントを仮定する。
IMP$M_ASSUME_JOB_WIDE マルチプロセス・ジョブでも新しいペルソナを仮定する。

表 5-3 無視される$PERSONA_CREATEフラグ

フラグ 説明
IMP$M_ASSUME_DEFCLASS デフォルト分類によってペルソナを作成する。

$PERSONAシステム・サービスの詳細については，『OpenVMS System Services Reference Manual: GETQUI-Z』を参照してください。

5.24.1.2 $PERSONAシステム・サービス:デフォルト特権の変更(Alpha のみ)

V7.2

ペルソナ特権を割り当てるときのデフォルト動作は，OpenVMS Alphaバージョン7.2 で変更されました。このリリースより以前には，ペルソナは， 指定されたユーザのUAFレコードに登録されている特権をデフォルト特権として使用して作成されていました。 ユーザのデフォルト特権は，$PERSONA_CREATE の呼び出しにIMP$V_ASSUME_DEFPRIVフラグがセットされている場合にだけ使用されていました。

このデフォルト動作は，OpenVMSセキュリティ・ポリシーと矛盾しているために，OpenVMS Alpha バージョン7.2で変更されました。新しいデフォルト動作では， ユーザのUAFレコードに指定されている特権を使用して，ペルソナが作成されます。

既存のプログラムをOpenVMS Alphaバージョン7.2で正しく実行するには， 指定されたデフォルト特権が登録されている特権と等しくなるように，ユーザのUAF レコードを変更しなければならない可能性があります。

2つの新しいフラグが$PERSONA_CREATEシステム・サービスに追加されました。ISS$V_CREATE_DEFPRIV は，以前のリリースのIMP$V_ASSUME_DEFPRIVフラグに相当し， 下位互換性を維持するためにだけ提供されます。ISS$V_ CREATE_AUTHPRIVは，呼び出し側がOpenVMSの以前のバージョンのデフォルト動作を実装できるように提供されます。 つまり，ユーザの登録されている特権をデフォルト特権として使用するために提供されます。

OpenVMS VAXバージョン7.2では，$PERSONA_CREATEの動作は変更されていません。

5.24.1.3 $PERSONAシステム・サービス:監査レコードの変更(Alpha のみ)

V7.2

ペルソナ作成のための監査レコードは，Server LoginタイプからPersona Createdタイプに変更されました。ペルソナは$PERSONA_CREATEシステム・ サービスを呼び出すことで作成されます。

5.24.2 問題点と制限事項

ここでは，システム・サービスの問題点と制限事項について説明します。

5.24.2.1 以前のバージョンで実行するためのSECURESHR イメージのリンク

V7.0

共有可能イメージ・ディスパッチ・ベクタにエントリ・ポイントが追加されました。 この変更により，SECURESHRのバージョン7.0以上に対してリンクされているアプリケーションは， バージョン7.0より以前のシステムで動作しません。SECURESHR を使用するシステム・サービスは次のとおりです。


$FORMAT_ACL
$PARSE_ACL
$FORMAT_AUDIT
$DELETE_INTRUSION
$SCAN_INTRUSION
$SHOW_INTRUSION
$ADD_PROXY
$DELETE_PROXY
$DISPLAY_PROXY
$VERIFY_PROXY

プログラムでこれらのシステム・サービスを使用しており，バージョン7.0 より以前のシステムで動作するバージョンを作成する必要がある場合は， バージョン7.0より以前のバージョンのOpenVMSを稼動しているシステムでプログラムをリンクしなければなりません。

5.24.2.2 $SUSPNDはクラスタ環境で正しく動作しない

VAX V6.0，
Alpha V1.5

$SUSPNDシステム・サービスを呼び出したときに，ターゲット・プロセスが$SUSPND サービスを呼び出しているプロセス以外のクラスタ・ノードで実行されている場合， カーネル・モードの一時停止フラグ(ビット0)は無視されます。 この結果，一時停止はスーパーバイザ・モードの一時停止として取り扱われます。

5.24.3 修正点

ここでは，複数のシステム・サービスの修正点について説明します。

5.24.3.1 $PERSONAの制限事項の解除(Alphaのみ)

V7.2

OpenVMSの以前のバージョンでは，$PERSONAシステム・サービス($PERSONA_ASSUME ，$PERSONA_CREATE，$PERSONA_DELETE)の使用に関して制限がありました。OpenVMS バージョン7.2では，これらの制限事項はなくなりました。

スレッド単位のセキュリティの詳細については，『OpenVMS Guide to System Security』を参照してください。$PERSONAシステム・サービスの詳細については， 『OpenVMS System Services Reference Manual』を参照してください。

5.25 X/Open Transport Interface (XTI)

ここでは，X/Open Transport Interface (XTI)のリリース・ノートをまとめます。

5.25.1 変更点と強化された機能

OpenVMSバージョン6.2以降，X/Open Transport Interface (XTI)プログラミング・ インタフェースがサポートされるようになりました。この実装は，XPG4 X/Open CAE XO/CAE/91/600 (ISBN 1 872630 29 4) X/Open Transport Interface (XTI)仕様に準拠しています。

サポートされるトランスポート

OpenVMSバージョン7.1以降では，DECnet for OpenVMS (フェーズIV) ，DECnet-Plus for OpenVMS (フェーズV)，TCP/IP Servicesトランスポートがサポートされます。 サポートの制限事項については，第5.25.2項を参照してください。

t_openルーチンで使用されるトランスポート名は，DECnetの場合は'dnet' であり，TCP/IPの場合は'ip/udp'または'ip/tcp'です。

他のネットワーキング・レイヤード・プロダクトでは，他のトランスポートを使用できます。OpenVMS XTI サポートの詳細については，各レイヤード・ プロダクトのドキュメントを参照してください。

アーキテクチャ

XTIはフロントエンドおよびバックエンド・コードでサポートされます。 フロントエンド・コードは，標準インタフェース・ルーチンへのアクセスを提供します。 バックエンド・コードは，フロントエンド・コードから選択されたネットワーキング・ トランスポートへのインタフェースを提供します。

サポート・イメージ・ファイルは次のとおりです。

XTIフロントエンド・コード SYS$SHARE:XTI$XTILIB.EXE
TCP/IP XTIバックエンド・ コード SYS$SHARE:XTI$IPSHR.EXE
DECnet XTIバックエンド・コード SYS$SHARE:XTI$DNETSHR.EXE
XTI Cプログラミング・インクルード・ファイル SYS$LIBRARY:XTI.H

リンクの要件

XTIプログラムをコンパイルした後，XTIとリンクするための追加修飾子は必要ありません。

ドキュメント

XTIに関するドキュメントは，OpenVMSドキュメンテーション・セットに含まれていません。 ドキュメントはX/Open Company Limitedに直接注文できます。 インターネットにアクセスできる場合は，次のURLを参照することで，X/Open Company Limited に関する詳細情報を取得できます(出版物も含めて) 。


http://www.xopen.co.uk/

また，X/Open Company Limitedと直接連絡をとることもできます。住所は次のとおりです。

5.25.2 問題点と制限事項

V6.2

OpenVMSシステムでXTIを使用する場合，次の制限事項があります。

さらに，t_open関数から返される't_info'構造は，特定のトランスポートに対して実装固有の制限事項を報告します(t_open コマンドの詳細については，XTI に関するドキュメントを参照してください)。

[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ] [ DOC Home ]