ОС 2200

ОС 2200

Разработчик	Унисис
Семейство ОС	ОС 2200
Рабочее состояние	Текущий
Исходная модель	Закрытый исходный код . Большая часть исходного кода доступна клиентам по лицензии.
Первоначальный выпуск	1967 год ( 1967 ) как Exec 8
Последний выпуск	20.0 (EXEC 50R1) / 30 марта 2023 г ( 30.03.2023 )
Маркетинговая цель	Предприятие / Мэйнфреймы
Обновить метод	Exec и некоторые другие компоненты: пакетные изменения на основе номера строки. Большинство компонентов: Промежуточные поправки (ВП).
Менеджер пакетов	ПРИМУС (внутренний), КОМУС и СОЛАР (клиентский и внутренний)
Платформы	Серия UNIVAC 1100/2200; системы Unisys ClearPath Dorado; Программное обеспечение ClearPath серии 2.1 и 3.0 (через VMware)
ядра Тип	Монолитное ядро ​​(с уникальной аппаратной поддержкой)
По умолчанию пользовательский интерфейс	Интерфейс командной строки
Лицензия	Собственный . Срочная лицензия или лицензии с оплатой за использование (лимитированные)
Официальный сайт	Сайт ОС 2200

OS 2200 — это операционная система для Unisys семейства мэйнфреймов ClearPath Dorado. Ядро операционной системы OS 2200 является прямым потомком Exec 8 для UNIVAC 1108 и ранее было известно как OS 1100 . Документацию и другую информацию о текущих и прошлых системах Unisys можно найти на веб-сайте общественной поддержки Unisys.

См. системную архитектуру серии Unisys 2200 для описания архитектуры машины и ее связи с операционной системой OS 2200. Unisys прекратила производство оборудования ClearPath Dorado в начале 2010-х годов, и теперь операционная система работает в режиме эмуляции.

История

Раньше существовали системы 1100, начиная с 1101 в 1951 году, но 1108 был первым компьютером серии 1100, разработанным для эффективной поддержки мультипрограммирования и многопроцессорной обработки. Вместе с этим новым оборудованием появилась операционная система Exec 8 (Executive System для 1108).

Компьютер UNIVAC 1108 был анонсирован в 1964 году и поставлен в конце 1965 года. Первые компьютеры 1108 использовали Exec I и Exec II , которые были разработаны для UNIVAC 1107 . Однако UNIVAC планировал предложить симметричные многопроцессорные версии 1108 с числом процессоров до 4, а более ранние операционные системы (действительно базовые программы мониторинга) не были предназначены для этого, даже несмотря на то, что они поддерживали ограниченное многопрограммирование.

Генеалогия программного обеспечения

Когда UNIVAC 1110 был представлен в 1972 году, название операционной системы было изменено на OS 1100, чтобы отразить поддержку более широкого спектра систем. Название OS 1100 сохранялось до 1988 года, когда была представлена ​​серия Sperry 2200 в качестве продолжения серии 1100, когда ее название было изменено на OS 2200. С этого времени серия 2200 стала Unisys ClearPath IX Series , а затем Unisys. ClearPath Dorado Series, но операционная система сохранила название OS 2200.

Название компании и названия ее продуктов также со временем менялись. Компания Engineering Research Associates (ERA) Сент-Пола была приобретена Remington Rand Corporation . Remington Rand также приобрела компьютерную корпорацию Eckert-Mauchly в Филадельфии, которая тогда производила компьютер UNIVAC . Эти двое были объединены в подразделение UNIVAC компании Remington Rand под руководством Уильяма Норриса. Уильям Норрис был одним из основателей ERA, а затем покинул Remington Rand, чтобы основать Control Data Corporation . Подразделение UNIVAC корпорации Remington Rand стало подразделением UNIVAC корпорации Sperry Rand после слияния Remington Rand с корпорацией Sperry . В 1970-х годах Сперри Рэнд начал программу фирменного стиля, в результате которой ее название было изменено на Sperry Corporation, а названия всех подразделений стали начинаться с Sperry, поэтому подразделение компьютерных систем стало Sperry UNIVAC. Позже названия дивизий были исключены, и все стало просто Сперри.

Ядро операционной системы до сих пор большинство сотрудников Unisys и клиентов называют «Exec». Однако, когда Unisys начала выпускать наборы продуктов, протестированных вместе, как базовые версии системы, позже получившие название «ClearPath OS 2200 Release n », термин OS 2200 изменился и стал относиться ко всему набору продуктов в выпуске системы и другим, таким как BIS . выпущен асинхронно для аппаратных платформ Dorado.

В 1986 году корпорации Burroughs и Sperry объединились и образовали Unisys (что, по словам некоторых давних клиентов серии 2200, означает «UNIVAC все еще ваш поставщик»). Основные линейки продуктов для мэйнфреймов обеих компаний продолжают развиваться, включая операционную систему MCP от Burroughs и OS 2200 от Sperry.

виртуальную версию OS2200 для Microsoft Windows для образовательных и развлекательных целей. В 2016 году Unisys предоставила бесплатную

Исполнительный 8

EXEC 8 (иногда называемая EXEC VIII) — операционная система UNIVAC, разработанная для UNIVAC 1108 в 1964 году. Она сочетала в себе лучшие функции более ранних операционных систем EXEC I и EXEC II , которые использовались на UNIVAC 1107 . EXEC 8 была одной из первых коммерчески успешных многопроцессорных операционных систем. Он поддерживал одновременные смешанные рабочие нагрузки, включая пакетную обработку , разделение времени и работу в режиме реального времени . Его единственная файловая система имела плоскую структуру именования для множества барабанов и шпинделей. Он также поддерживал хорошо принятую систему обработки транзакций .

Все предыдущие системы работали в реальном режиме без аппаратной поддержки защиты и разделения программ и операционной системы. Хотя в предыдущих системах существовала поддержка мультипрограммирования , она ограничивалась одновременным выполнением одного пользовательского задания с несколькими вспомогательными функциями, которые, как известно, хорошо себя ведут, такими как устройство чтения карт, принтер и спулеры перфокарт .

Операционная система Exec 8 с самого начала разрабатывалась как многопрограммная и многопроцессорная операционная система, поскольку 1108 была рассчитана на установку до четырех процессоров. Память и запоминающее устройство были основными ограничениями системы. Хотя серия 1100 задумывалась как ориентированная на более широкий рынок, основным требованием была экстремальная обработка данных в реальном времени.

