OS2200

OS 2200は、 Unisys ClearPath Dorado ファミリーのメインフレーム システム用のオペレーティング システムです。OS 2200 のオペレーティング システム カーネルは、UNIVAC 1108用のExec 8の直系子孫であり、以前はOS 1100として知られていました。現在および過去の Unisys システムに関するドキュメントやその他の情報は、Unisys のパブリック サポート Web サイトにあります。^{[注 1]}

マシンアーキテクチャとOS 2200オペレーティングシステムとの関係については、 Unisys 2200シリーズのシステムアーキテクチャを参照してください。Unisysは2010年代初頭にClearPath Doradoハードウェアの生産を中止し、オペレーティングシステムは現在エミュレーションで実行されています。^[1]

1951 年の1101に遡る以前の 1100 システムもありましたが、1108 は、マルチプログラミングとマルチプロセッシングを効率的にサポートするように設計された最初の1100 シリーズコンピュータでした。この新しいハードウェアとともに、オペレーティング システム Exec 8 (1108 用の Executive System) が登場しました。

UNIVAC 1108コンピュータは 1964 年に発表され、1965 年後半に納品されました。最初の 1108 コンピュータは、UNIVAC 1107用に開発されたExec IとExec II を使用しました。しかし、UNIVAC は最大 4 つのプロセッサを搭載した 1108 の対称型マルチプロセッサバージョンを提供することを計画しており、初期のオペレーティング システム (実際には基本的なモニタープログラム) は、限定的なマルチプログラミングをサポートしていたにもかかわらず、そのために設計されていませんでした。

UNIVAC 1110が 1972 年に導入されたとき、より広範囲のシステムをサポートすることを反映して、オペレーティング システムの名前が OS 1100 に変更されました。OS 1100 という名前は、1100 シリーズの後継として Sperry 2200 シリーズが導入された 1988 年まで保持され 、そのときに名前が OS 2200 に変更されました。それ以降、2200 シリーズはUnisys ClearPath IX シリーズになり、その後 Unisys ClearPath Dorado シリーズになりましたが、オペレーティング システムの名前は OS 2200 のままでした。

社名と製品名も時とともに変化した。^{[2]セントポールの} エンジニアリング・リサーチ・アソシエイツ（ERA）は、レミントン・ランド社に買収された。レミントン・ランド社は、当時UNIVACコンピュータを製造していたフィラデルフィアのエッカート・モークリー・コンピュータ社も買収した。この2社は、ウィリアム・ノリスの指揮の下、レミントン・ランド社のUNIVAC部門に統合された。 ウィリアム・ノリスはERAの創設者の1人であり、後にレミントン・ランド社を離れ、コントロール・データ社を設立した。レミントン・ランド社のUNIVAC部門は、レミントン・ランド社がスペリー社と合併した後、スペリー・ランド社のUNIVAC部門となった。1970年代にスペリー・ランド社は、社名をスペリー社に変更し、すべての部門名をスペリーで始まるようにする企業アイデンティティ・プログラムを開始したため、コンピュータシステム部門はスペリー・ユニバックとなった。後に部門名が削除され、すべてが単にスペリーとなった。

オペレーティング システム カーネルは、今でも Unisys および顧客のほとんどの担当者から「Exec」と呼ばれています。ただし、Unisys が、後に「ClearPath OS 2200 Release n」と呼ばれるようになったシステム ベース リリースとして一緒にテストされた製品スイートのリリースを開始したとき、OS 2200 という用語は、システム リリース内の製品スイート全体と、 Dorado ハードウェア プラットフォーム用に非同期でリリースされたBISなどの他の製品スイートを指すように変更されました。

1986 年にBurroughs 社と Sperry 社が合併して Unisys 社になりました (2200 シリーズの長年の顧客の中には、Unisys は「UNIVAC は依然としてお客様のサプライヤーです」の略であると言う人もいます)。^[3]両社の主要なメインフレーム製品ラインは、 Burroughs 社のMCP オペレーティング システムや Sperry 社の OS 2200 など、開発が継続されています。

2016年にユニシスはOS2200の仮想Microsoft Windowsバージョンを教育および娯楽目的で無料で利用できるようにしました。^[4]

EXEC 8 (EXEC VIII と呼ばれることもある) は、1964 年に UNIVAC 1108 用に開発された UNIVAC のオペレーティング システムです。これは、UNIVAC 1107で使用されていた以前のオペレーティング システム、 EXEC IとEXEC IIの優れた機能を組み合わせたものです。EXEC 8 は、商業的に成功した最初のマルチプロセッシングオペレーティング システムの 1 つでした。バッチ、タイムシェアリング、リアルタイムの混合ワークロードを同時にサポートしました。1 つのファイル システムは、多数のドラムとスピンドルにまたがるフラットな命名構造を持っていました。また、評判の高いトランザクション処理システムもサポートしていました。

以前のシステムはすべてリアルモード システムであり、プログラムとオペレーティング システムの保護と分離のためのハードウェア サポートはありませんでした。以前のシステムではマルチプログラミングがサポートされていましたが、カード リーダー、プリンター、カード パンチスプーラーなど、適切に動作することがわかっている複数のサポート機能と同時に 1 つのユーザー ジョブを実行することに限られていました。

Exec 8 オペレーティングシステムは、1108 が最大 4 つの CPU を搭載するように設計されていたため、最初からマルチプログラミングおよびマルチプロセッシングオペレーティングシステムとして設計されました。メモリと大容量ストレージが主なシステム制約でした。1100 シリーズはより一般的な市場をターゲットに想定されていましたが、極限のリアルタイム処理が主な要件でした。^[5]

Exec 8の仕様は、1964年12月までに暫定的なプログラマーズリファレンスマニュアル（ユーザーガイド）として作成され、1965年5月に作業が開始されました。^{[6] [7]}

Exec 8 は、当初は主に一般的な科学技術作業で使用されたリアルタイムオペレーティング システムでしたが、メッセージ交換、プロセス制御、シミュレーション、ミサイル発射制御にも使用されました。これは、多くの場合 128K ワード (576 K バイト - IBM PC XTの最大メモリ サイズよりも小さい) しかないシステムで実行するように設計されており、リアルタイム処理とバッチ処理に重点を置いていました。最も初期のリリース レベルは 128KW で動作しましたが、後のリリースで機能が増えたため、実用的なサイズのプログラムに十分なスペースが残らなかったため、128KW では動作しなくなりました。1108 の最大メモリ容量は 256KW (1,152 KB) であったため、コア メモリがシステムで最も高価な部分であったため、メモリの効率的な使用が最も重要な制約でした。

