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:
-
El usuario teclea la transacción de consulta de licencias, por ejemplo, LICC.
-
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.
-
El usuario rellena los campos de esa pantalla y le da al intro.
-
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