工作负载管理器（Workload Manager，WLM）一直是大型机上才有的福利，但在WLM出现之前，一直用的是系统资源管理器（Systems Resource Manager，SRM）管理性能，SRM使用高深莫测的参数在它们之间模糊地交互。上世纪80年代，一个系统程序员在做一个简单的变化之前，可能会烦恼几周，必须为意想不到的后果重新熟悉相关法律。WLM将事情变得更简单了，允许性能分析师设定目标，然后让系统自动管理它们。

　　WLM如何管理CICS

　　WLM可以将CICS作为地址空间或服务器进行管理，在地址空间模式下，WLM提供了以“相对速度”为目标的区域和管理外视图，它定义了可接受的工作负载延迟，其值是相对于执行时间的百分比。

　　WLM通过抽样确定地址空间的相对速度，当它收集到足够的样本后，计算相对速度就成为一件简单的事情，活动任务的处理时间除以所有活动任务时间加上由于WLM管理资源拖延地址空间的时间的总和，最后再乘以100，WLM就可以计算出百分比了。

　　响应时间目标对CICS往往更有意义，性能分析师设置了百分点（两秒内完成90%的事务）或平均响应时间目标，WLM尝试确保该区域有必要的资源来满足它。

　　性能分析师可以指定CICS响应时间和速度目标，使用这种策略时，WLM先管理CICS的速度目标，直到该区域开始独立报告工作性能，从那个时刻起，WLM切换到响应时间目标，而忽略速度目标。

　　CICS和WLM交互

　　如果需要WLM管理响应时间，它需要知道CICS的内部运行机制，CICS启动时连接到WLM，为最大的任务（Max Task，MXT）和一些系统任务每个分配一个性能块（Performance Block，PB），因此PB的数量可能很大。为了收集性能信息，WLM每1/4秒扫描一次PB。如果将MXT设置为最大值999，从管理角度来看会方便很多，但这样也将导致大量的开销，因为WLM每秒会遍历4次数个区域中的所有PB。

　　每个事务必须分配一个服务类给WLM，以便管理它的性能，因此，当CICS连接一个新事务时，它会发出一个分类WLM宏，WLM根据若干准则为工作单位选择一个服务类，这些准则包括事务ID，CICS APPLID，源LU名，甚至可以包括用户ID（如果CEO也偶尔会登陆一下，可以多给他分配点资源）。服务类为事务定义了性能目标，如果WLM没有找到匹配的服务类，它就分配一个默认的服务类。一旦分好类，CICS就可以让WLM通过一个启动请求知道任务是否正在等待。

　　参与动态路由的事务在另一个区域启动时，不用每次都重新分类，相反，CICS可以在多个区域操作链接上传递服务分类，CICS会发出一个宏通知WLM，现在的任务是上一个工作单位（unit of work，UOW）的延续。

　　这种UOW目标视图是一个不错的技术，如果WLM不能通过CICSPlex跟踪UOW的进度，管理响应时间目标将没有多大意义。最后，当一个文件所属区域在拖延时间，那如何提高应用程序所属区域的优先级，如何改善应用程序的响应时间呢？

　　当UOW中的每个任务完成时，CICS会发出一个通知宏告诉WLM事情进展如何。

　　WLM还具有另一个功能 - 动态工作负载管理，即为满足性能目标，重新分配资源。WLM每10秒检查一次所收集到的性能数据，通过为每个服务类计算“性能指标”，看是否有需要微调的地方，如果计算结果小于1，表示服务类已经达到或超过了它的性能目标，如果计算结果大于1，表示有些地方可能需要进行调整。

　　最后，WLM会选出一个未满足性能目标的服务类，然后调整地址空间的入口给它认为引起延迟的资源，如果要挖东墙补西墙，WLM也可能会修改其它的工作负载，在做出修改后，WLM又回到收集模式，直到下一个10秒间隔。

　　IBM在WLM中设计了10秒延时，每周期更新一次，避免了抖动的发生，毕竟，大多数客户都希望他们的电脑在给定可用资源的情况下能做更多的事情，也有助于理顺系统性能，而不是毫无节奏地乱调一通。

　　这个看似不错的策略也存在一些不足，有时，如果一个工作负载，如CICS陷入窘境，10秒的等待可能会导致一些问题，当然整体影响还是取决于反复无常的工作负载，以及它对性能变化周期的敏感度。