日本-日本語

製品  >  ソフトウェア  >  OpenVMS

OpenVMS FAQ


≫ 

OpenVMS ドキュメント
ライブラリ

タイトルページ
目次
第 1 章:概要
第 2 章:ドキュメント
第 3 章:時間の管理
第 4 章:ネットワークとクラスタ
索引
OpenVMS ホーム

HP OpenVMS
FAQ


目次 索引



厳密にはGoogle search の最初の数ページから抜粋した情報ですが,組み込みNTPサーバを備えたGPS ベースのレシーバの提供ベンダーがいくつか存在します。入手の可否,価格,OpenVMSとの互換性などについては未確認です。

  • http://www.galleon.eu.com/

  • http://www.meinberg.de/english/

  • http://www.ntp-servers.com/

直接接続 (ローカル,非IP,非NTP) リンクについては,いくつかのシリアル・オプションが利用できます。 Google で検索すると Spectracom Corporation の NetClock という製品が使えそうです。 OpenVMS ホスト・ソフトウェアが存在するかどうかはわかりませんが,このデバイスをサポートするための ASCII データ・ストリームを書くことは可能と思われます。 (このようなコーディングには,シリアルI/Oの知識,キャラクタ処理, OpenVMS におけるクロック・ドリフト API メカニズムに関する知識が必要です。 OpenVMS のクロック・ドリフト・メカニズムと結び付ける方法を学ぶのに利用可能な Freeware ツールが存在します。)

  • http://www.spectracomcorp.com/



3.3.1 クラスタ環境でバッチ・ジョブが設定時刻よりも早く実行されるのはなぜですか

クラスタ・メンバ間でシステム時刻がずれ,バッチ・ジョブを実行するメンバのシステム時刻よりもキュー管理ジョブを実行するクラスタ・メンバの時刻の方が遅く設定されているためです。

この動作は, SUBMIT/AFTER=TOMORROW あるいはこれと似たような構文を使用した場合に顕著で,これを避ける方法としては/AFTER="TOMMOROW+00:01:00" などの構文を使用することが推奨されます。指定する組み合せ時間値は,予想される時間のずれよりも大きな値にします。上記の例では,クラスタ内の各マシンの時刻のずれは最大でも 1:00 と予想されている環境における実行例です。

対応策として, 第 3.2 節 で説明するツールなどを使用してシステム時刻の同期をより適切に取ることも可能です。

3.3.2 OpenVMS システムの時刻がずれる理由を教えてください

メモリ・エラー,ハードウェアの問題,あるいは IPL 22 または IPL 24 以上で動作するほとんどの操作は,システム時刻のロスが発生する原因となります (クロック IPL はシステム・ファミリによって異なり,クロック IPL 以上で動作するコードは,クロック割り込みの処理を妨げます) 。また,(温度変化などによる) 一般的なクロックの変動や予想されるレベルの時計の狂いに伴い,クロックのずれが発生することがあります。

多数のドライバ割り込み動作やハードウェア・エラー,修正可能な (ソフト) メモリ・エラーなど,高い IPL でコードが動作した結果としてクロック割り込みがブロックされる場合は,クロックで「タイム・ロス」が発生し,ユーザに報告される時刻が遅れているように見えます。つまり,修正可能なメモリ・エラーは,システム時刻のタイム・ロスの一般的な原因となります。 PCI バスのトラフィックが過剰な場合も,タイム・ロスの原因になります。

この問題に関連する 1 つのバグがあり, ELSA GLoria Synergy PBXGK-BB (PowerStorm 3D10T) などの特定のグラフィック・コントローラの動作により PCI バスが事実上ストールするという問題があります。 ELSA GLoria Synergy の詳細については,英語版FAQの「System Management Information」の「Drivers and Configuration of New Graphics Controllers?」を参照してください。また,最新の GRAPHICS ECO キットがインストールされていることを確認してください。

クロックのドリフトは,DTSS または NTP パッケージの動作によって発生することもあります。

第 3.1.1.2.1 項第 3.1.1 項 ,および 第 3.3.4 項 も参照してください。

3.3.3 過去の時間へのシステム時刻の再設定について

SET TIME や SET TIME/CLUSTER などの DCL コマンドを使用してシステム時刻の同期を取り直すことができますが,これらのコマンドは現在のシステム時刻を過去の時刻に設定してしまう原因にもなります。時間の再設定はアプリケーションで問題を引き起こす可能性があり,絶対的なタイマーを使用するアプリケーションや,時間値は常に 1 つしか存在せず逆行はしないという前提で設計されているアプリケーションに悪影響を及ぼす可能性があります。

