Берроуз MCP - Википедия - Burroughs MCP

В MCP (Master Control Program) - это проприетарный Операционная система из Берроуз малые, средние и большие системы, включая Unisys Clearpath / MCP системы.

MCP был первоначально написан в 1961 году в ESPOL (Язык программирования исполнительных систем). В 1970-х годах MCP был преобразован в NEWP которая была лучше структурированной, более надежной и безопасной формой ESPOL.

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

История

В 1961 году MCP была первой ОС, написанной исключительно на язык высокого уровня (HLL). В Большая система Берроуза (B5000^[2] и его преемники) были уникальны тем, что они были разработаны с ожиданием, что все программное обеспечение, включая системное программное обеспечение, будет написано на HLL, а не на язык ассемблера, что было уникальным и новаторским подходом в 1961 году.

В отличие от IBM, которая столкнулась с конкуренцией за оборудование после ухода Джин Амдал, Программное обеспечение Burroughs было разработано для работы только на проприетарном оборудовании. По этой причине Burroughs мог свободно распространять исходный код всего проданного ею программного обеспечения, включая MCP, который был разработан с учетом этой открытости. Например, обновление потребовало от пользователя перекомпиляции системного программного обеспечения и применения любых необходимых локальных исправлений. В то время это было обычной практикой и было необходимо, поскольку в этом не было ничего необычного для клиентов (особенно крупных, таких как Федеральный резерв ), чтобы изменить программу в соответствии со своими потребностями.^[3] В результате была сформирована группа пользователей Burroughs, которая проводила ежегодные собрания и позволяла пользователям обмениваться собственными расширениями ОС и другими частями системного программного обеспечения. Многие такие расширения внедрились в код базовой ОС за прошедшие годы и теперь доступны всем клиентам. Таким образом, MCP можно считать одним из первых Открытый исходный код проекты.

Burroughs не был первым производителем, распространявшим исходный код, и поздно вошел в электронные вычисления (по сравнению со своими традиционными конкурентами NCR, IBM и Univac). Теперь, когда MCP работает на стандартном оборудовании, некоторые элементы программного пакета на основе MCP больше не предоставляются Unisys в виде исходного кода.

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

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

MCP обеспечивает файловая система с иерархической структурой каталогов. В ранних реализациях MCP каталог узлы были представлены отдельными файлами с записями каталогов, как и другие системы. Однако примерно с 1970 года MCP внутренне использует каталог «FLAT», в котором перечислены все пути к файлам на томе. Это связано с тем, что открытие файлов путем посещения и открытия каждого каталога в пути к файлу было неэффективным, и для производственной среды было обнаружено, что лучше хранить все файлы в одном каталоге, даже если они сохраняют иерархическую схему именования. Программно это не имеет значения. Единственное различие, видимое пользователям, состоит в том, что файл объекта может иметь то же имя, что и каталог. Например, "A / B" и "A / B / C" могут существовать оба; «B» может быть как узлом в файле, так и каталогом.

Файлы хранятся на именованных томах, например «this / is / a / filename на myvol», «myvol» - это имя тома. Это не зависит от устройства, поскольку диск, содержащий myvol, можно перемещать или копировать на другие физические диски. Диски также могут быть объединены, чтобы один том можно было установить на нескольких дисках, а также создать зеркальное отображение для восстановления конфиденциальных данных. Для дополнительной гибкости каждая программа может выполнять замену тома, имя тома может быть заменено основным и дополнительным альтернативным именем. Это называется СЕМЬЕЙ процесса. Например, назначение «FAMILY DISK = USERPACK OTHERWISE SYSPACK» сохраняет файлы, логически назначенные на томе DISK, на том USERPACK и сначала будет искать файлы на томе USERPACK. Если этот поиск не увенчается успехом, выполняется еще один поиск файла на томе SYSPACK. DISK - это имя тома по умолчанию, если оно не указано.

Каждый файл в системе имеет набор атрибутов файла. Эти атрибуты записывают все виды метаданные о файле, наиболее важно его имя и его тип (который сообщает системе, как обрабатывать файл, например, более ограниченный четырехсимвольный код типа файла на Macintosh ). Другие атрибуты включают размер записи файла (если он установлен для коммерческих приложений), размер блока (кратный количеству записей, который сообщает MCP, сколько записей нужно читать и записывать в одном физическом вводе-выводе) и размер области, кратный блокам, которые дает размер дисковых областей, которые будут выделяться при расширении файла.

