Burroughs MCP

El MCP ( Master Control Program ) es el sistema operativo de los Burroughs B5000/B5500/B5700 y B6500 y sus sucesores , incluidos los sistemas Unisys Clearpath/MCP .

MCP se escribió originalmente en 1961 en ESPOL (Executive Systems Problem Oriented Language). En la década de 1970, MCP se convirtió a NEWP, que era una versión de ESPOL mejor estructurada, más robusta y más segura.

El MCP fue pionero en muchos ámbitos, entre ellos: fue el primer sistema operativo en gestionar múltiples procesadores, la primera implementación comercial de memoria virtual y el primer sistema operativo escrito exclusivamente en un lenguaje de alto nivel .

En 1961, el MCP fue el primer sistema operativo escrito exclusivamente en un lenguaje de alto nivel (HLL). El Burroughs Large System ( B5000 ^{[ 2 ]} y sus sucesores) fue único porque fue diseñado con la expectativa de que todo el software, incluido el software del sistema, se escribiría en un HLL en lugar de en lenguaje ensamblador , lo que representó un enfoque único e innovador en 1961.

A diferencia de IBM, que se enfrentó a la competencia del hardware tras la marcha de Gene Amdahl , el software de Burroughs solo funcionaba en su propio hardware debido a la falta de hardware compatible de terceros. Por este motivo, Burroughs podía distribuir libremente el código fuente de todo el software que vendía, incluido el MCP, diseñado con esta apertura en mente. Por ejemplo, para actualizarlo, el usuario tenía que recompilar el software del sistema y aplicar los parches locales necesarios. En aquel entonces, esta era una práctica común y necesaria, ya que no era raro que los clientes (sobre todo los grandes, como la Reserva Federal ) modificaran el programa para adaptarlo a sus necesidades específicas. ^{[ 3 ]} Como resultado, se formó un Grupo de Usuarios de Burroughs, que celebraba reuniones anuales y permitía a los usuarios intercambiar sus propias extensiones para el sistema operativo y otras partes del paquete de software. Muchas de estas extensiones se han incorporado al código base del sistema operativo a lo largo de los años y ahora están disponibles para todos los clientes. Por ello, el MCP podría considerarse uno de los primeros proyectos de código abierto .

Burroughs no fue el primer fabricante en distribuir código fuente y se incorporó tarde al mundo de la informática electrónica (en comparación con sus rivales tradicionales NCR , IBM y Univac ). Ahora que MCP funciona con hardware estándar, Unisys ya no distribuye en código fuente algunos elementos del paquete de software basado en MCP.

MCP fue el primer sistema operativo comercial en ofrecer memoria virtual , una funcionalidad que la arquitectura Burroughs Large Systems ha soportado desde sus inicios. Este esquema es único en la industria, ya que almacena y recupera objetos definidos por el compilador en lugar de páginas de memoria de tamaño fijo, como consecuencia de su arquitectura general no von Neumann y uniformemente basada en pila.

Donald Knuth también tuvo influencia durante este período, convirtiéndose en consultor de Burroughs Corporation y uniéndose al Departamento de Planificación de Productos de 1960 a 1968. Se refiere a "un programa de control" (presumiblemente el MCP que estaba en desarrollo en ese momento) en su libro "Algoritmos Fundamentales" en la sección 2.5 sobre Asignación Dinámica de Almacenamiento . Knuth se atribuye el mérito de "El método de "etiqueta de límite", introducido en la Sección 2.5, fue diseñado por el autor en 1962 para su uso en un programa de control para la computadora B5000". ^{[ 4 ] : 460}

Unisys dejó de producir el hardware a principios de la década de 2010, y el sistema operativo ahora se ejecuta mediante emulación. ^{[ 5 ]}

MCP proporciona un sistema de archivos con estructuras de directorios jerárquicas. En las primeras implementaciones de MCP, los nodos de directorio se representaban mediante archivos separados con entradas de directorio, como en otros sistemas. Sin embargo, desde aproximadamente 1970, MCP utiliza internamente un directorio "FLAT" que lista todas las rutas de archivo en un volumen. Esto se debe a que abrir archivos visitando y abriendo cada directorio en una ruta de archivo era ineficiente, y para un entorno de producción se consideró mejor mantener todos los archivos en un solo directorio, aunque conserven el esquema de nombres jerárquico. Programáticamente, esto no supone ninguna diferencia. La única diferencia visible para los usuarios es que un archivo de entidad puede tener el mismo nombre que un directorio. Por ejemplo, "A/B" y "A/B/C" pueden existir; "B" puede ser tanto un nodo en un archivo como un directorio.