大容量記憶装置は、256KW (FH-432) から 2MW (FH-1782) までを収容できる 6 フィートの長さの回転ドラムで構成されていました。最大容量の大容量記憶装置はFASTRANDドラムで、22 MW (99 MB) を収容できました。ファイルの断片化は、「ファイル保存」と呼ばれるプロセスによって処理され、通常は 1 日 1 回、夜間に実行されました。このプロセスでは、すべてのファイルをテープに書き出し、ドラム ファイル システムを再初期化してから、ファイルを再度読み込みます。

厳しいメモリ制約とリアルタイム使用のため、コアにロードされるコードのコピーを 1 つだけ保持することが必須でした。1108 はマルチタスク用に設計されていたため、システムは完全に「再入可能」(スレッド セーフ) でした。各再入可能モジュールは、実行データのインスタンスごとに異なる単一のメモリ「ベース アドレス」を介してプログラム データにアクセスしました。実行コンテキストの切り替えは、単一のレジスタに異なるベース アドレスを設定するだけで、単一の命令で実行できました。システムでは、共有データ構造を保護するためにきめ細かいロックを使用しました。エグゼクティブ、コンパイラ、ユーティリティ、および複数のコピーが同時に実行される可能性のある高度なユーザー アプリケーションでさえ、コードを共有できるように記述されました。これにより、メモリにロードする必要があるのは 1 つのコピーのみとなり、スペースとコードのロードにかかる時間の両方が節約されました。

コードとデータを異なるロード エンティティに分離するもう 1 つの理由は、メモリが IBANK と DBANK (命令とデータ) と呼ばれる 2 つの独立したバンク (別々の物理キャビネット) として実装されていたためです。それぞれに独自のアクセス パスがあるため、CPU は両方のバンクを同時に読み取ることができます。実行可能コードを 1 つのメモリ バンクにロードし、データを別のメモリ バンクにロードすることで、多くのプログラムの実行時間をほぼ半分に短縮できます。

再入可能コードはスレッドセーフ (実行のみ) である必要があり、自己変更コードは許可されませんでした。他のプログラムでは、実行中に実行可能コードを変更することは、1100 シリーズのコンピューターの時代にはまだ許容されるプログラミング手法でしたが、パフォーマンスが低下するため、ユーザーはそれを行わないように推奨されていました。セキュリティ上の利点は宣伝されましたが、ほとんどの 1100 シリーズのアプリケーションをハッキングしても誰にもメリットがなく、当時は悪意のあるハッカーがほとんどいなかったため、あまり評価されていませんでした。

Exec 8 は主にバッチ処理システムであり、アプリケーション (「タスク」と呼ばれる) がスレッド (「アクティビティ」と呼ばれる) の CPU スケジュールの優先順位を非常に細かく制御できるようにしました。プロセッサの切り替えはプリエンプティブで、優先順位の高いスレッドが、どのプログラムでも現在最も優先順位の低いスレッドを実行しているプロセッサの制御を獲得しました。リアルタイム システムを除き、優先順位の最も低いタスクでもプロセッサ時間を取得しました。これは、完全に対称的なプロセッサ管理を備えたマルチプログラミングおよびマルチプロセス オペレーティング システムでした。ハードウェアに組み込まれたテスト アンド セット命令により、OS 内とマルチスレッド アプリケーション内の両方で非常に効率的で細分化されたロックが可能になりました。

Exec 8 では、作業は「実行」と呼ばれるジョブに編成され、その優先度と Uniservo テープ ドライブや Fastrand ドラム ファイルなどのロック可能なリソースの必要性に基づいてスケジュールされます。制御言語構文では、「@」記号 (Univac では「マスター スペース」と呼んでいました) が制御ステートメント認識記号として使用されます。この記号の直後にコマンドまたはプログラム名が続き、その後にコンマとオプション スイッチが続きます。スペース文字の後の残りのステートメントは、特定のコマンドによって異なります。FORTRAN プログラムをコンパイルするコマンドは、「@FOR[,options] sourcefile, objectfile」のようになります。アプリケーションの入力データは、ファイル (通常はカード イメージ) から読み取ることも、実行ストリーム内の @ コマンドの直後に記述することもできます。センチネル コマンド「@END」までのすべての行は入力データとみなされるため、これを挿入し忘れると、コンパイラは後続のコマンドをプログラム データとして解釈します。このため、実行ストリームに入力するよりもファイル内のデータを処理する方が望ましいとされました。

1968 年、 Exec 8 にタイムシェアリング機能を追加する作業が開始されました。これは、1969 年にエグゼクティブのレベル 23 で提供されました。タイムシェアリング (デマンド モードと呼ばれる) には、バッチ プロセスやリアルタイム プロセスと同じ機能がありました。バッチで実行できるすべての処理は、ASCII 端末から実行できました。デマンド モードでは、ジョブ ストリーム I/O は、カード イメージ (入力) ファイルやスプール (出力) ファイルではなく、端末ハンドラーに接続されました。両方に同じ実行制御言語が使用されました。数年後、より具体的なタイムシェアリング コマンドが追加され、エグゼクティブや実行中のプログラムのどちらもデータを期待していない場合でも、一部の制御ステートメントを非同期に発行して即時処理できるようになりました。端末からのみ入力できるこれらのコマンドは、「@@」で始まります。同じ端末から進行中の他の作業を停止せずに実行できるため、透過コマンドと呼ばれました。最初は、現在のプログラムを終了したり、端末出力をファイルにリダイレクトしたりするだけのステートメントでしたが、最終的には、ほぼすべての制御ステートメントが「即時」になることが許可されました。

バッチ実行とデマンド実行は両方とも @FIN ステートメントで終了し、実行がアクティブなときにデマンド ユーザーがセッションを終了すると、Exec は @FIN を要求せずに自動的に実行を終了します。

トランザクション処理機能は、1960 年代後半にユナイテッド航空との共同プロジェクトとして開発され、その後エア カナダとの別の共同プロジェクトで改良されました。この機能は 1972 年にオペレーティング システムに完全に統合され、1100 シリーズの将来の成長の基盤となりました。初期のユーザーは、リアルタイム プログラム内から通信回線を直接制御していました。トランザクション処理の開発には、通信回線を管理し、トランザクションとしてスケジュールされるメッセージを Exec 8 に提供する通信メッセージ システムが含まれていました。これにより、低レベルの通信物理回線管理とプロトコルがすべてアプリケーションから CMS 1100 アプリケーションに移動されました。