Тип файла указывает, является ли файл символьными данными или исходным кодом, написанным на определенных языках, двоичными данными или файлами кода.

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

Другой механизм безопасности заключается в том, что файлы кода могут быть созданы только надежными компиляторами. Вредоносные программисты не могут создать программу и назвать ее компилятором - программа может быть преобразована в компилятор только оператором с достаточными привилегиями с помощью команды оператора make compiler 'mc'.

MCP реализует Файловая система журналирования, обеспечивающая отказоустойчивость в случае отказа диска, потери питания и т. д. Невозможно повредить файловую систему (кроме как операционной системой или другим доверенным системным программным обеспечением с прямым доступом к его нижним уровням)^{[нужна цитата ]}.

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

Управление процессом

MCP процессы называются "Вакансии " и "Задачи. "Задание содержит одну или несколько задач. Задачи в рамках задания могут выполняться последовательно или параллельно. Логика может быть реализована на уровне задания, обычно на языке управления заданиями WFL MCP, для управления потоком задания. После того, как все задачи в работе завершены, сама работа завершена.

Процесс MCP проходит жизненный цикл с момента его входа в систему до момента выхода. Начальное состояние задания - «В очереди». Существует период времени, в течение которого задание находится в одной из нескольких пользовательских очередей заданий. Следующее состояние - «Запланировано», когда задание перемещается из очереди в память. Задачи внутри задания не ждут в очереди; вместо этого переход непосредственно в состояние «Запланировано» при запуске. Как только задание или задача запущены, они могут переключаться между «Активным», «Ожиданием» и «Запланированным» по мере выполнения. Когда задание или задача завершены, они переходят в состояние «Завершено».

Запущенные процессы - это те, которые используют ресурс процессора и помечены как «запущенные». Процессы, готовые к назначению процессору при отсутствии свободного процессора, помещаются в очередь готовности. Процессам может быть назначен приоритет «Объявленный» или «Видимый», обычно 50 по умолчанию, но может быть от 0 до 99 для пользовательских процессов. Системным процессам могут быть присвоены более высокие значения. Обратите внимание, что этот числовой приоритет вторичен по сравнению с общим приоритетом, который зависит от типа задачи. Процессы, которые являются непосредственно частью операционной системы, называемые независимыми исполнителями, имеют наивысший приоритет независимо от числового значения приоритета. Далее следуют процессы, использующие блокировку MCP, затем системы управления сообщениями, такие как КАНДА. Потом прекращенные процессы. Затем вакансии Work Flow Language. И, наконец, пользовательские процессы. На более низком уровне есть приоритет Fine, предназначенный для повышения приоритета задач, которые не используют весь свой сектор процессора. Это позволяет задаче с привязкой к вводу-выводу опережать время процессора над задачей, привязанной к процессору, с тем же объявленным приоритетом.

Процессы, ожидающие других ресурсов, таких как чтение файла, ожидают СОБЫТИЯ структура данных. Таким образом, все процессы, ожидающие одного ресурса, ждут одного события. Когда ресурс становится доступным, вызывается событие, которое пробуждает все ожидающие его процессы. Процессы могут ожидать нескольких событий, пока не произойдет одно из них, включая тайм-аут. События полностью программируются пользователем, то есть пользователи могут создавать системы, использующие обобщенную систему событий, предоставляемую MCP.

Завершенные процессы помечаются как завершенные.

В оперативном режиме оператору отображается статус всех задач в системе. Все запущенные и готовые процессы отображаются как «Активные» задачи (поскольку в системе реализованы вытесняющая многозадачность, переход от готовности к работе и обратно происходит настолько быстро, что различать готовые и выполняющиеся задачи бессмысленно, потому что все они получат часть процессора в течение секунды). Все активные задачи можно отобразить с помощью команды «А».

Завершенные задачи отображаются как завершенные задачи с указанием причины завершения, EOT для обычного «завершения задачи» и DSed с причиной сбоя процесса. Всем процессам присваивается смешанный номер, и операторы могут использовать этот номер для идентификации процесса, которым нужно управлять. Одной из таких команд является команда DS (которая расшифровывается как «Удалить из расписания», «DiScontinue» или «Deep Six», после влияния персонала ВМФ на ранние компьютерные проекты, в зависимости от того, с кем вы разговариваете). Задачи, завершенные оператором, перечислены в полных записях как O-DS.

