给定的自动显示文件刷新如何工作？
How does the given automated display file refresh work?
我举了个例子
http://www-01.ibm.com/support/docview.wss?uid=nas8N1010188
我意识到 'DFRWTR *NO' 是没有必要的。为什么？
KNUM 1 在 rpgle 中被转换为 MAXDEV(*FILE)。它对功能有何贡献？ （程序编译，但没有它不会刷新）
关于'READ TIMED'，为什么我们不能使用记录格式来读取呢？
（是外部描述的文件，可以编译，但不刷新）
非常感谢
彼得
DFRWRT(*YES)（CRTDSPF 的默认值）意味着 IBM i 将接受来自 HLL 程序的显示缓冲区并立即 return 控制 HLL 程序。 在第二个进程中，它实际上会将缓冲区发送到终端。 编辑：没有第二个进程；屏幕在下一次读取时发送。请参阅查尔斯的评论。 END EDIT 因此，使用 DFRWRT(*YES)，程序可以在用户看到显示之前继续运行。对于这个例子，这是无关紧要的，因为下一个操作是 READ，所以程序将停在那里等待输入。
此处的设计称为'Read from Invited Devices'，自动刷新是该技术唯一幸存的用途。最初，read from invited 是为一个程序——一项工作——控制多个终端而设计的。这个想法是将一个屏幕写入多个显示设备，并邀请它们在准备就绪时做出响应。第一个响应的人将满足 READ 并且程序将继续。如果 none 的设备在 WAITRCD() 间隔内响应，则 INVITE 将过期（作为 I/O 错误）并且程序将获得控制权 - 大概是将更新的信息重新发送到各种终端。
这就是我们告诉 RPG 有多个设备 - MAXDEV(*FILE) 的原因，也是我们从文件读取但写入记录格式的原因。想象一种安排，其中多个设备以老板-工人关系安排。您的程序将向老板设备发送 BOSS 记录格式，所有工作设备将获得 WORKER 记录格式。但是你不想只等老板回应；你需要听取每个人的意见。所以你阅读了文件。
可以在 Application Display Programming 手册中找到更多信息。知识中心 > 编程 > 设备 > 应用显示编程
我举了个例子 http://www-01.ibm.com/support/docview.wss?uid=nas8N1010188
我意识到 'DFRWTR *NO' 是没有必要的。为什么？
KNUM 1 在 rpgle 中被转换为 MAXDEV(*FILE)。它对功能有何贡献？ （程序编译，但没有它不会刷新）
关于'READ TIMED'，为什么我们不能使用记录格式来读取呢？ （是外部描述的文件，可以编译，但不刷新）
非常感谢
彼得
DFRWRT(*YES)（CRTDSPF 的默认值）意味着 IBM i 将接受来自 HLL 程序的显示缓冲区并立即 return 控制 HLL 程序。 在第二个进程中，它实际上会将缓冲区发送到终端。 编辑：没有第二个进程；屏幕在下一次读取时发送。请参阅查尔斯的评论。 END EDIT 因此，使用 DFRWRT(*YES)，程序可以在用户看到显示之前继续运行。对于这个例子，这是无关紧要的，因为下一个操作是 READ，所以程序将停在那里等待输入。
此处的设计称为'Read from Invited Devices'，自动刷新是该技术唯一幸存的用途。最初，read from invited 是为一个程序——一项工作——控制多个终端而设计的。这个想法是将一个屏幕写入多个显示设备，并邀请它们在准备就绪时做出响应。第一个响应的人将满足 READ 并且程序将继续。如果 none 的设备在 WAITRCD() 间隔内响应，则 INVITE 将过期（作为 I/O 错误）并且程序将获得控制权 - 大概是将更新的信息重新发送到各种终端。
这就是我们告诉 RPG 有多个设备 - MAXDEV(*FILE) 的原因，也是我们从文件读取但写入记录格式的原因。想象一种安排，其中多个设备以老板-工人关系安排。您的程序将向老板设备发送 BOSS 记录格式，所有工作设备将获得 WORKER 记录格式。但是你不想只等老板回应；你需要听取每个人的意见。所以你阅读了文件。
可以在 Application Display Programming 手册中找到更多信息。知识中心 > 编程 > 设备 > 应用显示编程