CMS 1100 自体は、通信回線の制御権を取得し、トランザクション メッセージをスケジュール用に送信する権限を持つ、リアルタイムのマルチスレッド プログラムとして実行されました。このため、Exec 8 では、どのような種類のアプリケーションでも、整合性の問題を引き起こさないように注意深く制御する必要があるという考え方になりました。セキュリティは確かに懸念事項でしたが、初期の頃はシステムの信頼性と整合性の方がはるかに大きな問題でした。システムは依然として主にバッチ処理とトランザクション処理であり、誰かがシステムに不正なコードをインストールする可能性はほとんどありませんでした。CMS 1100 は後に、デマンド ターミナルとトランザクション ターミナルの両方のインターフェイスになる機能を追加したため、ターミナルを両方に使用できるようになり、初期のターミナル ドライバーを Exec から削除できるようになりました。CMS 1100 は後に、CPComm (ClearPath Enterprise Servers Communications Platform) と SILAS (System Interface for Legacy Application Systems) の組み合わせに置き換えられました。^{[8] [9]} IntelベースのDoradoサーバーモデルでは、下位レベルの通信はファームウェアに移行され、上位レベルの通信はSILASとCPCommOS（ClearPath Enterprise Servers Communications Platform for Open Systems）によって処理されました。^[10]

Exec には、システム内で最高権限レベルで実行が許可されているすべてのコードが含まれています。他のコードをそれらの権限レベルに昇格させるメカニズムはありません。

Exec は、システム ハードウェアの管理、作業のスケジュールと管理、オペレーターおよび管理者とのコミュニケーションを担当します。

リリース 16.0 では、Exec はレベル 49R2 (49.70.5) です。内部システム レベルでは、21.92.42 (これは最初に広く使用された実稼働システムですが、以前のリリースは多くのサイトで実稼働で使用されていました) などの 3 部構成の番号が使用されます。最初の数字部分はメジャー レベルで、以前のすべての更新が新しいベース バージョンに統合された Exec の新しいバージョンを示します。これはまれなプロセスであり、数年間隔で発生します。2 番目の数字部分はメジャー レベルの更新のバージョンを示し、週に数回発生することがよくあります。機能コンテンツを凍結してリリースの準備をするという決定が下されると、3 番目の部分が機能し、修正とマイナー機能更新が適用されたプレリリース レベルのバージョンを示します。リリース用のレベルを準備すると同時に、エンジニアが将来のリリースに備えて変更を統合するにつれて、「メインライン」への更新が継続されます。長年にわたり、公式リリース レベルは完全な 3 部構成の番号でした。以降のリリースでは、3 つの部分からなる番号が引き続き内部的に使用されていますが、単に 44R1、44R2、49R2 などと命名されました。

Exec は本質的にはリアルタイムのマルチスレッド バッチ処理システムです。すべてがこのモデルに基づいて構築されています。Exec 自体は、主にリアルタイム プログラムとして構成されています。Windowsのサービスとして、または Linux と UNIX のデーモンとして実行される機能は、Exec 内のアクティビティとして、またはバックグラウンドで常に実行されるバッチ プログラムとして実装されます。

タイムシェアリング(デマンド モードと呼ばれる) とトランザクション処理は、バッチの特殊なケースとして実装されています。その結果、タイムシェアリング ユーザーまたはトランザクション プログラムが実行できる操作にはほとんど制限がありません。トランザクション プログラムの作成者に対しては、たとえばテープ マウントを要求するとパフォーマンスに満足できないという警告が多数ありますが、これは許可されています。

最大の作業単位は「実行」です。これは工場の「生産実行」という用語から取られたもので、通常は他のシステムのジョブまたはセッションに相当します。実行は「実行ストリーム」によって定義されます。実行ストリームは、実行する手順を表す一連の制御ステートメントです。実行ストリームには、ファイルの処理、プログラムの実行、および制御の分岐が含まれる場合があります。バッチ実行は通常、ファイルとして保存され、別の実行内からの「開始」コマンドまたはオペレータによってスケジュールされます。タイムシェアリング実行は、タイムシェアリング端末からログインして @RUN コマンドを入力することによって開始されます。多くの場合、@RUN ステートメントと 2 番目の制御ステートメント (多くの場合 @ADD またはプログラム実行) は、ユーザー プロファイルに基づいて自動的に生成されます。セキュリティ認証は、認証されたユーザー ID と実行制御ステートメントで提供されるその他の情報に基づいて検証されます。

トランザクションは特別なケースです。実際には制御ステートメントはありませんが、実行の内部データ構造が作成されます。これにより、Exec は、同じセキュリティ、アカウンティング、デバッグなどのメカニズムをトランザクション プログラムに関連付けることができます。通常、セキュリティ プロファイルは、トランザクション ユーザーが認証されたときにメモリにキャッシュされ、トランザクションがスケジュールされたときにユーザーのセッション データからトランザクション実行状態にコピーされます。各トランザクション インスタンスは基本的に実行であるため、アカウンティング、ログ記録、およびエラー処理はすべて実行メカニズムによってカプセル化されます。

バッチ ジョブ (実行) は、実行ストリーム (ジョブ制御言語ステートメント) がファイルに保存されるという特徴があります。バッチ ジョブには、ファイルの最初のレコードとして常に @RUN ステートメントが含まれます。このステートメントは、実行に名前 (runid) を付け、優先順位を定義し、ジョブが使用すると予想される SUPS (標準処理単位) の最大数を定義します。ジョブは、@START 制御ステートメントを使用して他のジョブから開始されるか、またはオペレーターが ST キー入力を使用して開始されます。システムは、起動時に任意の数のジョブに対して @START ステートメントを自動的に発行するように構成できます。これらのジョブは、初期化、回復、およびバックグラウンド機能を実行するために使用されます。

@RUN ステートメントのすべてのフィールドは、@START ステートメントの対応するフィールドによって上書きされる場合があります。@START が特権ユーザーによって実行される場合を除き、ユーザー ID およびその他のセキュリティ状態は常に @START を実行する実行から取得されます。

@RUN ステートメントには 2 つの優先度フィールドがあります。1 つはバックログ優先度を指定するために使用されます。バックログ優先度レベルは 26 レベル (A - Z) あります。Exec には、開いているバッチ実行の最大数が構成されています。そのレベルに達すると、ジョブは優先度順にバックログ キューから選択されます。優先度選択は通常 FIFO です。ただし、Exec は最初のプログラム実行までジョブ制御ステートメントを事前スキャンし、ファイル名とリール番号を探します。必要なリソースが利用できないためにジョブがすぐに停止する場合は、そのジョブをバイパスして、同じ優先度レベルの他のジョブを開始できます。

2 番目の優先度レベルは、実行プロセッサ リソース グループを定義します。一般に、実行グループの優先度が高いほど、プロセッサ時間が長くなります。

