Generalidades del Sistema Operativo de Mainframe

El texto de hoy abordará de manera muy general de que piezas se constituye el Sistema Operativo de un host, y como se juntan para crear un sistema robustísimo. La razón de hacerlo de manera general es principalmente porque podría aburriros con cientos y cientos de páginas, y para eso, casi mejor os redirijo a documentos ya creados por IBM, como por ejemplo este pdf y así no me canso.

Comentar también que solo abordaré esto desde el punto de vista del Sistema Operativo z/OS, ya que mi desconocimiento en otros sistemas como z/VM o z/VSE me impide poder explicar estas otras alternativas igualmente válidas, pero menos extendidas.

El sistema z/OS (y otros SO como VSE o VM) dispone de un terminal muy especial llamado Master Console. Esta consola además de mostrar mensajes informativos, de advertencia o de error del desempeño del sistema, es un elemento vital para la administración de la máquina. Vital, porque esta consola tiene prioridad sobre los 15000 terminales a los que puede estar conectado, de manera que un comando introducido por ese terminal tiene siempre una respuesta inmediata a pesar de que la maquina este casi muerta por miles de personas.

Además, es la única con autoridad suficiente como para emitir mandatos de cerrar el sistema, arrancar un servicio, variar el estado de los dispositivos periféricos, etc. Es por ello que este terminal suele estar en una sala de operadores o sala de explotación accesible solo por tarjetas de seguridad y solo personal muy cualificado tiene acceso a esta consola. Fijaos además si es vital que tiene su Alternate Console, que se accede a ella desde otro camino redundante por si la Master Console pierde conexión en un momento dado.

Otra de las particularidades por las que este SO es como es y lo que ha diferenciado notablemente con respecto a otros SO, es gracias al Planificador o Master Scheduler. Es el primer elemento que se coloca en memoria, incluso antes que el propio kernel del SO. Esta pieza del complicado rompecabezas es la encargada de evitar que el SO deje de responder o se cuelgue, ya que el decide cuando hacer caso a un proceso que lleva demasiado tiempo en ejecución.

En un sistema Windows o GNU/Linux, puede llegar un momento que con demasiada carga, el equipo parece que se quede congelado. En un sistema z/OS, es casi imposible que un proceso monopolice a toda la maquina, independientemente de la carga. Es más, podrían estar 15.000 usuarios conectados trabajando, y que llegue un momento en el cual al pulsar Intro sobre tu emulación 3270, se te quede en X SYSTEM o X “relojito” durante un rato, pero al final, SIEMPRE te responde.

Y en caso de no hacerlo, desde la Master console se puede consultar la razón por la que la máquina va lenta, que recursos pueden estar ocasionando cuellos de botella y cambiar las prioridades de las aplicaciones que necesitan mas carga.

Uno de los grandes problemas de la informática actual es que a grandes cargas de trabajo aplicadas a una maquina, se hace muy complicado que la maquina siga adelante, hasta el punto de que un PC o una maquina media se termine colgando y no aceptando mas proceso, haciendo que la maquina se detenga.

Y una vez detenida, no hay vuelta atrás mas que dándole al boton reset. En el caso del Host, el Master Scheduler tiene como mision que todos los procesos progresen, y también toma decisiones de cambios de prioridad: Por poner un ejemplo sencillo, en el caso de que actives un proceso de máxima prioridad que haga que la maquina vaya mas lenta, el Master Scheduler examina el impacto que provocaría bajar la prioridad de ese proceso para que otros progresen, o examinaría el proceso en cuestión para elevar las prioridades de los servicios que utiliza en la medida que pueda –- milagros tampoco se pueden pedir -- para agilizar el trabajo de este proceso. Por lo tanto, y después de 40 años de evolución, lo que marca la diferencia en un SO de alta disponibilidad como el z/OS es este planificador.

Otro de los elementos que garantizan la robustez del SO es la altísima protección de memoria que tiene. Para todo proceso que se pretende ejecutar, el Master Sheduler reserva un Address Space o espacio de direcciones para dicho proceso. El Address space no es mas que una región de memoria que se crea para ese proceso en concreto y tiene sus tablas de índices, información de reserva de memoria, estado, zona común, de forma que una aplicación se aloja allí dentro sin molestar a nadie.

Esto hace que por ejemplo, si por casualidades del destino, esa aplicación dejara de responder, no ocurre como en otros sistemas, que la finalización anormal hace que el resto del sistema tiemble, sobre todo si esta aplicación ha realizado algún desbordamiento.

En el host, una finalización anormal de una aplicación no afecta en absoluto al resto de aplicaciones. Esto, como imaginareis, en los nuevos SO como Windows XP, 2003, etc, así como GNU/Linux, tampoco pasa con frecuencia, pero bueno, basta con saber que este concepto en host se lleva desde 1964 y ha evolucionado de una manera impresionante, haciendo un sistema de protección de memoria muy elaborado, hasta el punto de que si deliberadamente o inconscientemente cometo un error en el programa que haga desbordar la memoria, el SO es lo suficientemente inteligente para no permitir la ejecución de ese programa o que aborte todo el programa cuando llegue a ese punto que provoque que la integridad de memoria se ponga en entredicho.

