WebSphere 最適化ローカル アダプター

IBM WebSphere Optimized Local Adapters (OLA または WOLA)は、 IBMのWebSphere Application Server for z/OSの機能コンポーネントであり、WAS z/OS への着信呼び出しと z/OS からの発信呼び出しの両方に対して効率的なクロスメモリ メカニズムを提供します。他の通信メカニズムのオーバーヘッドを回避するため、大量のメッセージ交換が可能です。WOLA は、WAS z/OS の既存のクロスメモリ交換メカニズムの拡張機能であり、WOLA は外部インターフェースを提供するため、WAS z/OS サーバー外部の z/OS アドレス空間がクロスメモリ交換に参加できます。WOLA は、WAS z/OS サーバーと、CICS、IMS、バッチ、UNIX システム サービス、および ALCS の 1 つ以上との間の接続をサポートします。WOLA は、WAS z/OS バージョン 7、Fixpack 4 (7.0.0.4) で初めて使用可能になりました。この記事に記載されているように、機能強化はその後のフィックスパックで実施されています。

WebSphere Optimized Local Adapters for WAS z/OS (略して WOLA または OLA) は、効率的な着信呼び出しメカニズム、つまり Java EE 環境の外部からJava EE環境にアクセスして Java EE 資産を活用するメカニズムを提供したいという要望から生まれました。この要件は、従来のバッチ処理で Java EE および EJB テクノロジに基づくプログラミング資産の増大する基盤の使用が求められていた z/OS で特に顕著でした。

他にも次のようなインバウンド ソリューションが存在しました。

• Websphere MQやその他の JMS プロバイダーなどのメッセージング。
• RMI / IIOP
• ウェブサービス

それぞれに長所がある一方で、オーバーヘッドやレイテンシ、構築の難しさ、セキュリティやトランザクション伝播モデルの欠陥など、それぞれに固有の欠点もありました。

これは、最適化されたローカル アダプターの元の設計ポイントでした。ソリューションの設計者は、外部アドレス空間から WAS z/OS へのインバウンドと、WAS から外部アドレス空間へのアウトバウンドという双方向の呼び出しを含めるように設計を拡張しました。

このソリューションの設計者は、「ローカル通信」と呼ばれる WAS z/OS 設計の既存の要素を活用することを選択しました。これは、同じ LPAR 上のアプリケーション サーバー間の IIOP トラフィックを最適化するために、V4.x の時代から WebSphere Application Server for z/OS で使用されてきたクロス メモリ メカニズム です。OLA は、本質的には、既存のクロス メモリ メカニズムを外部化したものなので、WAS z/OS 外部のアドレス空間が共有メモリ空間を介して接続し、メッセージを交換できます。

外部アドレス空間プログラムは、提供された API のセットを使用して OLA インターフェースにアクセスします。WAS z/OS で実行される Java プログラムは、標準 JCA リソース アダプターとしてパッケージ化された実装を通じて OLA インターフェースにアクセスします。

WAS z/OS OLA で 現在サポートされている外部アドレス空間は次のとおりです。

• IBM CICS
• バッチジョブ
• UNIX システム サービス(USS)
• 航空管制システム (ALCS)
• IMS (メンテナンス 7.0.0.12 からサポート開始)

外部アドレス空間でサポートされるプログラミング言語は次のとおりです。

• C/ C++ の
• コボル
• 高レベルアセンブラ
• 英語

Java は、WAS z/OS の Java EE コンテナー内から WAS z/OS OLA にアクセスするために使用されるプログラミング言語です。

IBM WebSphere Optimized Adapters 機能のサポートは、新しいバージョンまたはフィックスパックがリリースされるたびに更新されています。この機能は、WAS z/OS バージョン 7 リリース 0 フィックスパック 4 レベル (7.0.0.4) で初めて使用可能になりました。

WOLA は、WAS z/OS バージョン 7 リリース 0 製品に Fixpack 4 で導入されました。メンテナンスの適用により、WOLA モジュール、共有オブジェクト、JCA リソース アダプター、および開発クラス ライブラリを提供する新しいディレクトリが製品ファイル システムに作成されました。シェル スクリプト (olaInstall.sh) によって、ランタイム環境から製品インストール ファイル システムへの必要な UNIX シンボリック リンクが作成されました。

