ジョブとは
ジョブとは、IBM i 上で実行される一連の処理の単位です。
処理のかたまりのようなもの、と筆者は理解してます。
IBM i では主に次の4種類のジョブがあります:
ジョブの種類 | 内容 | 例 |
---|---|---|
対話型ジョブ(Interactive job) | ユーザーが5250画面などから直接操作して動かす処理など | WRKACTJOB、DSPJOBなど |
バッチジョブ (Batch job) | ユーザー操作なしで自動的に実行される処理 | 夜間バッチ、バックアップなど |
自動開始ジョブ | サブシステムが開始された際自動で実行されるジョブ等 | サブシステム記述の自動開始ジョブ |
スプールジョブ | 印刷や帳票出力などで生成された出力データを一時保存し、後で印刷される | OUTQなど |
ジョブの確認方法
現在動作中のジョブを確認するには、以下のコマンドを使います
WRKACTJOB
特定のサブシステム(たとえばQINTER)内のジョブだけ見たいときは
WRKACTJOB SBS(QINTER)
ジョブ名やユーザー名、状態(RUN、DEQ、MSGWなど)をここで確認できます。
サブシステムとは
IBM i で使われるサブシステムについて、
ジョブを実行するため部屋みたいなもの、だと筆者は理解しています。
ジョブは必ずサブシステムの中で動作します。
たとえば以下のような使い分けがあります:
サブシステム名 | ジョブタイプ | 用途の例 |
---|---|---|
QINTER | 対話型 | 5250操作など、ユーザーインタラクション |
QBATCH | バッチ | SBMJOBコマンドで投入する5250画面を使用しないジョブ |
QCTL | 制御系 | IPL時の処理、電源制御など |
対話型ジョブ(5250エミュレータなどで動くもの)やバッチジョブなど、それぞれのタイプに合わせて適切なサブシステムで処理されます。
デフォルトでは、対話型ジョブはすべて QINTER サブシステムで動作しています。
でも、この一部屋だけで全員を動かしていると、管理が難しかったり、制御が効きづらかったりします。
なんでサブシステムをたくさん作るのか
サブシステムを分けて管理することで、次のようなメリットがあります。
-
環境に応した制御ができる(セキュリティ向上)
例えば、海外支社の英語対応が必要なユーザー用に英語専用サブシステムを用意することで、英語UI端末のみを制御対象にできたり、必要なライブラリや環境変数を限定できたり、その国の基準に必要なセキュリティポリシー(アクセス制限やジョブ属性など)ごとに分離ができます。 -
特定ユーザーや業務だけにリソースを集中できる(パフォーマンス向上)
受注業務やカスタマーサポートなど、業務ごとに分けておけば、リソース割り当ても柔軟にできます。 -
保守作業がしやすくなる(メンテナンス性)
「一般ユーザーの部屋(QINTER)」だけ止めて、保守用のサブシステムは動かしておく、なんて使い方もできます。
サブシステムはどこで設定・確認するのか
サブシステムの設定や確認はコマンドラインから行えます。
サブシステムの一覧を見るには:
WRKACTJOB SBS(*ALL)
サブシステムの属性を確認するには:
WRKSBSD SBSD(QINTER)
端末名とは
端末名(ワークステーション名)は、5250エミュレータなどでIBM iに接続した際に自動的に割り当てられる接続元の名前です。
たとえば「USER01」といった文字列で、通常はログオン画面の左上に表示されます。
この端末名を使って、どの端末がどのサブシステムに入れるかを制御できます。
名前のパターンで制御もできるので、たとえば SAKU* と指定すれば「SAKU」で始まるすべての端末が対象になります。
端末名の確認・設定場所
確認方法(ユーザー側):
5250エミュレータのログオン画面の右上に表示されています。
設定方法(管理者側):
クライアントのエミュレータ設定(例:IBM i Access Client Solutions の5250設定)から「ワークステーションID」を設定できます。
この前提知識を踏まえてサブシステムQINTER2を作ってみます。
QINTER2の作成ざっくり手順
今回は、QINTER2 というサブシステムを作って、SAKU* という端末名を持つユーザーだけが接続できるようにします。
- QINTERをコピーしてQINTER2を作成
- ジョブキューを新規作成して割り当て
- 端末の許可設定
- QINTER2を起動
- ジョブの移行(オプション)
STEP 1:QINTERをコピーしてQINTER2を作成
CRTDUPOBJ OBJ(QINTER) FROMLIB(QSYS) OBJTYPE(*SBSD) TOLIB(QGPL) NEWOBJ(QINTER2)
STEP 2:ジョブキューを新規作成して割り当て
CRTJOBQ JOBQ(QGPL/QINTER2) TEXT('QINTER2用の対話型ジョブキュー')
ADDJOBQE SBSD(QGPL/QINTER2) JOBQ(QGPL/QINTER2) MAXACT(*NOMAX) SEQNBR(30)
※コピー元に不要なジョブキューがあったら削除します:
RMVJOBQE SBSD(QGPL/QINTER2) JOBQ(XXXXX)
STEP 3:端末許可設定
SAKUで始まる名前の*端末のみ使えるように許可設定を行います。
ADDWSE SBSD(QINTER2) WRKSTN(SAKU*)
RMVWSE SBSD(QGPL/QINTER2) WRKSTNTYPE(*ALL)
RMVWSE SBSD(QGPL/QINTER2) WRKSTNTYPE(*CONS)
STEP 4:QINTER2を起動
STRSBS SBSD(QGPL/QINTER2)
STEP 5:ジョブの移行(オプション)
すでにログオン中で QINTER に入ってしまった SAKUDSP端末のジョブは、以下のコマンドで QINTER2 に移動できます:
今はSAKUDSPはQINTERにいます。
QINTER2配下で稼働させます。
TFRJOB JOBQ(QINTER2)
おまけ:QINTER側でも端末を制限する
参考として、QINTER 側で、稼働するワークステーションIDを制御する設定例です:
ADDWSE SBSD(QGPL/QINTER) WRKSTN(SAKU*) AT(*ENTER)
これだとSAKU*のワークステーションIDのみ、QINTERを稼働させることができます。
またはアクセスを完全に止めたい場合:
ADDWSE SBSD(QGPL/QINTER) WRKSTN(SAKU*) MAXACT(0) AT(*ENTER)
この場合、SAKU*の端末名を持つ接続端末は、サブシステム QINTER に直接アクセスできません。
ただ、他のサブシステムに接続中のジョブであれば、TFRJOBコマンドを使ってQINTERに転送することは可能です。
まとめ
QINTER2 を作ってサブシステムを分けることで、
- セキュリティ管理がしやすくなる
- 保守作業が柔軟になる
- パフォーマンスの制御も効くようになる
一度作っておくと、さまざまな応用ができるので、ぜひお試しください!