ОС 2200 - OS 2200

ОС 2200
РазработчикUnisys
Семейство ОСОС 2200
Рабочее состояниеТекущий
Исходная модельЗакрытый источник. Большинство исходников доступно клиентам по лицензии.
изначальный выпуск1967; 53 года назад (1967) как Exec 8
Последний релиз18.0 / 18 июля 2018 г.; 2 года назад (2018-07-18)[1]
Маркетинговая цельПредприятие / мэйнфреймы
Метод обновленияExec и некоторые другие компоненты: пакетные изменения на основе номера строки. Большинство компонентов: Промежуточные исправления (IC)
Менеджер пакетовПРИМУС (внутренний), КОМУС и СОЛНЕЧНЫЙ (клиентский и внутренний)
ПлатформыСистемы UNIVAC 1100/2200 и Unisys ClearPath Dorado
Ядро типМонолитное ядро (с уникальной аппаратной поддержкой)[нужна цитата ]
Дефолт пользовательский интерфейсИнтерфейс командной строки
ЛицензияПроприетарный. Срочная лицензия или плата за использование (лимитных) лицензий
Официальный веб-сайтOS 2200 сайт

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

Видеть Системная архитектура Unisys серии 2200 для описания архитектуры машины и ее отношения к операционной системе OS 2200.

История

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

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

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

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

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

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

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

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

Exec 8

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

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

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

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

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

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

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

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

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

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

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

В 1968 году началась работа по добавлению совместное времяпровождение способность к исполнителю 8. Он был предоставлен руководителю 23 уровня в 1969 году. требовать режим) имел те же возможности, что и пакетные процессы и процессы в реальном времени. Все, что можно было сделать в пакетном режиме, можно было сделать с терминала 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) и SILAS (Системный интерфейс для устаревших прикладных систем).[8][9]Для моделей серверов Dorado на базе Intel связь нижнего уровня была перенесена на микропрограммное обеспечение, а верхние уровни обрабатывались SILAS и CPCommOS (Платформа связи серверов ClearPath Enterprise для открытых систем).[10]

Исполнитель

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

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

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

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

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

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

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

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

Партия

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

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

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

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

Хотя язык управления заданиями OS 2200 не поддерживает полную программируемость, он позволяет динамическое добавление последовательностей языка управления с помощью управляющего оператора @ADD. Добавляемый файл мог быть создан тем же заданием, которое непосредственно предшествовало его добавлению. @ADD и большинство других управляющих операторов также могут быть отправлены из запущенной программы через API.[11] Дополнительная возможность программирования доступна косвенно за счет использования генератора символьных потоков (SSG).[12] SSG - это язык программирования для управления и создания текстовых файлов из входных параметров и системной информации. Он широко используется для управления конфигурацией (делать ) обработки и других функций, в которых текстовые изображения необходимо создавать программно. Результирующий вывод может быть "@ADD" в том же прогоне, что обеспечивает косвенно программируемый поток выполнения.

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

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

требовать

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

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

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

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

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

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

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

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

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

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

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

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

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

Диспетчеризация процессора

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

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

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

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

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

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

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

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

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

Измерение

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

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

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

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

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

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

Имена файлов

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

В качестве программного файла можно использовать любой файл. Программный файл содержит элементы, которые обычно действуют как файлы. Именование элементов: квалификатор * имя файла (f-цикл) .Элемент / версия (электронный цикл) (например, "PERSONNEL * PROGRAMS.TAXCALC / 2008"). Элемент и версия - это имена, состоящие из двенадцати символов, которые могут использоваться любым желаемым пользователем образом. E-цикл похож на f-цикл в том, что он представляет номер поколения, но без ограничения 32 параллельными циклами, а ограничение составляет 256 К циклов. Однако электронный цикл применяется только к текстовым элементам, и каждая строка в текстовом элементе помечается номерами цикла, в котором он был вставлен и удален. У элементов также есть тип и подтип. Наиболее часто используемые типы - это «текст» и «объект». Если тип по умолчанию не подходит, опции выбирают подходящий тип. Text elements also have sub-types that typically represent the programming language (e.g., "ASM", "C", "COB", "FOR"). The default element name of an object file is the same as the text file from which it was created.

An object element may be executed if it is a main program or linked with other object elements including a main program. The linking may be static or dynamic. A main program may be executed without pre-linking provided all required sub-programs are in the same program file, are system libraries, or are otherwise known. Rules may be included in a program file to direct the dynamic linker's search for unfulfilled references. The linker may also be used to statically link multiple object modules together to form a new object module containing all instructions, data, and other information in the original object modules.

