次の方法で共有

TEST_RTS_AND_POST

  • [アーティクル]

TEST_RTS_AND_POST動詞を使用すると、パートナー トランザクション プログラム (TP) が方向の送信を要求したときに、アプリケーション (通常は 5250 エミュレーター) が非同期通知を要求できます。

次の構造体では、 TEST_RTS_AND_POST 動詞で使用される動詞制御ブロック (VCB) について説明します。

構文

  
struct test_rts {  
    unsigned short      opcode;  
    unsigned char       opext;  
    unsigned char       reserv2;  
    unsigned short      primary_rc;  
    unsigned long       secondary_rc;  
    unsigned char       tp_id[8];  
    unsigned long       conv_id;  
    unsigned char       reserv3;  
    unsigned long       handle;  
};

メンバー

opcode
指定されたパラメーター。 動詞操作コード (AP_B_TEST_RTS_AND_POST) を指定します。

opext
指定されたパラメーター。 動詞操作拡張機能を指定します(AP_BASIC_CONVERSATION)。

reserv2
予約済みフィールド。

primary_rc
返されたパラメーター。 動詞の完了時に APPC によって設定されるプライマリ リターン コードを指定します。 有効なリターン コードは、発行された APPC 動詞によって異なります。 この動詞の有効なエラーコードについては、「リターン コード」を参照してください。

secondary_rc
返されたパラメーター。 動詞の完了時に APPC によって設定されるセカンダリ リターン コードを指定します。 有効なリターン コードは、発行された APPC 動詞によって異なります。 この動詞の有効なエラーコードについては、「リターン コード」を参照してください。

tp_id
指定されたパラメーター。 ローカル TP を識別します。 このパラメーターの値は、呼び出し元の TP の TP_STARTED または呼び出された TP の RECEIVE_ALLOCATE によって返されました。

conv_id
指定されたパラメーター。 会話識別子を提供します。 このパラメーターの値は、呼び出し元 TP の ALLOCATE または呼び出された TP のRECEIVE_ALLOCATE によって返されました。

reserv3
予約済みフィールド。

handle
指定されたパラメーター。 Microsoft Windows では、このフィールドは設定するイベント ハンドルを提供します。

最初の動詞からのリターン コード

AP_OK
プライマリ リターン コード。動詞は正常に実行されました。 特に、最初の動詞からのAP_OKのリターン コードは、パートナー TP から受信した 動詞REQUEST_TO_SEND 示すわけではないことに注意してください。 これは、非同期通知を受信する機能が登録されていることを示すだけです。

AP_UNSUCCESSFUL
主なリターン コード。送信要求通知が受信されていません。

AP_PARAMETER_CHECK
プライマリ リターン コード。パラメーター エラーのため、動詞は実行されませんでした。

AP_BAD_CONV_ID

セカンダリ リターン コード。 conv_id の値が、APPC によって割り当てられた会話識別子と一致しませんでした。

AP_BAD_TP_ID

セカンダリ リターン コード。 tp_id の値が、APPC によって割り当てられた TP 識別子と一致しませんでした。

AP_INVALID_SEMAPHORE_HANDLE

セカンダリリターンコード、 ハンドル の値が無効でした。

