[ 前のページ ] [ 次のページ ] [ 目次 ] [ DOC Home ]
本章では，今回のリリースの機能と日本語TCP/IP Services for OvenVMS V5.0の概要について説明します。
本節では，日本語TCP/IP ServicesのV5.0からV5.0Aへのバージョンアップに伴う変更点について説明します。
管理制御プログラム・コマンドのPINGとLOOPで変更が行われています。 TCP/IP Services V5.0Ａでは，この2つのコマンドが次の修飾子を受け付けるようになっています。
TCPIP管理インタフェースのヘルプ・ファイルもアップデートされ，これらの変更点が反映されています。PING コマンドに関する情報を表示するには， 管理制御プログラム・コマンドを次のように入力します。
TCPIP> HELP PING
/TIMEOUT修飾子はサポートされなくなり，管理制御プログラム・コマンドから削除されていることに注意してください。
TCP/IP Services V5.0からTCP/IP Services V5.0Aへのバージョンアップに伴い， リリース・ノートは次を含むいくつかの点で改訂されています。
本節では，TCP/IP Services V5.0の機能について説明します。
本章の残りの部分では，日本語DIGITAL TCP/IP Services for OvenVMS V5.0製品が提供する新機能やその他の変更点を説明しています。
TCP/IP Services V5.0の新機能には，以下のものがあります。
TCP/IP Services V5.0では，広く普及し，機能が実証済みのDIGITAL UNIX V4.0Dから移植されたIPv4カーネルが搭載されています。[1]このカーネルでは， クラスレス・インタードメイン経路選択(CIDR)，パスMTU ディスカバリ，最適化されたTCP/IPスタックなど，パフォーマンス上の拡張がいくつか行われています。
インターネット・メモリ・バッファ(MBUF)は，これまでクラスタと呼ばれていた大きな非ページング・ プールから割り当てられます。すべてのMBUF は512バイトで，つねに512バイト境界上に存在します。これにより，この製品の前のバージョンのように大小さまざまなMBUF を割り当てる必要がなくなりました。 クォータやその他の制約は適用されなくなりました。
MBUFの中で割り当てられないデータ構造は，OpenVMSの非ページング・プールから直接割り当てられます。
統計情報を表示する管理制御プログラム・コマンドも，これに応じて変更されています( 表 1-2を参照してください)。
[1]このカーネルは，Berkeley Software Distribution (BSD) V4.3とV4.4をベースに，弊社が機能を拡張したものです。
TCP/IP Services製品は，ROUTEDによる動的経路選択に代わる手段として， ゲートウェイ経路選択デーモンGATED(ゲート・ディーと発音します) を実装しています。弊社の実装になるこのGATEDは，Cornell University のGatedaemon ProjectのGATED Release 3.5に基づいて開発されています。
GATEDは，内部と外部の両方のゲートウェイ・プロトコルをサポートしている点で，ROUTED と異なります。GATEDは複数の経路選択プロトコルから情報を取得し， この情報に基づいて最適な経路を選択します(ROUTEDは経路選択情報プロトコル(RIP) のみを使用して通信を行い，小規模から中規模のネットワークに適しています) 。
これらのプロトコルは，ゲートウェイ経路選択デーモンの起動時に読み込まれるTCPIP$GATED.CONF という1つのファイル中でコンフィギュレーションが行われます。GATED を起動した後には，コンフィギュレーション・ファイルを編集し，GATED を停止して再起動することによって，コンフィギュレーションを変更することができます。
GATEDは以下のプロトコルをサポートしています。
RIPは広く普及している内部プロトコルで，最小のメトリック(ホップ・ カウント)を持つ経路を最適な経路として選択します。
内部経路選択プロトコルであるOSPFは，リンク状態プロトコル(最短経路が優先される) であり，多数のルータが含まれている複雑なネットワークではRIP よりも適しています。
EGPは自律的なシステム間で到達可能性に関する情報を交換します。自律的なシステムとは， 通常は同じ管理下にあり，内部ゲートウェイ・ プロトコルと共通のメトリックを使ってパケットの経路選択を行っているルータのセットとして定義されます。 自律的なシステムは外部経路選択プロトコルを使用して， 他の自律的なシステムへのパケットの経路選択を行います。
EGPと同様に，BGPは自律的なシステム間で到達可能性に関する情報を交換しますが， 非階層的なトポロジをサポートしている点が異なります。BGP はパス属性を使用して，各経路についてより詳しい情報を提供します。 パス属性には，政治上，組織上またはセキュリティ上の理由に基づく管理者の優先設定などを含めることができます。
このプロトコルは，ホストに対して，パケットの送信先のホストの利用可能性を通知するために使用され， 静的にコンフィギュレーションされた省略時のルータの補助手段として使用されます。
GATEDプロトコルとコンフィギュレーションについての詳細は，『DIGITAL TCP/IP Services for OpenVMS Management』を参照してください。GATEDに関する既知の問題のリストについては， 次のGateD Consortiumホーム・ページを参照してください。
http://www.gated.org/gated-web/support/index.html
TCP/IP Services V5.0では，以下の管理制御プログラム・コマンドが新たに追加されています。 これらのコマンドはTCPIP>プロンプトで入力します。 詳しい説明については，『DIGITAL TCP/IP Command Reference』を参照するか，TCPIP> プロンプトでHELP commandと入力してください。
UNIXネットワーク・サブシステムの管理の経験があるシステム管理者のために，UNIX 管理ユーティリティのサポートが追加されました。以下に示すユーティリティをTCPIP> プロンプトから使用することができます。
| UNIXユーティリティ | 機能 |
|---|---|
| <tt>ifconfig</tt> | ネットワーク・インタフェース・ パラメータのコンフィギュレーションまたは表示，特定のインタフェースのアドレスの再定義， 別名(エイリアス名)リスト，ブロードキャスト・ アドレス，またはアクセス・フィルタなどのオプションを設定します。 |
| <tt>netstat</tt> | ソケット，データ・リンク・カウンタ，指定されたプロトコルまたは別名， ネットワーク・インタフェース，およびホストの経路選択テーブルのネットワーク統計情報を表示します。 |
| <tt>sysconfig</tt> | ネットワーク・ サブシステム属性を表示および保守します。 |
| <tt>route</tt> | 経路選択テーブルを手動で操作することができます。 |
| <tt>arp</tt> | ARPテーブルを制御し，表示します。 |
これらのコマンドを使用するためにはCMKRNL特権が必要です。
有効なコマンド・フラグや他のオプションについては，UNIXのマニュアル・ リファレンス・ページを参照してください。
表 1-1にリストされているコマンドは， 外部コマンドとして定義すれば，DCL プロンプトから実行することもできます。 コマンドの定義は，コマンド・プロシージャのTCPIP$DEFINE_COMMANDSで行います。 このプロシージャでは，リストされている以外のUNIXコマンドも定義できます。 コマンド・プロシージャを実行するには，次のように入力します。
$ @SYS$MANAGER:TCPIP$DEFINE_COMMANDS
$ netstat "-I"
TCP/IP Services V5.0では，Internet Software Consortium (ISC)のBIND 8.1.2に基づく新しいBINDが実装されています。
BIND 8.1.2は以下の機能を提供します。
TCP/IP Services V5.0では，BINDネーム・サーバのコンフィギュレーション方法が大きく変更されています。
古いコンフィギュレーションを使用したい場合には，次のコマンドを使用して， 古いネーム・サーバ・コンフィギュレーションを新しいBIND 8.1.2 の書式に変換する必要があります。
TCPIP> CONVERT /CONFIGURATION BIND
このコマンドは，ASCIIコンフィギュレーション・ファイルTCPIP$BIND.CONF を作成します。ネーム・サーバ・コンフィギュレーションを変更するには， 以下のいずれかの方法を使用します。
SETコマンドを使用する場合には，CONVERT/CONFIGURATION BINDコマンドを使用して， データベースを新しいBIND 8.1.2の書式に変換する必要があります。SHOW CONFIGURATION BIND コマンドを入力すると， コンフィギュレーションの変更点が表示されます。ただし，CONVERT /CONFIGURATION BINDコマンドを使ってコンフィギュレーション情報を変更していないと，BIND には変更点が反映されません。
また，自己ドキュメント型のコマンド・プロシージャSYS$MANAGER: TCPIP$BINDSETUP.COMを使っても，BIND 8.1.2環境をセットアップすることができます。 このコマンド・プロシージャはASCIIコンフィギュレーション・ ファイルTCPIP$BIND.CONFを変更します。以前のリリースでは， コマンド・プロシージャUCX$BINDSETUP.COMはコンフィギュレーション・ データベースUCX$CONFIGURATION.DATに変更を加えていました。この変更に注意してください。
TCP/IP Services V5.0については，BINDリゾルバの省略時の動作が変更されています。 これまで，BINDリゾルバは省略時のドメインと，2つ以上のラベルを持つ親ドメインから構成される検索リストを持っていました。 現在， 省略時の検索リストは省略時のドメインしか含んでいません。また， 以前の動作では，リゾルバは最後のステップとして，実際に入力された情報をもとに検索を行っていました。 現在，リゾルバは，入力に1つ以上のドットが含まれていれば， これを最初に検索します。ドットがなければ( ホスト名だけの場合など)，リゾルバは検索リストの要素をこれに追加して， 最後のステップとして検索を行います。
たとえば，TCPIP SHOW HOST FREDと入力し，検索リストが定義されていなかった場合，
リゾルバは省略時には以下のように検索を行います(
検索の際にFREDが見つからず，省略時のドメインが
parrot.birds.comだったとします)。
V4.xの方式:
fred.parrot.birds.com
fred.birds.com
fred.com
V5.0の方式:
fred.parrot.birds.com
fred (only tried first here if at least one dot is present)
TCPIP$CONFIG.COMを使ってUCXからTCP/IP Servicesへの移行を行った場合には， ドメイン検索リストが自動的に作成されます。この移行では，省略時のドメインが検索され， 親ドメインを網羅したリストが作成されます。 たとえば，省略時のドメインがDAISY.DUCK.BIRDS.COMだった場合，検索リストはDAISY.DUCK.BIRDS.COM ，DUCK.BIRDS.COM，BIRDS.COMとなります。 検索リストはSET CONFIGURATION NAME_SERVICE /PATHコマンドで変更できます。 この新しいコマンドの詳細は，『DIGITAL TCP/IP Services for OpenVMS Management Command Reference』を参照してください。
TCP/IP Services V5.0では，クラスタ・メンバ間で負荷を分散させるための， コンフィギュレーション可能な計算方式のロード・バランシング・メカニズムが採用されています。 この方式は，すべてのクラスタ・メンバの負荷を考慮に入れるという点で， ラウンドロビン・スケジューリング( ネーム・サーバが使用する省略時の方式)とは異なります。この方式では， ロード・ブローカと呼ばれるソフトウェアがクラスタ・ メンバをポーリングし，指定されたネーム・サーバに動的更新要求を送ることでネームスペースを更新します。
新しいロード・ブローカのコンフィギュレーションについての詳細は， 『DIGITAL TCP/IP Services for OpenVMS Management』を参照してください。
TCP/IP Services V5.0では，Competitive Automation社のJOINソフトウェア製品に基づく新しいDynamic Host Configuration Protocol (DHCP) が実装されています。
DHCPは，IPアドレス空間のコンフィギュレーションと保守を集中的に行うためのアプローチを提供します。 これにより，システム管理者は，ネットワーク上のさまざまなクライアントのコンフィギュレーションを1 箇所にいながら集中的に行うことができます。
DHCPサーバは，アドレスのプールから，ネットワーク上のクライアント・ ホストに一時的または永久的なIPアドレスを割り当てます。また，サーバは，DHCP クライアントとして実行されている各ホストについて，省略時のゲートウェイ・ パラメータ，ドメイン・ネーム・サーバ・パラメータ，サブネット・ マスクなどのクライアント・パラメータのコンフィギュレーションを行うことができます。
DHCPは以下の機能によってネットワーク管理を支援します。
DHCPプロトコルはBOOTPプロトコルのスーパーセットです。DHCP は，BOOTPの機能に加えて，IPアドレス，サブネット・マスク，省略時のゲートウェイなどを含む堅牢なコンフィギュレーション・ サービスを提供します。
前バージョンのTCP/IP ServicesはBOOTP専用の機能しか提供していませんでした。TCP/IP Services V5.0 には，本製品の前のバージョンに含まれていたBOOTP サーバに基づくBOOTP専用サーバも含まれています。
ユーザは，以前のBOOTP専用に実装された機能と，新しいDHCPサーバとして実装された機能のどちらを使用するかを決定しなければなりません。
ホストをDHCPサーバとしてコンフィギュレーションする方法については， 『DIGITAL TCP/IP Services for OpenVMS Management』を参照してください。
TCP/IP Services V5.0には，xNTP V3に基づいて実装された新しいNetwork Time Protocol(NTP)が採用されています。V3はV1およびV2のサーバとの互換性を持っています。 たとえば，日本語DIGITAL TCP/IP Services for OpenVMS V4.2を実行しているホストは，日本語DIGITAL TCP/IP Services for OpenVMS V5.0を実行しているホストと同期することができます。
NTPは起動時にファイルTCPIP$NTP.CONFを読み込んで，同期のソースと動作モードを決定します。 本リリースに付属するユーティリティ・プログラムを使うと， 実行時に変更を加えることができます。本バージョンの主な機能を以下に示します。
標準の問い合わせプログラムTCPIP$NTPQは，NTPサーバに対して現在の状態を問い合わせ， その状態への変更を要求します。
特殊な問い合わせプログラムNTPDCは，詳細な状態および統計情報を提供し， 実行時にコンフィギュレーション・オプションを設定するために使用することができます。 このプログラムは対話モードで実行するか， コマンド行引数を指定して実行します。
参加するサーバは，メッセージの認証に使用されるキー識別について同意しなければなりません。 キーとそれに関連する情報はキー・ファイルの中で指定されます。
TCPIP$NTPDATEは，指定されたサーバをポーリングすることで，ローカルな日付と時刻を設定します。 精度は，サーバの数，実行されるたびに作成されるポールの数と実行間隔に依存します。
NTPDATEは，手動で実行することもできますが，ホスト・スタートアップ・ スクリプトから実行することで，NTPが起動する前のブート時にクロックを設定することもできます。NTPDATE は，同じホスト上でNTPがすでに実行されていると， 日付の設定を行いません。
トレース・ユーティリティTCPIP$NTPTRACEは，NTPサーバのチェーンをたどって， マスタ・タイム・ソースまで遡ります。
NTPのコンフィギュレーションと管理についての詳細は，『DIGITAL TCP/IP Services for OpenVMS Management』を参照してください。
TCP/IP Services V5.0では，コミュニティ・ベースの簡易ネットワーク管理プロトコルを実装しています。 これは，以前はSNMPv2c(また一般にはSNMPv2) と呼ばれていたもので，RFC 1901〜1908に記述されています。 SNMPv2は，単純な暗号化されていないコミュニティ名に基づいて認証を行う， 古いSNMPv1のコミュニティ・ベースのセキュリティの概念に依存しています。
SNMPv2には，ネットワークのSNMPトラフィックのオーバーヘッドを軽減し， プロトコルをより広範囲のサーバとクライアントの要件に対応させ， パフォーマンス向上をもたらす改善事項が含まれています。
GetBulk要求により，大量のデータを取得することができます。
管理ステーションは，複数のGetNext要求を発行する代わりに，1
回のGetBulk要求で管理情報ベース(MIB)
の内容(経路選択テーブルなど)の全体または一部を取得することができます。
TCP/IP Servicesに実装されたSNMPv2の主な機能を以下に示します。
hrFSTable ; RFC 1514)が，OpenVMSに適用可能な部分で実装されています。
snmp_
request。新しいGetBulk要求機能と，標準のmibwalk
プログラムをエミュレートするオプションがあります。
sysORTableが実装されています。
SNMPのファイル，プログラミング，論理名およびコンフィギュレーションについての詳細は， 『DIGITAL TCP/IP Services for OpenVMS Management』を参照してください。
FTPは，長いファイル名と拡張された深いディレクトリ階層を含むExtended File Specifications をサポートします(このOpenVMS機能の詳細については， 『OpenVMS V7.2 Extended File Specificationsの手引き』を参照してください) 。
長いファイル名のサポートは，FTPサーバでは自動的に使用可能に設定され， 使用不能にすることはできません。通常，長いファイル名をサポートするためには，SYLOGIN.COM またはLOGIN.COMファイルに，ユーザごとに1 行を追加しなければならないので，このFTPサーバの動作は予測しにくいかもしれません。 長いファイル名のサポート機能を必要としない場合には，ODS-2 のファイル名をそのまま使い続けることができます。
OpenVMS V7.1では，FTPのCOPYおよびDIRECTORYコマンドは大文字のファイル名を使用しても期待どおりに動作します。OpenVMS V7.2 あるいはそれ以降のバージョンでは， 小文字のファイル名を使用する必要があります。
OpenVMS外部認証(『OpenVMS Version 7.2 Guide to System Security』を参照) をサポートしているのはFTPおよびREXEC機能だけです。これまで， パスワードを変更したユーザが，その新しいパスワードをFTPまたはREXEC で使用するためには，OpenVMSシステムにログインする必要がありました。
OpenVMS外部認証サポートを使用する場合には，以下の点が変更されます。
TELNETポート・ドライバ(TNDRIVER)は，RAW，NVT，RLOGINおよびTELNETの各プロトコルを使用して，TCP/IP ストリーム接続のターミナル・セッション・ サポートを提供します。接続のリモート側にはリモート・デバイスとアプリケーションのどちらが存在していてもかまいません。
ユーザ・プログラムは，IO$_TTY_PORTおよびIO$_TTY_PORT_BUFIO機能コードを使用して， 標準のOpenVMS $QIOシステム・サービスを通してTELNET 接続を管理することができます。第4章では， これらの機能コードとその引数について説明しています。
TCP/IP Services V5.0では，製品のエラー・メッセージが次のように拡張されています。
TCP/IP Services V5.0では，OpenVMSの集中化されたHelp Messageユーティリティ(MSGHLP) を通して，多数のTCP/IP Servicesメッセージに関する情報をオンラインで表示することができます。
ターミナル上でエラーを引き起こすコマンドを入力したりイメージを実行した場合，HELP/MESSAGE コマンドを入力すると，Help Messageは$STATUS に格納されている値を変換し，これを表示します。
たとえば，DCLコマンドSHOWに対して無効なキーワードを入力すると，エラー・ メッセージが表示されます。コマンドHELP/MESSAGEを発行すると， メッセージに関してさらに詳しい情報を見ることができます。
$ TCPIP SET HOST MOLLY
%TCPIP-E-HOSTERROR, cannot process host request
-TCPIP-E-INSKEY, insufficient information
$ HELP/MESSAGE INSKEY
INSKEY, insufficient information
Facility: TCPIP, Management Control Program
Explanation: You attempted to enter a record into a database, but
you did not specify enough information.
User Action: Reenter the command with the necessary qualifiers.
Help Messageでは以下の操作も行えます。
TCP/IP Services V5.0は，ソケット・プログラミング・インタフェース(V4.3 およびV4.4 BSD)を実装しています。4.4 BSDインタフェースにアクセスするには，_SOCKADDR_LEN オプションを使用します。
ソケットAPIについての詳細は，『DIGITAL TCP/IP Services for OpenVMS System Services and C Socket Programming』を参照してください。
本節では，TCP/IP Services V4.2からV5.0へのバージョンアップ時に行われたいくつかの変更点について説明します。
TCP/IP Services V5.0の変更点には，以下のものがあります。
過去のリリースで，製品名を"ULTRIX Connection (UCX)"から"DIGITAL TCP/IP Services for OpenVMS"に変更することにより始まった一連の変更は，TCP/IP Services V5.0 で完了しました。
この変更に伴い，以下に関連する記述で，"UCX"という識別子が"TCPIP"に書き換えられています。
TCP/IP Services V5.0は，すべてのUCX論理名で後方互換性を保っており， 大部分のUCX管理コマンドをサポートしています。
現時点では，UCX名に依存しているアプリケーションやコマンド・プロシージャをアップグレードする必要はありません。 たとえば，論理名UCX$DEVICE は現在でも使用できます。ただし，古い命名規則が今後のリリースでもサポートされるかどうかは保証されませんので， できるだけ早い時期に新しい命名規則( たとえば，TCPIP$DEVICE)に移行することを推奨します。
以下の各項では，TCP/IP Services for OpenVMSのインストレーションに関係する大きな変更点について説明します。
VAXシステムへの製品のインストレーションにVMSINSTALプロシージャは使用できなくなりました。 現在では，AlphaシステムとVAXシステムの両方で，POLYCENTER Software Installation ユーティリティ(PCSI)が使用されます。
TCP/IP Services製品の配布メディアとして使われていたTK50テープ・カセットや磁気テープは，V5.0 以降のリリースでは使用されなくなります。
ライセンス管理機能(LMF)の製品登録キー(PAK)は，変更の必要がありません。TCP/IP Services V5.0 でもそのまま使用できます。
TCP/IP Services V5.0では，システム・サービスSYS$GETUTC()を使用して， オペレーティング・システムが使用している標準時間帯の時差情報を探します。TCPIP$CONFIG は，この方法で標準時間帯情報を自動的に検証します。 ユーザからの入力は必要ありません。
前リリースでは，スタートアップ・プロシージャは出力論理名MCC_TDFを設定し， 論理名UCX$TZ，UCX$NTP_TZおよびUCX$TDFを使って標準時間帯情報を設定していました。V5.0 リリースでは，これらに対応する論理名は存在しません。TCPIP$STARTUP.COM はMCC_TDF論理名を設定しなくなっています。
システム上で協定世界時(UTC)のコンフィギュレーションが行われていないと，TCP/IP Services アプリケーションは不正確な時刻を報告することがあります。UTC 情報の設定と表示の方法については，OpenVMSのシステム管理のマニュアルで説明しています。
SET CONFIGURATIONおよびSHOW CONFIGURATION TIMEコマンドは(コマンド・ ファイルとの互換性のために)現在でも使用できますが，TCP/IP Services製品はこれらのコマンドが設定，表示する値を使用しなくなっています。 これらのコマンドは，本製品の将来のバージョンでは削除される可能性があります。TCPIP$CONFIG.COM のTIMEZONEエントリも，前のバージョンのTCP/IP Services 製品との互換性のために残されています。
管理制御プログラムは，TCP/IP Services環境を管理するためのコマンド行インタフェースを提供します。DCL コマンドのTCPIPを入力して，管理制御プログラムの実行環境に入り， コマンド行から必要な管理制御プログラム・ コマンドを入力します。
TCP/IP Services V5.0では，表 1-2に示す管理コマンドとコマンド修飾子の組み合わせが廃止されています( 関連するSET CONFIGURATION およびSHOWコマンドも同じように廃止されています)。
| コマンド | 説明 |
|---|---|
| BIND, SHOW BIND, UNBIND | これらのコマンドの代わりにMAP ，SHOW MAP，およびUNMAPコマンドが使用されます。 |
| PING/TIMEOUT | 新しいカーネルには適用されません。 |
| SET COMMUNICATION /ALLOW_LOG_OPTIONS | 新しいカーネルには適用されません。 |
| SET COMMUNICATION /DEVICE_SOCKETS | 新しいカーネルには適用されません。 |
| SET COMMUNICATION /FORCE_LOG_OPTIONS | 新しいカーネルには適用されません。 |
| SET COMMUNICATION /INTERFACES | 新しいカーネルには適用されません。 |
| SET COMMUNICATION /IRP | V5.0の新しいメモリ管理方式により，インターネットI/O 要求パケット(IRP)のためのクォータを設定する必要がなくなっています。 |
| SET COMMUNICATION /LARGE_BUFFERS | V5.0の新しいメモリ管理方式により， 静的および動的バッファを割り当てる必要がなくなっています。 現在は1つのサイズ(512バイト)のメモリ・バッファしか存在しません。 |
| SET COMMUNICATION /NON_UCX_ BUFFERS | OpenVMS非ページング・プール空きリストで非UCX バッファが指定されることはなくなりました。 |
| SET COMMUNICATION /REMOTE_TERMINAL=LARGE_BUFFER | 不要になりました。現在は1つのサイズ(512バイト) のメモリ・バッファしか存在しません。 |
| SET COMMUNICATION /REMOTE_TERMINAL=UCB | 新しいカーネルには適用されません。 |
| SET COMMUNICATION /REMOTE_TERMINAL=VIRTUAL | 新しいカーネルには適用されません。 詳細については，第1.3.9.2項を参照してください。 |
| SET COMMUNICATION /SERVICE | 新しいカーネルには適用されません。 |
| SET COMMUNICATION /ROUTES | 新しいカーネルには適用されません。 |
| SET COMMUNICATION /SMALL_BUFFERS | V5.0の新しいメモリ管理のために，静的および動的バッファを割り当てる必要がなくなっています。 現在は1つのサイズ(512バイト)のメモリ・バッファしか存在しません。 |
| SET COMMUNICATION /TYPE | V5.0の新しいメモリ管理方式により，大きなバッファ・ タイプを指定する必要がなくなっています。 |
| SET CONFIGURATION COMMUNICATION /ALLOW_LOG | |
| SET CONFIGURATION COMMUNICATION /FORCE_LOG | |
| SET CONFIGURATION COMMUNICATION /SERVICE | |
| SET PROTOCOL ARP /CACHE | 新しいカーネルには適用されません。 |
| SET PROTOCOL ARP /COMPLETE_TIMER | 新しいカーネルには適用されません。 |
| SET PROTOCOL ARP /INCOMPLETE_TIMER | 新しいカーネルには適用されません。 |
| SET PROTOCOL ICMP/UNREACHABLE | 新しいカーネルには適用されません。 |
| SET PROTOCOL IP /CHECKSUM | 新しいカーネルには適用されません。 |
| SET PROTOCOL RAW_IP /QUOTA | 新しいカーネルには適用されません。 |
| SET PROTOCOL TCP /CHECKSUM | 新しいカーネルには適用されません。 |
| SET PROTOCOL TCP /LOOPBACK | 新しいカーネルには適用されません。 |
| SET PROTOCOL TCP /PUSH | 新しいカーネルには適用されません。 |
| SET PROTOCOL UDP /BROADCAST | 新しいカーネルには適用されません。 |
| SET PROTOCOL UDP /CHECKSUM | 新しいカーネルには適用されません。 |
| SHOW INTERFACE /CONTINUOUS | 新しいカーネルには適用されません。 |
| SHOW PROTOCOL/CONTINUOUS | 新しいカーネルには適用されません。 |
| ZERO INTERFACE /COUNTERS | 新しいカーネルではカーネル・ カウンタのゼロへの設定はサポートされていません。 |
一部の管理コマンドは，これまでのOpenVMSの表示ではなく，UNIX形式の表示を出力するようになっています。 たとえば，前のバージョンでは，コマンドSHOW PROTOCOL UDP は次のような表示を出力していました。
UCX> SHOW PROTOCOL UDP
UDP
Bad header checksums: 6
Incomplete headers: 0
Bad data length fields: 0
Socket buffer drops: 0
Unknown broadcast port drops: 9881
Total received datagrams: 233066
Dropped: 0
TCP/IP Services V5.0では，同じコマンドが次の表示を出力します。
TCPIP> SHOW PROTOCOL UDP
udp:
12272 packets sent
1126540 packets received
0 incomplete headers
0 bad data length fields
0 bad checksums
0 full sockets
1114425 for no port (1114399 broadcasts, 0 multicasts)
0 input packets missed pcb cache
TCP/IP Services V5.0では，一部の管理コマンドがUNIX形式の表示を出力するようになったため， コマンド出力を解析するユーザ作成のコマンド・ プロシージャは正常に動作しない場合があります。
たとえば，前のバージョンのTCP/IP Servicesソフトウェアでは，PINGコマンドを実行すると" host alive"というメッセージが返されましたが，UNIX 形式の表示を実装したTCP/IP Services V5.0では，別の形式のメッセージが表示されます。
以降の各節では，スタートアップ・プロシージャの変更について説明します。
サーバ構成要素の起動のために呼び出されるファイルの位置と名前が， TCPIP$SYSTEM:TCPIP$component_name_RUN.COMに変更されました。 たとえば，TFTPのスタートアップ・ファイルはTCPIP$SYSTEM:TCPIP$TFTP_ RUN.COMです。
TCPIP$STARTUP.COMプロシージャがSYSGENパラメータSTARTUP_P1の値をチェックするようになりました。 これがMIN，UPGRADEまたはINSTだった場合， プロシージャはメッセージを出力し，$SEVERITYをFATALに設定してただちに終了します。
MINブートの場合のメッセージは次のとおりです。
%TCPIP-F-NONETSTART, Network not started due to MIN boot
この動作により，TCPIP$STARTUP.COMプロシージャがOpenVMSの正しい動作に必要な部分が存在しないことを検出した場合に，TCP/IP Services が起動しなくなります。
通常，STARTUP_P1は空白になっています。この場合，TCPIP$STARTUP.COM はTCP/IPソフトウェアを初期化します。
以下に，TCP/IP Services V5.0で行われたNFSサーバの変更点を示します。
VAXシステムでは，サーバはこれまでもOPCOMにメッセージを送信していました。 現在は，どちらのアーキテクチャでも一貫性のある動作になっています。
COPYなどの一部のOpenVMSユーティリティは，ファイルの作成を終える前に， 終了時のサイズを知ることができます。これらのユーティリティは， 一般にファイルを最終的なサイズまで拡張してから，割り当てられたブロックにデータをシーケンシャルに書き込んでいきます。 この場合， ファイルが完全に書き込まれ，クローズされるまで，ファイル終わりマークは更新されません。
前のバージョンのNFSサーバは，OpenVMSクライアントが，書き込まれるブロックを収容するのに必要な最小サイズよりも大きいサイズを設定していても， その設定を無視して，つねに書き込んだ最上位バイトにファイル終わりマークを移動していました。 このため，クライアントがファイルにシーケンシャルに書き込みをしている間， サーバは通常書き込みがあるたびに， ファイルを拡張しなければならず，ファイル・ ヘッダを新しいファイル終わりマークで更新しなければなりませんでした。
TCP/IP Services V5.0では，NFSサーバは，OpenVMSクライアント上で実行されているアプリケーションまたはユーティリティが要求し， TCPIP$CFS_KEEP_ALLOCが1に設定されていれば，ファイルを事前に拡張します。OpenVMS クライアントでは，クライアント・アプリケーションがファイルを事前に拡張している場合， サーバは，明示的な要求があるまでファイル終わりマークを更新しません。 この新しい動作により， 事前に拡張されるファイルのパフォーマンスが大幅に改善されます。
OpenVMSクライアントは，つねに割り当てられたサイズを使用された サイズと等しい値として報告することに注意してください。このため，TCP/IP Services V5.0 サーバでは，DIRECTORY /SIZE=ALLと指定すると，OpenVMS クライアントはコピーが完了するまで両方のサイズを0 として表示します。
TCPIP$CFS_KEEP_ALLOCが0に設定されている場合，サーバがファイル属性を更新するたびに， 割り当てられたブロックがファイル終わりマークの位置を収容できる以上の大きさになっていると， 余分なブロックが切り捨てられます。TCPIP$CFS_KEEP_ALLOC が1に設定されている場合には， サーバがファイルの割り当てサイズを減らすことはありません。
TCP/IP Services V5.0ではSMTPが以下のように変更されています。
SMTPユーザ名はUCX_SMTPからTCPIP$SMTPに変更されています(他の製品構成要素との一貫性のために， 下線(_)がドル記号($)に置き換えられています) 。
TCP/IP Services V5.0では，LPDキュー名がUCX$LPD_QUEUEからTCPIP$LPD_ TCPIP$LPD_QUEUEに変更されています。
LPDユーザ名はUCX_LPDからTCPIP$LPDに変更されています(他の製品構成要素との整合性をとるために， 下線(_)がドル記号($)に置き換えられています) 。
以下の各項では，TELNETに加えられた変更について説明します。
TCP/IP Services V5.0に含まれているTELNETサーバは，V4.2のシステムからV5.0 のシステムに接続するクライアントに対してライン・モードでのネゴシエーションを行いません。 接続はキャラクタ・モードで行われます。
コマンドSET COMMUNICATION/REMOTE_TERMINAL=VIRTUALは使用できなくなっています。 このコマンドを使用する代わりに，以下の論理名を値TRUEとして定義して， 対応するVTAサポートを使用可能にしてください。
TCP/IP Servicesの前のバージョンでは，TCP/IP Servicesが各ソケット・ コールに対して動的にイベント・フラグを割り当てていたため，同時に操作可能な数に制限がありました。
TCP/IP Services V5.0およびそれ以降のバージョンでは，各ソケットI/O 操作に対して異なるイベント・フラグが割り当てられなくなり，TCP /IP Servicesはイベント・フラグを使用しません。代わりに，各$QIO 操作にEFN$C_ENF (フラグでない)が指定されます。これにより，TCP/IP Services V4.2での制限はもはやなくなりました。1つのプログラムは，別のリソースを使い尽くしてしまうまで， それぞれが異なるソケット・コールを行う異なる数百のスレッドを持つことができます。 イベント・フラグはもはや制限となりません。
FTPクライアントおよびサーバは，TCPIP$STARTUP.COMの実行時に論理名TCPIP$FTP_WNDSIZ を定義しなくなりました。この変更により，FTPはTCP/IP Services V5.0 の大きな省略時のTCPウィンドウ・サイズを利用することができます。
論理名が定義されていると，FTPクライアントおよびサーバは制限付きで( およそ1K〜64K)その値を使用します。
低速の伝送媒体やエラーの多い伝送媒体では，TCPIP$FTP_WNDSIZの値を小さくすると有効なことがあります。
現在の省略値は，VMS_PlusモードではTCP/IP Services V4.2の省略値の約半分， 他の場合には約4倍です。この変更はほとんどのユーザに対しては透過的に処理されます。 ただし，OpenVMSシステムとOpenVMS以外のシステムの間で， 低品質のネットワーク・リンクを使って転送を行うユーザは， TCP/IP Services V5.0にアップグレードした後にパフォーマンスを監視するべきです。
TCP/IP Services V5.0では，FTPにさまざまな変更が加えられています。 これらの変更により，VMS_Plusが使用可能(省略時の設定)になっているOpenVMS ホストと通信する際の整合性の欠落や予期しない動作の発生を抑えられます。 ホストの1つがOpenVMS以外の場合のFTPの動作に影響はありません。
PUTおよびGETコマンドは，OpenVMS間の接続で，ファイルの新しいバージョンを作成するようになりました。
これまで，PUTおよびGETコマンドは，
ファイルの既存のコピーを上書きしていました。たとえば，ローカル・
ファイルa.dat;1が文字列"This is A.DAT"を含んでおり，
リモート・ファイルa.dat;1が文字列"Contents
removed"を含んでいた場合，次のコマンドを実行すると，ローカル・ファイル
a.dat;1は"Contents removed"を含むようになります。
FTP> get a.dat
本製品のこのバージョンで同じコマンドを実行すると，
a.dat;1とa.dat;2という2つのファイルが作成されます。
次のコマンドはエラーを発生させます。
FTP> get a.dat;1
エラーは次のように表示されます。
%TCPIP-E-FTP_OUTPROCF, error processing output file
DEVICE:[DIRECTORY]A.DAT;1
-RMS-E-FEX, file already exists, not superseded
MGETまたはMPUTコマンドの後に*.*を付けるとファイルの最大バージョンだけがコピーされ，*.*.* はバージョンを大から小の順に保存します。この変更は，OpenVMS ホストと，OpenVMS以外のホストの両方に影響を与えます。
これまで，MGETコマンドの後に*.*を付けると，ディレクトリ内のすべてのファイルのすべてのバージョンがコピーされていました。 現在では*.*; と指定した場合と同様に，各ファイルの最大バージョンだけがコピーされます。 また，MGETコマンドの後に*.*.*を付けると，これまではコピー先でファイルの順序が逆転していました。
例として，3つのローカル・ファイルがあったとします。
a.dat;1はテキスト"One"を，a.dat;2はテキスト"Two"
を，a.dat;3はテキスト"Three"を含んでいます。TCP/IP Services V4.2
よりも前のバージョンでは，MPUTコマンドの後に
a.dat;* を付けると，リモート上に３つのファイルが作成され，
最大バージョンのファイルにテキスト"One"を含み，最小バージョンにはテキスト"Three"
を含みます。
TCP/IP Services V5.0では，3つのファイルが作成され，最大バージョンがテキスト"Three" を含んでいます。リモート・サーバが日本語DIGITAL TCP/IP Services for OpenVMS V5.0以上を実行しているOpenVMSシステムである場合には， 新しいバージョンが作成されます(バージョンに重複があった場合には，RMS-E-FEX メッセージが表示されます)。その他の状況では， 依然として既存のバージョンの上書きが起こる可能性があります。
TCP/IP Services V5.0でも疑似インタフェース名はサポートされています。V4. x疑似インタフェース用に定義されているアドレスは， V5.0インタフェース構造体の別名アドレスにマップされます。ただし，疑似インタフェース・ ユニット番号は255以下でなければなりません。
インタフェース名の作成と削除を試みる前に，V5.0とV4.xの両リリースの実装上の違いに注意する必要があります。V4. xでは，IP アドレスとネットワーク・マスクのパラメータに加えて，疑似インタフェースのパラメータの設定と表示を行うことができました。V5.0 では，IPアドレス， ネットワーク・マスク，およびブロードキャスト・マスクのみ設定できます。
V5.0では，すべての疑似インタフェース名が有効なインタフェース名にマップされなければなりません。 これは，これらの疑似インタフェースのアドレスが， 既存のインタフェースの別名アドレスとして実装されているからです。
たとえば，疑似インタフェース名WEA0，WEA1，WEA2，...WEA255が，すべてインタフェース名WE0 にマップされており，インタフェース名WEB0， WEB1，WEB2，...がWE1にマップされている(以下同様)とします。
疑似インタフェースWEA1の作成要求が行われ，既存のWE0が存在する場合，WEA1 のアドレス情報はWE0の別名アドレスとして追加されます。次にSHOW INTERFACE コマンドを実行すると，インタフェース名がそのアドレスとともに表示されます。
しかし，インタフェースWE0が存在せず，WEA1の作成要求が行われた場合には， インタフェースWE0が作成され，WEA1に関連付けられたアドレスが与えられます。 プライマリ・アドレスが存在しないため，別名アドレスとして追加されることはありません。
この場合，SHOW INTERFACEコマンドを入力すると，WE0とWEA1の2つのインタフェースが同じアドレスで表示されます。
インタフェースを削除すると，インタフェースとそのすべての別名アドレスが同時に削除されます。 たとえば，インタフェースWE0を作成し，WEA0 ，WEA1およびWEA2のアドレスを追加した場合，コマンドSET NOINTERFACE WE0 はすべての疑似インタフェース・アドレスを削除するという効果を持ちます。
しかし，たとえばWEA1などの特定の疑似インタフェースを削除した場合には， そのアドレスだけが削除されます。
しかし，削除の結果としてアドレスを持たないインタフェース構造体が生じるような場合には， 問題が生じます。この場合，インタフェースに別名アドレスを割り当てることはできても， そのインタフェースはおそらく動作しなくなります。 アドレスが1つしか残っていない場合には，インタフェース全体を削除する必要があります。
TCP/IP Services製品は，現在も，SET INTERFACEコマンドの/CLUSTER修飾子を使用して，ARP に基づくクラスタ別名の設定をサポートしています。 新しいプロトコル・スタック環境でこれらの別名を処理できるように，拡張された内部ロジックが追加されています。ARP に基づく別名機能は現在も使用可能ですが， その実装の仕方は多少異なっています。
前のバージョンでは，アプリケーションは，関連するホストがクラスタ・ インパーソネータでない場合でも，ソケットをクラスタ別名アドレスにバインドすることができました。 これは予期しない動作を引き起こすことがあるため， 現在では使用できなくなっています。同様に，ユーザが任意の別名参加者からクラスタ別名アドレスへのTCP 接続を開始すると，その接続は， ローカル・ノードがインパーソネータでなかった場合でもローカル・ ノードにループ・バックしていました。本バージョンの製品では，別名IP アドレスをインパーソネータになったときにのみプロトコル・スタック上にコンフィギュレーションすることで， このような混乱が起きるのを防いでいます。