我正在使用供应商为REST服务提供的SDK。 为了使用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的前端，它使用likeds(DS1)和likeds(DS2)定义的参数，这样我就可以传回从SDK返回的内容，而无需进行大量编码。另一个开发人员编写了副本中的子过程来解析数据结构中返回的内容，以便将信息提供给我们的 ERP 包。 同样，子过程的参数是使用 likeds 定义的。
我们程序的规范是在出现问题时生成程序转储。 这是供应商ERP的默认行为，由于我们修改了他们的一些程序并采用了他们的一些标准，这也成为我们的规范。 自从将代码添加到我们自己的自定义程序和 ERP 供应商程序的修改版本以使用这个新的 REST 服务以来，如果出现问题，生成程序转储需要很长时间，我们通常必须回答一条消息，我们已经到达程序转储的最大假脱机文件页面。 通常，我们只是回答NOMAX并继续前进。
希望这是足够的背景，现在我们可以解决我的问题了。 问题是我们现在的程序转储在消息得到答复后最多可以达到 9,000+ 页。 我假设这是由于我们各个子过程中的所有大型数组数据结构。 我们目前处于测试模式，我正在尝试提出一个解决方案来解决大型程序转储问题。 添加此 REST 服务的某些程序对时间敏感，如果该程序在 MSGW 中停留了一段时间，它将延迟等待它后面的其他作业，然后我们得到滚雪球效应，我或我团队中的某个人在半夜接到电话，或者这是一个需要永远结束的交互式作业，因为它正在写出一个 5,000 页的程序转储用户变得不耐烦并关闭而不是等待。 结果将是相同的，有人会要求我们快速修复它。 关于如何解决这个问题的任何想法？
另一种可能性是将副本中的过程移动到单独的模块中，这将减小转储的大小。甚至到服务程序中，如果它们被复制到多个程序中。
您可以尝试使用 OVRPRTF 使用 MAXRCDS(*NOMAX) 覆盖打印机文件 QPPGMDMP。
IMO...如果程序转储是例行的，足以导致问题...然后你还有其他更严重的问题。
如果您仍然依赖前往MSGW的工作并被手动回答，那么您还有另一个问题。
您的程序(尤其是 Web 服务程序)应妥善处理任何合理可能的错误。
全局错误处理应该处理其他所有事情，转储程序，保存作业日志并通知您的团队。
通读第 7 章，异常和错误处理，在谁知道你可以用 RPG IV 做到这一点？IBM红皮书。