OS 2200 ジョブ制御言語は完全なプログラミング機能をサポートしていませんが、@ADD 制御ステートメントを通じて制御言語のシーケンスを動的に追加できます。追加するファイルは、追加する直前に同じジョブによって作成されたものである可能性があります。@ADD および他のほとんどの制御ステートメントは、実行中のプログラム内から API 経由で送信することもできます。^{[11]追加のプログラミング機能は、}シンボリック ストリーム ジェネレータ(SSG) を使用することで間接的に利用できます。 ^{[12] SSG は、入力パラメータとシステム情報からテキスト ファイルを操作および作成するためのプログラミング言語です。これは、構成管理 (} make ) 処理や、テキスト イメージをプログラムで作成する必要があるその他の機能 で頻繁に使用されます。結果の出力は、同じ実行で "@ADD" できるため、間接的にプログラミング可能な実行ストリームが提供されます。

オペレータ コマンドを使用して、実行のバックログと実行優先度の両方を変更できます。すべてのオペレータ コマンドは適切な権限を持つユーザーが API 経由で使用できるため、リモート管理者が自動化または制御できます。

期限はバッチの特殊なケースです。期限実行は、@RUN または @START 制御ステートメントで期限時間が指定されていることを除いて、他のバッチ実行とまったく同じです。期限時間は、制御ステートメントの最大 SUPS (時間見積もり) と組み合わせて使用​​されます。期限ジョブは、期限時間に間に合わない可能性がある場合を除き、または間に合わない可能性があると判断されるまで、通常のバッチ優先度で実行されます。期限までの時間と残りの SUPS の不一致が大きいほど、優先度が高くなります。期限はトランザクションを完全にシャットオフすることはできず、リアルタイムには影響しませんが、目的を達成するために必要であれば、システム内の他のほとんどの処理を効果的にシャットオフすることができます。

OS 2200 タイムシェアリング セッションは、デマンド (「オンデマンド」から来ている) 実行と呼ばれます。これらは、バッチ実行と同じ制御言語を使用しますが、いくつかの「即時」制御ステートメントと呼ばれる追加機能があります。即時制御ステートメントは、「@@」センチネルを使用します。これは、プログラムが実行中であっても、即時に実行されることを示します。即時制御ステートメントは、ファイルの作成や割り当てに使用できますが、最も重要なものは、デマンド ユーザーが実行中のプログラムをエラー終了させたり、シグナルを送信したりできるようにします。

トランザクションは実行として実行されますが、保存または送信された制御ステートメントはありません。代わりに、トランザクションセッションとして定義されたセッションからメッセージが受信されると、そのメッセージがスキャンされ、配置されるトランザクションキューが決定されます。これは通常、メッセージの最初の文字によって決定されますが、ユーザーが作成したスキャナーを追加することもできます。^[13]

最大 250,000 のアクティブ セッションを処理できる通信マネージャは、着信トランザクション メッセージを受け取り、それをメッセージ キューイング ソフトウェアに渡します。メッセージ キューイング アーキテクチャを使用して、キューに入れられたメッセージを無制限に処理できます。オペレーティング システムでトランザクション インターフェイス パッケージ (TIP) API が呼び出され、トランザクションが適切なキューイング ポイントにキューイングされます。各キューイング ポイントは、作業の優先度と同時実行レベル、および実行される関連トランザクション プログラムを識別します。

トランザクション プログラム スケジューリング ツリーにより、クライアントはトランザクション プログラムのグループの相対的な使用を確立できます。同時実行の制限により、1 種類の作業が他の作業を排除してシステムを占有することがなくなり、リソースの過剰使用も回避できます。ツリーには最大 4094 個のノードを作成できます。

• ツリー内の各ノードに指定された最大同時実行数
• 上位ノードの同時実行性は従属ノードの合計同時実行性を制限する
• 最高ノードの同時実行性がシステムの同時実行性を制限する

トランザクション プログラムごとに優先度 (0 ～ 63) と同時実行レベル (1 ～ 2047) を指定できます。

そのノードおよび上位ノードに有効な同時実行ポリシーによって制限される場合を除き、最も優先度の高いトランザクションがスケジュール対象として選択されます。

リアルタイムは別の種類の実行ではありません。むしろ、あらゆるアクティビティが要求する可能性のある一連の優先レベルです。リアルタイムは、OS 2200 通信マネージャ CPComm などの長時間実行されるバッチ プログラムで最もよく使用されますが、これに限定されるわけではありません。

アプリケーションが使用できる API には、36 のリアルタイム優先度レベルがあります。ユーザーとアカウントには、リアルタイム優先度を使用する権限が必要です。アプリケーションが優先度レベルをどのように使用するかは、サイト側で制御する必要があります。リアルタイム優先度は、それより低い優先度を完全に上回るため、不正なリアルタイム プログラムによって 1 つ以上のプロセッサが占有される可能性が高くなります。

リアルタイム優先度は個々のアクティビティ (スレッド) に適用されるため、プログラムではリアルタイム スレッドと非リアルタイム スレッドの両方が同時に実行される場合があります。

実行が開始されると、プロセッサへのアクセスによって進行速度が制御されます。Execの中心となるのは、すべてのプロセッサを管理するディスパッチャです。 ^[14]

Exec は最大 4095 のディスパッチ優先順位をサポートしますが、ほとんどのサイトではそれらの小さなサブセットのみが定義されています。最も高い 2 つの「優先順位」は切り替えられません。これらは、自発的に制御を放棄するまで、開始したプロセッサで続行する必要がある特定の種類の処理の認識です。割り込みロックアウトは、割り込みが到着したとき、または他の Exec コードがすべての割り込みを禁止する (割り込みハンドラがアクセスする可能性のあるデータの一部を変更するため) といういくつかの特殊な場合に発生します。

インターロックは、同じ物理プロセッサ上で実行する必要があるか、または単に割り込まれてはならない割り込み後処理ルーチンによって使用されます。ディスパッチャ、I/O 完了、および I/O 開始などがその例です。これらの両方の優先順位で使用されるすべてのロックはスピン ロックです。これは、他のユーザーがロックを設定できる唯一の方法が別のプロセッサ上であり、設計上、非常に短い命令シーケンスに対してのみロックを設定する必要があるためです。

高い Exec 優先度は、オペレータ コマンド ハンドラや、リアルタイム プログラムが制御しているときでも実行する必要があるその他の機能によって使用されます。これらの機能では、非常に短い時間しか使用されないはずです。さらに時間が必要な場合は、作業をキューに入れて、低い Exec アクティビティで処理する必要があります。

