Sistema operativo 2200

EXEC 8 (a veces denominado EXEC VIII) fue el sistema operativo de UNIVAC desarrollado para la UNIVAC 1108 en 1964. Combinaba las mejores características de los sistemas operativos anteriores, EXEC I y EXEC II , que se utilizaban en la UNIVAC 1107. EXEC 8 fue uno de los primeros sistemas operativos multiprocesamiento de éxito comercial . Admitía cargas de trabajo mixtas simultáneas que comprendían procesamiento por lotes , tiempo compartido y tiempo real . Su único sistema de archivos tenía una estructura de nombres plana en múltiples tambores y husillos. También admitía un sistema de procesamiento de transacciones que tuvo una buena acogida .

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 existía soporte para la multiprogramación en sistemas anteriores, este se limitaba a ejecutar un trabajo de usuario simultáneamente con múltiples funciones de soporte que se sabía que funcionaban correctamente, como el lector de tarjetas, la impresora y los gestores de impresió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 se concibió para un mercado más general, el procesamiento en tiempo real extremo era un requisito fundamental. ^{[ 5 ]}

Las especificaciones para Exec 8 se elaboraron en diciembre de 1964 como un Manual de Referencia para Programadores 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, utilizado inicialmente sobre todo en trabajos científicos y de ingeniería en general, pero también se empleó en conmutación de mensajes , control de procesos , simulación y control de lanzamiento de misiles. Fue diseñado para ejecutarse en sistemas que a menudo solo disponían de 128 KB de memoria (576 KB, menos que la capacidad máxima de memoria del IBM PC XT ), y se centraba en el procesamiento en tiempo real y por lotes. Si bien las primeras versiones funcionaban con 128 KB, el aumento de funcionalidades en versiones posteriores hizo que esto resultara insostenible, ya que no dejaba suficiente espacio para programas de tamaño útil. La capacidad máxima de memoria de un 1108 era de 256 KB (1152 KB), por lo que el uso eficiente de la memoria era la limitación más importante, dado que la memoria principal era el componente más costoso del sistema.

El almacenamiento masivo consistía en tambores giratorios de 1,8 metros de largo con capacidades que iban desde 256 kW (en el FH-432) hasta 2 MW (en el FH-1782). El tambor de mayor capacidad era el FASTRAND , con 22 MW (99 MB). La fragmentación de archivos se gestionaba mediante un proceso denominado "guardado de archivos", que generalmente se realizaba una vez al día, por la noche. Este proceso consistía en transferir todos los archivos a cinta, reinicializar el sistema de archivos del tambor y, a continuación, volver a cargar los archivos.

Debido a las severas limitaciones de memoria y al uso en tiempo real, era imprescindible mantener una única copia del código cargada en el núcleo. Dado que el 1108 fue diseñado para la multitarea, 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 contexto de ejecución podía realizarse con una sola instrucción, simplemente estableciendo una dirección base diferente en un único registro. El sistema utilizaba un bloqueo granular para proteger las estructuras de datos compartidas. El ejecutivo, los compiladores, las utilidades e incluso las sofisticadas aplicaciones de usuario que podían tener múltiples copias ejecutándose simultáneamente se escribieron de forma que su código pudiera compartirse. Esto requería cargar solo una copia en la memoria, ahorrando tanto espacio como tiempo de carga del código.

