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

コンピューティングにおいて、ジョブ制御とはジョブ実行の自動制御を指します。各ジョブが正しく実行するために十分なリソースにアクセスできること、限られたリソースをめぐる競合によってデッドロックが発生しないこと、デッドロックが発生した場合にはデッドロックを解決できること、そして何らかの理由で期待通りに実行されていないジョブを終了させることなどです。高度な自動化が実現されている場合でも、Unix系システムなどのほとんどのシステムでは、ジョブの中断、一時停止、再開などの手動操作や、通常のバックグラウンド（バッチ）モードではなくフォアグラウンド（対話型）での実行（完全自動実行）が許可されています。

ジョブ制御、別名バッチ処理は、ほとんどの場合、人間の介入なしに進行します。[ 1 ]ジョブ制御は、次のような詳細を決定するプログラマによって構成されます。

  • ジョブを実行するタイミング
  • どのような条件でステップをスキップするか
  • 入出力に使用するファイルやデバイス
  • ファイルを保持するか削除するか
  • 使用できるストレージの最大量

歴史

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

初期のコンピュータ開発者は、比較的低速な周辺機器がデータの読み書きなどの処理を完了するまでソフトウェアが待機する必要があるため、コンピュータのほとんどの時間がアイドル状態になっていることに気づきました。バッファリングは部分的な解決策を提供しましたが、最終的には出力バッファが利用可能なメモリをすべて占有するか、入力バッファが空になり、システムは比較的低速なデバイスがタスクを完了するまで待機するようになりました。

より一般的な解決策は、マルチタスクです。コンピュータは、プロセッサ時間を待機していないプロセスに有効に活用できる場合は一時停止できるプロセスにプログラムをロードすることで、複数のプログラムを同時に実行します。プロセスのコンテキストはメモリにキャッシュされ、別のプロセスのコンテキストを使用してそのプロセスの実行を再開します。コンテキスト スワップを担当するソフトウェアは、スケジューラと呼ばれます。スケジューラは、周辺デバイス ドライバーと連携して、デバイスが操作をすぐに完了できない場合にアクティブなプロセスの実行を一時停止し、そのプロセスを非アクティブ ジョブのキューに配置します。周辺機器が操作を完了すると、プロセスはスケジューラによって再開できるようになります。同様の一時停止と再開は、非同期プロセス間通信など、待機を伴う可能性のあるすべての操作に適用されます。

しかし、このスケジューリングには欠点があります。ほとんど待機しないプロセス（つまり、周辺機器を使用しないプロセス）は、完了するか割り込まれるまでプロセッサを独占してしまいます。その結果、他のプロセスはプロセッサリソースを奪われ、速度が低下する可能性があります。これは、プリエンプティブ・マルチタスク（別名タイムスライシング）によって解決できます。タイムスライシングでは、各プロセスは一定時間プロセッサを占有した後、スワップアウトします。さらに、プロセスに優先度を設定することで、優先度の低いプロセスよりも多くのアクセスを許可できます。

言語

バッチ

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

BANGおよびその他のIBM以外のJCL

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

かつてはBUNCH （Burroughs、Univac/Unisys、NCR、Control Data、Honeywell）として知られていた非IBM JCLは、 Unisysを除いて、沈静化した BANG [ 2 ] [ 3 ]の一部です。

相互の作用

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

ファイルシステムとデバイスの独立性

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

リアルタイムコンピューティング

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

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

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

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

参照

参考文献

  1. ^ 「営業時間外のメインフレームの稼働：バッチ処理」。
  2. ^ Xerox Data Systems とその買収した SDS が感嘆符付きで「オペレーティング システム リスト」と呼んだもの。
  3. ^ JCLのSLASH SLASHは、一部からはSLANT SLANTと呼ばれています。この脚注の残りの部分は、私がSLANT SLANTという言葉を初めて聞いた人物、故人である上級コンピュータオペレーターであり、人間中心の教訓を数多く教えてくれた退役軍人への追記です。彼の引用文献にこれを追加してください。
  4. ^ a b c Xerox Real-Time Batch Monitor (RBM)、Sigma 2/3 Computers、ユーザーズガイド(PDF) . Xerox Corporation . 2017年2月16日閲覧。
  5. ^ファミリー: Scientific Data Systems SDS Sigma 2 & 3、Xerox が買収した Xerox Data Systems、Xerox 530 として改名/統合。
  6. ^ SDS Sigma 5、6、7はXerox 560になった
  7. ^ XOs SIGMR 5/7 リアルタイムバッチモニター (RBM-2) (PDF) . 2017年2月16日閲覧。
「 https://en.wikipedia.org/w/index.php?title=Job_control_(computing)&oldid=1328415234」から取得