Задачи также могут завершаться из-за ошибок программы, отмеченных как F-DS или P-DS, для таких ошибок, как неверный индекс, числовое переполнение и т. д. Завершенные записи могут быть перечислены оператором с помощью команды «C».

Задачи, ожидающие на ресурсе, перечислены под записями об ожидании и причиной ожидания. Все ожидающие задачи могут быть перечислены с помощью команды «W». Причина ожидания также указана, и дополнительную информацию о задаче можно увидеть с помощью команды «Y». Возможно, задача ожидает ввода оператора, который отправляется задаче с помощью команды accept 'AX' (обратите внимание, что ввод оператора сильно отличается от ввода пользователя, который будет вводиться с сетевого устройства с интерфейсом GUI) .

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

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

Помимо возможности динамического переназначения запросов файла (или базы данных) на другие файлы (или базы данных) до или во время выполнения программы, доступны несколько механизмов, позволяющих программистам обнаруживать ошибки и восстанавливаться после них. Один из способов, заявление «ON», существует уже много лет. Можно перечислить конкретные ошибки (например, разделить на ноль) или использовать универсальную ошибку «любая ошибка». Оператор или блок, следующий за оператором «ON», распознается компилятором как код обработки ошибок. Во время выполнения, если в области действия оператора on происходит исправимая ошибка, стек сокращается и управление передается следующему за ним оператору.

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

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

Синтаксически операторы try выглядят как операторы if: try, за которыми следует оператор или блок, за которым следует else и еще один оператор или блок. Дополнительные предложения else могут следовать за первым. Если во время выполнения в коде, следующем за предложением 'try', происходит какое-либо восстанавливаемое завершение, при необходимости стек сокращается, а управление переходит к коду, следующему за первым 'else'. Кроме того, установлены атрибуты, позволяющие программе определять, что и где произошло (включая конкретный номер строки).

Большинство событий, которые могут привести к завершению задачи, можно восстановить. Это включает переполнение стека, доступ к массиву вне пределов, целочисленный поток выше / ниже и т. Д. Оператор (или пользователь) DS не может быть восстановлен, кроме как с помощью привилегированных задач, использующих UNSAFE форму попытки.

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

Как и в случае с атрибутами файла, задачи также имеют атрибуты, такие как приоритет задачи (который назначается во время компиляции или выполнения или может быть изменен во время выполнения задачи), время процессора, время ожидания, состояние и т. Д. Доступ к атрибутам можно получить программно, как и к файловым атрибутам файлов. Родительская задача доступна программно как атрибут задачи типа задача. Например, «self.initiator.name »дает имя процесса, который инициировал текущий процесс.

GETSPACE и ЗАБЫТЬ это две основные процедуры, управляющие выделением и освобождением памяти. Память должна быть выделена при запуске процесса и всякий раз, когда вводится блок, который использует массивы, файлы и т. Д. GETSPACE и ЗАБЫТЬ не только обрабатывают пространство памяти, они также выделяют или освобождают дисковое пространство, на которое могут накладываться нерезидентные данные. Память может быть СОХРАНЕННОЙ (т. Е. Резидентной в памяти), ПЕРЕВЕРЖИВАЕМОЙ (т. Е. Виртуальной памятью) или ПРИКЛЮЧЕННОЙ (то есть резидентной, но подвижной). Они призваны, например, к АППАРАТНОЕ ОБЕСПЕЧЕНИЕ когда процесс обращается к неинициализированному массиву или FILEOPEN.

АППАРАТНОЕ ОБЕСПЕЧЕНИЕ обрабатывает аппаратные прерывания и может вызывать GETSPACE, IO_FINISH или т.п.

BLOCKEXIT вызывается задачей, выходящей из блока. BLOCKEXIT может, в свою очередь, вызвать ЗАКРЫТЬ, ЗАБЫТЬ или т.п. при очистке и освобождении ресурсов, объявленных и используемых в этом блоке.

J_EDGAR_HOOVER является основным защитником системы, вызываемым при запуске процесса, открытии файла, входе пользователя в систему и т. д.

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

Задача проходит разные состояния, начиная с NASCENT. При ДОСТАВКЕ вызывается событие РОЖДЕНИЕ, и состояние задачи меняется на ЖИВОЕ. Когда вызывается PROCESSKILL, состояние меняется на DISEASED. Когда вызывается DEATH, задача помещается в структуру очереди MORGUE, после чего все оставшиеся ресурсы освобождаются для системы процессом PROCESSKILL.

