ジョブ制御（コンピューティング）

コンピューティングにおいて、ジョブ制御とは、コンピュータ システム上の複数のタスクまたはジョブを制御することを指し、各タスクまたはジョブが正しく実行するために十分なリソースにアクセスできるようにし、限られたリソースの競合によって2 つ以上のジョブが完了できないデッドロックが発生しないようにし、デッドロックが発生した場合にはその状況を解決し、何らかの理由で期待どおりに実行されていないジョブを終了します。

ジョブ制御は、人間のオペレーターがすべてのジョブの設定、監視、制御を担当していたコンピューターの初期の時代から、ジョブ制御の作業の大部分を引き受ける現代のオペレーティング システムへと発展してきました。

非常に洗練されたスケジューリング システムであっても、ある程度の人間の介入は望ましいものです。最新のシステムでは、ユーザーがジョブを停止および再開したり、ジョブをフォアグラウンド (ユーザーと対話可能) またはバックグラウンドで実行したりすることができます。Unixのようなシステムはこのパターンに従います。

初期のコンピュータ開発者にとって、高速マシンのほとんどの時間はアイドル状態になっていることは明らかでした。これは、実行中の単一のプログラムが、低速の周辺機器がデータの読み取りや書き込みなどの重要な操作を完了するまで待機する必要があるためです。現代の言葉で言えば、プログラムは計算バウンドではなく、I/O バウンドでした。バッファリングは部分的な解決策しか提供しませんでした。最終的には、出力バッファが使用可能なメモリをすべて占有するか、入力バッファがプログラムによって空になり、システムは比較的低速のデバイスが操作を完了するまで待機せざるを得なくなりました。

より一般的なソリューションは、マルチタスクです。コンピュータには常に複数の実行中のプログラム、つまりプロセスが存在します。プロセスが続行できない場合、そのコンテキストを保存して、コンピュータが別のプロセスの実行を開始または再開することができます。最初は非常に単純で、特別なプログラミング手法に依存していたマルチタスクは、すぐに自動化され、通常は スケジューラ と呼ばれる特別なプロセスによって実行され、他のプロセスの実行を中断して再開する機能を持ちます。通常、周辺機器のドライバは、デバイスが操作をすぐに完了できない場合に現在のプロセスの実行を一時停止し、スケジューラはプロセスをスリープ中のジョブのキューに入れます。周辺機器が操作を完了すると、プロセスは再び起動されます。同様の一時停止と再開は、プロセス間通信にも適用されます。プロセス間通信では、プロセスは非同期で相互に通信する必要がありますが、応答を待つ必要がある場合があります。

しかし、この低レベルのスケジューリングには欠点があります。周辺機器や他のプロセスとやり取りする必要がほとんどないプロセスは、完了するか手動介入によって停止されるまでプロセッサ リソースを占有するだけです。その結果、特に外部と頻繁にやり取りするタスクを実行する対話型システムでは、システムが遅くなり、タイムリーに反応するのが遅くなります。この問題は、各プロセスに「タイムスライス」を割り当てることで解決されます。これは、中断のない実行期間の後にスケジューラが自動的にそのプロセスをスリープ キューに入れるものです。プロセスには異なる優先順位を与えることができ、スケジューラは割り当てられた優先順位に基づいて、各プロセスに利用可能な実行時間のさまざまな割合を割り当てることができます。

このプリエンプティブマルチタスクシステムは、ほとんどの最新のジョブ制御システムの基礎を形成します。

バッチ処理は、コンピュータオペレータの有無にかかわらず24時間実行できますが、^[1]コンピュータは人間よりもはるかに高速であるため、ほとんどの意思決定はジョブの実行が開始される前に行われ、「プログラマ」による計画が必要になります。

コンピュータ オペレーターが存在する場合もありますが、バッチ処理は主に人間の介入なしで実行されることを意図しています。したがって、提出する指示には多くの詳細を含める必要があります。

• 実行するプログラム。
• 入出力に使用するファイルやデバイス^[2]
• どのような条件下でステップをスキップするか。