リアルタイム アクティビティはプロセッサ クォンタムが無制限で、優先度の高いリアルタイム アクティビティまたは High Exec アクティビティによって中断されない限り、切り替えなしで実行されます。リアルタイム アクティビティには、優先度の低いアクティビティを実行している利用可能なプロセッサの制御が与えられます。即時の可用性を確保するために、必要に応じてプロセッサ間で割り込みが送信されます。リアルタイムは、ミサイルの飛行、シミュレータの実行、および即時の応答を必要とするその他の機能に使用されます。

トランザクションの優先度は、サイトの定義に従って 2 つの方法で処理できます。優先度のみが重要で、クォンタム サイズが基本的に無限であるという点で、優先度の低いリアルタイムのようなものになります。これは、航空券の予約など、存続期間が非常に短いトランザクションに適しています。プログラミング エラーが原因でループした場合、Exec は、設定された非常に短い最大時間に達するとトランザクションを終了します。もう 1 つの形式では、Exec が優先度を一定の範囲内で変更して、システム リソースの使用を最適化できます。このアプローチでは、I/O が制限されているプログラムには高い優先度と短いタイム スライスが与えられ、コンピューティングを行っているプログラムには優先度が徐々に低くなりますが、タイム スライスが長くなります。Exec は、プログラムが異なる時間に両方の動作をすることが多いため、動作に基づいてこれらの優先度を動的に調整します。このアプローチは、データベース クエリや航空券の運賃見積もりなど、実行時間の長いトランザクションに適しています。

バッチとデマンドでは、常に動的に調整された優先順位が使用されます。I/O が制限されているプログラムや、タイムシェアリング ユーザーと会話しているプログラムは、優先順位が高くなりますが、タイム スライスは短くなります。計算指向の強いプログラムは、優先順位が低くなり、タイム スライスは長くなります。

Exec には、ディスパッチを最適化するためのメカニズムがさらに 2 つあります。1 つはアフィニティ ベースのディスパッチです。可能な場合、Exec は前回実行したのと同じプロセッサでアクティビティを実行し、キャッシュの残りの内容を最大限に活用します。それが不可能な場合は、キャッシュとメモリのアクセス時間の観点から「最も近い」プロセッサでアクティビティを実行しようとします。2 つ目は「公平性」ポリシー メカニズムです。サイトでは、トランザクション、デマンド、バッチのそれぞれに割り当てるリソースの相対的な割合を定義できます。トランザクションとバッチには、優先度グループがあり、グループの時間の何パーセントを優先度に割り当てるかをさらに指定できます。これにより、トランザクションがシステムを支配しすぎてバッチ作業がまったく行われないことがなくなります。さまざまな優先度グループ内で、各グループである程度の処理が確実に行われるようにします (グループの割合が 0 でない限り)。これらの「公平性」アルゴリズムは、プロセッサが非常にビジーな場合にのみ機能しますが、OS 2200 システムは、すべてのプロセッサがほぼ 100% 使用された状態で実行されることがよくあります。

OS 2200 は、システム パフォーマンス管理の複数のモデルをサポートしています。^[15] 顧客は一定の固定パフォーマンス レベルを購入でき、Exec はプロセッサの使用状況を監視し、パフォーマンスがそのレベルを超えないようにします。顧客は、作業負荷が増加したり、緊急時に必要になったりした場合に、システムの最大容量まで、一時的または永続的に追加のパフォーマンスを購入することもできます。

最近、このシステムには従量制使用機能が追加されました。このモードでは、システムの全機能を常に顧客が利用できます (ただし、管理上制限されることがあります)。使用量は 1 か月間で累積され、報告された使用量が Unisys の請求部門に送信されます。特定の契約条件に応じて、顧客は、その月の契約ベースラインを超えた超過使用量の請求書を受け取るか、契約合計使用量が減少したことを示す明細書を受け取る場合があります。最初の形式は、超過分に対して課金される可能性のある携帯電話の請求書のようなものです。後者は、プリペイド電話カードを購入するようなものです。

OS 2200 には、他のほとんどのオペレーティング システムのような階層型ファイル システムはありません。代わりに、構造化された命名規則と、プログラム ファイルと呼ばれるコンテナ ファイルの概念があります。

OS 2200 のファイルは、ファイル内のワード オフセットまたはファイル内のセクター (28 ワード単位) オフセットのいずれかでアドレス指定できる単なるコンテナーです。28 ワードは、物理トラックごとに 64 個のそのような単位を保持できた初期の大容量ストレージ デバイス (FASTRAND ドラム) からの歴史的な単位です。とはいえ、これは幸運な歴史的偶然です。このような 28 ワード単位 4 つ、つまり 112 ワードは、504 バイトを占めます。今日の大容量ストレージ デバイスはすべて 512 バイトの物理レコードを使用しているため、OS 2200 クライアントのほぼすべてが、物理レコード サイズとデータベース ページ サイズとして 112 ワードの倍数を採用しています。I/O プロセッサは、書き込み時に 8 バイトのゼロを追加し、各物理レコードの読み取り時にゼロを削除することで、504<->512 バイトのマッピングを自動的に調整します。 OS 2200 は、112 ワードの倍数以外のサイズを使用するアプリケーションを、含まれる物理レコードを分割せずに読み取り、変更されていない部分と変更された部分をデータ チェーンで書き戻すことによって処理します。特別なロック機能により、デバイス エラーが発生した場合やクラスター内の複数のシステム間でも分割不可が保証されます。

ファイル形式やその他の内部データ構造については、『データ構造プログラミングリファレンスマニュアル』で説明されています。^[16]

Exec-8 以降、ファイル名は Qualifier*Filename(f-cycle) という形式になっています (例: "PERSONNEL*EMPLOYEES(+1)")。^[11] Qualifier とファイル名は、クライアントが望む命名構造を作成するために使用される 12 文字の文字列です。f-cycle は、ファイルの複数世代を可能にする 0 から 999 までの数字です。これらは、相対番号で参照できます。(+1) 次のサイクルまたは新しいサイクル、(-1) 前のサイクル、(+0) 現在のサイクル。サイクルを省略すると、現在のサイクルがデフォルトになります。ファイルの新しい世代を作成するバッチ プロダクション ランでは、このアプローチが使用されます。番号は 999 を超えると折り返されます。一度に存在できる連続した相対サイクル番号は 32 個だけです。(+1) を作成すると、(-31) が削除されます。