Los archivos se almacenan en volúmenes con nombre, por ejemplo, 'este/es/un/nombre/de/archivo en myvol', donde 'myvol' es el nombre del volumen. Esto es independiente del dispositivo, ya que el disco que contiene 'myvol' se puede mover o copiar a diferentes unidades de disco físicas. Los discos también se pueden concatenar para que un solo volumen se pueda instalar en varias unidades, así como replicar para la recuperación de datos confidenciales. Para mayor flexibilidad, cada programa puede realizar sustituciones de volumen; un nombre de volumen se puede sustituir por un nombre alternativo principal y secundario. Esto se conoce como la FAMILIA del proceso. Por ejemplo, la asignación "FAMILIA DISK = USERPACK O SI NO" almacena los archivos designados lógicamente en el volumen DISK en el volumen USERPACK y buscará los archivos primero en el volumen USERPACK. Si esa búsqueda no tiene éxito, se realiza otra búsqueda del archivo en el volumen SYSPACK. DISK es el nombre de volumen predeterminado si no se especifica ninguno.

Cada archivo del sistema tiene un conjunto de atributos . Estos atributos registran diversos metadatos sobre el archivo, principalmente su nombre y su tipo (que indica al sistema cómo gestionarlo, como el código de tipo de archivo de cuatro caracteres más limitado en Macintosh ). Otros atributos incluyen el tamaño del registro del archivo (si es fijo para aplicaciones comerciales), el tamaño del bloque (en múltiplos de registros, que indica al MCP cuántos registros leer y escribir en una sola operación de E/S física) y un tamaño de área en múltiplos de bloques, que define el tamaño de las áreas de disco que se asignarán a medida que el archivo se expande.

El tipo de archivo indica si se trata de datos de caracteres, código fuente escrito en lenguajes específicos, datos binarios o archivos de código.

Los archivos están protegidos por los mecanismos de acceso de seguridad habituales, como público o privado, o bien un archivo puede tener un archivo de protección donde el propietario puede especificar reglas de seguridad complejas.

Otro mecanismo de seguridad es que los archivos de código solo pueden ser creados por compiladores de confianza. Los programadores malintencionados no pueden crear un programa y llamarlo compilador; un programa solo podría convertirse en un compilador mediante un operador con los privilegios suficientes utilizando el comando 'mc' make compiler operator.

El MCP implementa un sistema de archivos con registro de transacciones , lo que proporciona tolerancia a fallos en caso de fallo del disco, pérdida de energía, etc. No es posible corromper el sistema de archivos (excepto por el sistema operativo u otro software de sistema de confianza con acceso directo a sus capas inferiores) .

El sistema de archivos no distingue entre mayúsculas y minúsculas y no las conserva a menos que se agreguen comillas alrededor del nombre, en cuyo caso sí distingue entre mayúsculas y minúsculas y las conserva.

Los procesos de MCP se denominan " Trabajos " y " Tareas ". Un Trabajo contiene una o más tareas. Las tareas dentro de un trabajo pueden ejecutarse de forma secuencial o en paralelo. Se puede implementar lógica a nivel de Trabajo, generalmente en el lenguaje de control de trabajos WFL de MCP, para controlar el flujo del trabajo. Una vez que todas las tareas de un trabajo se completan, el trabajo en sí finaliza.

Un proceso MCP sigue un ciclo de vida desde que ingresa al sistema hasta que lo abandona. El estado inicial de un trabajo es "En cola". Durante un tiempo, el trabajo permanece en una de las colas de trabajos definidas por el usuario. El siguiente estado es "Programado" cuando el trabajo pasa de la cola a la memoria. Las tareas dentro de un trabajo no esperan en la cola; en su lugar, pasan directamente al estado "Programado" al iniciarse. Una vez que un trabajo o tarea se inicia, puede pasar de "Activo", "En espera" y "Programado" a medida que avanza. Una vez que un trabajo o tarea se completa, pasa al estado "Completado".

