| 前へ | 次へ | 目次 | 索引 |
WWPPS (World-Wide PostScript Printing Subsystem) は，任意の PostScript プリンタのさまざまな言語文字を使用して， PostScript ファイルを印刷するためのユーティリティです。フォント・データを PostScript 印刷可能ファイルに埋め込むことで，プリンタにローカル言語文字フォントがない場合でも，その言語の文字を印刷できます。
WWPPS ユーティリティの使い方の詳細については，『OpenVMS User's Manual』を参照してください。
WWPPS ユーティリティのインストールと管理の詳細については，『Compaq OpenVMS システム管理者マニュアル』を参照してください。
この章では，システム管理者に関連する新機能，変更点，拡張機能について説明します。
4.1 新しい AlphaServer GS シリーズ・システムに対する OpenVMS のサポート
OpenVMS Alpha バージョン 7.3 では， Compaq AlphaServer GS80，GS160，GS320 システムがサポートされます。このサポートは OpenVMS バージョン 7.2-1H1 で導入され，次の機能が提供されます。
4.1.1 ハード・パーティションとソフト・パーティションに対する OpenVMS のサポート
ハード・パーティションは，ハードウェアに設定されたアクセス境界によって，コンピューティング・リソースを物理的に分離することです。ハード・パーティション境界をこえて読み込みや書き込みを行うことはできません。ハード・パーティション間でリソースを共有することはできません。
ソフト・パーティションとは，ソフトウェアで制御されるアクセス境界によって，コンピューティング・リソースを分離することです。ソフト・パーティション境界をこえた読み込みアクセスと書き込みアクセスは，オペレーティング・システムによって制御されます。 OpenVMS Galaxy はソフト・パーティションをインプリメントした機能です。
システムをどのようにパーティションに区切るかは，コンピューティング環境およびアプリケーションの要件に応じて異なります。ハード・パーティションと OpenVMS Galaxy の使用方法の詳細については， 『Compaq OpenVMS Alpha パーティショニングおよび Galaxy ガイド』
を参照してください。
4.1.2 アプリケーションに対する OpenVMS Resource Affinity Domain (RAD) のサポート
OpenVMS Alpha バージョン 7.3 では，OpenVMS メモリ管理およびプロセス・スケジューリングで NUMA (non-uniform memory awareness) 機能が提供されます。この機能は OpenVMS バージョン 7.2-1H1 で導入されました。この機能により，アプリケーションに対して Resource Affinity Domain (RAD) がサポートされるようになります。 RAD のサポートにより，複数の Quad Building Block (QBB) 上の OpenVMS のシングル・インスタンスで稼動するアプリケーションは， NUMA 環境で効率よく実行できるようになります。RAD は共通のアクセス属性を持つハードウェア・コンポーネント (CPU，メモリ，IO) の集合であり， AlphaServer GS160 または GS320 システムの QBB に対応します。
アプリケーションに対する OpenVMS RAD のサポート機能の使用方法の詳細については， 『Compaq OpenVMS Alpha パーティショニングおよび Galaxy ガイド』
を参照してください。
4.1.3 OpenVMS でのCPU Online Replace 機能のサポート
OpenVMS Alpha バージョン 7.3 では，実行中のシステムを再ブートせずに，セカンダリ CPU を交換できるようになりました。その結果，システムの管理機能とサービス機能が向上しました。この機能は AlphaServer GS160/320 システムでのみサポートされます。プライマリ CPU を交換する場合は，再ブートが必要です。
この機能を使用するには，最初に次のアドレスからコンソール・ファームウェア・バージョン 5.9B をダウンロードしてください。
http://ftp.digital.com/pub/DEC/Alpha/firmware/ |
コンソールを最新のファームウェアでアップグレードした後，次の DCL コマンドを使用することで，再ブートせずに CPU を交換できます。
$ STOP/CPU n |
(n は停止する CPU の番号です。)
$ SET CPU/POWER=OFF n |
$ SET CPU/POWER=ON n |
OpenVMS は自動的に CPU をアクティブ・プロセッサ・セットに追加します。
Galaxy Configuration ユーティリティ (GCU) でも，この機能がサポートされます。
4.2 夏時間の自動設定
システム・パラメータ AUTO_DLIGHT_SAV は，OpenVMS が必要に応じてシステム時刻を夏時間と標準時間の間で自動的に切り換えるかどうかを制御します。このパラメータの値が 1 の場合は，夏時間と標準時間の切り換えが自動的に行われます。デフォルトは 0 (オフ) です。これは静的パラメータです。
しかし，タイム・サービス (DTSS など) を使用している場合は，タイム・サービスが引き続き時刻の変更を制御し，OpenVMS がその動作を妨害することはありません。他のタイム・サービスを使用している場合は，夏時間の自動設定を有効にしないでください。
詳細については，『Compaq OpenVMS システム管理者マニュアル』を参照してください。
4.3 CPU スケジューリングのためのクラス・スケジューラ
OpenVMS バージョン 7.3 では，クラス・スケジューリングのために新しい SYSMAN ベースのインタフェースが導入されました。この新しいクラス・スケジューラは，VAX システムと Alpha システムの両方でインプリメントされており，ユーザをスケジューリング・クラスに配置することで，システムのユーザに割り当てることのできる CPU 時間数を指定できます。各クラスに対して，システム全体で利用できる CPU 時間の一部がパーセントで割り当てられます。システム実行時に 1 つのクラス内のユーザが使用できる CPU 時間数は，そのクラスに割り当てられている CPU 実行時間の割合に制限されます。スケジューリング・クラスに対して /windfall が有効に設定されている場合は，そのクラスのユーザに追加 CPU 時間を割り当てることができます。 /windfall を有効にすると，CPU が使用されていない状態で，スケジューリング・クラスに割り当てられた CPU 時間数がすべて使用されてしまった場合，システムは少量の CPU 時間をそのスケジューリング・クラスに割り当てることができます。
クラス・スケジューラを起動するには，SYSMAN インタフェースを使用します。SYSMAN では，スケジューリング・クラスの作成，削除，変更，停止，再開，表示を行うことができます。 表 4-1 は，SYSMAN のコマンド CLASS_SCHEDULE とそのサブコマンドを示しています。
| サブコマンド | 意味 |
|---|---|
| ADD | 新しいスケジューリング・クラスを作成する。 |
| DELETE | スケジューリング・クラスを削除する。 |
| MODIFY | スケジューリング・クラスの属性を変更する。 |
| SHOW | スケジューリング・クラスの属性を表示する。 |
| SUSPEND | スケジューリング・クラスを一時停止する。 |
| RESUME | スケジューリング・クラスを再開する。 |
SYSMAN インタフェースを使用してクラス・スケジューラをインプリメントすると，パーマネント・データベースが作成され，システムがブートおよび再ブートされた後，OpenVMS は自動的にプロセスをクラス・スケジューリングできるようになります。このデータベースはシステム・ディスクの SYS$SYSTEM:VMS$CLASS_SCHEDULE.DATA に格納されます。 SYSMAN コマンド CLASS_SCHEDULE ADD を使用してスケジューリング・クラスを作成すると，SYSMAN はこのファイルを RMS 索引付きファイルとして作成します。
クラスタ環境では，SYSMAN はこのデータベース・ファイルを SYS$COMMON:[SYSEXE] ディレクトリに作成します。その結果，データベース・ファイルはすべてのクラスタ・メンバで共用されます。 SYSMAN の SET ENVIRONMENT コマンドを使用すると，スケジューリング・クラスをクラスタ単位またはノード単位で定義できます。
必要に応じて，システム管理者 (またはアプリケーション管理者) はパーマネント・クラス・スケジューラを使用して，プロセスの作成時にプロセスをスケジューリング・クラスに登録します。新規プロセスが作成されるときに，Loginout はこのプロセスがスケジューリング・クラスに属しているかどうか判断します。 SYSUAF ファイルから与えられるプロセス情報をもとに，Loginout で，プロセスがスケジューリング・クラスに属していることが判断された場合，そのプロセスはクラス・スケジューリングされます。
$SCHED システム・サービスではなく，SYSMAN ユーティリティを使用してクラス・スケジューリング操作を実行すると，次の利点があります。
詳細については，次のマニュアルを参照してください。
『OpenVMS Programming Concepts Manual, Volume I』
『Compaq OpenVMS DCL ディクショナリ: N--Z』
『OpenVMS System Services Reference Manual: A--GETUAI』
専用 CPU Lock Manager は，ロック・マネージャの処理頻度が非常に高い，大規模な SMP システムでパフォーマンスを向上できる新機能です。この機能は，実行中のロック・マネージャ操作が CPU を占有できるようにします。
専用 CPU を使用すると，次の点でシステム全体のパフォーマンスが向上します。
4.4.1 専用 CPU Lock Manager のインプリメント
専用 CPU Lock Manager が効果的に機能するには，システムに多くの CPU が搭載され，ロック・マネージャに与えられる MP_SYNCH の値が高く設定されていなければなりません。MP_SYNCH の値を確認するには， MONITOR ユーティリティと MONITOR MODE コマンドを使用します。システムに搭載されている CPU の数が 5 以上で，MP_SYNCH が 200% 以上の場合は，システムで専用 CPU Lock Manager を利用できます。また，System Dump Analyzer (SDA) のスピンロック・トレース機能を使用することで，MP_SYNCH の値が高くなっている原因がロック・マネージャにあるかどうかを判断することもできます。
専用 CPU Lock Manager は LCKMGR_SERVER プロセスによってインプリメントされます。このプロセスは優先順位 63 で実行されます。専用 CPU Lock Manager が有効に設定されている場合は，このプロセスは演算拘束ループで動作して，実行するロック・マネージャの作業を検索します。このプロセスは作業をポールするので，常に演算可能です。さらに，優先順位 63 で動作するので，このプロセスが CPU の使用を断念することは絶対にないため，CPU 全体を占有することになります。
プログラムが $ENQ または $DEQ システム・サービスを呼び出すときに，専用 CPU Lock Manager が実行中の場合には，ロック・マネージャ要求は専用 CPU Lock Manager の作業キューに格納されます。プロセスがロック要求の処理を待っている間，プロセスはカーネル・モードで IPL 2 でスピンします。専用 CPU が要求を処理した後，システム・サービスの状態がプロセスに返されます。
専用 CPU Lock Manager は動的であるため，使用してもメリットがない場合は，オフに設定できます。専用 CPU Lock Manager がオフになっている場合は，LCKMGR_SERVER プロセスは HIB (ハイバネート) 状態になります。プロセスを開始した後，削除することはできません。
4.4.2 専用 CPU Lock Manager の有効化
専用 CPU Lock Manager を使用するには， LCKMGR_MODE システム・パラメータをセットします。 LCKMGR_MODE システム・パラメータについては，次のことに注意してください。
LCKMGR_MODE を 0 より大きな値に設定すると， LCKMGR_SERVER という独立プロセスが作成されます。プロセスが作成された後，アクティブ CPU の数が LCKMGR_MODE システム・パラメータで設定された値に等しい場合は，プロセスの実行が開始されます。
さらに，STOP/CPU コマンドまたは Galaxy 構成での CPU 再割り当てによって，アクティブ CPU の数が必要なしきい値より少なくなると，専用 CPU Lock Manager は 1 秒以内に自動的にオフになり，LCKMGR_SERVER プロセスはハイバネート状態になります。CPU が再起動されると， LCKMGR_SERVER プロセスは操作を再開します。
4.4.3 アフィニティによる専用 CPU Lock Manager の使用
LCKMGR_SERVER プロセスでは，アフィニティ機能を使用して，プロセスをプライマリ CPU 以外で最も小さな CPU ID に設定します。この値は，LCKMGR_CPUID システム・パラメータで別の CPU ID を指定することで変更できます。専用 CPU Lock Manager はこの CPU を使用しようとします。この CPU を使用できない場合は，プライマリ以外で，最も小さい CPU ID を持つ CPU が使用されます。
LCKMGR_SERVER プロセスが使用する CPU を動的に変更するには，次の方法を使用します。
$RUN SYS$SYSTEM:SYSGEN SYSGEN>USE ACTIVE SYSGEN>SET LCKMGR_CPUID 2 SYSGEN>WRITE ACTIVE SYSGEN>EXIT |
この変更は現在実行中のシステムに適用されます。再ブートすると，プライマリ以外で ID が最小の CPU に戻ります。 LCKMGR_SERVER プロセスが使用する CPU を永久的に変更するには， MODPARAMS.DAT ファイルで LCKMGR_CPUID を設定します。
ロック・マネージャ専用の CPU を確認するには，次の SHOW SYSTEM コマンドを使用します。
$ SHOW SYSTEM/PROCESS=LCKMGR_SERVER OpenVMS V7.3 on node JYGAL 24-OCT-2000 10:10:11.31 Uptime 3 20:16:56 Pid Process Name State Pri I/O CPU Page flts Pages 4CE0021C LCKMGR_SERVER CUR 2 63 9 3 20:15:47.78 70 84 |
State フィールドには，プロセスが現在 CPU 2 で実行中であることが示されています。
専用 CPU Lock Manager が使用する CPU へのハード・アフィニティをプロセスに与えないようにしてください。ハード・アフィニティが与えられていると，このようなプロセスが演算可能になっても， CPU 時間を取得することができません。これは， LCKMGR_SERVER プロセスがリアルタイム・プロセスの最高の優先順位である 63 で実行されているからです。しかし， LCKMGR_SERVER は，アフィニティ・メカニズムによって，専用ロック・マネージャ CPU に設定されている演算可能なプロセスがあるかどうかを毎秒確認します。このようなプロセスがある場合，LCKMGR_SERVER は 1 秒間，別の CPU に切り換えて，待ち状態のプロセスを実行できるようにします。
4.4.4 Fast Path デバイスと組み合わせた専用 CPU Lock Manager の使用
OpenVMS バージョン 7.3 では，これまでサポートされてきた CIPCA アダプタの他に， Fast Path for SCSI および Fibre Channel コントローラもサポートされるようになりました。専用 CPU Lock Manager は LCKMGR_SERVER プロセスと Fast Path デバイスの両方を同じ CPU でサポートします。しかし，このような組み合わせで使用した場合，最適なパフォーマンスを実現できないことがあります。
デフォルト設定では，LCKMGR_SERVER はプライマリ以外で使用可能な最初の CPU で実行されます。LCKMGR_SERVER プロセスが使用する CPU には，できるだけ Fast Path デバイスを接続しないようにしてください。次のいずれかの方法で行うことができます。
たとえば，システムに 8 つの CPU が搭載されていて， CPU ID が 0〜7 であり，Fast Path を使用する SCSI アダプタが 4 つあるとしましょう。 IO_PREFER_CPUS からビット 1 をクリアすると， 4 つの SCSI デバイスは CPU 2，3，4，5 に対応付けられます。ロック・マネージャが使用するデフォルトの CPU 1 では， Fast Path デバイスは使用されません。
| 前へ | 次へ | 目次 | 索引 |