Ya que hablamos de memoria, el SO tiene muchas zonas de memoria que se inicializan en tiempo de arranque: la PSA (Prefixed Storage Area, memoria reservada por la arquitectura), la CSA (Common Service Area), el núcleo del SO, varias tipos de LPA (Link Pack Area), etc. Esta última, por ejemplo, en tiempo de arranque del SO, se precarga con programas compilados que sabes que vas a usar frecuentemente, y así los tienes en memoria ya listos para usar, como si fueran una cache.

Tampoco quiero explicar la disposición de la memoria de manera profunda, ya que cada tipo de zona de memoria tiene un uso específico de cara al SO y meterse a explicar cada zona por separado haría que os aburriría hasta la saciedad.

Bien, hasta aquí he explicado digamos las piezas fundamentales del SO. Ahora, vamos a ver como trabajamos con ella.

Una vez que el SO esta cargado en memoria, el Master Scheduler dando caña y las áreas de memoria definidas e inicializadas, se procede a la carga de los subsistemas. Un subsistema es un programa o conjunto de programas que conforma una pieza del puzzle del SO.

Un subsistema fundamental es el JES2 (Job Entry Subsystem Versión 2). Este subsistema es un planificador de trabajos. Toda ejecución en el SO de un host es un trabajo de proceso por lotes o job batch. Existe un lenguaje llamado JCL (Job Control Language) que, al igual que un .bat de MS-DOS, codificas un job que realice una función determinada. Luego, este job lo submites (lo ejecutas, vamos) y entra en una cola de entrada del JES2 para su ejecución.

El JES2 se encarga de dar todo lo que pide ese job para su ejecución, lo ejecuta y luego el resultado de ese job lo deja en una cola de salida. A su vez, el JES2 también controla programas cargados en memoria en forma de tareas, que pueden ser inicializadas en tiempo de arranque del SO. A este tipo de tareas se les llama “Started Tasks” o STCs. Si somos un usuario conectado, seremos un TSU o Time Sharing User. Y si lanzamos un job batch, el proceso se llamara directamente JOB. En función de que tipo de proceso seamos, el JES2 nos tratara de diferente forma, pero una cosa es segura: si pretendemos hacer funcionar algo, es necesario que el JES2 este activo y nos acepte la petición.

Otro subsistema fundamental es el VTAM o Virtual Telecommunication Access Mode. Este subsistema da la capa de red necesaria para la comunicación inter-procesos, comunicación con el exterior, etc. Funciona utilizando el protocolo SNA, pero opciones del VTAM también soportan TCP/IP (al final, esta opción encapsula el trafico SNA dentro del TCP/IP).

El RACF (Resource Access Control Facility) es otro subsistema que da la capa de seguridad infranqueable del SO. Este módulo controla no solo los accesos de los usuarios y sus aplicaciones, sino también que otros programas puedan obtener recursos de otros programas o de ficheros que quiera utilizar.

El TSO es un subsistema que nos permite acceder a la maquina para trabajar con ella, es la pieza que falta para que con un terminal, pueda hacer login dentro de la maquina. Para ello, el VTAM me proporciona el acceso desde el exterior con ese terminal y luego, en las definiciones de TSO, puedo hacer que ese terminal este autorizado para que yo pueda tener acceso al host. RACF se encargara de validar mi usuario y contraseña y vera en sus listas de control de acceso (ACL's) si yo tengo la autoridad suficiente para poder utilizar el TSO.

Hay mas módulos que conforman el rompecabezas del SO, pero estos son los mas importantes. Por ultimo, explicaré brevemente los programas producto mas utilizados:

• DB2: Sin duda, la Base de datos mas robusta del mundo mundial. Hoy en día, casi todos los datos que puede almacenar un host, están dentro de una tabla de DB2. Esta BD también tiene multitud de herramientas que son accesibles desde TSO, como QMF para administrar consultas SQL, SPUFI (SQL Processing Using File Input) para desarrollar querys desde TSO, o desde ficheros, etc. Se arranca como una STC dentro del JES2.

• CICS: Customer Interface Control System. Es un sistema transaccional que, en conjunción con DB2, permite desarrollar transacciones y luego poder ejecutarlas desde terminal (por ejemplo, la típica transacción de consultar saldo de una cuenta corriente). También se arranca como una STC dentro del JES2. O por ejemplo, si alguna vez habéis ido a una agencia de viajes a reservar un avión, la pantalla de la agencia trabaja contra una aplicación bajo CICS que se llama Amadeus.

• IMS: Otro transaccional como el CICS pero que se desarrollo años antes. En mi experiencia, solo conozco una instalación que lo tiene. El resto, son todas de CICS.

Buff, vaya tocho. Creo que por hoy es suficiente, ¿no? Si alguno quiere mas información detallada sobre algún producto en particular, que me lo diga y gustoso lo explicare (si es que sé, ya que lo que más he tocado ha sido CICS y tampoco soy un gurú ;) ).