Omnibus elements may be used as data by applications or may serve to hold structured information for applications and system utilities. There is no assumed structure to an omnibus element.

For compatibility with earlier (basic mode) programming models, there are relocatable and absolute element types. Relocatable elements are the output of basic mode compilers. They may be combined by the basic mode static linker (@MAP – the collector) to form an "absolute" element which is executable.

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

OS 2200 implements a fully virtual file system. Files may be allocated anywhere across any and all mass storage devices. Mass storage is treated as a large space pool similar to the way virtual memory is managed. While contiguous space is allocated if possible, mass storage is treated as a set of pages of 8KB size and a file can be placed in as many areas of the same or different devices as is required. Dynamic expansion of files attempts to allocate space adjacent to the previous allocation, but will find space wherever it is available. In fact, files need not even be present on mass storage to be used. The Exec and the file backup system are fully integrated. When file backups are made, the tape reel number(s) are recorded in the file directory. If space gets short on mass storage, some files are simply marked as "unloaded" if they have a current backup copy, and their space is available for use. If enough space can't be found that way, a backup is started.

Any reference to an unloaded file will be queued while the file is copied back to mass storage. The whole system is automatic and generally transparent to users.[17]

Access methods

In general, the Exec does not provide access methods. Files are simply containers. Access methods are provided by the language run time systems and the database manager. The one exception is a fixed-block access method provided for high-volume transaction processing.[18] It has much less overhead than the database manager, but does participate in all locking, clustering, and recovery mechanisms.

Removable packs

When clients want more explicit control over the location of files, they can use the "removable pack" concept. At one time these truly represented physically removable disk packs, and the operating system would automatically generate pack mount requests to operators as needed.

Today they are still used to place files, usually database files or transaction files, on one or more disk volumes. Files may still span multiple disk volumes, and now the list of volume names is given when the file is created. Files that are on such volume groups are still backed up but are not subject to automatic virtual space management.

CIFS

OS 2200 also provides a full implementation of the Common Internet File System (CIFS ).[19] CIFS implements the SMB protocol used by Microsoft servers and the UNIX/Linux Самба программного обеспечения. CIFS for ClearPath OS 2200 is both a file server and file client to other CIFS-compliant systems. This includes desktop PCs running Windows. CIFS supports SMB message signing.

To maintain OS 2200 security, CIFS for ClearPath OS 2200 provides two levels of protection. First, OS 2200 files are not visible to the network until they have been declared as "shares" with a CIFS command. A specific privilege exists to control who may declare a share. The second level of control is that all access is still protected by OS 2200 security. Clients accessing OS 2200 via CIFS will either have to be automatically identified via NTLM или же Kerberos or they will be presented with a query for their OS 2200 user id and password.

CIFS allows OS 2200 files to be presented in a hierarchical view. Typically the qualifier will appear as the highest level in the tree followed by filename, element name, and version. In addition, files may be stored on OS 2200 servers using the full Windows filename format. Windows applications will see OS 2200 as another file server.OS 2200 applications have APIs available to read and write files existing on other CIFS-compliant servers, such as Windows file servers, in the network. Text files are automatically converted to and from OS 2200 internal formats. Binary files must be understood by the application program.

The CIFSUT utility running under OS 2200 can exchange encrypted compressed files with other software, such as WinZip.

Subsystems

The concept of subsystems and protected subsystems are central to the design of OS 2200. A subsystem is most analogous to a .dll in Windows. It is code and data that may be shared among all programs running in the system.[20] In OS 2200 each subsystem has its own set of banks that reside in a separate part of the address space that cannot be directly accessed by any user program. Instead the hardware and the OS provide a "gate" that may be the target of a Call instruction. Видеть Unisys 2200 Series system architecture для дополнительной информации.

The database managers, run time libraries, messaging system, and many other system functions are implemented as subsystems. Some subsystems, usually consisting of pure code, such as the run time libraries, may be the direct target of a Call instruction without requiring a gate. These subsystems run in the user program's protection environment. Other subsystems, such as the database managers, consist of code and data or privileged code and may only be called via a gate. These subsystems may also have access control lists associated with them to control who may call them. More importantly, the gate controls the specific entry points that are visible, the protection environment in which the subsystem will run, and often a user-specific parameter that provides additional secure information about the caller.

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

B1 security

The OS 2200 security system is designed to protect data from unauthorized access, modification, or exposure. It includes an implementation of the DoD Оранжевая книга B1 level specification.[21] OS 2200 first obtained a successful B1 evaluation in September, 1989. That evaluation was maintained until 1994. After that point, OS 2200 developers continued to follow development and documentation practices required by the B1 evaluation.

