Publicado el Jueves 10 de Mayo del 2007 @ 19:42 por Kujaku.
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?
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.
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.
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:
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.
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.
Esto es un tocho infumable, pero hace mucho que no comento y necesito visitas para ganar Yenes nipones así que aquí dejo mi tremenda aportación a la entrada (no es necesario dar las gracias).
PD: ¿Hola, mamón? ¿Qué fué del mítico “Hola, Mundo!”? XD
Pues esta explicado de una forma bastante amena la verdad.
Sencillo, directo y clarificador. como el propio CICS.
Yo lo he leido por que al principio has mencionado “amadeus” ese programita que casi nunca funciona o no pueden entrar los de las agencias de viajes, y tenía mi curiosidad por ello.
Bien clara la explicación.
CICS es bueno para poder llevar los sistemas hechos en leguajes prehistoricos como COBOL o PL/1 a un ambiente SOA & Web Services. Permite no tener que botar tu legacy y utilizarlo para realizar las transacciones que siempre haces pero con un mejor rendimiento.
Excelente aporte, una forma amigable de compartir conocimiento sin dejar de lado la simplicidad.
Seria interesante que ampliaras el tema a la operatoria del CICS para iniciar las transacciones, basadas en sus propias transacciones de arquitectura y secuencia de ejecución para cumplir con una transaccion que no sea de la arquitectura CICS.
Gracias y felicitaciones
Muy buenas noches,
Estoy estudiando sobre CICS, tu articulo es muy interesante y apropiado, sin embargo el acronico de CICS es:
tomado de Wikipedia:
CICS, acrónimo en inglés de Customer Information Control System (en español, Sistema de control de información de clientes). y revisado en los manuales de IBM
Busco un manual de cobol cics db2 en castellano que permita a alguien que ya sabe Cobol (normal que vale para pc y para AS400) aprender reposicionamientos, on-line..etc etc etc…..
Existe?
Tambien busco unna emulacion que funcione en el PC para estudiar… En MIcrofocus existe pero es cara y al que te dejan bajar esta tan capada que no sierve para nada….
Si algun alma generosa sabe algo de esto mi correo es jfgmag@hotmail.com
Gracias
Es sorprendente como al programar en COBOL , se abre un mundo de conocimientos deseo saber de CICS, DB2, JCL. si me puden ayudar agradeceria bastante
Deseo informacion de CICS, DB2, JCL, favor de enviar a mi correo rhneciosup@hotmail.com
Ha pasado tanto tiempo q actualmente el CICS ya tiene todas las facilidades Web Services, quedando cada vez menos desventajas
MUY MUY BIENEXPLICADO.
Algún sitio donde encontrar un manualito en castellano??
Saludos,.