[ 前のページ ]
[ 次のページ ]
[ 目次 ]
[ 索引 ]
[ DOC Home ]
この章では，このバージョンの OpenVMS オペレーティング・システムでのアプリケーションおよびシステム・プログラミングに関連する新しい機能について説明します。
この節では，OpenVMS Alpha バージョン 7.2 でサポートされている新しいアダプタについて説明します。
ATMWORKS 351 アダプタは，PCI (peripheral component interconnect) スロットのあるシステムが ATM ネットワークを介して通信を行うことができるようにする高性能な，155 Mb/s，全二重の ATM アダプタです。 ATMWORKS 351 ドライバは，HWcu というデバイス名を持つ SYS$ATMWORKS351 ポート・ドライバによってサポートされています。 このとき，c はコントローラで u はユニット番号であり，たとえば，HWA0 のように指定します。
詳細については，『OpenVMS I/O User's Reference Manual』を参照してください。
OpenVMS Alpha バージョン 7.2 は，DE500-BA および DE504-BA アダプタのランタイムおよびブート・サポートを提供します。 DE500-BA および DE504-BA は，32 ビット PCI イーサネット・ネットワーク・インタフェース・カード (NIC) へのダイレクト・インタフェースのあるシングル・スロット・アダプタです。 DE500-BA はシングル・ポートで，DE504-BA には 4 つのポートがあります。 各ポートでは，Fast Ethernet (100 Mb/s) および 10 Mb/s の標準イーサネットのプロトコルを実行することができます。 どちらのアダプタも全二重および半二重モードをサポートし，単一のアダプタが Fast Ethernet または標準イーサネットのシステムと通信できるようにする柔軟な構成のためのどちらかの速度で動作することができます。 また，どちらのアダプタの NIC も，IEEE 802.3u の自動ネゴシエーションもサポートします。
DE500-BA は 8 ポジションのモジュラ・コネクタを使って，ハブ，スイッチまたは他の NIC に接続します。 このコネクタは，一般に RJ-45 と呼ばれているもので，データ・グレード 100-ohm カテゴリ 5 UTP または 150-ohm STP-A ケーブルの 2 つのペアを使用し，100 メートルまでの距離をサポートします。
OpenVMS Alpha バージョン 7.2 は，DE500-FA PCI FastEthernet ネットワーク・インタフェース・カード (NIC) のランタイムおよびブート・サポートを提供します。 DE500-FA は半二重および全二重モードで，100 Mb での動作を行うことができます。 この NIC は，IEEE 802.3u 仕様の 26 節に説明されている 100Base-FX 物理層をサポートしています。 100Base-FX は，2 本の 62.5/125 グレードのインデックス・マルチモード光ファイバ・ケーブル上で動作するように設計されています。 サポートされている最長距離は，半二重モードでは 412 メートル，全二重モードでは 2000 メートルです。 DE500-FA は SC 光ファイバ・コネクタを使用します。100Base-FX は自動ネゴシエーションも，10 Mb での動作もサポートしていません。
OpenVMS V7.2 は，DEGPA-SA PCI Gigabit イーサネット・ネットワーク・インタフェース・カード (NIC) のランタイム・サポートを提供します。 DEGPA-SA は，1000BASE-SX 光ファイバ・ケーブル上で，IEEE 802.3z Gigabit イーサネット標準に適合しています。 別の Gigabit イーサネット・アダプタへ，または Gigabit イーサネット・ハブ／スイッチへのポイント・トゥ・ポイントでの動作を行えます。 Gigabit イーサネットのサポートについての詳細は，第 3.19 節を参照してください。
クラスタ単位の論理名は，OpenVMS における既存の論理名サポートの拡張です。 これは OpenVMS Alpha と OpenVMS VAX で使用することができます。
この節では，アプリケーションの中でのクラスタ単位の論理名の使用に関する情報を提供します。 クラスタ単位の論理名について，DCL レベルでの作成方法などの一般的な情報については，第 3.16.2 項を参照してください。 アプリケーションで論理名を使用する方法についての詳細は，『OpenVMS Programming Concepts Manual』を参照してください。
$TRNLNM システム・サービスには 2 つの新しい属性が追加されています。
LNM$V_CLUSTERWIDE は，クラスタ単位の論理名の LNM$_ATTRIBUTES 項目を要求した場合に，項目リストに入れて返される出力属性です。
attr 引数ビットである LNM$M_INTERLOCKED を設定すると，実行中のクラスタ単位の論理名の変更操作は，名前が変換される前に必ず完了します。 LNM$M_INTERLOCKED は省略時の設定では設定されません。 アプリケーションがクラスタ単位の論理名の最新の定義を使って変換を行う必要がある場合には，この属性を使って，待ち状態の変更操作がすべて完了するまで変換を停止させます。
単独システムで，1 つのプロセスが論理名データベースの共用可能な部分を変更する場合，変更点はそのノード上の他のすべてのプロセスからただちに見えるようになります。 また，変更操作の実行中は，他のプロセスは共用可能な論理名の変換や変更は行えません。
一方，1 つのプロセスがクラスタ単位の論理名データベースを変更する場合，変更点はそのノード上ではただちに見えるようになりますが，他のノードに伝播され，そこで変更が加えられるまでにはしばらく時間がかかります。 省略時の設定では，クラスタ単位の論理名の変換は停止されません。 このため，複数のノード上のプロセスが論理名を変換した結果，変更の実行中に異なる等価名を受け取るということが起こる可能性があります。
LNM$M_INTERLOCKED を使用すると，アプリケーションは必ずクラスタ単位の論理名の最新の定義を受け取るようになります。
$GETSYI システム・サービスに，新しいクラスタ単位の属性である SYI$_CWLOGICALS が追加されました。 SYI$_CWLOGICALS を指定すると，$GETSYI はクラスタ単位の論理名データベースが CPU 上で初期化されている場合には数値 1 を，初期化されていない場合は値0を返します。 この数値は論理値 (1 または 0) なので，項目記述子の中のバッファ長フィールドは 1 (バイト) を指定していなくてはなりません。 非クラスタ化システムでは，SYI$_CWLOGICALS の値はつねに 0 です。
クラスタ単位のテーブルを作成するとき，$CRELNT の要求者はテーブル名を指定しなければなりません。 OpenVMS はクラスタ単位のテーブルの省略時の名前は提供しません。 さもないと，省略時の名前を使用することで，SYSPRV 特権を持たないプロセスが共用可能テーブルを作成できるようになるからです。
COM (Component Object Model) は，開発者が分散ネットワーク・オブジェクトを作成できるようにする Microsoft[R] 社の技術です。 DEC 社と Microsoft 社は，共同で COM 仕様を開発しました。 最初は NetOLE (Network Object Linking and Embedding) としてリリースされ，その後 DCOM (Distributed COM) に名称が変更されました。 現在，COM 仕様にはネットワーク・オブジェクトが含まれています。 COM for OpenVMS は，COM のドラフト規格をサポートする Microsoft のコードのインプリメンテーションです。
開発者は，次の方法で，OpenVMS 上に COM アプリケーションをインプリメントします。
OpenVMS 上に COM を実現するため，弊社は OpenVMS オペレーティング・システムに次のような変更を加えています。
Microsoft COM API のセットが OpenVMS に追加されています。 これらの API を使用すると，開発者は OpenVMS システム上で COM オブジェクトを作成したりデバッグしたりすることができます。 COM for OpenVMS の開発についての詳細は，COM for OpenVMS の開発者向けキットに同梱されている『OpenVMS Connectivity Developer Guide』を参照してください。
COM アプリケーションは，OpenVMS レジストリの内容について，追加，読み込み，変更，および削除を行うことができます。
OpenVMS レジストリの内容は，OpenVMS (REG$CP ユーティリティまたは $REGISTRY システム・サービスの使用) または Windows[R] NT[TM] (RegEdit または RegEdt32 の使用) のどちらからも参照および編集することができます。
これらの強化には，共通のユーザ認証や NTLM セキュリティによる承認済み RPC などがあります。 さらに，いくつかの DCE RPC 機能をベース・オペレーティング・システムに移すことにより，Microsoft RPC 呼び出しの限定的なサポートを提供しています。
アプリケーションは，システム，セキュリティ，およびアプリケーション・アクティビティ情報を OpenVMS イベント・ログに書き込みます。 ユーザは OpenVMS 上のイベント・ログの内容を OpenVMS (PATHWORKS Admin ユーティリティの使用) または Windows NT (Windows NT イベント ビューアの使用) のいずれからも参照することができます。
COM for OpenVMS は，OpenVMS オペレーティング・システムと一緒に出荷され，次のようにライセンスされています。
COM for OpenVMS のセキュリティは，2 つのフェーズでインプリメントされます。 以降の各項で，それぞれのフェーズについて説明します。
フェーズ 1: COM Version 1.0 for OpenVMS (認証なし)
このフェーズでは，COM for OpenVMS プロセスは，OpenVMS セキュリティ ID でのみ実行します。 つまり，OpenVMS は Windows NT クライアントからの COM 要求の認証を行わず，いかなる Windows NT セキュリティ証明 (クレデンシャル) も処理しません。
OpenVMS のシステム管理者は，次の方法で，COM サーバ・プロセスの COM for OpenVMS セキュリティ ID を設定することができます。
DCOM$GUEST ID でプロセスを実行する。
DCOM$GUEST は，インストレーション中に COM for OpenVMS によって作成される特権のないアカウントです (これは省略時の動作)。
この場合，システム管理者は，そのアカウトを作成した人が定義したように，特権，ライト，および制約を持つ OpenVMS のアカウントを作成します。 このアカウントから実行する COM サーバは，そのアカウントの OpenVMS セキュリティ・コンテキストに制限されます。
COM Version 1.0 for OpenVMS はリモート・ユーザの認証を行わないため，COM for OpenVMS は認証が行われた場合と同様にクライアントの要求を受け入れて処理します。 完全な NTLM のインプリメンテーションよりも安全性は劣りますが，COM Version 1.0 for OpenVMS は，OpenVMS のアカウントを使用してサーバを実行することにより，セキュリティ・リスクを最小限にします。 COM Version 1.0 for OpenVMS は，プロセス単位をベースにしてセキュリティを強化しているため，結果として，メソッドごとのセキュリティは利用できません。
COM プロセスには関連するNTセキュリティ証明がなく，COM Version 1.0 for OpenVMS に認証メカニズムが存在しないため，Windows NT システムは，Windows NT システムへの出力要求を認証されていないものとして処理します。 COM for OpenVMS クライアント・アプリケーションについて COM サーバ・プロセスを実行する Windows NT システムでは，特定のサーバ・アプリケーションが全員にアクセスできるようにする必要があります。
完全な NTLM 認証 (COM Version 1.1 for OpenVMS) が利用可能な場合，Compaq は別のオプション client access を追加します。 このオプションでは，COM for OpenVMS サーバ・プロセスが要求側の Windows NT クライアントのセキュリティ・コンテキスト内で実行できるようになります。 COM for OpenVMS サーバ・プロセスには，OpenVMS がレジストリ・アクセスおよび出力 COM 要求について使用できる Windows NT セキュリティ証明が含まれます。
COM Version 1.0 for OpenVMS ソフトウェア要件
COM Version 1.0 for OpenVMSは，NTLM セキュリティ機能 (便宜的なセキュリティ，SSPI，および認証済み RPC) を使用しません。 COM Version 1.0 for OpenVMS は，Advanced Server for OpenVMS (以前の PATHWORKS サーバ) を必要とせず，また使用もしません。 Advanced Server for OpenVMS が必要になるのは，Windows NT システムから接続して OpenVMS レジストリにアクセスする場合です。 イベント・ロギングは PATHWORKS の一部であり，COM Version 1.0 for OpenVMS で使用することはできません。
フェーズ 2: COM Version 1.1 for OpenVMS (NTLM 認証あり)
このフェーズでは，COM for OpenVMS は，OpenVMS のセキュリティ ID を処理し，Windows NT クライアントからの COM 要求を認証して，Windows NT セキュリティ証明を処理します。 これは，COM for OpenVMS 用の NTLM (NT LAN Manager) セキュリティの完全なインプリメンテーションです。
COM Version 1.1 for OpenVMS ソフトウェア要件
COM Version 1.1 for OpenVMS は，NTLM セキュリティ機能 (便宜的セキュリティ，SSPI，および認証済み RPC) を使用します。 COM Version 1.1 for OpenVMS では，Advanced Server for OpenVMS (以前の PATHWORKS サーバ) を必要とします。 COM Version 1.1 for OpenVMS は，イベント・ロギングを有効にします。
次の表に，COM Version 1.0 for OpenVMS と COM Version 1.1 for OpenVMS の相違をまとめます。
| 項目 | バージョン 1.0 | バージョン 1.1 |
|---|---|---|
| クライアント要求 | Windows NT 上での認証; OpenVMS への要求では認証は行われない。 | Windows NT および OpenVMS での認証。 |
| セキュリティ | サーバは，Windows NT 上ではクライアントの ID で実行し，OpenVMS 上ではあらかじめ指定されている OpenVMS の ID で実行できる。 | サーバは，Windows NT および OpenVMS 上で，クライアントの ID で実行できる。 |
| セキュリティ | Windows NT 上では，メソッドごとのセキュリティが設定できるが，OpenVMS 上ではプロセス単位のセキュリティだけ許される。 | Windows NT および OpenVMS 上でメソッドごとのセキュリティが許される。 |
| 出力 COM 要求 | Windows NT 上でのみ認証される。 | Windows NT および OpenVMS 上で認証される。 |
| レジストリ・アクセス | Windows NT 上: NT セキュリティ証明によって制御される。
OpenVMS 上: 特権やライト識別子などの OpenVMS のセキュリティ制御に依存する。 | Windows NT 上: NT セキュリティ証明によって制御される。
OpenVMS 上: Windows NT セキュリティ証明または OpenVMS のセキュリティ制御のいずれかで制御される。 |
| イベント・ロギング | Windows NT のみ | Windows NT および OpenVMS |
OpenVMS レジストリは，次の 2 つの方法で OpenVMS レジストリキーへのアクセスを制御することができます。
NTLM セキュリティは，NT セキュリティ証明を使用して，レジストリ・キーへのアクセスを制御し，特定のキーへのアクセスを制御するために使用できます。
OpenVMS セキュリティは，OpenVMS の特権とライト識別子を使用して OpenVMS レジストリデータベースへのアクセスを制御します。 これは，特定のキーへのアクセスを制御するために使用することはできません。
COM アプリケーションは COM レジストリ・キーへの読み込みアクセスを必要とし，COM 開発者は COM レジストリ・キーへの読み込み/書き込みアクセスを必要とします。 COM Version 1.0 for OpenVMS (認証なし) では，COM for OpenVMS は NT セキュリティ証明を持っておらず，その結果として，COM Version 1.0 for OpenVMS は OpenVMS のセキュリティを使用して OpenVMS レジストリへのアクセスを制御します。 この OpenVMS レジストリへのアクセスはキーごとに制御できないため，すべての COM アプリケーションに OpenVMS レジストリ全体への読み込みアクセスを許可しなければならず，すべての COM 開発者に OpenVMS レジストリ全体への書き込みアクセスを許可しなければなりません。 これは，COM for OpenVMS で使用されていない PATHWORKS の部分を含めて，OpenVMS レジストリ全体にCOMのアプリケーションおよび開発者がアクセスできることを意味します。
COM Version 1.1 for OpenVMS (NTLM 認証あり) では，COM for OpenVMS は NT セキュリティ証明を使用して，特定の OpenVMS レジストリキーへのアクセスを制御し，OpenVMS の特権およびライト識別子を削除します。 これにより，COM for OpenVMS で使用されない部分の OpenVMS レジストリを保護します。
OpenVMS バージョン 7.2 には，特定のファイル属性に関連する修飾子についてコマンド行を解析し，処理中のファイルをコマンド行から検索した選択基準と照合できるようにする UTIL$CQUAL ルーチン群が含まれています。 このユーティリティ・ルーチンを使用すると，明示的に実行するアプリケーション・ライタがなくても，ユーザはファイルを選択して端末 I/O を実行することができます。
共通ファイル修飾子ルーチンは，UTIL$CQUAL という文字列で始まります。 プログラムは，OpenVMS 呼び出し標準規則を使用してこれらのルーチンを呼び出します。 UTIL$CQUAL ルーチンを呼び出す場合は，必要な引数をすべて指定する必要があります。 完了時には，ルーチンは状態値として完了状態を返します。
次の表に，共通ファイル修飾子ルーチンの一覧を示します。
| ルーチン名 | 説明 |
|---|---|
| UTIL$CQUAL_FILE_PARSE | ファイル修飾子についてコマンド行を解析し，関連する値を取得する。照合および終了ルーチンを呼び出す際に使用するコンテキスト値を返す。 |
| UTIL$CQUAL_FILE_MATCH | ルーチン・ファイル入力を解析ルーチン呼び出しで取得したコマンド行データと比較する。 |
| UTIL$CQUAL_FILE_END | コマンド行解析ルーチン呼び出しの間に割り当てられたすべての仮想メモリを削除する。 |
| UTIL$CQUAL_CONFIRM_ACT | SYS$COMMAND から問い合わせに応答するようにユーザにプロンプトを表示する。 |
共通ファイル修飾子ルーチンを使用するには，次の手順に従ってください。
オプションとして UTIL$CQUAL_CONFIRM_ACT を呼び出すと，他の共通修飾子ルーチンを呼び出さなくても，ユーザの確認を求めることができます。
共通ファイル修飾子ルーチンについての詳細は，『OpenVMS Utility Routines Manual』を参照してください。
この節では，OpenVMS バージョン 7.2 のための新しい DECthreads の機能について説明します。
DECthreads は，使用可能なスタック領域とガード・ページの間に，特別に保護されたメモリ領域を用意するようになりました。 ここへのアクセスが起こると，VMS exec はこのメモリの保護を解除し，ユーザ・スレッドに対してスタック・オーバフロー例外が送信されます。 この機能により，アプリケーションはスタック・オーバフロー条件を捕捉し，回復または正常な終了を試みることができます。
DECthreads は，読み込み／書き込みロックと呼ばれる複数の読み込み者，単一の書き込み者のロックの使用をサポートするようになりました。 このロックでは，複数のスレッドがデータに対して読み込み専用アクセスを同時に行うことができ，またどの瞬間でも 1 つのスレッドだけが書き込みアクセスを行えます。 この種のロックは，一般には読み込みの頻度が書き込みの頻度よりも高いデータを保護するために使用されます。
このサポートの一環として，DECthreads POSIX 1003.1c ライブラリに次に示す新しいルーチンが追加されました。
pthread_rwlock_destroy()
pthread_rwlock_init()
pthread_rwlock_rdlock()
pthread_rwlock_tryrdlock()
pthread_rwlock_trywrlock()
pthread_rwlock_unlock()
pthread_rwlock_wrlock()
pthread_rwlockattr_destroy()
pthread_rwlockattr_init()
DECthreads のデバッギング・サポートが強化され，Compaq とサードパーティのデバッガが DECthreads とより緊密に統合できるようになりました。 これまでは SDA を通してしか利用できなかった 'pthread' デバッギング・インタフェースが，OpenVMS Debugger からも利用できるようになっています。
OpenVMS バージョン 7.2 以降，リモート・プロシージャ・コール (RPC) の機能はオペレーティング・システムに統合されることになります。 RPC は，異機種システムの間でのアプリケーション内の個々のプロシージャの接続機能を透過的に提供します。 この機能は DIGITAL Distributed Computing Environment (DCE) RPC を使用しますが，Microsoft RPC アプリケーション・プログラミング・インタフェース (API) と DIGITAL DCE RPC API を使用できる能力も提供します。 アプリケーションは RPC を使って，DIGITAL DCE または Microsoft RPC アプリケーションとの相互運用を行うことができます。 セキュリティが必要な場合には，Microsoft の NTLM セキュリティか，(DIGITAL DCE Run-Time Kit を完全にインストールすることで) DCE セキュリティを使用できます。
RPC デーモンにより，クライアント/サーバ RPC アプリケーションは自分に固有のエンドポイントを登録することができます。 エンドポイントの登録によって，アプリケーションの遠隔クライアントはシステム上のサーバ・アプリケーションのエントリ・ポイントを見つけ出せるようになります。
RPC アプリケーションを開発するためには DIGITAL DCE Application Developer's Kit (別途ライセンス) が必要ですが，その結果として得られたアプリケーションは任意の OpenVMS バージョン 7.2 システムに，または DIGITAL DCE Run-Time Kit が完全にインストールされている任意のサポート対象の OpenVMS システムにインストールすることができます。 DIGITAL DCE Run-Time Kit は，OpenVMS CD-ROM で出荷されていますが，OpenVMS オペレーティング・システムと一緒にライセンシングされているもので，ソフトウェア・ライセンスを別途購入する必要はありません。
RPCデーモンの起動と停止は，次の新しいコマンド・ファイルを使って行うことができます。
これらのコマンド・ファイルはディレクトリ SYS$COMMON:[SYSMGR] に置かれています。
RPC デーモンを起動するには，DCE$RPC_STARTUP.COM プロシージャを実行します。 次のオプションを指定することができます。
ユーザに対するプロンプトのオン／オフを切り替える。省略時の設定は CONFIRM。
RPC デーモンを停止するには，DCE$RPC_SHUTDOWN.COM プロシージャを実行します。 次のオプションを任意の順序で指定することができます。
ユーザに対するプロンプトのオン／オフを切り替える。省略時の設定は CONFIRM。
CLEAN
RPC エンドポイント・データベースからすべてのエントリを削除する。
RPC エンドポイントは RPC Control Program (RPCCP) を使って管理することができます。 このユーティリティを起動するには，次のコマンドを入力します。
$ RUN SYS$SYSTEM:DCE$RPCCP.EXE
システム・プロンプトで help と入力すると，パラメータの使用方法に関する情報が表示されます。
RPC デーモンは，RPC アプリケーションが使用するプロトコルを制限することができます。 使用可能なプロトコルを制約するには，論理名 RPC_SUPPORTED_PROTSEQS に有効なプロトコルの名前を設定します。 有効なプロトコルは ncadg_ip_udp，ncacn_ip_tcp および ncacn_dnet_nsp です。 各プロトコルはコロンで区切ります。 次に例を示します。
$ define RPC_SUPPORTED_PROTSEQS "ncacn_ip_tcp:ncacn_dnet_nsp"
この定義により，RPC アプリケーションは TCP/UDP を使用するエンドポイントを登録できなくなります。
『OpenVMS V7.2 リリース・ノート[翻訳版]』には DIGITAL DCE for OpenVMS の既存ユーザのための重要な情報があります。
DIGITAL DCE for OpenVMS の詳細については，オンライン・ヘルプまたは次のドキュメンテーションを参照してください。
OpenVMS Alpha バージョン 7.2 では，VLM アプリケーションは，グローバル・セクションを介して，プロセスによって共用されているメモリに対して Fast I/O を使用することができます。 OpenVMS Alpha の以前のバージョンでは，バッファ・オブジェクトはプロセス専用の仮想アドレス空間に対してのみ作成することができました。 複数のプロセスが大規模なキャッシュを共用するデータベース・アプリケーションは，現在では，次のタイプのグローバル・セクションについて，バッファ・オブジェクトを作成することができます。
バッファ・オブジェクトは Fast I/O システム・サービスを使用可能にします。 このシステム・サービスは，I/O デバイスに対して膨大な量の共用データの読み込みおよび書き込みをより高速に行うために使用することができます。 Fast I/O は，1 つの I/O 要求当たりの CPU コストを削減することにより，I/O 操作のパフォーマンスを向上します。 Fast I/O は，データベース・サーバなどのような VLM アプリケーションの性能を改善することにより，より大量のデータ処理およびスループット速度の向上に対処します。
Fast I/O およびグローバル・セクションのためのバッファ・オブジェクトを使用する方法についての詳細は，『OpenVMS Alpha 64 ビット・アドレッシングおよび VLM 機能説明書』を参照してください。
Fast Path は，I/O 性能を向上させるために設計されたオプションの高性能機能です。 Fast Path は，デバイスへの効率的なパスを作成します。 Fast Path は，強化された I/O 性能が必要なアプリケーションにとっては興味深いものです。 使用が適した例としては，ディスクへのデータの転送速度がしばしば重大な関心事となるようなデータベース・システムとリアル・タイム・アプリケーションの 2 つがあります。
Fast Path 機能を使用するためにソース・コードを変更する必要はありません。 Fast Path の利点を最大限に活用したいエキスパートのプログラマは，インタフェースを多少変更することができます。
OpenVMS Alpha バージョン 7.1 から，Fast Path では，CIXCD および CIPCA ポート用のディスク I/O をサポートしています。 これらのポートは，XMI および PCI ベースのシステムについて CI ストレージへのアクセスを提供しています。 バージョン 7.0 では，Fast Path では CIXCD ポート用にだけディスク I/O をサポートしていました。
Fast Path は，OpenVMS VAX オペレーティング・システムでは利用できません。
詳細については，本書の表 1-1 と第 4.21.5 項，および『OpenVMS I/O User's Reference Manual』を参照してください。
ユーザ作成プログラムからテープ装置にアクセスする場合は，新しい修飾子 IO$M_ALLOWFAST を使用して，IO$_SKIPFILE 機能の動作を制御することができます。
以前は，OpenVMS では必ず，移動を行うスキップ・レコード・コマンドを使用してテープ上のファイルをスキップしていました。 これは，本質的にファイルマークによるスキップをシミュレートしており，正しく機能しますが，このタイプのスキップは，ファイルマークによるスキップ・コマンドを使用した場合に比較して，時々，非常に遅いことがあります。
OpenVMS V7.2 では，ユーザが許可した場合には，ファイルマークによるスキップを使用するようにテープ装置を設定できるようになりました。 現在のテープ装置は，論理データの終わりを記録しているため，テープ装置にこれらの機能がある場合，MKdriver はこれらの機能を使用して，正しく位置決めすることができます。 これらの機能がない場合には，旧式のレコードによるスキップが使用されます。
ファイルマークによるスキップが使用されている場合，二重の EOF でテープが終了していれば，このスキップはテープの終端を正しく検出します。 ANSI フォーマットのテープを使用する Backup やファイル構造化コピーなどのユーティリティでは，終端の位置決めが正しく設定されていることを必要とし，新しいスキップ方式でうまく動作します。 空ファイルがある場合には，すでに空ファイルについてスキップ・ファイル操作が行われています。
ただし，サードパーティ製のユーティリティのなかには，テープ上の二重の EOF では，ファイルによるスキップを停止するというドキュメント済みの動作に依存するものがあります。 この問題に対処するため，OpenVMS は，省略時の設定ではテープ動作として旧式のレコードによるスキップの使用を想定します。
この形式の位置決めはファイルによるスキップより 100 倍も遅いため，OpenVMS では次の 2 つの機能を追加しています。
この節では，OpenVMS Alpha Hypersort ユーティリティのコマンド行インタフェースおよび呼び出し可能インタフェース (SOR ルーチン) に関連する新しい機能について簡単に説明します。 この情報は，一般ユーザおよびプログラマ向けのものです。
これらの新機能および OpenVMS Alpha Hypersort ユーティリティの使用方法についての詳細は，『OpenVMS ユーザーズ・マニュアル』および『OpenVMS Utility Routines Manual』を参照してください。
スレッドのサポートが Hypersort ユーティリティに追加されました。 これにより，SMP 構成システムで複数のプロセッサを利用することによって強化された性能が使用可能になります。
マルチプロセッサ・マシンで Hypersort ユーティリティを使用している場合に最高の性能を得るためには，/THREADS_ENABLE 修飾子を指定してプログラムをリンクしてください。
索引順編成出力ファイル構成のサポートが Hypersort ユーティリティに追加されました。
現在は，/INDEXED_SEQUENTIAL ファイル構成修飾子を指定することができます。
出力ファイルの重ね書きのサポートが，Hypersort ユーティリティに追加されました。
現在では，既存の空ファイルに出力ファイルを重ね書きしたり書き込んだりするための /OVERLAY 修飾子を指定できます。
統計要約情報の部分サポートが Hypersort ユーティリティに追加されました。
現在では，次のフィールドについて /STATISTICS 修飾子を指定することができます。
新しいクラスタ内通信 (ICC) システム・サービスは，Alpha および VAX 上で使用することができ，プロセス間通信を行うためのアプリケーション・プログラミング・インタフェース (API) を構成します。 大量のデータ転送では，ICC システム・サービスは，最高性能の OpenVMS アプリケーション通信メカニズムであり，標準のネットワーク・トランスポートおよびメールボックスよりも優れています。
ICC システム・サービスにより，アプリケーション・プログラム開発者は 1 つのシステム上で実行されている異なるプロセス間，または 1 つの OpenVMS Cluster システム内の異なるシステム上で実行されている複数のプロセス間に接続を持つ分散アプリケーションを作成することができます。
ICC システム・サービスではネットワーク・プロダクトを必要としません。 通信にはメモリまたは System Communication Services (SCS) を使用します。
ICC システム・サービスには，次の機能があります。
ICC システム・サービスは，次の利点を提供します。
新しいシステム・サービスを使用すると，アプリケーション・プログラム開発者は，1 つの OpenVMS Cluster システム内の同じまたは異なるシステム上のプロセス間に接続を作成することができます。
これらのサービスを次に示します。
ICC システム・サービスについての詳細は，『OpenVMS System Services Reference Manual: GETQUI-Z』を参照してください。
ICC を使用したプログラミングについては，『OpenVMS Programming Concepts Manual』を参照してください。
ICC のシステム管理およびセキュリティについては，『OpenVMS システム管理者マニュアル』を参照してください。
Java Development Kit (JDK) は OpenVMS オペレーティング・システムと一緒に出荷されます。 このキットを使うと，OpenVMS Alpha システム上で Java アプレットとプログラムを開発して，実行することができます。
OpenVMS システム用の JDK はジャスト・イン・タイム・コンパイラ (JIT) を含んでいます。 JIT コンパイラは，アプリケーションのJavaバイト・コードとランタイム呼び出しを動的にコンパイルし，ネイティブな Alpha マシン・コードを生成します。 その結果，Java アプリケーションの実行速度が，Java インタプリタを使った場合と比べて大幅に高速化されます。 JAVA コマンドが入力されると，省略時の設定では JIT が実行されます。
JDK はネイティブな (POSIX) スレッド上に Java スレッドをインプリメントしています。 これにより，マルチプロセッサ・マシン上では，アプリケーション内の異なる Java スレッドを異なるプロセッサ上で実行することができます。 これはまた，POSIX スレッドを使ってインプリメントされているネイティブなメソッドや API (DCE など) とリンクされたときに，Java アプリケーションが正しく動作するということも意味します。
詳細については，OpenVMS Alpha システムの，JDK がインストールされている次のディレクトリの Java ドキュメンテーションを参照してください。
SYS$COMMON:[SYSHLP.JAVA]INDEX.HTML
OpenVMS Alpha バージョン 7.2 には，次の新しいカーネル・スレッド機能が追加されています。
OpenVMS のカーネル・スレッド・サポートの最初のリリースでは，プロセス 1 つにつき 16 個までのカーネル・スレッドがサポートされていました。 これにより，アプリケーションは同時に 16 個までの CPU 上でスレッドを実行させることができました。 OpenVMS Alpha バージョン 7.2 では，プロセス 1 つ当たりに作成できるカーネル・スレッドの数は 256 個に増やされています。 また，MULTITHREAD システム・パラメータの最大値も 256 に増やされています。
SYS$SETPRI システム・サービスと SET PROCESS/PRIORITY DCL コマンドは，どちらも入力としてプロセス識別値 (PID) を取ります。 このため，一度に 1 つのカーネル・スレッドしか対象にすることができません。 プロセス内のすべてのカーネル・スレッドの基本優先順位を変更したいと思ったら，個々のスレッドについて SYS$SETPRI を呼び出すか，SET PROCESS/PRIORITY コマンドを起動する必要があります。
OpenVMS Alpha バージョン 7.2 では，SYS$SETPRI システム・サービスの 'policy' パラメータに新しい値が追加されました。 JPI$K_ALL_THREADS が指定されていると，SYS$SETPRI の呼び出しはターゲット・プロセスの中のすべてのカーネル・スレッドの基本優先順位を変更します。
また，SET PROCESS/PRIORITY DCL コマンドにも，同じ操作をサポートする ALL_THREADS 修飾子が追加されています。
プロセス内の省略時のユーザ・スタックは，要求に応じてかなり大きなサイズにまで拡大することができるので，一般にシングル・スレッド・アプリケーションがユーザ・スタックをオーバフローさせることはありません。 アプリケーションが DECthreads を使って書かれている場合，各スレッドは独自の固定サイズのユーザ・スタックを受け取ります。 アプリケーション開発者が必要なスタックの量を過小評価すると，スレッドがスタックをオーバフローして，アプリケーションが実行に失敗する可能性があります。 この失敗は一般にアクセス違反として報告され，診断が非常に困難です。 この問題に対処するために，OpenVMS バージョン 7.2 ではイエロー・スタック・ゾーンが導入され，DECthreads を使用するアプリケーションに提供されています。
イエロー・スタック・ゾーンは，スタック・オーバフローをアプリケーションに対して通知するためのメカニズムです。 これにより，アプリケーションはスタック・オーバフロー・ハンドラを提供するか，何も行わないかを選ぶことができます。 アプリケーションが何も行わない場合，このメカニズムはアプリケーション開発者が失敗の原因を判断するのに役立ちます (アクセス違反の代わりにスタック・オーバフロー・エラーが通知されます)。
この節では，次の OpenVMS デバッガの新機能について説明します。
詳細については，『OpenVMS デバッガ説明書』を参照してください。
Alpha システムでは，SET BREAK コマンドに新たに /SYSEMULATE 修飾子が追加され，指定されたクラスの命令がエミュレートされたときに，デバッガがプログラムの実行を必ず中断するようなブレークポイントを設定できるようになりました。 任意に指定できるマスクを使用すると，ブレークポイントを起動するエミュレートされた命令のクラスを指定できます。 現在定義されているエミュレートされた命令のクラスは，BYTE 命令と WORD 命令だけです。 これはマスクでビット 0 によって定義されます。
Alpha システムでは，OpenVMS デバッガは，C++ モジュールをデバッグするための強化されたサポートを提供しています。 デバッグ・サポートには，次のようなものがあります。
起動時間を改善するために，デバッガは最初の起動時に DFT (Debug Fixup Table) を処理しなくなりました。 デバッガは，モジュールが "set" されるときに，DFT を処理するようになりました。
この項では，追加および変更されたデバッガ・コマンドについて説明します。
OpenVMS デバッガでは，OpenVMS DUMP コマンドと同じ形式でメモリの内容を表示するために，新たに DUMP コマンドが追加されています。 DUMP コマンドはレジスタ，変数，配列も含めて，メモリの内容を表示します。次の修飾子を使用できます。
デバッガのSET BREAKコマンドに/HANDLER修飾子が新たに追加されました。 この修飾子を使用すると，デバッグしているプログラムで例外が発生したときに，デバッガは呼び出しスタックをスキャンし，設定されている各フレーム・ベースのハンドラにブレークポイントを設定しようとします。 デバッガは標準の実行時ライブラリ (RTL)・ハンドラとユーザ定義ハンドラを区別しません。
Alpha システムでは，ユーザ・プログラムが独自のハンドラを定義しているフレームに，多くの RTL がジャケット RTL ハンドラを確立します。 この RTL ジャケットは，ユーザが定義したハンドラを実際に呼び出す前に，何らかの設定と引数の操作を実行します。 例外を処理するときに，デバッガはジャケット RTL ジャケット・ハンドラにブレークポイントを設定します。 これは，このハンドラが呼び出しスタックのアドレスだからです。 デバッガがジャケット RTL ハンドラでプログラムの実行を中断した場合には，通常，STEP/CALL コマンドと STEP/IN コマンドを入力することにより，ユーザ定義ハンドラに到達することができます。 場合によっては，STEP/CALL コマンドと STEP/IN コマンドを追加入力しなければならないことがあります。
ジャケット RTL ハンドラが，ALPHA LIBOTS などのインストールされている共用イメージの一部である場合には，デバッガはブレークポイントを設定できません。 この場合には，RTL を論理名として定義することにより，RTL をプライベート・イメージとして起動します。次の例を参照してください。
DEFINE LIBOTS SYS$SHARE:LIBOTS.EXE;
.EXE ファイル拡張子の後のセミコロンは必ず指定しなければなりません。
画面モードで SET TERMINAL コマンドに /WRAP 修飾子が新たに追加され，メッセージ出力表示で出力メッセージを書式化するときに，デバッガがキャリッジ・リターンとライン・フィードを挿入する位置を制御できるようになりました。 /WRAP 修飾子は，折り返しカラムを，/WIDTH 修飾子によって設定されている現在の値に設定します。 次の例を参照してください。
SET TERM/WIDTH:20/WRAP
Alpha システムでは，/NODEBUG/DSF=filespec 修飾子を使用してリンクされたプログラムをデバッグできるようになりました。 ただし，DBG$PROCESS が DEFAULT または MULTIPROCESS として定義されている構成で実行しなければならず，必要な .DSF ファイルが存在するディレクトリを指すように，DBG$IMAGE_DSF_PATH を定義しなければなりません。 このディレクトリ内の .DSF ファイルだけがデバッグ対象イメージをデバッグするのに必要なファイルでなければなりません。
デバッガは次の Fortran 演算子をサポートするようになりました。
| 演算子 | 意味 |
|---|---|
| == | ... に等しい |
| /= | ... に等しくない |
| < | ... より小さい |
| > | ... より大きい |
| <= | ... に等しいか，小さい |
| >= | ... に等しいか，大きい |
| % | フィールド区切り文字 |
Alpha システムでは，新しい定義済みディスプレイ REG が追加され，16 進形式で汎用レジスタ R0 〜 R28，FP (R29)，SP (R30)，R31，PC，PS，浮動小数点レジスタ F0 〜 F31 の内容が表示されるようになりました。 また，ディスプレイに表示できる数だけ，呼び出しスタックの値も表示されます。
Alpha システムでは，新しい定義済みディスプレイ IREG が追加され，16 進形式で汎用レジスタ R0 〜 R28，FP (R29)，SP (R30)，R31，PC，PS の内容が表示されるようになり，また，ウィンドウに表示できる数だけ，呼び出しスタックの値も表示されるようになりました。
Alpha システムでは，新しい定義済みディスプレイ FREG が追加され，浮動小数点レジスタ F0 〜 F31 の内容が浮動小数点形式で表示され，FPCR と SFPCR が表示され，ウィンドウに表示できる数だけ，呼び出しスタックの値も (16 進形式で) 表示されるようになりました。
VAX システムでは，定義済みディスプレイ IREG が新たに追加され，定義済み REG ディスプレイと同じ情報を表示するようになりましたが，ディスプレイ・ウィンドウの構成は少し異なります。 ディスプレイ IREG が VAX インプリメンテーションに含まれているのは，VAX デバッグ・アプリケーションと Alpha デバッグ・アプリケーションの間でデバッガの .COM ファイルと .INI ファイルを簡単に移植できるようにするためです。
この節では，RTL ルーチン LIB$GET_LOGICAL について説明します。
LIB$GET_LOGICAL は，$TRNLNM システム・サービスへの簡略なインタフェースを提供します。 これは，いくつかのメリットを追加して $TRNLNM のほとんどの機能を提供しています。 文字列引数については，Run-Time Library でサポートされているすべての文字列クラスが認識されます。 高水準言語では構成の難しい項目記述子のリストを，LIB$GET_LOGICAL により内部的に処理します。
ルーチン LIB$GET_LOGICAL についての詳細は，『OpenVMS RTL Library (LIB$) Manual』を参照してください。
この節では，OpenVMS バージョン 7.2 リリースで強化された RMS の機能について説明します。
OpenVMS バージョン 7.2 では，RMS と File Access Listener (FAL) の両方が強化され，ファイルの日付および時刻情報 (ファイルの作成や変更など) を交換するための 128 ビットの協定世界時 (UTC) フォーマットがサポートされました。
この機能強化により，RMS と FAL はファイルの日付と時刻の情報の交換で 2 つの形式をサポートすることになります。
以前のバージョンの RMS と FAL では，(DAP 仕様には含まれていない) 独自のインプリメンテーションとして，1970 年を基準として年を 2 桁で表現する形式が使用されていました。 70 から 99 までの YY は 1970 年から 1999 年までに対応します。 00 から 69 までの YY は 2000 年から 2069 年までに対応します。 このため，これまでのバージョンでは 2000 年問題は回避されています。
システム構成メッセージの中でファイル転送を要求するクライアントが，「バイナリの日付／時刻形式のサポート」を示すシステム・ケーパビリティ (SYSCAP) を設定した場合，OpenVMS は，省略時の設定では UTC 形式を使用します。 また，このバージョンではすべての OpenVMS クライアントでこのシステム・ケーパビリティが設定されます。
OpenVMS 以外のクライアントが UTC ケーパビリティを設定しなかった場合には，現在の年を 2 桁で表現する方式が使用されます。 OpenVMS の RMS と FAL のコードにインプリメントされている，1970 年を基準とする切り替えは DAP 仕様の一部ではないことに注意してください。 このため，OpenVMS 以外のクライアントで，そもそも切り替えがインプリメントされている，または 1970 年という特定の年を基準とした切り替えがインプリメントされていると仮定することはできません。
RMS は，ファイル長ヒントの格納，取り出し，および保持を行えるようになりました。 ファイル長ヒントは，次の内容を持つクォドワード整数フィールド (16 バイト) のペアです。
On-Disk Structure Level 5 (ODS-5) ボリューム上の可変 (VAR) または固定長制御部付可変長 (VFC) のレコード形式を持つシーケンシャル・ファイルでは，次の条件が満たされている場合，RMS はファイル・ヒントを保持しなければなりません。
$OPEN または $DISPLAY 操作で，項目リスト XAB とともに XAB$_FILE_LENGTH_HINT 項目コードを使用して，ファイル長ヒントの値を調べることができます。 $CLOSE 操作で SETMODE を使用して，ファイル長ヒント・カウントを設定することができます。 SETMODE は，RMS が同時に保持しているすべてのカウントを無効にします。
XAB$_FILE_LENGTH_HINT XABITM は，2 つのクォドワードのために 16 バイトのバッファを必要とします。 これらのフィールドは 1 つのセットとして保持されており，両方のフィールドが有効であるか，無効であるかのどちらかになります。
各クォドワードの最上位 (符号) ビットは，関連付けられたカウントが有効であるかどうかを示すために使用されます。 ODS-5 ボリューム上に作成された VAR または VFC 形式のシーケンシャル・ファイルで，RMS レコード I/O ($PUT) を使ってデータが追加されており，上記の条件を満たしているものは，有効なカウントを持っているはずです。 しかし，いずれかの時点で，何らかのデータが RMS ブロック I/O などを使ってファイルに書き込まれると，ファイル・デアクセスの際に符号ビットにカウントが無効であることを示すビットがセットされます。 各フィールドに保持されている最後のカウントは，最後の有効な値が何であったかを示すヒントとして残されますが，符号ビットがセットされているために，それが無効な値であることがわかります。
ODS-5 ボリューム上のファイルで，これらのフィールドが RMS によって変更されたことがなかった場合，各クォドワードの内容は 8 バイトの 0xFF となります。 たとえば，On-Disk Structure Level 2 (ODS-2) ボリューム上でもともと作成され，保持されていたファイルが ODS-2 形式から ODS-5 形式に変換された後，これらのフィールドは 8 バイトの 0xFF を含むことになります。
これらのフィールドのカウントは，(ゼロへの打ち切りの場合を除き) 格納時の打ち切りが行われた場合には無効になります。
この項目コードを使用する SENSEMODE が非 ODS-5 ファイルに対して要求されると，各クォドワードについて返される内容は 8 バイトの 0xFF となります。 非 ODS-5 ファイルに対する，この項目コードを使用する SETMODE は無視されます。
ファイル長ヒントは DECnet 操作ではサポートされず，無視されます。 SENSE が試みられると，各クォドワードについて 8 バイトの 0xFF がユーザ・バッファに返されます。
OpenVMS バージョン 7.2 では，Analyze/RMS_File ユーティリティに新しい修飾子 /UPDATE_HEADER が追加されました。 /UPDATE_HEADER 修飾子は，ファイル・ヘッダ内の属性，最大レコード長 (LRL) とファイル長ヒント属性の一方または両方を更新しようとします。 この修飾子は，/STATISTICS または /CHECK (省略時の設定) のどちらかと一緒に使用する必要があります。 この修飾子は，順編成ファイル構成に対してのみ適用され，他のファイル構成では無視されます。
詳細については，『OpenVMS Record Management Utilities Reference Manual』を参照してください。
OpenVMS バージョン 7.2 では，ファイル・ユーザ特性項目 XAB$_UCHAR_PRESHELVED を RMSのXAB (XABITM) 項目リストで使用することができます。 XAB$_UCHAR_PRESHELVED 項目は，ファイルがシェルフ上にあるが，オンライン状態であることを示します。
詳細については，『OpenVMS Record Management Services Reference Manual』を参照してください。
OpenVMS バージョン 7.2には，RMS グローバル・バッファの性能を改善する 2 つの機能強化が含まれています。
前者の変更点は，非常に大きなグローバル・バッファ・カウントを使用したいと考えている人に有効です。 後者の変更点は，グローバル・セクションそのものでの競合がボトルネックになっている，グローバル・バッファを使用している任意のアプリケーションに有効です。
OpenVMS Alpha バージョン 7.2 では，ソフト・アフィニティのスケジューリング・アルゴリズムが改善されています。 ソフト・アフィニティを使うと，カーネル・スレッドを，それが最後に実行されたプロセッサ上で実行されるようにスケジュールすることができます。 これには，キャッシュと変換バッファに対して行った投資を無駄にせずに済むという効果があります。
新しいアルゴリズムは，プロセス・スケジューリング・データを収集し，使用することで，ソフト・アフィニティ・プロセスを現在の CPU 上で実行すべきかどうかを決定します。 システムは，各プロセス優先順位で次のデータを収集することで，プロセスの各 CPU での性能に関して，より詳しい情報を収集します。
ソフト・アフィニティを有効にする方法は 2 つあります。
CAP$V_IMPLICIT_ALL_THREADS フラグ。プロセス内のすべてのカーネル・スレッドについてソフト・アフィニティを有効にする。
OpenVMS Alpha バージョン 7.2 以前では，DCL コマンド SET PROCESS/AFF/SET=1 がプロセスのハード (または明示的) アフィニティを有効にしていましたが，ソフト・アフィニティを有効にする DCL コマンドはありませんでした。 OpenVMS Alpha バージョン 7.2 では，修飾子 /AFF に hard と soft という値が関連付けられています。 どちらの値も指定されなかった場合の省略時の値は，これまでと同じ hard です。
OpenVMS Alpha バージョン 7.2 では，DCL コマンド SHOW PROCESS/ALL はソフト・アフィニティ設定を表示します。このコマンドは次の新しい行を表示します。
Soft affinity: on
ソフト・アフィニティが有効になっていなければ，次の行を表示します。
Soft affinity: off.
ソフト・アフィニティには 2 つのシステム・パラメータが関連付けられています。
OpenVMS Alpha バージョン 7.2 では，AFFINITY_SKIP は廃止されています。
OpenVMS Alpha バージョン 7.2 では，AFFINITY_TIME は，プロセスが I/O バウンドまたはコンピュート・バウンドであると判断されるときのプロセスの自発的待機の期間 (秒単位) を指定します。 省略時の値は 3 秒です。
この節では，OpenVMS バージョン 7.2 におけるセキュリティの変更点について説明します。
この項では，OpenVMS Alpha バージョン 7.2 の新機能であるスレッドごとのセキュリティについて説明します。
スレッドごとのセキュリティにより，マルチスレッド・プロセスの中の各実行スレッドが，個別のセキュリティ・プロファイルを持つことができます。 OpenVMS バージョン 7.2 では，インパーソネーション・システム・サービスと下位のシステム・フレームワークが，スレッドごとのセキュリティ・プロファイルをサポートするように強化されています。
これまで，各種のプロセス・レベルのデータ構造とデータ・セルに含まれていたセキュリティ・プロファイル情報は，現在では Persona Security Block (PSB) という 1 つのデータ構造に格納され，実行スレッドにバインドされています。 OpenVMS の中のこれに関連するすべての参照が，適宜リダイレクトされています。 システム内の各プロセスは，プロセスのナチュラル・ペルソナである PSB を少なくとも 1 つ持っています。 ナチュラル・ペルソナはプロセスの作成時に作成されます。
スレッド・マネージャ (DECthreads に組み込まれているスレッド・マネージャなど) とセキュリティ・サブシステムの間の相互作用により，スレッドの実行のスケジューリングが行われる際に，自動的にプロファイルの切り替えが行われます。
OpenVMS システム上のスレッディング機能の詳細については，『Guide to DECthreads』の付録 B「Considerations for OpenVMS Systems」を参照してください。
スレッドごとのセキュリティを主に使用するのは，クライアントのインパーソネーションを行うスレッドを持っているマルチスレッド・サーバです。 これらのスレッドは，監査，アクセス・チェック，ライトの処理などの点で，システムにはクライアントのように見えます。 これは，ユーザのために要求を処理するシステム・レベルのサーバ・アプリケーションの開発者にとって便利です。 このようなアプリケーションは，DECthreads のスレッド・モデルとシステムの組み込みのインパーソネーション・サービスを使って，システムに要求側のクライアントのために自動的にセキュリティ・チェックを行わせることができます。
これまで，OpenVMS オペレーティング・システムでカーネル・スレッドをインプリメントするとき，1 つのスレッドのセキュリティ情報 (特権，ライトおよびアイデンティティ情報) を変更すると，スレッドが複数のプロセッサで同時に実行されるようにスケジューリングされていた場合 (カーネル・スレッドはまさにそのように設計されています)，その変更が誤って別のスレッドに渡されてしまう可能性がありました。
スレッドごとのセキュリティにより，このセキュリティ情報が正しく処理されることが保証されます。 プロセス内の各ユーザ・スレッドは完全に独立したセキュリティ・プロファイルを持ちます。ユーザ・スレッドがスケジューリングされると，そのスレッドのセキュリティ・プロファイルも自動的に切り替えられます。
スレッドごとのセキュリティについての詳細は，『OpenVMS Guide to System Security』を参照してください。
以前のバージョンの OpenVMS には，OpenVMS の特権プロセスがペルソナを作成し，使用するためのシステム・サービスが含まれていました。 これらのシステム・サービスには，次のものがあります。
これらのサービスの機能強化と追加機能は，OpenVMS Alpha バージョン 7.2 の新しい機能です。 これらの機能強化は，OpenVMS 以外のサブジェクト・セキュリティ証明をサポートします。 最初の時点では Windows NT スタイルのセキュリティ証明がサポートされます。
次に示す新しいシステム・サービスは，ペルソナのルックアップと取り出し，およびペルソナ・エクステンションをサポートしています。 これらのシステム・サービスは『OpenVMS System Services Reference Manual: GETQUI-Z』に記述されています。 これらのサービスについての詳細は，『OpenVMS Guide to System Security』を参照してください。
OpenVMS Alpha システム上で共用アドレス・データを使用すると，次のような場合に性能が改善されます。
次に，共用アドレス・データに関連する用語について説明します。
イメージは，複数のイメージ・セクションから構成されます。イメージ・セクションは次のものを含むことができます。
次のコマンドを使うと，イメージを共用既知イメージにすることができます。
$ INSTALL ADD image-name /SHARED
このコマンドを入力すると，インストール・ユーティリティは読み込み専用イメージ・セクションのためのグローバル・セクションを作成し，そのイメージを実行するすべてのプロセスからこれらのセクションを共用できるようにします。
ある種類のイメージ・セクションはアドレス・データを含んでいます。 アドレス・データ・セクションは実行時には読み込み専用です。 ただし，アドレスはイメージが起動されるまでは未定です。 このため，イメージ・セクションはイメージの起動が終わるまでは読み書き可能です。 共用可能イメージのアドレスは，一般にプロセスごとに異なります。 これは，個々のプロセスが，それぞれマップド・イメージの異なるコレクションを持つ可能性が高いからです。
共用アドレス・データ機能は，P1 イメージ領域から共用可能イメージの一意の P1 スペース・アドレスを割り当てます (IMGREG_PAGES システム・パラメータは P1 スペースのサイズを決定します)。 この割り当てられたアドレスをもとに，インストール・ユーティリティはイメージのインストール時にアドレス・データ・セクションの内容を決定します。 個々のアドレス・データ・イメージ・セクションへの共用アクセスを可能にするために，グローバル・セクションが作成されます。
実行可能 (メイン) イメージも共用アドレス・データ・セクションを使用することができます。 ただし，実行可能イメージのベース・アドレスはイメージのリンク時に決定されるので，これらのイメージには P1 アドレスは割り当てられません。
共用アドレス・データを持つイメージをインストールするには，INSTALL/SHARED コマンドで新しいキーワード SHARED_DATA を使用します。
$ INSTALL CREATE/SHARED=ADDRESS_DATA imagename
共用アドレス・データを持つイメージ (仮にイメージ A と呼びます) をインストールするとき，イメージ B がイメージ A から呼び出される場合には，イメージ B も共用アドレス・データ付きでインストールされなくてはならないことに注意してください。 この規則から導き出されることとして，次の 2 つがあります。
OpenVMS Alpha システムでは，次のコマンドで [NO]ADDRESS_DATA キーワードを使用することができます。
いずれかのコマンドで ADDRESS_DATA キーワードを使用すると，共用可能イメージに P1 スペース・アドレスが割り当てられます。 この割り当てられたアドレスをもとに，インストール・ユーティリティはイメージの起動時ではなくインストール時にアドレス・データ・セクションの内容を決定することができるので，CPU と I/O の時間が短縮されます。 アドレス・データ・イメージ・セクションへの共用アクセスを可能にするために，グローバル・セクションが作成されます。
次に例を示します。
INSTALL> CREATE/SHARED=ADDRESS_DATA WRKD$:[MAIN]INFOSHR
この例のコマンドは，INFOSHR ファイルを共用既知イメージとしてインストールし，コード・セクションと読み込み専用データ・セクションのための共用グローバル・セクションを作成します。 このコマンドには ADDRESS_DATA キーワードが含まれているので，アドレス・データも共用グローバル・セクションとして作成されます。
この節では，OpenVMS バージョン 7.2 に含まれている新しい SDA の機能について説明します。
次に示す SDA CLUE エクステンション・コマンド，SDA エクステンション・ルーチン，および SDA コマンドは，OpenVMS Alpha バージョン 7.2 で新しく追加または変更された修飾子やパラメータです。 これらのコマンドについての詳細は，『OpenVMS Alpha System Analysis Tools Manual』を参照してください。
次の表に，CLUE CALL_FRAME エクステンション・コマンドの修飾子を示します。
| 修飾子 | 説明 |
|---|---|
| /ADDRESS=n | CLUE CALL_FRAME/PROCESS と併用する際に，対象となるプロセスの PCB アドレスを指定する。 |
| /CPU [cpu-id|ALL] | CPU のための呼び出しフレームが必要であることを示す。 CPU は番号または ALL (すべての CPU を示す場合) を使用して指定する。 |
| /IDENTIFICATION=n | CLUE CALL_FRAME/PROCESS と併用する際に，対象となるプロセスの ID を指定する。 |
| /INDEX=n | CLUE CALL_FRAME/PROCESS と併用する際に，対象となるプロセスのインデックスを指定する。 |
| /PROCESS [process-name|ALL] | プロセスのための呼び出しフレームが必要であることを示す。 プロセスは，修飾子/ADDRESS，/IDENTIFICATION，/INDEX，または名前あるいは ALL (すべてのプロセスを示す場合) で指定する。 |
CLUE ERRLOG エクステンション・コマンドに新しい修飾子 /OLD が追加されました。 /OLD 修飾子は，古いエラーログ・フォーマットを使用して，エラーログ・バッファをファイルにダンプします。 省略時の動作では，/OLD が指定されていない場合，エラーログ・バッファは共通イベント・ヘッダ・フォーマットでダンプされます。
CLUE FRU エクステンション・コマンドは，DECevent で表示するために，Field Replacement Unit (FRU) テーブルをファイルに出力します。
Alpha SDA の新しい CLUE REGISTER コマンドは，クラッシュ CPU のアクティブ・レジスタを表示します。 CLUE REGISTER コマンドはクラッシュ・ダンプの分析をしているときにのみ有効です。
CLUE SG エクステンション・コマンドは，分散/集中 (scatter-gather) マップを表示します。 /CRAB 修飾子は，指定された Counted Resource Allocation Block (CRAB) のリングバッファを表示します。 省略時の動作では，すべての CRAB のリングバッファが表示されます。
Alpha SDA の新しい CLUE SYSTEM/LOGICAL コマンドは，システム内の共用論理名テーブルの内容を表示します。
SDA$GET_CURRENT_CPU エクステンション・ルーチンは，現在選択されている CPU の CPU データベース・アドレスを取得します。
SDA$SET_CPU エクステンション・ルーチンは，新しい SDA CPU コンテキストを設定します。
SDA$SET_PROCESS エクステンション・ルーチンは，新しい SDA プロセス・コンテキストを設定します。
フル・ダンプのメモリ・マップを表示します。
Alpha SDA の SHOW EXECUTIVE コマンドに，execlet-name というパラメータが新しく追加されています。 execlet-name が指定されていると，SDA は指定された execlet のデータだけを表示します。 execlet-name ではワイルドカードが使用でき，この場合 SDA はマッチしたすべての execlet のデータを表示します。
execlet-name パラメータの利点は，目的の情報を得るために必要な出力の量を減らせるということです。
Alpha SDA の SHOW EXECUTIVE コマンドには新しい修飾子が追加されています。 /SUMMARY 修飾子は，個々のロード可能イメージについて 1 行の出力を表示します。
SHOW GSD コマンドには，次に示す新しい修飾子が追加されています。
| 修飾子 | 意味 |
|---|---|
| /GLXGRP | Galaxy システムのグループ・グローバル・セクション記述子の中の情報を表示する |
| /GLXSYS | Galaxy システムのシステム・グローバル・セクション記述子の中の情報を表示する |
SHOW LOCK コマンドには，次に示す新しい修飾子が追加されています。
| 修飾子 | 意味 |
|---|---|
| /BLOCKING | ブロッキング AST が指定またはアタッチされているロックだけを表示する |
| /BRIEF | 簡単な 1 行のロック情報を表示する |
| /CONVERT | 変換キューに入っているロックだけを表示する |
| /GRANTED | 許可されたキューに入っているロックだけを表示する |
| /POOL | ロック・ブロック (LKB) とリソース・ブロック (RSB) を含んでいるロック・マネージャ・プールゾーンの情報を表示する |
| /STATUS=(keyword[,keyword...]) | LKB$L_STATUS フィールドに指定された状態ビットがセットされているロックだけを表示する。 この修飾子のキーワードとその意味についての詳細は，『OpenVMS Alpha System Analysis Tools Manual』を参照。 |
| /SUMMARY | 集計データと性能カウンタを表示する |
| /WAITING | 待機中のロックだけを表示する |
Alpha SDA の SHOW PAGE_TABLE コマンドには，次の新しい修飾子が追加されています。
| 修飾子 | 意味 |
|---|---|
| /INVALID_PFN [=option] | この修飾子は，I/O メモリ・マップを提供するプラットフォーム上で有効であり，システムのプライベート・メモリにも Galaxy 共用メモリにもなく，I/O アクセス・ページでもない PFN にマップしているページ・テーブル・エントリのみ SDA が表示するようにする。 |
| /NONMEMORY_PFN [=option] | この修飾子は，すべてのプラットフォーム上でサポートされており， システムのプライベート・メモリにも Galaxy 共用メモリにもないページ・テーブル・エントリのみ SDA が表示するようにする。 |
| /PTE_ADDRESS | 指定された範囲が，PTE によってマップされた仮想アドレスではなく，PTE アドレスであることを示す。 |
| /SECTION_INDEX=n | グローバル・セクションまたはロードされたイメージのページング可能な部分の中のページ範囲のためのページ・テーブルを表示する。 |
Alpha SDA の SHOW PAGE_TABLE /FREE コマンドには新しい修飾子が追加されています。 /HEADER=address 修飾子を指定すると，SDA は指定されたプライベート・ページ・テーブルのフリー・リストを表示します。
Alpha SDA の新しいコマンド SHOW PARAMETER は，システム・ダンプを取るときに，SYSGEN パラメータの名前，位置，および値を表示します。
SHOW PARAMETER コマンドには，次のようにパラメータがあります。
| パラメータ | 意味 |
|---|---|
| SYSGEN_parameter | 表示されるパラメータの値。指定する名前にワイルドカードを使用できる。 ただし，同等の SYSGEN コマンドや SYSMAN コマンドと異なり，短縮名は認識されない。 |
SHOW PARAMETER には，次のような修飾子があります。
| 修飾子 | 意味 |
|---|---|
| /ACP | すべての Files-11 パラメータを表示する。 |
| /ALL | すべてのパラメータの値を表示するが，特殊制御パラメータは除く。 |
| /CLUSTER | クラスタに固有なすべてのパラメータを表示する。 |
| /DYNAMIC | 実行中のシステム上で変更することができるすべてのパラメータを表示する。 |
| /GALAXY | Galaxy システムに固有なすべてのパラメータを表示する。 |
| /GEN | すべての汎用パラメータを表示する。 |
| /JOB | すべての Job Controller パラメータを表示する。 |
| /LGI | すべての LOGIN セキュリティ制御パラメータを表示する。 |
| /MAJOR | 最も重要なパラメータを表示する。 |
| /MULTIPROCESSING | マルチプロセッシングに固有なパラメータを表示する。 |
| /PQL | すべての省略時のプロセス・クォータ用のパラメータを表示する。 |
| /RMS | OpenVMS Record Management Services (RMS) に固有なすべてのパラメータを表示する。 |
| /SCS | OpenVMS Cluster System Communications Services に固有なすべてのパラメータを表示する。 |
| /SPECIAL | すべての特殊制御パラメータを表示する。 |
| /STARTUP | サイトに依存しないスタートアップ・プロシージャの名前を表示する。 |
| /SYS | すべてのアクティブなシステム・パラメータを表示する。 |
| /TTY | 端末ドライバ用のすべてのパラメータを表示する。 |
Alpha SDA の SHOW PFN_DATA コマンドには，/PRIVATE [=address] と /UNTESTED の 2 つの新しい修飾子が追加されています。 /PRIVATE [=address] 修飾子を指定すると，SDA はプライベート PFN リストを表示します。 アドレスが指定されないと，すべてのプライベート PFN リストが表示されます。 アドレスが指定されると，先頭が指定されたアドレスにある PFN リストだけが表示されます。 /UNTESTED 修飾子を指定すると，SDA はデファード・メモリ・テストのためにセットアップされた未テストの PFN リストの状態を表示します。
Alpha SDA の SHOW PROCESS コマンドには，次に示す新しい修飾子が追加されています。
| 修飾子 | 意味 |
|---|---|
| /BRIEF | この修飾子は，/LOCKS 修飾子と併用された場合，SDA が，現在のプロセスによって所有されている各ロックを簡略なフォーマット (各ロックを 1 行) で表示するようにする。 |
| /CHANNEL [=PID_ONLY] | プロセスに割り当てられている I/O チャネルに関する情報を表示する。 キーワード FID_ONLY が指定されている場合，ANALYZE/SYSTEM で起動されたとき，SDA は FID (File ID) をファイル名に変換しようとしない。 |
| /FANDLE | プロセスのファースト I/O ハンドルのデータを表示する。 |
| /INVALID_PFN [=option] | この修飾子は，I/O メモリ・マップを提供するプラットフォームで有効であり，システムのプライベート・メモリにも Galaxy 共用メモリにもなく，I/O アクセス・ページでもない PFN にマップするページ・テーブル・エントリだけを SDA が表示するようにする。 |
| /LOCKS [/BRIEF] | 現在のプロセスで所有されているロック管理ロックを表示する。
/LOCKS [/BRIEF] 修飾子を使用すると，SHOW LOCK コマンドで生成されるフォーマットと同様のフォーマットで表示が行われる。 /BRIEF 修飾子の説明も参照。 |
| /NONMEMORY_PFN [=option] | この修飾子は，すべてのプラットフォームでサポートされているが，システムのプレイベート・メモリにも Galaxy 共用メモリにもないページ・テーブル・エントリだけを SDA が表示するようにする。 |
| /PERSONA [=address] | プロセスの PERSONA ARRAY に保持されているすべてのペルソナ・セキュリティ・ブロック (PSB) を表示し，さらに個々の PSB に含まれている主な情報を表示する。
表示される情報には，PSB の中の次のセルの内容が含まれる。
フラグ 参照カウント 実行モード 監査状態 アカウント名 UIC 特権 ライト・イネーブルド・マスク PSB アドレスが指定された場合，上記の情報はそのPSBだけについて表示される。 |
| /PERSONAL/RIGHTS | すべての /PERSONA [=address] 情報と，主な情報を表示する。 これには，個々のペルソナ・セキュリティ・ブロック (PSB) について，現在保持されており，アクティブな状態になっているすべてのライトとその属性が含まれる。 |
| /PERSONA/RIGHTS/AUTHORIZED | すべての /PERSONA [=address] 情報と，主な情報を表示する。 これには，個々のペルソナ・セキュリティ・ブロック (PSB) について登録されているすべてのライトとその属性が含まれる。 |
SHOW PROCESS/PAGE_TABLES コマンドには，次に示す新しい修飾子が追加されています。
| 修飾子 | 意味 |
|---|---|
| /PTE_ADDRESS | PTE によってマップされた仮想アドレスの代わりに PTE アドレスを指定する。 |
| /SECTION_INDEX=n |
グローバル・セクションあるいはロードされたイメージのページング可能な部分の，また /PAGE_TABLE 修飾子が同時に指定されている場合には指定されたプロセス・セクションのページ範囲のためのページ・テーブルを表示する。
グローバル・ページ・テーブル・エントリ (GPTE) が表示されるグローバル・セクションの場合を除き，/L1，/L2 または /L3 のいずれかの修飾子を同時に指定することができる。
/PROCESS_SECTION_TABLE 修飾子と同時に指定された場合には，指定された 1 つのプロセス・セクションの PST を表示する。 /PAGE_TABLE と /PROCESS_SECTION_TABLE のどちらの修飾子も指定されていなければ，/SECTION_INDEX=n 修飾子は無視される。 |
| /INVALID_PFN [=option] | この修飾子は，I/O メモリ・マップを提供するプラットフォーム上で有効であり，システムのプライベート・メモリにも Galaxy 共用メモリ上にもなく，I/O アクセス・ページでもない PFN にマップするページ・テーブル・エントリだけを SDA で表示するようにする。 |
| /NONMEMORY_PFN [=option] | この修飾子は，すべてのプラットフォームでサポートされており， システムのプライベート・メモリにも Galaxy 共用メモリにもないページ・テーブル・エントリだけを SDA で表示するようにする。 |
SHOW RESOURCE コマンドには，次に示す新しい修飾子が追加されています。
| 修飾子 | 意味 |
|---|---|
| /BRIEF | 簡単な 1 行のリソース情報を表示する |
| /CONTENTION [=ALL] | 待機または変換キューに少なくとも 1 つのロックがあるリソースだけを表示する |
| /STATUS=(keyword[keyword,]) | RSB$L_STATUS フィールドに，指定された状態ビットがセットされているリソースだけを表示する。 この修飾子のキーワードとその意味については，『OpenVMS Alpha System Analysis Tools Manual』を参照。 |
Alpha SDA の SHOW STACK コマンドには，新しい修飾子 /PHYSICAL が追加されています。 /PHYSICAL 修飾子を指定すると，SDA は指定された範囲の開始および (または) 終了アドレスを物理アドレスとして扱います。 この修飾子は範囲が指定されている場合にのみ意味を持ちます。
Alpha SDA の SHOW STACK コマンドには，新しいパラメータ range が追加されています。 range パラメータは，メモリ位置の範囲をスタック形式で表示します。 range は次の構文を使って表現することができます。
| 値 | 意味 |
|---|---|
| m:n | m から n までのアドレス範囲 |
| m;n | m で始まり，n バイトの長さを持つアドレス範囲 |
Alpha SDA の SHOW SUMMARY コマンドには，新しい修飾子 /USER=username が追加されています。 /USER=username が指定されていると，SDA は指定されたユーザのプロセスだけを表示します。 /USER=username でワイルドカードを使用すると，SDA はマッチするすべてのユーザのプロセスを表示します。
/USER=username 修飾子の利点は，目的の情報を得るために必要な出力の量を減らせるということです。
Alpha SDAのSHOW SYMBOL /ALL コマンドには，2 つの新しい修飾子が追加されています。 /ALPHA 修飾子を指定すると，SDA はシンボルをアルファベット順だけでソートして表示します。 /VALUE 修飾子を指定すると，SDA はシンボルを値の順序だけでソートして表示します。 省略時の設定では，シンボルをまずアルファベット順でソートして表示した後に，値の順序で表示します。
Alpha SDAのSHOW SYMBOL コマンドを /ALL 修飾子なしで指定した場合，symbol-name パラメータで標準ワイルドカードを使用できるようになりました。 省略時の設定では，マッチするシンボルがアルファベット順でのみ表示されます。 SHOW SYMBOL /VALUE が指定されていれば，マッチするシンボルが値の順でソートされて出力されます。 /ALPHA と /VALUE の両方が指定されていると，マッチするシンボルはまずアルファベット順で，次に値の順でソートされて2度表示されます。
この新しい機能の利点は，SHOW SYMBOL コマンドで，名前の一部しかわかっていないシンボルを調べたいときの柔軟性が増したという点にあります。
Alpha SDA の VALIDATE PFN_LIST コマンドには，/PRIVATE と /UNTESTED の 2 つの新しい修飾子が追加されています。 /PRIVATE 修飾子を指定すると，SDA はすべてのプライベート PFN リストを確認します。 /UNTESTED 修飾子を指定すると，SDA はデファード・メモリ・テストのためにセットアップされた未テストの PFN リストの状態を確認します。
Alpha SDA の VALIDATE QUEUE コマンドには，/PHYSICAL と /BACKLINK の 2 つの新しい修飾子が追加されています。 /PHYSICAL 修飾子を指定すると，ヘッダとリンクが物理アドレスであるキューを確認することができます。 /BACKLINK 修飾子を指定すると，二重リンク・リストをキューの末尾から確認することができます。
/BACKLINK 修飾子の利点は，キューの先頭から確認を行ったときに，キューが壊れていることがわかった場合，この修飾子を使うと壊れているエントリのリストを狭めることができるという点にあります。
OpenVMS Alpha バージョン 7.2 では，システム・ダンプ・ファイルをシステム・ディスク以外のデバイスに書き込むことができます。 この機能強化により，ダンプ・オフ・システム・ディスク (DOSD) が使用されている場合でも，CLUE HISTORY 情報を収集できるようになりました。 SDA CLUE が分析対象のダンプ・ファイルを見つけ出せるように，次の操作を行う必要があります。
次の例では，ダンプ・ファイルは DMP$DEV というラベルが付けられたデバイス $3$DUA25 に置かれています。 SYS$MANAGER:SYLOGICALS.COM に次のコマンドを追加する必要があります。
$ MOUNT/SYSTEM/NOASSIST $3$DUA25: DMP$DEV DMP$DEV
$ DEFINE/SYSTEM CLUE$DOSD_DEVICE DMP$DEV
OpenVMS Alpha バージョン 7.2 には，システム・ダンプを解釈する新たな System Dump Analyzer (SDA) コマンドを作成するためのエクステンション・ルーチンが付属しています。 開発者は，ドキュメント化され，サポートされているインタフェースを使って，ビジネス・ニーズに合わせたカスタム SDA エクステンションを作成することができます。 SDA エクステンション・ルーチン，およびエクステンションの作成とデバッグの方法についての詳細は，『OpenVMS Alpha System Analysis Tools Manual』を参照してください。
OpenVMS バージョン 7.2 では，いくつかの新しいシステム・サービスが追加され，いくつかの既存のサービスが変更されています。 この節では，新しいサービスと変更されたサービスについて説明します。
新しいシステム・サービス $GETENV は，指定されたコンソール環境変数の値 (1 つ以上) を返します。
ローカルおよびクラスタ単位のプロセス間通信のためのアプリケーション・プログラミング・インタフェース (API) であるクラスタ内通信をサポートするために，新しいサービスが作成されています。
これらのサービスおよびそのアプリケーションについての詳細は，本書の第 4.11 節を参照してください。
この項では，クラスタ単位の論理名をサポートするために変更されたサービスについて説明します。 次の表に，変更点の詳細を示します。
| システム・サービス | 新しい機能 |
|---|---|
| $CRELNM | クラスタ単位の論理名のサポートが追加された。
|
| $CRELNT | クラスタ単位の論理名のサポートが追加された。
|
| $DELLNM | クラスタ単位の論理名のサポートが追加された。
|
| $GETSYI | クラスタ単位の論理名のサポートが追加された。
|
| $TRNLNM | クラスタ単位の論理名のサポートが追加された。
|
これらのサービスの詳細については，『OpenVMS System Services Reference Manual』を参照してください。
この項では，Extended File Specifications をサポートするために変更されたサービスについて説明します。 次の表にこれらの変更点の詳細を示します。
| システム・サービス | 新しい機能 |
|---|---|
| $CREPRC | Extended File Specifications のサポートが追加された。
|
| $CVT_FILENAME | Extended File Specifications のサポートが追加された。
|
| $GETJPI | Extended File Specifications のサポートが追加された。
|
| $SETDDIR | Extended File Specifications のサポートが追加された。
|
| $SET_PROCESS_PROPERTIESW | Extended File Specifications のサポートが追加された。
|
これらのサービスの詳細については，『OpenVMS System Services Reference Manual』を参照してください。
Fast Path をサポートするための 2 つの新しいサービス $IO_FASTPATH および $IO_FASTPATHW が作成されました。
Fast Path についての詳細は，『OpenVMS System Services Reference Manual: GETQUI-Z』，『OpenVMS I/O User's Reference Manual』，および本書の表 2-1 を参照してください。
以前のバージョンの OpenVMS には，特権 OpenVMS プロセスがペルソナを作成し，使用できるようにするためのシステム・サービスが含まれていました。 OpenVMS バージョン 7.2 以降，ペルソナのルックアップおよび取り出しと，ペルソナ・エクステンションをサポートするためのいくつかの新しいシステム・サービスが追加されています。
これらのサービスとその使用方法の詳細については，このマニュアルの第 4.18.2 項と『OpenVMS System Services Reference Manual』を参照してください。
[ 前のページ ]
[ 次のページ ]
[ 目次 ]
[ 索引 ]
[ DOC Home ]