MCP ( Master Control Program) — это операционная система Burroughs B5000/B5500/B5700 и B6500, а также их преемников , включая системы Unisys Clearpath/MCP .
MCP был первоначально написан в 1961 году на языке ESPOL (Executive Systems Problem Oriented Language). В 1970-х годах MCP был преобразован в NEWP , который был лучше структурированной, более надежной и более безопасной формой ESPOL.
MCP был лидером во многих областях, включая: первую операционную систему для управления несколькими процессорами, первую коммерческую реализацию виртуальной памяти и первую ОС, написанную исключительно на языке высокого уровня .
В 1961 году MCP стала первой ОС, написанной исключительно на языке высокого уровня (HLL). Burroughs Large System ( B5000 [2] и последующие) были уникальны тем, что они были разработаны с расчетом на то, что все программное обеспечение, включая системное, будет написано на языке HLL, а не на ассемблере , что было уникальным и инновационным подходом в 1961 году.
В отличие от IBM, которая столкнулась с конкуренцией в области оборудования после ухода Джина Амдаля , программное обеспечение Burroughs работало только на оборудовании Burroughs из-за отсутствия совместимого стороннего оборудования. По этой причине Burroughs могла свободно распространять исходный код всего продаваемого ею программного обеспечения, включая MCP, который был разработан с учетом этой открытости. Например, обновление требовало от пользователя перекомпилировать системное программное обеспечение и применить любые необходимые локальные исправления. В то время это было обычной практикой и было необходимо, поскольку для клиентов (особенно крупных, таких как Федеральный резерв ) не было ничего необычного в том, чтобы изменять программу в соответствии со своими конкретными потребностями. [3] В результате была сформирована Группа пользователей Burroughs, которая проводила ежегодные встречи и позволяла пользователям обмениваться собственными расширениями для ОС и других частей системного программного пакета. Многие такие расширения нашли свое место в базовом коде ОС на протяжении многих лет и теперь доступны всем клиентам. Таким образом, MCP можно считать одним из самых ранних проектов с открытым исходным кодом .
Burroughs не был первым производителем, который распространял исходный код, и поздно вошел в сферу электронных вычислений (по сравнению со своими традиционными конкурентами NCR, IBM и Univac). Теперь, когда MCP работает на общедоступном оборудовании, некоторые элементы программного пакета на основе MCP больше не предоставляются в исходном виде компанией Unisys.
MCP была первой коммерческой ОС, которая предоставляла виртуальную память , которая поддерживалась архитектурой больших систем Burroughs с момента ее создания. Эта схема является уникальной в отрасли, поскольку она хранит и извлекает объекты, определенные компилятором, а не страницы памяти фиксированного размера, как следствие ее общей нефон-неймановской и однородно стековой архитектуры.
Дональд Кнут также оказал влияние в этот период, став консультантом Burroughs Corporation, присоединившись к отделу планирования продукции с 1960 по 1968 год. Он ссылается на «программу управления» (предположительно, MCP, которая тогда находилась в стадии разработки) в своей книге «Фундаментальные алгоритмы» в разделе 2.5 о динамическом распределении памяти . Кнут утверждает, что «метод «граничных тегов», представленный в разделе 2.5, был разработан автором в 1962 году для использования в программе управления для компьютера B5000». [4] : 460
Unisys прекратила производство оборудования в начале 2010-х годов, и операционная система теперь работает в режиме эмуляции. [5]
MCP предоставляет файловую систему с иерархическими структурами каталогов. В ранних реализациях MCP узлы каталогов были представлены отдельными файлами с записями каталогов, как и в других системах. Однако примерно с 1970 года MCP внутренне использует каталог «FLAT», в котором перечислены все пути файлов на томе. Это связано с тем, что открытие файлов путем посещения и открытия каждого каталога в пути файла было неэффективным, и для производственной среды было обнаружено, что лучше хранить все файлы в одном каталоге, даже если они сохраняют иерархическую схему именования. Программно это не имеет значения. Единственное различие, видимое пользователям, заключается в том, что файл сущности может иметь то же имя, что и каталог. Например, «A/B» и «A/B/C» могут существовать оба; «B» может быть как узлом в файле, так и каталогом.
Файлы хранятся на именованных томах, например, «this/is/a/filename on myvol», где «myvol» — имя тома. Это не зависит от устройства, так как диск, содержащий «myvol», можно перемещать или копировать на разные физические диски. Диски также можно объединять, чтобы один том можно было установить на нескольких дисках, а также зеркалировать для восстановления конфиденциальных данных. Для дополнительной гибкости каждая программа может выполнять замену томов, имя тома может быть заменено первичным и вторичным альтернативным именем. Это называется процессом «FAMILY». Например, назначение «FAMILY DISK = USERPACK OTHERWISE SYSPACK» сохраняет файлы, логически назначенные на томе DISK, на томе USERPACK и будет сначала искать файлы на томе USERPACK. Если этот поиск не увенчается успехом, другой поиск файла выполняется на томе SYSPACK. DISK — это имя тома по умолчанию, если ничего не указано.
Каждый файл в системе имеет набор атрибутов файла. Эти атрибуты записывают все виды метаданных о файле, наиболее важные из которых — его имя и тип (который сообщает системе, как обрабатывать файл, например, более ограниченный четырехсимвольный код типа файла на Macintosh ). Другие атрибуты содержат размер записи файла (если он фиксирован для коммерческих приложений), размер блока (в кратных записях, который сообщает MCP, сколько записей читать и записывать в одном физическом вводе-выводе) и размер области в кратных блоках, который дает размер областей диска, которые будут выделены по мере расширения файла.
Тип файла указывает, является ли файл символьными данными или исходным кодом, написанным на определенных языках, двоичными данными или файлами кода.
Файлы защищены обычными механизмами безопасности доступа, такими как общедоступный или закрытый, или файл может иметь защитный файл, в котором владелец может указать сложные правила безопасности.
Другим механизмом безопасности является то, что файлы кода могут быть созданы только доверенными компиляторами. Злонамеренные программисты не могут создать программу и назвать ее компилятором — программа может быть преобразована в компилятор только оператором с достаточными привилегиями с помощью команды оператора компилятора 'mc' make compiler.
MCP реализует журналируемую файловую систему , обеспечивающую отказоустойчивость в случае сбоя диска, отключения питания и т. д. Файловую систему невозможно повредить (за исключением случаев, когда это делает операционная система или другое доверенное системное программное обеспечение, имеющее прямой доступ к ее нижним уровням) [ необходима ссылка ] .
Файловая система нечувствительна к регистру и не сохраняет его, если только имя не заключено в кавычки. В противном случае система становится чувствительной к регистру и сохраняет его.
Процессы MCP называются « Работами » и « Задачами ». Работа содержит одну или несколько задач. Задачи в работе могут выполняться последовательно или параллельно. Логика может быть реализована на уровне работы, обычно на языке управления работой MCP WFL, для управления потоком работы. После завершения всех задач в работе сама работа завершается.
Процесс MCP проходит жизненный цикл с момента входа в систему до момента выхода из нее. Начальное состояние для задания — «В очереди». Существует период времени, в течение которого задание находится в одной из нескольких очередей заданий, определенных пользователем. Следующее состояние — «Запланировано», когда задание перемещается из очереди в память. Задачи в задании не ждут в очереди; вместо этого они сразу переходят в состояние «Запланировано» при инициировании. После запуска задания или задачи они могут переходить между состояниями «Активно», «Ожидание» и «Запланировано» по мере выполнения. После завершения задания или задачи они переходят в состояние «Завершено».
Запущенные процессы — это те, которые используют ресурс процессора и помечены как «запущенные». Процессы, которые готовы к назначению процессору, когда нет свободного процессора, помещаются в очередь готовности. Процессам может быть назначен приоритет «Объявленный» или «Видимый», обычно 50 по умолчанию, но может быть от 0 до 99 для пользовательских процессов. Системным процессам могут быть назначены более высокие значения. Обратите внимание, что этот числовой приоритет является вторичным по отношению к общему приоритету, который основан на типе задачи. Процессы, которые являются непосредственно частью операционной системы, называемые независимыми исполнителями, имеют наивысший приоритет независимо от числового значения приоритета. Далее идут процессы, использующие блокировку MCP, затем системы управления сообщениями, такие как CANDE . Затем прекращенные процессы. Затем задания языка рабочего потока. Наконец, идут пользовательские процессы. На более низком уровне есть приоритет Fine, предназначенный для повышения приоритета задач, которые не используют весь свой процессорный срез. Это позволяет задаче, связанной с вводом-выводом, получить процессорное время раньше задачи, связанной с процессором, с тем же объявленным приоритетом.
Процессы, ожидающие другие ресурсы, такие как чтение файла, ждут структуру данных EVENT . Таким образом, все процессы, ожидающие один ресурс, ждут одного события. Когда ресурс становится доступным, вызывается событие, которое пробуждает все процессы, ожидающие его. Процессы могут ожидать несколько событий, пока не произойдет любое из них, включая тайм-аут. События полностью программируются пользователем, то есть пользователи могут писать системы, которые используют обобщенную систему событий, предоставляемую MCP.
Процессы, которые были завершены, помечаются как завершенные.
С точки зрения эксплуатации, статус всех задач в системе отображается оператору. Все запущенные и готовые процессы отображаются как «активные» задачи (поскольку система реализует вытесняющую многозадачность , переход от состояния готовности к состоянию выполнения и обратно происходит настолько быстро, что разделение готовых и запущенных задач бессмысленно, поскольку все они получат часть процессора в течение секунды). Все активные задачи можно отобразить с помощью команды «A».
Завершенные задачи отображаются как завершенные задачи с указанием причины завершения, EOT для обычного «завершения задачи» и DSed с указанием причины сбоя процесса. Всем процессам присваивается смешанный номер, и операторы могут использовать этот номер для идентификации процесса для управления. Одной из таких команд является команда DS (которая обозначает Delete from Schedule, DiScontinue или Deep Six, в соответствии с влиянием военно-морского персонала на ранние компьютерные проекты, в зависимости от того, с кем вы общаетесь). Задачи, завершенные оператором, перечислены в полных записях как O-DS.
Задачи также могут быть завершены из-за ошибок программы, отмеченных как F-DS или P-DS, таких как недопустимый индекс , числовое переполнение и т. д. Оператор может вывести список завершенных записей с помощью команды «C».
Задачи, ожидающие на ресурсе, перечислены под записями ожидания и причиной ожидания. Все ожидающие задачи могут быть перечислены с помощью команды «W». Причина ожидания также указана, и дополнительная информация о задаче может быть получена с помощью команды «Y». Может быть, задача ожидает ввода оператора, который отправляется задаче с помощью команды accept «AX» (обратите внимание, что ввод оператора сильно отличается от ввода пользователя, который был бы вводом с сетевого устройства с графическим интерфейсом).
Задачи, ожидающие ввода пользователя или чтения файла, обычно не будут перечислены как ожидающие записи для внимания оператора. Другая причина, по которой задача находится в состоянии ожидания, — это ожидание файла. Когда процесс открывает файл, а файл отсутствует, задача помещается в ожидающие записи, отмечая, что она ожидает определенный файл. Оператор (или пользователь, владеющий процессом) имеет возможность либо скопировать файл в ожидаемое место, либо перенаправить задачу на чтение файла из другого места, или файл может быть даже создан независимым процессом, который еще не завершен.
Если ресурс не может быть предоставлен оператором, оператор может DS задачи в качестве последнего средства. Это отличается от других систем, которые автоматически завершают задачу, когда ресурс, такой как файл, недоступен. MCP обеспечивает этот уровень восстанавливаемости задач оператором. Другие системы заставляют программистов добавлять код для проверки наличия файлов перед доступом к ним, и, таким образом, дополнительный код должен быть написан в каждом случае для обеспечения восстанавливаемости или синхронизации процессов. Такой код может быть написан в программе MCP, когда нежелательно, чтобы задача ждала, но из-за восстанавливаемости на уровне оператора это не принудительно и, следовательно, делает программирование намного проще.
В дополнение к возможности динамически переназначать запросы файлов (или баз данных) на другие файлы (или базы данных) до или во время выполнения программы, доступно несколько механизмов, позволяющих программистам обнаруживать и устранять ошибки. Один из способов, оператор 'ON', существует уже много лет. Можно перечислить конкретные ошибки (например, деление на ноль) или можно использовать универсальный 'anyfault'. Оператор или блок, следующий за оператором 'ON', распознается компилятором как код обработки ошибок. Во время выполнения, если в области действия оператора 'on' возникает исправимая ошибка, стек урезается, и управление передается оператору, следующему за ним.
Одной из проблем с логикой обработки, лежащей в основе оператора ON, было то, что он вызывался только для сбоев программы, а не для завершений программы по другим причинам. Со временем потребность в гарантированной обработке ненормальных завершений росла. В частности, требовался механизм, позволяющий программам вызывать плагины, написанные клиентами или третьими лицами, без какого-либо риска, если плагин будет вести себя плохо. В дополнение к общим механизмам плагинов, новая форма динамической компоновки библиотек (библиотеки подключений) позволяет программам импортировать и экспортировать функции и данные, и, следовательно, одна программа запускает код, предоставленный другой.
Для достижения такой усиленной защиты в середине 1990-х годов был введен новый механизм. В ошибочной попытке совместимости он был назван в честь тогда предложенной конструкции языка C++ с тем же именем. Поскольку синтаксис и поведение этих двух конструкций различаются в такой большой степени, выбор одного и того же имени привел только к путанице и недоразумениям.
Синтаксически операторы 'try' выглядят как операторы 'if': 'try', за которым следует оператор или блок, за которым следует 'else' и еще один оператор или блок. За первым могут следовать дополнительные операторы 'else'. Во время выполнения, если в коде, следующем за оператором 'try', происходит какое-либо восстанавливаемое завершение, стек урезается, если это необходимо, и управление переходит к коду, следующему за первым 'else'. Кроме того, устанавливаются атрибуты, позволяющие программе определять, что и где произошло (включая конкретный номер строки).
Большинство событий, которые могут привести к завершению задачи, можно восстановить. Это включает переполнение стека, доступ за пределами массива, переполнение/недополнение целочисленного значения и т. д. DS оператора (или пользователя) не может быть восстановлен, за исключением привилегированных задач, использующих НЕБЕЗОПАСНУЮ форму try.
Таким образом, MCP обеспечивает очень отказоустойчивую среду, а не аварийный сброс ядра, как в других системах.
Как и атрибуты файлов, задачи также имеют атрибуты, такие как приоритет задачи (который назначается во время компиляции или выполнения, или может быть изменен во время выполнения задачи), процессорное время, время ожидания, статус и т. д. К этим атрибутам задачи можно получить программный доступ, как и к атрибутам файлов. Родительская задача доступна программно как атрибут задачи, который имеет тип task. Например, 'myself.initiator.name' дает имя процесса, который инициировал текущий процесс.
GETSPACEи FORGETSPACEявляются двумя основными процедурами, обрабатывающими выделение и освобождение памяти. Память должна быть выделена при инициализации процесса и всякий раз, когда вводится блок, использующий массивы, файлы и т. д., GETSPACEи FORGETSPACEне только обрабатывают пространство памяти, они также выделяют или освобождают дисковое пространство, где могут быть наложены нерезидентные данные памяти. Память может быть SAVE (т. е. резидентной памятью), OVERLAYABLE (т. е. виртуальной памятью) или STICKY (т. е. резидентной памятью, но перемещаемой). Они вызываются, например HARDWAREINTERRUPT, когда процесс обращается к неинициализированному массиву или FILEOPEN.
HARDWAREINTERRUPTобрабатывает аппаратные прерывания и может вызывать GETSPACE, IO_FINISHили тому подобное.
BLOCKEXITвызывается задачей, выходящей из блока. BLOCKEXIT может в свою очередь вызвать FILECLOSEили FORGETSPACEчто-то подобное, очищая и освобождая ресурсы, объявленные и используемые в этом блоке.
J_EDGAR_HOOVER — главный страж безопасности системы, вызываемый при запуске процесса, открытии файла, входе пользователя в систему и т. д.
GEORGE— это процедура, которая решает, какой процесс следующим получит ресурсы ЦП, и, таким образом, является одним из немногих процессов, использующих инструкцию MoveStack.
Задача проходит через различные состояния, начиная с NASCENT. При DELIVERY вызывается событие BIRTH, и состояние задачи меняется на ALIVE. При вызове PROCESSKILL состояние меняется на DISEASED. При вызове DEATH задача помещается в очередь MORGUE, после чего все оставшиеся ресурсы освобождаются для системы процессом PROCESSKILL.
Пока задача ALIVE, функции MCP выполняются поверх этого конкретного процесса, таким образом, ресурсы ЦП автоматически зачисляются на задачу, вызывающую накладные расходы MCP. Кроме того, большая часть работы MCP выполняется с правами безопасности этого конкретного стека. Только до BIRTH и после DEATH MCP необходимо работать из какого-то другого стека. Если ни один из них не доступен, система поддерживает простаивающий стек.
Библиотеки MCP предоставляют способ совместного использования данных и кода между процессами. Статья о больших системах Burroughs рассматривает способ асинхронного запуска зависимых процессов, чтобы многие процессы могли совместно использовать общие данные (с механизмами для обеспечения синхронизированного обновления). Такое семейство связанных процессов должно было быть написано как единый программный блок, обрабатывающий процедуры на более высоких уровнях лекса как асинхронные процессы, которые все еще могли бы получать доступ к глобальным переменным и другим переменным на более низких уровнях лекса.
Библиотеки полностью перевернули этот сценарий, получив следующие преимущества:
Механизм библиотеки был настолько чистым и радикальным, что значительная часть системного программного обеспечения подверглась существенной переработке, что привело к улучшению структуры системы и повышению производительности.
Библиотеки были введены в системы MCP в начале 1980-х годов, разработанные Роем Гаком и другими в Burroughs . Они очень похожи на мониторы CAR Hoare и предоставляют возможность для контролируемого взаимного исключения и синхронизации между клиентскими процессами, используя MCP EVENTs и технику блокировки Dahm. Библиотеки предлагают процедурные точки входа для клиента, которые проверяются на совместимость интерфейса (проверяются все параметры и возвращаемые типы импортированных процедур) до того, как клиент будет связан с библиотекой. Библиотека и ее клиент могут быть написаны на разных языках. Преимущество в том, что вся синхронизация обеспечивается в библиотеке, и клиентскому коду вообще не нужно беспокоиться об этом уровне программирования. Это приводит к надежному коду, поскольку клиенты не могут подорвать код синхронизации в библиотеке. (Некоторые назвали бы это « Инициативой доверенных вычислений ».)
Библиотеки — это более сложные формы библиотек в других системах, такие как DLL . Библиотеки MCP могут быть «общими для всех», «общими для rununit» или «частными». Частный случай ближе всего к библиотекам в других системах — для каждого клиента вызывается отдельная копия библиотеки, и нет обмена данными между процессами.
Общий для всех интереснее. Когда клиент запускается, он может работать некоторое время, пока ему не потребуются службы в библиотеке. При первом обращении к точке входа библиотеки инициируется связывание. Если экземпляр библиотеки уже запущен, клиент затем связывается с этим экземпляром библиотеки. Все клиенты совместно используют один и тот же экземпляр.
Shared by rununit — это механизм совместного использования между этими двумя схемами совместного использования. Он был разработан специально для COBOL, где rununit определяется как исходная инициирующая клиентская программа и все библиотеки, с которыми она связана. Каждый rununit получает один экземпляр библиотеки, а разные rununit получают другой экземпляр. Это единственная динамическая реализация COBOL rununit.
Если это был первый вызов библиотеки, библиотека запускала свою основную программу (внешний блок в программе ALGOL) для инициализации своей глобальной среды. После завершения инициализации она выполняла заморозку, в которой все экспортированные точки входа становились доступными клиентам. В этой точке стек библиотеки считался замороженным, поскольку в этом стеке больше ничего не запускалось, пока библиотека не разморозилась, в этом случае запускался код очистки и завершения. Когда клиент вызывает процедуру в библиотеке, эта процедура запускается поверх клиентского стека, сохраняя там свои локальные и временные переменные. Это позволяет многим клиентам одновременно запускать одну и ту же процедуру, синхронизируясь с библиотечной процедурой, которая обращается к данным в глобальной среде стека библиотеки.
Заморозка также могла быть трех видов — временная, постоянная и контролируемая. Временная означала, что как только количество клиентов падало до нуля, библиотека размораживалась и прекращала работу. Постоянная означала, что библиотека оставалась доступной для дальнейших клиентов, даже если количество клиентов падало до нуля — постоянные библиотеки могли быть разморожены оператором с помощью команды THAW. Контролируемая заморозка означала, что библиотека фактически продолжала работать, так что она могла выполнять функции мониторинга и выполнять функции инициализации и очистки данных для каждого подключаемого клиента.
Библиотеки также можно было получить «по названию» и «по функции». В «по названию» клиент указывал имя файла библиотеки. «По функции» был косвенным методом, при котором клиент просто указывал имя функции библиотеки, например «system_support», а фактическое расположение библиотеки находилось в таблице, предварительно созданной оператором с помощью команд «SL» (системная библиотека), например «SL system_support = *system/library/support». Отказоустойчивое отношение MCP также работает здесь — если клиент пытается получить доступ к библиотеке, которая отсутствует, клиент помещается в «ожидающие» задачи, и библиотеку можно было сделать присутствующей, или запрос перенаправить.
Библиотеки также можно обновлять на лету, все, что нужно сделать, это 'SL' новой версии. Работающие клиенты будут продолжать использовать старую версию до тех пор, пока не прекратят работу, а новые клиенты будут перенаправлены на новую версию.
Библиотеки функций также реализовали очень важную функцию безопасности — классы связей. Все обычные библиотеки имеют класс связей, равный нулю. Библиотеки, используемые MCP или другими привилегированными системными модулями, могут быть недоступны для использования из обычных программ. К ним обращается функция и принудительно устанавливается в классе связей один. Клиент в классе связей ноль не может ссылаться на точки входа класса связей один. Библиотека с классом связей один, которой необходимо предлагать точки входа обычным программам, может это сделать, если она обозначена как «доверенная». Она может предлагать выбранные точки входа в классе связей ноль.
Вся система базы данных реализована с библиотеками, обеспечивающими очень эффективный и индивидуальный доступ к базам данных, совместно используемым многими клиентами. То же самое касается всех сетевых функций и внутренних систем.
В середине 1990-х годов появился новый тип библиотеки: библиотеки подключений. Это программы, которые могут выполняться независимо, а также импортировать и экспортировать данные и функции в другие программы в массивах структурных блоков. Например, сетевой компонент операционной системы доступен как библиотека подключений, что позволяет другим программам использовать ее службы путем экспорта и импорта функций. После связывания каждый клиент получает выделенный структурный блок для хранения информации о состоянии. Программа, использующая сеть, может импортировать функцию сетевой записи и экспортировать функцию сетевого чтения. Таким образом, если вы открываете сетевое соединение (например, с помощью TCP ), когда данные поступают для чтения, сетевой компонент может напрямую вызвать вашу функцию для их использования, без необходимости предварительного копирования данных в буфер и переключения контекста. Аналогично, вы можете записывать данные в сеть, напрямую вызывая функцию сетевой записи.
Библиотеки соединений позволяют в значительной степени контролировать связи. Каждая сторона связи может опционально одобрить связь и может разорвать связь по желанию. Состояние может легко поддерживаться как для каждой связи, так и глобально.
Другой метод межпроцессного взаимодействия (IPC) — файлы портов. Они похожи на Unix-конвейеры , за исключением того, что они обобщены как многоканальные и двунаправленные. Поскольку они на порядок медленнее других методов IPC, таких как библиотеки, лучше использовать другие методы, где IPC происходит между разными процессами на одной машине.
Поэтому наиболее выгодное использование файлов портов — для распределенного IPC. Файлы портов были введены с BNA (Burroughs Network Architecture), но с появлением стандартных сетевых технологий, таких как OSI и TCP / IP , файлы портов можно использовать и с этими сетями.
Сервер, прослушивающий входящие соединения, объявляет файл порта (файл с атрибутом KIND, равным PORT). Каждое соединение, которое выполняется от клиента, создает подфайл с индексом, поэтому каждый файл порта представляет несколько соединений с разными клиентами по всей сети.
Серверный процесс получает клиентские запросы из любой точки сети, выдавая чтение в файле порта (subfile = 0 для чтения из любого подфайла). Он выдает ответ клиенту, выдавшему запрос, записывая в конкретный подфайл, из которого был прочитан запрос.
MCP также обеспечивает сложную, но простую среду оператора. Для крупных установок может потребоваться, чтобы многие операторы обеспечивали доступ к физическим ресурсам, таким как принтеры (загрузка бумаги, картриджей с тонером и т. д.). Низкоуровневые среды для небольших офисов или одного пользователя могут потребовать среду без оператора (особенно реализация на ноутбуке).
Большие системы имеют выделенные операционные терминалы, называемые ODT (Operator Display Terminals), которые обычно находятся в безопасной среде. Для небольших систем машины могут управляться с любого терминала (при условии, что терминал и пользователь имеют достаточные привилегии) с помощью программы MARC (Menu Assisted Resource Control). Команды оператора также могут использоваться пользователями, знакомыми с ними.
Команды оператора в основном состоят из двух букв (как в Unix), а некоторые — из одной. Это означает, что интерфейс оператора нужно изучить, но он очень эффективен для опытных операторов, которые ежедневно управляют большой мэйнфреймовой системой. Команды нечувствительны к регистру.
Задачи вводятся в программу «mix» и идентифицируются номерами mix, как и библиотеки. Для выполнения программы операторы могут использовать команду «EX» или «RUN», за которой следует имя файла программы. ODT обычно запускаются с ADM (автоматический режим отображения), который представляет собой настраиваемое отображение состояния системы, обычно настроенное для отображения активных, ожидающих и завершенных записей mix, а также системных сообщений оператору для уведомлений или ситуаций, требующих действий оператора.
Полный список этих дисплеев представлен в виде «A» (активно), «W» (ожидание), «C» (завершено) и «MSG» (команды сообщений).
Если задача ожидает какого-либо действия оператора, оператор может узнать, что требуется задаче, введя ее номер смеси, а затем команду «Y». (Обратите внимание на объектно-ориентированный стиль команд, когда сначала выбирается объект, а затем команда.) Например, «3456Y».
Оператор может принудительно перевести задачу в ожидающие записи с помощью команды остановки '3456ST' и снова сделать ее активной с помощью OK: '3456OK'. Команда OK также может использоваться, когда оператор сделал ресурс доступным для задачи, хотя чаще всего MCP обнаруживает, что ресурсы стали доступны, ВЫЗЫВАЕТ СОБЫТИЕ, которого ожидали процессы без дальнейшего вмешательства оператора. Для передачи текстовой информации от оператора в программу можно использовать команду приема '3456AX MORE INFO'. Программы могут передавать информацию операторам с помощью механизма DISPLAY, который заставляет сообщения DISPLAY добавляться на дисплей MSG.
Помимо задач и процессов, операторы также имеют контроль над файлами. Файлы можно перечислять с помощью команды FILE, копировать с помощью COPY, удалять с помощью REMOVE и переименовывать.
Операционная среда MCP мощная, но простая и обычно требует лишь незначительного числа операторов по сравнению с другими системами.
Важной частью операционной среды является высокоуровневый язык рабочего процесса .
Все действия в системе регистрируются, например, все сообщения, отображаемые оператору, и все действия оператора. Все значимые действия программы опционально регистрируются в системном журнале и журнале программы, например, BOJ для начала задания WFL, BOT для начала задачи в задании WFL, EOT и EOJ для завершения задач и заданий. Также могут быть зарегистрированы все открытия и закрытия файлов и баз данных. Регистрация множества событий приводит к кажущейся замедленности операционной среды MCP по сравнению с такими системами, как Unix, поскольку все регистрируется с принудительными физическими записями в журнал программы после каждой записи, чего не делают такие системы, как Unix, хотя они тоже хранят много вещей в системных журналах.
Журналы могут использоваться для криминалистики, чтобы выяснить, почему программы или системы могли выйти из строя, или для обнаружения попыток взлома безопасности системы. Системные журналы автоматически закрываются после установленного системой периода и открываются новые. Системные журналы содержат огромное количество информации, которую можно фильтровать и анализировать с помощью таких программ, как LOGANALYZER.
DUMPANALYZER анализирует дампы памяти, которые изначально были записаны на ленту. Поскольку все компиляторы добавляли LINEINFO в файлы кода, DUMPANALYZER может точно определить, какой исходный оператор выполнялся в момент ошибки.
Кроме того, обычный дамп программы, в котором была сохранена только одна программа, содержит информацию о порядковом номере исходного кода и именах переменных.
Оба анализатора являются основными диагностическими инструментами для самых разных целей.
Помимо множества технических инноваций в конструкции MCP, Burroughs Large Systems имела много инноваций в управлении, которые теперь используются интернет-сообществом в целом. Системное программное обеспечение поставлялось клиентам, включая исходный код и все инструменты редактирования и компиляции, необходимые для создания новых версий MCP для клиентов. Многие клиенты разработали узкоспециализированные знания о внутренней работе MCP, и клиенты часто отправляли «патчи» (фрагменты исходного кода с порядковыми номерами) в качестве предложений новых расширенных функций или исправлений неисправностей (FTR — полевые отчеты о неполадках). Многие из предложенных патчей были включены разработчиками систем и интегрированы в следующую версию выпуска MCP. Включение сообщества добровольных, самопровозглашенных экспертов в основную техническую работу в настоящее время широко практикуется и является сутью открытых инноваций . Это управленческое новшество развития сообщества датируется 1970-ми годами.
За свою историю Unisys MCP имел несколько поколений компиляторов, поддерживающих широкий спектр языков программирования , включая:
Другие продукты включают в себя:
Ранее существовали компиляторы для ESPOL , COBOL(68), Fortran(66), APL и PL/I .
В операционной системе Unisys MCP ассемблера нет.
MCP была первой ОС, разработанной исключительно на языке высокого уровня. За свою 50-летнюю историю она имела много первых в коммерческой реализации, включая виртуальную память, симметричную многопроцессорную обработку и язык управления заданиями высокого уровня (WFL). Она давно имела много возможностей, которые только сейчас [ когда? ] появляются в других распространенных операционных системах, и вместе с архитектурой больших систем Burroughs MCP обеспечивает очень безопасную [ слова-ласка ] , высокопроизводительную, многозадачную и транзакционную среду обработки.