このドキュメントは、z/OS 環境にのみ適用されます。 以下のトピックについて説明します。
Natural は、プログラミング言語である以外に、クライアント/サーバー環境でサーバーとして機能できます。 Natural サブプログラムの実行などのサービスを提供します。 サーバー機能の一部は、拡張バッチドライバです。 クライアント/サーバー通信の基盤となるプロトコルが多数あり、DB2 のストアドプロシージャの実行やリモートプロシージャコールの実行などがあります。『Natural リモートプロシージャコール(RPC)』ドキュメントを参照してください。
サーバーとしての Natural は、独立したリージョン内で動作するか、DB2 ストアドプロシージャのようなサーバーサブシステムリージョン内で動作します。 Natural をサーバーとして実行するには、サービス固有のサーバースタブが必要です。 このサーバースタブは、サーバー製品の一部として提供され、 すべてのサービス要求を制御するとともに、Natural サーバーフロントエンドの唯一のインターフェイスとして機能します。
DB2 用や Natural RPC 用など、他にも異なるサーバースタブがあります。
Natural バッチドライバ(z/OS 環境の NATOS
など)は、拡張されて環境固有のインターフェイスコンポーネントとして機能するようになりました。Natural サーバーセッションを管理し、Natural に環境固有のサービスを提供します。 これは、サーバースタブモジュールにリンクするか、個別のモジュールとしてサーバースタブでロードすることができます。
バッチドライバは、スレッドストレージの圧縮、圧縮解除、および外部ストレージデバイスへのロールアウトの機能を持つストレージスレッドを使用して、複数のセッションを作成および制御できます。
サーバー初期化中にバッチドライバがサーバースタブによって初めて呼び出されると、ストレージスレッドがメインストレージに作成されます。 ストレージスレッドの数とサイズは、サーバースタブによって決まります。 その後、スタティックな Natural セッションが初期化されます。 これには、プロファイルパラメータの評価およびスタティックなストレージバッファの割り当てが含まれます。 作成された初期化済みストレージスレッドは、メインストレージに個別に保存されます。 新しい Natural セッションごとに、この最初の "セッションクローン" がスレッドにコピーされます。
サーバースタブの決定により、セッションはロールアウトされて後で再開されることがあります。 Natural ロールサーバーがドライバによって使用されて、セッションの圧縮スレッドストレージが保存されます。 別の方法としては、メインストレージを使用して、圧縮スレッドストレージを保存できます。 この場合は、ロールアウト状態のセッションの数はリージョンサイズによって制限されます。
Natural ニュークリアスおよびそのバッチドライバは、サーバー環境とサーバー以外の環境の両方をサポートするように設計されています。 サーバー固有の定義および要件については、該当のドキュメント(『Natural リモートプロシージャコール(RPC)』ドキュメントや『Natural for DB2』ドキュメントなど)を参照してください。
セッション数が少数に制限されておらず、セッションのロールアウトがサポートされるサーバータイプの場合は、サーバーを初期化する前に Natural ロールサーバーをインストールし起動する必要があります。 これを行うには、Natural パラメータモジュールの SUBSID
パラメータが正しい値に設定されていることを確認します。 サーバーでは、サーバーの他に、ADALNK
もリエントラントであるように Adabas リンクインターフェイス(ADALNK
)を生成する必要があります。
ローカルまたはグローバルの Natural バッファプールを使用できます。 ローカルバッファプールを定義すると、サーバーリージョン内のすべてのセッションで共有されます。
論理出力ファイルまたはワークファイル番号をサーバーセッション内で処理に使用する場合は、その番号をセッションの開始時にアクセスメソッドに関連付ける必要があります。 これを行うには、マクロ NTWORK
および NTPRINT
で NATPARM
を使用します。すべての出力ファイルおよびワークファイル番号の全範囲を使用可能にする場合は、以下の例のように指定します。
NTPRINT (1-31),AM=STD,OPEN=ACC,DEST=* NTWORK (1-32),AM=STD,OPEN=ACC,DEST=*
サブパラメータ DEST=*
は、最初の DEFINE WORK FILE
または DEFINE PRINTER
ステートメントの OUTPUT
節中に一般的な DD 名の生成を定義します(下記参照)。 サブパラメータ OPEN=ACC
は、プログラム起動時にファイルの事前オープンを回避します。 オープンはファイルの初回アクセス時に発行されます。
1 つのリージョンで多数の同時セッションを実行している場合は、外部出力ファイルおよびワークファイルとのリソースの競合が発生することがあります。 出力ファイルまたはワークファイル用の論理名(DD 名)は、マクロ NTPRINT
または NTWORK
のサブパラメータ DEST
か、同等のダイナミックパラメータ PRINT
または WORK
によって定義されます(デフォルトは CMPRTnn
または CMWKFnn
)。 通常の Natural バッチ処理では、これらのファイルは論理(DD)および物理データセット名によって JCL に定義されます。
ただし、DD 名は、各セッションの 1 つのタスクで排他的に使用するためにオペレーティングシステムによって予約されています。つまり、1 つのセッションで処理のために CMWKF01 が開かれた場合は、閉じられるまで他のセッションではこのファイルを使用できません。 他のセッションでこれを開こうとすると、エラーが発生します。
サーバー環境では、すべての出力ファイルおよびワークファイルの要求は専用の I/O サブタスクによって処理されます。 これにより、データセットの保全性が確保され、リソースの競合が回避されます。 そのため、Natural セッションの境界を超えて出力ファイルおよびワークファイルの共有使用が可能になります。つまり、複数のセッションで同じファイルに同時にアクセスできます。 これは、CM で始まる DD 名を持つ出力ファイルおよびワークファイルにのみ有効です。 他のファイルはすべて、排他的で共有不可と見なされます。
出力ファイルおよびワークファイルの排他的使用のため、Natural では以下の 2 つの機能でサーバー環境の出力ファイルおよびワークファイルをサポートします(どちらもサーバー環境用の Natural アプリケーションプログラム内に特別に実装する必要があります)。
DEFINE WORK FILE
または DEFINE PRINTER
ステートメントの OUTPUT
節
データセットのダイナミックアロケーション(アプリケーションプログラミングインターフェイス USR2021N
。「SYSEXT - Natural アプリケーションプログラミングインターフェイス」を参照)。
DEFINE WORK FILE
および DEFINE PRINTER
ステートメントの OUTPUT
節は、以下のいずれかの場合に使用できます。
ワークファイルまたは出力ファイル用の論理 DD 名を定義する場合
物理データセット名を定義する場合
出力スプールクラスを定義する場合
DD 名が指定された場合は、アクセスメソッドによって、データセットが割り当てられているかどうかがチェックされます。 割り当てられていないと、エラーが発行されます。 データセットは、ライブラリ SYSEXT
で提供された USR2021N
サブプログラムを使用する任意の Natural プログラムで割り当てることができます。
物理データセット名またはスプールファイルクラスが指定された場合は、DEFINE ...
ステートメントの実行中にアクセスメソッド自体によってデータセットがダイナミックに割り当てられます。 確実に一意の DD 名が使用されるように、DEST=*
を NATPARM
ファイルに事前に定義する必要があります。 これにより、DD 名の競合が回避されます。
アプリケーションがアプリケーションプログラミングインターフェイス USR2021N
を使用している場合は、DD 名変数にアスタリスク値を指定して、アクセスメソッドから一意の DD 名を戻します。 この DD 名は、後続の DEFINE ...
ステートメントに使用できます。
デフォルトでは、サーバージョブのアクセスプロパティは出力ファイルおよびワークファイルに使用されます。 一部のサーバータイプ(Natural 開発サーバーや Natural RPC など)では、偽装がサポートされます。つまり、個別のクライアントアカウントのアクセスプロパティが、排他的な出力ファイルおよびワークファイルに使用されます。 詳細については、サーバーのドキュメントの該当セクションを参照してください。