Central to a B1 system are the concepts of users and objects.[22][23] Users have identities, clearance levels, compartments and privileges. Objects require certain combinations of those for various types of access. Objects in OS 2200 consist of files, protected subsystems, devices, and tape reels.

The security profile of a user session includes the user identity, clearance level (0-63), compartment set, and set of allowed privileges. OS 2200 implements both Обязательный контроль доступа (MAC) и Дискреционный контроль доступа (DAC) based on the Модель Bell-La Padula for confidentiality (no read up, no write down) and the Biba integrity model (no read down, no write up). For a run to read or execute a file, the run's executing clearance level must be greater than or equal to the clearance level of the file, and the file's clearance level must be 0 or within the clearance level range of the run; in addition, the run's executing compartment set must contain the file's compartment set. Because OS 2200 combines the Bell-La Padula and Biba model requirements, a run's executing clearance level and compartment set must exactly match those of a file to permit writing to the file or deleting it.

DAC associates an access control list with an object; the list identifies users and user groups that have access and defines the type of access that user or group is allowed (read, write, execute, or delete).

Because the full set of B1 controls is too restrictive for most environments, system administrators can configure servers by choosing which controls to apply. A set of security levels from Fundamental Security through Security Level 3 serves as a starting point.

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

Every OS 2200 system has one user designated as the security officer. On systems configured with fundamental security, only the security officer is allowed to perform certain tasks. On systems configured with higher levels of security, other trusted users may be allowed to perform some of these tasks.

OS 2200 provides a fine-grained security mechanism based on the принцип наименьших привилегий. This principle demands that only the minimum privilege be granted necessary to perform the task required. Thus, OS 2200 has no concept of a "Super User" role that can be assumed by any user. Rather it uses a large set of specific privileges which may be granted separately to each user. Each privilege is associated with a specific authority.

File security

On systems configured with security level 1 or higher levels, the user who creates an object is the object's owner. The default is that the object is private to the creating user, but it may also be public or controlled by an access control list. The owner or the security officer may create an access control list for that object.

On system configured with fundamental security, files do not have owners. Instead, they are created private to an account or project, or they are public. Access to them can be controlled by read and write keys.

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

When users log on to the system, they identify themselves and optionally select the clearance level and compartment set they will use for this session.

OS 2200 offers a flexible authentication system. Multiple authentication mechanisms are supported concurrently. Client- or third party-written authentication software may also be used. Standard authentication capabilities include:

  • User id and password maintained in an encrypted file by OS 2200
  • Authentication performed by an external system such as Microsoft Windows using its user id and password mechanism
  • NTLM
  • Kerberos
  • LDAP

The last two permit the use of biometrics, smart cards, and any other authentication mechanism supported by those technologies.

Шифрование

OS 2200 provides encryption for data at rest through Cipher API, a software subsystem that encrypts and decrypts caller data.[24] Cipher API also supports the use of a hardware accelerator card for bulk data encryption.

For CMOS-based Dorado servers, CPComm provides SSL / TLS шифрование для данные в пути. For Intel-based Dorado servers, SSL and TLS are provided by openSSL, which is included in the Dorado firmware. All Dorado servers support TLS levels 1.0 through 1.2, as well as SSLv3, but SSL is disabled by default because of vulnerabilities in the protocol.

Both CPComm and Cipher API use the encryption services of CryptoLib, a FIPS -certified software encryption module. В AES и Тройной DES algorithms are among the algorithms implemented in CryptoLib.

OS 2200 also supports encrypting tape drives, which provide encryption for archive data.

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

OS 2200 systems may be сгруппированный to achieve greater performance and availability than a single system. Up to 4 systems may be combined into a cluster sharing databases and files via shared disks. A hardware device, the XPC-L, provides coordination among the systems by providing a high-speed lock manager for database and file access.[25]

A clustered environment allows each system to have its own local files, databases, and application groups along with shared files and one or more shared application groups. Local files and databases are accessed only by a single system. Shared files and databases must be on disks that are simultaneously accessible from all systems in the cluster.

The XPC-L provides a communication path among the systems for coordination of actions. It also provides a very fast lock engine. Connection to the XPC-L is via a special I/O processor that operates with extremely low latencies. The lock manager in the XPC-L provides all the functions required for both file and database locks. This includes deadlock detection and the ability to free up locks of failed applications.

The XPC-L is implemented with two physical servers to create a fully redundant configuration. Maintenance, including loading new versions of the XPC-L прошивка, may be performed on one of the servers while the other continues to run. Failures, including physical damage to one server, do not stop the cluster, as all information is kept in both servers.

