AUTODST： Language Environment 自动存储调整

通过将 CICS 系统初始化参数 AUTODST 设置为 "是"，可以选择激活 Language Environment® 的 CICS® 自动存储调整功能。 如果在具有活动的存储器密集型程序的系统中使用此功能，那么可以通过最大限度地减少 GETMAIN 和 FREEMAIN 请求 (否则将需要这些请求) 来节省 CPU 消耗。 但是，如果在不适合的环境 (例如，处理其存储需求在不同执行之间差异很大的事务的系统) 中使用，那么自动存储器调整也会导致存储分段，从而导致 CICS 出现存储空间不足 (SOS)。

工作原理： Language Environment 系统级自动存储调整

Language Environment 使用从 获取的每个运行单元的存储空间。 CICS 每个程序首次使用时， Language Environment 会告诉 CICS 运行单位工作区 (RUWA) 需要多少存储空间。 自动存储调整激活时， Language Environment 会监控每个主程序的执行。 如果在每次程序执行结束时需要分配额外的存储空间， Language Environment 会保留这一信息。 下次执行程序时， Language Environment 会增加初始存储分配，以包含这些额外的存储空间。 这一过程有助于最大限度地减少 CICS 必须执行的 GETMAIN 和 FREEMAIN 请求的数量。

自动存储器调整对于发出许多动态调用的程序特别有用，因为这类程序很容易超过其初始存储器分配。 它还消除了为 COBOL 单个程序手动调整存储的需要。

不过，你应该知道，一旦 Language Environment 增加了程序的初始存储分配，就永远不会再减少。 如果程序执行需要异常大的存储量，可能是因为用户已激活程序的自用功能，那么会将此存储量分配给程序的所有后续执行。 因此在极少数情况下，您可以发现自动存储器调整会导致为某些程序分配过多的存储器。

AUTODST 可能导致存储分段和 SOS 情况的原因

Language Environment 自动存储调整的工作原理是，在需要时增加运行单元的初始存储分配。

CICS 存储管理器根据需要按 1M 扩展数据块的倍数将存储器分配给每个扩展动态存储区。 如果 DSA 中没有足够的可用存储器来满足请求，那么 CICS 存储管理器会从 EDSALIM 总计将存储器分配给 DSA ，或者如果没有剩余更多未分配的扩展数据块，那么它会从另一个完全可用的 DSA 中窃取存储器以满足请求。

CICS 存储管理器工作原理的两个主要事实，是 Language Environment 自动存储调整造成的严重碎片问题和 SOS 状况：
  • 如果 GETMAIN 请求大于 1M 扩展数据块，那么 CICS 存储管理器会找到多个 1M 相邻扩展数据块以满足该请求。 释放时，不会将多兆字节扩展数据块分解为单个 1M 扩展数据块。 它已释放，但仍保持为多兆字节扩展数据块。
  • GETMAIN 请求通过第一个拟合来满足，而不是最佳拟合。

以下示例可帮助您了解这两个事实为何会导致存储分段。

示例：

您具有使用 AUTODST=YES运行的 CICS 区域。 系统具有多种多样的事务集，但以下三个事务大部分时间都在使用，它们使用的是 31 位存储:
  • TRN1 由单个运行单元组成，该运行单元总共使用 6M ，由自动存储器调整确定。
  • TRN2 由单个运行单元组成，该运行单元使用由自动存储器调整确定的总计 25K 。
  • TRN3 由单个运行单元组成，该运行单元使用由自动存储器调整确定的总计 500K 。

系统已通过 EDSALIM=100M启动，并且 TRN1 运行。 Language Environment 从 获取 ，用于。 CICS 6M TRN1 CICS 存储管理器会找到 6M 连续空闲存储空间，并将其分配给 EUDSA。 当 TRN1 结束时， CICS 存储管理器会释放存储，但仍会为 EUDSA 分配一个空的 6M extent。

当 TRN2 运行时。 它请求 25K。 CICS 存储管理器发现它将适合 6M 空扩展数据块，因此将 25K 从该扩展数据块中提供给具有该扩展数据块中剩余 5.975M 存储器的 TRN2 。

现在，另一个 TRN1 运行，它需要 6M，但上述扩展数据块中的其余 5.975M 太小，因此 CICS 存储管理器会为此任务找到另一个 6M 连续可用存储器。 当 TRN1 结束时， CICS 释放存储器，但 EUDSA 现在有第二个 6M 空扩展数据块。

TRN3 运行且需要 500K 。 CICS 存储管理器为该事务提供第二个空 6M 扩展数据块的 500K ，从而使 5.5M 可用。

随着具有较小存储器需求的每个事务进入并获取 6M 扩展数据块， CICS 存储管理器将尝试为 6M 事务分配更多数据块。 系统将很快拥有大量 6M 扩展数据块，直到 CICS 无法再找到 6M 的连续可用存储器，从而导致 SOS 情况。

实用建议:
  • 评估正在系统中运行的事务。 打开 AUTODST 以获取适当的用例。 如果您具有具有各种事务类型的系统，请关闭 AUTODST。
  • 如果需要 Language Environment 存储调整，可考虑使用 Language Environment 存储调整用户退出 CEECSTX 在程序级别自定义 Language Environment 存储调整。

通过 Language Environment 用户退出 CEECSTX 定制 Language Environment 存储调整

您可以使用 Language Environment 存储调整用户退出 CEECSTX 来更改自动存储调整机制的行为。 用户出口可以启用或禁用特定程序的存储调整，如果您有一个应用程序的存储需求在不同执行之间有很大差异，那么您可能会发现这很有用。 它还可以提供初始存储分配的起始值，并可用于限制 Language Environment 在自动存储调整过程中分配的最大存储量。

如果以前使用 CEECSTX 用户退出作为 Language Environment 存储调整方法，您可能会发现自动存储调整机制提供了相同的功能，而无需用户退出。 您需要决定使用哪种机制作为主要的存储调整方法，因为当您运行 CICS 并进行自动存储调整时，CEECSTX 用户出口的功能有限。 自动存储器调整通过监视存储器分配来运行，而存储器调整用户出口 CEECSTX 会监视用户应用程序所使用的实际存储器。 尽管如此，与基于 CEECSTX 出口的调整方法相比，自动存储器调整会产生较少的开销。 此外，自动存储器调整为事务调用的每个初始程序提供调整，而 CEECSTX 出口仅为该出口用作其输入的表中包含的那些程序提供调整。 这意味着自动存储器调整可以通过调整更多程序使用的存储器来提供更大的好处。

有关CEECSTX的更多信息，请参阅《 z/OS Language Environment 定制》 中的 Language Environment 存储调优用户退出。