Los procesos en ejecución son aquellos que utilizan un recurso del procesador y están marcados como "en ejecución". Los procesos que están listos para ser asignados a un procesador, cuando no hay ninguno libre, se colocan en la cola de listos. A los procesos se les puede asignar una prioridad "Declarada" o "Visible", generalmente 50 como valor predeterminado, pero puede ser de 0 a 99 para los procesos de usuario. A los procesos del sistema se les pueden asignar valores más altos. Tenga en cuenta que esta prioridad numérica es secundaria a una prioridad general, que se basa en el tipo de tarea. Los procesos que son parte directa del sistema operativo, llamados Ejecutores Independientes, tienen la prioridad más alta independientemente del valor de prioridad numérica. A continuación vienen los procesos que utilizan un bloqueo MCP, luego los Sistemas de Control de Mensajes como CANDE . Luego los procesos descontinuados. Luego los trabajos del Lenguaje de Flujo de Trabajo. Finalmente, vienen los procesos de usuario. En un nivel inferior, hay una prioridad Fina destinada a elevar la prioridad de las tareas que no utilizan su porción completa del procesador. Esto permite que una tarea limitada por E/S obtenga tiempo de procesador antes que una tarea limitada por el procesador con la misma prioridad declarada.

Los procesos que esperan otros recursos, como la lectura de un archivo, esperan en la estructura de datos EVENT . Por lo tanto, todos los procesos que esperan un único recurso esperan un único evento. Cuando el recurso está disponible, se activa el evento, que despierta a todos los procesos que lo esperan. Los procesos pueden esperar varios eventos, incluido un tiempo de espera. Los eventos son totalmente programables por el usuario; es decir, los usuarios pueden escribir sistemas que utilicen el sistema de eventos generalizado proporcionado por MCP.

Los procesos que han finalizado se marcan como completados.

Desde el punto de vista operativo, el estado de todas las tareas del sistema se muestra al operador. Todos los procesos en ejecución y listos se muestran como tareas "activas" (dado que el sistema implementa multitarea preventiva , el cambio de listo a en ejecución y viceversa es tan rápido que no tiene sentido distinguir entre tareas listas y en ejecución, ya que todas obtendrán una porción del procesador en menos de un segundo). Todas las tareas activas se pueden visualizar con el comando "A".

Las tareas terminadas se muestran como tareas completadas con el motivo de la terminación, EOT para "fin de tarea" normal y DSed con el motivo de un fallo del proceso. A todos los procesos se les asigna un número de mezcla, y los operadores pueden usar este número para identificar un proceso que controlar. Un ejemplo de este comando es el comando DS (que significa Eliminar de la programación, Discontinuar o Deep Six, debido a la influencia del personal de la Marina en los primeros proyectos informáticos, según a quién se pregunte). Las tareas terminadas por el operador se listan en las entradas completas como O-DS.

Las tareas también pueden finalizar debido a fallos del programa, marcados como F-DS o P-DS, por ejemplo, índice no válido , desbordamiento numérico , etc. El operador puede listar las entradas completadas con el comando 'C'.

Las tareas que esperan un recurso se muestran en la lista de tareas en espera, junto con el motivo de la espera. Todas las tareas en espera se pueden consultar con el comando 'W'. El motivo de la espera también se muestra y se puede obtener más información sobre una tarea con el comando 'Y'. Es posible que una tarea esté esperando la entrada del operador, que se envía a la tarea mediante el comando de aceptación 'AX' (tenga en cuenta que la entrada del operador es muy diferente de la entrada del usuario, que se realiza desde un dispositivo de red con interfaz gráfica de usuario).

Las tareas que esperan la entrada del usuario o la lectura de archivos normalmente no se listan como entradas en espera que requieren la atención del operador. Otra razón por la que una tarea puede estar en espera es la espera de un archivo. Cuando un proceso abre un archivo y este no está presente, la tarea se coloca en las entradas en espera, indicando que está esperando un archivo específico. Un operador (o el usuario propietario del proceso) tiene la oportunidad de copiar el archivo a la ubicación esperada, redirigir la tarea para que lea el archivo desde otra ubicación, o incluso el archivo podría ser creado por un proceso independiente que aún no ha finalizado.

Si el operador no puede proporcionar el recurso, puede ejecutar la tarea en segundo plano como último recurso. Esto difiere de otros sistemas, que finalizan automáticamente una tarea cuando un recurso, como un archivo, no está disponible. El MCP ofrece este nivel de recuperabilidad de tareas por parte del operador. Otros sistemas obligan a los programadores a añadir código para comprobar la presencia de archivos antes de acceder a ellos, lo que implica escribir código adicional en cada caso para garantizar la recuperabilidad o la sincronización del proceso. En un programa MCP, este código puede escribirse cuando no se desea que una tarea espere, pero gracias a la recuperabilidad a nivel de operador, esto no es obligatorio, lo que simplifica enormemente la programación.