Operations and administration

Операции

OS 2200 operations is built around active operators and one or more consoles. Each console is a terminal window, part of which is reserved for a fixed display that is frequently updated with summary information about activity in the system.[26]

The rest of the console is used as a scrolling display of events. When a message is issued that requires an operator response, it is given a number from 0 to 9 and remains on the display until it is answered. Tape mount messages do scroll with other messages but will be repeated every two minutes until the tape is mounted.

Operations Sentinel is used for all OS 2200 operations.[27] OS 2200 consoles are simply windows within an Operations Sentinel display. There may be as many display PCs as desired. Remote operation is typical. Operations Sentinel supports any number of ClearPath, Windows, Linux, and UNIX systems.

An auto-action message database is released with the product.[28] This database allows Operations Sentinel to recognize messages. Scripts may be written to automatically respond to messages that require a response, hide unwanted messages, translate them to other languages, create events, etc. Full dark room operation is used by some clients. At most they will have Operations Sentinel displays at remote locations monitoring the system and creating alerts when certain events occur.

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

Administration of OS 2200 systems is performed using a wide variety of tools, each specialized to a particular area of the system. For example, there is a tool used for administering the transaction environment that allows new transaction programs to be installed, specifies all the necessary information about them, changes the queuing structure, priorities, and concurrency levels, and so on.[29]

Other tools are specific to the security officer and allow creation of users, changing allowed privileges, changing system security settings, etc.[22],[30],[23]

Most of the tools have a graphical interface although some do not. All provide a batch stored file interface where all actions are specified in the control stream. This allows scripting any and all of the administrative interfaces from either local sites, maybe based on time of day or other events, or from remote sites. Unique privileges are required for each administrative area.

Application groups

Application groups are a logical construct consisting of an instance of the Universal Data System (UDS),[31] an instance of the message queue subsystem, and some set of transactions. Each application group has its own audit trail. OS 2200 supports a maximum of 16 application groups in a system.

The notion of application group corresponds to what is often called "an application." That is, a set of programs and data that represent some larger unit of connected processing. For example, an application group might represent an airline system. Another application group might represent the corporate finance system. Or, application groups might represent instances of the same application and data models, as in bank branches. The important thing is that each application group has its own environment, sessions, recovery, etc.

Application groups may be started, stopped, and recovered independently.

Application groups do not have their own accounting and scheduling rules. Transactions in multiple application groups may share the same priorities and have interleaved priorities. This permits the site to control the relative priorities of transactions across the entire system.

Смотрите также

Other locations of source material

В Информационный бюллетень Unisys History contains articles about Unisys history and computers. In addition to all of the Unisys History Newsletters there are links to other sites.

Most of the historical archives of Unisys are at the Институт Чарльза Бэббиджа at the University of Minnesota and at the Музей и библиотека Хэгли в Делавэре. The Charles Babbage Institute holds the archives from ERA, some early Remington Rand archives from Saint Paul, MN, and the Burroughs archives. The Hagley Museum and Library holds the bulk of the Sperry archives.

