给定的自动显示文件刷新如何工作？答案

【问题标题】：How does the given automated display file refresh work?给定的自动显示文件刷新如何工作？
【发布时间】：2015-02-19 23:16:48
【问题描述】：

我举了一个例子 http://www-01.ibm.com/support/docview.wss?uid=nas8N1010188

我意识到“DFRWTR *NO”不是必需的。为什么？

KNUM 1 已在 rpgle 中转换为 MAXDEV(*FILE)。它对功能有何贡献？（程序可以编译，但没有它就不会刷新）

关于'READ TIMED'，为什么不能使用记录格式来读取呢？（它是一个外部描述的文件，它可以编译，但不会刷新）

非常感谢
彼得

【问题讨论】：

标签： ibm-midrange rpgle

【解决方案1】：

DFRWRT(*YES)（CRTDSPF 的默认值）意味着 IBM i 将接受来自 HLL 程序的显示缓冲区并立即将控制权返回给 HLL 程序。 在第二个进程中，它实际上会将缓冲区发送到终端。 编辑：没有第二个进程；屏幕在下一次 READ 时发送。见查尔斯的评论。 END EDIT 因此，使用 DFRWRT(*YES) 程序可以在用户看到显示之前继续运行。对于这个例子，这是无关紧要的，因为下一个操作是 READ，所以程序将停在那里并等待输入。

这里的设计称为“从受邀设备读取”，自动刷新是该技术唯一幸存的用途。最初，从受邀中读取的目的是为一个程序 - 一项工作 - 控制多个终端。这个想法是为多个显示设备编写一个屏幕，并邀请它们在准备好时做出响应。第一个响应的将满足 READ 并且程序将继续。如果在 WAITRCD() 间隔内没有任何设备响应，则 INVITE 将过期（作为 I/O 错误）并且程序将获得控制权 - 可能会将更新的信息重新发送到各个终端。

这就是我们告诉 RPG 有多个设备 - MAXDEV(*FILE) 的原因，也是我们从文件读取但写入记录格式的原因。想象一种安排，其中多个设备以老板 - 工人的关系排列。您的程序将向老板设备发送 BOSS 记录格式，所有工作人员设备将获得 WORKER 记录格式。但你不想只等老板回应；你需要得到每个人的意见。所以你阅读文件。

更多信息可以在Application Display Programming 手册中找到。知识中心 > 编程 > 设备 > 应用显示编程

【讨论】：

非常感谢您的回答。这就是我要找的书。在这种情况下，只有一种记录格式，所以它看起来更像是一个规则而不是一个原因。来自书 pg 69：“不能在 read-from-invited-devices 操作中指定记录格式。从显示器返回的记录格式与写入显示站的最后记录格式相同。”仅供参考：第 75、83、249 页。您能否推荐一些有关读取文件而不是记录的机制的材料？
我发现了这个：rpg400-l.midrange.narkive.com/E2wBSSoT/…
实际上使用 DFRWRT(*YES)，屏幕不是由“第二个进程”发送的。而是在 READ 完成之前不会发送屏幕。 www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/cl/… "指定延迟写入数据，直到发出读取请求时将其与其他数据一起写出。"
我找不到规范参考。感谢查尔斯的更好解释。
来自rpg400-l.midrange.narkive.com/E2wBSSoT/…：Scott Klement 12 年前使用文件名读取将读取该文件中的下一条记录，无论它碰巧是什么记录格式。使用记录格式名称读取将读取您指定的格式名称的下一条记录。如果文件只有一种记录格式，它们的行为方式完全相同。所以如果是真的，工人和老板记录格式的逻辑是不相关的。你怎么看？