任意のファイルをプログラム ファイルとして使用できます。プログラム ファイルには、通常ファイルとして機能する要素が含まれています。要素の名前は、修飾子*ファイル名 (f-cycle).要素/バージョン (e-cycle) です (例: "PERSONNEL*PROGRAMS.TAXCALC/2008")。要素とバージョンは、ユーザーが希望する方法で使用される 12 文字の名前です。e-cycle は、世代番号を表すという点で f-cycle に似ていますが、同時実行サイクルが 32 に制限されず、制限は 256K サイクルです。ただし、e-cycle はテキスト要素にのみ適用され、テキスト要素の各行には、挿入および削除されたサイクル番号が付けられます。要素には、タイプとサブタイプもあります。最もよく使用されるタイプは、「テキスト」と「オブジェクト」です。デフォルトのタイプが適切でない場合は、オプションで適切なタイプを選択します。テキスト要素には、通常プログラミング言語を表すサブタイプもあります (例: "ASM"、"C"、"COB"、"FOR")。オブジェクト ファイルのデフォルトの要素名は、作成元のテキスト ファイルと同じです。

オブジェクト要素は、メイン プログラムである場合、またはメイン プログラムを含む他のオブジェクト要素とリンクされている場合に実行できます。リンクは静的または動的です。必要なすべてのサブプログラムが同じプログラム ファイル内にあるか、システム ライブラリであるか、または既知のものである場合、メイン プログラムは事前リンクなしで実行できます。動的リンカーによる未完了の参照の検索を指示するルールをプログラム ファイルに含めることができます。リンカーは、複数のオブジェクト モジュールを静的にリンクして、元のオブジェクト モジュールのすべての命令、データ、およびその他の情報を含む新しいオブジェクト モジュールを形成するためにも使用できます。

オムニバス要素は、アプリケーションによってデータとして使用される場合もあれば、アプリケーションやシステム ユーティリティの構造化された情報を保持するために使用される場合もあります。オムニバス要素には想定される構造はありません。

以前の (基本モード) プログラミング モデルとの互換性のために、再配置可能要素タイプと絶対要素タイプがあります。再配置可能要素は、基本モード コンパイラの出力です。これらは、基本モードの静的リンカー (@MAP – コレクター) によって結合され、実行可能な「絶対」要素を形成します。

OS 2200 は、完全な仮想ファイル システムを実装しています。ファイルは、あらゆる大容量ストレージ デバイスのどこにでも割り当てることができます。大容量ストレージは、仮想メモリの管理方法と同様に、大きなスペース プールとして扱われます。可能な場合は連続したスペースが割り当てられますが、大容量ストレージは 8KB サイズのページのセットとして扱われ、ファイルは、同じデバイスまたは異なるデバイスの必要な数の領域に配置できます。ファイルの動的拡張では、以前の割り当てに隣接するスペースを割り当てようとしますが、使用可能なスペースがあればどこでもスペースが見つかります。実際、ファイルは大容量ストレージ上に存在していなくても使用できます。Exec とファイル バックアップ システムは完全に統合されています。ファイルのバックアップが行われると、テープ リール番号がファイル ディレクトリに記録されます。大容量ストレージのスペースが不足すると、現在のバックアップ コピーがあり、スペースが使用可能なファイルには、単に「アンロード」のマークが付けられます。その方法で十分なスペースが見つからない場合は、バックアップが開始されます。

アンロードされたファイルへの参照は、ファイルが大容量ストレージにコピーされるまでキューに入れられます。システム全体は自動で行われ、ユーザーにとっては透過的です。^[17]

一般的に、Execはアクセスメソッドを提供しません。ファイルは単なるコンテナです。アクセスメソッドは、言語ランタイムシステムとデータベースマネージャによって提供されます。唯一の例外は、大量のトランザクション処理のために提供される固定ブロックアクセスメソッドです。^[18] データベースマネージャよりもオーバーヘッドがはるかに少ないですが、すべてのロック、クラスタリング、およびリカバリメカニズムに参加します。

クライアントがファイルの場所をより明示的に制御する必要がある場合、「リムーバブル パック」の概念を使用できます。かつては、これらは物理的に取り外し可能なディスク パックを表し、オペレーティング システムは必要に応じてオペレーターにパック マウント要求を自動的に生成していました。

現在でも、これらはファイル (通常はデータベース ファイルまたはトランザクション ファイル) を 1 つ以上のディスク ボリュームに配置するために使用されています。ファイルは複数のディスク ボリュームにまたがる場合があり、ファイルの作成時にボリューム名のリストが提供されるようになりました。このようなボリューム グループにあるファイルはバックアップされますが、自動仮想スペース管理の対象にはなりません。

OS 2200 は、Common Internet File System ( CIFS ) の完全な実装も提供します。^[19] CIFS は、Microsoft サーバーと UNIX/Linux Sambaソフトウェアで使用される SMB プロトコルを実装します。ClearPath OS 2200 の CIFS は、他の CIFS 準拠システムに対するファイル サーバーとファイル クライアントの両方です。これには、Windows を実行しているデスクトップ PC が含まれます。CIFS は SMB メッセージ署名をサポートします。

OS 2200 のセキュリティを維持するために、ClearPath OS 2200 の CIFS は 2 つのレベルの保護を提供します。まず、OS 2200 ファイルは、CIFS コマンドで「共有」として宣言されるまで、ネットワークからは見えません。共有を宣言できるユーザーを制御するための特定の権限が存在します。2 番目のレベルの制御では、すべてのアクセスが OS 2200 セキュリティによって保護されます。CIFS 経由で OS 2200 にアクセスするクライアントは、NTLMまたはKerberosによって自動的に識別されるか、OS 2200 ユーザー ID とパスワードのクエリが提示されます。

CIFS では、OS 2200 ファイルを階層ビューで表示できます。通常、ツリーの最上位レベルには修飾子が表示され、その後にファイル名、要素名、バージョンが続きます。さらに、ファイルは完全な Windows ファイル名形式を使用して OS 2200 サーバーに保存できます。Windows アプリケーションは、OS 2200 を別のファイル サーバーとして認識します。OS 2200 アプリケーションには、ネットワーク内の Windows ファイル サーバーなどの他の CIFS 準拠サーバーに存在するファイルの読み取りと書き込みに使用できる API があります。テキスト ファイルは、OS 2200 の内部形式との間で自動的に変換されます。バイナリ ファイルは、アプリケーション プログラムによって認識される必要があります。

OS 2200 で実行される CIFSUT ユーティリティは、暗号化された圧縮ファイルを WinZip などの他のソフトウェアと交換できます。

サブシステムと保護されたサブシステムの概念は、OS 2200 の設計の中心です。サブシステムは、Windows の .dll に最も似ています。サブシステムは、システムで実行されているすべてのプログラム間で共有できるコードとデータです。^[20] OS 2200 では、各サブシステムに独自のバンク セットがあり、アドレス空間の別の部分に配置され、ユーザー プログラムからは直接アクセスできません。代わりに、ハードウェアと OS が、Call 命令のターゲットになる可能性のある「ゲート」を提供します。詳細については、 Unisys 2200 シリーズのシステム アーキテクチャを参照してください。