Рекомендации

  1. ^ "Added Security, Digital Access Highlight Latest Release of Unisys ClearPath® OS 2200" (Пресс-релиз). Unisys.
  2. ^ Gray, George T.; Smith, Ronald Q. (2001). "Sperry Rand's transistor computers". IEEE Annals of the History of Computing. IEEE Computer Society. 20 (3): 16–26. Дои:10.1109/85.707571.
  3. ^ Gray, George T.; Smith, Ronald Q. (2007). "Against the Current: The Sperry-Burroughs Merger and the Unisys Struggle to Survive 1980-2001". IEEE Annals of the History of Computing. IEEE Computer Society. 29 (2): 3–17. Дои:10.1109/MAHC.2007.16.
  4. ^ Simon Sharwood (31 March 2016). "Free x86 mainframes for all! Virtual x86 mainframes, that is". Реестр. Получено 31 марта 2016.
  5. ^ Petschauer, Richard J (1990). History and Evolution of 1100/2200 Mainframe Technology (PDF). USE Conference. Bladensburg, MD: USE User Group.
  6. ^ Gray, George T.; Smith, Ronald Q. (2001). "Sperry Rand's Third-Generation Computers 1964-1980". IEEE Annals of the History of Computing. IEEE Computer Society. 23 (1): 3–16. Дои:10.1109/85.910845..
  7. ^ Gray, George T. & Smith, Ronald Q.(2008). Unisys Computers: An Introductory History. ISBN  978-1-61539-223-0 New Jersey, Lulu (www.lulu.com/content/2735927).
  8. ^ ClearPath Enterprise Servers Communications Platform Configuration and Operations Guide (Unisys publication 7844 8438) (PDF). Roseville, MN: Unisys Corporation. 2015 г.
  9. ^ System Interface for Legacy Application Systems(SILAS) Configuration and Operations Guide (Unisys publication 7851 5475) (PDF). Roseville, MN: Unisys Corporation. 2013.
  10. ^ ClearPath Enterprise Servers Communications Platform for Open Systems Configuration and Operations Guide (Unisys publication 3850 8032) (PDF). Roseville, MN: Unisys Corporation. 2015 г.
  11. ^ а б Executive Control Language (ECL) and FURPUR Reference Manual (Unisys publication 7830 7949) (PDF). Roseville, MN: Unisys Corporation. 2014 г.
  12. ^ Symbolic Stream Generator (SSG) Programming Reference Manual (Unisys publication 7830 7881) (PDF). Roseville, MN: Unisys Corporation. 2014 г.
  13. ^ OS 2200 Transaction Processing Administration and Operations Reference Manual (Unisys publication 7830 7881) (PDF). Roseville, MN: Unisys Corporation. 2014 г.
  14. ^ OS 2200 Exec System Software Administration Reference Manual (Unisys publication 7831 0323) (PDF). Roseville, MN: Unisys Corporation. 2014 г.
  15. ^ ClearPath OS 2200 Metering Technology (Unisys white paper publication 1749). Roseville, MN: Unisys Corporation. 2014 г.
  16. ^ Data Structures Programming Reference Manual (Unisys publication 7833 3481) (PDF). Roseville, MN: Unisys Corporation. 2014 г.
  17. ^ File Administration System (FAS) Operations Guide (Unisys publication 7830 7972) (PDF). Roseville, MN: Unisys Corporation. 2014 г.
  18. ^ Transaction Processing Conceptual Overview (Unisys publication 7830 9960) (PDF). Roseville, MN: Unisys Corporation. 2012 г.
  19. ^ CIFS for ClearPath OS 2200 User, Programmer, and Administrator Reference Manual (Unisys publication 7859 6137) (PDF). Roseville, MN: Unisys Corporation. 2014 г.
  20. ^ Linking System Programming Reference Manual (Unisys publication 7830 7551) (PDF). Roseville, MN: Unisys Corporation. 2014 г.
  21. ^ Department Of Defense Trusted Computer System Evaluation Criteria (NSI 5200.28-STD). National Security Institute. 1985. Архивировано из оригинал on 2009-06-25. Получено 2009-07-24.
  22. ^ а б Security Administration for ClearPath OS 2200 Help (Unisys publication 7862 1760). Roseville, MN: Unisys Corporation. 2014 г.
  23. ^ а б ClearPath OS 2200 Apex Help (Unisys publication 8207 4154) (PDF). Roseville, MN: Unisys Corporation. 2015 г.
  24. ^ Cipher Application Programming Interface (API) Programming Reference Manual 3826 6110 (PDF).
  25. ^ Integrated Recovery Ref and Admin Guide for Multihost Environments (Unisys publication 7831 0919) (PDF). Roseville, MN: Unisys Corporation. 2014 г.
  26. ^ Exec System Software Operations Reference Manual (Unisys publication 7831 0281) (PDF). Roseville, MN: Unisys Corporation. 2014 г.
  27. ^ Operations Sentinel Administration and Configuration Guide (Unisys publication 7862 2321) (PDF). Roseville, MN: Unisys Corporation. 2014 г.
  28. ^ Operations Sentinel Autoaction Message System Administration Guide (Unisys publication 7862 6900) (PDF). Roseville, MN: Unisys Corporation. 2012 г.
  29. ^ Transaction Processing Administration and Operations Reference Manual (Unisys publication 7830 7881) (PDF). Roseville, MN: Unisys Corporation. 2014 г.
  30. ^ TeamQuest Site Management Complex (SIMAN) Administration and End Use Reference Manual (TeamQuest publication TQ-01151.21) (PDF). Clear Lake, IA: TeamQuest Corporation. 2013.
  31. ^ Universal Data System Planning and Installation Overview (Unisys publication 7844 8370) (PDF). Roseville, MN: Unisys Corporation. 2014 г.

Сноски

  1. ^ Current Unisys documentation is available on the Unisys public support web site. For OS 2200 products, select one of the ClearPath Dorado platforms (e.g., Dorado 800 or Dorado 8300) and then the release level (usually the highest numbered one unless you are looking for something specific in an earlier release). That will take you to a search page where you can search by title or document content.