Otra razón para separar el código y los datos en entidades de carga distintas era que la memoria se implementaba como dos bancos independientes (compartimentos 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 debía ser seguro para subprocesos (solo ejecución); no se permitía el código automodificable . Para otros programas, modificar el código ejecutable durante la ejecución seguía siendo una técnica de programación aceptable en la época de los ordenadores de la serie 1100, pero se desaconsejaba a los usuarios hacerlo debido a la disminución del rendimiento. Se pregonaban las ventajas de seguridad, pero no se les daba mucha importancia, ya que piratear la mayoría de las aplicaciones de la serie 1100 no reportaría ningún beneficio a nadie, y porque en aquel entonces pocos piratas informáticos tenían malas intenciones.

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 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 ejecutaba el subproceso de menor prioridad de cualquier programa. Excepto en sistemas en tiempo real, incluso las tareas de menor prioridad recibían tiempo de procesador. Era un sistema operativo multiprogramación y multiprocesamiento con gestión de procesador totalmente simétrica. Una instrucción de prueba y ajuste integrada en el hardware permitía un bloqueo muy eficiente y preciso tanto dentro del sistema operativo como dentro de las aplicaciones multihilo.

En Exec 8, el trabajo se organiza en tareas, llamadas "ejecuciones", que se programan según su prioridad y la necesidad de recursos bloqueables, como unidades de cinta Uniservo o archivos de tambor Fastrand. La sintaxis del lenguaje de control utiliza el símbolo "@" (que Univac denominaba "el espacio maestro") como símbolo de reconocimiento de la instrucción de control. A continuación, se indicaba el comando o el nombre del programa, seguido de una coma y cualquier parámetro de opción. Tras un espacio, el resto de la instrucción variaba según el comando. Un comando para compilar un programa Fortran tendría el formato "@FOR[,opciones] archivo_origen, archivo_objeto". Los datos de entrada para una aplicación podían leerse de un archivo (generalmente imágenes de tarjetas) o seguir inmediatamente al comando "@" en el flujo de ejecución. Todas las líneas hasta el comando centinela "@END" se consideraban datos de entrada, por lo que olvidar insertarlo provocaba que el compilador interpretara los comandos subsiguientes como datos del programa. Por este motivo, era preferible procesar los datos en archivos en lugar de introducirlos en el flujo de ejecución.

En 1968, se comenzó a trabajar en la incorporación de la funcionalidad de tiempo compartido a Exec 8. Esta funcionalidad se incluyó en el nivel 23 del sistema en 1969. El tiempo compartido (denominado modo bajo demanda ) ofrecía las mismas capacidades que los procesos por lotes y en tiempo real. Todo lo que se podía realizar en modo por lotes podía hacerse desde una terminal ASCII. En el modo bajo demanda, la entrada/salida del flujo de trabajo se conectaba a un controlador de terminal en lugar de a archivos de imagen de tarjeta (entrada) y de cola (salida). Se utilizaba el mismo lenguaje de control de ejecución para ambos. Unos años más tarde, se añadieron comandos de tiempo compartido más específicos, y algunas instrucciones de control podían emitirse de forma asíncrona para su procesamiento inmediato, incluso cuando ni el sistema ni el programa en ejecución esperaban datos. Estos comandos, que solo podían introducirse desde una terminal, comenzaban con "@@". Dado que podían ejecutarse sin interrumpir otros trabajos en curso desde la misma terminal, se denominaron comandos transparentes. Al principio, se trataba simplemente de instrucciones para finalizar el programa actual o redirigir la salida de la terminal a un archivo, pero finalmente, casi todas las instrucciones de control pudieron ejecutarse de forma inmediata.

Tanto las ejecuciones por lotes como las ejecuciones bajo demanda finalizan con una instrucción @FIN, y si un usuario bajo demanda finaliza su sesión mientras su ejecución está activa, Exec finaliza automáticamente la ejecución sin necesidad de @FIN.

A finales de la década de 1960, se desarrolló una capacidad de procesamiento de transacciones como proyecto conjunto con United Airlines, la cual se perfeccionó posteriormente en otro proyecto conjunto con Air Canada. Esta capacidad se integró completamente al 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 incluyó un sistema de mensajería que gestionaba las líneas de comunicación y presentaba los mensajes a Exec 8 para su programación como transacciones. Esto trasladó toda la gestión de líneas físicas y protocolos de comunicación de bajo nivel fuera de las aplicaciones y a la aplicación CMS 1100.

El propio CMS 1100 funcionaba como un programa multihilo en tiempo real con la capacidad de controlar las líneas de comunicación y enviar mensajes de transacción para su programación. Esto dio lugar a la idea, en Exec 8, de que las aplicaciones de cualquier tipo debían controlarse cuidadosamente para garantizar que no pudieran causar problemas de integridad. La seguridad era sin duda una preocupación, pero en sus inicios, la fiabilidad e integridad del sistema eran cuestiones mucho más importantes. El sistema seguía siendo principalmente de procesamiento por lotes y de transacciones, y había pocas posibilidades de que alguien pudiera instalar código no autorizado. Posteriormente, el CMS 1100 incorporó la capacidad de ser la interfaz tanto para terminales de demanda como para terminales de transacciones, de modo que los terminales pudieran utilizarse para ambos fines y se pudieran eliminar los controladores de terminales iniciales del Exec. El CMS 1100 fue posteriormente reemplazado por una combinación de CPComm (ClearPath Enterprise Servers Communications Platform) y SILAS (System Interface for Legacy Application Systems). ^{[ 8 ] [ 9 ]} Para los modelos de servidor Dorado basados ​​en Intel, las comunicaciones de nivel inferior se trasladaron al firmware, mientras que los niveles superiores fueron gestionados por SILAS y CPCommOS (ClearPath Enterprise Servers Communications Platform for Open Systems). ^{[ 10 ]}

El archivo Exec contiene todo el código del sistema que tiene permiso para ejecutarse con los niveles de privilegio más altos. No existen mecanismos para que otro código pueda alcanzar esos niveles de privilegio.

El ejecutivo es responsable de gestionar el hardware del sistema, programar y administrar el trabajo, y comunicarse con los operadores y administradores.

En la versión 16.0, el Exec es de nivel 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 versiones anteriores se utilizaron 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 a intervalos de años. La segunda parte del número indica las versiones de las actualizaciones al nivel principal y suele ocurrir varias veces por semana. Cuando se decide congelar el contenido de las características y prepararse para el lanzamiento, entra en juego la tercera parte, que indica las versiones del nivel de prelanzamiento a medida que se aplican correcciones y actualizaciones menores de características. Simultáneamente con la preparación de un nivel para el lanzamiento, las actualizaciones de la "línea principal" continúan a medida que los ingenieros integran los 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. Las versiones posteriores se denominaron simplemente 44R1, 44R2, 49R2, y así sucesivamente, aunque internamente todavía se utiliza la numeración de tres partes.

Realizar trabajo

El Exec es, en esencia, un sistema de procesamiento por lotes multihilo en tiempo real. Todo se ha diseñado en torno a este modelo. El propio Exec está estructurado principalmente como un programa en tiempo real. Las funciones que se ejecutan como servicios en Windows o como demonios en sistemas tipo Unix se implementan como actividades dentro del Exec o como programas por lotes que se ejecutan continuamente en segundo plano.

El modo de tiempo compartido (conocido como modo bajo demanda ) y el procesamiento de transacciones se implementan como casos especiales del procesamiento por lotes. Esto implica que existen pocas restricciones sobre lo que puede hacer un usuario o programa de transacciones en modo de tiempo compartido. Si bien se advierte a los desarrolladores de programas de transacciones que el rendimiento podría verse afectado si, por ejemplo, se requiere el montaje de una cinta, esto está permitido.

La unidad de trabajo más grande es la "Ejecución". Este término proviene de la terminología de "producción en serie" de la 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. Estos pueden incluir la gestión de archivos, la ejecución de programas y las bifurcaciones de control. Una Ejecución por lotes se almacena normalmente como un archivo y se programa mediante un comando "Iniciar" desde otra Ejecución o por el operador. Una Ejecución de tiempo compartido se inicia al iniciar sesión desde una terminal de tiempo compartido e introducir el comando @RUN. A menudo, la instrucción @RUN y la segunda instrucción de control (generalmente @ADD o la ejecución de un programa) se generan automáticamente en función del perfil del usuario. Las autorizaciones de seguridad se validan en función del ID de usuario autenticado y otra información proporcionada en la instrucción de control de la Ejecución.

Las transacciones constituyen un caso especial. Si bien no existen instrucciones de control, sí se crean las estructuras de datos internas de una ejecución. Esto permite al Exec asociar los mismos mecanismos de seguridad, contabilidad, depuración, etc., a los programas de transacción. Generalmente, se almacena en caché un perfil de seguridad en la memoria cuando se autentica el usuario de la transacción y se copia de los datos de sesión del usuario al estado de ejecución de la transacción cuando esta se programa. Dado que cada instancia de transacción es esencialmente una ejecución, la contabilidad, el registro y el manejo de errores están encapsulados por el mecanismo de ejecución.

Lote

Los trabajos por lotes (ejecuciones) se caracterizan por tener un flujo de ejecución (declaraciones del lenguaje de control de trabajos) almacenado en un archivo. Un trabajo por lotes siempre contiene una declaración @RUN como primer registro del archivo. Esta declaración asigna un nombre (id de ejecución) a la ejecución, define las prioridades y especifica el número máximo de SUPS (Unidades Estándar de Procesamiento) que se espera que utilice. El trabajo se inicia desde otro trabajo mediante una declaración de control @START o por el operador mediante una entrada de teclado ST. El sistema puede configurarse para emitir automáticamente declaraciones @START para cualquier número de trabajos al arrancar. 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 sobrescritos por los campos correspondientes de la instrucción @START. Salvo cuando @START es ejecutada por un usuario con privilegios, el ID de usuario y demás información de seguridad siempre se toman del proceso que ejecuta @START.

La instrucción @RUN tiene dos campos de prioridad. Uno se usa para especificar la prioridad de la cola de espera. Hay 26 niveles de prioridad (A-Z). El Exec tiene configurado un número máximo de ejecuciones por lotes abiertas. Cuando se alcanza ese nivel, los trabajos se seleccionan de las colas de espera en orden de prioridad. Dentro de la selección por prioridad, generalmente se aplica el principio FIFO (primero en entrar, primero en salir). Sin embargo, el Exec preescanea las instrucciones de control de trabajos hasta la primera ejecución del programa, buscando nombres de archivo y números de rollo. Si el trabajo se detuviera inmediatamente porque algunos de los recursos que necesita no están disponibles, se puede omitir para iniciar otros trabajos del mismo nivel de prioridad.

El segundo nivel de prioridad define un grupo de recursos del procesador de ejecución. En general, las prioridades más altas de los grupos de ejecución suelen obtener más tiempo de procesador.

Aunque el lenguaje de control de trabajos del OS 2200 no admite una programabilidad completa, permite la adición dinámica de secuencias de lenguaje de control mediante una instrucción de control @ADD. El archivo que se va a añadir puede haber sido creado por el mismo trabajo inmediatamente anterior a su adición. La instrucción @ADD y la mayoría de las demás instrucciones de control también pueden enviarse desde dentro de un programa en ejecución a través de una API. ^{[ 11 ]} La programabilidad adicional está disponible indirectamente 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 ampliamente para el procesamiento de la gestión de configuración ( make ) y otras funciones donde se necesitan crear imágenes de texto programáticamente. La salida resultante puede ser "@ADD" en la misma ejecución, lo que proporciona el flujo de ejecución programable indirectamente.

SSG fue creado originalmente por Univac para la generación de actualizaciones de sistemas operativos (SO). Posteriormente, fue adoptado por la comunidad de usuarios en general para la creación de procesos informáticos complejos, tanto por lotes como en tiempo real. Los archivos fuente podían hacer referencia recursiva a otros archivos, lo que proporcionaba una gran flexibilidad en el análisis de entrada. Las reglas para la generación de salida también se encontraban en los archivos fuente, con niveles similares de capacidad de entrada dinámica. La interpretación de los múltiples archivos de entrada permitía la creación dinámica del contenido del flujo de salida. Se podían aplicar procesos recursivos complejos para generar código fuente de programas, secuencias de ejecución de trabajos, entrada dinámica simulada desde consolas virtuales y, en general, proporcionar capacidades de scripting similares a las de las herramientas grep y yacc de Unix .

Los comandos del operador permiten modificar tanto la cola de ejecución como las prioridades de ejecución. Dado que todos los comandos del operador están disponibles mediante API para usuarios con los privilegios adecuados, esto puede automatizarse o controlarse de forma remota por un administrador.

La ejecución con fecha límite es un caso especial de procesamiento por lotes. Una ejecución con fecha límite se ve igual que cualquier otra ejecución por lotes, excepto que se especifica una hora límite en la instrucción de control @RUN o @START. La hora límite se usa junto con el tiempo estimado máximo (SUPS) en la instrucción de control. Un trabajo con fecha límite se ejecuta con prioridades de procesamiento por lotes normales a menos que parezca que podría perder su tiempo límite. Entonces, cuanto mayor sea la discrepancia entre el tiempo restante hasta la fecha límite y el tiempo estimado restante (SUPS), mayor será la prioridad. Si bien la ejecución con fecha límite no puede detener completamente las transacciones y no afecta el tiempo real, puede detener la mayor parte del procesamiento en el sistema si es necesario para lograr su objetivo.

Demanda

Las sesiones de tiempo compartido del sistema operativo OS 2200 se denominan ejecuciones bajo demanda (del latín "on demand"). Utilizan el mismo lenguaje de control que las ejecuciones por lotes, con algunas adiciones conocidas como instrucciones de control "inmediatas". Estas instrucciones utilizan el símbolo "@@", que indica que deben ejecutarse inmediatamente, incluso si hay un programa en ejecución. Si bien pueden utilizarse para crear o asignar archivos, las más importantes permiten que un usuario bajo demanda finalice un programa en ejecución por error o incluso le envíe una señal.

Actas

Las transacciones se ejecutan como ejecuciones, pero sin instrucciones de control almacenadas ni enviadas. En cambio, cuando se recibe un mensaje de una sesión definida como sesión de transacción, se analiza para determinar la cola de transacciones en la que debe colocarse. Normalmente, esto se determina por los primeros caracteres del mensaje, pero se pueden añadir analizadores escritos por el usuario. ^{[ 13 ]}

El gestor de comunicaciones, capaz de administrar hasta 250 000 sesiones activas, recibe los mensajes de transacción entrantes y los transfiere al software de cola de mensajes. Mediante la arquitectura de cola de mensajes, puede gestionar un número ilimitado de mensajes en cola. Se realiza una llamada a las API del Paquete de Interfaz de Transacciones (TIP) del sistema operativo para poner la transacción en cola en el punto de cola correspondiente. Cada punto de cola identifica la prioridad y el nivel de concurrencia de la tarea, así como el programa de transacción asociado que se ejecutará.

Un árbol de planificación de programas de transacciones permite al cliente establecer el uso relativo de grupos de programas de transacciones. Los límites de concurrencia evitan que un tipo de trabajo domine el sistema, excluyendo a otros, y previenen la sobrecarga de recursos. Se pueden crear hasta 4094 nodos en el árbol.

• Concurrencia máxima especificada para cada nodo en el árbol.
• La concurrencia de nodos superiores limita la concurrencia total de nodos dependientes.
• La concurrencia del nodo más alto limita la concurrencia del sistema.

Se puede especificar la prioridad (de 0 a 63) y el nivel de concurrencia (de 1 a 2047) para cada programa de transacción.

Se selecciona la transacción de mayor prioridad para su programación, salvo las limitaciones impuestas por las políticas de concurrencia vigentes para su nodo y los nodos superiores.

Tiempo real

El procesamiento en tiempo real no es otro tipo de ejecución, sino un conjunto de niveles de prioridad que cualquier actividad puede solicitar. Suele utilizarse en programas por lotes de larga duración, como el gestor de comunicaciones CPComm del sistema operativo OS 2200, pero no se limita a estos.

La API ofrece 36 niveles de prioridad en tiempo real para que las aplicaciones los utilicen. El usuario y la cuenta deben tener el privilegio de usar las prioridades en tiempo real. El sitio web controla cómo sus aplicaciones utilizan estos niveles de prioridad. Las prioridades en tiempo real tienen prioridad absoluta sobre las prioridades inferiores, por lo que es muy posible que un programa que funcione incorrectamente sature uno o más procesadores.

La prioridad en tiempo real se aplica a una actividad individual (hilo), por lo que un programa puede tener hilos en tiempo real y hilos que no lo son ejecutándose al mismo tiempo.

Despacho de CPU

Una vez iniciada una ejecución, el acceso al procesador controla su ritmo de progreso. El núcleo del Exec es el Dispatcher , que gestiona 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. Se trata del reconocimiento de ciertos tipos de procesamiento que deben continuar en el procesador en el que se iniciaron hasta que cedan el control voluntariamente. El bloqueo de interrupciones se produce cuando llega una interrupción o, en algunos casos especiales, cuando otro código Exec impide todas las interrupciones (para modificar ciertos datos a los que también podría 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, la finalización de E/S y el inicio 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 otro proceso 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 gestor de comandos del operador y otras funciones que pueden tener que ejecutarse incluso cuando un programa en tiempo real tiene el control. Se espera que consuman muy poco tiempo. Si necesitan más tiempo, deben poner el trabajo en cola para que lo procese una actividad de ejecución baja.

Las actividades en tiempo real disponen de un cuanto de procesador ilimitado y se ejecutan sin interrupciones, salvo que sean interrumpidas por una actividad en tiempo real de mayor prioridad o una actividad de ejecución de alto nivel. Las actividades en tiempo real controlan cualquier procesador disponible que esté ejecutando una tarea de menor prioridad. Se envían interrupciones entre procesadores cuando es necesario para garantizar la disponibilidad inmediata. Los clientes utilizan el procesamiento en tiempo real para el lanzamiento de misiles, la ejecución de simuladores y otras funciones que requieren una respuesta inmediata.

Las prioridades de las transacciones pueden gestionarse de dos maneras, según lo defina el sitio. Pueden ser de menor prioridad y en tiempo real, donde solo importa la prioridad y el tamaño del cuanto es prácticamente infinito. Esto es apropiado para transacciones muy breves, como las reservas de vuelos; si una entra en un bucle debido a un error de programación, el Exec la finalizará cuando alcance su tiempo máximo configurado, que es 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. Este enfoque otorga mayor prioridad y segmentos de tiempo más cortos a los programas con limitaciones de E/S, y prioridades progresivamente más bajas, pero segmentos de tiempo más largos, a aquellos que realizan cálculos. El Exec ajusta dinámicamente estas prioridades en función del comportamiento, ya que los programas suelen comportarse de ambas maneras en diferentes momentos. Este enfoque es apropiado para transacciones de mayor duración, como consultas a bases de datos o cotizaciones de tarifas aéreas.

El procesamiento por lotes y bajo demanda siempre utiliza prioridades ajustadas dinámicamente. Los programas con limitaciones de E/S o que interactúan con un usuario de tiempo compartido obtienen mayor prioridad, pero menor tiempo de ejecución. Los programas que requieren mayor capacidad de cálculo obtienen menor prioridad y mayor tiempo de ejecución.

El Exec cuenta con dos mecanismos adicionales para optimizar la distribución de tareas. Uno de ellos es la distribución basada en afinidad. Siempre que sea posible, el Exec ejecutará una actividad en el mismo procesador que la última vez para aprovechar al máximo el contenido residual de la caché. Si esto no es posible, intenta mantener la actividad en el procesador más cercano en términos de tiempos de acceso a la caché y la memoria. El segundo mecanismo es una política de "equidad". El sistema puede definir el porcentaje relativo de recursos que se asignarán a cada una de las transacciones, la demanda y los lotes. Dentro de las transacciones y los lotes, existen agrupaciones de prioridad que pueden indicar qué porcentaje del tiempo de su grupo se asignará a la prioridad. Esto garantiza que las transacciones no dominen el sistema hasta el punto de impedir que se realicen las tareas por lotes. Dentro de las distintas agrupaciones de prioridad, se garantiza cierto 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 suelen funcionar con todos los procesadores casi al 100 % de su capacidad.

Medida

OS 2200 admite varios modelos para la gestión del rendimiento del sistema. ^{[ 15 ]} Los clientes pueden adquirir un nivel de rendimiento fijo determinado, y el Exec supervisará el uso del procesador para garantizar que el rendimiento no supere dicho nivel. Los clientes también pueden adquirir rendimiento adicional, ya sea de forma temporal o permanente, hasta alcanzar la capacidad máxima del sistema si su carga de trabajo aumenta o si surge una emergencia.

Más recientemente, el sistema ha incorporado la función de consumo medido. En este modo, el cliente dispone de toda la potencia del sistema (aunque puede limitarla administrativamente). El consumo se acumula durante un mes y, posteriormente, se envía a la facturación de Unisys. Según las condiciones específicas del contrato, el cliente puede recibir una factura por el consumo excesivo que supere el límite contratado para el mes o simplemente un extracto que indique que el consumo total contratado se ha reducido. La primera opción es similar a una factura de teléfono móvil, con la posibilidad de cobrar por los minutos adicionales. La segunda es similar a la compra de una tarjeta telefónica prepago.

OS 2200 no tiene un sistema de archivos jerárquico como la mayoría de los demás sistemas operativos. En cambio, utiliza una convención de nomenclatura estructurada y el concepto de archivos contenedores llamados archivos de programa.

En OS 2200, los archivos son simplemente contenedores que pueden direccionarse mediante el desplazamiento de palabras o el desplazamiento de sectores (unidades de 28 palabras). Las 28 palabras son una unidad histórica de un antiguo dispositivo de almacenamiento masivo (el tambor FASTRAND) que podía contener 64 de estas unidades por pista física. Sin embargo, se trata de una afortunada coincidencia histórica. Cuatro de estas unidades de 28 palabras, o 112 palabras, ocupan 504 bytes. Dado que los dispositivos de almacenamiento masivo actuales utilizan registros físicos de 512 bytes, los clientes de OS 2200 han adoptado casi todos un 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 504 a 512 bytes, añadiendo 8 bytes de ceros en las escrituras y eliminándolos en las lecturas de cada registro físico. OS 2200 gestiona las aplicaciones que utilizan tamaños distintos de los múltiplos de 112 palabras leyendo indivisiblemente los registros físicos que los contienen y reescribiendo las partes sin cambios y modificadas mediante encadenamiento de datos. Las funciones de bloqueo especiales garantizan la indivisibilidad incluso cuando se producen errores en los dispositivos 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 ]}