Спецификации Exec 8 были составлены к декабрю 1964 года как предварительное справочное руководство для программистов (руководство пользователя), а работа началась в мае 1965 года.

Exec 8 начиналась как операционная система реального времени и вначале использовалась в основном в общих научных и инженерных работах, но также использовалась для коммутации сообщений, управления процессами, моделирования и управления стрельбой ракет. Он был разработан для работы в системах, которые часто имели только 128 КБ слов (576 КБ — меньше максимального размера памяти для IBM PC XT ), и был ориентирован на обработку в реальном времени и пакетную обработку. Хотя самые ранние версии действительно работали на мощности 128 кВт, увеличение функциональности в более поздних версиях сделало это несостоятельным, поскольку не оставляло достаточно места для программ полезного размера. Максимальная емкость памяти 1108 составляла 256 КВт (1152 КБ), поэтому эффективное использование памяти было наиболее важным ограничением, поскольку основная память была самой дорогой частью системы.

Накопитель большой емкости состоял из вращающихся барабанов длиной 6 футов и мощностью от 256 кВт (в FH-432) до 2 МВт (в FH-1782). Самой большой емкостью был барабан FASTRAND , емкость которого составляла 22 МВт (99 МБ). Фрагментация файлов решалась с помощью процесса, называемого «сохранением файла», который обычно выполнялся один раз в день, ночью. Это включало запись всех файлов на ленту, повторную инициализацию файловой системы барабана и последующее чтение файлов обратно.

Из-за серьезных ограничений памяти и использования в режиме реального времени требовалось хранить только одну копию кода, загружаемую в ядро. Поскольку 1108 был разработан для многозадачности, система была полностью «реентерабельной» ( потокобезопасной ). Каждый реентерабельный модуль обращался к данным программы через один «базовый адрес» памяти, который был разным для каждого экземпляра данных запуска. Переключение контекстов выполнения можно выполнить в одной инструкции, просто установив другой базовый адрес в одном регистре. В системе использовалась детальная блокировка для защиты общих структур данных. Исполнительные программы, компиляторы, утилиты и даже сложные пользовательские приложения, которые могут одновременно работать в нескольких копиях, были написаны так, чтобы их код можно было использовать совместно. Для этого требовалась загрузка в память только одной копии, что экономило и пространство, и время, необходимое для загрузки кода.

Другая причина разделения кода и данных на разные объекты нагрузки заключалась в том, что память была реализована в виде двух независимых банков (отдельных физических шкафов), называемых IBANK и DBANK (инструкции и данные). У каждого был свой собственный путь доступа, поэтому ЦП мог читать оба банка одновременно. Загрузив исполняемый код в один банк памяти, а данные в другой, время выполнения многих программ можно сократить почти вдвое.

Реентерабельный код должен был быть потокобезопасным (только выполнение); самомодифицирующийся код не допускался. Для других программ изменение исполняемого кода во время выполнения все еще было приемлемым методом программирования во времена компьютеров серии 1100, но пользователям рекомендовалось не делать этого из-за снижения производительности. Преимущества безопасности рекламировались, но не оценивались высоко, потому что взлом большинства приложений серии 1100 никому не принес бы никакой пользы, и потому что тогда немногие хакеры были злонамеренными.

Exec 8 в первую очередь представлял собой систему пакетной обработки , которая давала приложениям (называемым «задачами») очень точный контроль над приоритетом планирования ЦП для своих потоков (называемых «действиями»). Переключение процессора было упреждающим: потоки с более высоким приоритетом получали контроль над процессором, в настоящее время выполняющим поток с самым низким приоритетом любой программы. За исключением систем реального времени, даже задачам с самым низким приоритетом требуется некоторое время процессора. Это была мультипрограммная и многопроцессорная операционная система с полностью симметричным управлением процессором. Инструкция тестирования и установки, встроенная в аппаратное обеспечение, обеспечивала очень эффективную и детальную блокировку как внутри ОС, так и в многопоточных приложениях.

В Exec 8 работа организована в задания, называемые «прогонами», которые планируются на основе их приоритета и потребности в блокируемых ресурсах, таких как ленточные накопители Uniservo или барабанные файлы Fastand. Синтаксис языка управления использует символ «@» (который Univac назвал «основным пространством») в качестве символа распознавания управляющего оператора. Сразу за ним следовало имя команды или программы, затем запятая и любые переключатели опций. После пробела оставшаяся часть оператора различалась для отдельных команд. Команда для компиляции программы на FORTRAN будет выглядеть так: «@FOR[,options] исходный файл, объектный файл». Входные данные для приложения могут быть прочитаны из файла (обычно изображения карточек) или сразу следовать за командой @ в потоке выполнения. Все строки до сторожевой команды «@END» считались входными данными, поэтому забывание вставить их приводило к тому, что компилятор интерпретировал последующие команды как данные программы. По этой причине было предпочтительнее обрабатывать данные в файлах, а не вводить их в поток выполнения.

В 1968 году началась работа по добавлению возможности разделения времени в Exec 8. В 1969 году он был реализован с 23-м уровнем руководителя. Разделение времени (так называемый режим по требованию ) имело те же возможности, что и пакетные процессы и процессы реального времени. Все, что можно было сделать в пакетном режиме, можно было сделать с терминала ASCII. В режиме запроса поток заданий ввода-вывода был прикреплен к обработчику терминала, а не к файлам образа карты (вход) и буферизации (выход). Для обоих использовался один и тот же язык управления запуском. Несколько лет спустя были добавлены более конкретные команды разделения времени, и некоторые операторы управления могли выполняться асинхронно для немедленной обработки, даже когда ни исполнительная система, ни работающая программа не ожидали данных. Те команды, которые можно было вводить только с терминала, начинались с «@@». Поскольку их можно было выполнять без остановки другой выполняемой работы с того же терминала, их называли прозрачными командами. Сначала это были просто операторы завершения текущей программы или перенаправления вывода терминала в файл, но со временем почти всем управляющим операторам стало разрешено быть «немедленными».

Как пакетный запуск, так и запуск по запросу завершаются оператором @FIN, и если пользователь запроса завершает свой сеанс, пока его запуск активен, Exec автоматически завершает запуск, не требуя @FIN.

Программное обеспечение для связи

