私が担当していたコンピュータシステムは、バッチ主体で、社内業務に必要なさまざまな計算を利用者の要求に応じて実行される非定型業務の科学技術計算システムとして稼働していました

一般的に、定型業務の場合、実行時間や必要なリソースなどがほぼ固まっているため、システム側が準備する環境は容易に把握できます。
ところが、非定型業務ではタスク毎に実行時間、リソースが異なるのでシステム側が用意すべきリソースを（安全率を加えるなどして）多くしなければならない事と、ある程度ユーザ側に実行するタスクに応じて実行クラスを決めてもらうと言った決定権を与える必要が出てきます（性善説ですが、、）

私は非定型業務を実行するコンピュータシステムは、タスクを投入するユーザも重要なシステム運行者の一員であると経験で感じました。
一人の人が大量な出力データをデータセットに（直接）出力せずにスプールへ吐き出すジョブを実行（スプールスペースパンクの要因になる）したり、ＣＰＵループさせるといった業務に支障が生じる処理を運用時間帯に行ったりするのは、他の利用者に迷惑を与える違反行為になります。これをシステム管理者が日々注視するのは不可能です。

本題に戻ります。

タスクスケジューリングをご説明する前に、入力について話す必要があります。


１）入力（イニシエータ、リーダ）

メインフレームシステムではタスクの入力にイニシエータやリーダ（入力、外部、内部など）と呼ばれるさまざまな入口を準備して複数のタスクが同時に入力出来るようになっています。

サーバでは業務ごとにCPUを分けたりや論理分割をするそうですが、メインフレームは高額のため、一つのＣＰＵを有効に使おうという思いから、効率良いスケジューリング手法が発達しました

とくに私が関わったシステムは非定型業務だったため、多様なタスクが入力されてきました。すぐに終了するものから、何時間がかかるものまで、、

言わば、何車線もある道路に、スポーツカーから、ダンプカー、消防車といった色々な速度や大きさ（用途）の車が何台も走って高速の料金所(演算）に向かうような感じです



この一車線がイニシエータやリーダー一本に相当します

イニシエータやリーダの詳細については、03．ジョブ入力サブシステムを参照してください

イニシエータ、リーダ一つ一つには走る事ができるタスク（車）の条件を設定します。メインフレームという高額マシンをみんなで共用するわけですから、短時間で終了するタスクも長い時間計算にかかるタスクも不公平なく処理されるようにする必要があります。

道路は車線内であれば、どんな車でも走行できますが、前の車がつかえていると自分の期待した速度で走行できない（時間内に目的地にたどり着けない）です。そのようなことを防ぐためにイニシエータ、リーダに条件を設定するのです。

スポーツカー用、大型バス用の車線と言った具合です

道路状況は目に見えますが、イニシエータ、リーダは簡単に人の目には見えませんから、、

私が担当したシステムでは、ユーザーに与える実行クラスの決定権を以下のような概念で与えていました



提供するリソースには、使用可能なメモリ（リージョンサイズ）、出力可能ページ数などです。

イニシエータ、リーダの数を整理して、入力されるタスク（車）の数と見合った能力（処理時間、リソース）を決めることで、タスクスケジューリングを考える条件が揃います。

次回、タスクスケジューリングについて書きます