Además de la capacidad de reasignar dinámicamente las solicitudes de archivos (o bases de datos) a otros archivos (o bases de datos), antes o durante la ejecución del programa, existen varios mecanismos que permiten a los programadores detectar y recuperarse de errores. Una de estas opciones, la instrucción 'ON', se utiliza desde hace muchos años. Se pueden especificar fallos concretos (por ejemplo, división por cero) o utilizar la instrucción genérica 'anyfault'. El compilador reconoce la instrucción o el bloque que sigue a la instrucción 'ON' como código de gestión de fallos. Durante la ejecución, si se produce un fallo recuperable dentro del ámbito de la instrucción 'ON', la pila se vacía y el control se transfiere a la instrucción siguiente.

Un problema con la lógica de manejo de la instrucción ON era que solo se invocaba para fallos del programa, no para terminaciones con otras causas. Con el tiempo, se hizo necesaria la gestión garantizada de las terminaciones anormales. En particular, se requería un mecanismo que permitiera a los programas invocar complementos escritos por clientes o terceros sin riesgo alguno en caso de que el complemento se comportara mal. Además de los mecanismos generales de complementos, la nueva forma de enlace dinámico de bibliotecas ( Bibliotecas de Conexión ) permite a los programas importar y exportar funciones y datos, y por lo tanto, un programa ejecuta código proporcionado por otro.

Para lograr una mayor protección, a mediados de la década de 1990 se introdujo un mecanismo más novedoso. En un intento desacertado por lograr compatibilidad, se le dio el mismo nombre que a la construcción del lenguaje C++ que se proponía en aquel entonces . Debido a que la sintaxis y el comportamiento de ambas difieren enormemente, elegir el mismo nombre solo ha generado confusión y malentendidos.

Sintácticamente, las sentencias `try` se parecen a las sentencias `if`: `try`, seguido de una sentencia o bloque, seguido de `else` y otra sentencia o bloque. Pueden añadirse cláusulas `else` adicionales. Durante la ejecución, si se produce una terminación recuperable en el código que sigue a la cláusula `try`, la pila se reduce si es necesario y el control salta al código que sigue al primer `else`. Además, se establecen atributos para que el programa pueda determinar qué ocurrió y dónde (incluido el número de línea específico).

La mayoría de los eventos que provocarían la terminación de una tarea son recuperables. Esto incluye desbordamiento de pila , acceso fuera de límites a matrices , desbordamiento/subdesbordamiento de enteros , etc. El DS del operador (o usuario) no es recuperable, excepto mediante tareas privilegiadas que utilicen una forma INSEGURA de try.

De este modo, MCP proporciona un entorno muy tolerante a fallos , a diferencia del volcado de memoria que se produce al bloquearse y quemarse, como ocurre en otros sistemas.

Al igual que los atributos de archivo, las tareas también tienen atributos, como la prioridad (que se asigna en tiempo de compilación o ejecución, o puede modificarse durante su ejecución), el tiempo de procesador, el tiempo de espera, el estado, etc. Se puede acceder a estos atributos de tarea mediante programación, al igual que a los atributos de archivo. La tarea principal está disponible mediante programación como un atributo de tarea de tipo tarea. Por ejemplo, 'myself.initiator.name' proporciona el nombre del proceso que inició el proceso actual.

GETSPACEy FORGETSPACEson los dos procedimientos principales que manejan la asignación y liberación de memoria. La memoria debe asignarse al inicio del proceso y cada vez que se ingresa a un bloque que utiliza matrices, archivos, etc. GETSPACEy FORGETSPACEno solo manejan el espacio de memoria, sino que también asignan o liberan el espacio en disco donde se pueden superponer datos no residentes en memoria. La memoria puede ser SAVE (es decir, residente en memoria), OVERLAYABLE (es decir, memoria virtual) o STICKY (es decir, residente en memoria, pero movible). Se llaman, por ejemplo, HARDWAREINTERRUPTcuando un proceso accede a una matriz no inicializada o por FILEOPEN.

HARDWAREINTERRUPTmaneja interrupciones de hardware y puede llamar a GETSPACE, IO_FINISHo similares.

BLOCKEXITes invocado por una tarea que sale de un bloque. BLOCKEXIT puede a su vez llamar a FILECLOSE, FORGETSPACEo similar mientras limpia y libera los recursos declarados y utilizados dentro de ese bloque.

J_EDGAR_HOOVER es el principal guardián de seguridad del sistema, al que se recurre al iniciar un proceso, abrir un archivo, iniciar sesión un usuario, etc.