Возможность обработки транзакций была разработана в конце 1960-х годов как совместный проект с United Airlines, а затем усовершенствована в другом совместном проекте с Air Canada. Эта возможность была полностью интегрирована в операционную систему в 1972 году и стала основой для большей части будущего роста серии 1100. Первые пользователи управляли линиями связи непосредственно из своих программ реального времени. Часть разработки обработки транзакций включала систему коммуникационных сообщений, которая управляла линиями связи и представляла сообщения Exec 8 для планирования как транзакций. Это переместило все управление физическими линиями связи и протоколы низкого уровня из приложений в приложение CMS 1100.

Сама CMS 1100 работала как многопоточная программа реального времени с привилегией получать контроль над линиями связи и отправлять транзакционные сообщения для планирования. Это привело к появлению в Exec 8 идеи о том, что приложения любого характера необходимо тщательно контролировать, чтобы гарантировать, что они не могут вызвать проблемы с целостностью. Безопасность, безусловно, вызывала беспокойство, но на заре надежность и целостность системы были гораздо более серьезными проблемами. Система по-прежнему в основном выполняла пакетную обработку и обработку транзакций, и вероятность того, что кто-либо сможет установить в систему несанкционированный код, была мала. Позже в CMS 1100 была добавлена ​​возможность быть интерфейсом для терминалов спроса, а также для транзакционных терминалов, так что терминалы можно было использовать для обоих, а ранние драйверы терминалов можно было удалить из Exec. Позже CMS 1100 был заменен комбинацией CPComm (коммуникационной платформы ClearPath Enterprise Servers) и SILAS (системный интерфейс для устаревших прикладных систем). Для моделей серверов Dorado на базе Intel связь нижнего уровня была перенесена во встроенное ПО, а верхние уровни обрабатывались SILAS и CPCommOS (коммуникационная платформа корпоративных серверов ClearPath для открытых систем).

Исполнительный директор

Exec содержит весь код в системе, который разрешено запускать на самых высоких уровнях привилегий. Не существует механизмов повышения другого кода до этих уровней привилегий.

Руководитель отвечает за управление системным оборудованием, планирование и управление работой, а также общение с операторами и администраторами.

В версии 16.0 руководитель имеет уровень 49R2 (49.70.5). На внутренних уровнях системы используется число, состоящее из трех частей, например 21.92.42 (это была первая широко используемая производственная система, хотя более ранние версии использовались в производстве на ряде сайтов). Первая цифровая часть является основным уровнем и указывает на новую версию Exec со всеми предыдущими обновлениями, интегрированными в новую базовую версию. Это нечастый процесс и происходит с интервалом в несколько лет. Вторая цифровая часть указывает версии обновлений основного уровня и часто происходит несколько раз в неделю. Когда принимается решение заморозить содержимое функций и подготовиться к выпуску, в игру вступает третья часть, в которой указываются версии предварительного уровня по мере применения исправлений и незначительных обновлений функций. Одновременно с подготовкой уровня к выпуску продолжаются обновления «основной ветки», поскольку инженеры интегрируют изменения в рамках подготовки к будущему выпуску. В течение многих лет официальным уровнем выпуска был полный номер из трех частей. Более поздние выпуски назывались просто 44R1, 44R2, 49R2 и т. д., хотя трехчастное число до сих пор используется внутри компании.

Выполнение работ

По сути, Exec представляет собой многопоточную систему пакетной обработки в реальном времени. Все построено вокруг этой модели. Сам Exec в значительной степени структурирован как программа реального времени. Функции, которые выполняются как службы в Windows или демоны в Linux и UNIX, реализуются либо как действия внутри Exec, либо как пакетные программы, которые всегда выполняются в фоновом режиме.

Разделение времени (известное как режим спроса ) и обработка транзакций реализованы как особые случаи пакетной обработки. Одним из результатов является то, что существует мало ограничений на то, что может делать пользователь или транзакционная программа с разделением времени. Существует множество предупреждений для авторов транзакционных программ о том, что они не будут довольны производительностью, если, например, потребуют монтирования на ленту, но это разрешено.

Самая большая единица работы – «Бег». Это взято из заводской терминологии «производственного цикла» и обычно соответствует заданию или сеансу в других системах. Запуск определяется его «потоком выполнения». Поток выполнения — это последовательность управляющих операторов, которые представляют шаги, которые необходимо предпринять. Они могут включать обработку файлов, выполнение программ и ветви управления. Пакетный прогон обычно хранится в виде файла и планируется командой «Пуск» из другого прогона или оператором. Запуск с разделением времени инициируется путем входа в систему с терминала разделения времени и ввода команды @RUN. Часто оператор @RUN и второй оператор управления (часто @ADD или выполнение программы) генерируются автоматически на основе профиля пользователя. Авторизации безопасности проверяются на основе аутентифицированного идентификатора пользователя и другой информации, предоставленной в операторе управления Run.

Транзакции представляют собой особый случай. На самом деле никаких управляющих операторов нет, но создаются внутренние структуры данных выполнения. Это позволяет руководителю связать одни и те же механизмы безопасности, учета, отладки и т. д. с программами транзакций. Обычно профиль безопасности кэшируется в памяти в момент аутентификации пользователя транзакции и копируется из данных сеанса пользователя в состояние выполнения транзакции, когда транзакция запланирована. Поскольку каждый экземпляр транзакции по сути представляет собой запуск, учет, ведение журнала и обработка ошибок инкапсулируются механизмом выполнения.

Партия

Пакетные задания (выполнения) характеризуются наличием потока выполнения (операторов языка управления заданиями), хранящегося в файле. Пакетное задание всегда содержит инструкцию @RUN в качестве первой записи в файле. Этот оператор дает запуску имя (runid), определяет приоритеты и максимальное количество SUPS (стандартных единиц обработки), которые предполагается использовать в задании. Задание запускается из другого задания с помощью управляющего оператора @START или оператором с помощью клавиши ST. Систему можно настроить на автоматическую выдачу операторов @START для любого количества заданий при загрузке. Эти задания служат для выполнения инициализации, восстановления и фоновых функций.

Все поля инструкции @RUN могут быть переопределены соответствующими полями инструкции @START. За исключением случаев, когда @START выполняется привилегированным пользователем, идентификатор пользователя и другое состояние безопасности всегда берутся из выполнения @START.

В операторе @RUN есть два поля приоритета. Один используется для указания приоритета невыполненной работы. Существует 26 уровней приоритета невыполненной работы (A – Z). В Exec настроено максимальное количество открытых пакетных запусков. При достижении этого уровня задания выбираются из очередей невыполненных работ в порядке приоритета. В рамках приоритетного выбора обычно используется FIFO. Однако Exec предварительно просматривает операторы управления заданиями до первого выполнения программы в поисках имен файлов и номеров барабанов. Если задание немедленно останавливается из-за отсутствия некоторых необходимых ему ресурсов, его можно обойти и запустить другие задания с тем же уровнем приоритета.