Пока задача ЖИВАЯ, функции MCP выполняются поверх этого конкретного процесса, поэтому ресурсы ЦП автоматически назначаются задаче, вызывая накладные расходы MCP. Кроме того, большая часть работы MCP выполняется с правами безопасности этого конкретного стека. Только перед РОЖДЕНИЕМ и после СМЕРТИ MCP должен работать из другого стека. Если ничего не доступно, система поддерживает неактивный стек.

Программные компоненты и библиотеки

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

Библиотеки полностью перевернули этот сценарий со следующими преимуществами:

• Библиотеки и независимые процессы написаны как независимые программные единицы.
• Библиотеки полностью контролируют доступ к общим ресурсам (данным инкапсуляция и прячется )
• Библиотеки и клиенты могут быть написаны на разных языках
• Переключение процессов не требовалось для безопасного доступа к данным

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

Библиотеки были введены в системы MCP в начале 1980-х годов и были разработаны Роем Гаком и другими в Берроуз. Они очень похожи К. А. Р. Хоар контролирует и обеспечивает возможность управляемого взаимного исключения и синхронизации между клиентскими процессами с использованием событий MCP EVENT и техники блокировки Dahm. Библиотеки предлагают клиенту процедурные точки входа, которые проверяются на совместимость интерфейса (проверяются все параметры и возвращаемые типы импортированных процедур) до того, как клиент будет связан с библиотекой. Библиотека и ее клиент могут быть написаны на разных языках. Преимущество заключается в том, что вся синхронизация обеспечивается в библиотеке, и клиентскому коду не нужно вообще беспокоиться об этом уровне программирования. Это приводит к созданию надежного кода, поскольку клиенты не могут подорвать код синхронизации в библиотеке. (Некоторые назвали бы это 'Надежные вычисления Инициатива '.)

Библиотеки - это более сложные формы библиотек в других системах, таких как DLL. Библиотеки MCP могут быть «общими для всех», «совместно используемыми rununit» или «частными». Частный случай наиболее близок к библиотекам в других системах - для каждого клиента вызывается отдельная копия библиотеки и нет обмена данными между процессами.

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

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

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

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

Доступ к библиотекам также можно получить «по названию» и «по функциям». В «по названию» клиент указал имя файла библиотеки. «По функции» был косвенным методом, при котором клиент просто указывал имя функции библиотеки, например, «system_support», а фактическое расположение библиотеки находилось в таблице, ранее созданной оператором с «SL» (система library), например 'SL system_support = * system / library / support'. Отказоустойчивое отношение MCP также работает здесь - если клиент пытается получить доступ к библиотеке, которой нет, клиент помещается в «ожидающие» задачи, и библиотека может присутствовать, или запрос перенаправляется.

Библиотеки также можно обновлять «на лету», все, что нужно сделать, - это «SL» новой версии. Запущенные клиенты будут продолжать использовать старую версию, пока они не прекратят работу и новые клиенты не будут перенаправлены на новую версию.

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

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

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

Библиотеки соединений позволяют в значительной степени контролировать связи. Каждая сторона связи может опционально утвердить связь и может при желании разорвать связь. Состояние можно легко поддерживать как для каждой связи, так и глобально.

Файлы порта

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

Поэтому наиболее выгодное использование файлов портов - для распределенного IPC. Файлы портов были представлены с помощью BNA (сетевой архитектуры Берроуза), но с появлением стандартных сетевых технологий, таких как OSI и TCP /IP, файлы портов также могут использоваться с этими сетями.

Сервер, прослушивающий входящие соединения, объявляет файл порта (файл с атрибутом KIND, равным PORT). Каждое соединение, выполняемое от клиента, создает подфайл с индексом, поэтому каждый файл порта представляет несколько подключений к разным клиентам в сети.

Серверный процесс получает клиентские запросы из любой точки сети, выполняя чтение из файла порта (subfile = 0 для чтения из любого подфайла). Он выдает ответ клиенту, отправившему запрос, путем записи в конкретный подфайл, из которого был прочитан запрос.

Рабочая среда

MCP также обеспечивает сложную, но простую среду оператора. Для крупных установок многим операторам может потребоваться предоставить физические ресурсы, такие как принтеры (загрузка бумаги, картриджи с тонером и т. Д.). Среды начального уровня для небольших офисов или для одного пользователя могут потребовать среды без оператора (особенно для портативных компьютеров).