GEORGEes el procedimiento que decide qué proceso es el siguiente en recibir recursos de CPU y, por lo tanto, es uno de los pocos procesos que utiliza la instrucción MoveStack.

Una tarea pasa por varios estados, comenzando con NASCENT. En DELIVERY se produce el evento BIRTH y el estado de la tarea cambia a ALIVE. Cuando se llama a PROCESSKILL, el estado cambia a DISEASED. Cuando se produce DEATH, la tarea se coloca en la estructura de cola MORGUE, tras lo cual todos los recursos restantes se liberan al sistema mediante un proceso llamado PROCESSKILL.

Mientras la tarea está activa, las funciones de MCP se ejecutan sobre ese proceso en particular, por lo que los recursos de la CPU se asignan automáticamente a la tarea, lo que genera la sobrecarga de MCP. Además, gran parte del trabajo de MCP se realiza con los permisos de seguridad de esa pila específica. Solo antes de BIRTH y después de DEATH, MCP necesita operar desde otra pila. Si no hay ninguna disponible, el sistema mantiene una pila inactiva.

Las bibliotecas MCP proporcionan una forma de compartir datos y código entre procesos. El artículo sobre sistemas grandes de Burroughs analiza cómo se podrían ejecutar procesos dependientes de forma asíncrona para que muchos procesos pudieran compartir datos comunes (con mecanismos para proporcionar actualizaciones sincronizadas). Dicha familia de procesos relacionados debía escribirse como una única unidad de programa, procesando procedimientos en niveles lex superiores como procesos asíncronos, que aún podían acceder a variables globales y otras variables en niveles lex inferiores.

Las bibliotecas invirtieron por completo este escenario con las siguientes ventajas:

• Las bibliotecas y los procesos independientes se escriben como unidades de programación independientes.
• Las bibliotecas controlaban completamente el acceso a los recursos compartidos ( encapsulación y ocultación de datos ).
• Las bibliotecas y los clientes podrían estar escritos en diferentes idiomas.
• No fue necesario cambiar de proceso para acceder a los datos de forma segura.

El mecanismo de la biblioteca era tan limpio y revolucionario que gran parte del software del sistema tuvo que ser reescrito en profundidad, lo que dio como resultado sistemas mejor estructurados y mejoras en el rendimiento.

Las bibliotecas se introdujeron en los sistemas MCP a principios de la década de 1980, desarrolladas por Roy Guck y otros en Burroughs . Son muy similares a los monitores de CAR Hoare y ofrecen la posibilidad de exclusión mutua controlada y sincronización entre procesos cliente, utilizando eventos MCP y la técnica de bloqueo de Dahm. Las bibliotecas ofrecen puntos de entrada procedimentales al cliente, que se verifican para comprobar la compatibilidad de la interfaz (se comprueban todos los parámetros y tipos de retorno de los procedimientos importados) antes de que el cliente se vincule a la biblioteca. La biblioteca y su cliente pueden estar escritos en lenguajes diferentes. La ventaja es que toda la sincronización se proporciona en la biblioteca y el código cliente no necesita preocuparse por este nivel de programación. Esto da como resultado un código robusto, ya que los clientes no pueden vulnerar el código de sincronización de la biblioteca. (Algunos lo denominan una « Iniciativa de Computación Confiable »).

Las bibliotecas son versiones más sofisticadas de las bibliotecas de otros sistemas, como las DLL . Las bibliotecas MCP pueden ser compartidas por todos, compartidas por la unidad de ejecución o privadas. El caso privado es el más similar a las bibliotecas de otros sistemas: para cada cliente se invoca una copia independiente de la biblioteca y no hay intercambio de datos entre procesos.

El hecho de que sea compartido por todos resulta más interesante. Cuando un cliente se inicia, puede ejecutarse durante un tiempo hasta que necesite los servicios de la biblioteca. Al acceder por primera vez a un punto de entrada de la biblioteca, se inicia la vinculación. Si ya hay una instancia de la biblioteca en ejecución, el cliente se vincula a dicha instancia. Todos los clientes comparten la misma instancia.

El mecanismo de compartición por unidad de ejecución se sitúa entre estos dos esquemas de compartición. Fue diseñado específicamente para COBOL, donde una unidad de ejecución se define como el programa cliente inicial original y todas las bibliotecas con las que está enlazado. Cada unidad de ejecución obtiene una instancia de la biblioteca, y las distintas unidades de ejecución obtienen una instancia diferente. Esta es la única implementación dinámica de las unidades de ejecución de COBOL.