Второй уровень приоритета определяет группу ресурсов исполнительного процессора. В целом, более высокие приоритеты группы выполнения обычно требуют больше процессорного времени.

Хотя язык управления заданиями OS 2200 не поддерживает полную программируемость, он позволяет динамически добавлять последовательности языка управления с помощью управляющего оператора @ADD. Добавляемый файл мог быть создан тем же заданием, непосредственно предшествующим его добавлению. @ADD и большинство других операторов управления также могут быть отправлены из работающей программы через API. Дополнительные возможности программирования доступны косвенно за счет использования генератора символьных потоков (SSG). SSG — это язык программирования для управления и создания текстовых файлов на основе входных параметров и системной информации. Он широко используется для обработки управления конфигурацией ( make ) и других функций, где текстовые изображения необходимо создавать программным способом. Полученный результат может быть обработан «@ADD» в одном и том же запуске, что обеспечивает косвенно программируемый поток выполнения.

Команды оператора доступны для изменения как журнала невыполненной работы, так и приоритетов выполнения запусков. Поскольку все команды оператора доступны через API для пользователей с соответствующими привилегиями, это может быть автоматизировано или контролироваться удаленным администратором.

Крайний срок — это частный случай пакета. Запуск по крайнему сроку выглядит так же, как и любой другой пакетный запуск, за исключением того, что время крайнего срока указывается в управляющем операторе @RUN или @START. Крайний срок используется вместе с максимальным SUPS (оценкой времени) в управляющем операторе. Задание с крайним сроком выполняется с обычными пакетными приоритетами до тех пор, пока не окажется, что оно может пропустить установленный срок. Тогда чем больше несоответствие между временем до крайнего срока и оставшимися SUPS, тем выше приоритет. Хотя крайний срок не может полностью отключить транзакции и не влияет на режим реального времени, он может эффективно отключить большинство других процессов в системе, если это необходимо для достижения цели.

Требовать

Сеансы с разделением времени в OS 2200 называются запусками по требованию (от «по требованию»). Они используют тот же язык управления, что и пакетные прогоны, с некоторыми дополнениями, известными как операторы «немедленного» управления. Операторы немедленного управления используют сигнальный знак «@@», который указывает, что они должны выполняться немедленно, даже если программа запущена. Хотя их можно использовать для создания или назначения файлов, наиболее важные из них позволяют пользователю по ошибке завершить работающую программу или даже отправить ей сигнал.

Транзакции

Схема обработки транзакций

Транзакции выполняются как прогоны, но без каких-либо сохраненных или отправленных управляющих операторов. Вместо этого, когда сообщение получено из сеанса, определенного как сеанс транзакции, оно сканируется для определения очереди транзакций, в которую оно должно быть помещено. Обычно это определяется по первым символам сообщения, но могут быть добавлены и написанные пользователем сканеры.

Менеджер связи, способный обрабатывать до 250 000 активных сеансов, принимает входящие сообщения о транзакциях и передает их в программное обеспечение очереди сообщений. Он может обрабатывать неограниченное количество сообщений в очереди, используя архитектуру очереди сообщений. Выполняется вызов API-интерфейсов пакета интерфейса транзакций (TIP) в операционной системе, чтобы поставить транзакцию в очередь в соответствующей точке очереди. Каждая точка очереди определяет приоритет и уровень параллелизма работы, а также соответствующую программу транзакции, которая должна быть выполнена.

Диаграмма планирования транзакций

Дерево планирования программ транзакций позволяет клиенту устанавливать относительное использование групп программ транзакций. Ограничения параллелизма позволяют избежать доминирования одного типа работы в системе и исключения другой работы, а также избежать чрезмерного использования ресурсов. В дереве можно создать до 4094 узлов.

• Максимальный параллелизм, указанный для каждого узла в дереве
• Параллелизм более высокого узла ограничивает общий параллелизм зависимых узлов.
• Параллелизм самого высокого узла ограничивает параллелизм системы.

Приоритет (от 0 до 63) и уровень параллелизма (от 1 до 2047) можно указать для каждой программы транзакции.

Для планирования выбирается транзакция с наивысшим приоритетом, за исключением случаев, когда это ограничено политиками параллелизма, действующими для ее узла и узлов более высокого уровня.

Реальное время

Реальное время — это не другой тип бега. Скорее, это набор уровней приоритета, которые может запросить любая деятельность. Режим реального времени чаще всего используется длительно работающими пакетными программами, такими как менеджер коммуникаций OS 2200 CPComm, но не ограничивается этим.

API предоставляет 36 уровней приоритета реального времени для использования приложениями. Пользователь и учетная запись должны иметь право использовать приоритеты реального времени. Сайт должен контролировать, как его приложения используют уровни приоритета. Приоритеты реального времени полностью доминируют над всеми более низкими приоритетами, поэтому некорректно работающая программа реального времени вполне может связать один или несколько процессоров.

Приоритет реального времени применяется к отдельному действию (потоку), поэтому в программе могут одновременно выполняться потоки как реального, так и нереального времени.

Отправка процессора

После запуска прогона получение доступа к процессору контролирует скорость его выполнения. Сердцем Exec является Диспетчер , который управляет всеми процессорами.

Диаграмма приоритетов диспетчеризации

Exec поддерживает до 4095 приоритетов диспетчеризации, хотя большинство сайтов определяют лишь небольшую их часть. Два высших «приоритета» не переключаются. Они представляют собой признание определенных типов обработки, которым необходимо разрешить продолжаться на процессоре, на котором они были начаты, до тех пор, пока они добровольно не откажутся от управления. Блокировка прерывания происходит при поступлении прерывания или в некоторых особых случаях, когда другой код Exec предотвращает все прерывания (чтобы изменить некоторые данные, к которым также может получить доступ обработчик прерывания).

Блокировка используется процедурами постобработки прерываний, которые либо должны выполняться на том же физическом процессоре, либо просто не должны прерываться. Диспетчер, завершение ввода-вывода и инициация ввода-вывода — вот некоторые примеры. Все блокировки, используемые обоими этими приоритетами, являются спин-блокировками, поскольку единственный способ их установки кем-то другим — это на другом процессоре, а конструкция требует, чтобы они устанавливались только для очень коротких последовательностей команд.