7.0.0.4 リリースでサポートされる機能は次のとおりです。

• CICS、バッチ、USS、ALCSのサポート
• CICS へのアウトバウンド WAS の 1 フェーズ コミット (7.0.0.12 で提供される CICS TS 4.1 への 2PC)
• CICS から WAS へのインバウンドの 2 フェーズ コミット
• ネイティブAPI
• JCA リソース アダプタ

WAS z/OS バージョン 7 リリース 0 の Fixpack 12 では、WOLA サポートに次の 2 つの更新が提供されました。

• WOLAとIMSのサポート
• WAS アウトバウンドから CICS TS 4.1 への 2 フェーズ コミット トランザクション処理

WebSphere Application Server for z/OS バージョン 8 リリース 0 では、WebSphere Optimized Local Adapters のサポートが継続されました。WOLA は製品に組み込まれて出荷されたため、olaInstall.sh を実行して製品ファイルへの UNIX シンボリック リンクを作成する必要がなくなりました。さらに、次の機能更新が提供されました。

• IMS での作業のためのマルチセグメントの大きなメッセージのサポート (サイズが 32K を超える)
• IIOP 呼び出しとは別に WOLA 呼び出しの着信トランザクション分類をサポート
• WOLA 呼び出しの SMF 120.9 レコード内での識別は IIOP ではなく WOLA として行われます。
• リソース障害の識別と代替JNDIフェイルオーバー

この機能は、JCA 接続ファクトリーに接続されたデータ リソースの損失を検出し、定義済みの代替 JNDI に自動的にフェイルオーバーする手段を提供します。プライマリ データ リソースのリカバリーとフェイルバックの検出も、この機能設計の要素です。リソース フェイルオーバー設計は、JDBC および JCA のすべてのプラットフォームにわたって WebSphere Application Server バージョン 8 に存在します。WAS z/OS バージョン 8 は、JCA リソース フェイルオーバーの一般的なサポートの一部として WOLA リソース フェイルオーバーをサポートします。フェイルオーバーは、構成可能なしきい値の数の getConnection() 障害が発生したときに呼び出されます。フェイルオーバーが呼び出された後、すべての新しい getConnection() 要求は、代替接続ファクトリー接続プールにルーティングされます。フェイルバックは、WAS z/OS が障害が発生したプライマリ データ リソースが戻ったと判断すると発生します。新しい getConnection() 要求は、プライマリ接続ファクトリーに対して処理されます。

この機能の一般的な使用パターンは、ターゲット CICS 領域がルーティング領域である CICS へのアウトバウンドです。このフェイルオーバー機能により、複数のルーティング領域を設計できるため、単一のルーティング領域が失われても CICS 全体の可用性に影響はありません。

このリソース フェイルオーバーおよびフェイルバック メカニズムをサポートするために、いくつかの接続プールのカスタム プロパティが追加されました。

• failureThreshold- 自動フェイルオーバーが呼び出される前に発生する必要がある連続した getConnection() 失敗の数
• alternateResourceJNDIName- 自動フェイルオーバーが呼び出された場合に使用する代替接続ファクトリの JNDI 名
• resourceAvailabilityTestRetryInterval - WAS がプライマリ リソースの戻りをテストするために使用する秒単位の間隔

注:この関数には、他の接続プールのカスタム プロパティが存在します。完全なリストについては、WAS z/OS InfoCenter で文字列「cdat_dsfailover」を検索してください。

注: WAS z/OS 8.5.0.0 は、8.0.0.1 と機能的に同一の WOLA サポートを提供します。

WebSphere Application Server for z/OS バージョン 8 の Fixpack 1 では、WOLA に次の機能更新が提供されました。

• 64 ビット モードで動作する C/C++ プログラム用の 64 ビット呼び出し可能なネイティブ API
• WAS からの WOLA発信コールの SMF 120 サブタイプ 10 レコード(SMF 120 サブタイプ 9 は着信コール情報をキャプチャします)
• 作業配分 - 同じ名前の複数の外部登録間で発信コールをラウンドロビンする機能
• リモートアクセスのプロキシサポート - これにはインバウンドとアウトバウンドの2つの形式があります