たとえ1 時間であっても設定時刻を過去に戻すのは,アプリケーションやレイヤード製品の実行時にさまざまな問題が発生する原因となります。このため,Year 2000 (Y2K) のテスト時にはこれらのコマンドによる方法は使用しないようにし,問題の発生を防ぐ正しい方法としてシステムあるいはクラスタのリブートを強くお勧めしました。

アプリケーション・プログラマに対しては,これらの方法を使用しても逆行するクロック・イベントにアプリケーションがうまく対応できるように, $set_system_event システム・サービスで利用できる時刻関係のイベントおよびTDF関係のイベントを使用すること,および UTC などを使用することをお勧めしています。 ( DECnet-Plus における DTSS から TDF イベントの生成に関する問題を修正するための ECO キットが提供されており, V7.3 ECO4 以降,V7.3-1 ECO3 以降,および V7.3-2 ECO1 以降でこれが適用されます。 DECnet-Plus から最適な TDF イベントをサポートするために,各 OpenVMS リリース用の最新の DECnet-Plus ECO キットを適用してください。 )

第 3.3.4 項 および 第 3.3.1 項 も参照してください。

3.3.4 OpenVMS のシステム時刻はどのようにドリフトするのですか

DECdts および TCP/IP Services の NTP では,「負の時間変動」によって発生する問題を回避するために,システム時刻の値が「ドリフト」されます (ドリフトは変更ではありません)。同様の基本的なクロック・ドリフト手法が, OpenVMS で動作するほとんどのタイム・サーバで使用されています。通常は,OpenVMS 内で直接サポートされるドリフト機能を利用しています。

システム時刻をドリフトさせるために (OpenVMS VAX で) 使用されている手法の例として, OpenVMS Freeware の SETCLOCK ツールがあります。

OpenVMS Alpha で EXE$GL_TIMEADJUST および EXE$GL_TICKLENGTH セルを使用する方法については,『OpenVMS AXP Internal and Data Structures』の 348 ページを参照してください。

夏時間 (DST) と標準時間の切り換えでは,時刻値はドリフトではなく,インターバルで調整されます。このプロシージャは,DST と標準時間の切り換えの定義で決められています(この切り換えがお使いの環境では適切でない場合は,夏時間への切り換えを行わないか,あるいは UTC を使用することを検討してください)。

第 3.3.3 項 も参照してください。

3.3.5 TCP/IP Services NTP をタイム・プロバイダとして構成する方法を教えてください

NTP タイム・プロバイダは,NTP プロトコルを介して現在の時刻を NTP クライアントに提供します。

NTP は,ストラータと呼ばれるレイヤ構造を持っています。実際の NTP タイム・ソース (インターネット・タイム・サーバはストラータ 1) から離れるほど,ストラータ階層は低くなります (ストラータに割り当てられる番号は大きくなります)。

ストラータ 1 で明示的に構成されている NTP は,低い階層のストラータで動作する NTP に時刻を提供し,提供された時刻はローカルのシステム時刻をもとに取得されるか,またはローカルでアクセス可能な外部のタイム・ソースを介して取得されます。

他の (低い階層の) ストラータで動作する NTP は,高い階層のストラータから時刻を受け取り,その時刻を低い階層のストラータへ提供し,ローカル・ストラータを自動的に調整することができます。最高レベルはストラータ 1 で,最低レベルはストラータ 15 です。

TCP/IP Services NTP パッケージはどのストラータでも動作でき,ピア,クライアント,ブロードキャスト・サーバのいずれとしても構成できます。 NTP は DECnet-Plus DTSS ネットワークにも時刻を提供できます。 第 3.2 節 を参照してください。

TCP/IP Services V5.0 以降,サポートされる参照クロックは LCL (ローカル・システム・クロック) だけです。システムに高機能のクロックが搭載されている場合や,システム時刻が他のタイム・サーバや周辺デバイス (DTSS サービス,GPS サービス,セシウム・クロック,GPIB コントローラ,その他の同様の時刻関連周辺デバイス) で制御されている場合は,システム・クロックを参照ソースとして使用するように NTP を構成できます。これは,マスタ・クロックの機能を模倣するものであり, NTP はストラータ 1 のタイム・サーバとして構成されます。このように構成するには,以下のコマンドを TCPIP$NTP.CONF に入力します。


server 127.127.1.0 prefer 
fudge 127.127.1.0 stratum 0 