В больших системах есть специальные операционные терминалы, называемые ODT (Operator Display Terminals), которые обычно хранятся в защищенной среде. В небольших системах машинами можно управлять с любого терминала (при условии, что терминал и пользователь имеют достаточные привилегии) ​​с помощью программы MARC (управление ресурсами с помощью меню). Команды оператора также могут использоваться знакомыми с ними пользователями.

Команды оператора в основном состоят из двух букв (как в Unix), а некоторые - из одной буквы. Это означает, что интерфейс оператора необходимо изучить, но он очень эффективен для опытных операторов, которые изо дня в день используют большую систему мэйнфреймов. Команды нечувствительны к регистру.

Задачи вводятся в программу "mix" и идентифицируются номерами смеси, как и библиотеки. Для выполнения программы операторы могут использовать команду «EX» или «RUN», за которой следует имя файла программы. ODT обычно запускаются с ADM (автоматический режим отображения), который представляет собой настраиваемое отображение состояния системы, обычно настраиваемое для отображения активных, ожидающих и завершенных смешанных записей, а также системных сообщений оператору для уведомлений или ситуаций, требующих действий оператора. .

Полный список этих дисплеев представлен буквами «A» (активен), «W» (ожидание), «C» (завершен) и «MSG» (команды сообщений).

Если задача становится ожидающей какого-либо действия оператора, оператор может узнать, что ей нужно, введя ее номер смеси, а затем команду «Y». (Обратите внимание на объектно-ориентированный стиль команд: сначала выберите объект, а затем команду.) Например, «3456Y».

Оператор может поместить задачу в ожидающие записи с помощью команды остановки «3456ST» и снова сделать ее активной с помощью OK: «3456OK». Команда OK также может использоваться, когда оператор сделал ресурс доступным для задачи, хотя чаще MCP обнаруживает, что ресурсы стали доступными, ВЫЗЫВАЕТ СОБЫТИЕ, которое процессы ожидали, без дальнейшего вмешательства оператора. Чтобы передать текстовую информацию от оператора программе, можно использовать команду accept «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 было много нововведений в области управления, которые теперь используются интернет-сообществом в целом. Системное программное обеспечение было отправлено клиентам, включая исходный код и все инструменты редактирования и компиляции, необходимые для создания новых версий MCP для клиентов. Многие клиенты разработали нишу для внутренней работы MCP, и клиенты часто присылали «патчи» (фрагменты исходного кода с порядковыми номерами) в качестве предложений по новым улучшенным функциям или исправлению ошибок (FTR - отчеты о неисправностях на местах). Многие из предложенных исправлений были включены разработчиками системы и интегрированы в следующую версию выпуска MCP. Включение сообщества добровольных, самопровозглашенных экспертов в основную техническую работу сейчас широко практикуется и является сутью Открытые инновации. Это нововведение в области управления общественным развитием относится к 1970-м годам.

Компиляторы

В истории Unisys MCP было несколько поколений компиляторов, поддерживающих широкий спектр языки программирования, включая:

• АЛГОЛ,^[4] включая DCALGOL, BDMSALGOL и DMALGOL.
• C^[5]
• КОБОЛ который включает COBOL74^[6] и COBOL85^[7]
• Fortran77^[8]
• NEWP^[9]
• Паскаль^[10]
• РПГ^[11]

Другие продукты включают:

• Связующее^[12]
• Язык определения сети^[13]
• Язык рабочего процесса^[14]

Компиляторы ранее существовали для ESPOL, КОБОЛ (68), Фортран (66), APL, и PL / I.

Ассемблер

В операционной системе Unisys MCP нет ассемблера, за исключением семейства средних систем.

Резюме

MCP была первой ОС, разработанной исключительно на языке высокого уровня. За свою 50-летнюю историю он имел много первых коммерческих реализаций, включая виртуальную память, симметричную многопроцессорную обработку и язык управления заданиями высокого уровня (WFL). У него уже давно было много возможностей, которые только сейчас появляются в других широко распространенных операционных системах, и вместе с архитектурой больших систем Burroughs MCP обеспечивает очень безопасную, высокопроизводительную среду многозадачности и обработки транзакций.

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

• Языки программирования Unisys MCP для информации о компиляторах MCP

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

внешняя ссылка

• MCP 19.0 Documentation – Free access but may require copyright acknowledgement