Introducción al Sistema de control de información de clientes

  En una entrada anterior de la presente bitácora se ha hablado del Sistema de control de información de clientes o CICS, según sus siglas en inglés. En esta entrada se profundizará sobre este gestor transaccional de IBM.

  Como buen programa de este tipo, CICS procesa información descomponiéndola de forma unitaria en operaciones indivisibles, denominadas transacciones. Cada transacción debe finalizar de forma correcta o incorrecta como una unidad completa, es decir, no puede acabar en un estado intermedio.

  Al igual que otros programas de este tipo, CICS se ha diseñado para mantener bases de datos en un estado conocido y consistente, asegurando que todas las operaciones, que son interdependientes, realizadas sobre la base de datos se han completado correctamente o se han cancelado.

  De este modo, este gestor transaccional permite enlazar varias operaciones individuales automáticamente como una sola transacción indivisible. El gestor garantiza que todas las operaciones finalizan sin errores o ninguna de ellas. Si algunas operaciones finalizaron correctamente pero otras no, el gestor inicia el proceso de reversión (“rollback” en inglés) de todas las operaciones implicadas (incluso de aquellas que finalizaron correctamente), eliminando todo rastro de la transacción y devolviendo la base de datos a un estado consistente como lo estaba antes de empezar a procesar la transacción. Si todas las operaciones de la transacción finalizaron correctamente, la transacción confirma los cambios realizados en la base de datos. Una vez confirmados dichos cambios, los datos de esa transacción quedan consolidados y la transacción no puede hacer una reversión de los cambios.

  Los principios básicos de CICS son los mismos que los de cualquier gestor transaccional:

•   Reversión: Este gestor transaccional asegura la integridad de las bases de datos registrando todos los estados intermedios de una base de datos mientras se modifica. En caso de que la transacción falle, se usan esos registros para devolver la base de datos a un estado consistente. Por ejemplo, se copia información de la base de datos antes de que sea modificada por una transacción, de tal manera que si parte de la transacción acaba incorrectamente, se usan esas copias [llamadas imagen anterior (“before image”, en inglés)] para restablecer la integridad de los datos.
•   Progresión: También es posible mantener una copia [llamada imagen posterior (“after image”, en inglés)] de todas aquellas modificaciones realizadas sobre una base de datos; no es necesario para hacer una reversión de las transacciones que finalizaron incorrectamente, pero sí es útil para actualizar la base de datos en un escenario de una recuperación. Si la base de datos falla estrepitosamente, la restauración se debe iniciar desde la copia de seguridad más reciente, aunque no reflejará aquellos cambios posteriores a la copia. Sin embargo, una vez se ha restablecido la copia de seguridad se aplica la copia imagen posterior que contendrá todas las modificaciones entre la copia de seguridad y el fallo de la base de datos; desgraciadamente, esta copia también contiene todas aquellas modificaciones que estaban en vuelo en el momento del fallo; por ello, es necesario aplicar la copia imagen anterior que hará una reversión de las transacciones con un estado intermedio, devolviendo la base de datos a un estado seguro y consistente. Esto es conocido como progresión (“rollforward”, en inglés).
•   Bloqueos mutuos: En ocasiones, dos transacciones pueden en el transcurso de su ejecución, competir por dos recursos al mismo tiempo de tal manera que impide seguir con la misma. Un bloqueo mutuo, o interbloqueo (“deadlock”, en inglés), ocurre, por ejemplo, cuando la transacción A intenta acceder al área X de la base de datos mientras la transacción B intenta acceder al área Y de la base de datos. Si, en algún punto intermedio, la transacción A intenta acceder al área Y mientras al mismo tiempo la transacción B intenta acceder al área X se genera un bloqueo mutuo que impide a ambas transacciones progresar. CICS está diseñado para detectar este tipo de bloqueos cuando ocurren y actuar en concordancia. O bien ambas transacciones son canceladas y el sistema hace una reversión de todos los cambios para luego volver a ejecutarlas automáticamente en diferente orden de tal forma que no se vuelva a formar otro bloqueo mutuo, o bien cancelar y hacer la reversión de una de ellas y volverla a lanzar después de una pequeña espera.

PROCESOS POR LOTES Y EN LÍNEA

  Este gestor transaccional puede procesar transacciones por lotes o en línea.

  Los procesos transaccionales por lotes (“batch”, en inglés) son conjuntos de programas que tienen como entrada ficheros o consultas sobre la base de datos, generalmente voluminosos, y procesan los datos generando como salida listados para consultar el resultado de los procesos que son distribuidos posteriormente a cada departamento/oficina responsable de los mismos.

  Por su parte, los procesos transaccionales en línea (“on-line”, en inglés) permiten procesar programas muy cortos (procesan uno o unos pocos registros) y, por tanto, generan una respuesta casi inmediata hacia el terminal que ha solicitado su ejecución. Cuando CICS se encarga de este tipo de procesos, su función consiste en establecer la unión entre los terminales del usuario y la lógica de negocio; de este modo, cada una de las peticiones que se recibe desde un terminal, constituye una transacción, la cual crea una unidad de trabajo, o tarea, para el procesador central. Una transacción es cada una de las peticiones que realiza un usuario al anfitrión (“host”, en inglés), el cual ejecuta un programa para realizar el procesado de los datos y devuelve los resultados al terminal.

GESTIÓN BÁSICA

  Este programa puede gestionarse directamente desde cada uno de los CIC de los que está compuesto o bien desde otras aplicaciones de IBM {como el programa Omegamon o el Sistema de Visualización y Facilitación de Búsqueda ["System Display and Search Facility" ("SDSF"), en inglés] del z/OS, por ejemplo}.

