CICS o Cómo Intentar Codificar Sabiamente

Autor: Kujaku | El jueves 10 de mayo del 2007 @ 19:42.

El presente articulo hará un repaso general sobre lo que es el CICS, actualmente el sistema transaccional mas extendido del planeta. El CICS (Customer Interface Control System) es un producto que corre bajo mainframe (z/Series) o mini (i/Series) y se usa sobre todo para el sistema conversacional entre el usuario y la máquina, dicho de otro modo, es el interfaz del usuario a los programas de aplicación codificados para un uso concreto.

A este respecto, el usuario teclea una transacción y el sistema le da un resultado por pantalla o ejecuta una acción determinada, que puede convertirse en una cadena de acciones hasta que se consigue el resultado. El típico ejemplo: "Consultar el estado de licencia de una Diosa". El usuario introduce el nombre de la transacción, y le sale una pantalla donde introduce el número de Diosa y al dar al Intro, le devuelve en pantalla el estado de su licencia, el tipo y si esta suspendida o no. O el sistema Amadeus de Reserva de Vuelos, es una infraestructura CICS como una casa. Fácil, ¿no?.

Ya, si, bueno, ¿pero cómo funciona esto?.

El CICS es básicamente un sistema donde residen una serie de transacciones de control del sistema y luego, transacciones de usuario. Todas las transacciones tienen un nombre de 4 caracteres que las identifica inequívocamente, de tal forma que por ejemplo, las que empiezan por una C, son transacciones de sistema (CEDA, CEMT, CESN, CEDF, etc).

Este sistema se ubica en la memoria del mainframe nada mas ejecutarse, y reserva una gran zona de memoria en función de la configuración que tenga, que se llama Región de CICS. Dentro de esta región, es donde residen las diversas tablas de configuración del CICS, entre ellas las tablas de transacciones, además de transacciones que están en vuelo o ejecutándose en este momento en forma de pequeños programas reutilizables.

Todas las transacciones tienen asociadas un programa inicial que será el que llame a otros programas o que a su vez, llame a otras transacciones. Este programa inicial suele estar escrito en COBOL por tradición, pero puede estar escrito en cualquier lenguaje como C, C++ o incluso JAVA.

Este programa realiza su función, pero tiene intercaladas varias instrucciones de la forma EXEC CICS Bleh, siendo Bleh un parámetro del API del CICS. Por ejemplo, EXEC CICS SEND MAP (MAPA02) lo que hace es enviar un mapa de pantalla llamado MAPA02 al CICS, que lo mostrará por el terminal donde ha sido llamada esa transacción.

Por otra parte, la eficiencia de programación de esos programitas es muy alta y se cuida hasta el ultimo detalle, ya que como son muy simples, se pueden optimizar muchísimo, al contrario que los mega-programas con cientos de funciones y procedimientos (eso no quita para que una transacción tenga asociado un programa de la pera, pero no suele ser lo habitual, ya que es mas fácil partir el programa en una o mas transacciones que luego se ejecutarán encadenadas que una única con un programa enorme, por evidentes motivos de rendimiento).

El funcionamiento es el siguiente: Cuando el usuario teclea la transacción, el CICS dedica su tiempo de CPU a atender ese usuario mientras la transacción esta en vuelo.

¿Cómo funciona el tema?

Pues el programa entre otras cosas, lo primero que hace es un EXEC CICS RECEIVE MAP con lo que captura las variables de la pantalla (o dicho de otro modo, los datos que el usuario ha tecleado). Con esos datos, el programa realiza la tarea que deba realizar y una vez obtenidos los resultados, el programa manda un EXEC CICS SEND MAP con la información que ha pedido, y en esos momentos puede decirse que la transacción está finalizada, momento en que el CICS empieza a hacer caso de mas transacciones que le pueden estar llegando desde otros terminales.

¿Programación en pseudo-qué?

El problema que surge es evidente: Si un usuario ha llamado a una transacción y ésta le muestra unos datos por el terminal para que los rellene y dé al intro para que se ejecute, y el usuario es lento o le da por ir a tomarse un café, ¿que? La transacción sigue corriendo y por tanto, el resto de la gente que quiera que su transacción se ejecute, se joderá y tendrá que esperar a que el gilipollas este de usuario deje de tocar los cojones y termine la transacción que empezó.

