IBM CICS (Customer Information Control System) es una familia de servidores de aplicaciones de lenguaje mixto que brindan gestión de transacciones en línea y conectividad para aplicaciones en sistemas mainframe IBM bajo z/OS y z/VSE .
Los productos de la familia CICS están diseñados como middleware y admiten el procesamiento rápido de transacciones en línea de gran volumen . Una transacción CICS es una unidad de procesamiento iniciada por una única solicitud que puede afectar a uno o más objetos. [2] Este procesamiento suele ser interactivo (orientado a la pantalla), pero son posibles las transacciones en segundo plano.
El servidor de transacciones CICS (CICS TS) se encuentra a la cabeza de la familia CICS y proporciona servicios que amplían o reemplazan las funciones del sistema operativo. Estos servicios pueden ser más eficientes que los servicios generalizados del sistema operativo y también más sencillos de utilizar para los programadores, en particular en lo que respecta a la comunicación con diversos dispositivos terminales.
Las aplicaciones desarrolladas para CICS pueden escribirse en una variedad de lenguajes de programación y utilizar extensiones de lenguaje proporcionadas por CICS para interactuar con recursos como archivos, conexiones de bases de datos , terminales o para invocar funciones como servicios web. CICS administra toda la transacción de modo que si por alguna razón una parte de la transacción falla, se pueden revertir todos los cambios recuperables.
Si bien CICS TS tiene su perfil más alto entre las grandes instituciones financieras, como bancos y compañías de seguros, se informa que muchas empresas de Fortune 500 y entidades gubernamentales utilizan CICS. Otras empresas más pequeñas también pueden utilizar CICS TS y otros productos de la familia CICS. CICS se puede encontrar regularmente detrás de escena en, por ejemplo, aplicaciones de cajeros automáticos , sistemas de control de producción industrial, aplicaciones de seguros y muchos otros tipos de aplicaciones interactivas.
Las mejoras recientes de CICS TS incluyen nuevas capacidades para mejorar la experiencia del desarrollador, incluida la elección de API, marcos, editores y herramientas de compilación, al mismo tiempo que se proporcionan actualizaciones en las áreas clave de seguridad, resiliencia y administración. En versiones anteriores y recientes de CICS TS, se brindó soporte para servicios web y Java , procesamiento de eventos , feeds Atom e interfaces RESTful .
El CICS fue precedido por un sistema de procesamiento de transacciones de un solo subproceso, IBM MTCS . Posteriormente se desarrolló un "puente MTCS-CICS" para permitir que estas transacciones se ejecutaran bajo CICS sin cambios en los programas de aplicación originales. El Sistema de control de información del cliente (CICS) de IBM, desarrollado por primera vez en conjunto con Michigan Bell en 1966. [3] Ben Riggins era ingeniero de sistemas de IBM en Virginia Electric Power Co. cuando se le ocurrió la idea del sistema en línea. [4]
CICS se desarrolló originalmente en los Estados Unidos en el Centro de Desarrollo de IBM en Des Plaines, Illinois , a partir de 1966 para abordar los requisitos de la industria de servicios públicos. El primer producto CICS se anunció en 1968, llamado Sistema de Control de Información de Clientes de Servicios Públicos o PU-CICS. Se hizo evidente de inmediato que tenía aplicabilidad a muchas otras industrias, por lo que el prefijo de Servicios Públicos se eliminó con la introducción de la primera versión del Producto de Programa CICS el 8 de julio de 1969, poco después del sistema de gestión de bases de datos IMS .
Durante los años siguientes, CICS se desarrolló en Palo Alto y se consideró un producto "más pequeño" y menos importante que IMS, que IBM consideraba más estratégico. Sin embargo, la presión de los clientes lo mantuvo con vida. Cuando IBM decidió finalizar el desarrollo de CICS en 1974 para concentrarse en IMS, la responsabilidad del desarrollo de CICS recayó en la planta de IBM Hursley en el Reino Unido, que acababa de dejar de trabajar en el compilador PL/I y, por lo tanto, conocía a muchos de los mismos clientes que CICS. El núcleo del trabajo de desarrollo continúa en Hursley hoy en día junto con las contribuciones de laboratorios en India, China, Rusia, Australia y los Estados Unidos.
En un principio, CICS solo admitía algunos dispositivos de la marca IBM, como el terminal basado en máquina de escribir IBM 2741 Selectric (pelota de golf) de 1965. Posteriormente, se utilizaron ampliamente los terminales de visualización de vídeo IBM 2260 de 1964 y IBM 3270 de 1972 .
En los primeros tiempos de los mainframes de IBM, el software informático era gratuito, se incluía sin coste adicional con el hardware informático . El sistema operativo OS/360 y el software de soporte de aplicaciones como CICS estaban "abiertos" a los clientes de IBM mucho antes de la iniciativa del software de código abierto . Corporaciones como Standard Oil of Indiana (Amoco) hicieron importantes contribuciones a CICS.
El equipo de IBM Des Plaines intentó añadir soporte para terminales populares que no eran de IBM, como el ASCII Teletype Model 33 ASR, pero el pequeño equipo de desarrollo de software de bajo presupuesto no podía permitirse el hardware de 100 dólares al mes para probarlo. Los ejecutivos de IBM creyeron incorrectamente que el futuro sería como el pasado, con procesamiento por lotes utilizando tarjetas perforadas tradicionales .
IBM proporcionó a regañadientes sólo una financiación mínima cuando las empresas de servicios públicos, los bancos y las compañías de tarjetas de crédito exigieron un sistema interactivo rentable (similar al Programa de Control de Líneas Aéreas de IBM de 1965 utilizado por el sistema de reservas por ordenador Sabre de American Airlines ) para el acceso a datos de alta velocidad y la actualización de la información de los clientes para sus operadores telefónicos (sin esperar a que los sistemas de tarjetas perforadas procesaran por lotes durante la noche).
Cuando se entregó CICS a Amoco con soporte para Teletype Model 33 ASR, provocó que todo el sistema operativo OS/360 fallara (incluidos los programas de aplicación que no eran CICS). La mayor parte del Programa de Control de Terminal CICS (TCP, el corazón de CICS) y parte de OS/360 tuvieron que ser rediseñados y reescritos laboriosamente por Amoco Production Company en Tulsa, Oklahoma. Luego se devolvió a IBM para su distribución gratuita a otros.
En pocos años, [¿ cuándo? ] CICS generó más de 60 mil millones de dólares en ingresos por hardware nuevo para IBM y se convirtió en su producto de software de mainframe más exitoso.
En 1972, CICS estaba disponible en tres versiones: DOS-ENTRY (número de programa 5736-XX6) para máquinas DOS/360 con memoria muy limitada, DOS-STANDARD (número de programa 5736-XX7), para máquinas DOS/360 con más memoria, y OS-STANDARD V2 (número de programa 5734-XX7) para las máquinas más grandes que ejecutaban OS/360. [5]
A principios de 1970, varios de los desarrolladores originales, incluido Ben Riggins (el arquitecto principal de los primeros lanzamientos) se trasladaron a California y continuaron el desarrollo de CICS en el Centro de Desarrollo de IBM en Palo Alto . Los ejecutivos de IBM no reconocieron el valor del software como un producto generador de ingresos hasta después de que la ley federal exigiera la desagregación del software . En 1980, los ejecutivos de IBM no hicieron caso de las fuertes sugerencias de Ben Riggins de que IBM debería proporcionar su propio sistema operativo basado en EBCDIC y chip de microprocesador de circuito integrado para su uso en la computadora personal IBM como terminal inteligente CICS (en lugar del chip Intel incompatible y el inmaduro DOS Microsoft 1980 basado en ASCII ).
Debido a la capacidad limitada de los procesadores de gran tamaño de esa época, cada instalación de CICS debía ensamblar el código fuente de todos los módulos del sistema CICS después de completar un proceso similar a la generación del sistema (sysgen), llamado CICSGEN , para establecer valores para las instrucciones condicionales en lenguaje ensamblador. Este proceso permitía a cada cliente excluir la compatibilidad del propio CICS para cualquier característica que no tuviera intención de utilizar, como la compatibilidad de dispositivos para tipos de terminales que no se utilizaban.
CICS debe su popularidad inicial a su implementación relativamente eficiente cuando el hardware era muy caro, su arquitectura de procesamiento multiproceso, su relativa simplicidad para desarrollar aplicaciones de transacciones en tiempo real basadas en terminales y muchas contribuciones de clientes de código abierto, incluidas tanto la depuración como la mejora de funciones.
Parte del CICS se formalizó utilizando la notación Z en los años 1980 y 1990 en colaboración con el Laboratorio de Computación de la Universidad de Oxford , bajo la dirección de Tony Hoare . Este trabajo ganó un Premio de la Reina por Logros Tecnológicos. [6]
En 1986, IBM anunció el soporte de CICS para los servicios de archivos orientados a registros definidos por la Arquitectura de Gestión de Datos Distribuidos (DDM). Esto permitió que los programas en computadoras remotas conectadas a la red crearan, administraran y accedieran a archivos que antes solo estaban disponibles dentro de los entornos de procesamiento de transacciones CICS/MVS y CICS/VSE. [7]
En las versiones más nuevas de CICS, se ha eliminado la compatibilidad con DDM. La compatibilidad con el componente DDM de CICS z/OS se interrumpió a finales de 2003 y se eliminó de CICS para z/OS a partir de la versión 5.2. [8] En CICS TS para z/VSE, la compatibilidad con DDM se estabilizó en el nivel V1.1.1, con la intención anunciada de discontinuarla en una versión futura. [9] A partir de CICS para z/VSE 2.1, CICS/DDM ya no es compatible. [10]
CICS Transaction Server introdujo por primera vez una interfaz HTTP nativa en la versión 1.2, junto con una tecnología Web Bridge para envolver programas basados en terminales de pantalla verde con una fachada HTML. Las API de documentos y web de CICS se mejoraron en CICS TS V1.3 para permitir que se escribieran aplicaciones compatibles con la web para interactuar de manera más eficaz con los navegadores web.
Las versiones 2.1 a 2.3 de CICS TS se centraron en la introducción de tecnologías CORBA y EJB en CICS, ofreciendo nuevas formas de integrar activos de CICS en modelos de componentes de aplicaciones distribuidas. Estas tecnologías dependían del alojamiento de aplicaciones Java en CICS. El entorno de alojamiento Java experimentó numerosas mejoras en muchas versiones. Durante la versión 4.1 de CICS TS se introdujo un recurso JVM multiproceso llamado JVMSERVER, que se mejoró aún más para utilizar la tecnología JVM de 64 bits en la versión 5.1. La versión 5.1 también vio la introducción del contenedor web de perfil WebSphere Liberty. Finalmente, WebSphere Liberty se integró completamente en CICS Transaction Server en la versión 5.3. Se podían alojar numerosas tecnologías web en CICS utilizando Java, lo que finalmente dio como resultado la eliminación de las tecnologías nativas CORBA y EJB.
CICS TS V3.1 agregó una implementación nativa de las tecnologías SOAP y WSDL para CICS, junto con API HTTP del lado del cliente para comunicación saliente. Estas tecnologías gemelas permitieron una integración más sencilla de los componentes de CICS con otras aplicaciones empresariales y tuvieron una adopción generalizada. Se incluyeron herramientas para tomar programas CICS tradicionales escritos en lenguajes como COBOL y convertirlos en servicios web definidos por WSDL, con pocos o ningún cambio en el programa. Esta tecnología experimentó mejoras periódicas en las sucesivas versiones de CICS.
CICS TS V4.1 y V4.2 incorporaron mejoras adicionales en la conectividad web, incluida una implementación nativa del protocolo de publicación Atom .
Muchas de las tecnologías web más nuevas se pusieron a disposición para versiones anteriores de CICS mediante modelos de entrega distintos a los de una versión de producto tradicional. Esto permitió a los primeros usuarios proporcionar comentarios constructivos que podrían influir en el diseño final de la tecnología integrada. Algunos ejemplos incluyen la versión preliminar de la tecnología Soap para CICS SupportPac para TS V2.2 o ATOM SupportPac para TS V3.1. Este enfoque se utilizó para introducir la compatibilidad con JSON para CICS TS V4.2, una tecnología que luego se integró en CICS TS V5.2.
La tecnología JSON en CICS es similar a la tecnología SOAP anterior , que permitía que los programas alojados en CICS se envolvieran con una fachada moderna. La tecnología JSON, a su vez, se mejoró en z/OS Connect Enterprise Edition, un producto de IBM para componer API JSON que pueden aprovechar los activos de varios subsistemas de mainframe.
También se han utilizado muchos productos asociados para interactuar con CICS. Algunos ejemplos populares incluyen el uso de CICS Transaction Gateway para conectarse a CICS desde servidores de aplicaciones Java compatibles con JCA y dispositivos IBM DataPower para filtrar el tráfico web antes de que llegue a CICS.
Las versiones modernas de CICS ofrecen muchas maneras de integrar activos de software nuevos y existentes en flujos de aplicaciones distribuidas. Se puede acceder a los activos de CICS desde sistemas remotos y se puede acceder a ellos; se puede propagar la identidad del usuario y el contexto transaccional; se pueden crear y gestionar API RESTful; los dispositivos, usuarios y servidores pueden interactuar con CICS utilizando tecnologías basadas en estándares; y el entorno IBM WebSphere Liberty en CICS promueve la rápida adopción de nuevas tecnologías.
En enero de 1985, una empresa consultora fundada en 1969, que había realizado "sistemas masivos en línea" para Hilton Hotels, FTD Florists, Amtrak y Budget Rent-a-Car, anunció lo que se convirtió en MicroCICS . [11] El enfoque inicial fue el IBM XT/370 y el IBM AT/370 . [12]
Aunque cuando se menciona CICS la gente generalmente se refiere a CICS Transaction Server, la familia CICS se refiere a una cartera de servidores de transacciones, conectores (llamados CICS Transaction Gateway ) y herramientas CICS.
CICS en plataformas distribuidas (no mainframes) se denomina IBM TXSeries . TXSeries es un middleware de procesamiento de transacciones distribuidas. Admite aplicaciones C, C++, COBOL, Java™ y PL/I en entornos de nube y centros de datos tradicionales. TXSeries está disponible en plataformas AIX , Linux x86, Windows , Solaris y HP-UX . [13] CICS también está disponible en otros sistemas operativos, en particular IBM i y OS/2 . La implementación z/OS (es decir, CICS Transaction Server para z/OS) es, con diferencia, la más popular y significativa.
Anteriormente, había dos versiones de CICS disponibles para VM/CMS , pero ambas se han discontinuado desde entonces. En 1986, IBM lanzó CICS/CMS , [14] [11] que era una versión de CICS para un solo usuario diseñada para uso en desarrollo, y las aplicaciones se transfirieron más tarde a un sistema MVS o DOS/VS para su ejecución en producción. [15] [16] Más tarde, en 1988, IBM lanzó CICS/VM . [17] [18] CICS/VM estaba destinado a usarse en IBM 9370 , un mainframe de gama baja destinado al uso departamental; IBM posicionó CICS/VM ejecutándose en mainframes departamentales o de sucursales para su uso junto con un mainframe central que ejecutara CICS para MVS. [19]
El aprovisionamiento, la gestión y el análisis de los sistemas y aplicaciones de CICS se realizan mediante las herramientas de CICS. Esto incluye la gestión del rendimiento, así como la implementación y la gestión de los recursos de CICS. En 2015, las cuatro herramientas básicas de CICS (y el paquete de soluciones de optimización de CICS para z/OS) se actualizaron con el lanzamiento de CICS Transaction Server para z/OS 5.3. Las cuatro herramientas básicas de CICS: CICS Interdependency Analyzer para z/OS, CICS Deployment Assistant para z/OS, CICS Performance Analyzer para z/OS y CICS Configuration Manager para z/OS.
CICS Transaction Server para z/OS ha utilizado los siguientes números de versión:
Se requería que los programas de aplicaciones de transacciones interactivas para múltiples usuarios fueran cuasi- reentrantes para poder soportar múltiples hilos de transacciones concurrentes . Un error de codificación de software en una aplicación podía bloquear a todos los usuarios del sistema. El diseño modular de los programas de control reentrantes/reutilizables de CICS significaba que, con una "poda" juiciosa, se podían ejecutar múltiples usuarios con múltiples aplicaciones en una computadora con solo 32K de costosa memoria física de núcleo magnético (incluido el sistema operativo ).
Los programadores de aplicaciones CICS tuvieron que hacer un esfuerzo considerable para que sus transacciones fueran lo más eficientes posible. Una técnica común era limitar el tamaño de los programas individuales a no más de 4096 bytes, o 4K, de modo que CICS pudiera reutilizar fácilmente la memoria ocupada por cualquier programa que no estuviera en uso para otro programa u otras necesidades de almacenamiento de la aplicación. Cuando se agregó memoria virtual a las versiones OS/360 en 1972, la estrategia de 4K se volvió aún más importante para reducir la sobrecarga improductiva de paginación y procesamiento de recursos.
La eficiencia de los programas compilados de alto nivel en lenguaje COBOL y PL/I dejaba mucho que desear. Muchos programas de aplicación CICS siguieron escribiéndose en lenguaje ensamblador, incluso después de que estuviera disponible el soporte para COBOL y PL/I.
En los años 1960 y 1970, los recursos de hardware eran caros y escasos, por lo que se desarrolló un "juego" competitivo entre los analistas de optimización de sistemas. Cuando se identificaba el código de la ruta crítica , se pasaba un fragmento de código de un analista a otro. Cada persona tenía que (a) reducir la cantidad de bytes de código necesarios o (b) reducir la cantidad de ciclos de CPU necesarios. Los analistas más jóvenes aprendían de lo que hacían sus mentores con más experiencia. Finalmente, cuando nadie podía hacer (a) o (b), el código se consideraba optimizado y pasaban a otros fragmentos. Las pequeñas empresas con un solo analista aprendieron la optimización de CICS muy lentamente (o no aprendieron nada).
Debido a que los programas de aplicación podían ser compartidos por muchos subprocesos simultáneos , el uso de variables estáticas integradas dentro de un programa (o el uso de la memoria del sistema operativo) estaba restringido (solo por convención).
Lamentablemente, muchas de las "reglas" se rompían con frecuencia, especialmente por parte de programadores de COBOL que no entendían los aspectos internos de sus programas o no usaban las opciones restrictivas necesarias en tiempo de compilación . Esto daba como resultado un código "no reentrante" que a menudo no era confiable, lo que provocaba violaciones de almacenamiento espurias y fallas completas del sistema CICS.
Originalmente, toda la partición , o región de almacenamiento virtual múltiple (MVS), funcionaba con la misma clave de protección de memoria , incluido el código del núcleo de CICS. La corrupción del programa y la corrupción del bloque de control de CICS eran una causa frecuente de tiempo de inactividad del sistema. Un error de software en un programa de aplicación podía sobrescribir la memoria (código o datos) de una o todas las transacciones de la aplicación que se estaban ejecutando en ese momento. Localizar el código de la aplicación que causaba errores de sincronización transitorios complejos podía ser un problema muy difícil para el analista del sistema operativo.
Estas deficiencias persistieron en múltiples versiones nuevas de CICS durante un período de más de 20 años, a pesar de su gravedad y del hecho de que las habilidades de CICS de alta calidad tenían una gran demanda y eran escasas. Se abordaron en TS V3.3, V4.1 y V5.2 con las funciones de protección de almacenamiento, aislamiento de transacciones y subespacio respectivamente, que utilizan características de hardware del sistema operativo para proteger el código de la aplicación y los datos dentro del mismo espacio de direcciones, aunque las aplicaciones no se escribieron para estar separadas. Las transacciones de aplicaciones CICS siguen siendo fundamentales para muchas empresas de servicios públicos, grandes bancos y otras instituciones financieras multimillonarias.
Además, es posible proporcionar una medida de protección avanzada de la aplicación realizando pruebas bajo el control de un programa de monitoreo que también sirve para proporcionar funciones de prueba y depuración.
Cuando se lanzó por primera vez CICS, solo admitía programas de transacciones de aplicaciones escritos en ensamblador IBM 360. Años después se agregó compatibilidad con COBOL y PL/I . Debido a la orientación inicial del ensamblador, las solicitudes de servicios CICS se realizaban mediante macros de lenguaje ensamblador . Por ejemplo, la solicitud para leer un registro de un archivo realizada mediante una llamada de macro al "Programa de control de archivos" de CICS podría verse así:
DFHFC TIPO=LECTURA, CONJUNTO DE DATOS=miarchivo, TIPOPER=ACTUALIZACIÓN,....etc.
Esto dio lugar a la terminología posterior " CICS de nivel macro ".
Cuando se agregó soporte para lenguajes de alto nivel, se conservaron las macros y el código fue convertido por un precompilador que expandió las macros a sus equivalentes de instrucción CALL de COBOL o PL/I. Por lo tanto, preparar una aplicación HLL fue efectivamente una compilación de "dos etapas" : la salida del preprocesador se ingresó al compilador HLL como entrada.
Consideraciones sobre COBOL : a diferencia de PL/I, IBM COBOL normalmente no permite la manipulación de punteros (direcciones). Para permitir que los programadores COBOL accedan a los bloques de control y al almacenamiento dinámico de CICS, los diseñadores recurrieron a lo que era esencialmente un truco. La sección de enlace de COBOL se utilizaba normalmente para la comunicación entre programas, como el paso de parámetros. El compilador genera una lista de direcciones, cada una llamada localizador base para el enlace (BLL), que se configuraban al entrar en el programa llamado. El primer BLL corresponde al primer elemento de la sección de enlace y así sucesivamente. CICS permite al programador acceder a estos y manipularlos pasando la dirección de la lista como primer argumento al programa. Los BLL se pueden configurar dinámicamente, ya sea por CICS o por la aplicación, para permitir el acceso a la estructura correspondiente en la sección de enlace. [36]
Durante la década de 1980, IBM en Hursley Park produjo una versión de CICS que admitía lo que se conoció como "CICS de nivel de comando", que aún admitía los programas más antiguos pero introducía un nuevo estilo de API para los programas de aplicación.
Una llamada típica a nivel de comando podría verse así:
EJECUTAR CICS ENVIAR MAPSET ( 'LOSMATT' ) MAP ( 'LOSATT' ) FINALIZAR EJECUCIÓN Los valores dados en el comando SEND MAPSET corresponden a los nombres utilizados en la primera macro DFHMSD en la definición de mapa que se proporciona a continuación para el argumento MAPSET y la macro DFHMSI para el argumento MAP. Esto se procesa previamente mediante una etapa de traducción por lotes de precompilación, que convierte los comandos integrados (EXEC) en instrucciones de llamada a una subrutina de código auxiliar. Por lo tanto, la preparación de programas de aplicación para su posterior ejecución aún requería dos etapas. Era posible escribir aplicaciones de " modo mixto " utilizando instrucciones tanto de nivel de macro como de nivel de comando.
Inicialmente, en el momento de la ejecución, los comandos de nivel de comando se convertían mediante un traductor de tiempo de ejecución, "el programa de interfaz EXEC", a la antigua llamada de nivel de macro, que luego era ejecutada por los programas del núcleo de CICS, que prácticamente no habían sufrido modificaciones. Pero cuando se reescribió el núcleo de CICS para TS V3, EXEC CICS se convirtió en la única forma de programar aplicaciones CICS, ya que muchas de las interfaces subyacentes habían cambiado.
El CICS de nivel de comandos únicamente introducido a principios de los años 90 ofrecía algunas ventajas sobre las versiones anteriores de CICS. Sin embargo, IBM también abandonó el soporte para programas de aplicación de nivel macro escritos para versiones anteriores. Esto significó que muchos programas de aplicación tuvieron que convertirse o reescribirse por completo para utilizar únicamente comandos EXEC de nivel de comandos.
En ese momento, probablemente había millones de programas en todo el mundo que habían estado en producción durante décadas en muchos casos. Reescribirlos a menudo introducía nuevos errores sin agregar necesariamente nuevas características. Hubo una cantidad significativa de usuarios que ejecutaron regiones propietarias de aplicaciones (AOR) de CICS V2 para continuar ejecutando código de macro durante muchos años después del cambio a V3.
También era posible ejecutar antiguos programas de nivel macro utilizando software de conversión como Command CICS de APT International . [37]
Las mejoras recientes del servidor de transacciones CICS incluyen soporte para varios estilos de programación modernos.
CICS Transaction Server versión 5.6 [38] introdujo un soporte mejorado para Java para ofrecer una experiencia nativa de la nube para los desarrolladores de Java. Por ejemplo, la nueva API Java de CICS (JCICSX) permite realizar pruebas unitarias más sencillas utilizando enfoques de simulación y stubbing, y se puede ejecutar de forma remota en la estación de trabajo local del desarrollador. Un conjunto de artefactos CICS en Maven Central permite a los desarrolladores resolver dependencias de Java utilizando herramientas de gestión de dependencias populares como Apache Maven y Gradle . También se proporcionan complementos para Maven (cics-bundle-maven) y Gradle (cics-bundle-gradle) para simplificar la creación automatizada de paquetes CICS, utilizando IDE familiares como Eclipse , IntelliJ IDEA y Visual Studio Code . Además, la compatibilidad con z/OS de Node.js se ha mejorado para la versión 12, lo que proporciona un inicio más rápido, mejores límites de montón predeterminados, actualizaciones del motor JavaScript V8, etc. También se incluye compatibilidad con Jakarta EE 8.
CICS TS 5.5 introdujo soporte para IBM SDK para Node.js, brindando un entorno de ejecución de JavaScript completo, API del lado del servidor y bibliotecas para crear de manera eficiente aplicaciones de red altamente escalables y de alto rendimiento para IBM Z.
La versión 2.1 de CICS Transaction Server introdujo compatibilidad con Java. La versión 2.2 de CICS Transaction Server admitía el kit de herramientas para desarrolladores de software. CICS proporciona el mismo contenedor de tiempo de ejecución que la familia de productos WebSphere de IBM, de modo que las aplicaciones Java EE son portables entre CICS y Websphere y existe una herramienta común para el desarrollo y la implementación de aplicaciones Java EE.
Además, CICS hizo hincapié en "envolver" los programas de aplicación existentes dentro de interfaces modernas para que las funciones empresariales establecidas desde hace mucho tiempo se puedan incorporar a servicios más modernos. Entre ellas se incluyen las interfaces WSDL, SOAP y JSON que envuelven el código heredado para que una aplicación web o móvil pueda obtener y actualizar los objetos empresariales básicos sin necesidad de una reescritura importante de las funciones de back-end.
Una transacción CICS es un conjunto de operaciones que realizan una tarea en conjunto. Por lo general, la mayoría de las transacciones son tareas relativamente simples, como solicitar una lista de inventario o ingresar un débito o crédito en una cuenta. Una característica principal de una transacción es que debe ser atómica . En los servidores IBM Z , CICS admite fácilmente miles de transacciones por segundo, lo que lo convierte en un pilar de la informática empresarial.
Las aplicaciones CICS comprenden transacciones, que pueden escribirse en numerosos lenguajes de programación , incluidos COBOL, PL/I, C, C++, IBM Basic Assembly Language, Rexx y Java.
Cada programa CICS se inicia utilizando un identificador de transacción. Las pantallas CICS se envían normalmente como una construcción denominada mapa, un módulo creado con macros de ensamblador de Basic Mapping Support (BMS) o herramientas de terceros. Las pantallas CICS pueden contener texto resaltado, con distintos colores y/o parpadeando según el tipo de terminal utilizado. A continuación se ofrece un ejemplo de cómo se puede enviar un mapa a través de COBOL. El usuario final introduce datos, que se hacen accesibles al programa al recibir un mapa de CICS.
EJECUTAR CICS RECIBIR MAPSET ( 'LOSMATT' ) MAPA ( 'LOSATT' ) EN ( NUESTRO-MAPA ) FIN-EJECUTAR . Por razones técnicas, los argumentos de algunos parámetros de comando deben ir entre comillas y otros no, según a qué se haga referencia. La mayoría de los programadores codificarán a partir de un libro de referencia hasta que comprendan qué argumentos se deben incluir entre comillas, o normalmente utilizarán una "plantilla predefinida" en la que tienen un código de ejemplo que simplemente copian y pegan, y luego editan para cambiar los valores.
El soporte de mapeo básico define el formato de pantalla a través de macros de ensamblador como las siguientes. Esto se ensambló para generar tanto el conjunto de mapas físicos (un módulo de carga en una biblioteca de carga CICS) como un conjunto de mapas simbólicos (una definición de estructura o DSECT en PL/I, COBOL, ensamblador, etc.) que se copió en el programa fuente. [39]
LOSMATT DFHMSD TIPO = MAPA , X MODO = INOUT , X TIOAPFX = SÍ , X TÉRMINO = 3270 - 2 , X IDIOMA = COBOL , X MAPATTS = ( COLOR , RESALTO ), X DSATTS = ( COLOR , RESALTO ), X ALMACENAMIENTO = AUTO , X CTRL = ( FREEKB , FRSET ) * LOSATT DFHMDI TAMAÑO = ( 24 , 80 ), X LÍNEA = 1 , X COLUMNA = 1 * LSSTDII DFHMDF POS = ( 1 , 01 ), X LONGITUD = 04 , X COLOR = AZUL , X INICIAL = 'MQCM' , X ATRIBUTO = PROT * DFHMDF POS = ( 24 , 01 ), X LONGITUD = 79 , X COLOR = AZUL X ATRIBUTO = SALTAR , X INICIAL = 'PF7- 8- 9- 10- X 11 - 12 - CANCELAR ' * DFHMSD TIPO = FINAL FIN En el entorno z/OS , una instalación de CICS comprende una o más " regiones " (generalmente denominadas "Región CICS"), [40] distribuidas en una o más imágenes del sistema z/OS. Aunque procesa transacciones interactivas, cada región CICS suele iniciarse como un espacio de direcciones de procesamiento por lotes con instrucciones JCL estándar : es un trabajo que se ejecuta indefinidamente hasta el apagado. Alternativamente, cada región CICS puede iniciarse como una tarea iniciada . Ya sea un trabajo por lotes o una tarea iniciada, las regiones CICS pueden ejecutarse durante días, semanas o incluso meses antes de apagarse por mantenimiento (MVS o CICS). Al reiniciar, un parámetro determina si el inicio debe ser "Frío" (sin recuperación) o "Caliente"/"Emergencia" (utilizando un apagado templado o reiniciando desde el registro después de un bloqueo). Los inicios en frío de regiones CICS grandes con muchos recursos pueden llevar mucho tiempo ya que se vuelven a procesar todas las definiciones.
Las instalaciones se dividen en múltiples espacios de direcciones por una amplia variedad de razones, como:
Una instalación típica consta de varias aplicaciones distintas que conforman un servicio. Cada servicio suele tener varias "regiones propietarias de terminales" (TOR) que enrutan transacciones a varias "regiones propietarias de aplicaciones" (AOR), aunque son posibles otras topologías. Por ejemplo, es posible que las AOR no realicen operaciones de E/S de archivos. En su lugar, habría una "región propietaria de archivos" (FOR) que realizaría la E/S de archivos en nombre de las transacciones en la AOR, dado que, en ese momento, un archivo VSAM solo podía admitir acceso de escritura recuperable desde un espacio de direcciones a la vez.
Pero no todas las aplicaciones CICS utilizan VSAM como fuente de datos principal (ni, históricamente, otros almacenes de datos con un único espacio de direcciones a la vez, como CA Datacom); muchas utilizan IMS/DB o Db2 como base de datos y/o MQ como gestor de colas. En todos estos casos, los TOR pueden equilibrar la carga de las transacciones en conjuntos de AOR que luego utilizan directamente las bases de datos/colas compartidas. CICS admite la confirmación en dos fases de XA entre almacenes de datos, por lo que las transacciones que abarcan MQ, VSAM/RLS y Db2, por ejemplo, son posibles con propiedades ACID.
CICS admite transacciones distribuidas mediante el protocolo SNA LU6.2 entre los espacios de direcciones que se pueden ejecutar en el mismo clúster o en clústeres diferentes. Esto permite actualizaciones ACID de múltiples almacenes de datos mediante aplicaciones distribuidas que cooperan. En la práctica, esto plantea problemas si se produce un fallo en el sistema o en las comunicaciones, ya que la disposición de la transacción (retroceso o confirmación) puede estar en duda si uno de los nodos que se comunican no se ha recuperado. Por ello, el uso de estas funciones nunca ha sido muy extendido.
En el momento de CICS ESA V3.2, a principios de la década de 1990, IBM se enfrentó al desafío de cómo lograr que CICS explotara la nueva línea de mainframes zOS Sysplex .
El Sysplex se basaría en CMOS (Complementary Metal Oxide Silicio) en lugar del hardware ECL (Emitter Coupled Logic) existente. El costo de escalar el ECL exclusivo de mainframe era mucho más alto que el CMOS, que estaba siendo desarrollado por un keiretsu con casos de uso de alto volumen como Sony PlayStation para reducir el costo unitario de las CPU de cada generación. El ECL también era caro para los usuarios porque la corriente de drenaje de la compuerta producía tanto calor que la CPU tenía que empaquetarse en un módulo especial llamado Módulo de Conducción Térmica (TCM [41] ) que tenía pistones de gas inerte y necesitaba una tubería de agua helada de alto volumen para enfriarse. Sin embargo, la velocidad de la CPU de la tecnología CMOS enfriada por aire inicialmente era mucho más lenta que la ECL (notablemente las cajas disponibles de los fabricantes de clones de mainframe Amdahl e Hitachi ). Esto fue especialmente preocupante para IBM en el contexto de CICS, ya que casi todos los clientes más grandes de mainframe ejecutaban CICS y para muchos de ellos era la carga de trabajo principal de mainframe.
Para lograr el mismo rendimiento total de transacciones en un Sysplex, se necesitarían utilizar varios equipos en paralelo para cada carga de trabajo. Sin embargo, un espacio de direcciones CICS, debido a su modelo de programación de aplicaciones cuasi-reentrante, no podría explotar más de 1,5 procesadores en un equipo a la vez, incluso con el uso de subtareas MVS. Sin un paralelismo mejorado, los clientes tenderían a pasarse a los competidores de IBM en lugar de utilizar Sysplex a medida que aumentaban las cargas de trabajo CICS. Hubo un debate considerable dentro de IBM sobre si el enfoque correcto sería romper la compatibilidad ascendente para las aplicaciones y pasar a un modelo como IMS/DC que fuera completamente reentrante, o extender el enfoque que los clientes habían adoptado para explotar más plenamente la potencia de un solo mainframe, utilizando la operación multirregional (MRO).
Finalmente, se adoptó la segunda opción tras consultar a la comunidad de usuarios de CICS. La comunidad se opuso vehementemente a romper la compatibilidad ascendente, dado que en ese momento tenían que hacer frente a la perspectiva del Y2K y no veían el valor de reescribir y probar millones de líneas de código principalmente COBOL, PL/I o ensamblador.
La estructura recomendada por IBM para CICS en Sysplex era que se colocara al menos una región propietaria de terminal CICS en cada nodo Sysplex que enviaba transacciones a muchas regiones propietarias de aplicaciones (AOR) distribuidas en todo el Sysplex. Si estas aplicaciones necesitaban acceder a recursos compartidos, utilizaban un almacén de datos que explotaba Sysplex (como IBM Db2 o IMS/DB ) o concentraban, mediante el envío de funciones, las solicitudes de recursos en regiones propietarias de recursos (ROR) singulares por recurso, incluidas las regiones propietarias de archivos (FOR) para VSAM y tablas de datos CICS, las regiones propietarias de colas (QOR) para MQ , los datos transitorios (TD) de CICS y el almacenamiento temporal (TS) de CICS. Esto preservó la compatibilidad para las aplicaciones heredadas a expensas de la complejidad operativa para configurar y administrar muchas regiones CICS.
En versiones y lanzamientos posteriores, CICS pudo explotar nuevas facilidades de explotación de Sysplex en VSAM/RLS, [42] MQ para zOS [43] y colocó sus propios recursos de Tablas de datos, TD y TS en el administrador de recursos compartidos diseñado para el Sysplex -> la Instalación de acoplamiento o CF, eliminando la necesidad de la mayoría de los ROR. El CF proporciona una vista mapeada de los recursos que incluye una base de tiempo compartida, grupos de búfer, bloqueos y contadores con asistencia de mensajería de hardware que hicieron que compartir recursos en el Sysplex fuera más eficiente que el sondeo y confiable (utilizando un CF de respaldo semisincronizado para usar en caso de falla).
En ese momento, la línea CMOS tenía cajas individuales que superaban la potencia disponible de la caja ECL más rápida con más procesadores por CPU. Cuando se acoplaban, 32 o más nodos podían escalar dos órdenes de magnitud más en potencia total para una sola carga de trabajo. Por ejemplo, en 2002, Charles Schwab estaba ejecutando un "MetroPlex" que consistía en un par redundante de Sysplexes de mainframe en dos ubicaciones en Phoenix, Arizona, cada uno con 32 nodos impulsados por una carga de trabajo CICS/DB/2 compartida para soportar el vasto volumen de solicitudes de consultas de clientes web anteriores a la burbuja de las puntocom .
Esta base de tecnología CMOS más barata y mucho más escalable, y los enormes costos de inversión de tener que llegar al direccionamiento de 64 bits y producir de forma independiente la funcionalidad CF clonada, expulsaron del negocio a los fabricantes de clones de mainframes de IBM uno por uno. [44] [45]
El objetivo de la recuperación/reinicio en CICS es minimizar y, si es posible, eliminar el daño causado al sistema en línea cuando ocurre una falla, de modo que se mantenga la integridad del sistema y de los datos. [46] Si la región CICS se apagó en lugar de fallar, realizará un inicio "caliente" aprovechando el punto de control escrito en el apagado. La región CICS también puede verse obligada a iniciarse "en frío", lo que vuelve a cargar todas las definiciones y borra el registro, dejando los recursos en el estado en el que se encuentren.
Según CICS, a continuación se enumeran algunos de los recursos que se consideran recuperables. Si se desea que estos recursos sean recuperables, se deben especificar opciones especiales en las definiciones de CICS pertinentes:
CICS también ofrece amplias funciones de recuperación y reinicio para que los usuarios establezcan su propia capacidad de recuperación y reinicio en su sistema CICS. Las funciones de recuperación y reinicio más utilizadas son:
Cada región de CICS comprende una tarea principal en la que se ejecuta cada transacción, aunque ciertos servicios, como el acceso a los datos de IBM Db2, utilizan otras tareas (TCB). Dentro de una región, las transacciones se ejecutan en múltiples tareas de manera cooperativa : se espera que se comporten bien y utilicen la CPU en lugar de esperar. Los servicios de CICS se encargan de esto automáticamente.
A cada " Tarea " o transacción única de CICS se le asigna su propia memoria dinámica al inicio y las solicitudes posteriores de memoria adicional se manejan mediante una llamada al "programa de control de almacenamiento" (parte del núcleo o " kernel " de CICS), que es análogo a un sistema operativo .
Un sistema CICS consta del núcleo en línea , programas de soporte por lotes y servicios de aplicaciones. [47]
El núcleo original de CICS constaba de una serie de módulos funcionales escritos en ensamblador 370 hasta la V3:
A partir de la versión 3, el núcleo de CICS se reescribió en una estructura de núcleo y dominio utilizando el lenguaje PL/AS de IBM , que se compila en ensamblador.
La estructura anterior no imponía la separación de intereses y, por lo tanto, tenía muchas dependencias entre programas que generaban errores a menos que se hiciera un análisis exhaustivo del código. La nueva estructura era más modular y, por lo tanto, resistente porque era más fácil cambiarla sin afectarla. Los primeros dominios se solían construir con el nombre del programa anterior, pero sin la "P" final. Por ejemplo, el dominio de control del programa (DFHPC) o el dominio de datos transitorios (DFHTD). El núcleo funcionaba como un conmutador para las solicitudes entre dominios; al principio, esto resultó costoso para los dominios a los que se llamaba con frecuencia (como Trace), pero al utilizar macros PL/AS, estas llamadas se integraban sin comprometer el diseño de dominios separados.
En versiones posteriores, se agregaron dominios completamente rediseñados, como el dominio de registro DFHLG y el dominio de transacción DFHTM, que reemplazaron al programa de control de diario (JCP).
Además de las funciones en línea, CICS tiene varios programas de soporte que se ejecutan como trabajos por lotes. [48] : pp.34–35
Los siguientes componentes de CICS respaldan el desarrollo de aplicaciones. [48] : pp.35–37
EXEC CICScomandos en llamadas a funciones CICSLos distintos países tienen diferentes pronunciaciones [49]
CICS DDM ya no está disponible en IBM y se interrumpió el soporte a partir del 31 de diciembre de 2003. CICS DDM ya no está disponible en CICS TS a partir de la versión 5.2.
El soporte para CICS Distributed Data Management (DDM) se ha estabilizado en CICS TS para VSE/ESA V1.1.1. En una futura versión de CICS TS para z/VSE, IBM tiene la intención de discontinuar el soporte para CICS DDM.
CICS Distributed Data Management (CICS/DDM) no es compatible con CICS TS for z/VSE V2.1.
Familia IBM Personal Computer XT/370