Высокий приоритет Exec используется обработчиком команд оператора и некоторыми другими функциями, которые, возможно, придется запускать, даже если управление имеет программа реального времени. Ожидается, что они будут использовать лишь очень короткое количество времени. Если им нужно больше времени, им следует поставить работу в очередь для обработки действием Low Exec.

Действия в реальном времени имеют неограниченный такт процессора и выполняются без переключения, если только они не прерываются действием в реальном времени с более высоким приоритетом или действием High Exec. Действиям в реальном времени предоставляется контроль над любым доступным процессором, на котором выполняется что-то с более низким приоритетом. Прерывания передаются между процессорами, когда это необходимо для обеспечения немедленной доступности. Клиенты используют режим реального времени для запуска ракет, запуска симуляторов и других функций, требующих немедленного реагирования.

Приоритеты транзакций могут обрабатываться двумя способами, определяемыми сайтом. Они могут быть чем-то вроде реального времени с более низким приоритетом, поскольку имеет значение только приоритет, а размер квантов по существу бесконечен. Это подходит для очень краткосрочных транзакций, таких как бронирование авиабилетов; если какой-либо цикл зацикливается из-за ошибки программирования, Exec прекратит его, когда он достигнет очень малого настроенного максимального времени. Другая форма позволяет руководителю изменять приоритет в пределах диапазона для оптимизации использования системных ресурсов. Этот подход дает более высокий приоритет и более короткие временные интервалы программам с ограниченным вводом-выводом и постепенно более низкие приоритеты, но более длинные временные интервалы для программ, которые выполняют вычисления. Exec динамически корректирует эти приоритеты в зависимости от поведения, поскольку программы часто в разное время ведут себя в обоих направлениях. Этот подход подходит для длительных транзакций, таких как запросы к базе данных или котировки тарифов авиакомпаний.

Партия и спрос всегда используют динамически регулируемые приоритеты. Программы, которые имеют ограниченный ввод-вывод или взаимодействуют с пользователем с разделением времени, получают более высокие приоритеты, но короткие временные интервалы. Программы, ориентированные на вычисления, имеют более низкие приоритеты и более длительные временные интервалы.

У Exec есть два дополнительных механизма для оптимизации диспетчеризации. Один из них — диспетчеризация на основе сходства. Когда это возможно, Exec будет запускать действие на том же процессоре, что и в прошлый раз, чтобы получить максимальную выгоду от остаточного содержимого кэша. Если это невозможно, он пытается сохранить активность на «ближайшем» процессоре с точки зрения времени доступа к кэшу и памяти. Второй механизм – политика «справедливости». Сайт может определить относительный процент ресурсов, которые будут выделены для каждой транзакции, запроса и пакета. Внутри транзакций и пакетов существуют группы приоритетов, которые могут дополнительно указывать, какой процент времени их группы должен быть выделен для приоритета. Это гарантирует, что транзакции не смогут настолько доминировать в системе, что не будет выполняться пакетная работа. В рамках различных групп приоритетов это гарантирует, что определенный прогресс может быть гарантирован для каждой группы (если процент группы не равен нулю). Эти алгоритмы «справедливости» вступают в действие только тогда, когда процессоры очень загружены, но системы OS 2200 часто работают с загрузкой всех процессоров почти на 100%.

Измерение

OS 2200 поддерживает несколько моделей управления производительностью системы. Клиенты могут приобрести определенный фиксированный уровень производительности, и руководитель будет контролировать использование процессора, чтобы гарантировать, что производительность не превышает этот уровень. Клиенты также могут приобрести дополнительную производительность временно или постоянно до полной мощности системы, если их рабочая нагрузка увеличивается или этого требует чрезвычайная ситуация.

Совсем недавно в систему добавлена ​​возможность дозированного использования. В этом режиме клиенту всегда доступна вся мощность системы (хотя он может административно ограничить это). Использование накапливается в течение месяца, а затем отчет об использовании передается в систему выставления счетов Unisys. В зависимости от конкретных условий контракта клиент может получить счет за превышение установленного в контракте базового уровня за месяц или просто заявление о том, что общий объем использования по контракту был уменьшен. Первая форма похожа на счет за мобильный телефон с возможностью взимания платы за лишние минуты. Последнее похоже на покупку предоплаченной телефонной карты.

Файловая система

OS 2200 не имеет иерархической файловой системы , как большинство других операционных систем. Скорее, он имеет структурированное соглашение об именах и понятие файлов-контейнеров, называемых программными файлами.

Файлы в OS 2200 представляют собой просто контейнеры, к которым можно обращаться либо по смещению слова в файле, либо по смещению сектора (единица из 28 слов) в файле. 28 слов — это историческая единица из раннего запоминающего устройства (барабан FASTRAND), которое могло содержать 64 таких единицы на физическую дорожку. Тем не менее, это удачная историческая случайность. Четыре таких блока по 28 слов или 112 слов занимают 504 байта. Поскольку все современные устройства хранения данных используют физические записи размером 512 байт, почти все клиенты OS 2200 приняли размер, кратный 112 словам, в качестве размера физической записи и размера страницы базы данных. Процессоры ввода-вывода автоматически подстраиваются под сопоставление 504<->512 байт, добавляя 8 байтов нулей при записи и удаляя их при чтении каждой физической записи. OS 2200 обрабатывает приложения, которые используют размеры, отличные от кратных 112 словам, путем неделимого чтения содержащихся физических записей и обратной записи неизмененных и измененных частей с помощью цепочки данных. Специальные функции блокировки гарантируют неделимость даже при наличии ошибок устройства и в нескольких системах в кластере.

Форматы файлов и другие внутренние структуры данных описаны в Справочном руководстве по программированию структур данных .

Имена файлов

Начиная с Exec-8, имена файлов принимали форму: Квалификатор*Имя файла(f-цикл) (например, «ПЕРСОНАЛ*СОТРУДНИКИ(+1)»). Квалификатор и имя файла — это просто строки из двенадцати символов, используемые для создания любой структуры именования, которую желает клиент. F-цикл — это число от 0 до 999, которое позволяет создавать несколько поколений файла. На них можно ссылаться с помощью относительных чисел: (+1) следующий или новый цикл, (-1) предыдущий цикл, (+0) текущий цикл. Если оставить цикл выключенным, по умолчанию будет использоваться текущий цикл. Этот подход используется при пакетном производстве, при котором создаются новые поколения файлов. Числа переходят после 999. Одновременно могут существовать только 32 последовательных числа относительных циклов. Создание (+1) удаляет (-31).