Para evitar que este tipo de usuarios gilipollas entorpezcan el trabajo a otros usuarios mas capacitados, se inventó el modo de programación PSEUDOCONVERSACIONAL. En este modo, la transacción solo está activa cuando tiene que calcular o mostrar algo, y luego le devuelve el control al CICS con un EXEC CICS RETURN. Desde un punto de vista práctico y muy resumido, y siguiendo el ejemplo de la consulta de la licencia:

  1. El usuario teclea la transacción de consulta de licencias, por ejemplo, LICC.

  2. CICS recibe la petición y lanza el programa inicial que está relacionado con esa transacción. Este programa hace un EXEC CICS SEND MAP con la pantalla y los campos a rellenar y seguidamente hace un EXEC CICS RETURN. Esto hace que el usuario tenga en la pantalla los campos a rellenar, pero el CICS está disponible para otros usuarios.

  3. El usuario rellena los campos de esa pantalla y le da al intro.

  4. En ese momento, el CICS detecta que la pantalla que había sido visualizada con la transacción LICC recibe una interrupción, por lo que activa el programa asociado y emite un EXEC CICS RECEIVE MAP. En este momento, el programa ya tiene los datos necesarios para trabajar, se conecta a la base de datos y recupera la fila y datos de la licencia de acuerdo al número de la Diosa, y una vez realizado todo el tema, el programa emite un EXEC CICS SEND MAP con la información solicitada y hace un EXEC CICS RETURN, antes de terminar el programa.

Vale, ¿pero para qué sirve todo esto?

La característica que ha hecho del CICS el mejor sistema, son 40 años de desarrollo en lo referente a la concurrencia. Además, sentó las bases del procesamiento distribuido. Imaginaos por un momento que se dispone de un repositorio de miles y miles de transacciones y programas. Yo puedo llamar a una transacción, y le meto unos datos, otro puede llamar a la misma transacción simultáneamente con unos datos iguales o diferentes a los míos, y si eso lo extrapolamos, un simple programilla que te puede hacer virguerías en una consulta o actualización de base de datos, puede ser ejecutado concurrentemente por mas de 10.000 usuarios, con unos consumos de CPU ridículos, y si se viera desbordado por el proceso de base de datos, el CICS mantiene un sistema de colas y bloqueos muy elaborado, haciendo caso a la vez a toda la gente.

Un ejemplo clarísimo son los miles y miles de cajeros que puede tener un banco repartido por todo el país, pues en la mayoría de los casos, detrás tiene un CICS que le da toda la información que solicita el cliente. Además, trata a las transacciones como una unidad, y si en algún momento el programa falla (bien porque no encuentra un tabla de base de datos, o hay un valor que no espera), el CICS se encarga de deshacer todo lo hecho hasta ahora, haciendo una serie de rollbacks automáticamente, siempre dejando el sistema en una situación coherente antes del procesamiento de esa transacción fallida.

Venga va, algo malo tiene que tener, ¿no?

Desgraciadamente, el CICS no ha evolucionado todo lo rápido que debiera en la inclusión de nuevas tecnologías y la actualización de las comunicaciones a TCP/IP se ha ido haciendo mediante parches y mas parches (CICS Transaction Gateway, CICSsockets, etc), por lo que otras tecnologías le han ido ganando terreno en este campo. Por si fuera poco, el CICS tiene una limitación: Solo se ejecuta en una CPU.

Si tuviéramos 32 procesadores, el CICS solo vería uno de los 32, por lo que el rendimiento sería sumamente bajo en comparación con el maquinón. Afortunadamente a este respecto, los desarrolladores de CICS idearon un sistema de CICSes concurrentes: Los TOR y los AOR.

Un TOR (Terminal Owning Region) es un CICS que solo recibe peticiones y el proceso lo deriva entre uno o mas AOR (Application Owning Region) que son CICSes que tratan las peticiones y cuyo resultado se lo devuelven al TOR. De este modo, podría tener un TOR y muchos AOR, de tal forma que, en conjunción con otras arquitecturas como Datasharing del DB2, balancearía el proceso entre todos esos CICSes, y como cada uno de ellos coge una CPU, podría tener muchos CICSes concurrentes en un entorno multiprocesador y mejorar el rendimiento de una manera asombrosa, haciendo caso a cientos de miles de usuarios concurrentes.

Iberdrola, por ejemplo, tiene una configuración de TOR y muchos AOR que le permiten hacer caso a varias decenas de miles de usuarios en todo el mundo, al igual que Kutxa o Caja Vital, aunque su configuración de TOR y AORs es más pequeña.

Sin mas, en la siguiente entrega explicaré como hacer una pequeña transacción que haga que nos muestre por pantalla "Hola, Mamon" y así podréis ver lo sencillo que es hacer un pequeño programa en COBOL y como crear una transacción asociada.

Comentarios