El concepto de subsistemas y subsistemas protegidos es fundamental para el diseño del sistema operativo 2200. Un subsistema es similar a una DLL en Windows. Se trata de código y datos que pueden ser compartidos 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 su lugar, el hardware y el sistema operativo proporcionan una "puerta" que puede ser el destino de una instrucción Call. Consulte la arquitectura del sistema de la serie Unisys 2200 para obtener más información.

Los gestores 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, generalmente compuestos de 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 puerta de enlace. Estos subsistemas se ejecutan en el entorno de protección del programa de usuario. Otros subsistemas, como los gestores de bases de datos, constan de código y datos o código privilegiado y solo pueden ser llamados mediante una puerta de enlace. Estos subsistemas también pueden tener listas de control de acceso asociadas para controlar quién puede llamarlos. Más importante aún, la puerta de enlace 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 quien realiza la llamada.

El funcionamiento del sistema operativo OS 2200 se basa 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 frecuentemente con información resumida sobre la actividad del sistema. ^{[ 28 ]}

El resto de la consola se utiliza como una pantalla desplazable de eventos. Cuando se emite un mensaje que requiere la respuesta del operador, se le asigna un número del 0 al 9 y permanece en la pantalla hasta que se recibe respuesta. Los mensajes de montaje de cinta se desplazan junto con los demás mensajes, pero se repiten cada dos minutos hasta que se monte la cinta.