初期のコンピュータ常駐モニタとオペレーティング システムは比較的原始的で、高度なリソース割り当てはできませんでした。通常、このような割り当ての決定は、コンピュータ オペレータまたはジョブを送信したユーザによって行われました。バッチ処理が一般的で、対話型コンピュータ システムはまれで高価でした。ジョブ制御言語は、入力データを含むデッキの先頭のカードにパンチされる基本的な命令として開発され、実行中に使用可能にするメモリ割り当て、磁気テープ スプールのシリアル番号または名前などのリソースを要求したり、ジョブによって参照されるデバイス番号にファイル名またはデバイスを割り当てたりします。メインフレームで現在も使用されているこの種の言語の典型的な例としては、IBMのジョブ制御言語(JCL とも呼ばれる) があります。初期の JCL の形式はパンチ カードでの使用を想定していましたが、ディスク上のコンピュータ ファイルへの保存に移行してもこの形式はそのまま残りました。

IBM 以外のメインフレームバッチシステムには、ジョブ制御言語 (そう呼ばれるかどうかは別として) がいくつかありました。その構文は IBM バージョンとはまったく異なりますが、通常は同様の機能を提供していました。対話型システムには「コマンド言語」が含まれます。コマンド ファイル (PCDOS の「.bat」ファイルなど) は非対話型で実行できますが、通常は JCL ほど無人ジョブを実行するための堅牢な環境を提供しません。一部のコンピュータ システムでは、ジョブ制御言語と対話型コマンド言語が異なる場合があります。たとえば、 z/OS システム上のTSO は、バッチ作業用の JCL とともに、コマンド言語としてCLISTまたはRexx を使用します。他のシステムでは、これらは同じである可能性があります。

かつてはBUNCH （Burroughs、Univac/Unisys、NCR、Control Data、Honeywell）として知られていたIBM以外のJCLは、 Unisysを除いて、鎮静化された BANG ^{[3] [4]の一部です。}

タイムシェアリング システムが開発されるにつれて、対話型ジョブ制御が登場しました。タイムシェアリング システムのエンド ユーザーは、リモートターミナルから対話型でジョブを送信し(リモート ジョブ エントリ)、オペレータと通信して特別な要件を警告し、システムに進行状況を問い合わせることができました。エンド ユーザーはジョブに優先順位を割り当て、必要に応じてジョブを終了 (kill) することができました。また、当然ながら、ジョブをフォアグラウンドで実行して、実行中のプログラムと直接通信することもできました。対話型実行中に、エンド ユーザーはジョブを中断してバックグラウンドで続行することも、ジョブを kill することもできます。マルチタスク環境での対話型コンピューティングのこの開発は、現代のシェルの開発につながりました。

特定のプログラムが使用するファイルまたはデバイスに関する情報の一部またはすべてを指定する必要がない機能は、デバイス独立性と呼ばれます。

ジョブ制御によるプリエンプティブ マルチタスクにより、システムがほとんどの場合にタイムリーに動作することが保証されます。一部の環境 (たとえば、高価な機械や危険な機械の操作) では、システムの強力な設計制約は、あらゆる状況でタイムリーな結果を提供することです。このような状況では、ジョブ制御はより複雑になり、スケジューリングの役割がより重要になります。

リアルタイムシステムはすべてのリアルタイム操作に対してイベント駆動型のスケジューリングを行うため、「これらのリアルタイム操作のシーケンスは、コンピュータオペレータやプログラマの直接の制御下にはありません。」^[5]

しかし、システムにはリアルタイムタスクと、それほど時間的制約のない他のタスクをインターリーブする機能があり、その場合の境界線は、例えば10分の1秒以内の応答が求められる場合などである。^{[5] : p.1}たとえば、ゼロックスRBM（リアルタイム/バッチモニター）システムの場合、^{[6] [7] [8]}には、他に2つの機能が存在した。^{[5] : p.2}

• コンピュータオペレータコマンド（「迷惑キー入力」）
• バックグラウンド ジョブ ストリーム (バッチ ジョブ)。

• ジョブ制御の基本

• コマンド言語
• ジョブ制御言語
• ジョブ制御 (Unix)