Любой файл может быть использован в качестве программного файла. Файл программы содержит элементы, которые обычно действуют как файлы. Именование элемента — Qualifier*Filename(f-cycle).Element/version(e-cycle) (например, «PERSONNEL*PROGRAMS.TAXCALC/2008»). Элемент и версия — это двенадцатизначные имена, которые можно использовать по желанию пользователя. E-цикл похож на f-цикл в том, что он представляет номер поколения, но без ограничения до 32 одновременных циклов и ограничения в 256 тысяч циклов. Однако электронный цикл применяется только к текстовым элементам, и каждая строка в текстовом элементе помечается номером цикла, в котором она была вставлена ​​и удалена. Элементы также имеют тип и подтип. Наиболее часто используемые типы — «текст» и «объект». Если тип по умолчанию не подходит, параметры выбирают соответствующий тип. Текстовые элементы также имеют подтипы, которые обычно представляют язык программирования (например, «ASM», «C», «COB», «FOR»). Имя элемента объектного файла по умолчанию совпадает с именем текстового файла, из которого он был создан.

Элемент объекта может быть выполнен, если он является основной программой или связан с другими элементами объекта, включая основную программу. Связь может быть статической или динамической. Основная программа может выполняться без предварительного связывания при условии, что все необходимые подпрограммы находятся в одном программном файле, являются системными библиотеками или известны иным образом. Правила могут быть включены в файл программы, чтобы направлять динамический компоновщик на поиск невыполненных ссылок. Компоновщик также может использоваться для статического связывания нескольких объектных модулей вместе для формирования нового объектного модуля, содержащего все инструкции, данные и другую информацию в исходных объектных модулях.

Элементы Omnibus могут использоваться приложениями в качестве данных или могут служить для хранения структурированной информации для приложений и системных утилит. Для составного элемента не существует предполагаемой структуры.

Для совместимости с более ранними (базовыми) моделями программирования существуют перемещаемые и абсолютные типы элементов. Перемещаемые элементы — это выходные данные компиляторов базового режима. Они могут быть объединены статическим компоновщиком базового режима (@MAP – сборщик) для формирования «абсолютного» элемента, который является исполняемым.

Управление файлами

OS 2200 реализует полностью виртуальную файловую систему. Файлы могут быть размещены где угодно на любом устройстве хранения данных. Накопитель большой емкости рассматривается как большой пул пространства, аналогичный способу управления виртуальной памятью. Хотя по возможности выделяется непрерывное пространство, запоминающее устройство рассматривается как набор страниц размером 8 КБ, и файл может быть размещен в таком количестве областей одного и того же или разных устройств, сколько необходимо. Динамическое расширение файлов пытается выделить пространство рядом с предыдущим выделением, но находит место везде, где оно доступно. Фактически, для использования файлов даже не обязательно присутствовать на запоминающем устройстве. Exec и система резервного копирования файлов полностью интегрированы. При резервном копировании файлов номера катушек с лентой записываются в каталог файлов. Если на запоминающем устройстве не хватает места, некоторые файлы просто помечаются как «выгруженные», если у них есть текущая резервная копия и их пространство доступно для использования. Если таким образом не удается найти достаточно места, запускается резервное копирование.

Любая ссылка на выгруженный файл будет помещена в очередь, пока файл копируется обратно в запоминающее устройство. Вся система автоматизирована и в целом прозрачна для пользователей.

Методы доступа

В целом, Exec не предоставляет методов доступа . Файлы — это просто контейнеры. Методы доступа предоставляются системами времени выполнения языка и менеджером базы данных. Единственным исключением является метод доступа с фиксированным блоком, предназначенный для обработки транзакций большого объема. Он требует гораздо меньше накладных расходов, чем менеджер баз данных, но участвует во всех механизмах блокировки, кластеризации и восстановления.

Съемные пакеты

Если клиентам нужен более явный контроль над расположением файлов, они могут использовать концепцию «съемного пакета». Когда-то они действительно представляли собой физически съемные дисковые пакеты, и операционная система автоматически генерировала операторам запросы на монтирование пакетов по мере необходимости.

Сегодня они по-прежнему используются для размещения файлов (обычно файлов базы данных или файлов транзакций) на одном или нескольких томах диска. Файлы по-прежнему могут занимать несколько томов диска, и теперь список имен томов предоставляется при создании файла. Резервное копирование файлов, находящихся в таких группах томов, по-прежнему выполняется, но не подлежит автоматическому управлению виртуальным пространством.

КИФС

OS 2200 также обеспечивает полную реализацию общей файловой системы Интернета ( CIFS ). CIFS реализует протокол SMB, используемый серверами Microsoft и программным обеспечением Samba UNIX/Linux . CIFS для ClearPath OS 2200 является одновременно файловым сервером и файловым клиентом для других CIFS-совместимых систем. Сюда входят настольные ПК под управлением Windows. CIFS поддерживает подписание сообщений SMB.

Для обеспечения безопасности OS 2200 CIFS для ClearPath OS 2200 обеспечивает два уровня защиты. Во-первых, файлы OS 2200 не видны в сети до тех пор, пока они не будут объявлены как «общие ресурсы» с помощью команды CIFS. Существует особая привилегия, позволяющая контролировать, кто может объявлять акции. Второй уровень контроля заключается в том, что весь доступ по-прежнему защищен системой безопасности OS 2200. Клиенты, обращающиеся к OS 2200 через CIFS, должны будут либо автоматически идентифицироваться через NTLM или Kerberos , либо им будет предложен запрос на ввод идентификатора пользователя и пароля OS 2200.

CIFS позволяет представлять файлы OS 2200 в иерархическом представлении. Обычно квалификатор отображается на самом высоком уровне дерева, за которым следуют имя файла, имя элемента и версия. Кроме того, файлы могут храниться на серверах OS 2200, используя полный формат имени файла Windows. Приложения Windows будут видеть OS 2200 как еще один файловый сервер. Приложения OS 2200 имеют API-интерфейсы, доступные для чтения и записи файлов, существующих на других CIFS-совместимых серверах, таких как файловые серверы Windows, в сети. Текстовые файлы автоматически преобразуются во внутренние форматы OS 2200 и обратно. Двоичные файлы должны пониматься прикладной программой.

Утилита CIFSUT, работающая под OS 2200, может обмениваться зашифрованными сжатыми файлами с другим программным обеспечением, например WinZip.