Operations Sentinel se utiliza para todas las operaciones de OS 2200. ^{[ 29 ]} Las consolas de OS 2200 son simplemente ventanas dentro de una pantalla de Operations Sentinel. Puede haber tantas PC de visualización como se desee. El funcionamiento remoto es habitual. Operations Sentinel admite cualquier número de sistemas ClearPath, Windows, Linux y UNIX.

Se incluye una base de datos de mensajes de acción automática con el producto. ^{[ 30 ]} Esta base de datos permite a Operations Sentinel reconocer los mensajes. Se pueden escribir scripts para responder automáticamente a los mensajes que requieren una respuesta, ocultar los mensajes no deseados, traducirlos a otros idiomas, crear eventos, etc. Algunos clientes utilizan el modo de operación en sala oscura completa. Como máximo, tendrán pantallas de Operations Sentinel en ubicaciones remotas que supervisan el sistema y generan 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 para administrar el entorno de transacciones que permite instalar nuevos programas de transacciones, especifica toda la información necesaria sobre ellos, modifica la estructura de colas, las prioridades y los niveles de concurrencia, etc. ^{[ 31 ]}

Otras herramientas son específicas del responsable de seguridad y permiten la creación de usuarios, el cambio de privilegios permitidos, el cambio de la configuración de seguridad del sistema, etc. ^{[ 22 ] , [ 32 ] , [ 23 ]}

La mayoría de las herramientas cuentan con una interfaz gráfica, aunque algunas no. Todas ofrecen una interfaz de archivos almacenados por lotes, donde todas las acciones se especifican en el flujo de control. Esto permite automatizar cualquier interfaz administrativa, ya sea desde sitios locales (por ejemplo, según la hora del día u otros eventos) o desde sitios remotos. Se requieren privilegios únicos para cada área administrativa.