Ibm midrange 大型数据结构和程序转储

我正在使用供应商为REST服务提供的SDK。为了使用SDK，我传递了几个数据结构。这些数据结构中有些是以数组作为子字段的数组数据结构，有些只是数组数据结构，有些只是普通的旧数据结构。例如，一个数组数据结构用Dim3750定义，几个子字段用Dim10定义。另一个定义为具有Dim3750的数组数据结构。作为一种视觉效果，它看起来是这样的：

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的前端，它使用likedsDS1和likedsDS2定义的参数，这样我就可以传回SDK返回的内容，而无需进行大量编码。另一个开发人员编写了复制本中的子过程来解析数据结构中返回的内容，以便将信息提供给我们的ERP包。同样，子流程的参数是使用likeds定义的

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

---

希望这是足够的背景，现在我们可以开始讨论我的问题。问题是，我们现在有程序转储，在消息被应答后，最多可以有9000多页。我假设这是由于我们各个子流程中的所有大型阵列数据结构造成的。我们目前处于测试模式，我正试图想出一个解决方案来解决大型程序转储问题。这个REST服务添加到的一些程序是时间敏感的，如果该程序在MSGW中运行一段时间，它将延迟后面等待的其他工作，然后我们会得到滚雪球效应，我或我团队中的某个人，在半夜接到一个电话，或者是一个交互式的工作，因为它正在写一个5000页的程序转储，用户变得不耐烦，关闭而不是等待。结果是一样的，有人会要求我们尽快修复它。关于如何解决这个问题，你有什么想法吗？

我想……如果程序转储是例行公事，足以导致问题……那么你还有其他更严重的问题

如果你仍然依赖于MSGW的一份工作，而该工作是手工完成的，那么你还有另一个问题

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

全局错误处理应该考虑所有其他问题，包括转储程序、保存作业日志和通知您的团队

---

通读IBM红皮书中的第7章，异常和错误处理。

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

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

Charles，我认为由于系统询问是否在转储列表中打印更多行而导致的MSGW问题与由于异常而导致的查询消息而导致的MSGW问题不同。@Barbaramoris，无参数。但正如我读到的，作业的初始MSGW等待手动回答。这是个问题。他可以随时将QPPGMDMP更改为*NOMAX，以处理垃圾场的大小。@Charles，我为造成的混乱道歉。首先，程序转储对我们来说不是例行公事。如果程序转储发生，我正在尝试提前计划。我们可以尝试并计划一些常见的事情，我就是这么做的，但最终会出现一些未处理的异常。Barbara Morris的说法是正确的，因为有一个未处理的异常，该程序不在MSGW中。当标准错误处理失败且全局错误处理生成程序转储假脱机文件时，该假脱机文件将达到最大假脱机文件页数。我很欣赏红皮书的建议。我已经读了一些，但是我会再读一遍，看看我错过了什么。我会和我的iSeries管理员联系，看看这是否有可能。有时候他们有点…特别…当涉及到线轴文件上的*NOMAX时。谢谢，@Barbaramoris。负责这段代码的开发人员决定使用copybooks。我会同意你的建议。