第 5 章共用環境の準備
どの OpenVMS Cluster 環境でも，リソースはできるだけ共用することが最適です。リソースを共用すると，作業をクラスタ全体で分散できるため，簡単に作業負荷のバランスをとることができます。 5.1 共用可能なリソース 全部ではありませんが，大部分のリソースは OpenVMS Cluster のノード間で共用できます。以下の表は共用できるリソースを示しています。
全部ではありませんが，大部分のリソースは OpenVMS Cluster のノード間で共用できます。以下の表は共用できるリソースを示しています。
5.1.1 ローカル・リソース以下の表は，ローカル・ノードだけからアクセスできるリソースを示しています。 共用できないリソース 説明 メモリ OpenVMS Cluster の各メンバは独自のメモリを管理しなければならない。 ユーザ・プロセス OpenVMS Cluster のメンバでユーザ・プロセスが生成される場合，プロセスはローカル・メモリを使用して，そのコンピュータで完了しなければならない。 プリンタ キューを通じて入力を受け付けないプリンタは，そのプリンタが直接接続されている OpenVMS Cluster メンバからだけ使用される。キューを通じて入力を受け付けるプリンタは，OpenVMS Cluster のどのメンバからもアクセス可能である。 5.1.2 構成例 図 5-1 に示すのは，Integrity サーバと Alpha システムで FC SAN ストレージを共有する OpenVMS Cluster システムです。それぞれのアーキテクチャで自身のシステム・ディスクを持っています。 図 5-1 アーキテクチャ混成クラスタでのリソースの共用 (Integrity および Alpha) 5.1.3 アーキテクチャ混成クラスタにおけるストレージ ここでは， OpenVMS Integrity サーバおよび OpenVMS Alpha システムで構成されるアーキテクチャ混成クラスタにおけるシステム・ディスクも含めたストレージに関する規則について説明します。 図 5-2 に示すのは，ローカルに接続されたストレージと共有 Storage Area Network (SAN) を持つ OpenVMS Integrity および OpenVMS Alpha システムのアーキテクチャ混成クラスタを単純化した図です。 図 5-2 アーキテクチャ混成クラスタにおけるリソースの共有 (Integrity および Alpha) アーキテクチャ混成 OpenVMS Cluster システムにおける Integrity サーバ・システムの特性は以下のとおりです。 ローカル・ディスクあるいは共有 Fibre Channel ディスクに OpenVMS Integrity のシステム・ディスクが必要です。 サービスされている Alpha ディスクと Alpha テープを使用できます。 SAN ディスクおよびテープを使用できます。 同じ SAN データ・ディスクを Alpha システムと共有することができます。 ディスクとテープを他の Integrity サーバおよび Alpha システムのどちらのクラスタ・メンバに対しても提供することができます。 アーキテクチャ混成 OpenVMS Cluster システムにおける Alpha システムの特性は以下のとおりです。 他の Alpha クラスタ・メンバと共有可能な OpenVMS Alpha のシステム・ディスクが必要です。 ローカルに接続されたディスクとテープを使用できます。 ディスクとテープを他の Integrity サーバおよび Alpha システムに対して提供することができます。 Integrity サーバがサービスするデータ・ディスクを使用できます。 SAN ディスクおよびテープを使用できます。 同じ SAN データ・ディスクを Integrity サーバと共有することができます。 5.2 共通環境クラスタと多重環境クラスタ 処理のニーズに応じて，すべての環境ファイルがクラスタ単位で共用される環境，または一部のファイルはクラスタ単位で共用され，他のファイルは特定のコンピュータからだけアクセス可能な環境のいずれかを準備できます。 以下の表は，共通環境クラスタと多重環境クラスタの特徴を示しています。 クラスタの種類 特徴 利点 共通環境 オペレーティング環境は OpenVMS Cluster 内のすべてのノードで同一である。 環境は以下のように設定される。 すべてのノードが同じプログラム，アプリケーション，ユーティリティを実行する。 すべてのユーザが同じ種類のユーザ・アカウントを持ち，同じ論理名が定義される。 すべてのユーザがストレージ・デバイスおよびキューに対して共通のアクセス権を持つことができる (アクセス権は，アクセス制御リスト [ACL] 保護が各ユーザに対してどのように設定されているかに応じて異なる)。 すべてのユーザが構成内のどのノードにもログインでき，他のすべてのユーザと同じ環境で作業する。 共通バージョンのシステム・ファイルを使用するため，管理が簡単である。 多重環境 オペレーティング環境はノードごとに変更できる。 個々のプロセッサまたは一部のプロセッサが以下のように設定される。 ユーザが実行するタスクの種類と使用するリソースに応じて，複数のアクセス権が提供される。 他のノードでは使用できないリソースを共用できる。 他のプロセッサが一般的なタイムシェアリング作業を実行している間，制限されたリソースを使用して専門化された機能を実行する。 ユーザはログインしているノード固有の環境で作業することができる。 一部のデータだけをコンピュータ間で共用し，しかも特定のコンピュータが特別なニーズに対応できるように設定したい場合に効果的である。 5.3 共通システム・ディスクのディレクトリ構造オペレーティング・システムのインストールまたはアップグレード・プロシージャで， 共通システム・ディスク が作成されます。ほとんどのオペレーティング・システム・ファイルとオプションの製品ファイルは，このシステム・ディスクの共通のルート・ディレクトリに格納されます。 5.3.1 ディレクトリ・ルート システム・ディスクのディレクトリ構造は，Integrity サーバ・システムと Alpha システムで同一です。システム・ディスクが Alpha 用の場合も VAX 用の場合も，ディレクトリ構造全体，つまり， 共通ルートと各コンピュータの ローカル・ルートは同じディスクに格納されます。インストールまたはアップグレードが完了した後， 第 8 章 で説明する CLUSTER_CONFIG.COM あるいは CLUSTER_CONFIG_LAN.COM コマンド・プロシージャを使用して，クラスタにブートするときに使用されるローカル・ルートを新しい各コンピュータに対して作成します。 通常のシステム・ディレクトリの他に，各ローカル・ルートには [VMS$COMMON] のディレクトリ・エイリアスである [SYSn.SYSCOMMON] ディレクトリが格納されます。これは，クラスタ共通ファイルが実際に格納されるクラスタ共通ルート・ディレクトリです。コンピュータをクラスタに追加する際，コマンド・プロシージャは共通ルート・ディレクトリ・エイリアスを定義します。 5.3.2 ディレクトリ構造の例 図 5-3 は，JUPITR と SATURN というコンピュータのディレクトリ構造を示しています。この 2 台のコンピュータは共通システム・ディスクから実行されます。ディスクのマスタ・ファイル・ディレクトリ (MFD) には，ローカル・ルート (JUPITR の場合は SYS0，SATURN の場合は SYS1) と，クラスタ共通ルート・ディレクトリ [VMS$COMMON] が格納されています。 図 5-3 共通システム・ディスクのディレクトリ構造 5.3.3 検索順序 論理名 SYS$SYSROOT は，最初はローカル・ルート (SYS$SYSDEVICE:[SYS0.SYSEXE]) を指し，次に共通ルート (SYS$COMMON:[SYSEXE]) を指す検索リストとして定義されています。したがって，システム・ディレクトリの論理名 (SYS$SYSTEM， SYS$LIBRARY，SYS$MANAGER など) は，2 つのディレクトリを指します。 図 5-4 は，論理名 SYS$SYSTEM がファイル指定で使用されているときに，共通システム・ディスクのディレクトリがどのように検索されるかを示しています。 図 5-4 共通システム・ディスクでのファイルの検索順序 重要: 共通システム・ディスクのシステム・ファイルを操作する場合は，この検索順序を念頭に置いておかなければなりません。コンピュータ固有のファイルは，常に該当するコンピュータのシステム・サブディレクトリに格納し，更新しなければなりません。 例 MODPARAMS.DAT は SYS$SPECIFIC:[SYSEXE] に格納しておかなければなりません。これは， JUPITR では [SYS0.SYSEXE] であり，SATURN では [SYS1.SYSEXE] です。したがって，JUPITR にログインするときに，JUPITR の新しい MODPARAMS.DAT ファイルを作成するには，以下のコマンドを入力します。 $ EDIT SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT ファイルが作成された後，JUPITR にログオンするときに，以下のコマンドを使用してファイルを変更することができます。 $ EDIT SYS$SYSTEM:MODPARAMS.DAT このコマンドを入力したときに，MODPARAMS.DAT ファイルが JUPITR の SYS$SPECIFIC:[SYSEXE] ディレクトリに存在せず， SYS$COMMON:[SYSEXE] ディレクトリに MODPARAMS.DAT ファイルがある場合，このコマンドは共通ディレクトリの MODPARAMS.DAT ファイルを編集します。 MODPARAMS.DAT ファイルがいずれのディレクトリにもない場合は，このコマンドは JUPITR の SYS$SPECIFIC:[SYSEXE] ディレクトリにファイルを作成します。 同じ共通システム・ディスクからブートされる他のコンピュータにログインするときに，JUPITR の MODPARAMS.DAT を変更するには，以下のコマンドを入力します。 $ EDIT SYS$SYSDEVICE:[SYS0.SYSEXE]MODPARAMS.DAT 1 つのクラスタ共通システム・ディスクを使用するクラスタ内で，クラスタ共通システム登録ファイルのレコードを変更するには，任意のコンピュータから以下のコマンドを入力します。 $ SET DEFAULT SYS$COMMON:[SYSEXE] $ RUN SYS$SYSTEM:AUTHORIZE 同じクラスタ共通システム・ディスクからブートされる別のコンピュータにログインするときに，コンピュータ固有のシステム登録ファイルのレコードを変更するには，デフォルト・ディレクトリを特定のコンピュータに設定しなければなりません。たとえば，JUPITR コンピュータのコンピュータ固有のシステム登録ファイル (SYSUAF.DAT) を設定している場合，以下に示すように，AUTHORIZE を起動する前に，デフォルト・ディレクトリを JUPITR コンピュータの固有の [SYSEXE] ディレクトリに設定する必要があります。 $ SET DEFAULT SYS$SYSDEVICE:[SYS0.SYSEXE] $ RUN SYS$SYSTEM:AUTHORIZE 5.4 クラスタワイド論理名 OpenVMS バージョン 7.2 でサポートされたクラスタワイド論理名により，共用可能な論理名の便利さと使いやすさが OpenVMS Cluster システムでも利用可能です。クラスタワイド論理名は OpenVMS Integrity と OpenVMS Alpha の単一アーキテクチャ・クラスタでも，あるいはアーキテクチャ混成クラスタのどちらでも利用可能です。 既存のアプリケーションは，アプリケーション・コードを変更せずに，クラスタワイド論理名を利用できます。ただし，アプリケーションから (直接的または間接的に) 参照される論理名テーブルを少しだけ変更しなければなりません。 デフォルト設定では，新しい論理名はローカルでのみ有効です。クラスタワイド論理名は，ある論理名テーブルの属性です。新しい論理名をクラスタ単位で有効になるように設定するには，クラスタワイド論理名テーブルにその論理名を作成しなければなりません。 クラスタワイド論理名の最も重要な機能は以下のとおりです。 新しいノードがクラスタに参加する場合，現在設定されているクラスタワイド論理名全部を自動的に受け取ります。 クラスタワイド論理名または論理名テーブルが作成，変更，削除されると，その変更は OpenVMS バージョン 7.2 以降が稼動するクラスタ内の他のすべてのノードに自動的に伝達されます。クラスタ単位のテーブルに対するセキュリティ・プロファイルの変更も，この方法で自動的に伝達されます。 クラスタ単位の名前の変換によってパフォーマンスができるだけ低下しないように，変換はローカルに行われます。 LNM$CLUSTER_TABLE と LNM$SYSCLUSTER_TABLE は， OpenVMS バージョン 7.2 以降が稼動するすべてのシステムに存在するため，クラスタワイド論理名を使用するプログラムとコマンド・プロシージャは，クラスタに接続されていないシステムでも開発，テスト，実行することができます。 5.4.1 デフォルトのクラスタワイド論理名テーブル クラスタワイド論理名をサポートするために，オペレーティング・システムは， 表 5-1 に示すように，システム・スタートアップ時に 2 つのクラスタワイド論理名テーブルとそれぞれの論理名を作成します。これらの論理名テーブルと論理名は，プロセス論理名テーブル，ジョブ論理名テーブル，グループ論理名テーブル，システム論理名テーブルに加えて提供されるものです。クラスタワイド論理名テーブルの名前はシステム論理名ディレクトリ LNM$SYSTEM_DIRECTORY に格納されます。 表 5-1 デフォルトのクラスタワイド論理名テーブルと論理名 名前 目的 LNM$SYSCLUSTER_TABLE クラスタワイド・システム論理名のデフォルト・テーブル。出荷時には何も登録されていない。このテーブルは，クラスタワイド論理名を使用して環境をカスタマイズするシステム管理者を対象に提供される。このテーブルに登録されている名前は，誰でも使用することができ，SHOW LOGICAL/SYSTEM に， LNM$SYSTEM のテーブル名，LNM$DCL_LOGICAL (DCL のデフォルト・テーブル検索リスト)，LNM$FILE_DEV (システムと RMS のデフォルト) のいずれかを指定して，論理名を変換することができる。 LNM$SYSCLUSTER LNM$SYSCLUSTER_TABLE の論理名。 LNM$SYSCLUSTER_TABLE を参照するときに便利なように提供される。形式は，LNM$SYSTEM_TABLE およびその論理名である LNM$SYSTEM と同じである。 LNM$CLUSTER_TABLE LNM$SYSCLUSTER_TABLE も含めて，すべてのクラスタワイド論理名テーブルの親テーブル。親テーブルとして LNM$CLUSTER_TABLE を使用して新規テーブルを作成すると，そのテーブルはクラスタ単位で使用可能になる。 LNM$CLUSTER LNM$CLUSTER_TABLE の論理名。LNM$CLUSTER_TABLE を参照するときに便利なように提供される。 目次 索引
5.1.2 構成例 図 5-1 に示すのは，Integrity サーバと Alpha システムで FC SAN ストレージを共有する OpenVMS Cluster システムです。それぞれのアーキテクチャで自身のシステム・ディスクを持っています。 図 5-1 アーキテクチャ混成クラスタでのリソースの共用 (Integrity および Alpha) 5.1.3 アーキテクチャ混成クラスタにおけるストレージ ここでは， OpenVMS Integrity サーバおよび OpenVMS Alpha システムで構成されるアーキテクチャ混成クラスタにおけるシステム・ディスクも含めたストレージに関する規則について説明します。 図 5-2 に示すのは，ローカルに接続されたストレージと共有 Storage Area Network (SAN) を持つ OpenVMS Integrity および OpenVMS Alpha システムのアーキテクチャ混成クラスタを単純化した図です。 図 5-2 アーキテクチャ混成クラスタにおけるリソースの共有 (Integrity および Alpha) アーキテクチャ混成 OpenVMS Cluster システムにおける Integrity サーバ・システムの特性は以下のとおりです。 ローカル・ディスクあるいは共有 Fibre Channel ディスクに OpenVMS Integrity のシステム・ディスクが必要です。 サービスされている Alpha ディスクと Alpha テープを使用できます。 SAN ディスクおよびテープを使用できます。 同じ SAN データ・ディスクを Alpha システムと共有することができます。 ディスクとテープを他の Integrity サーバおよび Alpha システムのどちらのクラスタ・メンバに対しても提供することができます。 アーキテクチャ混成 OpenVMS Cluster システムにおける Alpha システムの特性は以下のとおりです。 他の Alpha クラスタ・メンバと共有可能な OpenVMS Alpha のシステム・ディスクが必要です。 ローカルに接続されたディスクとテープを使用できます。 ディスクとテープを他の Integrity サーバおよび Alpha システムに対して提供することができます。 Integrity サーバがサービスするデータ・ディスクを使用できます。 SAN ディスクおよびテープを使用できます。 同じ SAN データ・ディスクを Integrity サーバと共有することができます。 5.2 共通環境クラスタと多重環境クラスタ 処理のニーズに応じて，すべての環境ファイルがクラスタ単位で共用される環境，または一部のファイルはクラスタ単位で共用され，他のファイルは特定のコンピュータからだけアクセス可能な環境のいずれかを準備できます。 以下の表は，共通環境クラスタと多重環境クラスタの特徴を示しています。 クラスタの種類 特徴 利点 共通環境 オペレーティング環境は OpenVMS Cluster 内のすべてのノードで同一である。 環境は以下のように設定される。 すべてのノードが同じプログラム，アプリケーション，ユーティリティを実行する。 すべてのユーザが同じ種類のユーザ・アカウントを持ち，同じ論理名が定義される。 すべてのユーザがストレージ・デバイスおよびキューに対して共通のアクセス権を持つことができる (アクセス権は，アクセス制御リスト [ACL] 保護が各ユーザに対してどのように設定されているかに応じて異なる)。 すべてのユーザが構成内のどのノードにもログインでき，他のすべてのユーザと同じ環境で作業する。 共通バージョンのシステム・ファイルを使用するため，管理が簡単である。 多重環境 オペレーティング環境はノードごとに変更できる。 個々のプロセッサまたは一部のプロセッサが以下のように設定される。 ユーザが実行するタスクの種類と使用するリソースに応じて，複数のアクセス権が提供される。 他のノードでは使用できないリソースを共用できる。 他のプロセッサが一般的なタイムシェアリング作業を実行している間，制限されたリソースを使用して専門化された機能を実行する。 ユーザはログインしているノード固有の環境で作業することができる。 一部のデータだけをコンピュータ間で共用し，しかも特定のコンピュータが特別なニーズに対応できるように設定したい場合に効果的である。 5.3 共通システム・ディスクのディレクトリ構造オペレーティング・システムのインストールまたはアップグレード・プロシージャで， 共通システム・ディスク が作成されます。ほとんどのオペレーティング・システム・ファイルとオプションの製品ファイルは，このシステム・ディスクの共通のルート・ディレクトリに格納されます。 5.3.1 ディレクトリ・ルート システム・ディスクのディレクトリ構造は，Integrity サーバ・システムと Alpha システムで同一です。システム・ディスクが Alpha 用の場合も VAX 用の場合も，ディレクトリ構造全体，つまり， 共通ルートと各コンピュータの ローカル・ルートは同じディスクに格納されます。インストールまたはアップグレードが完了した後， 第 8 章 で説明する CLUSTER_CONFIG.COM あるいは CLUSTER_CONFIG_LAN.COM コマンド・プロシージャを使用して，クラスタにブートするときに使用されるローカル・ルートを新しい各コンピュータに対して作成します。 通常のシステム・ディレクトリの他に，各ローカル・ルートには [VMS$COMMON] のディレクトリ・エイリアスである [SYSn.SYSCOMMON] ディレクトリが格納されます。これは，クラスタ共通ファイルが実際に格納されるクラスタ共通ルート・ディレクトリです。コンピュータをクラスタに追加する際，コマンド・プロシージャは共通ルート・ディレクトリ・エイリアスを定義します。 5.3.2 ディレクトリ構造の例 図 5-3 は，JUPITR と SATURN というコンピュータのディレクトリ構造を示しています。この 2 台のコンピュータは共通システム・ディスクから実行されます。ディスクのマスタ・ファイル・ディレクトリ (MFD) には，ローカル・ルート (JUPITR の場合は SYS0，SATURN の場合は SYS1) と，クラスタ共通ルート・ディレクトリ [VMS$COMMON] が格納されています。 図 5-3 共通システム・ディスクのディレクトリ構造 5.3.3 検索順序 論理名 SYS$SYSROOT は，最初はローカル・ルート (SYS$SYSDEVICE:[SYS0.SYSEXE]) を指し，次に共通ルート (SYS$COMMON:[SYSEXE]) を指す検索リストとして定義されています。したがって，システム・ディレクトリの論理名 (SYS$SYSTEM， SYS$LIBRARY，SYS$MANAGER など) は，2 つのディレクトリを指します。 図 5-4 は，論理名 SYS$SYSTEM がファイル指定で使用されているときに，共通システム・ディスクのディレクトリがどのように検索されるかを示しています。 図 5-4 共通システム・ディスクでのファイルの検索順序 重要: 共通システム・ディスクのシステム・ファイルを操作する場合は，この検索順序を念頭に置いておかなければなりません。コンピュータ固有のファイルは，常に該当するコンピュータのシステム・サブディレクトリに格納し，更新しなければなりません。 例 MODPARAMS.DAT は SYS$SPECIFIC:[SYSEXE] に格納しておかなければなりません。これは， JUPITR では [SYS0.SYSEXE] であり，SATURN では [SYS1.SYSEXE] です。したがって，JUPITR にログインするときに，JUPITR の新しい MODPARAMS.DAT ファイルを作成するには，以下のコマンドを入力します。 $ EDIT SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT ファイルが作成された後，JUPITR にログオンするときに，以下のコマンドを使用してファイルを変更することができます。 $ EDIT SYS$SYSTEM:MODPARAMS.DAT このコマンドを入力したときに，MODPARAMS.DAT ファイルが JUPITR の SYS$SPECIFIC:[SYSEXE] ディレクトリに存在せず， SYS$COMMON:[SYSEXE] ディレクトリに MODPARAMS.DAT ファイルがある場合，このコマンドは共通ディレクトリの MODPARAMS.DAT ファイルを編集します。 MODPARAMS.DAT ファイルがいずれのディレクトリにもない場合は，このコマンドは JUPITR の SYS$SPECIFIC:[SYSEXE] ディレクトリにファイルを作成します。 同じ共通システム・ディスクからブートされる他のコンピュータにログインするときに，JUPITR の MODPARAMS.DAT を変更するには，以下のコマンドを入力します。 $ EDIT SYS$SYSDEVICE:[SYS0.SYSEXE]MODPARAMS.DAT 1 つのクラスタ共通システム・ディスクを使用するクラスタ内で，クラスタ共通システム登録ファイルのレコードを変更するには，任意のコンピュータから以下のコマンドを入力します。 $ SET DEFAULT SYS$COMMON:[SYSEXE] $ RUN SYS$SYSTEM:AUTHORIZE 同じクラスタ共通システム・ディスクからブートされる別のコンピュータにログインするときに，コンピュータ固有のシステム登録ファイルのレコードを変更するには，デフォルト・ディレクトリを特定のコンピュータに設定しなければなりません。たとえば，JUPITR コンピュータのコンピュータ固有のシステム登録ファイル (SYSUAF.DAT) を設定している場合，以下に示すように，AUTHORIZE を起動する前に，デフォルト・ディレクトリを JUPITR コンピュータの固有の [SYSEXE] ディレクトリに設定する必要があります。 $ SET DEFAULT SYS$SYSDEVICE:[SYS0.SYSEXE] $ RUN SYS$SYSTEM:AUTHORIZE 5.4 クラスタワイド論理名 OpenVMS バージョン 7.2 でサポートされたクラスタワイド論理名により，共用可能な論理名の便利さと使いやすさが OpenVMS Cluster システムでも利用可能です。クラスタワイド論理名は OpenVMS Integrity と OpenVMS Alpha の単一アーキテクチャ・クラスタでも，あるいはアーキテクチャ混成クラスタのどちらでも利用可能です。 既存のアプリケーションは，アプリケーション・コードを変更せずに，クラスタワイド論理名を利用できます。ただし，アプリケーションから (直接的または間接的に) 参照される論理名テーブルを少しだけ変更しなければなりません。 デフォルト設定では，新しい論理名はローカルでのみ有効です。クラスタワイド論理名は，ある論理名テーブルの属性です。新しい論理名をクラスタ単位で有効になるように設定するには，クラスタワイド論理名テーブルにその論理名を作成しなければなりません。 クラスタワイド論理名の最も重要な機能は以下のとおりです。 新しいノードがクラスタに参加する場合，現在設定されているクラスタワイド論理名全部を自動的に受け取ります。 クラスタワイド論理名または論理名テーブルが作成，変更，削除されると，その変更は OpenVMS バージョン 7.2 以降が稼動するクラスタ内の他のすべてのノードに自動的に伝達されます。クラスタ単位のテーブルに対するセキュリティ・プロファイルの変更も，この方法で自動的に伝達されます。 クラスタ単位の名前の変換によってパフォーマンスができるだけ低下しないように，変換はローカルに行われます。 LNM$CLUSTER_TABLE と LNM$SYSCLUSTER_TABLE は， OpenVMS バージョン 7.2 以降が稼動するすべてのシステムに存在するため，クラスタワイド論理名を使用するプログラムとコマンド・プロシージャは，クラスタに接続されていないシステムでも開発，テスト，実行することができます。 5.4.1 デフォルトのクラスタワイド論理名テーブル クラスタワイド論理名をサポートするために，オペレーティング・システムは， 表 5-1 に示すように，システム・スタートアップ時に 2 つのクラスタワイド論理名テーブルとそれぞれの論理名を作成します。これらの論理名テーブルと論理名は，プロセス論理名テーブル，ジョブ論理名テーブル，グループ論理名テーブル，システム論理名テーブルに加えて提供されるものです。クラスタワイド論理名テーブルの名前はシステム論理名ディレクトリ LNM$SYSTEM_DIRECTORY に格納されます。 表 5-1 デフォルトのクラスタワイド論理名テーブルと論理名 名前 目的 LNM$SYSCLUSTER_TABLE クラスタワイド・システム論理名のデフォルト・テーブル。出荷時には何も登録されていない。このテーブルは，クラスタワイド論理名を使用して環境をカスタマイズするシステム管理者を対象に提供される。このテーブルに登録されている名前は，誰でも使用することができ，SHOW LOGICAL/SYSTEM に， LNM$SYSTEM のテーブル名，LNM$DCL_LOGICAL (DCL のデフォルト・テーブル検索リスト)，LNM$FILE_DEV (システムと RMS のデフォルト) のいずれかを指定して，論理名を変換することができる。 LNM$SYSCLUSTER LNM$SYSCLUSTER_TABLE の論理名。 LNM$SYSCLUSTER_TABLE を参照するときに便利なように提供される。形式は，LNM$SYSTEM_TABLE およびその論理名である LNM$SYSTEM と同じである。 LNM$CLUSTER_TABLE LNM$SYSCLUSTER_TABLE も含めて，すべてのクラスタワイド論理名テーブルの親テーブル。親テーブルとして LNM$CLUSTER_TABLE を使用して新規テーブルを作成すると，そのテーブルはクラスタ単位で使用可能になる。 LNM$CLUSTER LNM$CLUSTER_TABLE の論理名。LNM$CLUSTER_TABLE を参照するときに便利なように提供される。 目次 索引
図 5-1 に示すのは，Integrity サーバと Alpha システムで FC SAN ストレージを共有する OpenVMS Cluster システムです。それぞれのアーキテクチャで自身のシステム・ディスクを持っています。
図 5-1 アーキテクチャ混成クラスタでのリソースの共用 (Integrity および Alpha)
ここでは， OpenVMS Integrity サーバおよび OpenVMS Alpha システムで構成されるアーキテクチャ混成クラスタにおけるシステム・ディスクも含めたストレージに関する規則について説明します。
図 5-2 に示すのは，ローカルに接続されたストレージと共有 Storage Area Network (SAN) を持つ OpenVMS Integrity および OpenVMS Alpha システムのアーキテクチャ混成クラスタを単純化した図です。
図 5-2 アーキテクチャ混成クラスタにおけるリソースの共有 (Integrity および Alpha)
アーキテクチャ混成 OpenVMS Cluster システムにおける Integrity サーバ・システムの特性は以下のとおりです。
アーキテクチャ混成 OpenVMS Cluster システムにおける Alpha システムの特性は以下のとおりです。
5.2 共通環境クラスタと多重環境クラスタ 処理のニーズに応じて，すべての環境ファイルがクラスタ単位で共用される環境，または一部のファイルはクラスタ単位で共用され，他のファイルは特定のコンピュータからだけアクセス可能な環境のいずれかを準備できます。 以下の表は，共通環境クラスタと多重環境クラスタの特徴を示しています。
処理のニーズに応じて，すべての環境ファイルがクラスタ単位で共用される環境，または一部のファイルはクラスタ単位で共用され，他のファイルは特定のコンピュータからだけアクセス可能な環境のいずれかを準備できます。
以下の表は，共通環境クラスタと多重環境クラスタの特徴を示しています。
5.3 共通システム・ディスクのディレクトリ構造オペレーティング・システムのインストールまたはアップグレード・プロシージャで， 共通システム・ディスク が作成されます。ほとんどのオペレーティング・システム・ファイルとオプションの製品ファイルは，このシステム・ディスクの共通のルート・ディレクトリに格納されます。 5.3.1 ディレクトリ・ルート システム・ディスクのディレクトリ構造は，Integrity サーバ・システムと Alpha システムで同一です。システム・ディスクが Alpha 用の場合も VAX 用の場合も，ディレクトリ構造全体，つまり， 共通ルートと各コンピュータの ローカル・ルートは同じディスクに格納されます。インストールまたはアップグレードが完了した後， 第 8 章 で説明する CLUSTER_CONFIG.COM あるいは CLUSTER_CONFIG_LAN.COM コマンド・プロシージャを使用して，クラスタにブートするときに使用されるローカル・ルートを新しい各コンピュータに対して作成します。 通常のシステム・ディレクトリの他に，各ローカル・ルートには [VMS$COMMON] のディレクトリ・エイリアスである [SYSn.SYSCOMMON] ディレクトリが格納されます。これは，クラスタ共通ファイルが実際に格納されるクラスタ共通ルート・ディレクトリです。コンピュータをクラスタに追加する際，コマンド・プロシージャは共通ルート・ディレクトリ・エイリアスを定義します。 5.3.2 ディレクトリ構造の例 図 5-3 は，JUPITR と SATURN というコンピュータのディレクトリ構造を示しています。この 2 台のコンピュータは共通システム・ディスクから実行されます。ディスクのマスタ・ファイル・ディレクトリ (MFD) には，ローカル・ルート (JUPITR の場合は SYS0，SATURN の場合は SYS1) と，クラスタ共通ルート・ディレクトリ [VMS$COMMON] が格納されています。 図 5-3 共通システム・ディスクのディレクトリ構造 5.3.3 検索順序 論理名 SYS$SYSROOT は，最初はローカル・ルート (SYS$SYSDEVICE:[SYS0.SYSEXE]) を指し，次に共通ルート (SYS$COMMON:[SYSEXE]) を指す検索リストとして定義されています。したがって，システム・ディレクトリの論理名 (SYS$SYSTEM， SYS$LIBRARY，SYS$MANAGER など) は，2 つのディレクトリを指します。 図 5-4 は，論理名 SYS$SYSTEM がファイル指定で使用されているときに，共通システム・ディスクのディレクトリがどのように検索されるかを示しています。 図 5-4 共通システム・ディスクでのファイルの検索順序 重要: 共通システム・ディスクのシステム・ファイルを操作する場合は，この検索順序を念頭に置いておかなければなりません。コンピュータ固有のファイルは，常に該当するコンピュータのシステム・サブディレクトリに格納し，更新しなければなりません。 例 MODPARAMS.DAT は SYS$SPECIFIC:[SYSEXE] に格納しておかなければなりません。これは， JUPITR では [SYS0.SYSEXE] であり，SATURN では [SYS1.SYSEXE] です。したがって，JUPITR にログインするときに，JUPITR の新しい MODPARAMS.DAT ファイルを作成するには，以下のコマンドを入力します。 $ EDIT SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT ファイルが作成された後，JUPITR にログオンするときに，以下のコマンドを使用してファイルを変更することができます。 $ EDIT SYS$SYSTEM:MODPARAMS.DAT このコマンドを入力したときに，MODPARAMS.DAT ファイルが JUPITR の SYS$SPECIFIC:[SYSEXE] ディレクトリに存在せず， SYS$COMMON:[SYSEXE] ディレクトリに MODPARAMS.DAT ファイルがある場合，このコマンドは共通ディレクトリの MODPARAMS.DAT ファイルを編集します。 MODPARAMS.DAT ファイルがいずれのディレクトリにもない場合は，このコマンドは JUPITR の SYS$SPECIFIC:[SYSEXE] ディレクトリにファイルを作成します。 同じ共通システム・ディスクからブートされる他のコンピュータにログインするときに，JUPITR の MODPARAMS.DAT を変更するには，以下のコマンドを入力します。 $ EDIT SYS$SYSDEVICE:[SYS0.SYSEXE]MODPARAMS.DAT 1 つのクラスタ共通システム・ディスクを使用するクラスタ内で，クラスタ共通システム登録ファイルのレコードを変更するには，任意のコンピュータから以下のコマンドを入力します。 $ SET DEFAULT SYS$COMMON:[SYSEXE] $ RUN SYS$SYSTEM:AUTHORIZE 同じクラスタ共通システム・ディスクからブートされる別のコンピュータにログインするときに，コンピュータ固有のシステム登録ファイルのレコードを変更するには，デフォルト・ディレクトリを特定のコンピュータに設定しなければなりません。たとえば，JUPITR コンピュータのコンピュータ固有のシステム登録ファイル (SYSUAF.DAT) を設定している場合，以下に示すように，AUTHORIZE を起動する前に，デフォルト・ディレクトリを JUPITR コンピュータの固有の [SYSEXE] ディレクトリに設定する必要があります。 $ SET DEFAULT SYS$SYSDEVICE:[SYS0.SYSEXE] $ RUN SYS$SYSTEM:AUTHORIZE 5.4 クラスタワイド論理名 OpenVMS バージョン 7.2 でサポートされたクラスタワイド論理名により，共用可能な論理名の便利さと使いやすさが OpenVMS Cluster システムでも利用可能です。クラスタワイド論理名は OpenVMS Integrity と OpenVMS Alpha の単一アーキテクチャ・クラスタでも，あるいはアーキテクチャ混成クラスタのどちらでも利用可能です。 既存のアプリケーションは，アプリケーション・コードを変更せずに，クラスタワイド論理名を利用できます。ただし，アプリケーションから (直接的または間接的に) 参照される論理名テーブルを少しだけ変更しなければなりません。 デフォルト設定では，新しい論理名はローカルでのみ有効です。クラスタワイド論理名は，ある論理名テーブルの属性です。新しい論理名をクラスタ単位で有効になるように設定するには，クラスタワイド論理名テーブルにその論理名を作成しなければなりません。 クラスタワイド論理名の最も重要な機能は以下のとおりです。 新しいノードがクラスタに参加する場合，現在設定されているクラスタワイド論理名全部を自動的に受け取ります。 クラスタワイド論理名または論理名テーブルが作成，変更，削除されると，その変更は OpenVMS バージョン 7.2 以降が稼動するクラスタ内の他のすべてのノードに自動的に伝達されます。クラスタ単位のテーブルに対するセキュリティ・プロファイルの変更も，この方法で自動的に伝達されます。 クラスタ単位の名前の変換によってパフォーマンスができるだけ低下しないように，変換はローカルに行われます。 LNM$CLUSTER_TABLE と LNM$SYSCLUSTER_TABLE は， OpenVMS バージョン 7.2 以降が稼動するすべてのシステムに存在するため，クラスタワイド論理名を使用するプログラムとコマンド・プロシージャは，クラスタに接続されていないシステムでも開発，テスト，実行することができます。 5.4.1 デフォルトのクラスタワイド論理名テーブル クラスタワイド論理名をサポートするために，オペレーティング・システムは， 表 5-1 に示すように，システム・スタートアップ時に 2 つのクラスタワイド論理名テーブルとそれぞれの論理名を作成します。これらの論理名テーブルと論理名は，プロセス論理名テーブル，ジョブ論理名テーブル，グループ論理名テーブル，システム論理名テーブルに加えて提供されるものです。クラスタワイド論理名テーブルの名前はシステム論理名ディレクトリ LNM$SYSTEM_DIRECTORY に格納されます。 表 5-1 デフォルトのクラスタワイド論理名テーブルと論理名 名前 目的 LNM$SYSCLUSTER_TABLE クラスタワイド・システム論理名のデフォルト・テーブル。出荷時には何も登録されていない。このテーブルは，クラスタワイド論理名を使用して環境をカスタマイズするシステム管理者を対象に提供される。このテーブルに登録されている名前は，誰でも使用することができ，SHOW LOGICAL/SYSTEM に， LNM$SYSTEM のテーブル名，LNM$DCL_LOGICAL (DCL のデフォルト・テーブル検索リスト)，LNM$FILE_DEV (システムと RMS のデフォルト) のいずれかを指定して，論理名を変換することができる。 LNM$SYSCLUSTER LNM$SYSCLUSTER_TABLE の論理名。 LNM$SYSCLUSTER_TABLE を参照するときに便利なように提供される。形式は，LNM$SYSTEM_TABLE およびその論理名である LNM$SYSTEM と同じである。 LNM$CLUSTER_TABLE LNM$SYSCLUSTER_TABLE も含めて，すべてのクラスタワイド論理名テーブルの親テーブル。親テーブルとして LNM$CLUSTER_TABLE を使用して新規テーブルを作成すると，そのテーブルはクラスタ単位で使用可能になる。 LNM$CLUSTER LNM$CLUSTER_TABLE の論理名。LNM$CLUSTER_TABLE を参照するときに便利なように提供される。 目次 索引
システム・ディスクのディレクトリ構造は，Integrity サーバ・システムと Alpha システムで同一です。システム・ディスクが Alpha 用の場合も VAX 用の場合も，ディレクトリ構造全体，つまり， 共通ルートと各コンピュータの ローカル・ルートは同じディスクに格納されます。インストールまたはアップグレードが完了した後， 第 8 章 で説明する CLUSTER_CONFIG.COM あるいは CLUSTER_CONFIG_LAN.COM コマンド・プロシージャを使用して，クラスタにブートするときに使用されるローカル・ルートを新しい各コンピュータに対して作成します。
通常のシステム・ディレクトリの他に，各ローカル・ルートには [VMS$COMMON] のディレクトリ・エイリアスである [SYSn.SYSCOMMON] ディレクトリが格納されます。これは，クラスタ共通ファイルが実際に格納されるクラスタ共通ルート・ディレクトリです。コンピュータをクラスタに追加する際，コマンド・プロシージャは共通ルート・ディレクトリ・エイリアスを定義します。 5.3.2 ディレクトリ構造の例 図 5-3 は，JUPITR と SATURN というコンピュータのディレクトリ構造を示しています。この 2 台のコンピュータは共通システム・ディスクから実行されます。ディスクのマスタ・ファイル・ディレクトリ (MFD) には，ローカル・ルート (JUPITR の場合は SYS0，SATURN の場合は SYS1) と，クラスタ共通ルート・ディレクトリ [VMS$COMMON] が格納されています。 図 5-3 共通システム・ディスクのディレクトリ構造 5.3.3 検索順序 論理名 SYS$SYSROOT は，最初はローカル・ルート (SYS$SYSDEVICE:[SYS0.SYSEXE]) を指し，次に共通ルート (SYS$COMMON:[SYSEXE]) を指す検索リストとして定義されています。したがって，システム・ディレクトリの論理名 (SYS$SYSTEM， SYS$LIBRARY，SYS$MANAGER など) は，2 つのディレクトリを指します。 図 5-4 は，論理名 SYS$SYSTEM がファイル指定で使用されているときに，共通システム・ディスクのディレクトリがどのように検索されるかを示しています。 図 5-4 共通システム・ディスクでのファイルの検索順序 重要: 共通システム・ディスクのシステム・ファイルを操作する場合は，この検索順序を念頭に置いておかなければなりません。コンピュータ固有のファイルは，常に該当するコンピュータのシステム・サブディレクトリに格納し，更新しなければなりません。 例 MODPARAMS.DAT は SYS$SPECIFIC:[SYSEXE] に格納しておかなければなりません。これは， JUPITR では [SYS0.SYSEXE] であり，SATURN では [SYS1.SYSEXE] です。したがって，JUPITR にログインするときに，JUPITR の新しい MODPARAMS.DAT ファイルを作成するには，以下のコマンドを入力します。 $ EDIT SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT ファイルが作成された後，JUPITR にログオンするときに，以下のコマンドを使用してファイルを変更することができます。 $ EDIT SYS$SYSTEM:MODPARAMS.DAT このコマンドを入力したときに，MODPARAMS.DAT ファイルが JUPITR の SYS$SPECIFIC:[SYSEXE] ディレクトリに存在せず， SYS$COMMON:[SYSEXE] ディレクトリに MODPARAMS.DAT ファイルがある場合，このコマンドは共通ディレクトリの MODPARAMS.DAT ファイルを編集します。 MODPARAMS.DAT ファイルがいずれのディレクトリにもない場合は，このコマンドは JUPITR の SYS$SPECIFIC:[SYSEXE] ディレクトリにファイルを作成します。 同じ共通システム・ディスクからブートされる他のコンピュータにログインするときに，JUPITR の MODPARAMS.DAT を変更するには，以下のコマンドを入力します。 $ EDIT SYS$SYSDEVICE:[SYS0.SYSEXE]MODPARAMS.DAT 1 つのクラスタ共通システム・ディスクを使用するクラスタ内で，クラスタ共通システム登録ファイルのレコードを変更するには，任意のコンピュータから以下のコマンドを入力します。 $ SET DEFAULT SYS$COMMON:[SYSEXE] $ RUN SYS$SYSTEM:AUTHORIZE 同じクラスタ共通システム・ディスクからブートされる別のコンピュータにログインするときに，コンピュータ固有のシステム登録ファイルのレコードを変更するには，デフォルト・ディレクトリを特定のコンピュータに設定しなければなりません。たとえば，JUPITR コンピュータのコンピュータ固有のシステム登録ファイル (SYSUAF.DAT) を設定している場合，以下に示すように，AUTHORIZE を起動する前に，デフォルト・ディレクトリを JUPITR コンピュータの固有の [SYSEXE] ディレクトリに設定する必要があります。 $ SET DEFAULT SYS$SYSDEVICE:[SYS0.SYSEXE] $ RUN SYS$SYSTEM:AUTHORIZE 5.4 クラスタワイド論理名 OpenVMS バージョン 7.2 でサポートされたクラスタワイド論理名により，共用可能な論理名の便利さと使いやすさが OpenVMS Cluster システムでも利用可能です。クラスタワイド論理名は OpenVMS Integrity と OpenVMS Alpha の単一アーキテクチャ・クラスタでも，あるいはアーキテクチャ混成クラスタのどちらでも利用可能です。 既存のアプリケーションは，アプリケーション・コードを変更せずに，クラスタワイド論理名を利用できます。ただし，アプリケーションから (直接的または間接的に) 参照される論理名テーブルを少しだけ変更しなければなりません。 デフォルト設定では，新しい論理名はローカルでのみ有効です。クラスタワイド論理名は，ある論理名テーブルの属性です。新しい論理名をクラスタ単位で有効になるように設定するには，クラスタワイド論理名テーブルにその論理名を作成しなければなりません。 クラスタワイド論理名の最も重要な機能は以下のとおりです。 新しいノードがクラスタに参加する場合，現在設定されているクラスタワイド論理名全部を自動的に受け取ります。 クラスタワイド論理名または論理名テーブルが作成，変更，削除されると，その変更は OpenVMS バージョン 7.2 以降が稼動するクラスタ内の他のすべてのノードに自動的に伝達されます。クラスタ単位のテーブルに対するセキュリティ・プロファイルの変更も，この方法で自動的に伝達されます。 クラスタ単位の名前の変換によってパフォーマンスができるだけ低下しないように，変換はローカルに行われます。 LNM$CLUSTER_TABLE と LNM$SYSCLUSTER_TABLE は， OpenVMS バージョン 7.2 以降が稼動するすべてのシステムに存在するため，クラスタワイド論理名を使用するプログラムとコマンド・プロシージャは，クラスタに接続されていないシステムでも開発，テスト，実行することができます。 5.4.1 デフォルトのクラスタワイド論理名テーブル クラスタワイド論理名をサポートするために，オペレーティング・システムは， 表 5-1 に示すように，システム・スタートアップ時に 2 つのクラスタワイド論理名テーブルとそれぞれの論理名を作成します。これらの論理名テーブルと論理名は，プロセス論理名テーブル，ジョブ論理名テーブル，グループ論理名テーブル，システム論理名テーブルに加えて提供されるものです。クラスタワイド論理名テーブルの名前はシステム論理名ディレクトリ LNM$SYSTEM_DIRECTORY に格納されます。 表 5-1 デフォルトのクラスタワイド論理名テーブルと論理名 名前 目的 LNM$SYSCLUSTER_TABLE クラスタワイド・システム論理名のデフォルト・テーブル。出荷時には何も登録されていない。このテーブルは，クラスタワイド論理名を使用して環境をカスタマイズするシステム管理者を対象に提供される。このテーブルに登録されている名前は，誰でも使用することができ，SHOW LOGICAL/SYSTEM に， LNM$SYSTEM のテーブル名，LNM$DCL_LOGICAL (DCL のデフォルト・テーブル検索リスト)，LNM$FILE_DEV (システムと RMS のデフォルト) のいずれかを指定して，論理名を変換することができる。 LNM$SYSCLUSTER LNM$SYSCLUSTER_TABLE の論理名。 LNM$SYSCLUSTER_TABLE を参照するときに便利なように提供される。形式は，LNM$SYSTEM_TABLE およびその論理名である LNM$SYSTEM と同じである。 LNM$CLUSTER_TABLE LNM$SYSCLUSTER_TABLE も含めて，すべてのクラスタワイド論理名テーブルの親テーブル。親テーブルとして LNM$CLUSTER_TABLE を使用して新規テーブルを作成すると，そのテーブルはクラスタ単位で使用可能になる。 LNM$CLUSTER LNM$CLUSTER_TABLE の論理名。LNM$CLUSTER_TABLE を参照するときに便利なように提供される。 目次 索引
図 5-3 は，JUPITR と SATURN というコンピュータのディレクトリ構造を示しています。この 2 台のコンピュータは共通システム・ディスクから実行されます。ディスクのマスタ・ファイル・ディレクトリ (MFD) には，ローカル・ルート (JUPITR の場合は SYS0，SATURN の場合は SYS1) と，クラスタ共通ルート・ディレクトリ [VMS$COMMON] が格納されています。
図 5-3 共通システム・ディスクのディレクトリ構造
論理名 SYS$SYSROOT は，最初はローカル・ルート (SYS$SYSDEVICE:[SYS0.SYSEXE]) を指し，次に共通ルート (SYS$COMMON:[SYSEXE]) を指す検索リストとして定義されています。したがって，システム・ディレクトリの論理名 (SYS$SYSTEM， SYS$LIBRARY，SYS$MANAGER など) は，2 つのディレクトリを指します。
図 5-4 は，論理名 SYS$SYSTEM がファイル指定で使用されているときに，共通システム・ディスクのディレクトリがどのように検索されるかを示しています。
図 5-4 共通システム・ディスクでのファイルの検索順序
重要: 共通システム・ディスクのシステム・ファイルを操作する場合は，この検索順序を念頭に置いておかなければなりません。コンピュータ固有のファイルは，常に該当するコンピュータのシステム・サブディレクトリに格納し，更新しなければなりません。
例
$ EDIT SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT
ファイルが作成された後，JUPITR にログオンするときに，以下のコマンドを使用してファイルを変更することができます。
$ EDIT SYS$SYSTEM:MODPARAMS.DAT
このコマンドを入力したときに，MODPARAMS.DAT ファイルが JUPITR の SYS$SPECIFIC:[SYSEXE] ディレクトリに存在せず， SYS$COMMON:[SYSEXE] ディレクトリに MODPARAMS.DAT ファイルがある場合，このコマンドは共通ディレクトリの MODPARAMS.DAT ファイルを編集します。 MODPARAMS.DAT ファイルがいずれのディレクトリにもない場合は，このコマンドは JUPITR の SYS$SPECIFIC:[SYSEXE] ディレクトリにファイルを作成します。
$ EDIT SYS$SYSDEVICE:[SYS0.SYSEXE]MODPARAMS.DAT
$ SET DEFAULT SYS$COMMON:[SYSEXE] $ RUN SYS$SYSTEM:AUTHORIZE
$ SET DEFAULT SYS$SYSDEVICE:[SYS0.SYSEXE] $ RUN SYS$SYSTEM:AUTHORIZE
5.4 クラスタワイド論理名
OpenVMS バージョン 7.2 でサポートされたクラスタワイド論理名により，共用可能な論理名の便利さと使いやすさが OpenVMS Cluster システムでも利用可能です。クラスタワイド論理名は OpenVMS Integrity と OpenVMS Alpha の単一アーキテクチャ・クラスタでも，あるいはアーキテクチャ混成クラスタのどちらでも利用可能です。
既存のアプリケーションは，アプリケーション・コードを変更せずに，クラスタワイド論理名を利用できます。ただし，アプリケーションから (直接的または間接的に) 参照される論理名テーブルを少しだけ変更しなければなりません。
デフォルト設定では，新しい論理名はローカルでのみ有効です。クラスタワイド論理名は，ある論理名テーブルの属性です。新しい論理名をクラスタ単位で有効になるように設定するには，クラスタワイド論理名テーブルにその論理名を作成しなければなりません。
クラスタワイド論理名の最も重要な機能は以下のとおりです。
5.4.1 デフォルトのクラスタワイド論理名テーブル クラスタワイド論理名をサポートするために，オペレーティング・システムは， 表 5-1 に示すように，システム・スタートアップ時に 2 つのクラスタワイド論理名テーブルとそれぞれの論理名を作成します。これらの論理名テーブルと論理名は，プロセス論理名テーブル，ジョブ論理名テーブル，グループ論理名テーブル，システム論理名テーブルに加えて提供されるものです。クラスタワイド論理名テーブルの名前はシステム論理名ディレクトリ LNM$SYSTEM_DIRECTORY に格納されます。 表 5-1 デフォルトのクラスタワイド論理名テーブルと論理名 名前 目的 LNM$SYSCLUSTER_TABLE クラスタワイド・システム論理名のデフォルト・テーブル。出荷時には何も登録されていない。このテーブルは，クラスタワイド論理名を使用して環境をカスタマイズするシステム管理者を対象に提供される。このテーブルに登録されている名前は，誰でも使用することができ，SHOW LOGICAL/SYSTEM に， LNM$SYSTEM のテーブル名，LNM$DCL_LOGICAL (DCL のデフォルト・テーブル検索リスト)，LNM$FILE_DEV (システムと RMS のデフォルト) のいずれかを指定して，論理名を変換することができる。 LNM$SYSCLUSTER LNM$SYSCLUSTER_TABLE の論理名。 LNM$SYSCLUSTER_TABLE を参照するときに便利なように提供される。形式は，LNM$SYSTEM_TABLE およびその論理名である LNM$SYSTEM と同じである。 LNM$CLUSTER_TABLE LNM$SYSCLUSTER_TABLE も含めて，すべてのクラスタワイド論理名テーブルの親テーブル。親テーブルとして LNM$CLUSTER_TABLE を使用して新規テーブルを作成すると，そのテーブルはクラスタ単位で使用可能になる。 LNM$CLUSTER LNM$CLUSTER_TABLE の論理名。LNM$CLUSTER_TABLE を参照するときに便利なように提供される。 目次 索引
クラスタワイド論理名をサポートするために，オペレーティング・システムは， 表 5-1 に示すように，システム・スタートアップ時に 2 つのクラスタワイド論理名テーブルとそれぞれの論理名を作成します。これらの論理名テーブルと論理名は，プロセス論理名テーブル，ジョブ論理名テーブル，グループ論理名テーブル，システム論理名テーブルに加えて提供されるものです。クラスタワイド論理名テーブルの名前はシステム論理名ディレクトリ LNM$SYSTEM_DIRECTORY に格納されます。