AP_COMM_SUBSYSTEM_ABENDED
プライマリ リターン コード。次のいずれかの条件を示します。

  • このメッセージ交換で使用されているノードで、ABEND が発生しました。

  • TP と PU 2.1 ノードの間の接続が切断されました (LAN エラー)。

  • TP のコンピューターの SnaBase で ABEND が発生しました。

    ABEND の理由を特定するには、システム管理者がエラー ログを調べる必要があります。

    AP_COMM_SUBSYSTEM_NOT_LOADED
    主なリターン コード。必要なコンポーネントを読み込めなかったか、動詞の処理中に終了しました。 そのため、通信を行うことができませんでした。 是正措置については、システム管理者に問い合わせてください。

    この戻りコードを ALLOCATE と共に使用すると、ローカル論理装置 (LU) をサポートする通信システムが見つからなかったことを示している可能性があります。 (たとえば、 TP_STARTED で指定されたローカル LU エイリアスが正しくないか、構成されていません)。 lu_alias または mode_name が 8 文字未満の場合は、これらのフィールドに右側のスペースが入力されていることを確認する必要があることに注意してください。 ALLOCATE 要求を満たすノードがないため、これらのパラメーターにスペースが入っていない場合、このエラーが返されます。

    ALLOCATE が複数のノードで構成された Host Integration Server クライアント システムに対してこのリターン コードを生成する場合、次の 2 つのセカンダリ リターン コードがあります。

    0xF0000001

    セカンダリ リターン コード。ノードが開始されていません。

    0xF0000002

    セカンダリ リターン コード。少なくとも 1 つのノードが開始されましたが、ローカル LU ( TP_STARTED が発行された場合) は、どのアクティブ ノードでも構成されていません。 この問題は、次のいずれかである可能性があります。

  • ローカル LU を持つノードが開始されていません。

  • ローカル LU が構成されていません。

    AP_CONVERSATION_TYPE_MIXED
    主なリターン コード。TP は、基本的な会話動詞とマップされた会話動詞の両方を発行しました。 1 つの会話で発行できる型は 1 つだけです。

    AP_INVALID_VERB_SEGMENT
    プライマリ リターン コード。VCB がデータ セグメントの終わりを越えています。

    AP_STACK_TOO_SMALL
    プライマリ リターン コード。アプリケーションのスタック サイズが小さすぎて動詞を実行できません。 アプリケーションのスタック サイズを増やしてください。

    AP_CONV_BUSY
    主なリターン コード。どの会話でも、一度に 1 つの未処理の会話動詞しか存在できません。 これは、ローカル TP に複数のスレッドがあり、複数のスレッドが同じ conv_idを使用して APPC 呼び出しを発行している場合に発生する可能性があります。

    AP_THREAD_BLOCKING
    プライマリ リターン コード。呼び出し元のスレッドは、既にブロック呼び出しにあります。

    AP_UNEXPECTED_DOS_ERROR
    プライマリ リターン コード。ローカル TP からの APPC 呼び出しの処理中に、オペレーティング システムから APPC にエラーが返されました。 オペレーティング システムのリターン コードは、secondary_rc 経由で返されます。 これは、Intel バイトスワップ順で表示されます。 問題が解決しない場合は、システム管理者に問い合わせてください。

非同期完了からのリターン コード

AP_OK
主なリターン コード。送信要求通知がパートナー TP から受信されました。

AP_CANCELLED
未処理 のTEST_RTS_AND_POST 動詞が終了しました。 これは、基になる会話の割り当てが解除されたか、AP_TP_ENDEDが発行された場合に発生します。 RECEIVE_AND_POSTと同様に、TP は会話を正しく終了し、TP を終了する可能性があることに注意してください。 この時点で別の動詞 (RECEIVE_IMMEDIATE など) を発行すると、会話が失敗した理由が示されます。

TP がこの動詞を発行する場合、RESET を除く任意の状態にすることができます。 状態の変更はありません。

5250 エミュレーターなど、多くの APPC アプリケーションの一般的な機能は、送信するパートナーの要求を検出するための要件です。 現時点では、これは APPC インターフェイスをポーリングしてパートナーの要求を検出することで行うことができます。 たとえば、アプリケーションで次のいずれかの動詞が発行される場合があります。

  • TEST_RTS

注釈

  • rts_rcvd フィールドをRECEIVE_IMMEDIATEしてチェックする

  • 0 バイトのSEND_DATA、rts_rcvd フィールドをもう一度チェックします。

    このポーリング アプローチに関連する問題の一部を次に示します。

  • アプリケーションは、APPC をポーリングするためにメイン作業を継続的に中断する必要があります。

  • パートナーの要求は、使用可能になるとすぐには検出されません。

  • これらのアプローチは、プロセッサを集中的に使用します。

    TEST_RTS_AND_POST動詞を使用すると、Windows (通常は 5250 エミュレーター) で実行されているアプリケーションは、パートナー TP が方向を送信するように要求したときに非同期通知を要求できます。

    APPC アプリケーションは通常、SEND 状態の間にTEST_RTS_AND_POST動詞を発行し、そのメイン処理を続行します。 パートナー TP からの送信方向の要求は、アプリケーションに非同期的に示されます。 パートナーの要求を処理した後、通常、アプリケーションは SEND 状態に戻り、 TEST_RTS_AND_POST再発行して続行します。

    TEST_RTS_AND_POST動詞は同期的に完了し、戻りコード AP_OKは非同期通知の要求が登録されたことを示します。 これは、要求対送信がパートナー TP から受信されたことを示していないことを強調することが重要です。

    送信するパートナーの要求を受信すると、非同期イベントの完了が発生します。 これは、ローカル TP の元の TEST_RTS_AND_POST 動詞が完了する前である可能性があることに注意することが重要です。 これは、ローカル TP のTEST_RTS_AND_POST動詞が発行される前、またはローカル TP のTEST_RTS_AND_POST動詞が処理されている間に、パートナーの送信要求が受信された場合に当たります。