REQUEST_TO_SEND

REQUEST_TO_SEND谓词通知合作伙伴事务计划 (TP) 本地 TP 要发送数据。

以下结构描述了REQUEST_TO_SEND谓词使用的谓词控制块 (VCB )

语法

  
struct request_to_send {  
    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;  
};   

成员

opcode
提供的参数。 指定谓词操作代码,AP_B_REQUEST_TO_SEND。

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 返回。

返回代码

AP_OK
主要返回代码;谓词已成功执行。

AP_PARAMETER_CHECK
主要返回代码;由于参数错误,谓词未执行。

AP_BAD_CONV_ID

辅助返回代码; conv_id 的值与 APPC 分配的会话标识符不匹配。

AP_BAD_TP_ID

辅助返回代码; tp_id 的值与 APPC 分配的 TP 标识符不匹配。

AP_STATE_CHECK
主要返回代码;谓词未执行,因为它是在无效状态下发出的。

AP_R_T_S_BAD_STATE

辅助返回代码;当 TP 发出此谓词时,会话未处于允许状态。

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_aliasmode_name 少于 8 个字符,则必须确保用右侧空格填充这些字段。 如果这些参数未用空格填充,则返回此错误,因为没有可用于满足 ALLOCATE 请求的节点。

    ALLOCATE 为配置了多个节点的 Microsoft Host Integration Server 客户端系统生成此返回代码时,有两个辅助返回代码,如下所示:

    0xF0000001

    辅助返回代码;尚未启动任何节点。

    0xF0000002

    辅助返回代码;至少已启动一个节点,但发出 TP_STARTED 时本地 LU () 未在任何活动节点上配置。 问题可能出在以下任一方面:

  • 未启动具有本地 LU 的节点。

  • 未配置本地 LU。

    AP_CONVERSATION_TYPE_MIXED
    主返回代码;TP 已发出基本和映射对话谓词。 在单个会话中只能发出一种类型。

    AP_INVALID_VERB_SEGMENT
    主要返回代码;VCB 超出了数据段的末尾。

    AP_STACK_TOO_SMALL
    主要返回代码;应用程序的堆栈大小太小,无法执行谓词。 增加应用程序的堆栈大小。

    AP_CONV_BUSY
    主返回代码;任何对话一次只能有一个未完成的对话谓词。 如果本地 TP 具有多个线程,并且多个线程使用相同的 conv_id发出 APPC 调用,则可能会发生这种情况。

    AP_THREAD_BLOCKING
    主要返回代码;调用线程已在某个阻塞调用中。

    AP_UNEXPECTED_DOS_ERROR
    主要返回代码;操作系统在处理来自本地 TP 的 APPC 调用时向 APPC 返回了错误。 已通过 secondary_rc 返回了操作系统返回代码。 此返回代码是以 Intel 字节交换顺序显示的。 如果问题持续出现,请咨询系统管理员。

备注

当 TP 发出此谓词时,会话可能处于以下任何状态:

确认

PENDING_POST (OS/2)

RECEIVE

没有状态更改。

合作伙伴计划通过以下谓词的 rts_rcvd 参数接收请求发送通知:

  • 确认

  • RECEIVE_AND_POST

  • RECEIVE_AND_WAIT

  • RECEIVE_IMMEDIATE

  • SEND_DATA

  • SEND_ERROR

    它还由TEST_RTS上的AP_OK primary_rc指示。

    请求发送通知会立即发送到合作伙伴 TP;APPC 不会等到发送缓冲区填满或刷新。 因此,请求发送通知可能会不按顺序到达。 例如,如果本地 TP 处于“发送”状态,并且 PREPARE_TO_RECEIVE 后跟 REQUEST_TO_SEND,则处于 RECEIVE 状态的合作伙伴 TP 可能会在收到发送通知之前收到请求发送通知。 出于此原因,可以通过接收谓词向 TP 报告请求发送。

    为了响应此请求,合作伙伴 TP 可以将对话更改为:

  • 通过发出 PREPARE_TO_RECEIVERECEIVE_AND_WAIT来接收状态。

  • 通过 发出RECEIVE_AND_POST PENDING_POST状态。

    合作伙伴 TP 还可以忽略请求发送。

    当本地 TP 通过后续接收谓词的 what_rcvd 参数接收以下值之一时,本地 TP 的会话状态更改为 SEND:

  • 使用 CONFIRMED AP_CONFIRM_SEND和答复

  • 使用 CONFIRMED AP_DATA_COMPLETE_CONFIRM_SEND和答复

  • 使用 CONFIRMED AP_DATA_CONFIRM_SEND和答复

  • AP_SEND

    接收谓词是 RECEIVE_AND_POSTRECEIVE_IMMEDIATERECEIVE_AND_WAIT