データベース マネージャー、ランタイム ライブラリ、メッセージング システム、およびその他の多くのシステム機能は、サブシステムとして実装されています。ランタイム ライブラリなどの一部のサブシステムは、通常純粋なコードで構成されており、ゲートを必要とせずに Call 命令の直接のターゲットになる場合があります。これらのサブシステムは、ユーザー プログラムの保護環境で実行されます。データベース マネージャーなどの他のサブシステムは、コードとデータまたは特権コードで構成されており、ゲート経由でのみ呼び出すことができます。これらのサブシステムには、誰が呼び出せるかを制御するために、アクセス制御リストが関連付けられている場合もあります。さらに重要なのは、ゲートは、表示される特定のエントリ ポイント、サブシステムが実行される保護環境、および多くの場合、呼び出し元に関する追加のセキュリティ情報を提供するユーザー固有のパラメーターを制御することです。

OS 2200 セキュリティ システムは、不正アクセス、変更、または漏洩からデータを保護するように設計されています。これには、DoDオレンジ ブック B1レベル仕様の実装が含まれています。^[21] OS 2200 は、1989 年 9 月に初めて B1 評価に合格しました。この評価は 1994 年まで維持されました。その後、OS 2200 開発者は、B1 評価で要求される開発およびドキュメント作成の慣行に従い続けました。

B1システムの中心となるのは、ユーザーとオブジェクトの概念です。^{[22] [23]}ユーザーには、ID、クリアランスレベル、コンパートメント、権限があります。オブジェクトは、さまざまな種類のアクセスに対して、それらの特定の組み合わせを必要とします。OS 2200のオブジェクトは、ファイル、保護されたサブシステム、デバイス、テープリールで構成されています。

ユーザー セッションのセキュリティ プロファイルには、ユーザー ID、クリアランス レベル (0 ～ 63)、コンパートメント セット、および許可された権限のセットが含まれます。OS 2200 は、機密性に関するBell-La Padula モデル(読み取りなし、書き込みなし) とBiba 整合性モデル(読み取りなし、書き込みなし)に基づいて、強制アクセス制御(MAC ) と任意アクセス制御 (DAC) の両方を実装します。実行でファイルを読み取ったり実行したりするには、実行の実行クリアランス レベルがファイルのクリアランス レベル以上で、ファイルのクリアランス レベルが 0 または実行のクリアランス レベル範囲内である必要があります。さらに、実行の実行コンパートメント セットには、ファイルのコンパートメント セットが含まれている必要があります。OS 2200 は Bell-La Padula モデルと Biba モデルの要件を組み合わせているため、ファイルへの書き込みやファイルの削除を許可するには、実行の実行クリアランス レベルとコンパートメント セットがファイルのものと正確に一致している必要があります。

DAC は、アクセス制御リストをオブジェクトに関連付けます。リストは、アクセス権を持つユーザーとユーザー グループを識別し、ユーザーまたはグループに許可されるアクセスの種類 (読み取り、書き込み、実行、または削除) を定義します。

B1 コントロールの完全なセットはほとんどの環境にとって制限が厳しすぎるため、システム管理者は適用するコントロールを選択してサーバーを構成できます。基本セキュリティからセキュリティ レベル 3 までの一連のセキュリティ レベルが開始点として機能します。

すべての OS 2200 システムには、セキュリティ担当者として指定されたユーザーが 1 人います。基本的なセキュリティが構成されたシステムでは、セキュリティ担当者のみが特定のタスクを実行できます。より高いレベルのセキュリティが構成されたシステムでは、他の信頼できるユーザーがこれらのタスクの一部を実行できる場合があります。

OS 2200 は、最小権限の原則に基づくきめ細かなセキュリティ メカニズムを提供します。この原則では、必要なタスクを実行するために必要な最小限の権限のみが付与されることが求められます。したがって、OS 2200 には、どのユーザーでも引き受けることができる「スーパー ユーザー」ロールの概念はありません。代わりに、各ユーザーに個別に付与できる特定の権限の大規模なセットを使用します。各権限は、特定の権限に関連付けられています。

セキュリティ レベル 1 以上に設定されたシステムでは、オブジェクトを作成したユーザーがそのオブジェクトの所有者になります。デフォルトでは、オブジェクトは作成ユーザーに対してプライベートですが、パブリックにしたり、アクセス制御リストによって制御したりすることもできます。所有者またはセキュリティ担当者は、そのオブジェクトのアクセス制御リストを作成できます。

基本的なセキュリティが設定されたシステムでは、ファイルには所有者がいません。代わりに、ファイルはアカウントまたはプロジェクトに対して非公開で作成されるか、公開されます。ファイルへのアクセスは、読み取りキーと書き込みキーによって制御できます。

ユーザーがシステムにログオンすると、自分自身を識別し、オプションでこのセッションで使用するクリアランス レベルとコンパートメント セットを選択します。

OS 2200 は柔軟な認証システムを提供します。複数の認証メカニズムが同時にサポートされます。クライアントまたはサードパーティが作成した認証ソフトウェアも使用できます。標準の認証機能には次のものが含まれます。

• ユーザーIDとパスワードはOS 2200によって暗号化されたファイルに保存されます
• Microsoft Windowsなどの外部システムによるユーザーIDとパスワードのメカニズムを使用した認証
• NTLM
• ケルベロス
• LDAP の

最後の 2 つは、生体認証、スマート カード、およびそれらのテクノロジでサポートされているその他の認証メカニズムの使用を許可します。

OS 2200は、呼び出し元データを暗号化および復号化するソフトウェアサブシステムであるCipher APIを通じて、保存データの暗号化を提供します。^[24] Cipher APIは、バルクデータ暗号化用のハードウェアアクセラレータカードの使用もサポートしています。

CMOS ベースの Dorado サーバーの場合、CPComm は転送中のデータに対してSSL/TLS暗号化を提供します。Intel ベースの Dorado サーバーの場合、SSL と TLS はDorado ファームウェアに含まれるopenSSLによって提供されます。すべての Dorado サーバーは TLS レベル 1.0 から 1.2 および SSLv3 をサポートしていますが、プロトコルの脆弱性のため、SSL はデフォルトで無効になっています。

CPCommと Cipher API はどちらも、 FIPS認定のソフトウェア暗号化モジュールであるCryptoLib の暗号化サービスを使用します。AESおよびTriple DESアルゴリズムは、CryptoLib に実装されているアルゴリズムの 1 つです。

