MC_REQUEST_TO_SEND谓词向合作伙伴事务计划(TP)通知本地 TP 想要发送数据。
以下结构描述了 MC_REQUEST_TO_SEND 谓词使用的谓词控制块(VCB)。
语法
struct mc_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_M_REQUEST_TO_SEND。
opext
提供的参数。 指定谓词作扩展,AP_MAPPED_CONVERSATION。
reserv2
保留字段。
primary_rc
返回的参数。 指定 APPC 在谓词完成时设置的主要返回代码。 有效的返回代码因发布的 APPC 谓词而异。 有关此谓词的有效错误代码,请参阅返回代码。
secondary_rc
返回的参数。 指定 APPC 在谓词完成时设置的辅助返回代码。 有效的返回代码因发布的 APPC 谓词而异。 有关此谓词的有效错误代码,请参阅返回代码。
tp_id
提供的参数。 标识本地 TP。
此参数的值由调用 TP 中的 TP_STARTED 或调用的 TP 中的 RECEIVE_ALLOCATE 返回。
conv_id
提供的参数。 提供会话标识符。
此参数的值由调用 TP 中的 MC_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
主要返回代码;无法在处理谓词时加载或终止所需的组件。 因此,无法进行通信。 请联系系统管理员以采取纠正措施。当此返回代码与 MC_ALLOCATE一起使用时,它可能指示找不到任何通信系统来支持本地 LU。 (例如,使用 TP_STARTED 指定的本地 LU 别名不正确或尚未配置。请注意,如果 lu_alias 或 mode_name 少于 8 个字符,则必须确保这些字段填充右侧的空格。 如果这些参数未填充空格,则返回此错误,因为没有节点可以满足 MC_ALLOCATE 请求。
当MC_ALLOCATE为配置了多个节点的 Microsoft Host Integration Server 客户端系统生成此返回代码时,有两个辅助返回代码,如下所示:
0xF0000001
辅助返回代码;尚未启动任何节点。
0xF0000002
辅助返回代码;至少有一个节点已启动,但未在任何活动节点上配置本地 LU (TP_STARTED颁发 时)。 问题可能是以下任一问题:
未启动具有本地 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)
收到
没有状态更改。
合作伙伴计划通过以下谓词 的 rts_rcvd 参数接收请求到发送通知:
-
它还由MC_TEST_RTS上的AP_OK primary_rc表示。
请求到发送通知会立即发送到合作伙伴 TP;APPC 不会等到发送缓冲区填满或刷新为止。 因此,请求到发送通知可能会按顺序到达。 例如,如果本地 TP 处于 SEND 状态并发出 MC_PREPARE_TO_RECEIVE 后跟 MC_REQUEST_TO_SEND,则合作伙伴 TP 在 RECEIVE 状态下可能会收到请求到发送通知,然后再收到发送通知。 因此,可以通过接收谓词向 TP 报告请求到发送请求。
为了响应此请求,合作伙伴 TP 可以将对话更改为:
通过发出 MC_PREPARE_TO_RECEIVE 或 MC_RECEIVE_AND_WAIT来接收状态。
通过发出 MC_RECEIVE_AND_POST来PENDING_POST状态。
合作伙伴 TP 还可以忽略请求到发送。
当本地 TP 通过后续接收谓词 的 what_rcvd 参数接收下列值之一时,会话状态更改为 SEND:
使用MC_CONFIRMED AP_DATA_COMPLETE_CONFIRM_SEND和答复
AP_SEND
接收谓词是 MC_RECEIVE_AND_POST、 MC_RECEIVE_IMMEDIATE和 MC_RECEIVE_AND_WAIT。