大数据结构和程序转储
Large Data Structure and Program Dumps
我正在使用供应商为 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 页的程序转储，用户变得不耐烦并关闭而不是等待。结果是一样的，有人会要求我们尽快修复它。关于如何解决这个问题有什么想法吗？
IMO...如果程序转储的例行程序足以引起问题...那么您就会遇到其他更严重的问题。
如果您仍然依赖 MSGW 的工作并得到人工答复，那么您还有另一个问题。
您的程序，尤其是 Web 服务程序，应该优雅地处理任何合理可能的错误。
全局错误处理应该处理其他所有事情，转储程序、保存作业日志并通知您的团队。
通读 Who Knew You Could Do That with RPG IV? IBM 红皮书的第 7 章，异常和错误处理。
您可以尝试使用 OVRPRTF 用 MAXRCDS(*NOMAX) 覆盖打印机文件 QPPGMDMP。
另一种减小转储大小的可能性是将 copybook 中的过程移动到一个单独的模块中。如果它们被复制到多个程序中，甚至可以复制到一个服务程序中。
我正在使用供应商为 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 页的程序转储，用户变得不耐烦并关闭而不是等待。结果是一样的，有人会要求我们尽快修复它。关于如何解决这个问题有什么想法吗？
IMO...如果程序转储的例行程序足以引起问题...那么您就会遇到其他更严重的问题。
如果您仍然依赖 MSGW 的工作并得到人工答复，那么您还有另一个问题。
您的程序，尤其是 Web 服务程序，应该优雅地处理任何合理可能的错误。
全局错误处理应该处理其他所有事情，转储程序、保存作业日志并通知您的团队。
通读 Who Knew You Could Do That with RPG IV? IBM 红皮书的第 7 章，异常和错误处理。
您可以尝试使用 OVRPRTF 用 MAXRCDS(*NOMAX) 覆盖打印机文件 QPPGMDMP。
另一种减小转储大小的可能性是将 copybook 中的过程移动到一个单独的模块中。如果它们被复制到多个程序中，甚至可以复制到一个服务程序中。