Si se tratara de la primera invocación de la biblioteca, esta ejecutaría su programa principal (bloque externo en un programa ALGOL) para inicializar su entorno global. Una vez completada la inicialización, ejecutaría un bloqueo, momento en el que todos los puntos de entrada exportados estarían disponibles para los clientes. En este punto, se decía que la pila de la biblioteca estaba bloqueada, ya que no se ejecutaría nada más en ella hasta que la biblioteca se desbloqueara, momento en el que se ejecutaría el código de limpieza y terminación. Cuando un cliente llama a una rutina de una biblioteca, dicha rutina se ejecuta sobre la pila del cliente, almacenando allí sus variables locales y temporales. Esto permite que muchos clientes ejecuten la misma rutina simultáneamente, sincronizados por la rutina de la biblioteca, que accede a los datos en el entorno global de la pila de la biblioteca.

El bloqueo podía presentarse de tres formas: temporal, permanente y controlado. Temporal significaba que, una vez que el número de clientes llegara a cero, la biblioteca se desbloquearía y finalizaría. Permanente significaba que la biblioteca permanecía disponible para otros clientes incluso si el número de clientes llegaba a cero; las bibliotecas permanentes podían ser desbloqueadas por un operador con el comando THAW. Un bloqueo controlado significaba que la biblioteca seguía en funcionamiento, de modo que podía ejecutar funciones de monitorización y realizar funciones de inicialización y limpieza de datos para cada cliente de enlace.

También se podía acceder a las bibliotecas "por título" y "por función". En el método "por título", el cliente especificaba el nombre del archivo de la biblioteca. El método "por función" era indirecto: el cliente simplemente especificaba el nombre de la función de la biblioteca, por ejemplo, "system_support", y la ubicación real de la biblioteca se encontraba en una tabla previamente configurada por un operador con comandos "SL" (biblioteca del sistema), por ejemplo, "SL system_support = *system/library/support". La tolerancia a fallos de MCP también funciona aquí: si un cliente intenta acceder a una biblioteca que no está presente, se le asignan tareas en espera y se puede habilitar la biblioteca o redirigir la solicitud.

Las bibliotecas también se pueden actualizar sobre la marcha; basta con agregar la nueva versión mediante la función 'SL'. Los clientes en ejecución seguirán utilizando la versión anterior hasta que finalicen su sesión, y los nuevos clientes serán redirigidos a la nueva versión.

Las bibliotecas de funciones también implementaron una característica de seguridad muy importante: las clases de enlace. Todas las bibliotecas normales tienen una clase de enlace de cero. Las bibliotecas utilizadas por el MCP u otros módulos del sistema privilegiados pueden no ser accesibles desde programas normales. Se accede a ellas mediante funciones y se fuerzan a la clase de enlace uno. Un cliente con clase de enlace cero no puede enlazar con puntos de entrada de clase de enlace uno. Una biblioteca con clase de enlace uno que necesite ofrecer puntos de entrada a programas normales puede hacerlo si se designa como "de confianza". Puede ofrecer puntos de entrada seleccionados en la clase de enlace cero.

Todo el sistema de bases de datos se implementa con bibliotecas que proporcionan un acceso muy eficiente y personalizado a bases de datos compartidas entre múltiples clientes. Lo mismo ocurre con todas las funcionalidades de red y los elementos intrínsecos del sistema.

A mediados de la década de 1990, se puso a disposición un nuevo tipo de biblioteca: las bibliotecas de conexión. Se trata de programas independientes que pueden ejecutarse por sí mismos, además de importar y exportar datos y funciones a otros programas mediante matrices de bloques de estructura. Por ejemplo, el componente de red del sistema operativo está disponible como una biblioteca de conexión, lo que permite a otros programas utilizar sus servicios exportando e importando funciones. Tras la vinculación, cada cliente obtiene un bloque de estructura dedicado para almacenar información de estado. Un programa que utiliza la red podría importar una función de escritura de red y exportar una función de lectura de red. De este modo, si se abre una conexión de red (por ejemplo, mediante TCP ), cuando llegan datos para leer, el componente de red puede llamar directamente a la función para consumirlos, sin necesidad de copiar primero los datos a un búfer ni realizar un cambio de contexto . Del mismo modo, se pueden escribir datos en la red llamando directamente a una función de escritura de red.