OS 2200 は、アーカイブ データの暗号化を提供する暗号化テープ ドライブもサポートしています。

OS 2200 システムは、単一システムよりも高いパフォーマンスと可用性を実現するためにクラスタ化できます。最大 4 つのシステムをクラスタに結合し、共有ディスクを介してデータベースとファイルを共有できます。ハードウェア デバイスである XPC-L は、データベースとファイル アクセス用の高速ロック マネージャーを提供することで、システム間の調整を行います。^[25]

クラスター環境では、各システムが独自のローカル ファイル、データベース、アプリケーション グループを持つことができ、さらに共有ファイルと 1 つ以上の共有アプリケーション グループを持つことができます。ローカル ファイルとデータベースには、1 つのシステムからのみアクセスできます。共有ファイルとデータベースは、クラスター内のすべてのシステムから同時にアクセスできるディスク上に存在する必要があります。

XPC-L は、システム間の通信パスを提供し、アクションを調整します。また、非常に高速なロック エンジンも提供します。XPC-L への接続は、非常に低いレイテンシで動作する特殊な I/O プロセッサを介して行われます。XPC-L のロック マネージャは、ファイル ロックとデータベース ロックの両方に必要なすべての機能を提供します。これには、デッドロック検出や、失敗したアプリケーションのロック解除機能が含まれます。

XPC-L は 2 台の物理サーバーで実装され、完全な冗長構成を作成します。XPC-L ファームウェアの新しいバージョンのロードなどのメンテナンスは、一方のサーバーで実行しながら、もう一方のサーバーを継続して実行できます。一方のサーバーへの物理的な損傷などの障害が発生しても、すべての情報が両方のサーバーに保存されるため、クラスターは停止しません。

OS 2200の操作は、アクティブなオペレータと1つ以上のコンソールを中心に構築されています。各コンソールはターミナルウィンドウであり、その一部は固定ディスプレイ用に予約されており、システム内のアクティビティに関する概要情報が頻繁に更新されます。^[26]

コンソールの残りの部分は、イベントのスクロール表示として使用されます。オペレータの応答を必要とするメッセージが発行されると、0 から 9 までの番号が付けられ、応答があるまでディスプレイに表示されます。テープ マウント メッセージは他のメッセージとともにスクロールしますが、テープがマウントされるまで 2 分ごとに繰り返されます。

Operations Sentinelは、すべてのOS 2200操作に使用されます。^[27] OS 2200コンソールは、Operations Sentinelディスプレイ内の単なるウィンドウです。ディスプレイPCは必要な数だけ使用できます。リモート操作が一般的です。Operations Sentinelは、任意の数のClearPath、Windows、Linux、およびUNIXシステムをサポートします。

自動アクション メッセージ データベースが製品とともにリリースされています。^[28] このデータベースにより、Operations Sentinel はメッセージを認識できます。応答が必要なメッセージに自動的に応答したり、不要なメッセージを非表示にしたり、他の言語に翻訳したり、イベントを作成したりするためのスクリプトを作成できます。一部のクライアントでは、完全なダーク ルーム操作が使用されています。最大で、リモート ロケーションに Operations Sentinel ディスプレイを設置してシステムを監視し、特定のイベントが発生したときにアラートを作成します。

OS 2200システムの管理は、システムの特定の領域に特化したさまざまなツールを使用して実行されます。たとえば、トランザクション環境の管理に使用されるツールがあり、新しいトランザクションプログラムをインストールしたり、それらに関する必要な情報をすべて指定したり、キュー構造、優先順位、同時実行レベルなどを変更したりできます。^[29]

その他のツールはセキュリティ担当者専用であり、ユーザーの作成、許可された権限の変更、システムセキュリティ設定の変更などが可能です。^{[22] 、[30] 、[23]}

ほとんどのツールにはグラフィカル インターフェイスがありますが、一部のツールにはグラフィカル インターフェイスがありません。すべてのツールは、すべてのアクションが制御ストリームで指定されるバッチ保存ファイル インターフェイスを提供します。これにより、ローカル サイト (時刻やその他のイベントに基づく場合もあります) またはリモート サイトから、あらゆる管理インターフェイスをスクリプト化できます。管理領域ごとに固有の権限が必要です。

アプリケーショングループは、ユニバーサルデータシステム（UDS）のインスタンス、^[31]、メッセージキューサブシステムのインスタンス、およびいくつかのトランザクションセットで構成される論理構造です。各アプリケーショングループには独自の監査証跡があります。OS 2200は、システム内で最大16のアプリケーショングループをサポートします。

アプリケーション グループの概念は、よく「アプリケーション」と呼ばれるものに対応します。つまり、接続された処理のより大きな単位を表すプログラムとデータのセットです。たとえば、アプリケーション グループは航空会社のシステムを表す場合があります。別のアプリケーション グループは、企業の財務システムを表す場合があります。または、銀行支店のように、アプリケーション グループが同じアプリケーションとデータ モデルのインスタンスを表す場合があります。重要なことは、各アプリケーション グループに独自の環境、セッション、リカバリなどがあることです。

アプリケーション グループは個別に開始、停止、回復できます。

アプリケーション グループには、独自のアカウンティング ルールやスケジュール ルールはありません。複数のアプリケーション グループ内のトランザクションは、同じ優先順位を共有したり、優先順位をインターリーブしたりできます。これにより、サイトはシステム全体のトランザクションの相対的な優先順位を制御できます。

• ハードウェア アーキテクチャの詳細については、Unisys 2200 シリーズ システム アーキテクチャを参照してください。
• OS 2200 コンパイラおよびリンカーの詳細については、Unisys OS 2200 プログラミング言語を参照してください。
• OS 2200 データベースおよびデータベース マネージャーに関する情報については、Unisys OS 2200 データベースを参照してください。
• OS 2200 通信の詳細については、Unisys OS 2200 通信を参照してください。
• OS 2200 分散処理の詳細については、Unisys OS 2200 分散処理を参照してください。

Unisys History Newsletter には、Unisys の歴史とコンピュータに関する記事が掲載されています。すべての Unisys History Newsletter に加えて、他のサイトへのリンクもあります。

ユニシスの歴史的アーカイブのほとんどは、ミネソタ大学のチャールズ バベッジ研究所とデラウェア州のハグレー博物館図書館に保管されています。チャールズ バベッジ研究所には、ERA のアーカイブ、ミネソタ州セントポールの初期のレミントン ランド アーカイブ、およびバローズ アーカイブが保管されています。ハグレー博物館図書館には、スペリー アーカイブの大部分が保管されています。

Arcane Sciences の 2020 年代の OS 2200 に関する非常に役立つ紹介記事。