※本記事を印刷してご覧になりたい場合は、iWorld会員向けに公開しているPDF版「IBM i実行管理の概要と高度な実行方法」をご利用ください。
今回はIBM i 実行管理についてご紹介します。
IBM i エキスパートの皆様には、記事前半は既知の内容が多いと思われます。本稿のメイントピックである、 IBM i ジョブのより高度な実行方法:ジョブの再経路指定(Reroute JOB : RRTJOB) までスキップしてください。
実行管理の必要性
最初に改めて、実行管理の必要性を説明します。コンピューターでは様々なユーザーが様々なプログラム、データを使って処理を行います。各ユーザーの処理したい業務内容、処理負荷は多様な事が想像できます、その様々な種類の大量の業務処理をすべて円滑に処理するために必要なのが実行管理機能です。(図1)
▲図1.
Windows、Unix,Linux系のシステムでは処理負荷(例:HTTPサーバー、APサーバー、DBサーバー)毎にサーバーやVMを分割し、複数ワークロードの並行実行の複雑さ、難しさを回避する方法論が一般的です。IBM i やIBM Z(汎用機)などは、1つのOS(LPAR)上で様々な処理負荷を同時に効率的に、かつレスポンスよく処理するための機構が搭載されています。それが実行管理機能です。
IBM i 実行管理機能とは?
IBM i の実行管理機能の概要レベル全体像は図2のようになります。(図2にはセキュリティに関する記述がありませんが、IBM i のセキュリティ機能が下図全体に対して動作している等、省略があります。)
▲図2. IBM i 実行管理機能 概要全体図
いわゆるオープン系のOSでは、上記IBM i のようにハードウェア、OSが管理するコンピューティングリソースを論理的に分割し、ユーザーの処理特性に応じて配分・管理するような機能は無いと思われます。仮説としてIBM i の実行管理機能をOSより上位層のソフトウェアでエミュレーションすることはできるかもしれませんが、パフォーマンスや必要リソース等を予想すると、IBM i のように効率的に動作するという事はおそらくできないでしょう。IBM i の実行管理機能は基本的にIBM i OSレベル、またはIBM i のSLICマイクロコードレベルで実装されていますので、処理速度、負荷、必要リソースの面で非常に優秀です。
IBM i 実行管理:バッチジョブを投入する際のフロート関連オブジェクト定義
図3はIBM i でバッチジョブを実行する際に参照される実行管理機能関連オブジェクトの鳥瞰図です。
▲図3.
大まかな説明をすると、ユーザーが②SBMJOBコマンドでバッチジョブを投入する際にどのジョブ待ち行列にジョブ投入するかを指定します。
またIBM i上の全てのジョブにはジョブ記述 *JOBDが指定されています。バッチジョブは自身の*JOBDに指定されたジョブ待ち行列*JOBQに投入されます。
ジョブ待ち行列は必ず1つのサブシステムに関連づけられており、投入されるジョブ待ち行列が決定されます。サブシステム内でSBMJOBされたジョブが実行される際には、バッチジョブの*JOBDからさらに経路指定項目が参照されジョブ実行時のクラス *CLSが決定されます。*CLSにはジョブの実行優先順位やCPUのタイムスライス値、メモリ上に展開されたジョブ用データのパージ可否(バッチ型か5250対話型かで適した方の値が指定される)が指定されています。サブシステム定義*SBSD の経路指定項目はさらにSBMJOBされたジョブを処理するためのOSコマンド・機能が呼び出され、その元でSBMJOBで指定されたコマンド(図3では CRTRPGPGMコマンド)が実行されます。
以上の説明では省略しましたが、実際にはジョブ待ち行列から同時に活動状態にできるジョブ数の制限やサブシステム内で同時処理可能な最大ジョブ数等も指定されています。より詳細な説明や、対話型ジョブでの実行管理などを説明したページをQiitaに投稿していますのでご参照ください。(図4)
▲図4.
IBM i ジョブのより高度な実行方法:ジョブの再経路指定(Reroute JOB : RRTJOB)
さて、ここからが本稿の本題です。IBM i はサブシステム内でジョブに最適な環境を提供・制御することでパフォーマンスとスループットを最大化できます。
一般的なサブシステムにおいてはサブシステム内に1つのプール(メインメモリを論理分割したもの)を持ちますが、図5のように複数のプールを構成することもできます。(プールについての基本的な説明や設定方法については上述のQiita参照ページ内の記事をご参照下さい。)
ジョブを実行するサブシステムのプールは、ジョブ投入時の経路指定データに基づきサブシステムの経路指定テーブルを参照して決定されます。
図5においては通常はプール1が使用されるものとしています。プール1は多数のジョブで共用利用するメモリ領域となりますが、特定のジョブについては専用のメモリプール2を割り当てしたい、処理を優先して実行したいといったケースがあると思われます。そのような場合、RRTJOBコマンドを使用してジョブを再経路指定することで、同じサブシステム内で実行プールを切り替えることが可能になります。
このとき同時にジョブの参照するクラス記述 *CLSも変更でき、CPUのタイムスライス値や実行優先順位も変更することができます。RRTJOBコマンドでジョブを再経路指定すると、同一サブシステム内で実行されるジョブのなかで処理優先度を調整することができます。
▲図5. ジョブの再経路指定 概要
RRTJOBコマンドは次のような特徴があります。
- OVRxxxコマンドによる一時指定変更はすべて無効になります。
- QTEMP, ライブラリーリストなどジョブ属性はRRTJOB実行前後ですべて引き継がれます。
RRTJOBコマンドの実行例
以下ではRRTJOBコマンドの実行例をご紹介します。主な設定は図6の通りです。大まかな処理の流れは以下の通りです。
- SBMJOBコマンドでバッチジョブ3をバッチ実行。この際、
・ 経路指定項目はデフォルト*ANYが選択され、QBATCH2サブシステムのプール1(*BASEプール)でジョブが実行開始されます。
・ クラス*CLSはQSYS/QBATCHを参照し、実行優先順位 50, タイムスライス5000msで処理 - 1)でCALLしたCLP内から別なプログラムBCHPGM_Aを呼び出します。この直前にRRTJOBコマンドでジョブを再経路指定し実行環境を下記のように変更します。
※BCHPGM_A はサブシステム内でも処理の優先度を上げたいジョブと想定しています。
・ ジョブの実行プールをプール2に変更。プール2は他のジョブを実行しない専用プールです。
・ クラス*CLS QGPL/QBATCH2 を参照し、実行優先順位45、タイムスライス値7500msに変更
▲図6. RRTJOBコマンド実行例 設定概要
それでは実際の動きについて見ていきましょう。なお、関連するサブシステム記述、クラス記述などは最後にまとめて記載していますのでご参照ください。
手順1.バッチジョブを投入
下記のようなコマンドで対象のジョブ(BCHPGM2)をQBATCH2サブシステムに紐づいているジョブ待ち行列QBATCH3に投入します。
SBMJOB CMD(CALL PGM(GOMALIB/BCHPGM1)) JOB(BCHPGM2) JOBQ(QGPL/QBATCH3)
▲図7.
上記の結果、ジョブBCHPGM1がQBATCH2で実行開始されます。経路指定データは9999行目の*ANYが適合します。
その結果、実行プールは図7のようにプール1で実行されます。
▲図8.
また、クラス記述はデフォルトのQBATCH(図9)が使用された結果、実行優先順位 50, タイムスライス 5,000ミリ秒になっています。
▲図9.
手順2. バッチジョブ中でRRTJOBコマンドを実行
手順1で実行したCLP BCHPGM2は処理1(サンプルでは単純にDLYJOB(30)コマンドだけ)が完了した後、
継続のプログラムを実行する(CALLする)際に、下記のRRTJOBコマンドを用いて経路の再指定を行っています。
RRTJOB RTGDTA('ABC') RQSDTA('CALL GOMALIB/BCHPGM_A')
▲図10.
上記コマンドの結果、BCHPGM_Aが実行される環境が再設定され、下記のように変化します。
まず、経路指定データRTGDTA ‘ABC’が指定されているので、合致する経路指定テーブル 8888行目が選択され、図11のように実行プールが2 に変更されます。
▲図11.
また、経路指定テーブル8888行目ではクラス記述がQBATCH2を指定しているため、図12のように実行優先順位 45、タイムスライス値 7500ミリ秒に変更されます。
▲図12.
上記の結果、BCHPGM_A(と後続の処理)はQBATCH2のプール2を占有で使用することが可能となり、さらに実行優先順位、タイムスライス値もより優先度があがるため他のジョブより処理を優先して実行させることができるようになります。
今回はジョブの途中でRRTJOBコマンドを実行する、という方法のご紹介でしたが、対話型ジョブでRRTJOBコマンドを使用することもできます。
また、単純に特定のSBMJOBコマンドからのジョブ実行はすべてプール2で優先実行させたい、ということであれば経路指定テーブル 8888 ‘ABC’ に合致するようにSBMJOBコマンドを投入(例えばジョブ記述を用意する等)すれば実行可能です。
上記例で使用した設定例
JOB待ち行列 QGPL/QBATCH3
CRTJOBQ JOBQ(QGPL/QBATCH3) TEXT('QGPL/QBATCH2 のJOBQ’)
共用プールを新規作成
WRKSHRPOOLコマンドで *SHRPOOL1 を作成((SHRPOOL1のサイズ、最大活動に値を入力する)
サイズ、最大活動数はシステム値がQPFRADJ=2の為可変となります(可変させたくない場合QPFRADJ=0に変更する)。
ページングオプションを*CALCとしてエキスパートキャッシュをオンに
▲図13.
サブシステム記述 QGPL/QBATCH2
CRTSBSD SBSD(QGPL/QBATCH2) POOLS((1 *BASE) (2 *SHRPOOL1))
▲図14.
ジョブ待ち行列QBATCH3をサブシステム記述 QBATCH2のジョブ待ち行列として追加
ADDJOBQE SBSD(QGPL/QBATCH2) JOBQ(QGPL/QBATCH3)
▲図15.
クラス記述*CLS QGPL/QBATCH2 を作成。実行優先順位 40, タイムスライス値 7500ミリ秒を指定。
CRTCLS CLS(QGPL/QBATCH2) RUNPTY(40) TIMESLICE(7500) PURGE(*NO) DFTWAIT(120)
▲図16.
サブシステム記述QBATCH2に経路指定項目 8888 行目(比較値 ‘ABC’)を追加。経路指定データは ‘ABC’ 、クラス記述は QBATCH2、実行プールID 2 を指定。
※比較値 ‘ABC’ はユニークな値であれば特に制約はありません。また経路指定項目は順序番号の小さい行から比較し最初に合致したものが選択されます。指定する番号自体に特に制約はなく、ユーザーで自由に指定できます。一般的にはシステムデフォルトで経路指定項目が存在している場合(比較値 *ANYをのぞく)、ユーザー追加の経路指定項目はシステムデフォルトの順序番号より大きい値を指定する方が安全です。
ADDRTGE SBSD(QGPL/QBATCH2) SEQNBR(8888) CMPVAL(‘ABC’) PGM(QSYS/QCMD) CLS(QGPL/QBATCH2) POOLID(2)
比較値 *ANYが存在していない場合は 9999行目も追加
ADDRTGE SBSD(QGPL/QBATCH2) SEQNBR(9999) CMPVAL(*ANY) PGM(QSYS/QCMD) CLS(QSYS/QBATCH)
▲図17.
▲図18. 経路指定項目 8888 明細
▲図19. 経路指定項目 9999 明細
※注意事項
実行優先順位の変更(より優先度を上げる)、タイムスライス値をより長くする、という設定変更は裏返すと、それ以外のジョブの実行優先度を相対的に下げる、という事もできます。例で記載した実行優先順位(40)やタイムスライス値 7500ミリ秒はあくまでサンプルで、お客様固有のシステムでの最適な値は十分慎重な検討・テストで決定下さいますようお願いいたします。
筆者
日本アイ・ビー・エム株式会社 多数の執筆記事を、iWorldに寄稿中。 |
IBM i 実行管理のより詳細な説明参照ページ;
Qiita主な記事の目次 IBM i 実行管理
https://qiita.com/gomAnomalocaris/items/6669728f368e87c2d75e#ibm-i-%E5%AE%9F%E8%A1%8C%E7%AE%A1%E7%90%86