Подсистемы

Концепция подсистем и защищенных подсистем занимает центральное место в конструкции OS 2200. Подсистема наиболее похожа на .dll в Windows. Это код и данные, которые могут использоваться всеми программами, работающими в системе. В OS 2200 каждая подсистема имеет свой набор банков, находящихся в отдельной части адресного пространства, к которой не имеет прямого доступа ни одна пользовательская программа. Вместо этого аппаратное обеспечение и ОС предоставляют «шлюз», который может быть целью инструкции вызова. см. в архитектуре системы Unisys серии 2200 Дополнительную информацию .

Менеджеры баз данных, библиотеки времени выполнения, система обмена сообщениями и многие другие системные функции реализованы как подсистемы. Некоторые подсистемы, обычно состоящие из чистого кода, такие как библиотеки времени выполнения, могут быть прямой целью инструкции вызова, не требуя шлюза. Эти подсистемы работают в среде защиты пользовательской программы. Другие подсистемы, такие как менеджеры баз данных, состоят из кода и данных или привилегированного кода и могут быть вызваны только через шлюз. Эти подсистемы также могут иметь связанные с ними списки управления доступом, позволяющие контролировать, кто может к ним обращаться. Что еще более важно, шлюз управляет конкретными видимыми точками входа, защитной средой, в которой будет работать подсистема, и часто параметром, специфичным для пользователя, который предоставляет дополнительную защищенную информацию о вызывающем объекте.

Безопасность

Безопасность B1

Система безопасности OS 2200 предназначена для защиты данных от несанкционированного доступа, изменения или раскрытия. Он включает в себя реализацию спецификации уровня DoD Orange Book B1 . OS 2200 впервые получила успешную оценку B1 в сентябре 1989 года. Эта оценка сохранялась до 1994 года. После этого разработчики OS 2200 продолжали следовать практикам разработки и документации, требуемым оценкой B1.

Центральное место в системе B1 занимают концепции пользователей и объектов. У пользователей есть идентификационные данные, уровни доступа, отсеки и привилегии. Объекты требуют определенных комбинаций для различных типов доступа. Объекты в OS 2200 состоят из файлов, защищенных подсистем, устройств и катушек с лентой.

Профиль безопасности пользовательского сеанса включает идентификатор пользователя, уровень доступа (0–63), набор отсеков и набор разрешенных привилегий. OS 2200 реализует как обязательный контроль доступа (MAC), так и дискретный контроль доступа (DAC) на основе модели конфиденциальности Белла-Ла Падулы (без чтения и записи) и модели целостности Biba (без чтения и записи). . Чтобы запуск мог читать или выполнять файл, уровень допуска выполнения выполнения должен быть больше или равен уровню допуска файла, а уровень допуска файла должен быть равен 0 или находиться в пределах диапазона уровня допуска запуска; кроме того, набор исполняемых отсеков выполнения должен содержать набор отсеков файла. Поскольку OS 2200 сочетает в себе требования моделей Bell-La Padula и Biba, уровень допуска выполнения и набор отсеков для выполнения должны точно совпадать с таковыми для файла, чтобы разрешить запись в файл или его удаление.

DAC связывает список управления доступом с объектом; список идентифицирует пользователей и группы пользователей, которые имеют доступ, и определяет тип доступа, который разрешен пользователю или группе (чтение, запись, выполнение или удаление).

Поскольку полный набор элементов управления B1 слишком ограничен для большинства сред, системные администраторы могут настраивать серверы, выбирая, какие элементы управления применять. Набор уровней безопасности от «Фундаментальной безопасности» до уровня безопасности 3 служит отправной точкой.

Сотрудник службы безопасности

В каждой системе OS 2200 есть один пользователь, назначенный офицером безопасности. В системах, настроенных с фундаментальной безопасностью, только офицеру безопасности разрешено выполнять определенные задачи. В системах, настроенных с более высоким уровнем безопасности, другим доверенным пользователям может быть разрешено выполнение некоторых из этих задач.

OS 2200 предоставляет детальный механизм безопасности, основанный на принципе минимальных привилегий . Этот принцип требует, чтобы предоставлялись только минимальные привилегии, необходимые для выполнения требуемой задачи. Таким образом, в OS 2200 нет понятия роли «Суперпользователя», которую может взять на себя любой пользователь. Скорее, он использует большой набор конкретных привилегий, которые могут быть предоставлены отдельно каждому пользователю. Каждая привилегия связана с определенным органом власти.

Безопасность файлов

В системах, настроенных с уровнем безопасности 1 или выше, пользователь, создающий объект, является владельцем объекта. По умолчанию объект является частным для создающего пользователя, но он также может быть общедоступным или контролироваться списком управления доступом. Владелец или Сотрудник службы безопасности может создать список контроля доступа для этого объекта.

В системе с фундаментальной безопасностью файлы не имеют владельцев. Вместо этого они создаются частными для учетной записи или проекта или являются общедоступными. Доступ к ним можно контролировать с помощью ключей чтения и записи.

Аутентификация

Когда пользователи входят в систему, они идентифицируют себя и при необходимости выбирают уровень допуска и набор отсеков, которые они будут использовать для этого сеанса.

OS 2200 предлагает гибкую систему аутентификации. Одновременно поддерживаются несколько механизмов аутентификации. Также может использоваться программное обеспечение для аутентификации, написанное клиентом или третьей стороной. Стандартные возможности аутентификации включают в себя:

• Идентификатор пользователя и пароль сохраняются в зашифрованном файле OS 2200.
• Аутентификация, выполняемая внешней системой, такой как Microsoft Windows, с использованием механизма идентификатора пользователя и пароля.
• НТЛМ
• Керберос
• ЛДАП

Последние два позволяют использовать биометрию, смарт-карты и любые другие механизмы аутентификации, поддерживаемые этими технологиями.

Шифрование

OS 2200 обеспечивает шифрование хранящихся данных с помощью Cipher API, программной подсистемы, которая шифрует и расшифровывает данные вызывающего абонента. Cipher API также поддерживает использование карты аппаратного ускорителя для шифрования больших объемов данных.

Для серверов Dorado на базе CMOS CPComm обеспечивает шифрование SSL/TLS для передаваемых данных . Для серверов Dorado на базе процессоров Intel SSL и TLS предоставляются openSSL , который включен в прошивку Dorado. Все серверы Dorado поддерживают уровни TLS от 1.0 до 1.2, а также SSLv3, но SSL по умолчанию отключен из-за уязвимостей в протоколе.