8.0.0.1 より前は、ネイティブ API モジュールは 31 ビットの呼び出し可能な形式でのみ提供されていました。これらのモジュールには、各モジュール名に関連付けられた 4 文字のプレフィックス BBOA* がありました。

8.0.0.1 では、31 ビットと 64 ビットの両方の呼び出し可能な API モジュールが提供されます。31 ビット モジュールでは、各モジュール名に 4 文字のプレフィックス BBOA* が付きます。64 ビット モジュールでは、各モジュール名に 4 文字のプレフィックス BBGA* が付きます。

API の数は以前と同じで、特定の API は 13 個です。使用方法は以前と同じです。

情報センター検索: cdat_olaapis

WAS z/OS V7 では、SMF の WOLA サポートは着信呼び出しのみに限定されていました。WAS z/OS コンテナー内のターゲット EJB への着信 WOLA 呼び出しは IIOP 呼び出しとして識別され、SMF によって IIOP 呼び出しとしてキャプチャされ、他の IIOP 呼び出しと区別がつかなくなりました。着信呼び出し情報のキャプチャには、通常の WAS z/OS SMF 120 サブタイプ 9 レコード (省略表記では 120.9) が使用されました。

WAS z/OS 8.0.0.0 では、SMF 120.9 の記録およびキャプチャ機能が変更され、着信 IIOP 呼び出しとは別に着信 WOLA 呼び出しを識別するようになりました。

WAS z/OS 8.0.0.1 では、WAS z/OS からの発信呼び出しに関する情報を取得するために SMF 120.10 レコードが作成されました。SMF 120.10 レコードには 8 つのセクションがあります。

• プラットフォーム中立のサーバー情報セクション
• z/OS サーバー情報セクション
• 送信リクエスト情報セクション
• WOLA アウトバウンドリクエストタイプ固有のセクション
• 送信要求トランザクション コンテキスト セクション
• 送信要求セキュリティ コンテキスト セクション
• アウトバウンド要求 CICS コンテキスト セクション
• OTMA アウトバウンド リクエスト タイプ固有のセクション

送信リクエストごとに 1 つのレコードが作成されます。

インフォセンター検索: rtrb_SMFsubtype10

この機能更新により、同じ登録名を使用して特定の WAS z/OS サーバーに登録された複数の外部アドレス空間に発信呼び出しを分散できるようになります。この機能の一般的な使用パターンは、同じステートレス ターゲット プログラム サービスがデプロイされた複数の CICS 領域です。必要な作業分散のタイプを示すために、新しい環境変数が作成されました。次に、この機能の使用法を示します。

情報センター検索: cdat_olacustprop

WOLA 通信のクロスメモリ特性により、WAS z/OS サーバーと外部アドレス空間は同じ z/OS 論理パーティション (LPAR) 上になければなりません。WAS z/OS 8.0.0.1 は、WOLA 呼び出し元と WOLA ターゲットを別々に配置できるようにするプロキシ機能を提供します。これには、z/OS 以外のオペレーティング システム インスタンス上の配置も含まれます。この機能には、アウトバウンドコールのプロキシ サポートとインバウンドコールのプロキシ サポートの 2 つの形式があります。

これにより、Java アプリケーションが提供の WOLA JCA リソース アダプターを使用してリモート z/OS 上のターゲット アドレス空間にアクセスできるメカニズムが提供されます。使用パターンの例としては、提案されたアプリケーションの開発またはテストが挙げられます。ターゲット z/OS システム上のクロスメモリー WOLA 接続へのアクセスは、WOLA 対応の WAS z/OS サーバーにインストールされた提供の WOLA プロキシー アプリケーションによって提供されます。次の図は、トポロジーを示しています。

アプリケーションから WAS z/OS システムへのネットワーク フローは IIOP 経由です。WOLA 接続ファクトリーは、接続プールへのいくつかの新しいカスタム プロパティを介して、プロキシへのこの IIOP フローを通知されます。WAS z/OS 上のプロキシ アプリケーションは呼び出しを受信し、実際のクロスメモリ WOLA 接続を介して、指定されたターゲット サービスに転送します。

