Операционная система MCP: История и особенности мэйнфрейма Burroughs
Burroughs MCP
MCP: операционная система мэйнфреймов Burroughs и Unisys Clearpath. Первая ОС на ЯВУ, с виртуальной памятью и поддержкой многопроцессорности. История и особенности.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Операционная система мэйнфрейма
Mainframe computer operating system
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 был пионером во многих областях, в том числе: первая операционная система, способная управлять несколькими процессорами, первая коммерческая реализация виртуальной памяти и первая ОС, полностью написанная на языке высокого уровня.
The MCP (Master Control Program) is the operating system of the Burroughs B5000/B5500/B5700 and the B6500 and successors, including the Unisys Clearpath/MCP systems. MCP was originally written in 1961 in ESPOL (Executive Systems Problem Oriented Language). In the 1970s, MCP was converted to NEWP which was a better structured, more robust, and more secure form of ESPOL. The MCP was a leader in many areas, including: the first operating system to manage multiple processors, the first commercial implementation of virtual memory, and the first OS written exclusively in a high level language.
История
В 1961 году MCP стала первой ОС, написанной исключительно на языке высокого уровня (HLL). Комплекс Burroughs Large System (B5000 и последующие модели) был уникален тем, что при его разработке предполагалось, что все программное обеспечение, включая системное, будет написано на HLL, а не на языке ассемблера. Такой подход был новаторским и неслыханным в 1961 году. В отличие от IBM, столкнувшейся с конкуренцией в области аппаратного обеспечения после ухода Джина Амдала, программное обеспечение Burroughs работало исключительно на аппаратном обеспечении Burroughs из-за отсутствия совместимого оборудования от сторонних производителей. Благодаря этому Burroughs имела возможность распространять исходный код всего продаваемого программного обеспечения, включая MCP, который изначально разрабатывался с учетом принципов открытости. Например, для обновления системы пользователю требовалось перекомпилировать системное программное обеспечение и применить необходимые локальные исправления. В то время это было обычной практикой, поскольку клиенты (особенно крупные, такие как Федеральная резервная система) часто модифицировали программу для соответствия своим специфическим потребностям. В результате была создана Группа пользователей Burroughs, которая проводила ежегодные встречи, позволяя пользователям обмениваться собственными расширениями для ОС и других компонентов системного программного обеспечения. Многие из этих расширений со временем были включены в базовый код ОС и стали доступны всем клиентам. Таким образом, MCP можно считать одним из первых проектов с открытым исходным кодом. Компания Burroughs не была первым производителем, распространявшим исходный код, и относительно поздно вошла на рынок электронных вычислений (по сравнению с традиционными конкурентами NCR, IBM и Univac). В настоящее время, когда MCP работает на стандартном оборудовании, некоторые компоненты программного обеспечения на базе MCP больше не предоставляются Unisys в исходном коде. MCP стала первой коммерческой ОС, реализовавшей виртуальную память, поддержка которой заложена в архитектуре крупных систем Burroughs с момента ее создания. Эта схема уникальна в отрасли, поскольку она хранит и извлекает объекты, определенные компилятором, а не страницы памяти фиксированного размера, что является следствием не-фон-неймановской и унифицированной стековой архитектуры. Компания Unisys прекратила производство аппаратного обеспечения в начале 2010-х годов, и в настоящее время операционная система работает в среде эмуляции.
In 1961, the MCP was the first OS written exclusively in a high level language (HLL). The Burroughs Large System (B5000 and successors) were unique in that they were designed with the expectation that all software, including system software, would be written in an HLL rather than in assembly language, which was a unique and innovative approach in 1961. Unlike IBM, which faced hardware competition after the departure of Gene Amdahl, Burroughs software only ever ran on Burroughs hardware due to a lack of compatible third party hardware. For this reason, Burroughs was free to distribute the source code of all software it sold, including the MCP, which was designed with this openness in mind. For example, upgrading required the user to recompile the system software and apply any needed local patches. At the time, this was common practice, and was necessary as it was not unusual for customers (especially large ones, such as the Federal Reserve) to modify the program to fit their specific needs. As a result, a Burroughs Users Group was formed, which held annual meetings and allowed users to exchange their own extensions to the OS and other parts of the system software suite. Many such extensions have found their way into the base OS code over the years, and are now available to all customers. As such, the MCP could be considered one of the earliest open source projects. Burroughs was not the first manufacturer to distribute source code and was a late entry to electronic computing (compared to its traditional rivals NCR, IBM, and Univac). Now that MCP runs on commodity hardware, some elements of the MCP based software suite are no longer made available in source form by Unisys. The MCP was the first commercial OS to provide virtual memory, which has been supported by the Burroughs large systems architecture since its inception. This scheme is unique in the industry, as it stores and retrieves compiler defined objects rather than fixed size memory pages, as a consequence of its overall non von Neumann and uniformly stack based architecture. Unisys stopped producing the hardware in the early 2010s, and the operating system is now run under emulation.
Файловая система
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'. MCP реализует журналируемую файловую систему, обеспечивающую устойчивость к сбоям в случае отказа диска, потери питания и т.п. Повредить файловую систему невозможно (за исключением операционной системы или другого доверенного системного программного обеспечения с прямым доступом к ее нижним уровням). Файловая система не учитывает регистр символов, если вокруг имени не указаны кавычки, в этом случае она учитывает регистр и сохраняет его.
The MCP provides a file system with hierarchical directory structures. In early MCP implementations, directory nodes were represented by separate files with directory entries, as other systems did. However, since about 1970, MCP internally uses a 'FLAT' directory listing all file paths on a volume. This is because opening files by visiting and opening each directory in a file path was inefficient and for a production environment it was found to be better to keep all files in a single directory, even though they retain the hierarchical naming scheme. Programmatically, this makes no difference. The only difference visible to users is that an entity file can have the same name as a directory. For example, "A/B" and "A/B/C" can both exist; "B" can be both a node in a file and a directory. Files are stored on named volumes, for example 'this/is/a/filename on myvol', 'myvol' being the volume name. This is device independent, since the disk containing 'myvol' can be moved or copied to different physical disk drives. Disks can also be concatenated so that a single volume can be installed across several drives, as well as mirrored for recoverability of sensitive data. For added flexibility, each program can make volume substitutions, a volume name may be substituted with a primary and secondary alternate name. This is referred to as the process’ FAMILY. For instance, the assignment “FAMILY DISK = USERPACK OTHERWISE SYSPACK” stores files logically designated on volume DISK onto the volume USERPACK and will seek files first on volume USERPACK. If that search has no success, another search for the file is done on volume SYSPACK. DISK is the default volume name if none is specified. Each file in the system has a set of file attributes. These attributes record all sorts of meta data about a file, most importantly its name and its type (which tells the system how to handle a file, like the more limited four character file type code on the Macintosh). Other attributes have the file's record size (if fixed for commercial applications), the block size (in multiples of records that tells the MCP how many records to read and write in a single physical IO) and an area size in multiples of blocks, which gives the size of disk areas to be allocated as the file expands. The file type indicates if the file is character data, or source code written in particular languages, binary data, or code files. Files are protected by the usual security access mechanisms such as public or private, or a file may have a guard file where the owner can specify complex security rules. Another security mechanism is that code files can only be created by trusted compilers. Malicious programmers cannot create a program and call it a compiler – a program could only be converted to be a compiler by an operator with sufficient privileges with the 'mc' make compiler operator command. The MCP implements a Journaling file system, providing fault tolerance in case of disk failure, loss of power, etc. It is not possible to corrupt the file system (except by the operating system or other trusted system software with direct access to its lower layers)
The file system is case insensitive and not case preserving unless quotes are added around the name in which case it is case sensitive and case preserving.
Управление процессами
Процессы MCP называются "Заданиями" и "Задачами". Задание содержит одну или несколько задач. Задачи внутри задания могут выполняться последовательно или параллельно. Логика может быть реализована на уровне задания, как правило, на языке управления заданиями MCP WFL, для управления потоком задания. Как только все задачи в задании завершены, само задание также завершается. Процесс MCP проходит жизненный цикл с момента его входа в систему до момента его выхода. Начальное состояние для задания – "В очереди". Существует период времени, в течение которого задание находится в одной из нескольких определяемых пользователем очередей заданий. Следующее состояние – "Запланировано", когда задание перемещается из очереди в память. Задачи внутри задания не ожидают в очереди; вместо этого они переходят непосредственно в состояние "Запланировано" при запуске. После того, как задание или задача запущены, они могут переходить между состояниями "Активно", "Ожидание" и "Запланировано" по мере выполнения. Как только задание или задача завершены, они переходят в состояние "Завершено". Запущенные процессы – это те, которые используют ресурс процессора и помечены как "Запущенные". Процессы, готовые к назначению процессору, когда нет свободных процессоров, помещаются в очередь готовых. Процессам может быть присвоен приоритет "Объявленный" или "Видимый", обычно 50 по умолчанию, но может быть от 0 до 99 для пользовательских процессов. Системным процессам могут быть присвоены более высокие значения. Следует отметить, что этот числовой приоритет вторичен по отношению к общему приоритету, который основан на типе задачи. Процессы, которые непосредственно являются частью операционной системы, называемые Независимыми исполнителями, имеют наивысший приоритет независимо от числового значения приоритета. Далее следуют процессы, использующие блокировку MCP, затем системы управления сообщениями, такие как CANDE. Затем – завершенные процессы. Затем – задания языка рабочих потоков. И, наконец, – пользовательские процессы. На более низком уровне существует приоритет "Тонкий", предназначенный для повышения приоритета задач, которые не используют весь процессорный квант. Это позволяет задаче, связанной с вводом-выводом, получить процессорное время раньше задачи, связанной с процессором, при том же объявленном приоритете. Процессы, ожидающие другие ресурсы, такие как файл для чтения, ожидают структуру данных EVENT. Таким образом, все процессы, ожидающие один и тот же ресурс, ожидают одно и то же событие. Когда ресурс становится доступным, событие вызывается, что пробуждает все процессы, ожидающие его. Процессы могут ожидать несколько событий, чтобы произошло любое из них, включая тайм-аут. События полностью программируются пользователем, то есть пользователи могут создавать системы, использующие обобщенную систему событий, предоставляемую MCP. Процессы, которые завершились, помечаются как завершенные. Оперативно, статус всех задач в системе отображается оператору. Все запущенные и готовые процессы отображаются как "Активные" задачи (поскольку система реализует вытесняющую многозадачность, переход из состояния "Готов" в "Запущен" и обратно происходит настолько быстро, что различать готовые и запущенные задачи бессмысленно, поскольку все они получат квант процессора в течение секунды). Все активные задачи могут быть отображены с помощью команды "A". Завершенные задачи отображаются как завершенные задачи с указанием причины завершения: EOT для нормального "конца задачи" и DSed с указанием причины сбоя процесса. Всем процессам присваивается номер смешения, и операторы могут использовать этот номер для идентификации процесса, подлежащего управлению. Одной из таких команд является команда DS (которая означает либо "Удалить из расписания", "Прекратить", либо "Отправить на дно", в зависимости от влияния военно-морского персонала на ранние компьютерные проекты, в зависимости от того, с кем вы разговариваете). Задачи, завершенные оператором, отображаются в полных записях как O DS. Задачи также могут быть завершены из-за ошибок программы, отмеченных как F DS или P DS, для таких ошибок, как недействительный индекс, числовое переполнение и т. д. Завершенные записи могут быть перечислены оператором с помощью команды "C". Задачи, ожидающие ресурс, отображаются в записях ожидания с указанием причины ожидания. Все ожидающие задачи могут быть перечислены с помощью команды "W". Причина ожидания также указывается, и дополнительную информацию о задаче можно увидеть с помощью команды "Y". Возможно, что задача ожидает ввода оператора, который отправляется задаче с помощью команды accept "AX" (обратите внимание, что ввод оператора сильно отличается от пользовательского ввода, который будет вводом с сетевого устройства с графическим интерфейсом). Задачи, ожидающие пользовательского ввода или чтения файлов, обычно не отображаются в записях ожидания для привлечения внимания оператора. Другой причиной ожидания задачи является ожидание файла. Когда процесс открывает файл, и файл отсутствует, задача помещается в записи ожидания с указанием того, что она ожидает определенный файл. Оператор (или пользователь, которому принадлежит процесс) имеет возможность либо скопировать файл в ожидаемое место, либо перенаправить задачу на чтение файла из другого места, либо файл может быть даже создан независимым процессом, который еще не завершен. Если ресурс не может быть предоставлен оператором, оператор может завершить задачу (DS) в качестве крайней меры. Это отличается от других систем, которые автоматически завершают задачу, когда недоступен ресурс, такой как файл. MCP обеспечивает этот уровень восстановления задач оператором. Другие системы заставляют программистов добавлять код для проверки наличия файлов перед доступом к ним, и, следовательно, дополнительный код должен быть написан в каждом случае для обеспечения восстановления или синхронизации процессов. Такой код может быть написан в программе MCP, когда нежелательно, чтобы задача ожидала, но из-за возможности восстановления на уровне оператора это не является обязательным и, следовательно, упрощает программирование. В дополнение к возможности динамического переназначения запросов к файлам (или базам данных) другим файлам (или базам данных) до или во время выполнения программы, существует несколько механизмов, позволяющих программистам обнаруживать и восстанавливаться после ошибок. Один из способов, оператор "ON", существует уже много лет. Можно указать конкретные ошибки (например, деление на ноль) или использовать универсальный "anyfault". Оператор или блок, следующий за оператором "ON", распознается компилятором как код обработки ошибок. Во время выполнения, если произойдет восстанавливаемая ошибка в области действия оператора "on", стек будет сокращен, и управление будет передано оператору, следующему за ним. Одна из проблем с логикой обработки оператора "ON" заключалась в том, что он вызывался только для ошибок программы, а не для завершений программы по другим причинам. Со временем возросла потребность в гарантированной обработке ненормальных завершений. В частности, был необходим механизм, позволяющий программам вызывать плагины, написанные клиентами или третьими сторонами, без какого-либо риска, если плагин будет работать некорректно. В дополнение к общим механизмам плагинов, новая форма динамической связи библиотек (Connection Libraries) позволяет программам импортировать и экспортировать функции и данные, и, следовательно, одна программа выполняет код, предоставляемый другой. Для достижения такой повышенной защиты в середине 1990-х годов был введен более новый механизм. В ошибочной попытке совместимости он был назван в честь тогдашнего предлагаемого конструктора языка C++ с тем же именем. Поскольку синтаксис и поведение двух языков настолько сильно различаются, выбор одного и того же имени привел только к путанице и недопониманию. Синтаксически операторы "try" выглядят как операторы "if": "try", за которым следует оператор или блок, за которым следует "else" и другой оператор или блок. За первым "else" могут следовать дополнительные операторы "else". Во время выполнения, если в коде, следующем за оператором "try", произойдет какое-либо восстанавливаемое завершение, стек будет сокращен, если это необходимо, и управление перейдет к коду, следующему за первым оператором "else". Кроме того, устанавливаются атрибуты, позволяющие программе определить, что произошло и где (включая конкретный номер строки). Большинство событий, которые приводят к завершению задачи, восстанавливаются. Это включает переполнение стека, выход за границы массива, целочисленное переполнение/недополнение и т. д. Завершение (DS) оператором или пользователем не восстанавливается, за исключением привилегированных задач, использующих небезопасную форму try. Таким образом, MCP обеспечивает высоко отказоустойчивую среду, а не сбой и дамп памяти других систем. Как и в случае с файлами...
MCP processes are called "Jobs" and "Tasks." A Job contains one or more tasks. Tasks within a job can run sequentially or in parallel. Logic can be implemented at the Job level, typically in the MCP's job control language WFL, to control the flow of a job. Once all tasks in a job are complete, the job itself is completed. An MCP Process goes through a life cycle from the time it enters the system until it leaves. The initial state for a Job is "Queued." There is a period of time while the Job resides in one of several user defined Job Queues. The next state is "Scheduled" as the Job moves from a queue into memory. Tasks within a job do not wait in queue; instead going directly to the 'Scheduled' state when initiated. Once a Job or Task is started, it can transition between "Active," "Waiting" and "Scheduled" as it progresses. Once a Job or Task completes, it moves to the 'Completed' state. Running processes are those that use a processor resource and are marked as 'running'. Processes that are ready to be assigned to a processor, when there is no free processor are placed in the ready queue. Processes may be assigned a “Declared” or “Visible” priority, generally 50 as the default, but can be from 0 to 99 for user processes. System processes may be assigned the higher values. Note that this numerical priority is secondary to an overall priority, which is based on the task type. Processes that are directly part of the operating system, called Independent Runners, have the highest priority regardless of numeric priority value. Next come processes using an MCP lock, then Message Control Systems such as CANDE. Then Discontinued processes. Then Work Flow Language jobs. Finally come user processes. At a lower level, there is a Fine priority intended to elevate the priority of tasks that do not use their full processor slice. This allows an IO bound task to get processor time ahead of a processor bound task on the same declared priority. Processes that are waiting on other resources, such as a file read, wait on the EVENT data structure. Thus all processes waiting on a single resource wait on a single event. When the resource becomes available, the event is caused, which wakes up all the processes waiting on it. Processes may wait on multiple events for any one of them to happen, including a time out. Events are fully user programmable – that is, users can write systems that use the generalized event system provided by the MCP. Processes that have terminated are marked as completed. Operationally, the status of all tasks in the system is displayed to the operator. All running and ready processes are displayed as 'Active' tasks (since the system implements preemptive multitasking, the change from ready to running and back is so quick that distinguishing ready and running tasks is pointless because they will all get a slice of the processor within a second). All active tasks can be displayed with the 'A' command. Terminated tasks are displayed as completed tasks with the reason for termination, EOT for normal 'end of task', and DSed with a reason for a process failure. All processes are assigned a mix number, and operators can use this number to identify a process to control. One such command is the DS command (which stands for either Delete from Schedule, DiScontinue, or Deep Six, after the influence of Navy personnel on early computer projects, depending on who you talk to). Tasks terminated by the operator are listed in the complete entries as O DS. Tasks can also terminate due to program faults, marked as F DS or P DS, for faults such as invalid index, numeric overflow, etc. Completed entries can be listed by the operator with the 'C' command. Tasks waiting on a resource are listed under the waiting entries and the reason for waiting. All waiting tasks may be listed with the 'W' command. The reason for waiting is also listed and more information about a task may be seen with the 'Y' command. It may be that a task is waiting for operator input, which is sent to a task via the accept 'AX' command (note that operator input is very different from user input, which would be input from a network device with a GUI interface). Tasks waiting on user input or file reads would not normally be listed as waiting entries for operator attention. Another reason for a task to be waiting is waiting on a file. When a process opens a file, and the file is not present, the task is placed in the waiting entries, noting that it is waiting on a certain file. An operator (or the user that owns the process) has the opportunity either to copy the file to the expected place, or to redirect the task to read the file from another place, or the file might even be created by an independent process that hasn't yet completed. If the resource cannot be provided by the operator, the operator can DS the task as a last resort. This is different from other systems, which automatically terminate a task when a resource such as a file is not available. The MCP provides this level of operator recoverability of tasks. Other systems force programmers to add code to check for the presence of files before accessing them, and thus extra code must be written in every case to provide recoverability, or process synchronization. Such code may be written in an MCP program when it is not desirable to have a task wait, but because of the operator level recoverability, this is not forced and therefore makes programming much simpler. In addition to the ability to dynamically remap file (or database) requests to other files (or databases), before or during program execution, several mechanisms are available to allow programmers to detect and recover from errors. One way, an 'ON' statement, has been around for many years. Specific faults (e. g., divide by zero) can be listed, or the catch all 'anyfault' can be used. The statement or block following the 'ON' statement is recognized by the compiler as fault handling code. During execution, if a recoverable fault occurs in scope of the 'on' statement, the stack is cut back and control transferred to the statement following it. One problem with the handling logic behind the ON statement was that it would only be invoked for program faults, not for program terminations having other causes. Over time, the need for guaranteed handling of abnormal terminations grew. In particular, a mechanism was needed to allow programs to invoke plug ins written by customers or third parties without any risk should the plug in behave badly. In addition to general plug in mechanisms, the new form of dynamic library linkage (Connection Libraries) allows programs to import and export functions and data, and hence one program runs code supplied by another. To accomplish such enhanced protection, a newer mechanism was introduced in the mid 1990s. In a misguided attempt at compatibility, it was named after the then proposed C++ language construct of the same name. Because the syntax and behavior of the two differ to such a large extent, choosing the same name has only led to confusion and misunderstanding. Syntactically, 'try' statements look like 'if' statements: 'try', followed by a statement or block, followed by 'else' and another statement or block. Additional 'else' clauses may follow the first. During execution, if any recoverable termination occurs in the code following the 'try' clause, the stack is cut back if required, and control branches to the code following the first 'else'. In addition, attributes are set to allow the program to determine what happened and where (including the specific line number). Most events that would result in task termination are recoverable. This includes stack overflow, array access out of bounds, integer over/under flow, etc. Operator (or user) DS is not recoverable except by privileged tasks using an UNSAFE form of try. MCP thus provides a very fault tolerant environment, not the crash and burn core dump of other systems. As with file attributes, tasks have attributes as well, such as the task priority (which is assigned at compile time or execution time, or can be changed while the task is running), processor time, wait time, status, etc. These task attributes can be accessed programmatically as can file attributes of files. The parent task is available programmatically as a task attribute that is of type task. For example, 'myself. initiator. name' gives the name of the process that initiated the current process. GETSPACE and FORGETSPACE are the two main procedures handling memory allocation and deallocation. Memory needs to be allocated at process initiation and whenever a block is entered that uses arrays, files, etc. GETSPACE and FORGETSPACE not only handle memory space, they also allocate or deallocate the disk space where non memory resident data may be overlaid. Memory may be SAVE (i. e., memory resident), OVERLAYABLE (i. e., virtual memory) or STICKY (meaning memory resident, but movable). They are called upon e. g. by HARDWAREINTERRUPT when a process addresses an uninitialized array or by FILEOPEN. HARDWAREINTERRUPT handles hardware interrupts and may call upon GETSPACE, IO FINISH or the like. BLOCKEXIT is called upon by a task exiting a block. BLOCKEXIT may in turn call FILECLOSE, FORGETSPACE or the like while cleaning up and releasing resources declared and used within that block. J EDGAR HOOVER is the main security guardian of the system, called upon at process start, file open, user log on, etc. GEORGE is the procedure that decides which process is the next one to receive CPU resources and is thus one of the few processes that uses the MoveStack instruction. A task goes through various states starting with NASCENT. At DELIVERY the event BIRTH is caused and the task's state changes to ALIVE. When PROCESSKILL is called upon, the state changes into DISEASED. When DEATH is caused the task gets put into the queue structure the MORGUE, after which all remaining resources are freed to the system by a process called PROCESSKILL. While the task is ALIVE, MCP functions are run on top of that particular process, thus CPU resources are automatically charged to the task causing the MCP overhead. Also, much of the MCP work is being performed with that particular stack's security rights. Only before BIRTH and after DEATH does the MCP need to be operating out of some other stack. If none is available, the system maintains an idle stack.
Порт-файлы
Другой метод межпроцессного взаимодействия (IPC) – это портовые файлы. Они похожи на каналы Unix, но обобщены для обеспечения многосторонней и двунаправленной связи. Поскольку они на порядок медленнее других методов IPC, таких как библиотеки, предпочтительнее использовать другие методы для IPC между различными процессами на одном компьютере. Поэтому наиболее эффективное применение портовых файлов – для распределенного IPC. Портовые файлы были введены вместе с BNA (Burroughs Network Architecture), но с появлением стандартных сетевых технологий, таких как OSI и TCP/IP, их можно использовать и с этими сетями. Сервер, ожидающий входящие соединения, объявляет портовый файл (файл с атрибутом KIND, равным PORT). Каждое соединение, установленное клиентом, создает подфайл с индексом, поэтому каждый портовый файл представляет собой множество соединений с различными клиентами в сети. Серверный процесс получает запросы от клиентов из любой точки сети, выполняя операцию чтения из портового файла (подфайл = 0 для чтения из любого подфайла). Он отправляет ответ клиенту, который отправил запрос, выполняя операцию записи в конкретный подфайл, из которого был прочитан запрос.
Another technique for inter process communication (IPC) is port files. They are like Unix pipes, except that they are generalized to be multiway and bidirectional. Since these are an order of magnitude slower than other IPC techniques such as libraries, it is better to use other techniques where the IPC is between different processes on the same machine. The most advantageous use of port files is therefore for distributed IPC. Port files were introduced with BNA (Burroughs Network Architecture), but with the advent of standard networking technologies such as OSI and TCP/IP, port files can be used with these networks as well. A server listening for incoming connections declares a port file (a file with the KIND attribute equal to PORT). Each connection that is made from a client creates a subfile with an index, so each port file represents multiple connections to different clients around the network. A server process receives client requests from anywhere on the network by issuing a read on the port file (subfile = 0 to read from any subfile). It issues a response to the client that issued the request by writing to the particular subfile from which the request was read.
Окружающая среда
MCP также предоставляет сложную, но при этом простую операторскую среду. Для крупных установок может потребоваться несколько операторов для обеспечения доступности физических ресурсов, таких как принтеры (загрузка бумаги, тонер-картриджей и т.п.). В средах начального уровня для небольших офисов или отдельных пользователей может потребоваться среда, не требующая оператора (особенно в случае реализации для ноутбуков). Крупные системы оснащены специализированными операторскими терминалами, называемыми ODT (Operator Display Terminals), которые обычно размещаются в защищенной среде. Для небольших систем управление машинами может осуществляться с любого терминала (при условии, что терминал и пользователь обладают достаточными правами) с помощью программы MARC (Menu Assisted Resource Control). Операторские команды также могут использоваться пользователями, знакомыми с ними. Операторские команды в основном состоят из двух букв (как в Unix), а некоторые – всего из одной. Это означает, что операторский интерфейс требует изучения, но он очень эффективен для опытных операторов, ежедневно работающих с крупной мэйнфрейм-системой. Команды не чувствительны к регистру. Задачи вводятся в программу 'mix' и идентифицируются номерами миксов, как и библиотеки. Для запуска программы операторы могут использовать команду 'EX' или 'RUN', за которой следует имя файла программы. ODT обычно работают в режиме ADM (Automatic Display Mode) – настраиваемом отображении состояния системы, обычно настроенном для отображения активных, ожидающих и завершенных записей миксов, а также системных сообщений для оператора, содержащих уведомления или информацию о ситуациях, требующих его вмешательства. Полный перечень этих отображений предоставляется командами 'A' (активные), 'W' (ожидающие), 'C' (завершенные) и 'MSG' (сообщения). Если задача переходит в состояние ожидания действия оператора, оператор может узнать, что требуется задаче, введя ее номер микса, за которым следует команда 'Y'. (Обратите внимание на объектно-ориентированный стиль команд: сначала выбирается объект, затем команда.) Например, '3456Y'. Оператор может перевести задачу в состояние ожидания с помощью команды остановки '3456ST' и снова активировать ее командой OK: '3456OK'. Команда OK также может использоваться, когда оператор предоставил ресурс для задачи, хотя чаще всего MCP самостоятельно обнаруживает, что ресурсы стали доступны, и генерирует событие, которого ожидали процессы, без дальнейшего вмешательства оператора. Для передачи текстовой информации от оператора программе можно использовать команду accept ‘3456AX MORE INFO’. Программы могут передавать информацию операторам с помощью механизма DISPLAY, который добавляет сообщения DISPLAY в отображение MSG. Помимо задач и процессов, операторы также контролируют файлы. Файлы можно просмотреть с помощью команды FILE, скопировать с помощью COPY, удалить с помощью REMOVE и переименовать. Операционная среда MCP мощная, но простая и обычно требует значительно меньше операторов, чем другие системы. Важной частью операционной среды является язык рабочего процесса высокого уровня.
The MCP also provides a sophisticated yet simple operator environment. For large installations, many operators might be required to make physical resources, such as printers (loading paper, toner cartridges, etc.) available. Low end environments for small offices or single user may require an operator free environment (especially the laptop implementation). Large systems have dedicated operations terminals called ODTs (Operator Display Terminals), usually kept in a secure environment. For small systems, machines can be controlled from any terminal (provided the terminal and user have sufficient privileges) using the MARC program (Menu Assisted Resource Control). Operator commands can also be used by users familiar with them. Operator commands are mostly two letters (as with Unix), and some are just one letter. This means that the operator interface must be learned, but it is very efficient for experienced operators who run a large mainframe system from day to day. Commands are case insensitive. Tasks are entered in the program 'mix' and identified by mix numbers, as are libraries. To execute a program, operators can use the 'EX' or 'RUN' command followed by the file name of the program. ODTs are run typically with ADM (Automatic Display Mode), which is a tailorable display of system status usually set up to display the active, waiting, and completed mix entries, as well as system messages to the operator for notifications or situations requiring operator action. Complete listing of these displays are given by the 'A' (active), 'W' (waiting), 'C' (completed), and 'MSG' (message commands). If a task becomes waiting on some operator action, the operator can find out what the task needs by entering its mix number followed by the 'Y' command. (Note the object oriented style of commands, selecting the object first, followed by the command.) For example, '3456Y'. An operator can force a task into the waiting entries with the stop command '3456ST' and make it active again with OK: '3456OK'. The OK command can also be used when an operator has made a resource available for a task, although more frequently than not, the MCP will detect that resources have become available, CAUSE the EVENT that processes have been waiting on without further operator intervention. To pass textual information from an operator to a program, the accept command ‘3456AX MORE INFO’ can be used. Programs can pass information to operators using the DISPLAY mechanism, which causes DISPLAY messages to be added to the MSG display. As well as tasks and processes, operators also have control over files. Files can be listed using the FILE command, copied using COPY, removed using REMOVE, and renamed. The operating environment of the MCP is powerful, yet simple and usually only requires a fraction of the number of operators of other systems. An important part of the operations environment is the high level Work Flow Language.
Лесозаготовка
Все действия в системе протоколируются, например, все сообщения, отображаемые оператору, и все действия оператора. Все значимые действия программы могут быть протоколированы в системном журнале и журнале программы, например, BOJ для обозначения начала задания WFL, BOT – начала задачи в рамках задания WFL, EOT и EOJ – завершения задач и заданий. Также протоколируются все операции открытия и закрытия файлов и баз данных. Интенсивное протоколирование событий вносит вклад в кажущуюся медлительность операционной среды MCP по сравнению с системами, такими как Unix, поскольку все протоколируется с принудительной физической записью в журнал программы после каждой записи, чего системы, подобные Unix, не делают, хотя и они хранят множество данных в системных журналах. Журналы могут использоваться для проведения криминалистического анализа с целью выяснения причин сбоев программ или систем, а также для выявления попыток компрометации безопасности системы. Системные журналы автоматически закрываются по истечении периода времени, заданного в настройках системы, и открываются новые. Системные журналы содержат огромный объем информации, который можно фильтровать и анализировать с помощью программ, таких как LOGANALYZER. DUMPANALYZER анализирует дампы памяти, первоначально записанные на ленту. Поскольку все компиляторы добавляют LINEINFO в файлы кода, DUMPANALYZER способен точно определить, какая строка исходного кода выполнялась в момент возникновения ошибки. Кроме того, обычный дамп программы, содержащий информацию только об одной программе, включает данные о номере последовательности исходного кода и именах переменных. Оба анализатора являются важными диагностическими инструментами для решения широкого спектра задач.
All actions in the system are logged, for example all messages displayed to the operator, and all operator actions. All significant program actions are optionally logged in a system log and a program log, for example BOJ for beginning of a WFL job, BOT for beginning of a task within a WFL job, EOT and EOJ for end of tasks and jobs. As well, all file and database open and closes can be logged. Logging many events contributes to an apparent slowness of the MCP operating environment compared to systems like Unix, since everything is logged with forced physical writes to the program log after every record, which is what systems like Unix don't do, even though they too keep many things in the system logs. The logs can be used for forensics to find out why programs or systems may have failed, or for detecting attempts to compromise system security. System logs are automatically closed after a system settable period and a new one opened. System logs contain a huge amount of information, which can be filtered and analyzed with programs such as LOGANALYZER. The DUMPANALYZER analyzes memory dumps that were originally written to tape. As all compilers added LINEINFO into the code files, the DUMPANALYZER is able to pinpoint exactly which source statement was being executed at the time of error. Also a normal program dump, where just one program was dumped, contains information on source code sequence number and variable names. The two analyzers are major diagnostic tools for all kinds of purposes.
Инновации
Помимо множества технических инноваций в архитектуре MCP, большие системы Burroughs содержали ряд управленческих инноваций, которые сейчас широко используются интернет-сообществом. Системное программное обеспечение поставлялось клиентам вместе с исходным кодом и всеми инструментами редактирования и компиляции, необходимыми для создания новых версий MCP. Многие клиенты приобрели глубокие знания о внутреннем устройстве MCP и часто присылали "патчи" (небольшие фрагменты исходного кода с номерами последовательности) в качестве предложений по добавлению новых функций или исправлению ошибок (отчеты о проблемах в эксплуатации FTR). Многие из предложенных патчей принимались разработчиками и включались в следующую версию MCP. Привлечение сообщества добровольных, самопровозглашенных экспертов к основной технической работе стало широко распространенной практикой и является основой концепции открытых инноваций. Эта управленческая инновация, основанная на развитии сообщества, берет свое начало в 1970-х годах.
Beyond the many technical innovations in the MCP design, the Burroughs Large Systems had many management innovations now being used by the internet community at large. The system software was shipped to customers inclusive of source code and all the editing and compilation tools needed to generate new versions of MCP for customers. Many customers developed niche expertise on the inner workings of the MCP, and customers often sent in the 'patches' (fragment pieces of source code with sequence numbers) as suggestions of new enhanced features or fault corrections (FTR field trouble reports). Many of the suggested patches were included by the systems developers and integrated into the next version of the MCP release. Including a community of voluntary, self professed experts, into mainstream technical work, is now widely practised and is the essence of open innovation. This management innovation of community development dated back to the 1970s.
Сборщик
В операционной системе Unisys MCP отсутствует ассемблер.
There is no assembler on the Unisys MCP operating system.
Резюме
MCP была первой ОС, разработанной исключительно на языке высокого уровня. За свою 50-летнюю историю она стала пионером во многих коммерческих реализациях, включая виртуальную память, симметричную многопроцессорность и язык управления заданиями высокого уровня (WFL). Она на протяжении долгого времени обладала множеством функций, которые только сейчас появляются в других широко распространенных операционных системах, а в сочетании с архитектурой больших систем Burroughs, MCP предоставляет высокопроизводительную, многозадачную среду для обработки транзакций.
The MCP was the first OS developed exclusively in a high level language. Over its 50 year history, it has had many firsts in a commercial implementation, including virtual memory, symmetric multiprocessing, and a high level job control language (WFL). It has long had many facilities that are only now appearing in other widespread operating systems, and together with the Burroughs large systems architecture, the MCP provides a , high performance, multitasking and transaction processing environment.