Берроуз MCP

«Мастерская программа управления» перенаправляется сюда. О вымышленном злодее из фильма «Трон» см. «Мастерская программа управления» ( Трон ) .

МКП

Разработчик	Берроуз / Unisys
Написано в	ЭСПОЛ , НЬЮП
Рабочее состояние	Текущий
Исходная модель	Источник доступен
Первоначальный выпуск	1961 год ( 1961 )
Последний выпуск	20.0 / май 2021 г.
Платформы	Крупные системы Burroughs, включая Unisys Clearpath/MCP
По умолчанию пользовательский интерфейс	Текстовый пользовательский интерфейс
Лицензия	Собственный
Официальный сайт	Unisys ClearPath

MCP операционная (Master Control Program) — это система для Burroughs B5000/B5500/B5700 и B6500 и его преемников , включая системы Unisys Clearpath/MCP .

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

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

История

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

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

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

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

Unisys прекратила производство оборудования в начале 2010-х годов, и теперь операционная система работает в режиме эмуляции.

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

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 'mc'.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Большинство событий, которые могут привести к завершению задачи, можно восстановить. Сюда входит переполнение стека, доступ к массиву за пределами границ, целочисленное превышение/недополнение и т. д. DS оператора (или пользователя) не подлежит восстановлению, кроме как с помощью привилегированных задач с использованием НЕБЕЗОПАСНОЙ формы попытки.

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

Как и атрибуты файлов, задачи также имеют атрибуты, такие как приоритет задачи (который назначается во время компиляции или во время выполнения или может быть изменен во время выполнения задачи), время процессора, время ожидания, состояние и т. д. Эти задачи Доступ к атрибутам можно получить программно, как и к атрибутам файлов. Родительская задача доступна программно как атрибут задачи типа задача. Например, «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 вызывается событие РОЖДЕНИЕ и состояние задачи меняется на ЖИВОЕ. При вызове PROCESSSKILL состояние меняется на ЗАБОЛЕВАНИЕ. При возникновении СМЕРТИ задача помещается в структуру очереди MORGUE, после чего все оставшиеся ресурсы освобождаются для системы процессом под названием PROCESSSKILL.

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

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

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

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

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

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

Библиотеки были представлены в системах MCP в начале 1980-х годов и были разработаны Роем Гаком и другими сотрудниками Burroughs . Они очень похожи на мониторы CAR Hoare и предоставляют возможность контролируемого взаимного исключения и синхронизации между клиентскими процессами с использованием MCP EVENT и техники блокировки Дама. Библиотеки предлагают клиенту процедурные точки входа, которые проверяются на совместимость интерфейса (проверяются все параметры и типы возвращаемых данных импортированных процедур) перед тем, как клиент будет связан с библиотекой. Библиотека и ее клиент могут быть написаны на разных языках. Преимущество в том, что вся синхронизация обеспечивается в библиотеке и клиентскому коду вообще не нужно беспокоиться об этом уровне программирования. В результате получается надежный код, поскольку клиенты не могут подорвать код синхронизации в библиотеке. (Некоторые назвали бы это « Инициативой в области надежных вычислений ».)

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

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

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

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

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

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

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

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

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

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

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

Файлы порта

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

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

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

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

Операционная среда

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

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

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

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

Полный список этих дисплеев представлен буквами «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 содержали множество управленческих инноваций, которые сейчас используются интернет-сообществом в целом. Системное программное обеспечение было отправлено клиентам вместе с исходным кодом и всеми инструментами редактирования и компиляции, необходимыми для создания новых версий MCP для клиентов. Многие клиенты приобрели специализированный опыт внутренней работы MCP, и клиенты часто присылали «заплатки» (фрагменты исходного кода с порядковыми номерами) в качестве предложений новых расширенных функций или исправлений ошибок (FTR - отчеты о неполадках на месте). Многие из предложенных исправлений были включены разработчиками системы и интегрированы в следующую версию выпуска MCP. Включение сообщества добровольных экспертов-самоучек в основную техническую работу в настоящее время широко практикуется и является сутью открытых инноваций . Эта управленческая инновация развития сообщества возникла еще в 1970-х годах.

Составители

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

• АЛГОЛ , включая DCALGOL, BDMSALGOL и DMALGOL.
• С
• COBOL , который включает COBOL74. и КОБОЛ85
• Фортран77
• НЬЮП
• Паскаль
• РПГ

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

• связующее
• Язык определения сети
• Язык рабочего процесса

Ранее существовали компиляторы для ESPOL , COBOL(68), Fortran(66), APL и PL/I .

Ассемблер

В операционной системе Unisys MCP нет ассемблера.

Краткое содержание

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

Внешние ссылки

• Документация MCP 19.0 — бесплатный доступ, но может потребоваться подтверждение авторских прав.
• Unisys ClearPath