大数据结构和程序转储

Question

我正在使用供应商提供的SDK作为REST服务。为了使用SDK，我传递了几个数据结构。这些数据结构中有些是数组数据结构，数组作为子字段，有些只是数组数据结构，有些只是普通的旧数据结构。例如，用Dim(3750)定义数组数据结构，用Dim(10)定义多个子字段。另一个被定义为带有Dim(3750)的数组数据结构。从视觉上看，应该是这样的：

D DS1                     Dim(3750)
D  subfield1      10A     Dim(10)
D  subfiled2       7  4   Dim(10)

D DS2                     Dim(3750)
D  subfield1      40A
D  subfield2      15  4

有更多的子字段，但我只是试图提供一个简短的可视化。我们有包含反映DS1和DS2的参数的子过程。我编写了一个服务程序，作为供应商SDK的前端，它使用用相似(DS1)和相似(DS2)定义的参数，这样我就可以传回从SDK返回的内容，而不必做大量的编码。另一个开发人员编写了文案中的子过程来解析数据结构中返回的内容，以便将信息提供给我们的ERP包。同样，子过程的参数是使用likeds定义的。

我们的程序的规范是在出问题时产生一个程序转储。这是供应商ERP的默认行为，因为我们修改了他们的一些程序并采用了他们的一些标准，这也成为我们的规范。由于向我们自己的自定义程序和ERP供应商的程序的修改版本添加了代码以利用这一新的REST服务，如果出了问题，生成程序转储需要花费很长时间，我们通常必须回答一条消息，当我们到达程序转储的最大假脱机文件页时。通常，我们只是回答NOMAX，然后继续前进。

希望这是足够的背景，现在我们可以讨论我的问题了。问题是，我们现在有程序转储，在消息被回复之后，程序转储可以达到9,000+页面。我假设这是由于我们的各个子过程中的所有大型数组数据结构所致。我们目前处于测试模式，我正试图找到一个解决方案来解决大型程序转储问题。这个REST服务被添加到的一些程序是时间敏感的，如果这个程序在MSGW中停留一段时间，它会延迟其他工作在它后面等待，然后我们得到一个滚雪球效应，然后我，或者我的团队中的某个人，在半夜接到一个电话，或者是一个交互的工作，它需要很长时间才能结束，因为它正在写一个5000页的程序转储，用户会不耐烦地停止等待，而不是等待。结果是一样的，有人会要求我们尽快解决它。对我如何解决这个问题有什么想法吗？

Answer 1

另一种可以减少转储大小的方法是将文案中的程序移到一个单独的模块中。如果它们被复制到多个程序中，甚至被复制到服务程序中。

Answer 2

您可以尝试使用OVRPRTF使用MAXRCDS(*NOMAX)覆盖打印机文件QPPGMDMP。

Answer 3

IMO...If程序转储是足够例行的，足以导致problems...then，您还有其他更严重的问题。

如果你仍然依赖于一份去MSGW的工作，并被手工回答，那么你还有另外一个问题。

您的程序，特别是web服务程序，应该很好地处理任何合理可能的错误。

全局错误处理应该负责其他一切，转储程序，保存作业日志并通知您的团队。

阅读谁知道你能用RPG IV做这件事？红皮书中的第7章，异常和错误处理。