出站数据
本部分介绍从本地节点到应用程序的出站数据流。 所述协议的总体结构适用于系统服务控制点 (SSCP) 和主逻辑单元 (PLU) 连接，但某些功能（例如使用延迟请求模式）仅适用于 PLU 连接。
本地节点将源自主机的数据呈现给不同连接上的应用程序，具体取决于数据流经的 SNA 会话，如下所示：
源自主机 SSCP 并定向到 Host Integration Server 逻辑单元 (LU) 的功能管理数据网络服务 (FMD NS)（会话服务）数据和功能管理数据 (FMD) 被发送到 SSCP 连接上的应用程序。
源自主机 PLU 并定向到 SNA 服务器 LU 的 FMD 数据被发送到 PLU 连接上的应用程序。
对于所有连接，只有 FMD 请求作为 Data 消息（message-type = DATAFMI）呈现给应用程序。 DFC 和会话控制请求用于生成 Status-Control 消息。 （有关详细信息，请参阅 Status-Control 消息。）
在向应用程序发送 Data 消息之前，本地节点执行请求中响应头 (RH) 指示符所需的数据流控制状态更改。
SNA 请求传输头 (TH) 和 RH 指示符对于出站 Data 消息上的应用程序不可用。 相反，本地节点在 Data 消息头中提供反映 RH 指示符子集设置的应用程序标志，但由本地节点对其进行解释，以保护应用程序不受更模糊的链接和括号使用方面的影响。 有关可用标志的说明以及本地节点针对出站数据使用这些标志的方式，请参阅应用程序标志。
对于出站数据，标准功能管理接口 (FMI) 的第一个字节为 RU[0]，FMI 逻辑单元应用程序 (LUA) 变量的第一个字节为 TH[0]。
从本地节点到应用程序的所有 Data 消息都包含一个消息键。 本地节点为传入应用程序的每个出站数据流维护一个唯一的消息键序列。 当本地节点向特定连接上的应用程序发送 Data 消息时，它将出站序列中的下一个消息键置于消息头，设置应用程序标志，并将消息发送至应用程序。 这意味着消息键将唯一标识本地节点和应用程序之间特定连接上的 Data 消息。 请注意，本地节点也会在出站 Status-Control 请求消息上放置消息键。
Host Integration Server 强制实施的确认协议反映了在 SNA 会话上使用的链响应协议和请求模式，如下所示：
出站 RQD 请求生成 Data 消息，并在消息头中设置 ACKRQD。
出站 RQE 请求生成 Data 消息，但不设置 ACKRQD。
出站 RQN 请求生成 Data 消息，但不设置 ACKRQD。
如果会话使用主即时请求模式，则设置了 ACKRQD 的 Data 消息必须由应用程序予以确认，才能继续接收 Data 消息。
如果会话使用主延迟请求模式，则设置了 ACKRQD 的 Data 消息无需由应用程序立即确认。 将继续接收 Data 消息。
请注意，Host Integration Server 对所有连接强制实施出站数据确认协议即时响应模式的等效操作。 应用程序必须按顺序发送确认。
如果本地节点在传入应用程序的 Data 消息的消息头中设置了 ACKRQD 字段，则表示需要对此 Data 消息进行确认。 应用程序确认出站 Data 消息的方法是向同一连接上的本地节点发送 Status-Acknowledge 消息（其中包含与 Data 消息相同的消息键和序列号字段）。
收到 Status-Acknowledge(Ack) 后，本地节点会将消息键与未完成的出站消息相关联，并生成对相应 SNA 请求的 SNA 肯定响应。
应用程序应该使用 Status-Acknowledge(Nack-1) 消息作为否定确认。 收到 Status-Acknowledge(Nack-1) 后，本地节点会将消息与未完成的出站消息相关联，并生成对相应 SNA 请求的 SNA 否定响应和检测数据。 应用程序提供检测数据，该检测数据应作为 Status-Acknowledge(Nack-1) 消息的一部分与否定响应一起提供，并且必须包含与判定为否定确认的 Data 消息相同的消息键、应用程序标志和序列号字段。
由加急流请求引发的 Status-Control 消息可以随时发送，并且不影响向正常流出站 Data 消息发送肯定或否定确认。 它们在 Data 消息和匹配的 Status-Acknowledge 消息之间出现纯属巧合。 有关哪些 Status-Control 消息对应于 SNA 请求的详细信息，请参阅 Status-Control 消息。
如果从主机的正常流请求格式中检测到错误，或者请求不适合会话的状态，则本地节点将为应用程序生成错误的 Data 消息，并具有以下特征：
SDI 和 ECI 应用程序标志已设置。
与错误关联的检测代码占用 Data 消息的前四个字节。 （有关详细信息，请参阅 Status-Control 消息。）
ACKRQD 已设置。
应用程序应返回 Status-Acknowledge(Ack)，且本地节点将生成一个否定响应，其中包含与检测到的错误相对应的检测代码。 此机制具有以下作用：
通知应用程序检测到的错误。
允许应用程序在本地节点向 Data 消息发送否定响应之前响应任何之前接收的数据。
在应用程序正在接收一系列 RQE 链的会话上，本地节点将保留每个链的相关信息（以防应用程序需要向任何链发送否定响应）。 如果本地节点已用完相关表条目，它将尝试分配更多条目，并且（如果此操作失败）将被迫终止会话。 若要防止出现这种情况，应用程序应该为在这种情况下不希望拒绝的 RQE 数据提供 Status-Acknowledge(Ack) 消息。 5个连续 RQE 链之后的响应应该已经足够。 此类消息称为“礼节性确认”，不会对主机做出响应，而只是自由的内部相关数据。
以下六张图阐释了在本地节点和应用程序之间强制实施的数据确认协议，并展示了应用程序生成肯定和否定 Status-Acknowledg 消息的效果。
这些图形展示了以下内容：
SNA 请求/响应中的相关 RH 标志。
SNA 请求/响应的序列号。
SNA 请求/响应和 Status-Acknowledge 消息上的任何检测数据（显示为“SENSE=...”）。
Data 消息中的 ACKRQD 字段。
Data 消息中的消息键。
为简单起见，我们假定所有消息都是在同一 PLU 会话上传输的 FM 数据。
在下图中，应用程序接受对应于确切响应 RU 的 Data 消息。
应用程序发送对应于确切响应 RU 的 Data 消息在下图中，应用程序接受对应于多 RU 确切响应链的 Data 消息。
应用程序接受对应于多 RU 确切响应链的 Data 消息在下图中，应用程序拒绝对应于确切响应链的 Data 消息。
应用程序拒绝对应于确切响应链的 Data 消息在下图中，应用程序拒绝对应于多 RU 确切响应链的 Data 消息。
应用程序拒绝对应于多 RU 确切响应链的 Data 消息下图中，本地节点强制实施即时响应模式。 响应必须按顺序发送。 应用程序拒绝第二个异常响应链并接受确切响应链，这意味着接受第三个异常响应链。
本地节点强制实施即时响应模式下图中，本地节点在发往应用程序的数据中检测出链接错误（RQD 而不是 EC）。 (此示例要求接收检查 0x4007有效。有关详细信息，请参阅打开 SSCP Connection.)
本地节点在发往应用程序的数据中检测出链接错误