このトポロジーには、同じ z/OS LPAR 上のアウトバウンド WOLA 呼び出しと比較して制限があります。2 フェーズ コミットを必要とするグローバル トランザクションは、IIOP 接続を介して WOLA プロキシに伝播できず、WAS スレッド上のユーザー ID は z/OS 上のターゲット サービスにアサートできません。

これにより、外部アドレス空間の非 Java アプリケーションが、別の z/OS LPAR または分散 WAS プラットフォーム上のリモート WAS インスタンス内のターゲット WOLA 対応 EJB への着信呼び出しを行うことができるメカニズムが提供されます。ローカル WAS z/OS インスタンスにインストールされている同じ提供された WOLA プロキシ アプリケーションは、初期のクロスメモリ WOLA 呼び出しを処理し、それをリモート WAS インスタンス上の指定されたターゲット EJB に転送する必要があります。次の図は、トポロジを示しています。

ターゲットの WOLA 対応 EJB は、プロキシが使用中であることを認識しません。着信フローは、同じ LPAR 上のクロスメモリ WOLA が使用された場合と同様に、IIOP 呼び出しとして到着します。呼び出し側プログラムは、フローがプロキシ サービスを使用することを指示する必要があります。これは、BBOA1INV (または BBOA1SRQ) の requesttype パラメータに 2 を指定して行います。これにより、ローカル プロキシ アプリケーションは、ターゲット EJB の JNDI 名として指定される要求されたサービスを、IIOP を使用して EJB を呼び出す要求として処理します。JNDI 検索が成功するには、ローカルおよびリモートの WAS インスタンスがフェデレーテッド名前空間を持つか、または単一のセルとして動作する必要があります。

8.0.0.3 (および 8.5.0.1) では、IBM Integration Designer for BPEL Processes に WOLA サポートが含まれています。

8.0.0.4 (および 8.5.0.1) では、IMS 従属領域から WOLA 経由の WAS への RRS トランザクション コンテキスト アサーションが含まれるようにサポートが更新されました。

• IMSのアプリケーションは、レジスタAPIに「トランザクションサポート」フラグを設定します。
• ターゲットWAS環境ではola_rrs_context_propagate = 1環境変数が設定され、有効になっています。
• IMS制御領域はRRS=Yで実行されている必要があります

Fixpack 8.0.0.5 / 8.5.0.2 では、(1) WOLA / OTMA 経由での WAS から IMS への RRS トランザクション コンテキスト アサーション、(2) CICS チャネルとコンテナーのサポート強化という 2 つの機能強化が提供されました。

IMS トランザクションの場合:

• IMS制御領域はRRS=Yで実行されている必要があります
• ターゲットWAS環境ではola_rrs_context_propagate_otma = 1環境変数が設定され、有効になっています。

CICS チャネルとコンテナの拡張サポートについては、8.0.0.5 / 8.5.0.2 より前のバージョンでは、CICS チャネルとコンテナのサポートは、要求と応答の両方に対して 1 つの固定名チャネルと、BIT または CHAR タイプの 1 つのコンテナに制限されていました。8.0.0.5 / 8.5.0.2 では、次のようになります。

• ターゲットCICSプログラムから1つ以上のコンテナを送受信する
• チャンネル名はsetLinkTaskChanID()メソッドを使用して設定されます
• チャネルタイプはsetLinkTaskChanType()メソッドを使用して設定されます。
• 個々のリクエスト コンテナーの名前は、put() メソッドを使用して MappedRecord にデータを追加することによって設定されます。
• MappedRecord のキーは CICS コンテナ名に対応しており、対応する値は CICS 内のコンテナを埋めるために使用されます。
• CICS 要求が完了した後、応答コンテナー名がチャネルから抽出され、新しい MappedRecord に入力されてクライアントに返されます。

最適化されたローカル アダプターは、次のコンポーネントに分類できます。

• インターフェースモジュール- OLAインターフェースとOLA APIへのプログラムによるアクセスを提供します
• CICSタスク関連ユーザー出口、リンク タスク サーバー、および制御トランザクション- CICS 内のプログラム アセットへの発信呼び出しをサポートするための簡略化されたメカニズムを提供します。
• JCAリソースアダプタ- Java環境と外部環境間のインターフェースを提供します
• 開発ツールのサポート- OLA 対応アプリケーションを開発するためのサポートクラスを提供します
• サンプル- プログラミング モデルの使用方法を示す C/C++、COBOL、Java のサンプルのセット

