El MCP (Master Control Program) es el sistema operativo de Burroughs B5000/B5500/B5700 y B6500 y sus sucesores , incluidos los sistemas Unisys Clearpath/MCP .
MCP fue escrito originalmente en 1961 en ESPOL (Lenguaje orientado a problemas de sistemas ejecutivos). En la década de 1970, MCP se convirtió en NEWP , que era una forma de ESPOL mejor estructurada, más sólida y más segura.
El MCP fue líder en muchas áreas, entre ellas: el primer sistema operativo que administraba 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, MCP fue el primer sistema operativo escrito exclusivamente en un lenguaje de alto nivel (HLL). El Burroughs Large System ( B5000 [2] y sucesores) fueron únicos porque fueron diseñados con la expectativa de que todo el software, incluido el software del sistema, se escribiera en un HLL en lugar de en lenguaje ensamblador , lo cual fue un enfoque único e innovador en 1961.
A diferencia de IBM, que enfrentó competencia de hardware después de la salida de Gene Amdahl , el software de Burroughs solo se ejecutó en hardware de Burroughs debido a la falta de hardware de terceros compatible. Por esta razón, Burroughs tenía libertad para distribuir el código fuente de todo el software que vendía, incluido el MCP, que fue diseñado teniendo en cuenta esta apertura. Por ejemplo, la actualización requería que el usuario volviera a compilar el software del sistema y aplicara los parches locales necesarios. En ese momento, esta era una práctica común y era necesaria, ya que no era inusual que los clientes (especialmente 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 celebró reuniones anuales y permitió a los usuarios intercambiar sus propias extensiones del sistema operativo y otras partes del paquete de software del sistema. Muchas de estas extensiones han llegado al código base del sistema operativo a lo largo de los años y ahora están disponibles para todos los clientes. Como tal, 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 entró tarde a la informática electrónica (en comparación con sus rivales tradicionales NCR, IBM y Univac). Ahora que MCP se ejecuta en hardware básico, Unisys ya no ofrece algunos elementos del paquete de software basado en MCP en formato fuente.
El MCP fue el primer sistema operativo comercial que proporcionó memoria virtual , que ha sido respaldada por la arquitectura de grandes sistemas de Burroughs 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 basada uniformemente en pilas.
Unisys dejó de producir el hardware a principios de la década de 2010 y el sistema operativo ahora se ejecuta bajo emulación. [4]
El MCP proporciona un sistema de archivos con estructuras de directorios jerárquicas. En las primeras implementaciones de MCP, los nodos de directorio estaban representados por archivos separados con entradas de directorio, como lo hacían otros sistemas. Sin embargo, desde aproximadamente 1970, MCP utiliza internamente un directorio 'FLAT' que enumera todas las rutas de archivos 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 descubrió que era mejor mantener todos los archivos en un solo directorio, aunque conserven el esquema de nombres jerárquico. Programáticamente, esto no hace 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 ambos; "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', siendo 'myvol' 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 se pueda instalar un solo volumen en varias unidades, así como duplicarse para recuperar datos confidenciales. Para mayor flexibilidad, cada programa puede realizar sustituciones de volúmenes; el nombre de un volumen se puede sustituir por un nombre alternativo primario y secundario. Esto se conoce como el proceso 'FAMILIA'. Por ejemplo, la asignación “DISCO FAMILIAR = USERPACK DE OTRA MANERA SYSPACK” almacena los archivos designados lógicamente en el volumen DISCO en el volumen USERPACK y buscará primero los archivos 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 en el sistema tiene un conjunto de atributos de archivo. Estos atributos registran todo tipo de metadatos sobre un archivo, lo más importante es su nombre y su tipo (que le indica al sistema cómo manejar un archivo, como el código de tipo de archivo más limitado de cuatro caracteres en Macintosh ) . Otros atributos tienen el tamaño de registro del archivo (si está fijado para aplicaciones comerciales), el tamaño de bloque (en múltiplos de registros que le indica al MCP cuántos registros leer y escribir en una sola IO física) y un tamaño de área en múltiplos de bloques, que proporciona el tamaño de las áreas del disco que se asignarán a medida que se expande el archivo.
El tipo de archivo indica si el archivo son datos de caracteres o código fuente escrito en idiomas particulares, datos binarios o archivos de código.
Los archivos están protegidos por los mecanismos de acceso de seguridad habituales, como públicos o privados, o 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 confiables. Los programadores maliciosos no pueden crear un programa y llamarlo compilador; un programa sólo puede ser convertido en compilador por un operador con privilegios suficientes con el comando de operador del compilador 'mc' make.
El MCP implementa un sistema de archivos Journaling , que proporciona tolerancia a fallas en caso de falla 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 confiable con acceso directo a sus capas inferiores). ) [ cita necesaria ] .
El sistema de archivos no distingue entre mayúsculas y minúsculas y no las preserva a menos que se agreguen comillas alrededor del nombre, en cuyo caso distingue entre mayúsculas y minúsculas y las preserva.
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. La lógica se puede implementar a nivel de trabajo, generalmente en el lenguaje de control de trabajos WFL del MCP, para controlar el flujo de un trabajo. Una vez que se completan todas las tareas de un trabajo, el trabajo en sí se completa.
Un proceso MCP pasa por un ciclo de vida desde que ingresa al sistema hasta que sale. El estado inicial de un trabajo es "En cola". Hay un período de tiempo durante el cual el trabajo reside en una de varias colas de trabajos definidas por el usuario. El siguiente estado es "Programado" cuando el trabajo pasa de una cola a la memoria. Las tareas dentro de un trabajo no esperan en cola; en lugar de eso, pasa directamente al estado "Programado" cuando se inicia. Una vez que se inicia un trabajo o tarea, puede pasar de "activo", "en espera" y "programado" a medida que avanza. Una vez que se completa un trabajo o tarea, 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 ningún procesador 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 los valores más altos. Tenga en cuenta que esta prioridad numérica es secundaria respecto de una prioridad general, que se basa en el tipo de tarea. Los procesos que forman parte directamente del sistema operativo, llamados corredores independientes, tienen la prioridad más alta independientemente del valor de prioridad numérico. Luego vienen los procesos que utilizan un bloqueo MCP, luego los sistemas de control de mensajes como CANDE . Luego procesos discontinuados. Luego trabajos de 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 vinculada a IO obtenga tiempo de procesador antes que una tarea vinculada al procesador con la misma prioridad declarada.
Los procesos que están esperando otros recursos, como la lectura de un archivo, esperan la estructura de datos EVENTO . Por tanto, todos los procesos que esperan un único recurso esperan un único evento. Cuando el recurso está disponible, se provoca el evento, que activa todos los procesos que lo esperan. Los procesos pueden esperar múltiples eventos hasta que ocurra cualquiera de ellos, 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 terminado 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 ejecutar y viceversa es tan rápido que distinguir las tareas listas y en ejecución no tiene sentido porque todas obtendrán una porción del procesador dentro un segundo). Todas las tareas activas se pueden mostrar con el comando 'A'.
Las tareas terminadas se muestran como tareas completadas con el motivo de la terminación, EOT para el "fin de tarea" normal y DSed con el motivo de una falla del proceso. A todos los procesos se les asigna un número combinado y los operadores pueden usar este número para identificar un proceso a controlar. Uno de esos comandos es el comando DS (que significa Eliminar del programa, Discontinuar o Deep Six, en honor a la influencia del personal de la Marina en los primeros proyectos informáticos, dependiendo de con quién se hable). Las tareas finalizadas por el operador se enumeran en las entradas completas como O-DS.
Las tareas también pueden finalizar debido a fallas del programa, marcadas como F-DS o P-DS, por fallas como índice no válido , desbordamiento numérico , etc. El operador puede enumerar las entradas completadas con el comando 'C'.
Las tareas en espera en un recurso se enumeran debajo de las entradas en espera y el motivo de la espera. Todas las tareas en espera pueden enumerarse con el comando 'W'. También se enumera el motivo de la espera y se puede ver más información sobre una tarea con el comando 'Y'. Puede ser que una tarea esté esperando la entrada del operador, que se envía a una tarea mediante el comando aceptar 'AX' (tenga en cuenta que la entrada del operador es muy diferente de la entrada del usuario, que se ingresaría desde un dispositivo de red con una interfaz GUI) .
Las tareas que esperan la entrada del usuario o la lectura de archivos normalmente no figurarían como entradas en espera de atención del operador. Otro motivo por el que una tarea está en espera es la espera de un archivo. Cuando un proceso abre un archivo y el archivo no está presente, la tarea se coloca en las entradas en espera, y se observa que está esperando en un archivo determinado. Un operador (o el usuario propietario del proceso) tiene la oportunidad de copiar el archivo al lugar esperado, o redirigir la tarea para leer el archivo desde otro lugar, o incluso el archivo podría ser creado por un proceso independiente que no lo haya creado. Aún no está completo.
Si el operador no puede proporcionar el recurso, el operador puede DS la tarea como último recurso. Esto es diferente de otros sistemas, que finalizan automáticamente una tarea cuando un recurso, como un archivo, no está disponible. El MCP proporciona este nivel de recuperabilidad de tareas por parte del operador. Otros sistemas obligan a los programadores a agregar código para verificar la presencia de archivos antes de acceder a ellos y, por lo tanto, se debe escribir código adicional en cada caso para proporcionar capacidad de recuperación o sincronización de procesos. Dicho código se puede escribir en un programa MCP cuando no es deseable que una tarea espere, pero debido a la capacidad de recuperación a nivel de operador, esto no es forzado y, por lo tanto, simplifica mucho la programación.
Además de la capacidad de reasignar dinámicamente solicitudes de archivos (o bases de datos) a otros archivos (o bases de datos), antes o durante la ejecución del programa, hay varios mecanismos disponibles para permitir a los programadores detectar errores y recuperarse de ellos. Una forma, la declaración 'ON', existe desde hace muchos años. Se pueden enumerar fallos específicos (por ejemplo, dividir por cero) o se puede utilizar el término general 'cualquier fallo'. El compilador reconoce la declaración o bloque que sigue a la declaración 'ON' como código de manejo de fallas. Durante la ejecución, si se produce un error recuperable en el alcance de la instrucción 'on', la pila se reduce y el control se transfiere a la instrucción que le sigue.
Un problema con la lógica de manejo detrás de la declaración ON era que sólo sería invocada por fallas del programa, no por terminaciones del programa que tuvieran otras causas. Con el tiempo, creció la necesidad de un manejo garantizado de las terminaciones anormales. En particular, se necesitaba un mecanismo que permitiera a los programas invocar complementos escritos por clientes o terceros sin ningún riesgo en caso de que el complemento se comportara mal. Además de los mecanismos generales de complemento, la nueva forma de vinculación dinámica de bibliotecas (Bibliotecas de conexión) permite a los programas importar y exportar funciones y datos y, por lo tanto, un programa ejecuta el código proporcionado por otro.
Para lograr esa protección mejorada, a mediados de la década de 1990 se introdujo un mecanismo más nuevo. En un intento equivocado de compatibilidad, recibió el nombre de la construcción del lenguaje C++ propuesta en ese momento del mismo nombre. Debido a que la sintaxis y el comportamiento de los dos difieren en gran medida, elegir el mismo nombre sólo ha dado lugar a 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. Es posible que a continuación de la primera se incluyan cláusulas adicionales que indiquen lo contrario. Durante la ejecución, si se produce alguna terminación recuperable en el código que sigue a la cláusula "try", la pila se recorta si es necesario y el control se bifurca al código que sigue al primer "else". Además, se configuran atributos para permitir que el programa determine qué sucedió y dónde (incluido el número de línea específico).
La mayoría de los eventos que darían lugar a la finalización de la tarea son recuperables. Esto incluye desbordamiento de pila, acceso a matriz fuera de límites, flujo excesivo o insuficiente de enteros, etc. El DS del operador (o usuario) no es recuperable excepto mediante tareas privilegiadas que utilicen una forma de prueba NO SEGURA.
Por lo tanto, MCP proporciona un entorno muy tolerante a fallas, no el volcado de memoria de otros sistemas.
Al igual que los atributos de los archivos, las tareas también tienen atributos, como la prioridad de la tarea (que se asigna en el momento de la compilación o de la ejecución, o se puede cambiar mientras la tarea se está ejecutando), el tiempo del procesador, el tiempo de espera, el estado, etc. Se puede acceder a los atributos mediante programación, al igual que los atributos de los archivos. La tarea principal está disponible mediante programación como un atributo de tarea de tipo tarea. Por ejemplo, 'yo.iniciador.nombre' proporciona el nombre del proceso que inició el proceso actual.
GETSPACEy FORGETSPACEson los dos procedimientos principales que manejan la asignación y desasignación de memoria. La memoria debe asignarse al inicio del proceso y cada vez que se ingresa un bloque que utiliza matrices, archivos, etc. GETSPACEy FORGETSPACEno solo maneja el espacio de memoria, sino que también asigna o desasigna el espacio en disco donde se pueden superponer datos no residentes en la memoria. La memoria puede ser GUARDAR (es decir, memoria residente), OVERLAYABLE (es decir, memoria virtual) o STICKY (es decir, memoria residente, pero móvil). Son invocados, por ejemplo, HARDWAREINTERRUPTcuando un proceso aborda una matriz no inicializada o por FILEOPEN.
HARDWAREINTERRUPTmaneja interrupciones de hardware y puede invocar GETSPACE, IO_FINISHo similares.
BLOCKEXITes invocado por una tarea que sale de un bloque. BLOCKEXIT puede a su vez llamar a FILECLOSE, FORGETSPACEo algo similar, mientras limpia y libera recursos declarados y utilizados dentro de ese bloque.
J_EDGAR_HOOVER es el principal guardián de seguridad del sistema, invocado al inicio del proceso, apertura de archivos, inicio de sesión del usuario, etc.
GEORGEes el procedimiento que decide qué proceso es el siguiente en recibir recursos de la CPU y, por tanto, es uno de los pocos procesos que utiliza la instrucción MoveStack.
Una tarea pasa por varios estados comenzando con NASCENT. En la ENTREGA se provoca el evento NACIMIENTO y el estado de la tarea cambia a VIVO. Cuando se invoca PROCESSKILL, el estado cambia a ENFERMEDAD. Cuando se produce la MUERTE, la tarea se coloca en la estructura de cola MORGUE, después de lo cual todos los recursos restantes se liberan al sistema mediante un proceso llamado PROCESSKILL.
Mientras la tarea está VIVA, las funciones de MCP se ejecutan sobre ese proceso en particular, por lo que los recursos de la CPU se cargan automáticamente a la tarea que causa la sobrecarga de MCP. Además, gran parte del trabajo de MCP se realiza con los derechos de seguridad de esa pila en particular. Solo antes del NACIMIENTO y después de la MUERTE es necesario que el MCP esté operando desde alguna otra pila. Si no hay ninguno 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 los grandes sistemas de Burroughs analiza la forma en que los procesos dependientes podrían ejecutarse de forma asincrónica para que muchos procesos puedan compartir datos comunes (con los mecanismos para proporcionar actualizaciones sincronizadas). Tal familia de procesos relacionados tenía que escribirse como una sola unidad de programa, procesando procedimientos en niveles lex más altos como procesos asincrónicos, que aún podían acceder a variables globales y otras variables en niveles lex más bajos.
Las bibliotecas invirtieron completamente este escenario con las siguientes ventajas:
El mecanismo de la biblioteca era tan limpio y radical que gran parte del software del sistema se sometió a reescrituras importantes, lo que resultó en sistemas mejor estructurados y aumentos de rendimiento.
Las bibliotecas se introdujeron en los sistemas MCP a principios de la década de 1980, y fueron desarrolladas por Roy Guck y otros en Burroughs . Se parecen mucho a los monitores de CAR Hoare y brindan la oportunidad de exclusión mutua controlada y sincronización entre procesos de cliente, utilizando MCP EVENT y la técnica de bloqueo Dahm. Las bibliotecas ofrecen puntos de entrada de procedimientos al cliente, que se verifican para detectar una interfaz compatible (se verifican 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 diferentes idiomas. La ventaja es que toda la sincronización se proporciona en la biblioteca y el código del cliente no necesita preocuparse en absoluto por este nivel de programación. Esto da como resultado un código robusto ya que los clientes no pueden socavar el código de sincronización en la biblioteca. (Algunos llamarían a esto una " Iniciativa de Computación Confiable ").
Las bibliotecas son formas más sofisticadas de bibliotecas en otros sistemas, como las DLL . Las bibliotecas MCP pueden ser "compartidas por todos", "compartidas por unidad de ejecución" o "privadas". El caso privado es el más cercano a las bibliotecas de otros sistemas: para cada cliente se invoca una copia separada de la biblioteca y no se comparten datos entre procesos.
Compartido por todos es más interesante. Cuando se inicia un cliente, puede ejecutarse durante un tiempo hasta que requiera los servicios de la biblioteca. Tras la primera referencia a un punto de entrada a la biblioteca, se inicia el enlace. Si ya se está ejecutando una instancia de la biblioteca, el cliente se vincula a esa instancia de la biblioteca. Todos los clientes comparten la misma instancia.
Compartido por rununit es un mecanismo de intercambio entre estos dos esquemas de intercambio. 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 a las que está vinculado. Cada unidad de ejecución obtiene una instancia de la biblioteca y diferentes unidades de ejecución obtienen una instancia diferente. Esta es la única implementación dinámica de unidades de ejecución COBOL.
Si esta fuera la primera invocación de la biblioteca, la biblioteca ejecutaría su programa principal (bloque externo en un programa ALGOL) para inicializar su entorno global. Una vez completada la inicialización, se ejecutaría una congelación, momento en el cual 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 congelada ya que no se ejecutaría nada más en esta pila hasta que la biblioteca se descongelara, en cuyo caso se ejecutaría el código de limpieza y terminación. Cuando un cliente llama a una rutina en una biblioteca, esa rutina se ejecuta en la parte superior de la pila del cliente, almacenando allí sus variables locales y temporales. Esto permite que muchos clientes estén ejecutando la misma rutina al mismo tiempo, siendo sincronizados por la rutina de la biblioteca, que accede a los datos en el entorno global de la pila de la biblioteca.
La congelación también podría adoptar tres formas: temporal, permanente y controlada. Temporal significaba que una vez que el recuento de clientes cayera a cero, la biblioteca se descongelaría y se cerraría. Permanente significaba que la biblioteca permanecía disponible para más clientes incluso si el recuento de clientes caía a cero; un operador podía descongelar las bibliotecas permanentes con un comando THAW. Una congelación controlada significaba que la biblioteca realmente seguía funcionando, de modo que podía ejecutar funciones de monitoreo y realizar funciones de inicialización y limpieza de datos para cada cliente vinculado.
También se puede acceder a las bibliotecas "por título" y "por función". En 'por título' el cliente especificó el nombre del archivo de la biblioteca. 'Por función' era un método indirecto en el que un 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 encuentra en una tabla previamente configurada por un operador con 'SL' (sistema biblioteca), por ejemplo 'SL system_support = *system/library/support'. La actitud tolerante a fallas de MCP también funciona aquí: si un cliente intenta acceder a una biblioteca que no está presente, el cliente se coloca en las tareas de "espera" y la biblioteca podría volver a estar presente o redirigir la solicitud.
Las bibliotecas también se pueden actualizar sobre la marcha, todo lo que hay que hacer es 'SL' la nueva versión. Los clientes en ejecución continuarán usando la versión anterior hasta que finalicen y los nuevos clientes serán dirigidos a la nueva versión.
Las bibliotecas de funciones también implementaron una característica de seguridad muy importante: las clases de vinculación. Todas las bibliotecas normales tienen una clase de vinculación de cero. Es posible que las bibliotecas utilizadas por el MCP u otros módulos del sistema privilegiados no se puedan utilizar desde programas normales. Se accede a ellos por función y se fuerzan en la clase de vinculación uno. Un cliente en la clase de vinculación cero no puede vincularse a los puntos de entrada de la clase de vinculación uno. Una biblioteca con clase de vinculación uno que necesita ofrecer puntos de entrada a programas normales puede hacerlo si está designada como "confiable". Puede ofrecer puntos de entrada seleccionados en la clase de vinculación cero.
Todo el sistema de base de datos se implementa con bibliotecas que brindan un acceso muy eficiente y personalizado a bases de datos compartidas entre muchos clientes. Lo mismo ocurre con todas las funciones 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: Bibliotecas de conexión. Estos son programas por derecho propio que pueden ejecutarse de forma independiente, así como importar y exportar datos y funciones a otros programas en matrices de bloques estructurales. Por ejemplo, el componente de red del sistema operativo está disponible como una biblioteca de conexión, lo que permite que otros programas utilicen sus servicios exportando e importando funciones. Tras la vinculación, cada cliente obtiene un bloque de estructura dedicado para mantener la información de estado. Un programa que utiliza la red puede importar una función de escritura de red y exportar una función de lectura de red. Por lo tanto, si abre una conexión de red (por ejemplo, usando TCP ), cuando llegan datos para que los lea, el componente de red puede llamar directamente a su función para consumirlos, sin tener que copiar primero los datos a un búfer y realizar un cambio de contexto. . Asimismo, puede escribir datos en la red llamando directamente a una función de escritura de red.
Las bibliotecas de conexión permiten un grado significativo de control sobre los enlaces. Opcionalmente, cada lado de un vínculo puede aprobar un vínculo y puede cortarlo según lo desee. El estado se puede mantener fácilmente por vínculo y también a nivel global.
Otra técnica para la comunicación entre procesos (IPC) son los archivos de puerto. Son como tuberías de Unix , excepto que están generalizadas para ser multidireccionales y bidireccionales. Dado que son un orden de magnitud más lentas que otras técnicas de IPC, como las bibliotecas, es mejor utilizar otras técnicas en las que el IPC se realiza entre diferentes procesos en la misma máquina.
Por tanto, el uso más ventajoso de los archivos de puerto es para IPC distribuido. Los archivos de puerto se introdujeron con BNA (Burroughs Network Architecture), pero con la llegada de tecnologías de red estándar como OSI y TCP / IP , los archivos de puerto también se pueden utilizar con estas redes.
Un servidor que escucha conexiones entrantes declara un archivo de puerto (un archivo con el atributo KIND igual a PORT). Cada conexión que se realiza desde un cliente crea un subarchivo con un índice, por lo que cada archivo de puerto representa múltiples conexiones a diferentes clientes en la red.
Un proceso de servidor recibe solicitudes de clientes desde cualquier lugar de la red emitiendo una lectura en el archivo del puerto (subarchivo = 0 para leer desde cualquier subarchivo). Emite una respuesta al cliente que emitió la solicitud escribiendo al subarchivo particular desde donde se leyó la solicitud.
El MCP también proporciona un entorno de operador sofisticado pero simple. Para instalaciones grandes, es posible que se requiera que muchos operadores pongan a disposición recursos físicos, como impresoras (carga de papel, cartuchos de tóner, etc.). Los entornos de gama baja para oficinas pequeñas o usuarios individuales pueden requerir un entorno sin operador (especialmente la implementación de portátiles).
Los sistemas grandes tienen terminales de operaciones dedicadas llamadas ODT (Operator Display Terminals), generalmente guardadas en un entorno seguro. Para sistemas pequeños, las máquinas se pueden controlar desde cualquier terminal (siempre que el terminal y el usuario tengan privilegios suficientes) utilizando el programa MARC (Control de recursos asistido por menú). Los comandos del operador también pueden ser utilizados por usuarios familiarizados con ellos.
Los comandos del operador son en su mayoría de dos letras (como en Unix), y algunos tienen solo una letra. Esto significa que se debe aprender a utilizar la interfaz del operador, pero es muy eficiente para operadores experimentados que manejan un gran sistema mainframe día a día. Los comandos no distinguen entre mayúsculas y minúsculas.
Las tareas se ingresan en la 'mezcla' del programa 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 de archivo del programa. Los ODT generalmente se ejecutan 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 al operador para notificaciones o situaciones que requieren la acción del operador. .
La lista completa de estas pantallas viene dada por 'A' (activo), 'W' (en espera), 'C' (completado) y 'MSG' (comandos de mensaje).
Si una tarea queda en espera de alguna acción del operador, el operador puede averiguar qué necesita la tarea ingresando su número de combinación seguido del comando 'Y'. (Tenga en cuenta el estilo de los comandos orientados a objetos, seleccionando primero el objeto, seguido del comando). Por ejemplo, '3456Y'.
Un operador puede forzar una tarea en las entradas en espera con el comando de parada '3456ST' y activarla nuevamente con OK: '3456OK'. El comando Aceptar también se puede utilizar cuando un operador ha puesto un recurso a disposición para una tarea, aunque la mayoría de las veces, el MCP detectará que los recursos están disponibles, CAUSANDO el EVENTO en el que los procesos han estado esperando sin mayor intervención del operador. Para pasar información textual de un operador a un programa, se puede utilizar el comando de aceptación '3456AX MÁS INFORMACIÓN'. Los programas pueden pasar información a los operadores utilizando el mecanismo DISPLAY, lo que hace que los mensajes DISPLAY se agreguen a la pantalla MSG.
Además de las tareas y los procesos, los operadores también tienen control sobre los archivos. Los archivos se pueden enumerar usando el comando ARCHIVO, copiar usando COPIAR, eliminar usando ELIMINAR y cambiarles el nombre.
El entorno operativo del MCP es potente, pero simple y normalmente solo requiere una fracción del número de operadores de otros sistemas.
Una parte importante del entorno de operaciones es el lenguaje de flujo de trabajo de alto nivel .
Todas las acciones en el sistema se registran, por ejemplo, todos los mensajes mostrados al operador y todas las acciones del operador. Todas las acciones importantes del programa se registran opcionalmente en un registro del sistema y en un registro del programa, por ejemplo BOJ para el inicio de un trabajo WFL, BOT para el comienzo 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, que es lo que sistemas como Unix no hacen, aunque también lo hacen. Mantenga muchas cosas en los registros del sistema.
Los registros se pueden utilizar con fines forenses para descubrir por qué los programas o sistemas pueden haber fallado, o para detectar intentos de comprometer la seguridad del sistema. Los registros del sistema se cierran automáticamente después de un período configurable por el sistema y se abre uno nuevo. Los registros del sistema contienen una gran cantidad de información, que se puede filtrar y analizar con programas como LOGANALYZER.
DUMPANALYZER analiza volcados de memoria que se escribieron originalmente en cinta. Como todos los compiladores agregaron LINEINFO en los archivos de código, DUMPANALYZER puede identificar exactamente qué declaración fuente se estaba ejecutando en el momento del error.
Además, un volcado de programa normal, en el que sólo 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 importantes herramientas de diagnóstico para todo tipo de propósitos.
Más allá de las muchas innovaciones técnicas en el diseño del MCP, Burroughs Large Systems tenía muchas innovaciones de gestión que ahora utiliza la comunidad de Internet en general. El software del sistema se envió a los clientes, incluido el código fuente y todas las herramientas de edición y compilación necesarias para generar nuevas versiones de MCP para los clientes. Muchos clientes desarrollaron experiencia especializada en el funcionamiento interno del MCP, y los clientes a menudo enviaban los 'parches' (fragmentos de código fuente con números de secuencia) como sugerencias de nuevas características mejoradas o correcciones de fallas (FTR - informes de problemas de campo). Muchos de los parches sugeridos fueron incluidos por los desarrolladores de sistemas y se integraron en la próxima versión de MCP. Incluir una comunidad de expertos voluntarios y autoproclamados en el trabajo técnico convencional es ahora una práctica generalizada y es la esencia de la innovación abierta . Esta innovación en la 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 que admiten una amplia variedad de lenguajes de programación , entre ellos:
Otros productos incluyen:
Anteriormente existían compiladores para ESPOL , COBOL(68), Fortran(66), APL y PL/I .
No hay ningún ensamblador en el sistema operativo Unisys MCP.
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 tenido muchas primicias en una implementación comercial, incluida la memoria virtual, el multiprocesamiento simétrico y un lenguaje de control de trabajos de alto nivel (WFL). Ha tenido durante mucho tiempo muchas instalaciones que sólo ahora [ ¿cuándo? ] que aparece en otros sistemas operativos generalizados y, junto con la arquitectura de sistemas grandes de Burroughs, el MCP proporciona un entorno de procesamiento de transacciones y multitarea muy seguro [ palabras de comadreja ] , de alto rendimiento.