DLPAR 操作集成到应用程序中

可以通过以下方式将 DLPAR 操作集成到应用程序中:

  • 使用基于脚本的方法,其中用户将一组 DLPAR 脚本安装到目录中。 在运行 DLPAR 操作时,将调用这些脚本。 这些脚本设计用于从外部重新配置应用程序。
  • 使用 SIGRECONFIG 信号,用于捕捉每个已注册进程的信号。 该信号方法假定应用程序经编码可捕捉该信号,且信号处理程序将重新配置应用程序。 信号处理程序调用接口以确定 DLPAR 操作的性质。

这两种方法都遵循相同的高级别结构。 任一方法都可用于提供对 DLPAR的支持,尽管只有基于脚本的机制可用于管理与 工作负载管理器 软件分区 (处理器集) 相关的 DLPAR 依赖关系。 没有任何 API 与 工作负载管理器相关联,因此使用信号处理程序不是处理 工作负载管理器施加的调度约束的合适工具。 应用程序本身不具有 工作负载管理器感知功能。 在这种情况下,系统管理员可能希望提供一个脚本来调用 工作负载管理器 命令,以管理 DLPAR工作负载管理器的交互。

对使用哪个方法的决定应该基于系统或特定于资源的逻辑被引入应用程序的方式。 如果应用程序是被从外部要求使用特定数量的线程或按大小排列其缓冲区,请使用基于脚本的方法。 如果应用程序是直接了解系统配置从而使用该信息,请使用基于信号的方法。

DLPAR 操作本身分为以下阶段:
  • 检查阶段

    首先调用 检查阶段 ,它使应用程序能够在更改系统中的任何状态之前使当前 DLPAR 请求失败。 例如,如果添加 CPU 使系统中的处理器数量超过了所许可的处理器数量,检查阶段可由基于 CPU 的许可证管理器使用以停止新处理器的集成。 它还可用于保留非 DLPAR安全的程序的 DLPAR 安全性。 在后例中必须考虑由应用程序提供的服务,因为它可能可以更好地终止程序、完成请求,然后重新启动该程序。

  • 之前阶段之后阶段

    提供了之前阶段之后阶段以更好地终止程序、完成请求,然后重新启动该程序。

DLPAR 事件进入下一阶段之前,系统会尝试确保不同介质中的所有校验码都完整地在系统级别执行。