Las bibliotecas de conexión permiten un control significativo sobre los enlaces. Cada participante en un enlace puede aprobarlo opcionalmente y romperlo según lo desee. El estado se puede mantener fácilmente tanto para cada enlace como a nivel global.

Otra técnica para la comunicación entre procesos (IPC) son los archivos de puerto. Son similares a las tuberías de Unix , pero están generalizados para ser multidireccionales y bidireccionales. Dado que son mucho más lentos que otras técnicas de IPC, como las bibliotecas, es preferible utilizar otras técnicas donde la comunicación se produce entre diferentes procesos en la misma máquina.

Por lo tanto, el uso más ventajoso de los archivos de puerto es para la comunicación entre procesos distribuida (IPC). Los archivos de puerto se introdujeron con BNA (Burroughs Network Architecture), pero con la llegada de tecnologías de red estándar como TCP / IP , también se pueden usar con estas redes.

Un servidor que escucha conexiones entrantes declara un archivo de puertos (un archivo con el atributo KIND igual a PORT). Cada conexión que realiza un cliente crea un subarchivo con un índice, por lo que cada archivo de puertos representa múltiples conexiones a diferentes clientes en la red.

Un proceso de servidor recibe solicitudes de clientes desde cualquier punto de la red mediante una operación de lectura en el archivo del puerto (subarchivo = 0 para leer desde cualquier subarchivo). Emite una respuesta al cliente que realizó la solicitud escribiendo en el subarchivo específico desde el que se leyó la solicitud.

El MCP también proporciona un entorno de operador sofisticado pero sencillo. En instalaciones grandes, puede ser necesario contar con varios operadores para gestionar recursos físicos como impresoras (carga de papel, cartuchos de tóner, etc.). En entornos más sencillos, como oficinas pequeñas o para un solo usuario, puede ser necesario un entorno sin operador (especialmente en la implementación con ordenador portátil).

Los sistemas grandes cuentan con terminales de operación dedicadas, denominadas ODT (Operator Display Terminals), que suelen estar ubicadas en un entorno seguro. En sistemas pequeños, las máquinas pueden controlarse desde cualquier terminal (siempre que tanto la terminal como el usuario tengan los privilegios suficientes) mediante el programa MARC (Menu Assisted Resource Control). Los usuarios familiarizados con los comandos del operador también pueden utilizarlos.

Los comandos de operador constan principalmente de dos letras (como en Unix), aunque algunos solo tienen una. Esto implica que es necesario aprender la interfaz de operador, pero resulta muy eficiente para operadores experimentados que gestionan un sistema mainframe de gran tamaño a diario. Los comandos no distinguen entre mayúsculas y minúsculas.

Las tareas se introducen en el programa «mix» y se identifican mediante números de mezcla, al igual que las bibliotecas. Para ejecutar un programa, los operadores pueden usar el comando «EX» o «RUN» seguido del nombre del archivo del programa. Los ODT se ejecutan normalmente con ADM (Modo de Visualización Automática), que es una visualización personalizable del estado del sistema, generalmente configurada para mostrar las entradas de mezcla activas, en espera y completadas, así como mensajes del sistema para el operador en caso de notificaciones o situaciones que requieran su intervención.

La lista completa de estas pantallas se proporciona mediante las letras 'A' (activo), 'W' (en espera), 'C' (completado) y 'MSG' (comandos de mensaje).

Si una tarea queda en espera de alguna acción del operador, este puede averiguar qué necesita la tarea introduciendo su número de mezcla seguido del comando 'Y'. (Observe el estilo de comandos orientado a objetos: primero se selecciona el objeto y luego el comando). Por ejemplo, '3456Y'.

Un operador puede forzar una tarea a las entradas en espera con el comando de parada '3456ST' y volver a activarla con OK: '3456OK'. El comando OK también se puede usar cuando un operador ha puesto un recurso a disposición de una tarea, aunque, en la mayoría de los casos, el MCP detectará que los recursos están disponibles y CAUSARÁ el EVENTO que los procesos han estado esperando sin más intervención del operador. Para pasar información textual de un operador a un programa, se puede usar el comando de aceptación '3456AX MORE INFO'. Los programas pueden pasar información a los operadores mediante el mecanismo DISPLAY, que hace que los mensajes DISPLAY se añadan a la pantalla MSG.

Además de las tareas y los procesos, los operadores también controlan los archivos. Pueden listarlos con el comando FILE, copiarlos con COPY, eliminarlos con REMOVE y cambiarles el nombre.

El entorno operativo del MCP es potente, a la vez que sencillo, y normalmente solo requiere una fracción del número de operadores que otros sistemas.

