OS 2200 — это операционная система для семейства мэйнфреймовых систем Unisys ClearPath Dorado. Ядро операционной системы OS 2200 является прямым потомком Exec 8 для UNIVAC 1108 и ранее было известно как OS 1100. Документацию и другую информацию о текущих и прошлых системах Unisys можно найти на общедоступном веб-сайте поддержки Unisys. [примечание 1]
Описание архитектуры машины и ее связи с операционной системой OS 2200 см. в разделе Архитектура системы Unisys 2200 Series . Unisys прекратила выпуск оборудования ClearPath Dorado в начале 2010-х годов, и теперь операционная система работает в режиме эмуляции. [1]
Были и более ранние системы 1100, начиная с 1101 в 1951 году, но 1108 был первым компьютером серии 1100 , разработанным для эффективной поддержки многопрограммного и многопроцессорного режима. Вместе с этим новым оборудованием появилась операционная система Exec 8 (Executive System для 1108).
Компьютер UNIVAC 1108 был анонсирован в 1964 году и поставлен в конце 1965 года. Первые компьютеры 1108 использовали Exec I и Exec II , которые были разработаны для UNIVAC 1107. Однако UNIVAC планировал предложить симметричные многопроцессорные версии 1108 с числом процессоров до 4, а более ранние операционные системы (действительно базовые программы-мониторы) не были предназначены для этого, хотя и поддерживали ограниченную многопрограммность.
Когда в 1972 году был представлен UNIVAC 1110 , название операционной системы было изменено на OS 1100, чтобы отразить поддержку более широкого спектра систем. Название OS 1100 сохранялось до 1988 года с выпуском Sperry 2200 Series в качестве преемника серии 1100, когда ее название было изменено на OS 2200. С этого времени серия 2200 стала называться Unisys ClearPath IX Series , а затем 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 Corporation . Подразделение UNIVAC Remington Rand Corporation стало подразделением UNIVAC Sperry Rand Corporation после слияния Remington Rand со Sperry Corporation . В 1970-х годах Sperry Rand начала программу корпоративной идентичности, которая изменила ее название на Sperry Corporation и все названия подразделений, начинающиеся со Sperry, поэтому подразделение компьютерных систем стало Sperry UNIVAC. Позже названия подразделений были отброшены, и все стало просто Sperry.
Ядро операционной системы по-прежнему именуется "Exec" большинством сотрудников Unisys и заказчиков. Однако, когда Unisys начала выпускать наборы продуктов, протестированных вместе как системные базовые выпуски, позже названные "ClearPath OS 2200 Release n ", термин OS 2200 изменился, чтобы обозначать весь набор продуктов в системном выпуске и другие, такие как BIS , выпущенные асинхронно для аппаратных платформ Dorado.
В 1986 году корпорации Burroughs и Sperry объединились и стали называться Unisys (что, по словам некоторых давних клиентов серии 2200, означает «UNIVAC по-прежнему ваш поставщик»). [3] Основные линейки продуктов для мэйнфреймов обеих компаний продолжают развиваться, включая операционную систему MCP от Burroughs и ОС 2200 от Sperry.
В 2016 году компания Unisys сделала виртуальную версию Microsoft Windows OS2200 доступной бесплатно для образовательных и развлекательных целей. [4]
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 начиналась как операционная система реального времени с ранним использованием в основном в общих научных и инженерных работах, но она также использовалась для коммутации сообщений, управления процессами, моделирования и управления запуском ракет. Она была разработана для работы на системах, которые часто имели только 128K слов (576K байт — меньше максимального размера памяти для IBM PC XT ), и была сосредоточена на реальном времени и пакетной обработке. Хотя самые ранние уровни выпуска работали в 128KW, увеличение функциональности в более поздних выпусках сделало это невозможным, поскольку оно не оставляло достаточно места для программ полезного размера. Максимальная емкость памяти 1108 составляла 256KW (1152 КБ), поэтому эффективное использование памяти было самым важным ограничением, поскольку основная память была самой дорогой частью системы.
Массовое хранилище состояло из вращающихся барабанов длиной 6 футов, которые вмещали от 256 кВт (в FH-432) до 2 МВт (в FH-1782). Наибольшей емкостью массового хранилища был барабан FASTRAND , который вмещал 22 МВт (99 МБ). Фрагментация файлов решалась с помощью процесса, называемого «сохранение файла», который обычно выполнялся один раз в день, ночью. Он включал в себя перенос всех файлов на ленту, повторную инициализацию файловой системы барабана, а затем обратное чтение файлов.
При жестких ограничениях памяти и использовании в реальном времени сохранение только одной копии кода, загруженного в ядро, было обязательным требованием. Поскольку 1108 был разработан для многозадачности, система была полностью «реентерабельной» ( потокобезопасной ). Каждый реентерабельный модуль обращался к данным программы через один «базовый адрес» памяти, который был разным для каждого экземпляра данных запуска. Переключение контекстов выполнения можно было выполнить одной инструкцией, просто установив другой базовый адрес в одном регистре. Система использовала мелкозернистую блокировку для защиты общих структур данных. Исполнительные программы, компиляторы, утилиты и даже сложные пользовательские приложения, которые могли иметь несколько копий, работающих одновременно, были написаны так, чтобы их код мог быть общим. Это требовало загрузки только одной копии в память, экономя как пространство, так и время, необходимое для загрузки кода.
Другой причиной разделения кода и данных на различные загрузочные сущности было то, что память была реализована как два независимых банка (отдельные физические шкафы), называемые IBANK и DBANK (инструкции и данные). Каждый имел свой собственный путь доступа, поэтому ЦП мог считывать оба банка одновременно. Загружая исполняемый код в один банк памяти, а данные в другой, можно было сократить время выполнения многих программ почти вдвое.
Код повторного входа должен был быть потокобезопасным (только выполнение); самомодифицирующийся код не допускался. Для других программ изменение исполняемого кода во время выполнения все еще было приемлемым методом программирования во времена компьютеров серии 1100, но пользователям рекомендовалось не делать этого из-за снижения производительности. Преимущества безопасности рекламировались, но не ценились высоко, поскольку взлом большинства приложений серии 1100 не принес бы никакой выгоды никому, и потому что тогда мало кто из хакеров был злонамеренным.
Exec 8 был в первую очередь системой пакетной обработки , которая давала приложениям (называемым «задачами») очень тонкий контроль над приоритетом планирования ЦП для его потоков (называемых «активностями»). Переключение процессоров было упреждающим, при этом потоки с более высоким приоритетом получали контроль над процессором, в данный момент выполнявшим поток с самым низким приоритетом любой программы. За исключением систем реального времени, даже задачи с самым низким приоритетом получали некоторое процессорное время. Это была многопрограммная и многопроцессорная операционная система с полностью симметричным управлением процессором. Встроенная в оборудование инструкция «тест-и-установить» позволяла осуществлять очень эффективную и мелкозернистую блокировку как внутри ОС, так и внутри многопоточных приложений.
В Exec 8 работа организована в задания, называемые «запусками», которые планируются на основе их приоритета и потребности в блокируемых ресурсах, таких как ленточные накопители Uniservo или файлы барабанов Fastrand. Синтаксис языка управления использует символ «@» (который Univac называл «главным пробелом») в качестве символа распознавания оператора управления. За ним сразу следовало имя команды или программы, затем запятая и любые переключатели опций. После символа пробела оставшаяся часть оператора отличалась для определенных команд. Команда для компиляции программы FORTRAN выглядела бы как «@FOR[,options] исходный_файл, объектный_файл». Входные данные для приложения могли быть считаны из файла (обычно это изображения карт) или сразу следовать за командой @ в потоке выполнения. Все строки до контрольной команды «@END» считались входными данными, поэтому если забыть ее вставить, компилятор интерпретировал последующие команды как данные программы. По этой причине было предпочтительнее обрабатывать данные в файлах, а не вводить их в поток выполнения.
В 1968 году началась работа по добавлению возможности разделения времени в Exec 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 Servers Communications Platform) и SILAS (System Interface for Legacy Application Systems). [8] [9] Для моделей серверов Dorado на базе Intel коммуникации нижнего уровня были перемещены во встроенное ПО, а верхние уровни обрабатывались SILAS и CPCommOS (коммуникационная платформа для открытых систем ClearPath Enterprise Servers). [10]
Exec содержит весь код в системе, которому разрешено выполняться на самых высоких уровнях привилегий. Нет механизмов для продвижения другого кода на эти уровни привилегий.
Руководитель отвечает за управление аппаратным обеспечением системы, планирование и управление работами, а также за взаимодействие с операторами и администраторами.
В версии 16.0 уровень Exec равен 49R2 (49.70.5). Внутренние уровни системы используют трехкомпонентный номер, например 21.92.42 (который был первой широко используемой производственной системой, хотя более ранние выпуски использовались в производстве на ряде сайтов). Первая часть числа — это основной уровень, который указывает на новую версию Exec со всеми предыдущими обновлениями, интегрированными в новую базовую версию. Это нечастый процесс, который происходит с интервалом в несколько лет. Вторая часть числа указывает на версии обновлений основного уровня и часто происходит несколько раз в неделю. Когда принимается решение заморозить содержимое функций и подготовиться к выпуску, в игру вступает третья часть и указывает на версии уровня предварительной версии, поскольку применяются исправления и незначительные обновления функций. Одновременно с подготовкой уровня к выпуску обновления «основной линии» продолжаются, поскольку инженеры интегрируют изменения в рамках подготовки к будущему выпуску. В течение многих лет официальным уровнем выпуска был полный трехкомпонентный номер. Более поздние версии назывались просто 44R1, 44R2, 49R2 и т. д., хотя внутри компании по-прежнему используется трехчастное обозначение.
Exec по сути является многопоточной пакетной системой обработки в реальном времени. Все построено вокруг этой модели. Сам Exec в значительной степени структурирован как программа реального времени. Функции, которые выполняются как службы в Windows или демоны в Linux и UNIX, реализованы либо как действия в Exec, либо как пакетные программы, которые всегда работают в фоновом режиме.
Разделение времени (известное как режим запроса) и обработка транзакций реализованы как особые случаи пакетной обработки. Одним из результатов является то, что существует мало ограничений на то, что может делать пользователь или программа транзакций с разделением времени. Существует много предупреждений для авторов программ транзакций о том, что они не будут довольны производительностью, если, например, они вызовут крепление ленты, но это разрешено.
Самая большая единица работы — «Run». Это взято из терминологии «производственный запуск» завода и обычно соответствует заданию или сеансу в других системах. Run определяется его «потоком запуска». Поток запуска — это последовательность операторов управления, которые представляют шаги, которые необходимо выполнить. Они могут включать обработку файлов, выполнение программы и ветви управления. Пакетный запуск обычно хранится в виде файла и планируется командой «Запустить» из другого запуска или оператором. Запуск с разделением времени инициируется путем входа в систему с терминала с разделением времени и ввода команды @RUN. Часто оператор @RUN и второй оператор управления (часто @ADD или выполнение программы) генерируются автоматически на основе профиля пользователя. Авторизации безопасности проверяются на основе аутентифицированного идентификатора пользователя и другой информации, предоставленной в операторе управления запуском.
Транзакции — это особый случай. Фактически нет никаких управляющих операторов, но создаются внутренние структуры данных запуска. Это позволяет Exec связывать те же механизмы безопасности, учета, отладки и т. д. с программами транзакций. Обычно профиль безопасности кэшируется в памяти во время аутентификации пользователя транзакции и копируется из данных сеанса пользователя в состояние запуска транзакции, когда транзакция запланирована. Поскольку каждый экземпляр транзакции по сути является запуском, учет, регистрация и обработка ошибок инкапсулируются механизмом запуска.
Пакетные задания (Run) характеризуются наличием runstream (языковых операторов управления заданиями), хранящихся в файле. Пакетное задание всегда содержит оператор @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 — это язык программирования для манипулирования и создания текстовых файлов из входных параметров и системной информации. Он активно используется для обработки управления конфигурацией ( make ) и других функций, где текстовые изображения должны быть созданы программным способом. Результирующий вывод может быть "@ADD" в том же запуске, таким образом обеспечивая косвенно программируемый поток выполнения.
Команды оператора доступны для изменения как отставания, так и приоритетов выполнения запусков. Поскольку все команды оператора доступны через API для пользователей с соответствующими привилегиями, это может быть автоматизировано или контролироваться удаленным администратором.
Крайний срок — это особый случай пакета. Крайний срок выглядит так же, как и любой другой пакетный запуск, за исключением того, что время крайнего срока указано в операторе управления @RUN или @START. Время крайнего срока используется вместе с максимальным SUPS (оценкой времени) в операторе управления. Задание крайнего срока выполняется с обычными приоритетами пакета, если только или пока не выяснится, что оно может пропустить свое время крайнего срока. Тогда чем больше несоответствие между временем до крайнего срока и оставшимся SUPS, тем выше приоритет. Хотя крайний срок не может полностью отключить транзакции и не влияет на реальное время, он может эффективно отключить большую часть другой обработки в системе, если это необходимо для достижения его цели.
Сеансы разделения времени OS 2200 называются запусками по требованию (от "on demand"). Они используют тот же язык управления, что и пакетные запуски, с несколькими дополнениями, известными как "немедленные" операторы управления. Операторы немедленного управления используют "@@", который указывает, что они должны быть выполнены немедленно, даже если программа запущена. Хотя их можно использовать для создания или назначения файлов, наиболее важные из них позволяют пользователю по требованию завершать запущенную программу по ошибке или даже отправлять ей сигнал.
Транзакции выполняются как запуски, но без каких-либо сохраненных или отправленных управляющих операторов. Вместо этого, когда сообщение получено из сеанса, определенного как сеанс транзакции, оно сканируется для определения очереди транзакций, в которую оно должно быть помещено. Обычно это определяется первыми символами сообщения, но могут быть добавлены написанные пользователем сканеры. [13]
Менеджер коммуникаций, способный обрабатывать до 250 000 активных сеансов, принимает входящие сообщения транзакций и передает их в программное обеспечение очереди сообщений. Он может обрабатывать неограниченное количество сообщений в очереди, используя архитектуру очереди сообщений. Выполняется вызов API пакета интерфейса транзакций (TIP) в операционной системе для постановки транзакции в очередь в соответствующей точке очереди. Каждая точка очереди определяет приоритет и уровень параллелизма работы и связанную программу транзакции, которая должна быть выполнена.
Дерево планирования транзакционных программ позволяет клиенту устанавливать относительное использование для групп транзакционных программ. Ограничения параллелизма позволяют избежать доминирования одного типа работы в системе за счет исключения другой работы и избежать создания избыточного выделения ресурсов. В дереве можно создать до 4094 узлов.
Для каждой программы транзакции можно указать приоритет (от 0 до 63) и уровень параллелизма (от 1 до 2047).
Для планирования выбирается транзакция с наивысшим приоритетом, за исключением случаев, когда это ограничивается политиками параллелизма, действующими для ее узла и более высоких узлов.
Реальное время — это не другой тип выполнения. Скорее, это набор уровней приоритета, которые может запросить любая активность. Реальное время чаще всего используется долго работающими пакетными программами, такими как менеджер коммуникаций OS 2200 CPComm, но не ограничивается ими.
API предоставляет 36 уровней приоритета реального времени для использования приложениями. Пользователь и учетная запись должны иметь привилегию использовать приоритеты реального времени. Сайт должен контролировать, как его приложения используют уровни приоритета. Приоритеты реального времени полностью доминируют над всеми более низкими приоритетами, поэтому вполне возможно, что неправильно работающая программа реального времени загрузит один или несколько процессоров.
Приоритет реального времени применяется к отдельной активности (потоку), поэтому программа может иметь как потоки реального времени, так и потоки нереального времени, выполняемые одновременно.
После запуска выполнения, получение доступа к процессору контролирует скорость его выполнения. Сердцем Exec является Dispatcher , который управляет всеми процессорами. [14]
Exec поддерживает до 4095 приоритетов диспетчеризации, хотя большинство сайтов определяют только небольшое подмножество из них. Два самых высоких «приоритета» непереключаемы. Они распознают определенные типы обработки, которые должны быть разрешены для продолжения на процессоре, на котором они были запущены, пока они добровольно не откажутся от управления. Блокировка прерывания происходит при поступлении прерывания или в некоторых особых случаях, когда другой код Exec предотвращает все прерывания (чтобы изменить некоторые данные, к которым также может получить доступ обработчик прерываний).
Блокировка используется процедурами обработки прерываний, которые либо должны выполняться на том же физическом процессоре, либо просто не должны прерываться. Dispatcher, завершения ввода-вывода и инициирование ввода-вывода — вот некоторые примеры. Все блокировки, используемые обоими этими приоритетами, являются спин-блокировками, поскольку единственный способ, которым они могут быть установлены кем-то другим, — это другой процессор, а конструкция требует, чтобы они устанавливались только для очень коротких последовательностей инструкций.
Высокий приоритет Exec используется обработчиком команд оператора и некоторыми другими функциями, которые могут выполняться даже при управлении программой реального времени. Ожидается, что они будут использовать только очень короткие промежутки времени. Если им нужно больше времени, они должны поставить работу в очередь для обработки действием Low Exec.
Действия в реальном времени имеют неограниченный квант процессора и выполняются без переключения, если не прерываются более приоритетным действием в реальном времени или действием High Exec. Действия в реальном времени получают управление любым доступным процессором, который выполняет что-то с более низким приоритетом. Прерывания отправляются между процессорами, когда это необходимо для обеспечения немедленной доступности. Реальное время используется клиентами для запуска ракет, запуска симуляторов и других функций, требующих немедленного ответа.
Приоритеты транзакций могут обрабатываться двумя способами, как определено на сайте. Они могут быть своего рода более низким приоритетом в реальном времени, в котором важен только приоритет, а размер кванта по сути бесконечен. Это подходит для очень кратковременных транзакций, таких как бронирование авиабилетов; если одна из них зацикливается из-за ошибки программирования, Exec прервет ее, когда она достигнет своего очень маленького настроенного максимального времени. Другая форма позволяет Exec изменять приоритет в пределах диапазона для оптимизации использования системных ресурсов. Подход дает более высокий приоритет и более короткие временные интервалы программам, которые ограничены вводом-выводом, и постепенно более низкие приоритеты, но более длинные временные интервалы тем, которые выполняют вычисления. Exec динамически корректирует эти приоритеты на основе поведения, поскольку программы часто ведут себя обоими способами в разное время. Этот подход подходит для более длительных транзакций, таких как запросы к базе данных или котировки авиабилетов.
Пакетная обработка и обработка по требованию всегда используют динамически настраиваемые приоритеты. Программы, ограниченные вводом-выводом или находящиеся в диалоге с пользователем, работающим в режиме разделения времени, получают более высокие приоритеты, но короткие временные интервалы. Программы, ориентированные на вычисления, получают более низкие приоритеты и более длинные временные интервалы.
Exec имеет два дополнительных механизма для оптимизации диспетчеризации. Один из них — диспетчеризация на основе сродства. Когда это возможно, Exec будет запускать действие на том же процессоре, на котором оно было в прошлый раз, чтобы получить наибольшее преимущество от остаточного содержимого кэша. Если это невозможно, он пытается сохранить действие на «ближайшем» процессоре с точки зрения времени доступа к кэшу и памяти. Второй — механизм политики «справедливости». Сайт может определить относительный процент ресурсов, выделяемых для каждой из транзакций, спроса и пакета. Внутри транзакций и пакета существуют приоритетные группы, которые могут дополнительно указывать, какой процент времени их группы должен быть выделен для приоритета. Это гарантирует, что транзакции не смогут настолько доминировать в системе, что никакая пакетная работа не будет выполнена. Внутри различных приоритетных группировок это гарантирует, что некоторый прогресс может быть гарантирован для каждой группы (если только процент группы не равен нулю). Эти алгоритмы «справедливости» вступают в игру только тогда, когда процессоры очень заняты, но системы OS 2200 часто работают со всеми процессорами, загруженными почти на 100%.
OS 2200 поддерживает несколько моделей управления производительностью системы. [15] Клиенты могут приобрести определенный фиксированный уровень производительности, и Exec будет контролировать использование процессора, чтобы гарантировать, что производительность не превысит этот уровень. Клиенты также могут приобрести дополнительную производительность временно или постоянно до полной емкости системы, если их рабочая нагрузка увеличится или этого потребует чрезвычайная ситуация.
Совсем недавно система добавила возможность измеренного использования. В этом режиме полная мощность системы всегда доступна клиенту (хотя они могут административно ограничивать это). Использование накапливается в течение месяца, а затем отчет об использовании отправляется в счет Unisys. В зависимости от конкретных условий контракта клиент может получить счет за превышение некоторого контрактного базового уровня за месяц или просто выписку, показывающую, что общее контрактное использование было уменьшено. Первая форма похожа на счет за мобильный телефон с возможностью взимания платы за лишние минуты. Последняя похожа на покупку предоплаченной телефонной карты.
OS 2200 не имеет иерархической файловой системы , как большинство других операционных систем. Вместо этого она имеет структурированное соглашение об именовании и понятие файлов-контейнеров, называемых программными файлами.
Файлы в OS 2200 — это просто контейнеры, к которым можно обращаться либо по смещению слова в файле, либо по смещению сектора (28-словный блок) в файле. 28 слов — это историческая единица из раннего запоминающего устройства (барабан FASTRAND), которое могло вмещать 64 таких блока на физическую дорожку. Тем не менее, это удачная историческая случайность. Четыре таких 28-словных блока или 112 слов занимают 504 байта. Поскольку все современные запоминающие устройства используют 512-байтовые физические записи, клиенты OS 2200 почти все приняли кратные 112 словам в качестве размера физической записи и размера страницы базы данных. Процессоры ввода-вывода автоматически настраиваются на отображение 504<->512 байт, добавляя 8 байт нулей при записи и удаляя их при чтении каждой физической записи. OS 2200 обрабатывает приложения, которые используют размеры, отличные от кратных 112 слов, путем неделимого чтения содержащихся физических записей и записи обратно неизмененных и измененных частей с цепочкой данных. Специальные функции блокировки гарантируют неделимость даже при наличии ошибок устройств и в нескольких системах в кластере.
Форматы файлов и другие внутренние структуры данных описаны в Справочном руководстве по программированию структур данных . [16]
Начиная с Exec-8, имена файлов принимают форму: Квалификатор*Имя файла(f-цикл) (например, "PERSONNEL*EMPLOYEES(+1)"). [11] Квалификатор и имя файла — это просто строки из двенадцати символов, используемые для создания любой структуры именования, которую желает клиент. F-цикл — это число от 0 до 999, которое допускает несколько поколений файла. На них можно ссылаться с помощью относительных номеров: (+1) следующий или новый цикл, (-1) предыдущий цикл, (+0) текущий цикл. Если цикл не указан, по умолчанию используется текущий цикл. Этот подход используется в пакетных производственных запусках, создающих новые поколения файлов. Номера переходят после 999. Одновременно могут существовать только 32 последовательных относительных номера цикла. Создание (+1) удаляет (-31).
Любой файл может использоваться как программный файл. Программный файл содержит элементы, которые обычно действуют как файлы. Именование элементов — Квалификатор*Имя файла(f-цикл).Элемент/версия(e-цикл) (например, "PERSONNEL*PROGRAMS.TAXCALC/2008"). Элемент и версия — это двенадцатисимвольные имена, используемые любым способом, который пожелает пользователь. E-цикл похож на f-цикл в том, что он представляет номер поколения, но без ограничения в 32 параллельных цикла, а предел составляет 256 тыс. циклов. Однако e-цикл применяется только к текстовым элементам, и каждая строка в текстовом элементе помечается номерами циклов, в которых она была вставлена и удалена. Элементы также имеют тип и подтип. Наиболее часто используемые типы — "текст" и "объект". Если тип по умолчанию не подходит, параметры выбирают соответствующий тип. Текстовые элементы также имеют подтипы, которые обычно представляют язык программирования (например, "ASM", "C", "COB", "FOR"). Имя элемента объектного файла по умолчанию совпадает с именем текстового файла, из которого он был создан.
Элемент объекта может быть выполнен, если он является основной программой или связан с другими элементами объекта, включая основную программу. Связывание может быть статическим или динамическим. Основная программа может быть выполнена без предварительного связывания, если все требуемые подпрограммы находятся в одном и том же файле программы, являются системными библиотеками или иным образом известны. Правила могут быть включены в файл программы, чтобы направлять поиск динамическим компоновщиком невыполненных ссылок. Компоновщик также может использоваться для статического связывания нескольких модулей объекта вместе для формирования нового модуля объекта, содержащего все инструкции, данные и другую информацию в исходных модулях объекта.
Элементы Omnibus могут использоваться приложениями как данные или могут служить для хранения структурированной информации для приложений и системных утилит. Для элемента omnibus не существует предполагаемой структуры.
Для совместимости с более ранними моделями программирования (базовый режим) существуют перемещаемые и абсолютные типы элементов. Перемещаемые элементы являются выходными данными компиляторов базового режима. Они могут быть объединены статическим компоновщиком базового режима (@MAP – сборщик) для формирования «абсолютного» элемента, который является исполняемым.
OS 2200 реализует полностью виртуальную файловую систему. Файлы могут быть размещены в любом месте на любых устройствах хранения данных. Хранилище данных рассматривается как большой пул пространства, аналогично тому, как управляется виртуальная память. В то время как непрерывное пространство выделяется, если это возможно, хранилище данных рассматривается как набор страниц размером 8 КБ, и файл может быть размещен в любом количестве областей одного и того же или разных устройств, сколько требуется. Динамическое расширение файлов пытается выделить пространство, смежное с предыдущим выделением, но найдет место везде, где оно доступно. Фактически, файлы даже не обязательно должны присутствовать на устройстве хранения данных, чтобы их можно было использовать. Exec и система резервного копирования файлов полностью интегрированы. При создании резервных копий файлов номера катушек с лентой записываются в каталог файлов. Если на устройстве хранения данных не хватает места, некоторые файлы просто помечаются как «выгруженные», если у них есть текущая резервная копия, и их пространство доступно для использования. Если таким образом не удается найти достаточно места, запускается резервное копирование.
Любая ссылка на выгруженный файл будет поставлена в очередь, пока файл копируется обратно в хранилище. Вся система автоматическая и в целом прозрачна для пользователей. [17]
В общем, Exec не предоставляет методы доступа . Файлы — это просто контейнеры. Методы доступа предоставляются системами времени выполнения языка и менеджером базы данных. Единственным исключением является метод доступа с фиксированным блоком, предоставляемый для обработки транзакций большого объема. [18] Он имеет гораздо меньше накладных расходов, чем менеджер базы данных, но участвует во всех механизмах блокировки, кластеризации и восстановления.
Когда клиенты хотят более явного контроля над расположением файлов, они могут использовать концепцию «съемного пакета». Когда-то они действительно представляли собой физически съемные дисковые пакеты, и операционная система автоматически генерировала запросы на монтирование пакетов операторам по мере необходимости.
Сегодня они по-прежнему используются для размещения файлов, обычно файлов баз данных или файлов транзакций, на одном или нескольких дисковых томах. Файлы по-прежнему могут охватывать несколько дисковых томов, и теперь список имен томов указывается при создании файла. Файлы, находящиеся в таких группах томов, по-прежнему резервируются, но не подлежат автоматическому управлению виртуальным пространством.
OS 2200 также обеспечивает полную реализацию Common Internet File System ( CIFS ). [19] CIFS реализует протокол SMB, используемый серверами Microsoft и программным обеспечением UNIX/Linux Samba . 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. Это код и данные, которые могут совместно использоваться всеми программами, работающими в системе. [20] В OS 2200 каждая подсистема имеет свой собственный набор банков, которые находятся в отдельной части адресного пространства, к которому не может напрямую обращаться ни одна пользовательская программа. Вместо этого оборудование и ОС предоставляют «ворота», которые могут быть целью инструкции Call. Для получения дополнительной информации см. Архитектуру системы Unisys 2200 Series .
Менеджеры баз данных, библиотеки времени выполнения, система обмена сообщениями и многие другие системные функции реализованы как подсистемы. Некоторые подсистемы, обычно состоящие из чистого кода, такие как библиотеки времени выполнения, могут быть прямой целью инструкции Call без необходимости шлюза. Эти подсистемы работают в среде защиты пользовательской программы. Другие подсистемы, такие как менеджеры баз данных, состоят из кода и данных или привилегированного кода и могут быть вызваны только через шлюз. Эти подсистемы также могут иметь списки контроля доступа, связанные с ними, чтобы контролировать, кто может их вызывать. Что еще более важно, шлюз контролирует определенные точки входа, которые видны, среду защиты, в которой будет работать подсистема, и часто пользовательский параметр, который предоставляет дополнительную защищенную информацию о вызывающем.
Система безопасности OS 2200 разработана для защиты данных от несанкционированного доступа, модификации или раскрытия. Она включает реализацию спецификации уровня B1 DoD Orange Book . [21] OS 2200 впервые получила успешную оценку B1 в сентябре 1989 года. Эта оценка сохранялась до 1994 года. После этого момента разработчики OS 2200 продолжали следовать практикам разработки и документирования, требуемым оценкой B1.
Центральными для системы B1 являются концепции пользователей и объектов. [22] [23] Пользователи имеют идентификационные данные, уровни допуска, отсеки и привилегии. Объектам требуются определенные комбинации этих данных для различных типов доступа. Объекты в OS 2200 состоят из файлов, защищенных подсистем, устройств и катушек с лентой.
Профиль безопасности сеанса пользователя включает в себя идентификатор пользователя, уровень допуска (0-63), набор отсеков и набор разрешенных привилегий. OS 2200 реализует как обязательный контроль доступа (MAC), так и дискреционный контроль доступа (DAC) на основе модели Bell-La Padula для конфиденциальности (без чтения и записи) и модели целостности Biba (без чтения и записи). Для того чтобы запуск читал или выполнил файл, уровень допуска запуска должен быть больше или равен уровню допуска файла, а уровень допуска файла должен быть равен 0 или находиться в пределах диапазона уровней допуска запуска; кроме того, набор отсеков запуска должен содержать набор отсеков файла. Поскольку OS 2200 объединяет требования моделей Bell-La Padula и Biba, уровень допуска запуска и набор отсеков запуска должны точно соответствовать таковым файла, чтобы разрешить запись в файл или его удаление.
DAC связывает список контроля доступа с объектом; список идентифицирует пользователей и группы пользователей, которые имеют доступ, и определяет тип доступа, разрешенный пользователю или группе (чтение, запись, выполнение или удаление).
Поскольку полный набор элементов управления B1 слишком ограничителен для большинства сред, системные администраторы могут настраивать серверы, выбирая, какие элементы управления применять. Набор уровней безопасности от «Фундаментальной безопасности» до «Уровня безопасности 3» служит отправной точкой.
В каждой системе OS 2200 есть один пользователь, назначенный офицером безопасности. В системах, настроенных на базовую безопасность, только офицеру безопасности разрешено выполнять определенные задачи. В системах, настроенных на более высокие уровни безопасности, другим доверенным пользователям может быть разрешено выполнять некоторые из этих задач.
OS 2200 обеспечивает механизм безопасности с высокой степенью детализации, основанный на принципе наименьших привилегий . Этот принцип требует, чтобы предоставлялись только минимальные привилегии, необходимые для выполнения требуемой задачи. Таким образом, в OS 2200 нет концепции роли «Суперпользователя», которую может принять любой пользователь. Вместо этого она использует большой набор определенных привилегий, которые могут быть предоставлены каждому пользователю отдельно. Каждая привилегия связана с определенными полномочиями.
В системах, настроенных на уровень безопасности 1 или выше, пользователь, создающий объект, является владельцем объекта. По умолчанию объект является закрытым для создавшего его пользователя, но он также может быть публичным или контролироваться списком контроля доступа. Владелец или сотрудник службы безопасности может создать список контроля доступа для этого объекта.
В системе, настроенной с базовой безопасностью, файлы не имеют владельцев. Вместо этого они создаются как частные для учетной записи или проекта, или они являются публичными. Доступ к ним можно контролировать с помощью ключей чтения и записи.
При входе в систему пользователи идентифицируют себя и по желанию выбирают уровень допуска и набор отсеков, которые они будут использовать для этого сеанса.
OS 2200 предлагает гибкую систему аутентификации. Одновременно поддерживаются несколько механизмов аутентификации. Также может использоваться клиентское или стороннее программное обеспечение аутентификации. Стандартные возможности аутентификации включают:
Последние два допускают использование биометрии, смарт-карт и любых других механизмов аутентификации, поддерживаемых этими технологиями.
OS 2200 обеспечивает шифрование данных в состоянии покоя с помощью Cipher API, программной подсистемы, которая шифрует и расшифровывает данные вызывающего абонента. [24] Cipher API также поддерживает использование карты аппаратного ускорителя для массового шифрования данных.
Для серверов Dorado на базе CMOS CPComm обеспечивает шифрование SSL/TLS для данных в пути . Для серверов Dorado на базе Intel SSL и TLS предоставляются openSSL , который включен в прошивку Dorado. Все серверы Dorado поддерживают уровни TLS 1.0–1.2, а также SSLv3, но SSL по умолчанию отключен из-за уязвимостей в протоколе.
Оба API CPComm и Cipher используют службы шифрования CryptoLib, сертифицированного FIPS программного модуля шифрования. Алгоритмы AES и Triple DES входят в число алгоритмов, реализованных в CryptoLib.
OS 2200 также поддерживает шифрование ленточных накопителей, что обеспечивает шифрование архивных данных.
Системы OS 2200 могут быть объединены в кластер для достижения большей производительности и доступности, чем одна система. До 4 систем могут быть объединены в кластер, совместно используя базы данных и файлы через общие диски. Аппаратное устройство XPC-L обеспечивает координацию между системами, предоставляя высокоскоростной менеджер блокировки для доступа к базам данных и файлам. [25]
Кластерная среда позволяет каждой системе иметь собственные локальные файлы, базы данных и группы приложений вместе с общими файлами и одной или несколькими общими группами приложений. Локальные файлы и базы данных доступны только одной системе. Общие файлы и базы данных должны находиться на дисках, которые одновременно доступны всем системам в кластере.
XPC-L обеспечивает коммуникационный канал между системами для координации действий. Он также обеспечивает очень быстрый механизм блокировки. Подключение к XPC-L осуществляется через специальный процессор ввода-вывода, который работает с чрезвычайно малыми задержками. Менеджер блокировок в XPC-L обеспечивает все функции, необходимые для блокировки как файлов, так и баз данных. Это включает в себя обнаружение взаимоблокировок и возможность освобождения блокировок неисправных приложений.
XPC-L реализован с двумя физическими серверами для создания полностью избыточной конфигурации. Техническое обслуживание, включая загрузку новых версий прошивки XPC-L , может выполняться на одном из серверов, в то время как другой продолжает работать. Сбои, включая физическое повреждение одного сервера, не останавливают кластер, поскольку вся информация хранится на обоих серверах.
Операции OS 2200 строятся вокруг активных операторов и одной или нескольких консолей. Каждая консоль представляет собой терминальное окно, часть которого зарезервирована для фиксированного дисплея, который часто обновляется сводной информацией об активности в системе. [26]
Остальная часть консоли используется как прокручиваемый дисплей событий. Когда выдается сообщение, требующее ответа оператора, ему присваивается номер от 0 до 9, и оно остается на дисплее до тех пор, пока на него не ответят. Сообщения о монтировании ленты прокручиваются вместе с другими сообщениями, но будут повторяться каждые две минуты, пока лента не будет смонтирована.
Operations Sentinel используется для всех операций OS 2200. [27] Консоли OS 2200 — это просто окна на дисплее Operations Sentinel. Может быть столько ПК с дисплеем, сколько необходимо. Типичным является удаленное управление. Operations Sentinel поддерживает любое количество систем ClearPath, Windows, Linux и UNIX.
База данных сообщений автодействий выпускается вместе с продуктом. [28] Эта база данных позволяет Operations Sentinel распознавать сообщения. Могут быть написаны скрипты для автоматического реагирования на сообщения, требующие ответа, скрытия нежелательных сообщений, перевода их на другие языки, создания событий и т. д. Некоторые клиенты используют полную работу в темной комнате. В лучшем случае они будут иметь дисплеи Operations Sentinel в удаленных местах, контролирующие систему и создающие оповещения при возникновении определенных событий.
Администрирование систем OS 2200 осуществляется с использованием широкого спектра инструментов, каждый из которых специализирован для определенной области системы. Например, есть инструмент, используемый для администрирования среды транзакций, который позволяет устанавливать новые программы транзакций, указывает всю необходимую информацию о них, изменяет структуру очередей, приоритеты и уровни параллелизма и т. д. [29]
Другие инструменты предназначены только для сотрудников службы безопасности и позволяют создавать пользователей, изменять разрешенные привилегии, изменять настройки безопасности системы и т. д. [22] , [30] , [23]
Большинство инструментов имеют графический интерфейс, хотя некоторые его не имеют. Все они предоставляют интерфейс пакетного файла, где все действия указываются в потоке управления. Это позволяет создавать скрипты любых и всех административных интерфейсов либо с локальных сайтов, возможно, на основе времени суток или других событий, либо с удаленных сайтов. Для каждой административной области требуются уникальные привилегии.
Группы приложений представляют собой логическую конструкцию, состоящую из экземпляра Universal Data System (UDS), [31] экземпляра подсистемы очереди сообщений и некоторого набора транзакций. Каждая группа приложений имеет свой собственный аудиторский след. OS 2200 поддерживает максимум 16 групп приложений в системе.
Понятие группы приложений соответствует тому, что часто называют «приложением». То есть набору программ и данных, которые представляют собой некую более крупную единицу связанной обработки. Например, группа приложений может представлять систему авиакомпании. Другая группа приложений может представлять корпоративную финансовую систему. Или группы приложений могут представлять экземпляры одного и того же приложения и модели данных, как в банковских отделениях. Важно то, что каждая группа приложений имеет свою собственную среду, сеансы, восстановление и т. д.
Группы приложений можно запускать, останавливать и восстанавливать независимо друг от друга.
Группы приложений не имеют собственных правил учета и планирования. Транзакции в нескольких группах приложений могут иметь одинаковые приоритеты и чередоваться. Это позволяет сайту контролировать относительные приоритеты транзакций во всей системе.
Unisys History Newsletter содержит статьи об истории и компьютерах Unisys. В дополнение ко всем Unisys History Newsletters есть ссылки на другие сайты.
Большая часть исторических архивов Unisys находится в Институте Чарльза Бэббиджа в Университете Миннесоты и в Музее и библиотеке Хэгли в Делавэре. Институт Чарльза Бэббиджа хранит архивы ERA, некоторые ранние архивы Remington Rand из Сент-Пола, штат Миннесота, и архивы Берроуза. Музей и библиотека Хэгли хранит большую часть архивов Sperry.
Очень полезная вводная статья об ОС 2200 в 2020-х годах на сайте Arcane Sciences.