- Este artículo cubre las instrucciones específicas sobre IBM System / 360 y las computadoras mainframe sucesoras . Para conocer el concepto general de una instrucción para realizar llamadas a un sistema operativo, consulte Llamada al sistema .
Una instrucción de llamada de supervisor ( SVC ) es una instrucción de hardware en la familia System / 360 de computadoras mainframe IBM hasta zSeries contemporáneas (así como computadoras mainframe que no son de IBM como Amdahl 470V / 5, 470V / 6, 470V / 7, 470V / 8, 580, 5880, 5990M y 5990A, y otros; Univac 90/60 , 90/70 y 90/80, y posiblemente otros; y Fujitsu M180 (UP) [1] y M200 (MP), y otros) utilizado para provocar una interrupción para solicitar un servicio del sistema operativo . La rutina del sistema que proporciona el servicio se denomina rutina SVC . SVC es una implementación específica de unllamada al sistema .
Razón fundamental
Los mainframes de IBM en las familias System / 360 y sucesoras operan en uno de dos estados: estado de problema o estado de supervisor y en una de las dieciséis claves de acceso al almacenamiento (0 a 15). En estado de problema , un programa de usuario dispone de un gran conjunto de instrucciones no privilegiadas de propósito general . En el estado de supervisor , los programas del sistema también pueden utilizar un pequeño conjunto de instrucciones privilegiadas que generalmente están destinadas a funciones de supervisión. Estas funciones pueden afectar a otros usuarios, otros procesadores o todo el sistema informático. En la clave de almacenamiento 0, un programa puede acceder a todo el almacenamiento direccionable [a] ; de lo contrario, se limita a las áreas de almacenamiento con una clave coincidente. Un programa solo puede acceder a funciones de supervisión específicas después de una verificación de autorización exhaustiva por parte del sistema operativo: DEBCHK (SVC 117), TESTAUTH (SVC 119) y posiblemente pruebas adicionales. Los programas que fallan en cualquiera de estas pruebas se ABENDE, se termina de forma anormal y se detiene inmediatamente el procesamiento. Algunas de estas pruebas no estaban disponibles en OS / 360, pero se agregaron en OS / VS1 , SVS o MVS / 370 , pero todas estaban disponibles en MVS / 370 o versiones posteriores, y todavía están disponibles hasta el día de hoy.
En OS / VS1 , OS / VS2 (SVS) , MVS / 370 y versiones posteriores del sistema operativo, la función MODESET (SVC 107) obvió la necesidad de muchos SVC escritos por el usuario, ya que este sistema SVC acomodó ambos cambios en el modo (estado del problema al estado de supervisor) y clave (8-15 [usuario] a 0-7 [sistema]) en una sola operación, y muchas SVC escritas por el usuario originalmente estaban pensadas para cambios simples de modo y clave, de todos modos, y posteriormente el único requisito especial era que el paso de trabajo estuviera autorizado por APF [b] [c] y que el programa que invocaba a MODESET residiera en una concatenación de bibliotecas, todas identificadas como autorizadas, y este enfoque seguro estaba completamente bajo el control de la instalación. Este enfoque generalmente simplificó los controles del usuario sobre la autorización, aunque se requirieron algunos cambios simples en la aplicación. En general, las instalaciones de los usuarios favorecieron este enfoque y, por lo tanto, la confiabilidad general del sistema mejoró significativamente.
Aunque las aplicaciones de mainframe suelen ser procesos sincrónicos , el sistema operativo en sí es naturalmente asincrónico , aunque el sistema también admite muchos procesos que son naturalmente sincrónicos . Cuando una aplicación solicita un servicio del sistema que es naturalmente asíncrono , como el procesamiento de entrada / salida, se debe emplear un mecanismo para sincronizar la aplicación y el sistema operativo. Este mecanismo esencial es a través de funciones que están integradas en el sistema operativo, o que son específicamente respaldadas por él, que incluyen: WAIT (detener temporalmente el procesamiento de la aplicación hasta que ocurra un evento externo); POST (indica la ocurrencia de un evento externo para que el procesamiento de la aplicación pueda continuar); y SYNCH (cambiar el modo de procesamiento del sistema — supervisor a usuario y clave del sistema a clave de usuario — mientras se preserva la integridad del sistema y se realiza de forma sincronizada una función en nombre de la aplicación, después de lo cual el procesamiento del supervisor puede continuar).
La siguiente tabla de SVC de OS / 360 indica las condiciones en las que se pueden emplear estas facilidades de sincronización.
Implementación
SVC es una instrucción de dos bytes con el código de operación hexadecimal 0A ; el segundo byte de la instrucción, el número SVC , indica la solicitud específica. [2] El número SVC puede ser cualquier valor de 0 a 255, y el número SVC particular depende del implementador del sistema operativo, por ejemplo, en MVS de IBM, SVC 3 se usa para terminar un programa, mientras que en UNIVAC VS / 9 y los sistemas operativos Fujitsu BS2000, SVC 9 se utilizó para el mismo propósito.
Cuando un programa emite un SVC, se produce una interrupción. El PSW, un registro privilegiado de 8 bytes (en el System 360 y S / 370) o 16 bytes (en el sistema z /) que contiene, entre otras cosas, la dirección actual de la instrucción a ejecutar, el bit de privilegio ( 1 si tiene privilegios) y la clave de almacenamiento se guarda en una ubicación absoluta. Estas son las ubicaciones 32-39 en 360 y 370; 320-335 en z / System. Luego, el PSW se carga desde una ubicación absoluta diferente; es 96-103 en el 360 y 370, 448-463 en el sistema z /. La ejecución se reanuda en la dirección que se cargó en el PSW. Los bits 24-31 del PSW guardado (dirección absoluta 35 en 360 y 370, 323 en z / System) contienen el número de llamada del supervisor.
SVC invoca una función de supervisión, generalmente implementada como una "subrutina cerrada" del manejador de interrupciones SVC del sistema . La información que se pasa hacia y desde las rutinas SVC se pasa en registros de propósito general o en la memoria.
En los sistemas operativos desarrollados por IBM, el retorno de una rutina SVC es, para las rutinas SVC de tipo 2, 3 y 4, a través de una invocación de SVC 3 (EXIT) y para otros tipos de SVC mediante la instrucción Load PSW (LPSW) privilegiada, y que se ejecuta en nombre de la rutina SVC por el despachador del programa de control o el manejador de interrupciones SVC.
En sistemas operativos no desarrollados por IBM como MUSIC / SP desarrollado por McGill University en Montreal, Canadá para mainframes IBM, y para mainframes que no son IBM, VS / 9 , desarrollado por Univac (del sistema operativo TSOS para la serie RCA Spectra 70 computadoras) para la línea de mainframe UNIVAC Serie 90 y el sistema operativo B800 (también desarrollado a partir del sistema operativo TSOS) para las mainfames de Fujitsu , todos usan la instrucción LPSW para salir de una llamada de supervisor.
La elección de si una llamada de supervisor regresa al programa de llamada directamente a través de una instrucción LPSW o por algún otro medio, como una instrucción de retorno de subrutina o una llamada de supervisor en sí, es una cuestión de diseño. No hay una forma "correcta" obvia de hacer esto; puede haber razones para ambos métodos. El uso de una instrucción LPSW para salir de una rutina SVC permite una ejecución más rápida, pero significa que la prueba real de la rutina debe realizarse en una máquina dedicada que ejecute el código como parte de un supervisor del sistema operativo real. Si el código se escribió como una subrutina ordinaria, puede probarse de la misma manera que cualquier programa ordinario y, potencialmente, implementarse sin tener que modificarlo. También permitiría medir métricas, en cuanto al tiempo que tarda una rutina de llamada de supervisor en completar su tarea, permitiendo el análisis de rutinas que son excesivamente largas en tiempo de ejecución (o muy rápidas).
En OS / 360 y versiones posteriores del sistema operativo, los puntos de entrada de rama y enlace son alternativas a las invocaciones de SVC para algunas rutinas de modo supervisor. En MVS / SP V1R3 y versiones posteriores del sistema operativo, las entradas de Llamada de programa (PC) tienen SVC aumentadas para invocaciones de muchas funciones de supervisión por parte de programas autorizados y no autorizados; y algunas funciones sólo pueden ser invocadas por entradas de rama o de PC, por ejemplo, Iniciar entrada / salida . (Esto también tiene la ventaja de evitar que los sistemas operativos de IBM se ejecuten en hardware que no sea de IBM).
Los diferentes sistemas operativos de IBM tienen poca compatibilidad en los códigos específicos utilizados o en los servicios de supervisor que pueden invocarse. Los sistemas VM / 370 yz / VM usan la instrucción DIAG de manera similar y dejan SVC para que lo utilicen los sistemas operativos que se ejecutan en máquinas virtuales. La mayoría de los SVC de OS / 360 se han mantenido para programas "heredados", pero algunos SVC se han "ampliado" con el paso del tiempo.
OS / 360 y SVC del sistema sucesor
En OS / 360 y sistemas sucesores, los números de SVC del 0 al 127 aproximadamente están definidos por IBM, y el personal de programación de sistemas de una instalación puede utilizar 255 hacia abajo. z / OS cambió esto a números SVC de 0 a aproximadamente 200 para IBM, y 255 hacia abajo para la instalación, ya que IBM estaba implementando servicios adicionales del sistema, principalmente en soporte de cifrado / descifrado, utilizando SVC. Las rutinas SVC deben tener nombres de módulo en un formato específico que comience con IGC.
Por diseño del sistema, el término "deshabilitado" significa deshabilitado para todas las interrupciones excepto para las interrupciones de verificación de la máquina en sistemas anteriores a MVS / 370, y con el "bloqueo local" retenido, pero no "deshabilitado" para cualquier interrupción en MVS / 370 y todos los sistemas posteriores. La primera es una desactivación física, la última es una desactivación lógica, ya que el "bloqueo local" de un espacio de direcciones tiene el mismo impacto dentro de su espacio de direcciones que la desactivación física, pero no tiene ningún impacto en otros espacios de direcciones.
OS / 360 definió cuatro tipos de rutinas SVC, llamadas "Tipo 1" a "Tipo 4"; MVS / 370 agregó un "Tipo 6" adicional, que es similar al "Tipo 1", excepto que la rutina SVC está físicamente deshabilitada. El "Tipo 5" no se definió ni se implementó. La siguiente información, que forma parte de una tabla para OS / 360, aumentada para MVS / 370 y sistemas sucesores, da una idea de las consideraciones involucradas en la escritura de una rutina SVC.
Convenciones | Tipo 1 / Tipo 6 | Tipo 2 | Tipo 3 | Tipo 4 |
---|---|---|---|---|
Parte del programa de control de residentes | sí | sí | No | No |
Tamaño de la rutina | Alguna | Alguna | Módulo de carga única ≤ 1024 bytes | Cada módulo de carga ≤ 1024 bytes |
Rutina reentrable | Opcional, pero debe ser reutilizable en serie | sí | sí | sí |
Puede permitir interrupciones | No | sí | sí | sí |
Registrar contenido en la entrada | Los registros [d] 3, 4, 5, 6, 7 y 14 contienen punteros de comunicación; los registros 0, 1 y 15 son registros de parámetros. | |||
Puede contener datos reubicables | sí | sí | No | No |
Puede pasar el control a qué otros tipos de rutinas de SVC | Ninguno | Alguna | ||
Puede emitir WAIT | No | Sí, usando "WAIT" (SVC 1) | ||
Puede emitir POST | Sí, pero debe utilizar la entrada de sucursal deshabilitada "Publicar" | Sí, usando "POST" (SVC 2) | ||
Puede programar salidas síncronas | Sí, pero debe usar la entrada de rama deshabilitada "Exit Effector" | Sí, usando "SYNCH" (SVC 12) | ||
Puede programar una terminación anormal | Sí, usando la entrada de sucursal deshabilitada "Abterm" | Sí, usando "ABEND" (SVC 13) |
Las restricciones de tamaño en las rutinas SVC de tipos 3 y 4 son necesarias porque se cargan en "áreas transitorias" designadas (PLPA en post-MVT) cuando se invocan.
- Un ejemplo de Tipo 1 es SVC 10, utilizado tanto para GETMAIN como para FREEMAIN, que asigna un área de almacenamiento principal a una tarea y luego la libera, respectivamente. SVC 10 se conoce informalmente como "REGMAIN", ya que intercambia parámetros a través de registros de propósito general, únicamente, y puede obtener almacenamiento tanto GET como FREE. SVC 4 y SVC 5 pueden realizar funciones GET y FREE similares, respectivamente, pero intercambian parámetros a través de listas de parámetros en almacenamiento.
- Un ejemplo de Tipo 2 es SVC 42, ATTACH, que crea una nueva tarea.
- Un ejemplo de Tipo 3 es SVC 33, IOHALT, que finaliza las operaciones de E / S en un dispositivo que no es DASD. Este SVC se cambió a Tipo 2 en OS / VS ya que IOHALT se utiliza mucho en muchos sistemas basados en teleprocesamiento.
- Un ejemplo de Tipo 4 es SVC 19, OPEN, que se utiliza para hacer que un conjunto de datos esté disponible para su uso por un programa de usuario, que incluye módulos comunes a todos los métodos de acceso y llama a módulos adicionales específicos para cada método de acceso . OPEN también admite conjuntos de datos en los que se utilizará un método de acceso "roll your own", como aquellos a los que se accede mediante EXCP .
- Un ejemplo de Tipo 6 es SVC 107, MODESET, que no obtiene bloqueos, pero puede cambiar el modo y la clave del sistema, de acuerdo con los parámetros pasados.
Seguridad
OS / 360, en general, no tenía ninguna forma de restringir el uso de SVC. En consecuencia, hubo bastantes exposiciones no intencionales de la integridad del sistema y de los datos que fueron posibles mediante el empleo de ciertas secuencias de SVC y otras instrucciones. Se convirtió en una práctica común para los usuarios curiosos intentar descubrir estas exposiciones, pero algunos programadores de sistemas utilizaron estas exposiciones en lugar de desarrollar sus propios SVC escritos por el usuario.
A partir de MVS / 370, IBM consideró un defecto del producto si un error de diseño del sistema permitía que un programa de aplicación entrara en estado supervisor sin autorización. Exigieron que todas las SVC de IBM estuvieran protegidas para cerrar todas las exposiciones de integridad de datos y sistemas. Ellos "garantizaron" cerrar las exposiciones a medida que se descubrieran. Para la versión 3.7 de MVS / 370 en 1977, casi todas las exposiciones de este tipo habían sido identificadas y cerradas, a costa de 100.000 informes de análisis de programas autorizados (APAR) y arreglos temporales de programas (PTF) relacionados. Este fue un logro notable, ya que el "tiempo de actividad" del sistema se midió a partir de entonces en años , en lugar de en días o incluso en horas .
Notas
- ^ Es decir, todo el almacenamiento en el espacio de direcciones accesible por la unidad de despacho actual.
- ^ Inicialmente, esto significaba que el programa jobstep estaba vinculado con AC (1) y provenía de una concatenación autorizada de bibliotecas. TSO / E luego agregó una función para los comandos TSO autorizados.
- ^ varias bibliotecas del sistema siempre fueron implícitamente parte de la concatenación
- ^ El uso del registro SVC en OS / 360 y MVS es
- Dirección CVT R3
- Dirección R4 TCB
- Dirección R5 RB
- Dirección del punto de entrada R6 (solo MVS)
- Dirección R7 ASCB (solo MVS)
- Dirección de retorno R14 CVTEXIR o SVC SLIH
Referencias
- ^ Guía del usuario de instrucciones de ensamblador V1.3, Fujitsu Solutions GmBH, https://bs2manuals.ts.fujitsu.com/download/manual/959.1 (PDF) junio de 2010, página 167 (consultado el 9 de noviembre de 2020)
- ^ Corporación IBM. IBM System / 360 Principios de funcionamiento (PDF) . pag. 72.
- ^ IBM Corporation (1967). IBM System / 360 Operating System System Programmer's Guide (PDF) .
Otras lecturas
- Cragon, Harvey G. (23 de agosto de 2000). Arquitectura e Implementación de Computadores . Prensa de la Universidad de Cambridge. ISBN 9780521651684 - a través de Google Books.
- Harris, J. Archer (21 de diciembre de 2001). Esquema de sistemas operativos de Schaum . Profesional de McGraw Hill. ISBN 9780071394482 - a través de Google Books.