Una parte importante del entorno operativo es el lenguaje de flujo de trabajo de alto nivel .

Todas las acciones del sistema se registran , por ejemplo, todos los mensajes mostrados al operador y todas sus acciones. Opcionalmente, todas las acciones importantes del programa se registran en un registro del sistema y en un registro del programa; por ejemplo, BOJ para el inicio de un trabajo WFL, BOT para el inicio de una tarea dentro de un trabajo WFL, EOT y EOJ para el final de tareas y trabajos . Además, se pueden registrar todas las aperturas y cierres de archivos y bases de datos. El registro de muchos eventos contribuye a una aparente lentitud del entorno operativo MCP en comparación con sistemas como Unix , ya que todo se registra con escrituras físicas forzadas en el registro del programa después de cada registro, algo que sistemas como Unix no hacen, aunque también almacenan mucha información en los registros del sistema.

Los registros del sistema pueden utilizarse para análisis forense con el fin de determinar las causas de fallos en programas o sistemas, o para detectar intentos de vulnerar la seguridad del sistema . Los registros se cierran automáticamente tras un periodo configurable por el sistema y se abre uno nuevo. Estos registros contienen una gran cantidad de información que puede filtrarse y analizarse con programas como LOGANALYZER.

DUMPANALYZER analiza los volcados de memoria que se grabaron originalmente en cinta. Dado que todos los compiladores añadieron información de línea (LINEINFO) a los archivos de código, DUMPANALYZER puede identificar con precisión qué instrucción del código fuente se estaba ejecutando en el momento del error.

Asimismo, un volcado de programa normal, en el que solo se volcó un programa, contiene información sobre el número de secuencia del código fuente y los nombres de las variables.

Los dos analizadores son herramientas de diagnóstico fundamentales para todo tipo de propósitos.

Más allá de las numerosas innovaciones técnicas en el diseño de MCP, Burroughs Large Systems implementó muchas innovaciones de gestión que ahora utiliza la comunidad de internet en general. El software del sistema se enviaba a los clientes con el código fuente y todas las herramientas de edición y compilación necesarias para generar nuevas versiones de MCP. Muchos clientes desarrollaron conocimientos especializados sobre el funcionamiento interno de MCP y, a menudo, enviaban «parches» (fragmentos de código fuente con números de secuencia) como sugerencias de nuevas funciones mejoradas o correcciones de fallos (FTR - informes de problemas de campo). Muchos de los parches sugeridos fueron incluidos por los desarrolladores del sistema e integrados en la siguiente versión de MCP. La inclusión de una comunidad de expertos voluntarios y autoproclamados en el trabajo técnico convencional es una práctica común hoy en día y constituye la esencia de la innovación abierta . Esta innovación de gestión del desarrollo comunitario se remonta a la década de 1970.

Unisys MCP ha tenido varias generaciones de compiladores a lo largo de su historia, compatibles con una amplia variedad de lenguajes de programación , entre los que se incluyen:

• ALGOL , ^{[ 6 ]} incluyendo DCALGOL, BDMSALDOL y DMALGOL.
• C ^{[ 7 ]}
• COBOL que incluye COBOL74 ^{[ 8 ]} y COBOL85 ^{[ 9 ]}
• Fortran77 ^{[ 10 ]}
• NUEVO ^{[ 11 ]}
• Pascal ^{[ 12 ]}
• Juego de rol ^{[ 13 ]}

Otros productos incluyen:

• Carpeta ^{[ 14 ]}
• Lenguaje de definición de red ^{[ 15 ]}
• Lenguaje de flujo de trabajo ^{[ 16 ]}

Anteriormente existían compiladores para ESPOL , COBOL(68), Fortran(66), APL y PL/I .

El MCP fue el primer sistema operativo desarrollado exclusivamente en un lenguaje de alto nivel. A lo largo de sus 50 años de historia, ha sido pionero en numerosas implementaciones comerciales, como la memoria virtual, el multiprocesamiento simétrico y un lenguaje de control de trabajos de alto nivel (WFL). Desde hace tiempo, cuenta con muchas funcionalidades que ahora están apareciendo en otros sistemas operativos de uso generalizado, y junto con la arquitectura Burroughs Large Systems, el MCP proporciona un entorno de procesamiento de transacciones y multitarea de alto rendimiento y muy seguro .

• Documentación de MCP 21.0 : acceso gratuito, pero puede requerir el reconocimiento de los derechos de autor.