ローカル・マスタ機能の場合も,コマンドはほとんど同じです。以下のコマンドを入力してください。


server 127.127.1.0 
fudge 127.127.1.0 stratum 8 

上記の 2 つのコマンドの違いは,ストラータの違いと, prefer というキーワードが省略されている点です。高い値のストラータを指定すると,ノードはバックアップ NTP サーバとして機能することも,隔離されたネットワークで単独のタイム・サーバとして機能することもできます。サーバがアクティブになるのは,通常使用される他のすべての同期ソースが使用できなくなった場合だけです。 "prefer" というキーワードを使用すると,NTP は指定されたクロックを常に時刻同期ソースとして使用します。

V5.0 より前のバージョンの TCP/IP Services では, NTP の管理はもっと原始的です。ローカルの OpenVMS システムを NTP クライアントから NTP サーバに構成するには (V5.0 より前のバージョンの TCP/IP Services で),以下の行を sys$specific:[ucx$ntp]ucx$ntp.conf ファイルに追加します。


master-clock 1 

また,V5.0 より前のバージョンの TCP/IP Services の場合は,以下の NTP テンプレート・ファイルも参照してください。


SYS$SPECIFIC:[UCX$NTP]UCX$NTP.TEMPLATE 

NTP では,夏時間 (DST) の切り換えに関する機能は提供されません。切り換えはローカル・システムのタイムゾーン・ルールや SYS$EXAMPLES:DAYLIGHT_SAVINGS プロシージャから行う必要があります。 さらに,V7.3 の SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM にはバグがあることがわかっています。提供されている ECO キットを適用してください。

最新の TCP/IP Services および関連する OpenVMS ドキュメントについては,以下のサイトを参照してください。

  • http://h50146.www5.hpe.com/products/software/oe/openvms/manual/ (日本語)

  • http://www.hp.com/go/openvms/doc/ (英語)



3.4 タイムゾーンの管理,時刻の管理,UTC,夏時間について教えてください

OpenVMS V6.0 以降では,以下のコマンド・プロシージャを使用して, OpenVMS TDF (Timezone Differential Factor) を構成できます。

  • SYS$MANAGER:UTC$TIME_SETUP.COM

BOTH オプションを選択してください。このコマンド・プロシージャは OpenVMS TDF を設定しますが,他のソフトウェア・パッケージで必要とされる (または使用される) タイムゾーン・ルールや TDF は,構成される場合も,構成されない場合もあります。以下のコマンド・プロシージャを直接起動しないようにしてください。

  • SYS$MANAGER:UTC$CONFIGURE_TDF.COM ! 直接使用しないこと

  • SYS$MANAGER:UTC$TIMEZONE_SETUP.COM ! 直接使用しないこと

TCP/IP Services V5.0 以降では,OpenVMS TDF,UTC,およびタイムゾーン・サポートが使用されます。それより前のバージョンでは,TCP/IP Services パッケージの内部にある TDF メカニズムおよびタイムゾーン・データベースが使用されます。また,以前のバージョンでは,OpenVMS で TDF を構成することに加えて,TCP/IP Services の内部でも TDF を手動で構成する必要があります。

V7.3 以降の DECnet-Plus では,OpenVMS TDF,UTC,およびタイムゾーンのサポートが使用され,タイムゾーン・プロンプトは UTC$TIME_SETUP.COM を使用して表示されます。 V7.3 より前のバージョンでは,TDF メカニズム,タイムゾーン・データベース,および自動切り換え (DECnet-Plus パッケージの内部) が使用されます。また,V7.3 より前のバージョンでは,OpenVMS で TDF を構成することに加えて,DECnet-Plus DECdtss パッケージの内部でも TDF を構成する必要があります。

HP C (以前は Compaq C,その前は DEC C と呼ばれていました) を使用しているアプリケーションでは,OpenVMS V7.0 以降で C コードがコンパイルされる場合 (およびマクロ _VMS_V6_SOURCE が定義されていない場合), OpenVMS UTC および TDF メカニズムが使用されます。 V7.0 より前のバージョンの OpenVMS で C コードがコンパイルされる場合や,プリプロセッサ宣言 _VMS_V6_SOURCE が宣言されている場合には,HP C は OpenVMS UTC おおび TDF を使用しません。

OpenVMS Alpha V6 リリース (V6.1,V6.2,V6.2-1Hx など) では, TDF の値は SYS$BASE_IMAGE.EXE に書き込まれます。 OpenVMS Alpha V7.0 以降,および OpenVMS VAX V6.0 以降では,TDF は SYS$SYSTEM:SYS$TIMEZONE.DAT に格納されます。 つまり,V7.0 より前のバージョンの OpenVMS Alpha システムでリブートする場合は,通常,SYSTARTUP_VMS.COM の内部で,TDF の値を手動でリセットする必要があります。

