Loading article…
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（Executive System for the 1108）も登場しました。
UNIVAC 1108コンピュータは1964年に発表され、1965年末に納入されました。最初の1108コンピュータは、 UNIVAC 1107用に開発されたExec IとExec IIを使用していました。しかし、UNIVACは最大4つのプロセッサを搭載した対称型マルチプロセッサ版の1108を提供する予定でしたが、初期のオペレーティングシステム（実際には基本的なモニタプログラム）は、限定的なマルチプログラミングをサポートしていたものの、そのようなマルチプロセッサ版向けには設計されていませんでした。
1972年にUNIVAC 1110が発売された際、対応システム範囲の拡大を反映して、オペレーティングシステムの名称はOS 1100に変更されました。OS 1100という名称は、1988年にSperry 2200シリーズが 1100シリーズの後継機種として登場し、OS 2200に名称変更されるまで維持されました。その後、2200シリーズはUnisys ClearPath IXシリーズ、そしてUnisys ClearPath Doradoシリーズへと名称変更されましたが、オペレーティングシステムの名称はOS 2200のままでした。
会社名と製品名も時間の経過とともに変化しました。[ 2 ]セントポールのエンジニアリング リサーチ アソシエイツ(ERA) は、レミントン ランド コーポレーションに買収されました。レミントン ランドは、当時UNIVACコンピュータを製造していたフィラデルフィアのエッカート モークリー コンピュータ コーポレーションも買収しました。この 2 社は、ウィリアム ノリスの指揮の下、レミントン ランドの UNIVAC 部門に統合されました。 ウィリアム ノリスはERA の創設者の 1 人であり、後にレミントン ランドを離れてコントロール データ コーポレーションを設立しました。レミントン ランド コーポレーションの UNIVAC 部門は、レミントン ランドがスペリー コーポレーションと合併した後、スペリー ランド コーポレーションの UNIVAC 部門になりました。1970 年代にスペリー ランドは、社名をスペリー コーポレーションに変更し、すべての部門名をスペリーで始める企業アイデンティティ プログラムを開始したため、コンピュータ システム部門はスペリー UNIVAC になりました。その後、部門名は削除され、すべてが単にスペリーになりました。
オペレーティングシステムのカーネルは、Unisys社および顧客の担当者のほとんどから今でも「Exec」と呼ばれています。しかし、Unisys社がシステムベースリリースとして一緒にテストされた製品スイートをリリースし始めたとき（後に「ClearPath OS 2200 Release n 」と呼ばれるようになりました）、OS 2200という用語は、システムリリースに含まれる製品スイート全体と、 Doradoハードウェアプラットフォーム向けに非同期でリリースされたBISなどの他の製品を指すようになりました。
1986年にバロウズ社とスペリー社が合併し、ユニシス社となりました（2200シリーズの長年の顧客の中には、「UNIVACは今もあなたのサプライヤーです」という意味だと言う人もいます）。[ 3 ]両社の主要なメインフレーム製品ラインは、バロウズ社のMCPオペレーティングシステムやスペリー社のOS 2200などを含め、開発が続けられています。
2016年、Unisysは教育および娯楽目的でOS2200の仮想Microsoft Windows版を無償で提供した。[ 4 ]
EXEC 8（EXEC VIIIとも呼ばれる）は、1964年にUNIVAC 1108向けに開発されたUNIVACのオペレーティングシステムです。UNIVAC 1107で使用されていた以前のオペレーティングシステム、 EXEC IとEXEC IIの優れた機能を統合しました。EXEC 8は、商用的に成功した最初のマルチプロセッシングオペレーティングシステムの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) であったため、コア メモリがシステムの中で最も高価な部分であったため、メモリの効率的な使用が最も重要な制約でした。
大容量ストレージは、長さ6フィートの回転ドラムで構成され、容量は256kW（FH-432）から2MW（FH-1782）でした。最大容量の大容量ストレージはFASTRANDドラムで、22MW（99MB）でした。ファイルの断片化は、「ファイル保存」と呼ばれる処理によって対処され、通常は夜間に1日1回実行されました。この処理では、すべてのファイルをテープに書き出し、ドラムのファイルシステムを再初期化してから、ファイルを再度読み込んでいました。
厳しいメモリ制約とリアルタイム処理のため、コアにロードされるコードのコピーを1つだけにしておくことが必須でした。1108はマルチタスク用に設計されていたため、システムは完全に「リエントラント」（スレッドセーフ）でした。各リエントラントモジュールは、実行データのインスタンスごとに異なる単一のメモリ「ベースアドレス」を介してプログラムデータにアクセスしました。実行コンテキストの切り替えは、単一のレジスタの異なるベースアドレスを設定するだけで、単一の命令で実行できました。システムは、共有データ構造を保護するために、きめ細かいロックを使用しました。実行部、コンパイラ、ユーティリティ、さらには複数のコピーが同時に実行される可能性のある高度なユーザーアプリケーションでさえ、コードを共有できるように記述されていました。これにより、メモリにロードするコピーを1つだけにするだけで済み、メモリ容量とコードのロードにかかる時間の両方を節約できました。
コードとデータを別々のロードエンティティに分離するもう一つの理由は、メモリがIBANK（命令）とDBANK（データ）と呼ばれる2つの独立したバンク（別々の物理的な筐体）として実装されていたためです。それぞれに独自のアクセスパスがあったため、CPUは両方のバンクを同時に読み取ることができました。実行可能コードを一方のメモリバンクに、データをもう一方のバンクにロードすることで、多くのプログラムの実行時間をほぼ半減させることができました。
再入可能なコードはスレッドセーフ（実行のみ）である必要があり、自己書き換えコードは許可されていませんでした。他のプログラムでは、1100シリーズのコンピュータの時代には、実行時に実行可能コードを変更することは依然として許容されるプログラミング手法でしたが、パフォーマンスの低下を招くため、ユーザーには行わないよう推奨されていました。セキュリティ上の利点は謳われていましたが、1100シリーズのアプリケーションのほとんどをハッキングしても誰にも利益がなく、また当時悪意のあるハッカーは少なかったため、それほど重視されていませんでした。
Exec 8は主にバッチ処理システムであり、アプリケーション（「タスク」と呼ばれる）がスレッド（「アクティビティ」と呼ばれる）のCPUスケジューリング優先度を非常に細かく制御できるように設計されていました。プロセッサの切り替えはプリエンプティブ方式で、優先度の高いスレッドが、現在実行中のプログラムの中で最も優先度の低いスレッドのプロセッサを制御できるようになりました。リアルタイムシステムを除き、最も優先度の低いタスクでさえ、ある程度のプロセッサ時間を取得できました。Exec 8は、完全に対称的なプロセッサ管理を備えたマルチプログラミングおよびマルチプロセッシングオペレーティングシステムでした。ハードウェアに組み込まれたテストアンドセット命令により、OS内およびマルチスレッドアプリケーション内の両方で、非常に効率的かつきめ細かなロックが可能でした。
Exec 8 では、作業は「実行」と呼ばれるジョブに編成され、優先順位と Uniservo テープ ドライブや Fastrand ドラム ファイルなどのロック可能なリソースの必要性に基づいてスケジュールされます。制御言語の構文では、制御ステートメントの認識記号として「@」記号 (Univac では「マスター スペース」と呼ばれていました) を使用します。その直後にコマンドまたはプログラム名、コンマ、オプション スイッチが続きます。スペース文字の後、ステートメントの残りの部分は特定のコマンドによって異なります。Fortran プログラムをコンパイルするコマンドは、 「@ FOR [,options] sourcefile, objectfile」のようになります。アプリケーションの入力データはファイル (一般的にはカード イメージ) から読み込むか、実行ストリームで @ コマンドの直後に記述できます。番兵コマンド「@END」までのすべての行は入力データとみなされるため、これを挿入し忘れると、コンパイラは後続のコマンドをプログラム データとして解釈します。このため、実行ストリームに入力するよりもファイルでデータを処理する方が望ましいとされていました。
1968年、 Exec 8にタイムシェアリング機能を追加する作業が開始され、1969年にExec 8のレベル23で実装されました。タイムシェアリング（デマンドモードと呼ばれた）は、バッチ処理やリアルタイム処理と同じ機能を備えていました。バッチ処理で実行できるすべての処理をASCII端末から実行できました。デマンドモードでは、ジョブストリームの入出力は、カードイメージ（入力）ファイルやスプール（出力）ファイルではなく、端末ハンドラに接続されました。どちらの場合も同じ実行制御言語が使用されました。数年後、より具体的なタイムシェアリングコマンドが追加され、Execや実行中のプログラムがデータを待っていない場合でも、一部の制御ステートメントを非同期で発行して即時処理できるようになりました。これらのコマンドは端末からのみ入力でき、「@@」で始まりました。同じ端末から他の進行中の作業を停止することなく実行できるため、透過コマンドと呼ばれました。当初は、現在のプログラムを終了したり、端末出力をファイルにリダイレクトしたりするだけのステートメントでしたが、最終的には、ほぼすべての制御ステートメントが「即時」で実行できるようになりました。
バッチ実行とオンデマンド実行はどちらも@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には、システム内で最高レベルの権限で実行が許可されているすべてのコードが含まれています。他のコードをこれらの権限レベルに昇格させる仕組みはありません。
担当者は、システムハードウェアの管理、作業のスケジュール管理、およびオペレーターや管理者とのコミュニケーションを担当します。
リリース 16.0 では、Exec のレベルは 49R2 (49.70.5) です。内部システム レベルは、21.92.42 (これは最初に広く使用された本番システムですが、それ以前のリリースもいくつかのサイトで本番で使用されていました) のような 3 部構成の番号を使用します。最初の番号部分はメジャー レベルであり、以前のすべての更新が新しいベース バージョンに統合された Exec の新しいバージョンを示します。これはまれなプロセスであり、数年の間隔で発生します。2 番目の番号部分は、メジャー レベルへの更新のバージョンを示し、多くの場合、週に数回発生します。機能コンテンツを固定してリリース準備を行うことが決定された場合、3 番目の部分が有効になり、修正やマイナーな機能更新が適用されるプレ リリース レベルのバージョンを示します。レベルをリリース用に準備すると同時に、エンジニアが将来のリリースに備えて変更を統合するため、「メインライン」への更新が継続されます。長年にわたり、公式のリリース レベルは 3 部構成の番号全体でした。後のリリースでは、44R1、44R2、49R2などと単純に命名されたが、内部的には依然として3桁の番号が使用されている。
Execは、本質的にはリアルタイムのマルチスレッドバッチ処理システムです。すべてがこのモデルに基づいて構築されています。Exec自体も、大部分がリアルタイムプログラムとして構成されています。WindowsのサービスやUnix系システムのデーモンとして実行される機能は、Exec内のアクティビティとして、または常にバックグラウンドで実行されるバッチプログラムとして実装されています。
タイムシェアリング（デマンドモードとも呼ばれる）とトランザクション処理は、バッチ処理の特殊なケースとして実装されています。その結果、タイムシェアリングユーザーやトランザクションプログラムが実行できる処理にはほとんど制限がありません。例えばテープマウントを呼び出すとパフォーマンスが低下する可能性があるという警告がトランザクションプログラムの作成者には多数表示されますが、実際にはテープマウントは許可されています。
作業の最小単位は「実行」です。これは工場の「生産実行」という用語に由来し、一般的には他のシステムにおけるジョブまたはセッションに相当します。実行は「実行ストリーム」によって定義されます。実行ストリームとは、実行される手順を表す一連の制御ステートメントです。これには、ファイル処理、プログラム実行、および制御の分岐が含まれる場合があります。バッチ実行は通常ファイルとして保存され、別の実行内またはオペレーターによる「開始」コマンドによってスケジュールされます。タイムシェアリング実行は、タイムシェアリング端末からログインし、@RUNコマンドを入力することによって開始されます。多くの場合、@RUNステートメントと2番目の制御ステートメント（多くの場合@ADDまたはプログラム実行）は、ユーザープロファイルに基づいて自動的に生成されます。セキュリティ認証は、認証されたユーザーIDと実行制御ステートメントで提供されるその他の情報に基づいて検証されます。
トランザクションは特殊なケースです。実際には制御文は存在しませんが、実行の内部データ構造が作成されます。これにより、Exec はトランザクション プログラムに同じセキュリティ、アカウンティング、デバッグなどのメカニズムを関連付けることができます。通常、セキュリティ プロファイルはトランザクション ユーザーが認証された時点でメモリにキャッシュされ、トランザクションがスケジュールされるとユーザーのセッション データからトランザクション実行状態にコピーされます。各トランザクション インスタンスは基本的に実行であるため、アカウンティング、ログ記録、およびエラー処理はすべて実行メカニズムによってカプセル化されます。
バッチジョブ（実行）は、実行ストリーム（ジョブ制御言語ステートメント）がファイルに格納されているのが特徴です。バッチジョブには、ファイルの最初のレコードとして必ず @RUN ステートメントが含まれます。このステートメントは、実行に名前（runid）を付け、優先順位を定義し、ジョブが使用すると想定される最大 SUP（標準処理単位）数を定義します。ジョブは、@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" できるため、間接的にプログラム可能な実行ストリームが提供されます。
SSGは元々、Univac社がオペレーティングシステム（OS）のアップデートを作成するために開発したものです。その後、一般ユーザーコミュニティによって、複雑なバッチ処理やリアルタイム処理の作成に採用されました。ソースは再帰的に他のソースを参照できるため、入力解析において幅広い柔軟性を実現できます。出力生成ルールもソースファイルに記述されており、同様に高度な動的入力機能を備えています。複数の入力ソースを解釈することで、出力ストリームの内容を動的に生成できます。複雑な再帰処理を適用することで、プログラムのソースコード、ジョブ実行シーケンス、仮想コンソールからの動的入力のシミュレーションなどを作成でき、Unixのgrepやyaccツールを彷彿とさせるスクリプト機能を提供できます。
オペレーターコマンドを使用すると、実行のバックログと実行優先度の両方を変更できます。すべてのオペレーターコマンドは、適切な権限を持つユーザーがAPI経由で利用できるため、自動化したり、リモート管理者が制御したりすることが可能です。
デッドラインはバッチ処理の特殊なケースです。デッドライン実行は、@RUN または @START 制御ステートメントでデッドライン時刻が指定されている点を除けば、他のバッチ実行とほぼ同じです。デッドライン時刻は、制御ステートメントの最大 SUP (時間見積もり) と組み合わせて使用されます。デッドライン ジョブは、デッドライン時刻に間に合わない可能性があると判断されるまで、通常のバッチ優先度で実行されます。デッドラインまでの時間と残りの SUP の差が大きいほど、優先度が高くなります。デッドラインはトランザクションを完全に停止させることはできず、リアルタイム処理にも影響を与えませんが、目的を達成するために必要な場合は、システム内の他のほとんどの処理を効果的に停止させることができます。
OS 2200 のタイムシェアリングセッションは、オンデマンド実行（「オンデマンド」の略）と呼ばれます。バッチ実行と同じ制御言語を使用しますが、「即時」制御ステートメントと呼ばれるいくつかの追加機能があります。即時制御ステートメントは「@@」番兵を使用し、プログラムが実行中であってもすぐに実行されることを示します。ファイルの作成や割り当てに使用できますが、最も重要なのは、実行中のプログラムをエラー終了させたり、シグナルを送信したりできる機能です。
トランザクションは実行として実行されますが、格納または送信された制御ステートメントは実行されません。代わりに、トランザクション セッションとして定義されたセッションからメッセージが受信されると、そのメッセージが配置されるトランザクション キューを決定するためにスキャンされます。これは通常、メッセージの最初の文字によって決定されますが、ユーザーが作成したスキャナを追加することもできます。[ 13 ]
最大25万のアクティブセッションを処理できる通信マネージャは、受信したトランザクションメッセージを受け取り、メッセージキューイングソフトウェアに渡します。メッセージキューイングアーキテクチャを使用することで、無制限の数のキューイングメッセージを処理できます。オペレーティングシステムのトランザクションインターフェースパッケージ（TIP）APIを呼び出し、トランザクションを適切なキューイングポイントにキューイングします。各キューイングポイントは、処理の優先度と同時実行レベル、および実行される関連トランザクションプログラムを識別します。
トランザクションプログラムのスケジューリングツリーを使用すると、クライアントはトランザクションプログラムのグループごとに相対的な使用状況を設定できます。同時実行制限により、特定の種類の作業がシステムを占有して他の作業が阻害されることを防ぎ、リソースの過剰割り当てを回避できます。ツリーには最大4094個のノードを作成できます。
各トランザクションプログラムに対して、優先度（0～63）と同時実行レベル（1～2047）を指定できます。
最も優先度の高いトランザクションがスケジューリング対象として選択されるが、そのノードおよび上位ノードに適用される同時実行ポリシーによって制限される場合を除きます。
リアルタイムは、別の種類の実行ではありません。むしろ、あらゆるアクティビティが要求できる優先度レベルのセットです。リアルタイムは、OS 2200の通信マネージャであるCPCommのような、長時間実行されるバッチプログラムで最も一般的に使用されますが、それに限定されるものではありません。
API を通じてアプリケーションが利用できるリアルタイム優先度レベルは 36 段階あります。ユーザーとアカウントは、リアルタイム優先度を使用する権限を持っている必要があります。アプリケーションが優先度レベルをどのように使用するかは、サイト側で制御する必要があります。リアルタイム優先度はすべての下位優先度を完全に優先するため、不適切な動作をするリアルタイムプログラムが 1 つ以上のプロセッサを占有してしまう可能性は十分にあります。
リアルタイム優先度は個々のアクティビティ（スレッド）に適用されるため、プログラム内でリアルタイムスレッドと非リアルタイムスレッドが同時に実行される可能性があります。
実行が開始されると、プロセッサへのアクセスによって進行速度が制御されます。Exec の中核は、すべてのプロセッサを管理するDispatcherです。 [ 14 ]
Exec は最大 4095 のディスパッチ優先度をサポートしていますが、ほとんどのサイトではそのごく一部のみを定義しています。最も高い 2 つの「優先度」は切り替えできません。これらは、自発的に制御を放棄するまで、開始したプロセッサ上で継続を許可する必要がある特定の種類の処理を認識するためのものです。割り込みロックアウトは、割り込みが発生したとき、またはいくつかの特殊なケースで、他の Exec コードがすべての割り込みを阻止する場合 (割り込みハンドラもアクセスする可能性のあるデータを変更するため) に発生します。
インターロックは、同じ物理プロセッサ上で実行する必要がある、または単に割り込みを受けてはならない割り込み後処理ルーチンで使用されます。ディスパッチャ、I/O完了、I/O開始などがその例です。これらの優先順位で使用されるすべてのロックはスピンロックです。これは、他のプロセッサ上でしかロックを設定できず、設計上、非常に短い命令シーケンスに対してのみロックを設定する必要があるためです。
高優先度の実行処理は、オペレーターコマンドハンドラーや、リアルタイムプログラムが制御している場合でも実行する必要があるその他の機能で使用されます。これらの処理はごく短時間しか必要としないことが想定されています。より多くの時間が必要な場合は、低優先度の実行処理によって処理されるように処理をキューに追加する必要があります。
リアルタイム処理は、プロセッサの割り当て量に制限がなく、優先度の高いリアルタイム処理または高実行処理によって中断されない限り、切り替えなしで実行されます。リアルタイム処理は、優先度の低い処理を実行している利用可能なプロセッサを制御できます。必要に応じてプロセッサ間で割り込みが送信され、即時の可用性が確保されます。リアルタイム処理は、ミサイルの発射、シミュレータの実行、その他即時応答を必要とする機能に顧客によって利用されています。
トランザクションの優先順位は、サイトによって定義される2つの方法で処理できます。1つは、優先順位のみが重要で、クォンタムサイズが実質的に無限であるという、一種の低優先度リアルタイム方式です。これは、航空券の予約など、非常に短時間で完了するトランザクションに適しています。プログラミングエラーによってループが発生した場合、Execは設定された非常に短い最大時間に達するとトランザクションを終了します。もう1つの方式では、Execはシステムリソースの使用を最適化するために、優先順位を範囲内で変更できます。この方式では、I/Oが制限されているプログラムには高い優先順位と短いタイムスライスを与え、計算を行うプログラムには徐々に低い優先順位と長いタイムスライスを与えます。Execは、プログラムが異なるタイミングで両方の動作をすることが多いため、動作に基づいてこれらの優先順位を動的に調整します。この方式は、データベースクエリや航空券の見積もりなど、長時間実行されるトランザクションに適しています。
バッチ処理とオンデマンド処理では、常に動的に調整された優先度が使用されます。I/O処理がボトルネックとなっているプログラムや、タイムシェアリングユーザーと通信中のプログラムは、優先度は高くなりますが、処理時間は短くなります。計算処理を重視するプログラムは、優先度が低くなり、処理時間は長くなります。
Exec には、ディスパッチを最適化するための追加のメカニズムが 2 つあります。1 つはアフィニティベースのディスパッチです。Exec は、可能な限り前回と同じプロセッサでアクティビティを実行し、残存キャッシュの内容を最大限に活用します。それが不可能な場合は、キャッシュとメモリへのアクセス時間の観点から「最も近い」プロセッサでアクティビティを実行しようとします。2 つ目は「公平性」ポリシー メカニズムです。サイトは、トランザクション、デマンド、バッチのそれぞれに割り当てるリソースの相対的な割合を定義できます。トランザクションとバッチ内には優先度グループがあり、そのグループの時間の何パーセントを優先度に割り当てるかをさらに指定できます。これにより、トランザクションがシステムを支配しすぎてバッチ処理が全く行われなくなることがなくなります。さまざまな優先度グループ内では、各グループで一定の進捗が保証されます (グループの割合がゼロでない限り)。これらの「公平性」アルゴリズムは、プロセッサが非常にビジーな場合にのみ有効になりますが、OS 2200 システムでは、すべてのプロセッサがほぼ 100% で稼働していることがよくあります。
OS 2200 は、システム パフォーマンス管理のためのいくつかのモデルをサポートしています。[ 15 ] 顧客は特定の固定パフォーマンス レベルを購入することができ、Exec はプロセッサの使用状況を監視し、パフォーマンスがそのレベルを超えないようにします。顧客は、ワークロードが増加した場合や緊急事態が発生した場合に、システムの最大容量まで、一時的または永続的に追加のパフォーマンスを購入することもできます。
最近、このシステムには従量制利用機能が追加されました。このモードでは、システムは常にフルパワーで利用可能です（ただし、管理上制限することも可能です）。使用量は1か月分累積され、報告された使用量がUnisysの請求部門に送信されます。契約条件によっては、顧客は契約で定められた基準値を超える使用量に対する請求書を受け取る場合と、契約使用量の合計が減少したことを示す明細書を受け取る場合があります。前者は、超過通話分に対して料金が発生する可能性のある携帯電話の請求書に似ています。後者は、プリペイド式電話カードを購入するようなものです。
OS 2200は、他のほとんどのオペレーティングシステムのような階層型ファイルシステムを持っていません。その代わりに、構造化された命名規則と、プログラムファイルと呼ばれるコンテナファイルの概念を採用しています。
OS 2200 のファイルは、ファイル内のワードオフセットまたはセクタ (28 ワード単位) オフセットのいずれかでアドレス指定できる単なるコンテナです。28 ワードは、初期の大容量記憶装置 (FASTRAND ドラム) に由来する歴史的な単位で、物理トラックごとに 64 個の単位を格納できました。とはいえ、これは幸運な歴史的偶然です。このような 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 と filename は、クライアントが希望する命名構造を作成するために使用される 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 はテキスト要素にのみ適用され、テキスト要素の各行には、挿入および削除されたサイクル番号がマークされます。要素には、タイプとサブタイプもあります。最も一般的に使用されるタイプは「text」と「object」です。デフォルトのタイプが適切でない場合は、オプションで適切なタイプを選択できます。テキスト要素には、通常プログラミング言語を表すサブタイプもあります (例: "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 ファイルを階層構造で表示できます。通常、ツリーの最上位レベルには修飾子が表示され、その後にファイル名、要素名、バージョンが続きます。また、OS 2200 サーバーには、完全な Windows ファイル名形式を使用してファイルを保存できます。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 セキュリティシステムは、不正アクセス、改ざん、漏洩からデータを保護するように設計されています。これには、国防総省オレンジブック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は柔軟な認証システムを提供します。複数の認証メカニズムが同時にサポートされます。クライアントまたはサードパーティが作成した認証ソフトウェアも使用できます。標準の認証機能には以下が含まれます。
最後の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の暗号化サービスを利用しています。CryptoLibには、 AESやTriple DESなどのアルゴリズムが実装されています。
OS 2200は暗号化テープドライブもサポートしており、アーカイブデータの暗号化を実現します。
SightLine Enterprise Data Manager (EDM) は、OS 2200 処理の中核要素として SightLine Software Suite と連携して動作します。J2EE アプリケーションとして構築された EDM は、データ コレクタ サービス (DCS) と Web ベースのユーザー インターフェイスという 2 つの主要コンポーネントで構成されています。これらのコンポーネントが連携して、データ収集とメンテナンス、エージェント構成、アラート処理、レポート作成、およびブラウザからアクセスできるユーザー インターフェイスの集中監視と管理を提供します。[ 25 ] [ 26 ]
OS 2200 システムは、単一システムよりも優れたパフォーマンスと可用性を実現するためにクラスタ化できます。最大 4 つのシステムをクラスタに組み合わせ、共有ディスクを介してデータベースとファイルを共有できます。ハードウェア デバイスである XPC-L は、データベースとファイル アクセス用の高速ロックマネージャを提供することで、システム間の調整を行います。[ 27 ]
クラスタ環境では、各システムが独自のローカルファイル、データベース、アプリケーショングループに加え、共有ファイルと1つ以上の共有アプリケーショングループを持つことができます。ローカルファイルとデータベースは、単一のシステムからのみアクセス可能です。共有ファイルとデータベースは、クラスタ内のすべてのシステムから同時にアクセスできるディスク上に配置する必要があります。
XPC-Lは、システム間の通信経路を提供し、動作の調整を可能にします。また、非常に高速なロックエンジンも備えています。XPC-Lへの接続は、極めて低遅延で動作する専用のI/Oプロセッサを介して行われます。XPC-Lのロックマネージャは、ファイルロックとデータベースロックの両方に必要なすべての機能を提供します。これには、デッドロック検出機能や、障害が発生したアプリケーションのロックを解放する機能が含まれます。
XPC-Lは、完全冗長構成を実現するために2台の物理サーバーで構成されています。XPC-Lファームウェアの新バージョンのロードなどのメンテナンスは、一方のサーバーが稼働を継続している間でも実行できます。一方のサーバーに物理的な損傷などの障害が発生しても、すべての情報は両方のサーバーに保持されるため、クラスタは停止しません。
OS 2200 の操作は、アクティブなオペレータと 1 つ以上のコンソールを中心に構築されています。各コンソールは端末ウィンドウであり、その一部はシステム内のアクティビティに関する概要情報が頻繁に更新される固定表示用に予約されています。[ 28 ]
コンソールの残りの部分は、イベントのスクロール表示に使用されます。オペレーターの応答が必要なメッセージが発行されると、0から9までの番号が割り当てられ、応答があるまで表示され続けます。テープマウントメッセージは他のメッセージとともにスクロール表示されますが、テープがマウントされるまで2分ごとに繰り返されます。
Operations Sentinel は、すべての OS 2200 操作に使用されます。[ 29 ] OS 2200 コンソールは、Operations Sentinel ディスプレイ内の単なるウィンドウです。ディスプレイ PC は必要な数だけ使用できます。リモート操作が一般的です。Operations Sentinel は、ClearPath、Windows、Linux、および UNIX システムをいくつでもサポートします。
製品には自動アクションメッセージデータベースが付属しています。[ 30 ] このデータベースにより、Operations Sentinel はメッセージを認識できます。スクリプトを作成することで、応答が必要なメッセージに自動的に応答したり、不要なメッセージを非表示にしたり、他の言語に翻訳したり、イベントを作成したりできます。一部のクライアントは完全なダークルーム運用を使用しています。せいぜい、遠隔地に Operations Sentinel ディスプレイを設置し、システムを監視して特定のイベントが発生したときにアラートを作成する程度です。
OS 2200 システムの管理は、システムの特定の領域に特化したさまざまなツールを使用して行われます。たとえば、トランザクション環境を管理するために使用されるツールがあり、新しいトランザクション プログラムをインストールしたり、それらに関する必要なすべての情報を指定したり、キューイング構造、優先順位、同時実行レベルなどを変更したりできます。[ 31 ]
その他のツールはセキュリティ担当者専用で、ユーザーの作成、許可された権限の変更、システムセキュリティ設定の変更などが可能です。[ 22 ]、[ 32 ]、[ 23 ]
ほとんどのツールにはグラフィカルインターフェースが備わっていますが、一部には備えていないものもあります。いずれのツールも、制御ストリームで全てのアクションを指定するバッチファイルインターフェースを提供しています。これにより、ローカルサイト（時間帯やその他のイベントに基づいて設定可能）またはリモートサイトから、あらゆる管理インターフェースをスクリプト化できます。各管理領域には固有の権限が必要です。
アプリケーション グループは、ユニバーサル データ システム (UDS) のインスタンス、[ 33 ]メッセージ キュー サブシステムのインスタンス、およびトランザクションのセットで構成される論理的な構成要素です。各アプリケーション グループには独自の監査証跡があります。OS 2200 は、システム内で最大 16 個のアプリケーション グループをサポートします。
アプリケーショングループという概念は、一般的に「アプリケーション」と呼ばれるものに対応します。つまり、接続された処理のより大きな単位を表すプログラムとデータの集合です。例えば、あるアプリケーショングループは航空会社のシステムを表すかもしれません。別のアプリケーショングループは企業の財務システムを表すかもしれません。あるいは、銀行の支店のように、アプリケーショングループは同じアプリケーションとデータモデルのインスタンスを表すかもしれません。重要なのは、各アプリケーショングループが独自の環境、セッション、リカバリなどを持っているということです。
アプリケーショングループは、個別に起動、停止、復旧できます。
アプリケーショングループには、独自の会計ルールやスケジューリングルールはありません。複数のアプリケーショングループ内のトランザクションは、同じ優先順位を共有したり、優先順位が交互に適用されたりする場合があります。これにより、サイトはシステム全体におけるトランザクションの相対的な優先順位を制御できます。
Unisysの歴史ニュースレターには、Unisysの歴史とコンピュータに関する記事が掲載されています。Unisysの歴史ニュースレター全巻に加え、他のサイトへのリンクも掲載されています。
ユニシスの歴史的資料のほとんどは、ミネソタ大学のチャールズ・バベッジ研究所とデラウェア州のハグリー博物館・図書館に所蔵されている。チャールズ・バベッジ研究所には、ERAの資料、ミネソタ州セントポールにあるレミントン・ランドの初期資料の一部、そしてバロウズの資料が保管されている。ハグリー博物館・図書館には、スペリーの資料の大部分が所蔵されている。
Arcane Sciencesに掲載されている、2020年代のOS 2200に関する非常に役立つ入門記事です。