И CPComm, и Cipher API используют службы шифрования CryptoLib, модуля программного шифрования, сертифицированного по стандарту FIPS . Алгоритмы AES и Triple DES входят в число алгоритмов, реализованных в CryptoLib.

OS 2200 также поддерживает ленточные накопители с шифрованием, которые обеспечивают шифрование архивных данных.

Кластеризация

Системы OS 2200 можно объединять в кластеры для достижения большей производительности и доступности, чем в одной системе. До 4 систем могут быть объединены в кластер, совместно использующий базы данных и файлы через общие диски. Аппаратное устройство XPC-L обеспечивает координацию между системами, предоставляя высокоскоростной менеджер блокировок для доступа к базе данных и файлам.

Кластеризованная среда позволяет каждой системе иметь свои собственные локальные файлы, базы данных и группы приложений, а также общие файлы и одну или несколько общих групп приложений. Доступ к локальным файлам и базам данных возможен только из одной системы. Общие файлы и базы данных должны находиться на дисках, одновременно доступных со всех систем кластера.

XPC-L обеспечивает канал связи между системами для координации действий. Он также обеспечивает очень быстрый механизм блокировки. Подключение к XPC-L осуществляется через специальный процессор ввода-вывода, который работает с чрезвычайно низкой задержкой. Менеджер блокировок в XPC-L предоставляет все функции, необходимые для блокировки файлов и баз данных. Сюда входит обнаружение взаимоблокировок и возможность снятия блокировок отказавших приложений.

XPC-L оснащен двумя физическими серверами для создания полностью резервированной конфигурации. XPC-L Техническое обслуживание, включая загрузку новых версий прошивки , может выполняться на одном из серверов, пока другой продолжает работать. Сбои, в том числе физическое повреждение одного сервера, не останавливают работу кластера, поскольку вся информация хранится на обоих серверах.

Операции и администрирование

Операции

Операции OS 2200 построены на основе активных операторов и одной или нескольких консолей. Каждая консоль представляет собой окно терминала, часть которого отведена для фиксированного дисплея, который часто обновляется сводной информацией о активности в системе.

Остальная часть консоли используется для прокрутки событий. При выдаче сообщения, требующего реакции оператора, ему присваивается номер от 0 до 9, и оно остается на дисплее до момента ответа на него. Сообщения о монтировании ленты прокручиваются вместе с другими сообщениями, но будут повторяться каждые две минуты, пока лента не будет смонтирована.

Operations Sentinel используется для всех операций OS 2200. Консоли OS 2200 — это просто окна на дисплее Operations Sentinel. ПК с дисплеями может быть сколько угодно. Дистанционное управление является типичным. Operations Sentinel поддерживает любое количество систем ClearPath, Windows, Linux и UNIX.

Вместе с продуктом поставляется база данных сообщений автоматических действий. Эта база данных позволяет Operations Sentinel распознавать сообщения. Могут быть написаны сценарии для автоматического ответа на сообщения, требующие ответа, скрытия нежелательных сообщений, перевода их на другие языки, создания событий и т. д. Некоторые клиенты используют полную работу в темной комнате. В лучшем случае они будут иметь дисплеи Operations Sentinel в удаленных местах, контролирующие систему и создающие оповещения при возникновении определенных событий.

Администрация

Администрирование систем OS 2200 осуществляется с использованием широкого спектра инструментов, каждый из которых предназначен для определенной области системы. Например, существует инструмент, используемый для администрирования среды транзакций, который позволяет устанавливать новые программы транзакций, задает всю необходимую информацию о них, изменяет структуру очередей, приоритеты, уровни параллелизма и так далее.

Другие инструменты специфичны для сотрудника службы безопасности и позволяют создавать пользователей, изменять разрешенные привилегии, изменять настройки безопасности системы и т. д. ^{, ,}

Большинство инструментов имеют графический интерфейс, хотя некоторые его не имеют. Все они предоставляют пакетный файловый интерфейс, в котором все действия указываются в потоке управления. Это позволяет создавать сценарии для любых административных интерфейсов как с локальных сайтов, возможно, в зависимости от времени суток или других событий, так и с удаленных сайтов. Для каждой административной области требуются уникальные привилегии.

Группы приложений

Группы приложений представляют собой логическую конструкцию, состоящую из экземпляра универсальной системы данных (UDS), экземпляр подсистемы очереди сообщений и некоторый набор транзакций. Каждая группа приложений имеет свой собственный контрольный журнал. OS 2200 поддерживает максимум 16 групп приложений в системе.

Понятие группы приложений соответствует тому, что часто называют «приложением». То есть набор программ и данных, которые представляют собой некую более крупную единицу связанной обработки. Например, группа приложений может представлять систему авиакомпании. Другая группа приложений может представлять систему корпоративных финансов. Или группы приложений могут представлять собой экземпляры тех же моделей приложений и данных, что и в отделениях банка. Важно то, что каждая группа приложений имеет свою среду, сеансы, восстановление и т. д.

Группы приложений можно запускать, останавливать и восстанавливать независимо друг от друга.

Группы приложений не имеют собственных правил учета и планирования. Транзакции в нескольких группах приложений могут иметь одни и те же приоритеты и чередующиеся приоритеты. Это позволяет сайту контролировать относительные приоритеты транзакций во всей системе.

См. также

• Системная архитектура Unisys 2200 Series для получения информации об аппаратной архитектуре.
• Языки программирования Unisys OS 2200 для получения информации о компиляторах и компоновщиках OS 2200.
• Базы данных Unisys OS 2200 для получения информации о базах данных OS 2200 и менеджере баз данных.
• Связь Unisys OS 2200 для получения информации о связи OS 2200.
• Распределенная обработка Unisys OS 2200 для получения информации о распределенной обработке OS 2200.

Другие места исходного материала

Информационный бюллетень Unisys History содержит статьи об истории Unisys и компьютерах. Помимо всех информационных бюллетеней Unisys History, имеются ссылки на другие сайты.

Большая часть исторических архивов Unisys находится в Институте Чарльза Бэббиджа при Университете Миннесоты, а также в Музее и библиотеке Хэгли в Делавэре. Институт Чарльза Бэббиджа хранит архивы ERA, некоторые ранние архивы Remington Rand из Сент-Пола, Миннесота, и архивы Берроуза. В музее и библиотеке Хэгли хранится большая часть архивов Сперри.

Очень полезная вводная статья об OS 2200 2020-х годов в Arcane Sciences .