このドキュメントでは、インターネットおよび XML にアクセスするためのステートメントの機能概要、メインフレーム環境でこれらのステートメントを使用するための全般的な前提条件、制限事項、およびその他の参照情報について説明します。 これらのステートメントを最大限に活用するには、通信規格に関する深い知識が必要です。
次のトピックについて説明します。
次の Natural ステートメントを使用して、インターネットおよび XML ドキュメントにアクセスできます。
このステートメントを使用すると、ハイパーテキスト転送プロトコル（HTTP）、および z/OS の場合のみ Hypertext Transfer Protocol Secure（HTTPS）を使用して、与えられた Uniform Resource Identifier（URI）または Uniform Resource Locator（URL）を持つ Web 上のドキュメントにアクセスできます。URI および URL は、Web サイトのインターネットアドレスまたはイントラネットアドレスです。
REQUEST DOCUMENT では HTTP クライアントを Natural ステートメントレベルに実装します。これにより、アプリケーションはイントラネットまたはインターネット上の任意の HTTP サーバーにアクセスできます。 このステートメントにはオペランドのセットがあり、このオペランドを使用してユーザーアプリケーションの要件に沿った
HTTP 要求を作成できます。 例えば、送信オペランドを使用すると、ユーザー定義 HTTP ヘッダー、フォームデータ、またはドキュメント全体を HTTP サーバーに送信できます。 受信オペランドを使用すると、サーバーからドキュメントを取得したり、サーバーから返された
HTTP ヘッダーブロック全体を表示したり、専用のヘッダーの値を戻したりできます。バイナリフォーマットオペランドを使用すると、gif ファイルなどのバイナリオブジェクトを HTTP サーバーと交換できます。 基本認証用として、ユーザー ID やパスワードのオペランドを指定できます。
このオペランドの内容は、HTTP 標準に従って回線上を base64 エンコーディングを使用して送信されます。
Natural では次の要求メソッドがサポートされています。
GET - ドキュメントと HTTP ヘッダーの取得
HEAD - HTTP ヘッダーのみの取得
POST - フォームデータの HTTP サーバーへの転送
PUT - ファイルの HTTP サーバーへの転送
要求メソッドは、通常、実行される REQUEST DOCUMENT ステートメントにコーディングされているオペランドに基づいて、自動的に評価されます。 ただし、あらかじめ設定されている要求メソッドは、要求メソッドヘッダーをユーザーが明示的に指定することによって上書きできます。
REQUEST DOCUMENT ステートメントを使用したデータ転送では、通常、コードページ変換は呼び出されません。 送信データ／受信データを特定のコードページでエンコードする場合は、REQUEST DOCUMENT ステートメントの DATA ALL 節／RETURN PAGE 節を使用して指定できます。
HTTP サーバーを持つ EBCDIC ベースのメインフレームは、ほとんどが UTF-8 または ISO-8859-1 でエンコードされたデータを使用しています。このようなメインフレームとのデータ交換を簡略化するため、このステートメントでは ENCODED 節を使用して、送受信ドキュメントデータを暗黙的または自動的に変換できます。
REQUEST DOCUMENT ステートメントの実装は、主に次の 2 階層で構成されています。
独立したランタイム層。HTTP 処理、URL 解析、データ変換などの一切が実行されます。
環境依存ルーチンが Natural と HTTP サーバーとの TCP/IP 通信を処理する層。 この層は、z/OS、VSE、および VM/CMS の場合は LE（言語環境）ソケットに基づいて、Com-plete および Natural 開発サーバーの場合は SMARTS ソケットに基づいて、BS2000/OSD の場合は CRTE ソケットに基づいて、それぞれ実装されます。 CICS の場合は、適切なソケットライブラリがビルドプロセスに追加されます。
Natural for Mainframes では HTTP プロトコルバージョン 1.0 のみがサポートされています。つまり、サーバーへの固定接続は維持されません。 事実上、すべての企業のネットワークプロセスでは、クライアントからインターネットにアクセスするとき、プロキシサーバーを経由します。このため、Natural は、プロキシサーバーおよびプロキシサーバーの処理対象となるポートに適した設定を使用して構成できるようになっています。 また、プロキシサーバーを経由せずに直接アクセスする、ローカルドメイン名の接尾辞（イントラネットサイト）も指定できます。 「適用可能な Natural パラメータの概要」も参照してください。
プロキシサーバーは、クライアント（ユーザー）とインターネットの間に配置され、クライアントからの要求を受信して宛先サーバーに転送したり、返されたドキュメントをキャッシュしてクライアントに転送したりします。 プロキシサーバーの利点として、キャッシュ処理によってパフォーマンスが向上すること、およびセキュリティの問題の回避に役立つこと（ほとんどのプロキシサーバーがファイアウォールとしても機能する）を挙げることができます。
次の例は、REQUEST DOCUMENT ステートメントを使用して、外部に保管されているドキュメントにアクセスする方法を示しています。
REQUEST DOCUMENT FROM "http://bolsap1:5555/invoke/sap.demo/handle_RFC_XML_POST" WITH USER #User PASSWORD #Password DATA NAME 'XMLData' VALUE #Queryxml NAME 'repServerName' VALUE 'NT2' RETURN PAGE #Resultxml RESPONSE #rc
REQUEST DOCUMENT ステートメントの構文と詳細なアプリケーションヒントについては、『ステートメント』ドキュメントを参照してください。
REQUEST DOCUMENT ステートメントは、次のメインフレームプラットフォームでサポートされます。
z/OS：Batch、TSO、CICS、Com-plete、IMS/TM
z/VSE：Batch、Com-plete、CICS
VM/CMS
BS2000/OSD：Batch、TIAM、openUTM *
* 後述の「openUTM での XML 関連ステートメントのサポートに対する前提条件」も参照してください。
また、このステートメントは Natural でサポートされているすべての OpenSystems プラットフォームで使用できます。
PARSE XML ステートメントを使用すると、Natural プログラム内で XML ドキュメントを解析できるようになります。
PARSE XML ステートメントではフル XML パーサを Natural に統合します。これにより、Natural アプリケーションで XML ドキュメントを解析できるようになり、コンテンツの処理が容易になります。 PARSE XML ステートメントでは処理ループを開き、解析プロセス中にリストのイベントのいずれかが発生するたびに、それぞれのドキュメントのパス、解析された要素の名前と値、およびいくつかのパーサステータスシステム変数を返します。
XML ドキュメント解析の一般的な戦略またはモデルは次のとおりです。
DOM（Document Object Model）。オブジェクト指向アプローチの一種です。
SAX（Simple Access to XML）。ストリーム指向の解析メソッドです。
Natural for Mainframes での PARSE XML ステートメントの実装は SAX メソッドに基づいており、（オープンソース）SAX パーサ EXPAT のバージョン 2.0.0 のメインフレームポートを使用しています。
解析処理は、対象ドキュメントの UTF-16 エンコードイメージに対して内部的に行われます。つまり、配信されたドキュメントのエンコーディングが違う場合は、UTF-16 への変換が内部的に実行されてから解析が開始されます。 例えば、TP 環境のスレッドサイズを評価する場合は、Natural をインストールときにこのことを考慮する必要があります。
解析するドキュメントのエンコーディングは自動的に確認されます。
ドキュメントのエンコーディングを示す BOM（バイトオーダーマーク）が確認されます。
BOM が見つからない場合、ASCII、EBCDIC、または UTF-16（BE または LE、つまりビッグエンディアンまたはリトルエンディアン）が確認されます。
エンコーディングが EBCDIC または ASCII の場合は、エンコーディングの処理命令が検索されます。
エンコーディングが不明の場合は、該当するエラーメッセージが発行され、解析プロセスは終了します。 内部的に、パーサは UTF-16BE で動作するため、解析されるドキュメントは必ずこのエンコーディングに変換されてから EXPAT パーサに渡されます。
エンコーディングが PI（処理命令）の場合は、次のデフォルトが適用されます。
ASCII の場合は、UTF-8 エンコーディングが想定されます。
EBCDIC の場合は、Natural デフォルトコードページ（システム変数 *CODEPAGE を参照）エンコーディングが想定されます。
解析プロセス自体は、2 段階で構成されます。
最初の段階では、コールバックエントリの整形式セットを通知するために、パーサが繰り返し呼び出されます。 その時点で解析中のドキュメントに、これらのエントリに関連する要素が出現するたび、これらのエントリがパーサによって入力されます。 例えば、開始タグが出現することは、対応するエントリへのコールバックをトリガするイベントとなります。 コールバックエントリは、解析プロセスの実行のための Natural ランタイムロジックを公開します。
第 2 段階は、実際の解析プロセスです。 解析するドキュメントを入力オペランドとして、パーサが呼び出されます。 この段階で各要素が解析され、各要素タイプに対応するコールバックルーチンが呼び出されます。 次に、Natural ランタイムでは返された要素を処理し、返されるオペランドを更新し、それらのオペランドを処理するための解析ループに入ります。 その後、パーサが再起動され、解析プロセスが続行されます。 解析プロセスは、ドキュメントの解析が完了したとき、および現在のドキュメントで XML 構文エラーが発生したとき、つまりドキュメントの形式が無効であった場合に完了します。
注意:
技術的な理由により、Natural for Mainframes ではネスト構造の解析ループはサポートされていません。
Natural バージョン 4.2.5 以降、解析対象文字列に空白文字または事前定義された XML エンティティが含まれていた場合に、文字データの解析でブレイクまたはループパスが発生することはありません。 バージョン 4.2.5 より前の Natural で問題になっていましたが、解決されました。 Natural バージョン 4.2.5 では、文字データの解析は Natural for Windows、UNIX、および Linux と互換性があります。
次のサンプルプログラムの出力は、バージョン 4.2.5 とそれより前のバージョンとの違いを示します。
DEFINE DATA LOCAL 1 PAGE (A) DYNAMIC 1 #PATH (A200) 1 #NAME (A) DYNAMIC 1 #VALUE (A40) 1 #CMX (A) DYNAMIC 1 #CMP (A) DYNAMIC END-DEFINE FORMAT PS=60 LS=80 COMPRESS ' A<B ' H'0D0D' ' B<C' INTO #CMX LEAVING NO MOVE ALL #CMX TO #CMP UNTIL 16 COMPRESS '<?xml version="1.0" ?>' '<character-data-sample>' '<string_with_whitespace_and_predefined_entity>' #CMX '</string_with_whitespace_and_predefined_entity>' '</character-data-sample>' INTO PAGE LEAVING NO PARSE XML PAGE INTO PATH #PATH NAME #NAME VALUE #VALUE PRINT #PATH / 'NA=' #NAME / 'VA=' #VALUE LOOP END
Natural バージョン 4.2.5 より前でプログラムが実行された場合の出力：
Page 1 08-11-04 14:39:51
character-data-sample
NA= character-data-sample
VA=
character-data-sample/string_with_whitespace_and_predefined_entity
NA= string_with_whitespace_and_predefined_entity
VA=
character-data-sample/string_with_whitespace_and_predefined_entity/$
NA=
VA= A
character-data-sample/string_with_whitespace_and_predefined_entity/$
NA=
VA= <
character-data-sample/string_with_whitespace_and_predefined_entity/$
NA=
VA= B
character-data-sample/string_with_whitespace_and_predefined_entity/$
NA=
VA= ?
character-data-sample/string_with_whitespace_and_predefined_entity/$
NA=
VA= ?
NA=
VA= B
character-data-sample/string_with_whitespace_and_predefined_entity/$
NA=
VA= ?
character-data-sample/string_with_whitespace_and_predefined_entity/$
NA=
VA= ?
character-data-sample/string_with_whitespace_and_predefined_entity/$
NA=
VA= B
character-data-sample/string_with_whitespace_and_predefined_entity/$
NA=
VA= <
character-data-sample/string_with_whitespace_and_predefined_entity/$
NA=
VA= C
character-data-sample/string_with_whitespace_and_predefined_entity//
NA= string_with_whitespace_and_predefined_entity
VA=
character-data-sample//
NA= character-data-sample
VA=
MORE
Natural バージョン 4.2.5（以降）でプログラムが実行された場合の出力：
Page 1 08-11-04 13:41:34
character-data-sample
NA= character-data-sample
VA=
character-data-sample/string_with_whitespace_and_predefined_entity
NA= string_with_whitespace_and_predefined_entity
VA=
character-data-sample/string_with_whitespace_and_predefined_entity/$
NA=
VA= A<B?? B<C
character-data-sample/string_with_whitespace_and_predefined_entity//
NA= string_with_whitespace_and_predefined_entity
VA=
character-data-sample//
NA= character-data-sample
VA=
MORE
PARSE XML ステートメントの構文と詳細なアプリケーションヒントについては、『ステートメント』ドキュメントを参照してください。
PARSE XML ステートメントは、次のメインフレームプラットフォームでサポートされます。
z/OS：Batch、TSO、CICS、Com-plete、IMS/TM *
z/VSE：Batch、Com-plete、CICS
VM/CMS
BS2000/OSD：Batch、TIAM、openUTM **
* 後述の「IMS/TM に関する制限事項」を参照してください。
** 後述の「openUTM での XML 関連ステートメントのサポートに対する前提条件」も参照してください。
また、このステートメントは Natural でサポートされているすべての OpenSystems プラットフォームで使用できます。
このセクションでは、Natural ステートメント REQUEST DOCUMENT および PARSE XML を使用する場合に適用される前提条件について説明します。
Natural ステートメント REQUEST DOCUMENT および PARSE XML の使用を有効にするには、『インストール』ドキュメントの「REQUEST DOCUMENT および PARSE XML ステートメントサポートのインストール」で説明されているインストール手順を実行する必要があります。
REQUEST DOCUMENT および PARSE XML は、少なくとも内部的には必ずデータのエンコーディングを変換する必要があるため、Natural の稼働にはアクティブな ICU サポートが必要です。 このため、ICU ライブラリをインストールする必要があります。
REQUEST DOCUMENT または PARSE XML を使用する予定の場合は、次の前提条件を満たす必要があります。
実行環境で TCP/IP スタックが使用可能で有効になっていること
インターネットアドレス解決要求（gehthostbyname 関数）を解決するため、実行環境で DNS（Domain Name System）サーバーまたは DNS サービスが使用可能であること
Natural ドライバが LE 対応（IBM 環境の場合）または CRTE 対応（BS2000/OSD 環境）でインストールされていること
Com-plete で HTTPS をサポートする場合は、APS バージョン 2.7.2 パッチレベル 16
次の表に、ステートメント REQUEST DOCUMENT および PARSE XML のサポートを有効化および無効化するか、またはサポートに影響を及ぼす、Natural プロファイルパラメータおよびセッションパラメータの概要を示します。
| パラメータ | 目的 |
|---|---|
XML |
この Natural プロファイルパラメータまたは対応するパラメータマクロ NTXML とそのキーワードサブパラメータは、ステートメント REQUEST DOCUMENT および PARSE XML の有効化／無効化に使用されます。
また、
|
CFICU |
この Natural プロファイルパラメータまたは対応するパラメータマクロ NTCFICU とそのキーワードサブパラメータは、Unicode およびコードページサポートを有効にするために使用します。
|
CP |
この Natural プロファイルパラメータでは、Natural データおよび Natural ソースのデフォルトのコードページを定義します。 |
CPCVERR |
この Natural プロファイルおよびセッションパラメータでは、変換時に発生した変換エラーが Natural エラーにつながるかどうかを指定します。 |
ステートメント REQUEST DOCUMENT および PARSE XML のサポートを現在のセッションで有効にするには
両ステートメントをともに有効にするには、Natural プロファイルパラメータ XML を ON に設定します。 システムコマンド GLOBALS を使用するか、Natural の起動時にこのパラメータを動的に指定します。
または:
サポートを個別に設定するには、XML/NTXML の該当するキーワードサブパラメータのみ ON に設定します。
RDOC - REQUEST DOCUMENT サポートの有効化
PARSE - PARSE XML サポートの有効化
インストールプラットフォームがインターネットファイアウォールの背後にある場合、またはインターネットトラフィックがプロキシサーバー経由でルーティングされる場合は、プロキシおよびプロキシポートに関する XML/NTXML のキーワードサブパラメータをそれに合わせて指定する必要があります。
ステートメント REQUEST DOCUMENT および PARSE XML のサポートをすべてのセッションについて有効にするには
「適用可能な Natural パラメータの概要」にリストされているパラメータやマクロを Natural パラメータモジュール NATPARM に追加し、該当する値を設定するよう、システム管理者に依頼します。
ステートメント REQUEST DOCUMENT および PARSE XML のサポートを無効にするには
両ステートメントをともに無効にするには、Natural プロファイルパラメータ XML またはパラメータマクロ NTXML を OFF に設定します。
または:
サポートを個別に無効にするには、XML/NTXML の該当するキーワードサブパラメータのみ OFF に設定します。
RDOC - REQUEST DOCUMENT サポートの無効化
PARSE - PARSE XML サポートの無効化
詳細については、『パラメータリファレンス』ドキュメントの「XML - PARSE XML および REQUEST DOCUMENT ステートメントの有効化」も参照してください。
Unicode サポートを有効にするには
プロファイルパラメータ CFICU を ON に設定します。
プロファイルパラメータ CFICU のキーワードサブパラメータに設定できるさまざまなオプションの詳細については、『パラメータリファレンス』ドキュメントの「CFICU - Unicode とコードページのサポート」を参照してください。
『Unicode とコードページのサポート』ドキュメントの「Natural プログラミング言語の Unicode とコードページのサポート」の「ステートメント」に記載されている、PARSE XML および REQUEST DOCUMENT に関連する説明も参照してください。
HTTPS は Hypertext Transfer Protocol Secure の略で、HTTP と TCP/IP プロトコルスタックとの間の追加セキュリティ層です。
| 階層 | プロトコル |
|---|---|
| アプリケーション層 | HTTP（S） |
| セキュリティ層 | TLS/SSL |
| トランスポート層 | TCP |
| ネットワーク層 | IP |
HTTPS は、インターネット経由での安全なデータ通信を目的として、暗号化と通信パートナー認証を実現するために導入されました。
HTTPS URI スキームは、HTTP 通信がセキュリティ保護されることを示すために使用されます。 データの暗号化には、SSL（Secure Socket Layer）プロトコルまたはその後継である TLS（Transport Layer Security）が使用されます。 そのため認証は、通信パートナーの身元を保証する証明書の交換によって行われます。
ただし、ほとんどの HTTPS 通信において、サーバーが一方的に証明書を使用してクライアントの認証を受けます。 クライアント証明書を使用したクライアント認証はほとんど行われません。
SSL 通信はいくつかの段階を経て確立されます。
まず、いわゆる SSL ハンドシェイクプロトコル（Client Hello、Server Hello）による通信パートナーの識別と認証が行われます。
このハンドシェイクが終わると、非対称暗号化を使用した対称セッションキーの交換が行われます（秘密 - 公開キー処理）。 公開キーはサーバー証明書に不可欠な部分で、これ以降クライアントによって使用されます。
ハンドシェイクとキー交換の実行後、暗号化されたペイロード要求メッセージが交換されます。 前の手順でネゴシエーションされた対称セッションキーは、メッセージの暗号化／復号化に使用されます。
HTTPS プロトコルでは、標準的な HTTP ポート番号とは違うポート番号を使用します。 HTTP が通常ポート 80 を使用するのに対し、HTTPS のデフォルトポート番号は 443 です。
LAN（ローカルエリアネットワーク）に接続されているクライアントからインターネットへの HTTP アクセスは、通常、プロキシと呼ばれる特別な HTTP サーバーを経由して処理されます。 プロキシは LAN からインターネットへの出入口であり、セキュリティポリシーを実行し、キャッシュ、検証ルーチン、およびフィルタ機能を提供し、ファイアウォールとして機能します。 HTTPS でセキュリティ保護されたインターネットアクセスのほとんどが、リモートサーバーとの接続を管理する、専用のプロキシサーバー経由で実行されます。 このようなプロキシは "SSL プロキシ" とも呼ばれています。
証明書は、証明書の所有者や発行者に関する情報、セッションキーデータの暗号化に使用する公開キー、有効期限、デジタル署名など、さまざまな情報項目が含まれたバイナリドキュメントです。 HTTPS サーバーによって提示される証明書は、通常、証明書チェーン全体で最も下のリンクです。 このような証明書チェーンは、公開キーインフラストラクチャ（PKI）と呼ばれます。 このようなチェーンの最上位にある証明書は、ルート証明書と呼ばれます。 ルート証明書は、一般に、認証機関（CA）と呼ばれる特別な組織によって発行されます。 CA によって発行および署名されたルート証明書も、CA（ルート）証明書と呼ばれます。 詳細については、HTTP 開発者用のマニュアルおよびインターネットで公開されているその他の情報源を参照してください。
Natural REQUEST DOCUMENT ステートメントの HTTPS サポートは、z/OS の通信サーバーコンポーネント AT-TLS（Application Transparent-Transport Layer Security）がベースです。
AT-TLS は、TLS/SSL 暗号化をソケットアプリケーションの構成可能サービスとして提供します。 この機能は TCP/IP プロトコルスタックの上に追加層として実現され、SSL 機能をソケットアプリケーションに対するほとんどあるいは完全な透過（トランスペアレント）モードで利用します。 AT-TLS には 3 つの動作モードが用意されています。 『z/OS Communications Server, IP Programmer’s Guide and Reference. Version 1, Release 9』（IBM マニュアル SC31-8787-09）の第 15 章を参照してください。
3 つのモードは次のとおりです。
ソケットアプリケーションは、変更されずに透過モードで実行され、AT-TLS 経由で暗号化された通信を実行していることが認識されません。 このため、レガシーアプリケーションはソースコードを修正することなくセキュリティ保護されたモードで実行できます。
アプリケーションは、セキュリティ保護されたモードで実行されていることを認識し、TLS ステータス情報をクエリできます。
ソケットアプリケーションは、AT-TLS を認識し、AT-TLS の暗号化サービスそのものの使用を制御します。 つまり、アプリケーションはセキュリティ保護された通信とそうでない通信を切り替えることができます。
Natural for Mainframes では Controlling モードを使用して、HTTPS 要求に対してのみセキュリティ保護されたモードをオンにし、HTTP 要求は暗号化しません。
z/OS では、AT-TLS で使用される証明書を 2 通りの方法で管理できます。 証明書は、z/OS UNIX ファイルシステム内の RACF キーリングまたはキーデータベースに格納されます。 どちらの方法が実際に適用されるかは、Natural HTTPS クライアントが使用する z/OS TCP/IP スタックの AT-TLS Policy Agent Configuration ファイルに定義されています。
IBM では、z/OS システムデリバリーごとに、一般的に使用される CA ルート証明書のセットを配布しています。 サーバー証明書の保持にキーリングを使用する予定の場合は、配布されたルート証明書をシステム管理者が手動でインポートする必要があります。 有効期限が切れたルート証明書の新しい置き換えが IBM から配布された場合は、影響を受けるすべてのキーリングを更新する必要があります。
キーデータベースはキーリングとは異なり、新たに作成されるとルート証明書の最新セットが自動的に格納されます。 ただし、キーデータベースを使用する場合も、ルート証明書の最新セットを常に維持することが必要です。
Natural HTTPS クライアントによって使用される証明書は、信頼済みとフラグされることが必要です。 証明書が公開キーインフラストラクチャの一部の場合は、対応する CA ルート証明書が信頼済みとフラグされることが必要です。
RACF では、デジタル証明者はいわゆるキーリングに格納されます。 キーリングとそれが格納される証明書の作成と管理には、RACF コマンド RACDCERT が使用されます。
『z/OS Security Server RACF Security Administrator’s Guide』（IBM マニュアル SA22-7683-11）および『z/OS Security Server RACF Command Language Reference』（IBM マニュアル SA22-7687-11）を参照してください。
RACF の代わりとして、z/OS UNIX サービスファイルシステムに存在するキーデータベースに証明書を格納できます。 キーデータベースの作成と管理には、GSKKYMAN ユーティリティを使用する必要があります。
『z/OS Cryptographic Services PKI Services Guide and Reference』（IBM マニュアル SA22-7693-10）を参照してください。
IMS/TM 環境で Natural ステートメント REQUEST DOCUMENT および PARSE XML を使用する場合は、以下の制限事項が適用されます。
PARSE XML ステートメントは、TP モニタの IMS/TM で実行できますが、アクティブな PARSE ループ内で I/O ステートメントを実行できないという制限があります。 PARSE ループ内で I/O が発生すると、エラー NAT0967 が発行されます。
詳細については、ステートメントの説明の対応する注意点を参照してください。
I/O の発生するアクティブな PARSE ループでは、UTM ファンクションコール PGWT を使用する必要があります。 これは以下のことを意味します。
UTM アプリケーションは、複数のタスクで開始する必要があります。そうでない場合、UTM エラー K319 が発生し、ダンプが生成されます。
PGWT 条件を KDCDEF に定義する必要があります。
PGWT コール中の入力メッセージに対する最大待機時間（秒）を定義します。
例：
MAX PGWTTIME=60
PGWT コールに対する最大の UTM タスク数を定義します。
例：
MAX TASKS-IN-PGWT=1
PGWT は、TAC-PRIORITIES 命令または TACCLASS コンセプトのどちらかを使用して制御できます。
TAC-PRIORITIES 命令を使用した PGWT の制御
例：
DEFAULT TAC TYPE=D,PROGRAM=NATUTM,. . . . . . . TAC NAT,ADMIN=NO,TIME=(0,0),PGWT=YES,TACCLASS=1 TAC-PRIORITIES DIAL-PRIO=EQ
TACCLASS コンセプトを使用した PGWT の制御
例：
DEFAULT TAC TYPE=D,PROGRAM=NATUTM,. . . . . . . TAC NAT,ADMIN=NO,TIME=(0,0),TACCLASS=1 TAC NAT1,ADMIN=NO,TIME=(0,0),TACCLASS=2 TACCLASS 1,TASKS=2 TACCLASS 2,TASKS=1,PGWT=YES
次のサンプルプログラムは、ステートメント REQUEST DOCUMENT および PARSE XML の使用方法を示します。
これ以外のサンプルプログラムは、各ステートメントの説明の末尾と Natural ライブラリ SYSEXV に用意されています。
DEFINE DATA
LOCAL
1 #FROM (A) DYNAMIC
1 #HEADER (A) DYNAMIC
1 #PAGE (A) DYNAMIC
1 #RC (I4)
1 #COL (N8)
1 #COL1 (I4)
1 #COL2 (I4)
1 #COL3 (I4)
1 #LOC (A30)
1 #CP (A) DYNAMIC
1 #PATH (A) DYNAMIC
1 #NAME (A) DYNAMIC
1 #VALUE (A) DYNAMIC
1 #RTERR (I4)
END-DEFINE
*
ASSIGN #FROM = 'HTTP://SI15.HQ.SAG/autos6.xml'
**
REQUEST DOCUMENT FROM #FROM
RETURN
HEADER ALL #HEADER
PAGE #PAGE ENCODED FOR TYPES 'TEXT/XML'
CODEPAGE ' '
RESPONSE #RC
GIVING #RTERR
**
IF #RC NE 200 /* TEST FOR HTTP RESPONSE 200 = 'OK'
WRITE 'HTTP RESPONSE' #RC 'RECEIVED'
ESCAPE ROUTINE
END-IF
EJECT
PRINT #HEADER
/ '_'(79)
PRINT #PAGE
/ '_'(79)
/ '_'(79)
ASSIGN #CP = *CODEPAGE
EXAMINE #PAGE FOR 'encoding' GIVING POSITION #COL1
IF #COL1 GT 0
EXAMINE #PAGE FOR '?>' GIVING POSITION #COL3
IF #COL3 GT #COL1
EXAMINE #PAGE FOR 'ISO-8859-1' GIVING POSITION #COL2
END-IF
IF #COL2 GT #COL1 AND #COL2 LT #COL3
EXAMINE #PAGE FOR 'ISO-8859-1' REPLACE #CP
END-IF
END-IF
PRINT #PAGE
/ '_'(79)
EJECT
PARSE XML #PAGE INTO PATH #PATH NAME #NAME VALUE #VALUE
PRINT #PATH / 'NAME=' #NAME / 'VALUE=' #VALUE / '_'(79)
END-PARSE
END 注意:
上記のプログラムでアクセスされている URL はイントラネットサイトのアドレスを指しており、インターネットからはアクセスできません。
サンプルプログラムの出力：
HTTP/1.1 200 OK?Date: Thu, 10 Aug 2006 16:26:22 GMT?Server: Apache/1.3.19 ( BS2000)?Last-Modified: Thu, 27 Jul 2006 16:44:42 GMT?ETag: "2602c-111-44c8ed7a" ?Accept-Ranges: bytes?Content-Length: 273?Connection: close?Content-Type: text/ xml?? _______________________________________________________________________________ <?xml version="1.0" encoding="ISO-8859-1" ?><autos>?<make></make>?<make>Ford</ make>?<model>Thunderbird</model>?<make>Merceds-Benz</make><model>S400</model>< make>BWM</make><model version="latest">330I</model>?<make><label><company> Mercedes</company></label></make>?</autos>? _______________________________________________________________________________ <?xml version="1.0" encoding="IBM01140" ?><autos>?<make></make>?<make>Ford</ make>?<model>Thunderbird</model>?<make>Merceds-Benz</make><model>S400</model>< make>BWM</make><model version="latest">330I</model>?<make><label><company> Mercedes</company></label></make>?</autos>? _______________________________________________________________________________
MORE
autos Name= autos Value= _______________________________________________________________________________ autos/$ Name= Value= ? _______________________________________________________________________________ autos/make Name= make Value= _______________________________________________________________________________ autos/make// Name= make Value= _______________________________________________________________________________ autos/$ Name= Value= ? _______________________________________________________________________________ autos/make Name= make Value= VVVV Name= autos Value= _______________________________________________________________________________ autos/$ Name= Value= ? _______________________________________________________________________________ autos/make Name= make Value= _______________________________________________________________________________
メインフレーム上の Natural に関するドキュメントに「"Natural ICU ハンドラを Natural ニュークリアスにリンクする必要があります"」との記載があります。
コードページサポートが必要となります。これは、メインフレームプラットフォームでは、（すでに UTF-16 でエンコードされている場合を除き、）解析されるドキュメントは常に内部的に UTF-16 に変換されるためです。 ほとんどの場合、ドキュメントは
UTF-16 ではなく、変換が実行されます。 詳細については、PARSE XML ステートメントの説明および『Unicode およびコードページのサポート』ドキュメントの PARSE XML の説明を参照してください。
受信 HTTP ヘッダーの解釈と送信 HTTP ヘッダーの変換には、ICU ライブラリが必要です。 通常、受信ヘッダーは ISO 8859-1 でエンコードされており、メインフレームの場合は常に Natural デフォルトコードページに変換することが必要です（システム変数
*CODEPAGE も参照）。PC の場合、変換は必ずしも必要ではありません。
PC の場合、REQUEST DOCUMENT ステートメントは Internet Explorer を実行し、そこに定義されている設定を使用します。
メインフレームの場合は、すべての要求が経由してルーティングされる必要のある（イントラネット）プロキシサーバーの URL は、NTXML/XML のキーワードサブパラメータ RDP を使用して指定する必要があります。 キーワードサブパラメータ RDNOP を使用すると、プロキシサーバーを経由しない、直接アドレス指定するローカルドメイン（複数可）を定義できます。
サイトのプロキシサーバー、ポート番号、および HTTP サーバーについては、ネットワーク管理者に確認することが必要です。
サイトに定義されているプロキシサーバーは、ブラウザでも確認できます。
例えば、Internet Explorer では［ツール］>［インターネット オプション］>［接続］>［LAN の設定］>［詳細設定］で確認できます。
また、Web で検索するとこのような情報を確認できるツールが見つかることがあります。 例（テストはしていません）：http://www.sharewareconnection.com/titles/proxy-settings.htm
HTTP レスポンスは、RESPONSE 節を介して operand16 に返されます。 『ステートメント』ドキュメントの「レスポンス番号の概要 - HTTP/HTTPS 要求」に説明があります。
これらのエラーの範囲は 8300 番以降です。
特に、エラー NAT8304 では、失敗した HTTP 要求の詳細がわかります。
TCP/IP エラー番号はインストールされている環境によって異なることがあるため、NAT8304 によって返されるテキストが最も参考になります。
追加情報
オフセット 480 のバッファ RDOCWA を参照してください。
TCP/IP エラーはほとんどが ICU エラーです。プロファイルまたはセッションパラメータ CPCVERR を OFF に設定することをお勧めします。
問題が Natural インストールに関連しているのか、より一般的な問題なのかを切り分けるには、TSO から PING を実行します。
例えば、TSO コマンドシェルに次のコマンドを入力します。
TSO PING www.google.com
次のような結果が返されます。
CS V1R9: Pinging host WWW.GOOGLE.COM (66.249.91.99) Ping #1 response took 0.018 seconds.
次に、Natural セッション内で、後述の小さいプログラムを使用してこの Web サイトへのアクセスをテストできます。
例えば、次のコマンドで Natural を起動します。
NATvr CFICU=ON XML=(ON,RDOC=ON,PARSE=ON,RDP='HTTPPROX.HQ.SAG',RDPPORT=8080,RDNOP='*.EUR.AD.SAG; *.HQ.SAG;*.SOFTWAREAG.COM')
vr は、Natural のリリースおよびバージョン番号を表します。
これらの値は、弊社の内部環境と保存されたプロファイルのものです。 キーワードサブパラメータ RDP、RDPPORT、および RDNOP の設定をネットワーク管理者に確認するか、ブラウザ（Internet Explorer）に定義されている値を試すことが必要です。
次の処理を実行します。
DEFINE DATA LOCAL 1 #RESULTXML (A) DYNAMIC 1 #RC (I4) END-DEFINE REQUEST DOCUMENT FROM "HTTP://WWW.GOOGLE.DE" RETURN HEADER ALL #HEADER RESPONSE #RC WRITE #RC WRITE #HEADER (AL=79) END
SYSPROD ユーティリティで確認できます。
SYSPROD で、Natural 製品に対する SC（サブコンポーネントの表示）コマンドを入力します。 インストールされているサブコンポーネントのリストをスクロールしていくと、Nat Request Document のエントリ（Product ID .... TCP）が見つかります。
よくあるユーザーエラーです。XML ドキュメントは、暗黙的または明示的に、あるコードページから別のコードページに、例えば ISO-8859-1 からシステム変数 *CODEPAGE に指定されていたコードページに変換されます。 ただし、ドキュメントのエンコーディング PI encoding="ISO-8859-1" が、変換されたエンコーディングに合わせて調整されていません。 この場合、パーサは解析するドキュメントの最初の文字でエラーになり、終了します。
セッションパラメータ CPCVERR を OFF に設定します。
自己署名証明書は、OpenSSL の SDK を使用して、テストを目的としてイントラネットサーバーで使用できます。 キーデータベースまたは RACF キーリングにインポートした自己署名証明書は、信頼済みとフラグする必要があります。
RACF キーリングのアプローチには、キーデータベースに比べてはるかに多くの作業が必要となります。 キーリングは HTTPS サーバーにアクセスするユーザーごとに作成する必要がある一方、キーデータベースは複数のユーザーで共有できます。
次のように進めます。
TCP/IP コンフィグレーションファイルで、TCPCONFIG ステートメントにオプション TTLS を設定します。
AT-TLS Policy Agent を構成および開始します。 このエージェントは、接続が SSL かどうかを確認するため、TCP/IP によって新しい TCP 接続のたびに呼び出されます。
AT-TLS ルールを含む Policy Agent ファイルを作成します。 Policy Agent ファイルには、どの接続が SSL かを規定するルールが含まれます。
『z/OS Communications Server: IP Configuration Guide』の第 18 章「Application Transparent Transport Layer Security (AT-TLS) data protection」も参照してください。
Sample Policy Agent ファイルには、すべての送信接続がアプリケーション制御の TLS として定義されています。 ルールがアプリケーション制御であるため、これにより Natural REQUEST DOCUMENT サポート以外の TCP/IP アプリケーションが影響されることはありません。 つまり、アプリケーションが接続ステータスを SSL に設定できます。 アプリケーションは、このステータスを設定しない限り、影響を受けません。 一方、Policy Agent
ファイルでは、アプリケーション制御の SSL 接続を特定のポート、ユーザー、またはアドレススペースに制限することもできます。 サンプルでは、証明書データベースが HFS ファイル / u/admin/CERT.kdb に存在することが想定されています。
TTLSRule ConnRule01~1
{
LocalAddrSetRef addr1
RemoteAddrSetRef addr1
LocalPortRangeRef portR1
Direction Outbound
Priority 255
TTLSGroupActionRef gAct1~AllUsersAsClient
TTLSEnvironmentActionRef eAct1~AllUsersAsClient
TTLSConnectionActionRef cAct1~AllUsersAsClient
}
TTLSGroupAction gAct1~AllUsersAsClient
{
TTLSEnabled On
Trace 6
}
TTLSEnvironmentAction eAct1~AllUsersAsClient
{
HandshakeRole Client
EnvironmentUserInstance 0
TTLSKeyringParmsRef keyR1
}
TTLSConnectionAction cAct1~AllUsersAsClient
{
HandshakeRole Client
TTLSCipherParmsRef cipher1~AT-TLS__Silver
TTLSConnectionAdvancedParmsRef cAdv1~AllUsersAsClient
Trace 0
}
TTLSConnectionAdvancedParms cAdv1~AllUsersAsClient
{
ApplicationControlled On
}
TTLSKeyringParms keyR1
{
Keyring /u/admin/CERT.kdb
KeyringStashFile /u/admin/CERT.sth
}
TTLSCipherParms cipher1~AT-TLS__Silver
{
V3CipherSuites TLS_RSA_WITH_DES_CBC_SHA
V3CipherSuites TLS_RSA_WITH_3DES_EDE_CBC_SHA
V3CipherSuites TLS_RSA_WITH_AES_128_CBC_SHA
}
IpAddrSet addr1
{
Prefix 0.0.0.0/0
}
PortRange portR1
{
Port 1024-65535
}
Policy-Agent ジョブ出力 JESMSGLG で次を確認します。
EZZ8771I PAGENT CONFIG POLICY PROCESSING COMPLETE FOR <your TCP/IP address space>: TTLS
このメッセージは、初期化に成功したことを示しています。
Policy-Agent ジョブ出力 JESMSGLG で次を確認します。
EZZ8438I PAGENT POLICY DEFINITIONS CONTAIN ERRORS FOR <your TCP/IP address space>: TTLS
このメッセージは、コンフィグレーションファイルにエラーがあることを示しています。 詳細については、syslog.log ファイルを参照してください。
コンフィグレーションルールはクライアントも対象となりますか。
syslog.log で次を確認します。
EZD1281I TTLS Map CONNID: 00002909 LOCAL: 10.20.91.61..1751 REMOTE: 10.20.91.117..443 JOBNAME: KSP USERID: KSP TYPE: OutBound STATUS: Appl Control RULE: ConnRule01 ACTIONS: gAct1 eAct1 AllUsersAsClient
上記のエントリは、ポート 443 へのユーザー KSP による接続がアプリケーション制御であることを示しています。
『z/OS V1R8.0 Comm Svr: IP Diagnosis Guide: 3.23』の第 29 章「Diagnosing Application Transparent Transport Layer Security (AT-TLS)」も参照してください。
『Comm Svr: IP Configuration Reference』の第 20 章「Syslog deamon and Comm Svr」および『IP Configuration Guide』の第 1.5.1 項「Configuring the syslog daemon (syslogd)」を参照してください。
ポリシーエージェントトレースで、リターンコード RC および対応する GSK_ ファンクション名を探します。
「System SSL Programming」の第 12.1 項「SSL Function Return Codes」の RC の説明を参照してください。
trace=255 の場合のサンプルトレース：
EZD1281I TTLS Map CONNID: 00002909 LOCAL: 10.20.91.61..1751 REMOTE: 10.20.91.117..443 JOBNAME: KSP USERID: KSP TYPE: OutBound STATUS: A EZD1283I TTLS Event GRPID: 00000003 ENVID: 00000000 CONNID: 00002909 RC: 0 Connection Init EZD1282I TTLS Start GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 Initial Handshake ACTIONS: gAct1 eAct1 AllUsersAsClient HS-Client EZD1284I TTLS Flow GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 RC: 0 Call GSK_SECURE_SOCKET_OPEN - 7EE4F718 EZD1284I TTLS Flow GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 RC: 0 Set GSK_SESSION_TYPE - CLIENT EZD1284I TTLS Flow GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 RC: 0 Set GSK_V3_CIPHER_SPECS - 090A2F EZD1284I TTLS Flow GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 RC: 0 Set GSK_FD - 00002909 EZD1284I TTLS Flow GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 RC: 0 Set GSK_USER_DATA - 7EEE9B50 EZD1284I TTLS Flow GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 RC: 435 Call GSK_SECURE_SOCKET_INIT - 7EE4F718 EZD1283I TTLS Event GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 RC: 435 Initial Handshake 00000000 7EEE8118 EZD1286I TTLS Error GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 JOBNAME: KSP USERID: KSP RULE: ConnRule01 RC: 435 Initial Handshake EZD1283I TTLS Event GRPID: 00000003 ENVID: 00000002 CONNID: 00002909 RC: 0 Connection Close 00000000 7EEE8118
役立つリソースのリストを以下に示します。
Software AG のコーポレートユニバーシティでは、このテーマの特別訓練コースを用意しています。 コーポレートユニバーシティの訓練コースについては、http://servline24.softwareag.com/public/ の ServLine24 を参照してください。
また、お近くの地域におけるオンサイトの特別訓練コースについて、担当地域の Software AG にお問い合わせください。
役立つリンクを以下に示します。
World Wide Web Consortium（W3C）：http://www.w3.org/
Extensible Markup Language（XML）：http://www.w3.org/XML/
HyperText Markup Language（HTML）ホームページ：http://www.w3.org/MarkUp/
W3 Schools：http://www.w3schools.com/