OpenVMS のブート時に,SYSINIT モジュールは SYS$TIMEZONE.DAT を読み取って TDF を取得し,システム・グローバル・セル EXE$GQ_TDF で使用します。 この操作が行われるのは,有効な TDF (0 の可能性がある値) を使用してシステムが確実にブートされるようにするためです。 UTC システム・サービスはこのセルから TDF を取得します。これらのサービス,および HP C RTL には有効な TDF が必要です。 OpenVMS V7.3 より前のバージョンでは, DECnet-Plus または DECnet/VAX Extensions が構成され,実行されている場合,イメージ DTSS$SET_TIMEZONE.EXE が起動され,SYSINIT または UTC$TIME_SETUP.COM から TDF およびタイムゾーン・ルールの設定を変更することができます。 このイメージは,DTSS が無効に設定されている場合でも実行されます。 UTC$TIME_SETUP.COM および NET$CONFIGURE.COM に指定されているタイムゾーン設定が矛盾するために,設定が一致しない場合は,定義が一致するように,DTSS が値を再設定します。

OpenVMS V7.3 より前のバージョンでは,夏時間の切り換えは, DCE DTS または DECnet-Plus DTSS が使用されている場合にだけ,自動的に処理されます。 V7.3 では,自動的に夏時間に切り換えられるように OpenVMS を構成することができ,アプリケーションで標準時間と夏時間の切り換えを検出するために使用できるイベントが生成されます。

夏時間と標準時間の手動切り換えは, SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM コマンド・プロシージャを使用して適切に行うことができます。

注意

NTP (単独) では,自動的な切り換えは行われません

注意

DST の切り換えでは,時刻値はドリフトされません。切り換えでは時差全体が 1 つのまとまりとして適用されますが,これは標準的で期待される動作です。 (お使いの環境で1時間の変更が TC を使用することを検討してください。)

TDF や DST の設定を切り換える場合は,時刻の設定が重要なアプリケーション (V7.3 以降のバージョンで, TDF (Time Differential Factor) の変更イベントを使用しないアプリケーション) の再起動や再構成も必要になることがあります。このようなアプリケーションの例として, NFS クライアントと NTP は再起動が必要です。 (この場合 NTP は時刻を「ドリフト」しようとしますが ( 第 3.2 節 および 第 3.3.3 項 を参照),夏時間の切り換えの時期があまりに大きな値であるため,「ドリフト」できないと判断します。したがって,NTP は再起動されます。)

3.4.1 タイムゾーン定義の作成/アップデート/管理

OpenVMS における UTC の実装に関する問題点として, SYS$TIMEZONE_RULE を使用する C 関数あるいはその他のプログラムの動作があります。 OpenVMS のこのメカニズムは,タイムゾーンおよび夏時間の切り換えのすべての制御を担います。これにより,C ライブラリおよびさまざまなアプリケーションによる時間の計算が可能になります。

ただしこれは, DST あるいは TDF の設定に手動で変更が必要なシステムあるいはアプリケーション,あるいは,ローカルのまたはカスタマイズしたタイムゾーン定義が必要なシステムあるいはアプリケーションとは互換性がありません。このようなサイトで確実な時間管理を行うには, SYS$TIMEZONE_RULE で指示された場合にローカル時間と TDF を設定するための手順を用意しておかなければなりません。

シフト変更の調整や,ローカルあるいは地域のタイムゾーン・ルールの変更などのために,非標準の時間切り換えが必要なサイトでは, zic コンパイラを使用してカスタム・タイムゾーン・ルールを作成する必要があります。

さらに,時間の変更を行う前にアプリケーション側で特別な動作を実行させる必要があるかもしれません。アプリケーションのソースコードが入手できる場合は, OpenVMS の sys$set_system_event システム・サービスで提供される TDF および時間変更通知イベントによってこの処理を扱うのが最適な方法の 1 つです。

OpenVMS のタイムゾーン・データベースを管理するための ZIC および関連ツールの詳細については,『HP C ランタイム・ライブラリ・リファレンス・マニュアル』を参照してください。このドキュメントは,HP C のドキュメント・セットではなく OpenVMS ドキュメント・セットに含まれています。

詳細は 第 3.4.1.1 項 を参照してください。


目次 索引

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