大数据结构和程序转储

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中稍微停留一下，它会延迟在其后面等待的其他工作，然后我们得到一个滚雪球效应我和我团队中的某个人获得在半夜打电话或者它是一个永远结束的交互式工作，因为它写出了5,000页的程序转储，用户变得不耐烦而且关闭而不是等待。结果将是相同的，有人会要求我们快速修复它。关于如何解决这个问题的任何想法？

Answer 1

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

Answer 2

IMO ......如果程序转储的常规性足以导致问题......那么您还有其他更严重的问题。

如果您仍然依靠转到MSGW的工作并手动接听，那么您还有另一个问题。

您的程序，尤其是Web服务程序，应该能够妥善处理任何可能的错误。

全局错误处理应该处理其他所有事情，转储程序，保存作业日志并通知您的团队。

在Who Knew You Could Do That with RPG IV? IBM红皮书中阅读第7章异常和错误处理。

Answer 3

另一种可能减少转储大小的可能性是将副本中的过程移动到单独的模块中。甚至是服务程序，如果它们被复制到多个程序中。