最適化されたローカル アダプターは、タスク関連ユーザー出口 (TRUE) として CICS に実装されます。これにより、CICS クロス メモリから WAS z/OS アドレス空間への重要な接続が提供されます。

さらに、WAS から CICS への呼び出し用に、リンク サーバー タスク (BBO$) とリンク呼び出しタスク (BBO#) が提供されます。BBO$/BBO# リンク サーバー タスクは、プログラミングの詳細を CICS プログラムから隠します。WAS からの OLA 呼び出しは、これらの提供されたタスクによって処理され、指定された CICS プログラムは、標準のEXEC CICS LINK 呼び出しで呼び出されます。指定された CICS プログラムは変更されず、OLA を使用して WAS から呼び出しが行われたことを認識しません。CICS のターゲット プログラムは、LINK 呼び出しで呼び出すことができる必要があります。COMMAREA ^{[説明が必要]}とチャネル/コンテナーの両方がサポートされています。

BBOC トランザクションも提供されており、TRUE を手動で起動する (PLTPI にない場合)、TRUE を停止する、リンク サーバーを起動および停止する、その他の制御機能や管理機能など​​を実行するための一連の制御コマンドを提供します。

OLA プログラミング インターフェース モジュール ライブラリ データ セットは、CICS 領域の DFHRPL DD ステートメントに連結する必要があります。

次の図は、トランザクション伝播とセキュリティアサーションに対する WOLA CICS サポートをまとめたものです。

最適化されたローカル アダプターは、IMS の外部サブシステムとして実装されます。メッセージ処理プログラム (MPP)、バッチ メッセージ処理プログラム (BMP)、IMS 高速パス (IFP)、およびバッチ DL/I アプリケーションでの使用がサポートされています。

IMS から WAS への呼び出しでは、外部サブシステム接続機能 (ESAF) が使用されます。これは、DB2 や MQ などの他のサブシステムで使用されるものと同じインターフェースです。

WAS から IMS 従属領域への呼び出しは、OTMA を使用して、または直接行うことができます (つまり、IMS 内のプログラムは、以下に説明するように OLA API を使用して「サービスをホスト」します)。OTMA は、いくらかのオーバーヘッドを犠牲にして、IMS アプリケーションに OLA 透過性を提供します。IMS アプリケーションで OLA API を使用すると、オーバーヘッドが削減され、パフォーマンスとスループットが向上します。

IMS 用のプログラミング API は、最初に導入されたものと同じ形式と構文です。ただし、IMS がそこで実行されている場合は IMS を認識し、ESAF を使用するように更新されています。

さらに、WAS 用の JCA リソース アダプターを実装する ola.rar ファイルは、IMS で使用するために、Fixpack 7.0.0.12 以降に同梱されているものでなければなりません。メソッド パラメーターは IMS サポート用に更新されており、7.0.0.12 に同梱されている ola.rar を再インストールすると、その更新が WAS で使用できるようになります。

次の図は、トランザクション伝播とセキュリティアサーションに対する WOLA IMS サポートをまとめたものです。

外部アドレス空間は、提供されたインターフェイス モジュールと文書化された API を介して OLA メカニズムにアクセスします。現在、13 個の API があります。これらは以下のように分類されます。

WAS z/OS 環境で実行され、外部からの呼び出しのターゲットとなることを望む Java プログラムは、開発ツール サポートで提供される OLA クラス ファイルを使用して、ステートレス セッション Bean に OLA インターフェースを実装する必要があります。

OLA 呼び出しのアウトバウンドを開始する Java プログラムは、サーブレットまたは EJB として実装できます。Java プログラムは、開発ツール サポートで提供されるクラス ファイルを使用して、提供された JCA リソース アダプター (ola.rar) にコード化されます。

発信コールのターゲットとなる外部アドレス空間は、コールを受け入れる準備ができている必要があります。次の 2 つの基本モデルが存在します。

• 外部アドレス空間が CICS の場合、ユーザーは、提供されているリンク サーバー タスクを使用して、既存の CICS プログラム資産の代わりに受信エージェントとして動作させることができます。リンク サーバー タスク (デフォルトでは BBO$) は呼び出しを受け取り、interactionSpecImpl.setServiceName() で指定されたプログラムの EXEC CICS LINK を発行します。既存の CICS プログラムが COMMAREA またはチャネル/コンテナーのいずれかをサポートしている限り、プログラムを変更する必要はありません。
• 外部アドレスが IMS の場合、呼び出しは IMS OTMA インターフェイスを使用して行うことができます (IMS アプリケーションに変更はありません)。または、OLA を直接使用して行うことができます (IMS プログラムで OLA API を使用して「サービスをホスト」することを意味します)。
• 外部アドレス空間が CICS または IMS 以外の場合、プログラムは提供されている API の 1 つを使用して「サービスをホスト」する必要があります。これにより、プログラムは WAS z/OS の Java プログラムからの呼び出しを受信できる状態になります。呼び出しを受信すると、プログラムは要求を処理し、WAS z/OS の Java プログラムに応答を返すことができます。

API は両方のモードをサポートします。同期では、応答を受信するまでプログラム制御が呼び出しプログラムに返されないため、よりシンプルなプログラミング モデルが提供されます。非同期では、長時間実行されるターゲット プロセスからの応答を待たずに、他の作業を処理する機会が設計者に提供されます。

OLA 固有のプログラミング アーティファクトを設計して、OLA インターフェイスと既存の資産の間の「ブリッジ」として機能させることができます。これにより、既存のプログラミング資産への影響が最小限に抑えられ、「プラットフォーム ロックイン」の程度が制限されます。

• CICS へのアウトバウンド - 提供されているリンク サーバー実装を使用します。CICS プログラムにはまったく変更を加えません。
• WAS へのインバウンド - OLA 呼び出しを受け取り、指定された EJB を呼び出す EJB を構築します。ターゲット EJB が同じ JVM 内にある場合は、非常に効率的です。ターゲット EJB が同じ LPAR 上の同じセル内にある場合は、前述の「ローカル通信」機能が使用されます。

13 個の API があり、次のカテゴリに分類されます。

• 一般的なセットアップとティアダウン- BBOA1REG (登録) と BBOA1URG (登録解除)
• インバウンド ベーシック- BBOA1INV (自動取得応答で呼び出す)
• 受信アドバンス- BBOA1CNG (接続の取得)、BBOA1SRQ (要求の送信)、BBOA1RCL (応答の長さの取得)、BBOA1GET (メッセージ データの取得)、BBOA1CNR (接続の解放)
• アウトバウンド ベーシック- BBOA1SRV (サービスをホスト)、BBOA1SRP (応答を送信)
• アウトバウンド アドバンス- BBOA1RCA (任意の接続で受信)、BBOA1RCS (特定の接続で受信)、BBOA1GET (メッセージ データを取得)、BBOA1SRP (応答を送信)、BBOA1SRX (例外を送信)

InfoCenter には、パラメータ リスト、戻りコード (RC)、理由コード (RSN) とともに、それぞれの詳細な説明が記載されています。cdat_olaapis で検索してください。

一般的なインバウンドAPI 使用モデルは次のようになります。

この場合、BBOA1REG API を使用して WebSphere Application Server for z/OS デーモン グループ (セルの短縮名) に登録し、BBOA1INV を複数回呼び出してターゲット EJB を呼び出します。BBOA1INV は同期的であるため、EJB が応答を返すまでプログラム制御は保持されます。この API は、呼び出し側プログラムが応答メッセージのサイズを事前に知っている場合に便利です。呼び出し時に応答メッセージのサイズが不明な場合は、より基本的な API (BBOA1SRQ (要求の送信)、BBOA1RCL (応答の長さの取得)、BBOA1GET (メッセージ データの取得)) の方が適しています。

呼び出しプログラムは、作業が完了したと判断すると、BBOA1URG を使用してデーモン グループから登録解除します。

ターゲット Java プログラムの応答間隔が長い場合は、非同期モデルの方が適している可能性があります。次の図は、プリミティブAPIと呼ばれるものを使用して非同期呼び出しを実行する方法を示しています。BBOA1SRQ で async=1 パラメータが設定されます。

図に示されているように、非同期モードでは、Java 以外のプログラムが制御を取得して他の処理を実行できます。これは、将来のある時点で応答を確認することを意味します。BBOA1RCL は、この目的に使用されます。この例では、BBOA1RCL は同期的に発行されます(パラメーター async=0)。応答が利用可能な場合、BBOA1RCL は長さを提供し、プログラム制御はプログラムに戻ります。応答が利用できない場合、BBOA1RCL は応答が利用可能になるまでプログラム制御を保持します。応答が利用できない場合、async=1 の BBOA1RCL は x'FFFFFFFF' を返し、プログラム制御はすぐに戻ります。

アウトバウンドに関するその他の図は、IBM Techdocs Web サイトにある WP101490 ドキュメントに記載されています。

注: WAS から CICS へのアウトバウンドでは、 API コーディングは必要ありません。その場合、提供された BBO$/BBO# リンク サーバー トランザクションがその処理を実行します。これらのリンク サーバー トランザクションは、BBOA1SRV API に類似した内部構造を使用して「サービスをホスト」します。バッチ プログラムへのアウトバウンドでは、「サービスをホスト」するために API を使用する必要があります。

最適化されたローカル アダプターは、CICS インバウンドから WAS への 2 フェーズ コミット (2PC) 処理をサポートします。

メンテナンス 7.0.0.12 の登場により、最適化されたローカル アダプターは WAS から CICS への 2 フェーズ コミット アウトバウンドもサポートするようになりました。7.0.0.12 より前は、WAS から CICS へのトランザクション サポートは「戻り時の同期」に限定されていました。

IMS の場合、IMS 従属領域から WAS へのトランザクション アサーション インバウンドのサポートは、フィックスパック 8.0.0.4 および 8.5.0.1 で提供されました。WOLA/OTMA 経由の WAS から IMS へのトランザクション アサーション アウトバウンドは、フィックスパック 8.0.0.5 で提供されました。

トランザクションの伝播は、バッチ、USS、または航空会社のライン コントロールへのインバウンドまたはアウトバウンドではサポートされていません。

最適化されたローカル アダプターは、次の状況で ID をアサートできます。

• WAS --> CICS: WOLA API を呼び出すために使用される WAS スレッド上の ID は、CICS に ID をアサートするために使用できます。これを行うには、WOLA CICS リンク サーバーが使用され、SEC=Y パラメータで開始され、CICS 領域が SEC=YES で実行され、リンク サーバー タスクが実行される ID に、伝播されたユーザー ID に代わってトランザクションを開始するための SURROGAT SAF 権限がなければなりません。詳細については、IBM InfoCenter を参照してください。
• WAS --> バッチ、USS、または ALCS: ID をアサートする試みは行われません。ターゲット プロセスは、開始時に使用された ID で実行されます。
• CICS --> WAS: CICSはリージョンIDまたはアプリケーションユーザーIDをアサートできます。
• バッチ、USS、または ALCS: 外部プロセスは、その ID を WAS z/OS にアサートしようとします。

WAS z/OS 最適化ローカル アダプターは、特定の LPAR 内でのみ使用できます。これはクロスメモリ メカニズムであり、LPAR 間やマシン外では使用できません。

• Redbooks: z/OS 上の WebSphere - 最適化されたローカル アダプター
• IBM ホワイト ペーパー: WebSphere z/OS 最適化ローカル アダプター
• IBM InfoCenter: z/OS 用に最適化されたローカル アダプターの使用計画
• ビデオデモは、YouTubeでキーワードWASOLA1を検索すると見ることができます。
• YouTube動画:
  • WP101490 - WOLA - WOLA の要点 [1]
  • WP101490 - WOLA - CICS [2]
  • WP101490 - WOLA - IMS [3]
  • WP101490 - WOLA - ネイティブAPIパート1/2 [4]
  • WP101490 - WOLA - ネイティブAPI パート2/2 [5]
  • WP101490 - WOLA - Javaに関する考慮事項 [6]