OS 2200 es el sistema operativo de la familia de sistemas mainframe Unisys ClearPath Dorado. El núcleo del sistema operativo de OS 2200 es un descendiente directo de Exec 8 para UNIVAC 1108 y anteriormente se conocía como OS 1100. La documentación y otra información sobre los sistemas actuales y anteriores de Unisys se puede encontrar en el sitio web de soporte público de Unisys. [nota 1]
Consulte la arquitectura del sistema de la serie Unisys 2200 para obtener una descripción de la arquitectura de la máquina y su relación con el sistema operativo OS 2200. Unisys dejó de producir hardware ClearPath Dorado a principios de la década de 2010 y ahora el sistema operativo se ejecuta bajo emulación. [1]
Hubo sistemas 1100 anteriores, desde el 1101 en 1951, pero el 1108 fue el primer ordenador de la serie 1100 diseñado para soportar de manera eficiente la multiprogramación y el multiprocesamiento. Junto con este nuevo hardware llegó el sistema operativo Exec 8 (sistema ejecutivo para el 1108).
El ordenador UNIVAC 1108 se anunció en 1964 y se entregó a finales de 1965. Los primeros ordenadores 1108 utilizaban Exec I y Exec II , que habían sido desarrollados para el UNIVAC 1107. Sin embargo, UNIVAC planeaba ofrecer versiones multiprocesador simétrico del 1108 con hasta 4 procesadores y los sistemas operativos anteriores ( programas de monitorización realmente básicos ) no estaban diseñados para eso, a pesar de que admitían una multiprogramación limitada.
Cuando se presentó el UNIVAC 1110 en 1972, el nombre del sistema operativo se cambió a OS 1100 para reflejar su compatibilidad con una gama más amplia de sistemas. El nombre OS 1100 se mantuvo hasta 1988 con la introducción de la serie Sperry 2200 como continuación de la serie 1100, cuando su nombre se cambió a OS 2200. Desde entonces, la serie 2200 se convirtió en la serie Unisys ClearPath IX y luego en la serie Unisys ClearPath Dorado, pero el sistema operativo mantuvo el nombre OS 2200.
El nombre de la empresa y los nombres de sus productos también cambiaron con el tiempo. [2] Engineering Research Associates (ERA) de Saint Paul fue adquirida por Remington Rand Corporation . Remington Rand también adquirió Eckert–Mauchly Computer Corporation de Filadelfia, que en ese momento estaba construyendo la computadora UNIVAC . Las dos se combinaron en la división UNIVAC de Remington Rand bajo la dirección de William Norris. William Norris había sido uno de los fundadores de ERA y luego dejó Remington Rand para iniciar Control Data Corporation . La división UNIVAC de Remington Rand Corporation se convirtió en la división UNIVAC de Sperry Rand Corporation después de que Remington Rand se fusionara con Sperry Corporation . En la década de 1970, Sperry Rand comenzó un programa de identidad corporativa que cambió su nombre a Sperry Corporation y todos los nombres de las divisiones comenzaron con Sperry, por lo que la división de sistemas informáticos se convirtió en Sperry UNIVAC. Más tarde, los nombres de las divisiones se eliminaron y todo simplemente se convirtió en Sperry.
La mayoría de los empleados de Unisys y de los clientes aún se refieren al núcleo del sistema operativo como "Exec". Sin embargo, cuando Unisys comenzó a lanzar conjuntos de productos probados juntos como versiones base del sistema, posteriormente denominados "ClearPath OS 2200 Release n ", el término OS 2200 cambió para referirse a todo el conjunto de productos de la versión del sistema y otros, como BIS , lanzados de forma asincrónica para las plataformas de hardware Dorado.
En 1986, las corporaciones Burroughs y Sperry se fusionaron para convertirse en Unisys (que, según algunos clientes de larga data de la serie 2200, significa "UNIVAC sigue siendo su proveedor"). [3] Las principales líneas de productos mainframe de ambas compañías han continuado su desarrollo, incluido el sistema operativo MCP de Burroughs y el OS 2200 de Sperry.
En 2016, Unisys puso a disposición una versión virtual de OS2200 para Microsoft Windows sin costo para fines educativos y de ocio. [4]
EXEC 8 (a veces denominado EXEC VIII) fue el sistema operativo de UNIVAC desarrollado para el UNIVAC 1108 en 1964. Combinaba las mejores características de los sistemas operativos anteriores, EXEC I y EXEC II , que se utilizaban en el UNIVAC 1107. EXEC 8 fue uno de los primeros sistemas operativos multiprocesamiento comercialmente exitosos . Admitía cargas de trabajo mixtas simultáneas que comprendían procesamiento por lotes , tiempo compartido y tiempo real . Su sistema de archivos único tenía una estructura de nombres plana en muchos tambores y husillos. También admitía un sistema de procesamiento de transacciones bien recibido .
Los sistemas anteriores eran todos sistemas en modo real sin soporte de hardware para la protección y separación de programas y el sistema operativo. Si bien había soporte para multiprogramación en sistemas anteriores, estaba limitado a ejecutar un trabajo de usuario simultáneamente con múltiples funciones de soporte que se sabía que se comportaban bien, como el lector de tarjetas, la impresora y los spoolers de perforación de tarjetas .
El sistema operativo Exec 8 fue diseñado desde el principio para ser un sistema operativo multiprogramación y multiprocesamiento, ya que el 1108 fue diseñado para tener hasta cuatro CPU. La memoria y el almacenamiento masivo eran las principales limitaciones del sistema. Si bien la serie 1100 fue concebida para un mercado más general, el procesamiento en tiempo real extremo era un requisito primordial. [5]
Las especificaciones para Exec 8 se elaboraron en diciembre de 1964 como un Manual de referencia del programador preliminar (guía del usuario) y el trabajo comenzó en mayo de 1965. [6] [7]
Exec 8 comenzó como un sistema operativo en tiempo real con un uso temprano principalmente en trabajos científicos y de ingeniería en general, pero también se utilizó en conmutación de mensajes, control de procesos, simulación y control de disparo de misiles. Fue diseñado para ejecutarse en sistemas que a menudo tenían solo 128K palabras (576 K bytes, menos que el tamaño máximo de memoria para IBM PC XT ), y estaba enfocado en el tiempo real y el procesamiento por lotes. Si bien los primeros niveles de lanzamiento funcionaban en 128KW, el aumento de la funcionalidad en versiones posteriores lo hizo insostenible, ya que no dejaba suficiente espacio para programas de tamaño útil. La capacidad máxima de memoria de un 1108 era 256KW (1,152 KB), por lo que el uso eficiente de la memoria era la restricción más importante, ya que la memoria central era la parte más cara del sistema.
El almacenamiento masivo consistía en tambores giratorios de 6 pies de largo que contenían entre 256KW (en el FH-432) y 2MW (en el FH-1782). El almacenamiento masivo de mayor capacidad era el tambor FASTRAND , que contenía 22 MW (99 MB). La fragmentación de archivos se solucionaba mediante un proceso llamado "guardado de archivos", que generalmente se hacía una vez al día, por la noche. Implicaba pasar todos los archivos a cinta, reiniciar el sistema de archivos del tambor y volver a leer los archivos.
Debido a las severas limitaciones de memoria y al uso en tiempo real, era necesario mantener una única copia del código cargado en el núcleo. Dado que el 1108 estaba diseñado para realizar múltiples tareas, el sistema era completamente "reentrante" ( seguro para subprocesos ). Cada módulo reentrante accedía a los datos del programa a través de una única "dirección base" de memoria, que era diferente para cada instancia de datos de ejecución. El cambio de contextos de ejecución se podía realizar en una única instrucción simplemente configurando una dirección base diferente en un único registro. El sistema utilizaba un bloqueo de grano fino para proteger las estructuras de datos compartidas. El ejecutivo, los compiladores, las utilidades e incluso las aplicaciones de usuario sofisticadas que podían tener varias copias ejecutándose simultáneamente se escribieron de modo que su código pudiera compartirse. Esto requería cargar solo una copia en la memoria, ahorrando tanto espacio como el tiempo que llevaba cargar el código.
Otra razón para separar el código y los datos en diferentes entidades de carga fue que la memoria se implementó como dos bancos independientes (gabinetes físicos separados) llamados IBANK y DBANK (instrucción y datos). Cada uno tenía su propia ruta de acceso, por lo que la CPU podía leer ambos bancos simultáneamente. Al cargar el código ejecutable en un banco de memoria y los datos en el otro, el tiempo de ejecución de muchos programas podía reducirse casi a la mitad.
El código reentrante tenía que ser seguro para subprocesos (solo ejecución); no se permitía código automodificable. Para otros programas, modificar el código ejecutable durante el tiempo de ejecución todavía era una técnica de programación aceptable en la época de las computadoras de la serie 1100, pero se alentaba a los usuarios a no hacerlo debido a la pérdida de rendimiento. Se promocionaban los beneficios de seguridad, pero no se valoraban demasiado porque piratear la mayoría de las aplicaciones de la serie 1100 no proporcionaría ningún beneficio a nadie y porque pocos piratas informáticos eran malintencionados en ese entonces.
Exec 8 era principalmente un sistema de procesamiento por lotes que otorgaba a las aplicaciones (denominadas "tareas") un control muy preciso de la prioridad de programación de la CPU para sus subprocesos (denominados "actividades"). El cambio de procesador era preventivo, y los subprocesos de mayor prioridad obtenían el control del procesador que estaba ejecutando el subproceso de menor prioridad de cualquier programa. Excepto en los sistemas de tiempo real, incluso las tareas de menor prioridad obtenían algo de tiempo de procesador. Era un sistema operativo multiprogramación y multiprocesamiento con una gestión de procesador totalmente simétrica. Una instrucción de prueba y configuración integrada en el hardware permitía un bloqueo muy eficiente y de grano fino tanto dentro del sistema operativo como dentro de las aplicaciones multiproceso.
En Exec 8, el trabajo se organiza en tareas, llamadas "ejecuciones", que se programan en función de su prioridad y la necesidad de recursos bloqueables, como unidades de cinta Uniservo o archivos de batería Fastrand. La sintaxis del lenguaje de control utiliza el símbolo "@" (al que Univac llamó "el espacio maestro") como el símbolo de reconocimiento de la instrucción de control. Iba seguido inmediatamente por el nombre del comando o programa, luego una coma y cualquier cambio de opción. Después de un carácter de espacio, el resto de la instrucción difería para comandos particulares. Un comando para compilar un programa FORTRAN se vería así: "@FOR[,options] sourcefile, objectfile". Los datos de entrada para una aplicación se podían leer desde un archivo (generalmente imágenes de tarjetas) o seguir inmediatamente al comando @ en el flujo de ejecución. Se asumía que todas las líneas hasta el comando centinela "@END" eran datos de entrada, por lo que olvidarse de insertarlo hacía que el compilador interpretara los comandos posteriores como datos del programa. Por esta razón, era preferible procesar los datos en archivos en lugar de ingresarlos en el flujo de ejecución.
En 1968, se comenzó a trabajar en la incorporación de la capacidad de compartir tiempo a Exec 8. Se entregó con el nivel 23 del ejecutivo en 1969. El tiempo compartido (llamado modo de demanda) tenía las mismas capacidades que los procesos por lotes y en tiempo real. Todo lo que se podía hacer en lotes se podía hacer desde una terminal ASCII. En el modo de demanda, la E/S del flujo de trabajo se adjuntaba a un controlador de terminal en lugar de a archivos de imagen de tarjeta (entrada) y spool (salida). Se utilizaba el mismo lenguaje de control de ejecución para ambos. Unos años más tarde, se agregaron comandos de tiempo compartido más específicos y algunas sentencias de control se podían emitir de forma asincrónica para su procesamiento inmediato, incluso cuando ni el ejecutivo ni el programa en ejecución esperaban datos. Esos comandos, que solo se podían ingresar desde una terminal, comenzaban con "@@". Debido a que se podían ejecutar sin detener otro trabajo en progreso desde la misma terminal, se los llamó comandos transparentes. Al principio, estas eran solo sentencias para matar el programa actual o redirigir la salida de la terminal a un archivo, pero con el tiempo, se permitió que casi todas las sentencias de control fueran "inmediatas".
Tanto las ejecuciones por lotes como las ejecuciones bajo demanda finalizan con una declaración @FIN y, si un usuario bajo demanda finaliza su sesión mientras su ejecución está activa, el Exec finaliza automáticamente la ejecución sin necesidad de @FIN.
A finales de los años 60 se desarrolló una capacidad de procesamiento de transacciones como un proyecto conjunto con United Airlines y posteriormente se perfeccionó en otro proyecto conjunto con Air Canada. Esta capacidad se integró completamente en el sistema operativo en 1972 y se convirtió en la base de gran parte del crecimiento futuro de la Serie 1100. Los primeros usuarios controlaban las líneas de comunicación directamente desde sus programas en tiempo real. Parte del desarrollo del procesamiento de transacciones incluía un sistema de mensajes de comunicación que administraba las líneas de comunicación y presentaba mensajes a Exec 8 para que se programaran como transacciones. Esto trasladó toda la gestión de líneas físicas de comunicación de bajo nivel y los protocolos fuera de las aplicaciones y a la aplicación CMS 1100.
El propio CMS 1100 se ejecutaba como un programa multiproceso en tiempo real con el privilegio de adquirir el control de las líneas de comunicación y enviar mensajes de transacción para su programación. Esto llevó a las nociones en Exec 8 de que las aplicaciones de cualquier naturaleza debían controlarse cuidadosamente para garantizar que no pudieran causar problemas de integridad. La seguridad era sin duda una preocupación, pero en los primeros tiempos la fiabilidad y la integridad del sistema eran cuestiones mucho más importantes. El sistema seguía siendo principalmente un sistema de procesamiento de lotes y transacciones y había pocas posibilidades de que alguien pudiera instalar código no autorizado en el sistema. Más tarde, CMS 1100 añadió la capacidad de ser la interfaz para terminales de demanda, así como terminales de transacción, de modo que los terminales pudieran utilizarse para ambos y los primeros controladores de terminales pudieran eliminarse del Exec. Más tarde, CMS 1100 fue reemplazado por una combinación de CPComm (Plataforma de comunicaciones de servidores empresariales ClearPath) y SILAS (Interfaz del sistema para sistemas de aplicaciones heredadas). [8] [9] Para los modelos de servidor Dorado basados en Intel, las comunicaciones de nivel inferior se trasladaron al firmware, y los niveles superiores fueron manejados por SILAS y CPCommOS (Plataforma de comunicaciones de servidores empresariales ClearPath para sistemas abiertos). [10]
El Exec contiene todo el código del sistema que puede ejecutarse en los niveles de privilegio más altos. No existen mecanismos para que otro código pueda ascender a esos niveles de privilegio.
El ejecutivo es responsable de administrar el hardware del sistema, programar y gestionar el trabajo y comunicarse con los operadores y administradores.
En la versión 16.0, el nivel Exec es 49R2 (49.70.5). Los niveles internos del sistema utilizan un número de tres partes, como 21.92.42 (que fue el primer sistema de producción ampliamente utilizado, aunque se utilizaron versiones anteriores en producción en varios sitios). La primera parte del número es el nivel principal e indica una nueva versión del Exec con todas las actualizaciones anteriores integradas en una nueva versión base. Este es un proceso poco frecuente y ocurre en intervalos de años. La segunda parte del número indica versiones de actualizaciones del nivel principal y, a menudo, ocurre varias veces por semana. Cuando se toma la decisión de congelar el contenido de las características y prepararse para el lanzamiento, entra en juego la tercera parte e indica versiones del nivel previo al lanzamiento a medida que se aplican correcciones y actualizaciones de características menores. Al mismo tiempo que se prepara un nivel para el lanzamiento, las actualizaciones de la "línea principal" continúan a medida que los ingenieros integran cambios en preparación para un lanzamiento futuro. Durante muchos años, el nivel de lanzamiento oficial fue el número completo de tres partes. Los lanzamientos posteriores se denominaron simplemente 44R1, 44R2, 49R2, etc., aunque el número de tres partes todavía se utiliza internamente.
En esencia, Exec es un sistema de procesamiento por lotes multiproceso en tiempo real. Todo se ha construido en torno a ese modelo. Exec en sí está estructurado en gran medida como un programa en tiempo real. Las funciones que se realizan como servicios en Windows o como demonios en Linux y UNIX se implementan como actividades dentro de Exec o como programas por lotes que siempre se ejecutan en segundo plano.
El modo de tiempo compartido (conocido como modo de demanda) y el procesamiento de transacciones se implementan como casos especiales de procesamiento por lotes. Un resultado es que existen pocas restricciones sobre lo que un usuario o programa de transacciones de tiempo compartido puede hacer. Hay muchas advertencias para los escritores de programas de transacciones de que no estarán satisfechos con el rendimiento si, por ejemplo, solicitan un montaje de cinta, pero está permitido.
La unidad de trabajo más grande es la "Ejecución". Esto proviene de la terminología de "ejecución de producción" de fábrica y generalmente equivale a un trabajo o sesión en otros sistemas. Una Ejecución se define por su "flujo de ejecución". Un flujo de ejecución es una secuencia de instrucciones de control que representan los pasos a seguir. Pueden incluir el manejo de archivos, la ejecución de programas y las ramas de control. Una Ejecución por lotes generalmente se almacena como un archivo y se programa mediante un comando "Iniciar" desde dentro de otra Ejecución o por el operador. Una Ejecución de tiempo compartido se inicia iniciando sesión desde una terminal de tiempo compartido e ingresando el comando @RUN. A menudo, la instrucción @RUN y la segunda instrucción de control (a menudo @ADD o una ejecución de programa) se generan automáticamente según el perfil del usuario. Las autorizaciones de seguridad se validan según la identificación del usuario autenticado y otra información suministrada en la instrucción de control de Ejecución.
Las transacciones son un caso especial. En realidad, no hay declaraciones de control, pero se crean las estructuras de datos internas de una ejecución. Esto permite que el Exec asocie los mismos mecanismos de seguridad, contabilidad, depuración, etc. con los programas de transacción. Generalmente, un perfil de seguridad se almacena en caché en la memoria en el momento en que se autentica al usuario de la transacción y se copia desde los datos de la sesión del usuario al estado de ejecución de la transacción cuando se programa la transacción. Debido a que cada instancia de transacción es esencialmente una ejecución, la contabilidad, el registro y el manejo de errores están todos encapsulados por el mecanismo de ejecución.
Los trabajos por lotes (ejecuciones) se caracterizan por tener un flujo de ejecución (sentencias del lenguaje de control de trabajos) almacenado en un archivo. Un trabajo por lotes siempre contiene una sentencia @RUN como primer registro del archivo. Esta sentencia le da un nombre a la ejecución (id de ejecución), define las prioridades y define la cantidad máxima de SUPS (unidades estándar de procesamiento) que se espera que utilice el trabajo. El trabajo se inicia desde algún otro trabajo con una sentencia de control @START o por el operador mediante una entrada de teclado ST. El sistema se puede configurar para que emita automáticamente sentencias @START para cualquier cantidad de trabajos cuando se inicia. Estos trabajos sirven para realizar funciones de inicialización, recuperación y en segundo plano.
Todos los campos de la instrucción @RUN pueden ser reemplazados por los campos correspondientes de la instrucción @START. Excepto cuando @START es ejecutado por un usuario privilegiado, el ID de usuario y otros estados de seguridad siempre se toman de la ejecución que realiza @START.
Hay dos campos de prioridad en la sentencia @RUN. Uno se utiliza para especificar la prioridad de la lista de tareas pendientes. Hay 26 niveles de prioridad de la lista de tareas pendientes (A – Z). El Exec tiene configurado un número máximo de ejecuciones de lotes abiertas. Cuando se alcanza ese nivel, se seleccionan los trabajos de las colas de la lista de tareas pendientes en orden de prioridad. Dentro de una prioridad, la selección suele ser FIFO. Sin embargo, el Exec escanea previamente las sentencias de control de trabajos hasta la primera ejecución del programa en busca de nombres de archivos y números de carrete. Si el trabajo se detiene inmediatamente porque algunos recursos que necesita no están disponibles, se puede omitir para iniciar otros trabajos en el mismo nivel de prioridad.
El segundo nivel de prioridad define un grupo de recursos de procesador de ejecución. En general, las prioridades de grupo de ejecución más altas suelen obtener más tiempo de procesador.
Aunque el lenguaje de control de trabajos OS 2200 no admite una programación completa, sí permite adiciones dinámicas de secuencias de lenguaje de control a través de una declaración de control @ADD. El archivo que se va a agregar puede haber sido creado por el mismo trabajo inmediatamente anterior a agregarlo. La @ADD y la mayoría de las demás declaraciones de control también se pueden enviar desde dentro de un programa en ejecución a través de una API. [11] Se puede obtener una programación adicional de forma indirecta mediante el uso del generador de flujo simbólico (SSG). [12] SSG es un lenguaje de programación para manipular y crear archivos de texto a partir de parámetros de entrada e información del sistema. Se utiliza mucho para el procesamiento de gestión de configuración ( make ) y otras funciones en las que es necesario crear imágenes de texto mediante programación. La salida resultante se puede "@ADD" en la misma ejecución, lo que proporciona el flujo de ejecución programable de forma indirecta.
Los comandos del operador están disponibles para cambiar tanto el trabajo pendiente como las prioridades de ejecución de las ejecuciones. Como todos los comandos del operador están disponibles mediante API para usuarios con los privilegios adecuados, esto se puede automatizar o controlar mediante un administrador remoto.
La fecha límite es un caso especial de lote. Una ejecución de fecha límite se parece a cualquier otra ejecución de lote, excepto que se especifica una hora límite en la declaración de control @RUN o @START. La hora límite se utiliza junto con el SUPS máximo (estimación de tiempo) en la declaración de control. Un trabajo con fecha límite se ejecuta con prioridades de lote normales a menos que parezca que podría perder su hora límite. Entonces, cuanto mayor sea el desajuste entre el tiempo hasta la fecha límite y el SUPS restante, mayor será la prioridad. Si bien la fecha límite no puede detener por completo las transacciones y no tiene ningún efecto en el tiempo real, puede detener de manera efectiva la mayoría de los demás procesos en el sistema si es necesario para lograr su objetivo.
Las sesiones de tiempo compartido de OS 2200 se denominan ejecuciones bajo demanda (de "a pedido"). Utilizan el mismo lenguaje de control que las ejecuciones por lotes con algunas adiciones conocidas como instrucciones de control "inmediatas". Las instrucciones de control inmediatas utilizan el centinela "@@" que indica que se deben ejecutar inmediatamente incluso si se está ejecutando un programa. Si bien se pueden utilizar para crear o asignar archivos, las más importantes permiten que un usuario bajo demanda finalice por error un programa en ejecución o incluso le envíe una señal.
Las transacciones se ejecutan como ejecuciones pero sin ninguna instrucción de control almacenada o enviada. En cambio, cuando se recibe un mensaje de una sesión definida como sesión de transacción, se escanea para determinar la cola de transacciones en la que se colocará. Esto normalmente se determina por los primeros caracteres del mensaje, pero se pueden agregar escáneres escritos por el usuario. [13]
El administrador de comunicaciones, que puede gestionar hasta 250.000 sesiones activas, toma los mensajes de transacción entrantes y los pasa al software de cola de mensajes. Puede gestionar una cantidad ilimitada de mensajes en cola utilizando la arquitectura de cola de mensajes. Se realiza una llamada a las API del Paquete de interfaz de transacción (TIP) en el sistema operativo para poner en cola la transacción en el punto de cola adecuado. Cada punto de cola identifica la prioridad y el nivel de concurrencia del trabajo y el programa de transacción asociado que se va a ejecutar.
Un árbol de programación de programas de transacciones permite al cliente establecer un uso relativo para grupos de programas de transacciones. Los límites de concurrencia evitan que un tipo de trabajo domine el sistema con exclusión de otros trabajos y evitan la creación de un exceso de compromiso de recursos. Se pueden crear hasta 4094 nodos en el árbol.
Se puede especificar la prioridad (0 a 63) y el nivel de concurrencia (1 a 2047) para cada programa de transacción.
Se selecciona la transacción de mayor prioridad para la programación, excepto según lo limitado por las políticas de concurrencia vigentes para su nodo y los nodos superiores.
El tiempo real no es otro tipo de ejecución, sino un conjunto de niveles de prioridad que cualquier actividad puede solicitar. El tiempo real se utiliza más comúnmente en programas por lotes de larga ejecución, como el administrador de comunicaciones CPComm de OS 2200, pero no se limita a ellos.
Hay 36 niveles de prioridad en tiempo real disponibles por API para que las aplicaciones los utilicen. El usuario y la cuenta deben tener el privilegio de utilizar prioridades en tiempo real. Depende del sitio controlar cómo sus aplicaciones utilizan los niveles de prioridad. Las prioridades en tiempo real dominan totalmente a todas las prioridades inferiores, por lo que es muy posible que un programa en tiempo real con mal comportamiento ocupe uno o más procesadores.
La prioridad de tiempo real se aplica a una actividad individual (hilo), por lo que un programa puede tener hilos en tiempo real y en tiempo no real ejecutándose al mismo tiempo.
Una vez que se ha iniciado una ejecución, el acceso al procesador controla su velocidad de progreso. El núcleo del Exec es el Dispatcher , que administra todos los procesadores. [14]
El Exec admite hasta 4095 prioridades de despacho, aunque la mayoría de los sitios definen solo un pequeño subconjunto de ellas. Las dos "prioridades" más altas no son conmutables. Son el reconocimiento de ciertos tipos de procesamiento que deben continuar en el procesador en el que comenzaron hasta que voluntariamente cedan el control. El bloqueo de interrupciones ocurre cuando llega una interrupción o en algunos casos especiales cuando otro código Exec evita todas las interrupciones (para cambiar algunos datos a los que también puede acceder un controlador de interrupciones).
El enclavamiento se utiliza en rutinas de posprocesamiento de interrupciones que deben ejecutarse en el mismo procesador físico o que simplemente no deben interrumpirse. El despachador, las finalizaciones de E/S y la iniciación de E/S son algunos ejemplos. Todos los bloqueos utilizados por estas dos prioridades son bloqueos de giro, ya que la única forma en que otra persona puede establecerlos es en otro procesador y el diseño requiere que solo se establezcan para secuencias de instrucciones muy cortas.
La prioridad de ejecución alta la utilizan el controlador de comandos del operador y algunas otras funciones que pueden tener que ejecutarse incluso cuando un programa en tiempo real tiene el control. Se espera que utilicen solo períodos de tiempo muy breves. Si necesitan más tiempo, deben poner en cola el trabajo para que lo procese una actividad de ejecución baja.
Las actividades en tiempo real tienen una cantidad ilimitada de procesadores y se ejecutan sin cambios a menos que se interrumpan por una actividad en tiempo real de mayor prioridad o una actividad de alta ejecución. Las actividades en tiempo real tienen el control de cualquier procesador disponible que esté ejecutando algo de menor prioridad. Se envían interrupciones entre procesadores cuando es necesario para garantizar la disponibilidad inmediata. Los clientes utilizan el tiempo real para volar misiles, ejecutar simuladores y otras funciones que requieren una respuesta inmediata.
Las prioridades de transacción se pueden manejar de dos maneras, según lo definido por el sitio. Pueden ser una especie de tiempo real de menor prioridad, en el que solo importa la prioridad y el tamaño cuántico es esencialmente infinito. Esto es apropiado para transacciones de vida muy corta, como las reservas de aerolíneas; si una entra en un bucle debido a un error de programación, el Exec la terminará cuando alcance su tiempo máximo configurado muy pequeño. La otra forma permite al Exec variar la prioridad dentro de un rango para optimizar el uso de los recursos del sistema. El enfoque otorga mayor prioridad y porciones de tiempo más cortas a los programas que tienen limitaciones de E/S y prioridades progresivamente más bajas, pero porciones de tiempo más largas a los que están computando. El Exec ajusta dinámicamente estas prioridades en función del comportamiento, ya que los programas a menudo se comportan de ambas maneras en diferentes momentos. Este enfoque es apropiado para transacciones de ejecución más prolongada, como consultas de bases de datos o cotizaciones de tarifas aéreas.
Los procesos por lotes y a demanda siempre utilizan prioridades ajustadas dinámicamente. Los programas que tienen una limitación de E/S o que están en una conversación con un usuario que comparte el tiempo obtienen prioridades más altas, pero porciones de tiempo más cortas. Los programas más orientados a la computación obtienen prioridades más bajas y porciones de tiempo más largas.
El Exec tiene dos mecanismos adicionales para optimizar el despacho. Uno es el despacho basado en afinidad. Cuando es posible, el Exec ejecutará una actividad en el mismo procesador en el que estaba la última vez para aprovechar al máximo el contenido residual de la caché. Si eso no es posible, intenta mantener la actividad en el procesador "más cercano" desde el punto de vista de los tiempos de acceso a la memoria y la caché. El segundo es un mecanismo de política de "equidad". El sitio puede definir el porcentaje relativo de recursos que se asignarán a cada una de las transacciones, la demanda y el lote. Dentro de las transacciones y el lote hay agrupaciones de prioridad que pueden indicar además qué porcentaje del tiempo de su grupo se asignará a la prioridad. Esto garantiza que las transacciones no puedan dominar el sistema de tal manera que no se realice ningún trabajo del lote. Dentro de las diversas agrupaciones de prioridad, garantiza que se pueda asegurar algún progreso para cada grupo (a menos que el porcentaje del grupo sea cero). Estos algoritmos de "equidad" solo entran en juego cuando los procesadores están muy ocupados, pero los sistemas OS 2200 a menudo funcionan con todos los procesadores casi al 100% utilizados.
OS 2200 admite varios modelos para la gestión del rendimiento del sistema. [15] Los clientes pueden comprar un determinado nivel de rendimiento fijo y el administrador supervisará el uso del procesador para garantizar que el rendimiento no supere ese nivel. Los clientes también pueden comprar rendimiento adicional, ya sea temporal o permanente, hasta alcanzar la capacidad total del sistema si su carga de trabajo aumenta o si una emergencia lo requiere.
Más recientemente, el sistema ha incorporado una función de uso medido. En este modo, el cliente siempre tiene a su disposición toda la potencia del sistema (aunque puede limitarla administrativamente). El uso se acumula a lo largo de un mes y luego el uso informado se envía a la facturación de Unisys. Según los términos específicos del contrato, el cliente puede recibir una factura por el exceso de uso por encima de una base contratada para el mes o simplemente un estado de cuenta que muestra que se ha reducido el uso total contratado. La primera forma es como una factura de teléfono móvil con la posibilidad de cobrar por los minutos en exceso. La segunda es como comprar una tarjeta telefónica prepaga.
OS 2200 no tiene un sistema de archivos jerárquico como la mayoría de los demás sistemas operativos, sino que tiene una convención de nombres estructurada y el concepto de archivos contenedores llamados archivos de programa.
Los archivos en OS 2200 son simplemente contenedores a los que se puede acceder por desplazamiento de palabra en el archivo o por desplazamiento de sector (unidad de 28 palabras) en el archivo. Las 28 palabras son una unidad histórica de un dispositivo de almacenamiento masivo temprano (el tambor FASTRAND) que podía contener 64 de esas unidades por pista física. No obstante, es un accidente histórico afortunado. Cuatro de esas unidades de 28 palabras o 112 palabras ocupan 504 bytes. Como los dispositivos de almacenamiento masivo actuales utilizan todos registros físicos de 512 bytes, casi todos los clientes de OS 2200 han adoptado algún múltiplo de 112 palabras como tamaño de registro físico y tamaño de página de base de datos. Los procesadores de E/S se ajustan automáticamente a la asignación de bytes 504<->512, agregando 8 bytes de ceros en las escrituras y eliminándolos en las lecturas de cada registro físico. OS 2200 maneja aplicaciones que utilizan tamaños distintos a múltiplos de 112 palabras mediante la lectura indivisible de los registros físicos que los contienen y la reescritura de las partes modificadas y no modificadas mediante encadenamiento de datos. Las funciones de bloqueo especiales garantizan la indivisibilidad incluso cuando hay errores de dispositivo y en varios sistemas de un clúster.
Los formatos de archivo y otras estructuras de datos internas se describen en el Manual de referencia de programación de estructuras de datos . [16]
Desde Exec-8, los nombres de archivo han tomado la forma: Calificador*Nombre de archivo(ciclo-f) (por ejemplo, "PERSONAL*EMPLEADOS(+1)"). [11] El calificador y el nombre de archivo son simplemente cadenas de doce caracteres que se utilizan para crear cualquier estructura de nombres que desee el cliente. El ciclo-f es un número de 0 a 999 que permite múltiples generaciones de un archivo. Estos pueden ser referenciados por números relativos: (+1) próximo o nuevo ciclo, (-1) ciclo anterior, (+0) ciclo actual. Si se deja el ciclo desactivado, se utiliza el ciclo actual de forma predeterminada. Las ejecuciones de producción por lotes que crean nuevas generaciones de archivos utilizan este enfoque. Los números se reinician después de 999. Solo pueden existir 32 números de ciclo relativo consecutivos a la vez. Al crear un (+1) se elimina (-31).
Cualquier archivo puede utilizarse como archivo de programa. Un archivo de programa contiene elementos que generalmente actúan como archivos. La denominación de los elementos es Qualifier*Filename(f-cycle).Element/version(e-cycle) (p. ej., "PERSONNEL*PROGRAMS.TAXCALC/2008"). Element y version son nombres de doce caracteres que se utilizan de cualquier forma que desee el usuario. E-cycle es similar a f-cycle en que representa un número de generación pero sin la restricción de 32 ciclos simultáneos y el límite es de 256K ciclos. Sin embargo, e-cycle solo se aplica a elementos de texto y cada línea de un elemento de texto está marcada con los números de ciclo en los que se insertó y se eliminó. Los elementos también tienen un tipo y un subtipo. Los tipos más utilizados son "text" y "object". Si el tipo predeterminado no es adecuado, las opciones seleccionan el tipo apropiado. Los elementos de texto también tienen subtipos que normalmente representan el lenguaje de programación (p. ej., "ASM", "C", "COB", "FOR"). El nombre del elemento predeterminado de un archivo de objeto es el mismo que el del archivo de texto a partir del cual se creó.
Un elemento de objeto puede ejecutarse si es un programa principal o está vinculado con otros elementos de objeto, incluido un programa principal. La vinculación puede ser estática o dinámica. Un programa principal puede ejecutarse sin vinculación previa siempre que todos los subprogramas requeridos estén en el mismo archivo de programa, sean bibliotecas del sistema o se conozcan de otra manera. Se pueden incluir reglas en un archivo de programa para dirigir la búsqueda del vinculador dinámico de referencias no cumplidas. El vinculador también se puede utilizar para vincular estáticamente varios módulos de objeto para formar un nuevo módulo de objeto que contenga todas las instrucciones, datos y otra información de los módulos de objeto originales.
Los elementos ómnibus pueden ser utilizados como datos por las aplicaciones o pueden servir para almacenar información estructurada para aplicaciones y utilidades del sistema. No se supone que exista una estructura para un elemento ómnibus.
Para lograr compatibilidad con modelos de programación anteriores (modo básico), existen tipos de elementos reubicables y absolutos. Los elementos reubicables son la salida de los compiladores de modo básico. Pueden combinarse mediante el enlazador estático de modo básico (@MAP – el recopilador) para formar un elemento "absoluto" que es ejecutable.
OS 2200 implementa un sistema de archivos completamente virtual. Los archivos pueden asignarse en cualquier lugar de todos los dispositivos de almacenamiento masivo. El almacenamiento masivo se trata como un gran conjunto de espacio similar a la forma en que se administra la memoria virtual. Si bien se asigna espacio contiguo si es posible, el almacenamiento masivo se trata como un conjunto de páginas de 8 KB de tamaño y un archivo se puede colocar en tantas áreas del mismo dispositivo o de dispositivos diferentes como sea necesario. La expansión dinámica de archivos intenta asignar espacio adyacente a la asignación anterior, pero encontrará espacio donde esté disponible. De hecho, los archivos ni siquiera necesitan estar presentes en el almacenamiento masivo para ser utilizados. El sistema Exec y el sistema de respaldo de archivos están completamente integrados. Cuando se realizan respaldos de archivos, el número de carrete de cinta se registra en el directorio de archivos. Si el espacio en el almacenamiento masivo es escaso, algunos archivos simplemente se marcan como "descargados" si tienen una copia de respaldo actual y su espacio está disponible para su uso. Si no se puede encontrar suficiente espacio de esa manera, se inicia un respaldo.
Cualquier referencia a un archivo descargado se pondrá en cola mientras el archivo se copia de nuevo al almacenamiento masivo. Todo el sistema es automático y, en general, transparente para los usuarios. [17]
En general, el Exec no proporciona métodos de acceso . Los archivos son simplemente contenedores. Los métodos de acceso son proporcionados por los sistemas de tiempo de ejecución del lenguaje y el administrador de la base de datos. La única excepción es un método de acceso de bloque fijo proporcionado para el procesamiento de transacciones de alto volumen. [18] Tiene mucha menos sobrecarga que el administrador de la base de datos, pero participa en todos los mecanismos de bloqueo, agrupamiento y recuperación.
Cuando los clientes desean un control más explícito sobre la ubicación de los archivos, pueden utilizar el concepto de "paquete extraíble". En un momento, estos paquetes representaban paquetes de discos extraíbles físicamente y el sistema operativo generaba automáticamente solicitudes de montaje de paquetes para los operadores según fuera necesario.
Hoy en día, todavía se utilizan para colocar archivos, generalmente archivos de bases de datos o archivos de transacciones, en uno o más volúmenes de disco. Los archivos aún pueden abarcar varios volúmenes de disco y ahora la lista de nombres de volúmenes se proporciona cuando se crea el archivo. Los archivos que se encuentran en dichos grupos de volúmenes aún se respaldan, pero no están sujetos a la administración automática del espacio virtual.
OS 2200 también proporciona una implementación completa del Common Internet File System ( CIFS ). [19] CIFS implementa el protocolo SMB utilizado por los servidores de Microsoft y el software Samba de UNIX/Linux . CIFS para ClearPath OS 2200 es a la vez un servidor de archivos y un cliente de archivos para otros sistemas compatibles con CIFS. Esto incluye PC de escritorio que ejecutan Windows. CIFS admite la firma de mensajes SMB.
Para mantener la seguridad de OS 2200, CIFS para ClearPath OS 2200 proporciona dos niveles de protección. En primer lugar, los archivos de OS 2200 no son visibles para la red hasta que se los haya declarado como "recursos compartidos" con un comando CIFS. Existe un privilegio específico para controlar quién puede declarar un recurso compartido. El segundo nivel de control es que todo el acceso sigue estando protegido por la seguridad de OS 2200. Los clientes que accedan a OS 2200 a través de CIFS tendrán que ser identificados automáticamente a través de NTLM o Kerberos o se les presentará una consulta para su ID de usuario y contraseña de OS 2200.
CIFS permite que los archivos OS 2200 se presenten en una vista jerárquica. Normalmente, el calificador aparecerá como el nivel más alto en el árbol seguido del nombre de archivo, el nombre del elemento y la versión. Además, los archivos se pueden almacenar en servidores OS 2200 utilizando el formato de nombre de archivo completo de Windows. Las aplicaciones de Windows verán a OS 2200 como otro servidor de archivos. Las aplicaciones OS 2200 tienen API disponibles para leer y escribir archivos existentes en otros servidores compatibles con CIFS, como servidores de archivos de Windows, en la red. Los archivos de texto se convierten automáticamente a y desde formatos internos de OS 2200. El programa de aplicación debe comprender los archivos binarios.
La utilidad CIFSUT que se ejecuta en OS 2200 puede intercambiar archivos comprimidos cifrados con otro software, como WinZip.
El concepto de subsistemas y subsistemas protegidos es fundamental para el diseño del sistema operativo 2200. Un subsistema es muy similar a un archivo .dll en Windows. Se trata de código y datos que pueden compartirse entre todos los programas que se ejecutan en el sistema. [20] En el sistema operativo 2200, cada subsistema tiene su propio conjunto de bancos que residen en una parte separada del espacio de direcciones a la que ningún programa de usuario puede acceder directamente. En cambio, el hardware y el sistema operativo proporcionan una "puerta" que puede ser el objetivo de una instrucción Call. Consulte la arquitectura del sistema de la serie Unisys 2200 para obtener más información.
Los administradores de bases de datos, las bibliotecas de tiempo de ejecución, el sistema de mensajería y muchas otras funciones del sistema se implementan como subsistemas. Algunos subsistemas, que normalmente consisten en código puro, como las bibliotecas de tiempo de ejecución, pueden ser el objetivo directo de una instrucción Call sin necesidad de una compuerta. Estos subsistemas se ejecutan en el entorno de protección del programa de usuario. Otros subsistemas, como los administradores de bases de datos, consisten en código y datos o código privilegiado y solo se pueden llamar a través de una compuerta. Estos subsistemas también pueden tener listas de control de acceso asociadas a ellos para controlar quién puede llamarlos. Más importante aún, la compuerta controla los puntos de entrada específicos que son visibles, el entorno de protección en el que se ejecutará el subsistema y, a menudo, un parámetro específico del usuario que proporciona información segura adicional sobre el llamador.
El sistema de seguridad OS 2200 está diseñado para proteger los datos contra acceso, modificación o exposición no autorizados. Incluye una implementación de la especificación de nivel B1 del Libro Naranja del Departamento de Defensa . [21] OS 2200 obtuvo por primera vez una evaluación B1 exitosa en septiembre de 1989. Esa evaluación se mantuvo hasta 1994. Después de ese punto, los desarrolladores de OS 2200 continuaron siguiendo las prácticas de desarrollo y documentación requeridas por la evaluación B1.
Los conceptos de usuarios y objetos son fundamentales para un sistema B1. [22] [23] Los usuarios tienen identidades, niveles de autorización, compartimentos y privilegios. Los objetos requieren ciertas combinaciones de estos para varios tipos de acceso. Los objetos en OS 2200 consisten en archivos, subsistemas protegidos, dispositivos y carretes de cinta.
El perfil de seguridad de una sesión de usuario incluye la identidad del usuario, el nivel de autorización (0-63), el conjunto de compartimentos y el conjunto de privilegios permitidos. OS 2200 implementa tanto el Control de acceso obligatorio (MAC) como el Control de acceso discrecional (DAC) según el modelo Bell-La Padula para confidencialidad (sin lectura ascendente, sin escritura descendente) y el modelo de integridad Biba (sin lectura descendente, sin escritura ascendente). Para que una ejecución lea o ejecute un archivo, el nivel de autorización de ejecución de la ejecución debe ser mayor o igual que el nivel de autorización del archivo, y el nivel de autorización del archivo debe ser 0 o estar dentro del rango del nivel de autorización de la ejecución; además, el conjunto de compartimentos de ejecución de la ejecución debe contener el conjunto de compartimentos del archivo. Debido a que OS 2200 combina los requisitos del modelo Bell-La Padula y Biba, el nivel de autorización de ejecución de una ejecución y el conjunto de compartimentos deben coincidir exactamente con los de un archivo para permitir escribir en el archivo o eliminarlo.
DAC asocia una lista de control de acceso con un objeto; la lista identifica a los usuarios y grupos de usuarios que tienen acceso y define el tipo de acceso que se le permite a ese usuario o grupo (lectura, escritura, ejecución o eliminación).
Dado que el conjunto completo de controles B1 es demasiado restrictivo para la mayoría de los entornos, los administradores de sistemas pueden configurar los servidores eligiendo qué controles aplicar. Un conjunto de niveles de seguridad, desde Seguridad básica hasta Nivel de seguridad 3, sirve como punto de partida.
Cada sistema OS 2200 tiene un usuario designado como responsable de seguridad. En los sistemas configurados con seguridad básica, solo el responsable de seguridad puede realizar determinadas tareas. En los sistemas configurados con niveles de seguridad más altos, es posible que otros usuarios de confianza puedan realizar algunas de estas tareas.
OS 2200 ofrece un mecanismo de seguridad de grano fino basado en el principio del mínimo privilegio . Este principio exige que solo se conceda el privilegio mínimo necesario para realizar la tarea requerida. Por lo tanto, OS 2200 no tiene el concepto de un rol de "superusuario" que pueda ser asumido por cualquier usuario. En cambio, utiliza un gran conjunto de privilegios específicos que pueden otorgarse por separado a cada usuario. Cada privilegio está asociado con una autoridad específica.
En los sistemas configurados con el nivel de seguridad 1 o superior, el usuario que crea un objeto es el propietario del mismo. El valor predeterminado es que el objeto sea privado para el usuario que lo crea, pero también puede ser público o estar controlado por una lista de control de acceso. El propietario o el responsable de seguridad pueden crear una lista de control de acceso para ese objeto.
En un sistema configurado con seguridad básica, los archivos no tienen propietarios. En cambio, se crean de forma privada para una cuenta o proyecto, o son públicos. El acceso a ellos se puede controlar mediante claves de lectura y escritura.
Cuando los usuarios inician sesión en el sistema, se identifican y, opcionalmente, seleccionan el nivel de autorización y el conjunto de compartimentos que utilizarán para esta sesión.
OS 2200 ofrece un sistema de autenticación flexible. Se admiten varios mecanismos de autenticación simultáneamente. También se puede utilizar software de autenticación creado por el cliente o por terceros. Las capacidades de autenticación estándar incluyen:
Los dos últimos permiten el uso de biometría, tarjetas inteligentes y cualquier otro mecanismo de autenticación soportado por dichas tecnologías.
OS 2200 proporciona cifrado para datos en reposo a través de Cipher API, un subsistema de software que cifra y descifra los datos de la persona que llama. [24] Cipher API también admite el uso de una tarjeta aceleradora de hardware para el cifrado de datos masivos.
Para los servidores Dorado basados en CMOS, CPComm proporciona cifrado SSL/TLS para los datos en tránsito . Para los servidores Dorado basados en Intel, SSL y TLS son proporcionados por openSSL , que está incluido en el firmware Dorado. Todos los servidores Dorado admiten los niveles TLS 1.0 a 1.2, así como SSLv3, pero SSL está deshabilitado de forma predeterminada debido a vulnerabilidades en el protocolo.
Tanto CPComm como Cipher API utilizan los servicios de cifrado de CryptoLib, un módulo de cifrado de software con certificación FIPS . Los algoritmos AES y Triple DES se encuentran entre los algoritmos implementados en CryptoLib.
OS 2200 también admite unidades de cinta de cifrado, que proporcionan cifrado para datos archivados.
Los sistemas OS 2200 pueden agruparse para lograr un mayor rendimiento y disponibilidad que un solo sistema. Se pueden combinar hasta 4 sistemas en un clúster que comparta bases de datos y archivos a través de discos compartidos. Un dispositivo de hardware, el XPC-L, proporciona coordinación entre los sistemas al proporcionar un administrador de bloqueo de alta velocidad para el acceso a bases de datos y archivos. [25]
Un entorno en clúster permite que cada sistema tenga sus propios archivos locales, bases de datos y grupos de aplicaciones junto con archivos compartidos y uno o más grupos de aplicaciones compartidos. Solo un único sistema puede acceder a los archivos y bases de datos locales. Los archivos y bases de datos compartidos deben estar en discos a los que se pueda acceder simultáneamente desde todos los sistemas del clúster.
El XPC-L proporciona una vía de comunicación entre los sistemas para la coordinación de acciones. También proporciona un motor de bloqueo muy rápido. La conexión con el XPC-L se realiza a través de un procesador de E/S especial que funciona con latencias extremadamente bajas. El administrador de bloqueos del XPC-L proporciona todas las funciones necesarias para los bloqueos de archivos y bases de datos. Esto incluye la detección de bloqueos y la capacidad de liberar bloqueos de aplicaciones fallidas.
El XPC-L se implementa con dos servidores físicos para crear una configuración totalmente redundante. El mantenimiento, incluida la carga de nuevas versiones del firmware del XPC-L , se puede realizar en uno de los servidores mientras el otro continúa en funcionamiento. Las fallas, incluido el daño físico a un servidor, no detienen el clúster, ya que toda la información se mantiene en ambos servidores.
Las operaciones del sistema operativo 2200 se basan en operadores activos y una o más consolas. Cada consola es una ventana de terminal, parte de la cual está reservada para una pantalla fija que se actualiza con frecuencia con información resumida sobre la actividad en el sistema. [26]
El resto de la consola se utiliza como una pantalla de eventos desplazable. Cuando se emite un mensaje que requiere una respuesta del operador, se le asigna un número del 0 al 9 y permanece en la pantalla hasta que se responde. Los mensajes de montaje de cinta se desplazan con otros mensajes, pero se repetirán cada dos minutos hasta que se monte la cinta.
Operations Sentinel se utiliza para todas las operaciones del sistema operativo 2200. [27] Las consolas del sistema operativo 2200 son simplemente ventanas dentro de una pantalla de Operations Sentinel. Puede haber tantas PC de pantalla como se desee. La operación remota es típica. Operations Sentinel admite cualquier cantidad de sistemas ClearPath, Windows, Linux y UNIX.
Con el producto se incluye una base de datos de mensajes de acción automática. [28] Esta base de datos permite a Operations Sentinel reconocer mensajes. Se pueden escribir scripts para responder automáticamente a los mensajes que requieren una respuesta, ocultar mensajes no deseados, traducirlos a otros idiomas, crear eventos, etc. Algunos clientes utilizan la operación de sala oscura completa. Como máximo, tendrán pantallas de Operations Sentinel en ubicaciones remotas que monitorean el sistema y crean alertas cuando ocurren ciertos eventos.
La administración de los sistemas OS 2200 se realiza mediante una amplia variedad de herramientas, cada una especializada en un área particular del sistema. Por ejemplo, existe una herramienta que se utiliza para administrar el entorno de transacciones que permite instalar nuevos programas de transacciones, especifica toda la información necesaria sobre ellos, cambia la estructura de colas, las prioridades y los niveles de concurrencia, etc. [29]
Otras herramientas son específicas del responsable de seguridad y permiten la creación de usuarios, cambiar privilegios permitidos, cambiar configuraciones de seguridad del sistema, etc. [22] , [30] , [23]
La mayoría de las herramientas tienen una interfaz gráfica, aunque algunas no. Todas proporcionan una interfaz de archivo almacenado por lotes donde todas las acciones se especifican en el flujo de control. Esto permite crear scripts para todas y cada una de las interfaces administrativas desde sitios locales, tal vez en función de la hora del día u otros eventos, o desde sitios remotos. Se requieren privilegios únicos para cada área administrativa.
Los grupos de aplicaciones son una construcción lógica que consta de una instancia del Sistema de datos universal (UDS), [31] una instancia del subsistema de cola de mensajes y un conjunto de transacciones. Cada grupo de aplicaciones tiene su propio registro de auditoría. OS 2200 admite un máximo de 16 grupos de aplicaciones en un sistema.
El concepto de grupo de aplicaciones corresponde a lo que se suele denominar "una aplicación", es decir, un conjunto de programas y datos que representan una unidad mayor de procesamiento conectado. Por ejemplo, un grupo de aplicaciones podría representar un sistema de aerolíneas, otro grupo de aplicaciones podría representar el sistema de finanzas corporativas o bien, los grupos de aplicaciones podrían representar instancias de la misma aplicación y modelos de datos, como en las sucursales bancarias. Lo importante es que cada grupo de aplicaciones tenga su propio entorno, sesiones, recuperación, etc.
Los grupos de aplicaciones pueden iniciarse, detenerse y recuperarse de forma independiente.
Los grupos de aplicaciones no tienen sus propias reglas de contabilidad y programación. Las transacciones en varios grupos de aplicaciones pueden compartir las mismas prioridades y tener prioridades intercaladas. Esto permite que el sitio controle las prioridades relativas de las transacciones en todo el sistema.
El boletín informativo sobre la historia de Unisys contiene artículos sobre la historia de Unisys y las computadoras. Además de todos los boletines informativos sobre la historia de Unisys, hay enlaces a otros sitios.
La mayor parte de los archivos históricos de Unisys se encuentran en el Instituto Charles Babbage de la Universidad de Minnesota y en el Museo y Biblioteca Hagley de Delaware. El Instituto Charles Babbage conserva los archivos de ERA, algunos archivos antiguos de Remington Rand de Saint Paul, Minnesota, y los archivos de Burroughs. El Museo y Biblioteca Hagley conserva la mayor parte de los archivos de Sperry.
Un artículo introductorio muy útil sobre OS 2200 en la década de 2020 en Arcane Sciences.