ワークロード グループを使用するべき理由
ワークロード グループというのは、IBM i作業管理の隠された宝石であるように思われます。これまで様々なクライアントを相手に業務を行ってきましたが、ワークロード グループを積極的に活用しているショップに出会ったのは1度だけでした。2010年に導入されたワークロード グループは、CPUに対する追加的な管理機能を提供します。また、ワークロード グループを使用することにより、区画でアクティブ化されているより少ないコア数でソフトウェア製品をライセンスすることができるようになることもあります。
ワークロード グループは、非常に単純なエンティティであり、ワークロード グループの追加（ADDWLCGRP）コマンドを使用することで追加できます。ワークロード グループの名前と、そのワークロード グループによって使用できるプロセッサー コア数（「プロセッサー制限」とも呼ばれる）を指定するだけです。プロセッサー制限は、1～256の整数の値で指定します。システムのすべてのワークロード グループのリストを表示するには、ワークロード グループの表示（DSPWLCGRP）コマンドを使用します。
ワークロード グループを作成したら、ワークロード グループにワークロードを関連付ける必要があります。以下のワークロードを関連付けることができます。
-
サブシステム、およびそのサブシステムで実行されるすべてのジョブ。
7.2リリースでは、この関連付けは、サブシステム名およびそのサブシステムのワークロード グループが格納される、QSYS/QWTWLCGRPというデータ域を作成することによって行われます。データ域が作成されたら、関連付けが有効になるためには、サブシステムを終了して（活動状態の場合）、再度、開始する必要があります。
7.3リリースで、IBMは、サブシステム記述作成（CRTSBSD）およびサブシステム記述変更（CHGSBSD）コマンドにWLCGRPパラメーターを追加する機能強化を行いました。これにより、変更を有効にするために、活動状態のサブシステムを終了する必要はなくなりました。活動状態のジョブは、引き続き、以前のワークロード グループを使用します。変更は、開始される新しいジョブに対して有効となります。
すべてのリリースで、CPI146Cメッセージ（Subsystem &1 is using workload group &2（サブシステム &1 はワークロード・グループ &2 を使用））が、サブシステム モニター ジョブのジョブ ログに記録されます。
-
特定のジョブ。
ジョブ変更（CHGJOB）コマンドにはWLCGRPパラメーターがあり、これを使用してワークロード グループに特定のジョブを関連付けることができます。変更は、直ちにそのジョブに反映されます。
-
ジョブ記述によって属性が定義されているジョブ（7.4以降）
7.4リリースで、ジョブ記述作成（CRTJOBD）およびジョブ記述変更（CHGJOBD）コマンドにWLCGRPパラメーターが追加される機能強化が行われました。
では、ワークロード グループが、どのようにしてCPU使用量を管理することができるのかについて見てみましょう。従来のCPUの作業管理コントロールは、クラス オブジェクトにあります。最大CPU時間、タイム スライス、実行優先順位というラベルが付いたノブおよびダイヤルによって、ジョブがCPUをどのように使用できるかを管理しました。これらは有用なコントロールですが、より優先順位の高い作業が実行中でない場合は、優先順位の低いジョブが、CPUを大量に使用することができます。サブシステムの優先順位の低いジョブのグループが原因で、CPU使用率が高くなってしまう場合もあります。ワークロードをワークロード グループに関連付けると、そのワークロードのすべてのジョブは、プロセッサー制限で指定されているより多くのプロセッサー時間を使用しないよう制限されるようになります。
ワークロード グループを使用してCPU使用量を管理するのが効果的であるもうひとつのケースは、アドホックな照会が関わるケースです。本番データに対する様々なレポートを日常的に作成する必要のあるユーザーのグループがいるとします。これらの照会は、その場その場で作成されたり、書き方が適切でなかったりするため、実行はかなり高負荷になってしまう可能性もあります。たとえば、 ユーザー プロファイルによって作業をルーティングすることにより、これらのユーザーを特定のサブシステムに分離することができれば、そのサブシステムをワークロード グループに関連付けて、こうしたアドホックな照会によって使用されるCPU資源の量を抑制することができることになります。ユーザーは引き続きデータにアクセスしてレポートを作成することができますが、システムに対する影響はより適切に管理されます。ただし、照会の実行に、時間が長く掛かるようになるかもしれません。
また、ワークロード グループが、費用の節減に役立つケースもあります。たとえば、24コアの区画があり、IBMの MQ 製品を使用しているとします。そして、費用の点からも、また、他にもその区画で行う多くの作業があることからも、MQでの24コアのライセンスは望まないとします。この場合、ワークロード グループを使用することにより、そうしたMQワークロードを専用のサブシステムに分離させ、そのサブシステムをワークロード グループに関連付けることができます。そうすることにより、MQのライセンスを、ワークロード グループで指定されたプロセッサー数に抑えることも可能となります。ワークロード プロダクト項目の追加（ADDWLCPRDE）コマンドは、既存のワークロード グループにプロダクト項目を追加します。プロダクト項目は、ワークロード グループに定義されたプロセッサーの数によって制限される、プロダクトのライセンス条件および機能を識別します。また、ワークロード プロダクト項目の除去（RMVWLCPRDE）コマンドも利用可能です。こちらの、 ワークロード グループを使用してMQのライセンスを制限する方法 についてのドキュメントは、ずいぶん前に書かれたものですが、内容は現在でも通用します。参考にしてみてください。ここではMQを例として取り上げましたが、ライセンスを制限する目的でワークロード グループを使用するというのは、MQ以外でももちろん可能です。
最後に、ワークロード グループ コマンドおよびパラメーターの名前（WLCGRP）の中に「C」という文字が含まれていることについて、オヤッと思われた方もおられるのではないでしょうか。IBMは、開発時点では「workload capping groups（ワークロード キャッピング グループ）」という用語を使用していました。コマンドおよびパラメーターは確定していましたが、リリース直前になって、「workload groups（ワークロード グループ）」へと名前が短縮されることになったという経緯があるようです。