Gestión directa

  Como se ha explicado en otra entrada de esta bitácora, para acceder directamente a la consola de un CIC se suele escribir “CIC<nº de cic><entorno>” (por ejemplo, “CIC55P”) en el campo "APLICACIÓN" de la pantalla de inicio del sistema operativo correspondiente (en los ejemplos se utilizará z/OS). Dentro de la consola (aparece, normalmente, en negro con un cursor parpadeante en blanco), se deberá escribir (en mayúsculas) el primer paso de la ruta de la transacción a la que se desea acceder (deberá aparecer el menú correspondiente) y pulsar el botón de función “Enter”.

  Al acabar de realizar las operaciones que hagan falta en esa transacción, se pulsará la tecla de función “3” o bien la opción del menú para salir de la misma, con lo que se volverá a la pantalla principal de la consola donde, esta vez, aparecerá un mensaje indicando que se ha salido de la misma sin problema alguno (si todo va bien, claro).

  Para salir definitivamente del CIC, se deberá escribir “CESF LOGOFF” (no hace falta borrar la indicación antes mencionada), con lo que se volverá a la pantalla de inicio del sistema operativo.

SDSF
  Si se emplea esta herramienta, se debe acudir al panel “DA” y emplear el filtro “PRE CIC*” en el “COMMAND INPUT”.

  Luego, se utilizará el comando adecuado de esta pantalla según lo que se quiera hacer (se deben tener los permisos adecuados) en la línea correspondiente al CIC a manipular (por ejemplo, se usa el comando S sobre un CIC para ver un registro de archivos del mismo).

  Para salir basta con hacerlo con la tecla de función “3” varias veces o una sola vez (se sale de la opción escogida con el comando) y cambiando de pantalla.

Omegamon

  Se entra en el programa escribiendo el comando OC<identificador de entorno del CIC> en “APLICACION” en la pantalla inicial.

  Cuando se accede al menú principal (normalmente de un CIC predeterminado), se escribe “CICS <nombre del CIC a entrar>” sobre la línea dibujada justo antes del nombre del menú.

 Luego, se escribe la opción del menú requerida del menú principal en la línea que se encuentra al lado de la cabecera de la pantalla (en el siguiente ejemplo, se usará la opción “H” para ver el historial de transacciones del CIC previamente seleccionado).

  Para salir del programa, se pulsa repetidamente la tecla de función “3”, o bien una vez dicha tecla y luego se añade “X” en la línea que se encuentra al lado de la cabecera de la pantalla dos veces; en ambos casos, se regresará a la pantalla de inicio del sistema operativo.

    Normalmente, los sistemas operativos donde funciona CICS poseen una ruta más directa para ver el registro de mensajes de sus CICs [ejemplo: en z/OS es la ruta “G > C”, donde se debe escribir el número de CIC en el primer dígito (predeterminadamente está “1”) y la partición de CIC en el segundo (o bien dejar la variable “%”, que ya aparece predeterminadamente)].

  Para salir sólo hay que darle a la tecla de función “3” hasta volver al menú principal del sistema operativo.

TRANSACCIONES RELEVANTES

  Normalmente, cuando se gestiona directamente un CIC, se suelen emplear las siguientes transacciones:

•   CESN: Esta transacción es la más básica de todas, ya que sirve para iniciar sesión en la consola y abrir una nueva sesión en CICS.
•   CESF: Sirve para desconectar la sesión que se tenga abierta en el CICS.
•   CEOT: Muestra una pantalla informativa en la que se puede ver cuál es el código de consola asociado a la sesión del usuario.
•   CECI: Permite acceder a todo el interfaz de programación de aplicaciones ["Application Programming Interfaces", ("API"), en inglés] del CICS. De esa manera, con ella es posible ejecutar cualquiera de los comandos existentes en este programa (por ejemplo, SEND, READ o RETURN).
•   CMAC: Permite visualizar una explicación detallada asociada a los mensajes y códigos de error CICS. Para ello, basta con introducir el código correspondiente.
•   CEDA: Sirve para definir la infraestructura de los recursos (programas, mapas, ficheros, colas, terminales o transacciones) que van a estar asociados a una aplicación en este gestor transaccional. Esta información queda almacenada en el fichero "CSD" ("CICS System Definition"). Adicionalmente, con CEDA también se puede realizar la instalación de los recursos, momento en el que la información de la infraestructura se enviará desde el fichero CSD hasta la memoria del CICS (esto es, al CICS Transaction Server).
•   CEMT (terminal maestro): Permite acceder a la información operativa de los recursos de la infraestructura. También sirve para ejecutar la función Newcopy sobre los objetos de una aplicación (programas en línea o mapas). Lo que hace dicha función es tomar la compilación de un objeto y enviarla a la memoria de este programa. De esta forma, el objeto quedará disponible de forma operativa para ser invocado por la transacción CIC que se desee asociar. Se debe tener en cuenta que, antes de hacer el Newcopy, previamente el objeto habrá tenido que ser instalado administrativamente mediante la transacción CEDA.
•   CEDF: Se trata de una herramienta de depuración. En el caso de que exista algún error en la ejecución de la transacción de una aplicación, con esta opción es posible realizar una depuración de la misma. Al lanzar la aplicación, CEDF realizará una simulación controlada de la ejecución, mostrando al usuario en todo momento el contenido de las variables activas y la parte del código CICS que se está ejecutando.
•   CEBR: Se emplea para visualizar el contenido de las Colas de almacenamiento temporal [“Temporary Storage” (“TS”), en inglés] y de las Colas de datos transitorios [“Transient Data” (“TD”), en inglés].
•   CMSG: Permite el envío de mensajes a través del CICS. Hay que especificar el código de terminal en el que se desee que se visualice el texto.

  Aguardo que la presente entrada haya sido interesante para el lector. Si es así, espero que éste la comente y/o la comparta, por favor.