IBM CICS (Sistema de control de información del cliente) es una familia de servidores de aplicaciones de lenguaje mixto que brindan conectividad y administración de transacciones en línea 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 un 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 transacciones en segundo plano.
CICS Transaction Server (CICS TS) está 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 usar para los programadores, particularmente con respecto 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 gestiona toda la transacción de modo que, si por algún motivo una parte de la transacción falla, se puedan 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 Fortune 500 y entidades gubernamentales administran CICS. Otras empresas más pequeñas también pueden ejecutar CICS TS y otros productos de la familia CICS. CICS se puede encontrar regularmente entre bastidores, por ejemplo, en aplicaciones de cajeros bancarios, sistemas 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, y al mismo tiempo brindan actualizaciones en las áreas clave de seguridad, resiliencia y administración. En versiones anteriores y recientes de CICS TS, se proporcionaba soporte para servicios web y Java , procesamiento de eventos , fuentes Atom e interfaces RESTful .
CICS fue precedido por un sistema anterior 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, denominado Sistema de control de información del cliente de servicios públicos o PU-CICS. Inmediatamente quedó claro que tenía aplicabilidad en muchas otras industrias, por lo que el prefijo de utilidad pública se eliminó con la introducción de la primera versión del producto del 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" menos importante que IMS, que IBM luego consideró más estratégico. Sin embargo, la presión de los clientes lo mantuvo vivo. Cuando IBM decidió poner fin al desarrollo de CICS en 1974 para concentrarse en IMS, la responsabilidad del desarrollo de CICS fue asumida por el sitio de IBM Hursley en el Reino Unido, que acababa de dejar de trabajar en el compilador PL/I y por eso conocía muchas de las mismas cosas. clientes como CICS. El núcleo del trabajo de desarrollo continúa hoy en Hursley junto con las contribuciones de laboratorios de India, China, Rusia, Australia y Estados Unidos.
Originalmente, 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. Los terminales de visualización de vídeo IBM 2260 de 1964 y IBM 3270 de 1972 se utilizaron ampliamente posteriormente.
En los primeros días de las mainframes de IBM, el software era gratuito y se incluía sin costo adicional con el hardware de la computadora . 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ó agregar 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 sintieron erróneamente que el futuro sería como el pasado, con procesamiento por lotes utilizando tarjetas perforadas tradicionales .
IBM, a regañadientes, proporcionó 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 informático de reservas Sabre de American Airlines ) para el acceso a datos de alta velocidad. y actualizar la información del cliente para sus operadores telefónicos (sin esperar a que los sistemas de tarjetas perforadas procesen por lotes durante la noche).
Cuando CICS se entregó a Amoco con soporte Teletype Model 33 ASR, provocó que todo el sistema operativo OS/360 fallara (incluidos los programas de aplicaciones que no eran CICS). La mayor parte del Programa de control de terminales 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 fue devuelto a IBM para que lo distribuyera gratuitamente a otros.
En unos años, [ ¿ cuándo? ] CICS generó más de 60 mil millones de dólares en ingresos por nuevo hardware para IBM y se convirtió en su producto de software mainframe de mayor éxito.
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 las primeras versiones) se trasladaron a California y continuaron el desarrollo de CICS en el Centro de Desarrollo de Palo Alto de IBM . Los ejecutivos de IBM no reconocieron el valor del software como producto generador de ingresos hasta que la ley federal exigió la desagregación del software . En 1980, los ejecutivos de IBM no prestaron atención a las fuertes sugerencias de Ben Riggins de que IBM debería proporcionar su propio sistema operativo basado en EBCDIC y su propio chip de microprocesador de circuito integrado para su uso en la computadora personal de IBM como terminal inteligente CICS (en lugar del incompatible chip Intel, y Microsoft 1980 DOS basado en ASCII inmaduro ).
Debido a la capacidad limitada de incluso los procesadores más grandes de esa época, cada instalación de CICS era necesaria para 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 el ensamblaje condicional. -declaraciones de lenguaje. Este proceso permitió a cada cliente excluir el soporte de CICS para cualquier función que no pretendía utilizar, como el soporte de dispositivos para tipos de terminales que no estaban en uso.
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, incluida la depuración y la funcionalidad. mejora.
Parte de 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 el liderazgo de Tony Hoare . Este trabajo ganó el Queen's Award for Technological Achievement. [6]
En 1986, IBM anunció el soporte de CICS para los servicios de archivos orientados a registros definidos por Distributed Data Management Architecture (DDM). Esto permitió que los programas en computadoras remotas conectadas a la red crearan, administraran y accedieran a archivos que anteriormente solo estaban disponibles dentro de los entornos de procesamiento de transacciones CICS/MVS y CICS/VSE. [7]
En las versiones más recientes de CICS, se ha eliminado la compatibilidad con DDM. El soporte para 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, el soporte para DDM se estabilizó en el nivel V1.1.1, con la intención anunciada de descontinuarlo en una versión futura. [9] En CICS para z/VSE 2.1 y posteriores, no se admite CICS/DDM. [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 empaquetar programas basados en terminales de pantalla verde con una fachada HTML. Las API web y de documentos de CICS se mejoraron en CICS TS V1.3 para permitir que las aplicaciones web se escriban para interactuar de manera más efectiva con los navegadores web.
Las versiones 2.1 a 2.3 de CICS TS se centraron en introducir tecnologías CORBA y EJB en CICS, ofreciendo nuevas formas de integrar activos 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 con respecto a 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. Al final, WebSphere Liberty quedó completamente integrado en CICS Transaction Server en la versión 5.3. Numerosas tecnologías orientadas a la web podrían alojarse en CICS utilizando Java, lo que finalmente resultó en 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 la comunicación saliente. Estas tecnologías gemelas permitieron una integración más sencilla de los componentes CICS con otras aplicaciones empresariales y experimentaron 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 versiones sucesivas de CICS.
CICS TS V4.1 y V4.2 vieron 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 estuvieron disponibles para versiones anteriores de CICS utilizando modelos de entrega distintos a los de una versión de producto tradicional. Esto permitió a los primeros usuarios brindar comentarios constructivos que podrían influir en el diseño final de la tecnología integrada. Los ejemplos incluyen la vista previa 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 el soporte 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 , las cuales permitieron que los programas alojados en CICS estuvieran envueltos 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 activos de varios subsistemas de mainframe.
También se han utilizado muchos productos de socios para interactuar con CICS. Los 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 formas de integrar activos de software nuevos y existentes en flujos de aplicaciones distribuidas. Se puede acceder a los activos CICS desde sistemas remotos y se puede acceder a sistemas remotos; la identidad del usuario y el contexto transaccional se pueden propagar; Las API RESTful se pueden componer y gestionar; 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 de consultoría fundada en 1969, que había creado "sistemas masivos en línea" para hoteles Hilton, 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 normalmente 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 llama 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 de z/OS (es decir, CICS Transaction Server para z/OS) es, con diferencia, la más popular e importante.
Anteriormente había dos versiones de CICS disponibles para VM/CMS , pero desde entonces ambas han sido descontinuadas. 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; las aplicaciones se transfirieron posteriormente a un sistema MVS o DOS/VS para su ejecución en producción. [15] [16] Posteriormente, en 1988, IBM lanzó CICS/VM . [17] [18] CICS/VM estaba pensado para su uso en IBM 9370 , un mainframe de gama baja destinado a uso departamental; IBM posicionó CICS/VM ejecutándose en mainframes departamentales o de sucursales para su uso junto con un mainframe central que ejecuta CICS para MVS. [19]
CICS Tools proporciona el aprovisionamiento, la gestión y el análisis de los sistemas y aplicaciones CICS. Esto incluye la gestión del rendimiento, así como la implementación y gestión de recursos CICS. En 2015, las cuatro herramientas fundamentales 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 CICS principales: 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 soportar múltiples subprocesos de transacciones concurrentes . Un error de codificación de software en una aplicación podrí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 sólo 32K de costosa memoria física de núcleo magnético (incluido el sistema operativo ).
Los programadores de aplicaciones CICS requirieron 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 4.096 bytes, o 4K, para que CICS pudiera reutilizar fácilmente la memoria ocupada por cualquier programa que no se estuviera utilizando actualmente para otro programa u otras necesidades de almacenamiento de aplicaciones. Cuando se agregó memoria virtual a las versiones OS/360 en 1972, la estrategia 4K se volvió aún más importante para reducir la paginación y la sobrecarga improductiva de contención de recursos.
La eficiencia de los programas compilados en lenguaje COBOL y PL/I de alto nivel dejaba mucho que desear. Muchos programas de aplicación CICS continuaron escribiéndose en lenguaje ensamblador, incluso después de que estuvo disponible el soporte COBOL y PL/I.
Con los recursos de hardware de las décadas de 1960 y 1970 caros y escasos, se desarrolló un "juego" competitivo entre los analistas de optimización de sistemas. Cuando se identificó el código de ruta crítica , se pasó un fragmento de código de un analista a otro. Cada persona tenía que (a) reducir la cantidad de bytes de código requeridos o (b) reducir la cantidad de ciclos de CPU requeridos. Los analistas más jóvenes aprendieron de lo que hicieron los mentores más experimentados. Finalmente, cuando nadie pudo hacer (a) o (b), el código se consideró optimizado y pasaron a otros fragmentos. Los talleres pequeños con un solo analista aprendieron la optimización de CICS muy lentamente (o 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).
Desafortunadamente, muchas de las "reglas" se infringían con frecuencia, especialmente por programadores de COBOL que podrían no comprender los aspectos internos de sus programas o no utilizar las opciones restrictivas de tiempo de compilación necesarias . Esto dio como resultado un código "no reentrante" que a menudo no era confiable, lo que provocaba falsas violaciones de almacenamiento 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 kernel CICS. La corrupción del programa y del bloque de control CICS fue una causa frecuente de tiempo de inactividad del sistema. Un error de software en un programa de aplicación podría sobrescribir la memoria (código o datos) de una o todas las transacciones de la aplicación que se están ejecutando actualmente. Localizar el código de la aplicación infractor para errores de temporización transitorios complejos podría ser un problema muy difícil para los analistas 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 escasez. Se abordaron en TS V3.3, V4.1 y V5.2 con las funciones Protección de almacenamiento, Aislamiento de transacciones y Subespacio respectivamente, que utilizan funciones de hardware del sistema operativo para proteger el código de la aplicación y los datos dentro del mismo espacio de direcciones incluso aunque el las solicitudes no fueron escritas para ser separadas. Las transacciones de aplicaciones CICS siguen siendo de misión crítica 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 CICS se lanzó por primera vez, solo admitía programas de transacciones de aplicaciones escritos en IBM 360 Assembler. Años más tarde se añadió compatibilidad con COBOL y PL/I . Debido a la orientación inicial del ensamblador, las solicitudes de servicios CICS se realizaron utilizando macros en 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 TYPE=LEER,DATASET=miarchivo,TYPOPER=ACTUALIZAR,....etc.
Esto dio lugar a la terminología posterior " CICS de nivel macro ".
Cuando se agregó soporte de lenguaje de alto nivel, las macros se conservaron y el código se convirtió mediante un precompilador que expandió las macros a sus equivalentes de declaración COBOL o PL/I CALL. Por lo tanto, preparar una aplicación HLL fue efectivamente una compilación de "dos etapas" : la salida del preprocesador se introdujo en el compilador HLL como entrada.
Consideraciones sobre COBOL : a diferencia de PL/I, IBM COBOL normalmente no prevé la manipulación de punteros (direcciones). Para permitir a los programadores de COBOL acceder a los bloques de control de CICS y al almacenamiento dinámico, los diseñadores recurrieron a lo que era esencialmente un truco. La sección de enlace COBOL se usaba normalmente para la comunicación entre programas, como el paso de parámetros. El compilador genera una lista de direcciones, cada una llamada Localizador de base para enlace (BLL), que se configuraron al ingresar al programa llamado. El primer BLL corresponde al primer elemento de la Sección de vinculación y así sucesivamente. CICS permite al programador acceder a ellos y manipularlos pasando la dirección de la lista como primer argumento del programa. Luego, los BLL se pueden configurar dinámicamente, ya sea mediante CICS o mediante la aplicación para permitir el acceso a la estructura correspondiente en la Sección de vinculación. [35]
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 API para los programas de aplicación.
Una llamada típica a nivel de comando podría tener el siguiente aspecto:
EXEC CICS ENVIAR MAPSET ( 'LOSMATT' ) MAP ( 'LOSATT' ) END-EXEC Los valores proporcionados 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 declaraciones de llamada a una subrutina 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 declaraciones tanto a nivel de macro como a nivel de comando.
Inicialmente, en el momento de la ejecución, los comandos a nivel de comando se convirtieron utilizando un traductor en tiempo de ejecución, "El programa de interfaz EXEC", a la antigua llamada a nivel de macro, que luego fue ejecutada por los programas del núcleo CICS, en su mayoría sin cambios. Pero cuando se reescribió el kernel 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 comando únicamente introducido a principios de la década de 1990 ofrecía algunas ventajas sobre 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 comando.
En ese momento, tal vez había millones de programas en todo el mundo que en muchos casos habían estado en producción durante décadas. Reescribirlos a menudo introducía nuevos errores sin agregar necesariamente nuevas características. Hubo un número significativo 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 programas antiguos a nivel de macro utilizando software de conversión como Command CICS de APT International . [36]
Las mejoras recientes de CICS Transaction Server incluyen soporte para varios estilos de programación modernos.
CICS Transaction Server Versión 5.6 [37] introdujo soporte mejorado para Java para ofrecer una experiencia nativa de la nube para los desarrolladores de Java. Por ejemplo, la nueva API CICS Java (JCICSX) permite realizar pruebas unitarias más sencillas utilizando enfoques de simulación y creación de trozos, 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 populares de administración de dependencias 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 Node.js z/OS se ha mejorado para la versión 12, lo que proporciona un inicio más rápido, mejores límites de almacenamiento dinámico 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, proporcionando un tiempo 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.
CICS Transaction Server Versión 2.1 introdujo soporte para Java. CICS Transaction Server Versión 2.2 admitía Software Developers Toolkit. CICS proporciona el mismo contenedor de tiempo de ejecución que la familia de productos WebSphere de IBM, por lo que las aplicaciones Java EE son portátiles entre CICS y Websphere y existen herramientas comunes para el desarrollo y la implementación de aplicaciones Java EE.
Además, CICS puso énfasis en "envolver" los programas de aplicación existentes dentro de interfaces modernas para que las funciones comerciales establecidas desde hace mucho tiempo puedan incorporarse a servicios más modernos. Estos incluyen interfaces WSDL, SOAP y JSON que empaquetan código heredado para que una aplicación web o móvil pueda obtener y actualizar los objetos comerciales principales sin requerir 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++, lenguaje ensamblador básico de IBM, Rexx y Java.
Cada programa CICS se inicia utilizando un identificador de transacción. Las pantallas CICS generalmente se envían como una construcción llamada mapa, un módulo creado con macros ensambladoras de soporte básico de mapeo (BMS) o herramientas de terceros. Las pantallas CICS pueden contener texto resaltado, con diferentes colores y/o parpadeando según el tipo de terminal utilizado. A continuación se proporciona un ejemplo de cómo se puede enviar un mapa a través de COBOL. El usuario final ingresa datos, a los que el programa puede acceder al recibir un mapa de CICS.
EXEC CICS RECIBIR MAPSET ( 'LOSMATT' ) MAP ( 'LOSATT' ) EN ( OUR-MAP ) END-EXEC . Por razones técnicas, los argumentos de algunos parámetros de comando se deben citar y otros no, dependiendo de a qué se haga referencia. La mayoría de los programadores codificarán a partir de un libro de referencia hasta que comprendan el concepto de qué argumentos se citan, o normalmente usarán una "plantilla enlatada" donde tienen un código de ejemplo que simplemente copian y pegan, y luego lo editan. cambiar los valores.
El soporte básico de mapeo 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. [38]
LOSMATT DFHMSD TIPO = MAPA , X MODO = INOUT , X TIOAPFX = SÍ , X TERM = 3270 - 2 , X LANG = COBOL , X MAPATTS = ( COLOR , HILIGHT ), X DSATTS = ( COLOR , HILIGHT ), X ALMACENAMIENTO = AUTO , X CTRL = ( FREEKB , FRSET ) * LOSATT DFHMDI TAMAÑO = ( 24 , 80 ), X LINEA = 1 , X COLUMNA = 1 * LSSTDII DFHMDF POS = ( 1 , 01 ), X LONGITUD = 04 , X COLOR = AZUL , X INICIAL = 'MQCM' , X ATTRB = PROT * DFHMDF POS = ( 24 , 01 ), X LONGITUD = 79 , X COLOR = AZUL X ATTRB = PREGUNTAR , X INICIAL = 'PF7- 8- 9- 10- X 11 - 12 - CANCELAR ' * TIPO DFHMSD = FINAL FINAL En el entorno z/OS , una instalación CICS comprende una o más " regiones " (generalmente denominadas "Región CICS"), [39] distribuidas en una o más imágenes del sistema z/OS. Aunque procesa transacciones interactivas, cada región CICS generalmente se inicia como un espacio de direcciones por lotes (procesamiento por lotes) con declaraciones JCL estándar : es un trabajo que se ejecuta indefinidamente hasta que se apaga. Alternativamente, cada región CICS se puede iniciar 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 cerrarse por mantenimiento (MVS o CICS). Al reiniciar, un parámetro determina si el inicio debe ser "Frío" (sin recuperación) o "Cálido"/"Emergencia" (usando un apagado en caliente o reiniciando desde el registro después de un bloqueo). Los arranques en frío de regiones CICS grandes con muchos recursos pueden llevar mucho tiempo ya que se reprocesan todas las definiciones.
Las instalaciones se dividen en múltiples espacios de direcciones por una amplia variedad de motivos, como por ejemplo:
Una instalación típica consta de varias aplicaciones distintas que conforman un servicio. Cada servicio suele tener una serie de "regiones propietarias de terminales" (TOR) que enrutan las transacciones a múltiples "regiones propietarias de aplicaciones" (AOR), aunque son posibles otras topologías. Por ejemplo, es posible que los AOR no realicen E/S de archivos. En su lugar, habría una "Región propietaria de archivos" (FOR) que realizaba la E/S de archivos en nombre de las transacciones en el AOR, dado que, en ese momento, un archivo VSAM solo podía admitir acceso de escritura recuperable desde un espacio de direcciones en un momento.
Pero no todas las aplicaciones CICS utilizan VSAM como fuente de datos principal (o históricamente otros almacenes de datos de espacio de dirección única a la vez, como CA Datacom); muchas utilizan IMS/DB o Db2 como base de datos y/o MQ. como administrador de colas. Para todos estos casos, los TOR pueden equilibrar la carga de transacciones en conjuntos de AOR que luego utilizan directamente las bases de datos/colas compartidas. CICS admite la confirmación XA en dos fases entre almacenes de datos y, por lo tanto, las transacciones que abarcan MQ, VSAM/RLS y Db2, por ejemplo, son posibles con propiedades ACID.
CICS admite transacciones distribuidas utilizando el protocolo SNA LU6.2 entre los espacios de direcciones que pueden ejecutarse en el mismo clúster o en diferentes. Esto permite actualizaciones ACID de múltiples almacenes de datos mediante la cooperación de aplicaciones distribuidas. En la práctica, existen problemas con esto si se produce una falla del sistema o de las comunicaciones porque la disposición de la transacción (retirada o compromiso) puede estar en duda si uno de los nodos de comunicación no se ha recuperado. Por tanto, el uso de estas instalaciones nunca ha estado muy extendido.
En el momento de CICS ESA V3.2, a principios de la década de 1990, IBM enfrentó el desafío de cómo lograr que CICS explotara la nueva línea de mainframe zOS Sysplex .
El Sysplex se basaría en CMOS (óxido metálico de silicio complementario) en lugar del hardware ECL (lógica acoplada de emisor) 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 gran volumen como Sony PlayStation para reducir el costo unitario de las CPU de cada generación. El funcionamiento del ECL también era costoso 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 [40] ) que tenía pistones de gas inerte y necesitaba ser conectado con alta tensión. Volumen de agua enfriada a enfriar. Sin embargo, la velocidad de la CPU de la tecnología CMOS refrigerada por aire era inicialmente mucho más lenta que la de la ECL (en particular, las cajas disponibles de los fabricantes de clones de mainframe Amdahl e Hitachi ). Esto era especialmente preocupante para IBM en el contexto de CICS, ya que casi todos los clientes de mainframe más grandes 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, sería necesario utilizar varias cajas en paralelo para cada carga de trabajo. Sin embargo, un espacio de direcciones CICS, debido a su modelo de programación de aplicaciones casi reentrante, no podía explotar más de 1,5 procesadores en una caja a la vez, incluso con el uso de subtareas MVS. Sin un paralelismo mejorado, los clientes tenderían a optar por los competidores de IBM en lugar de utilizar Sysplex a medida que ampliaran las cargas de trabajo de CICS. Hubo un debate considerable dentro de IBM sobre si el enfoque correcto sería romper con la compatibilidad hacia arriba para las aplicaciones y pasar a un modelo como IMS/DC que fuera completamente reentrante, o ampliar el enfoque que los clientes habían adoptado para explotar más plenamente el poder de un solo mainframe. – utilizando operación multirregional (MRO).
Finalmente se adoptó el segundo camino después de consultar a la comunidad de usuarios de CICS. La comunidad se opuso vehementemente a romper la compatibilidad ascendente dado que tenían que lidiar con la perspectiva del año 2000 en ese momento 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 enviara transacciones a muchas regiones propietarias de aplicaciones (AOR) repartidas por 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 envío de funciones, las solicitudes de recursos en regiones de propiedad de recursos (ROR) singulares por recurso, incluidas Regiones propietarias de archivos (FOR) para tablas de datos VSAM y CICS, regiones propietarias de colas (QOR) para MQ , datos transitorios (TD) de CICS y almacenamiento temporal (TS) de CICS. Esto preserva la compatibilidad para aplicaciones heredadas a expensas de la complejidad operativa para configurar y administrar muchas regiones CICS.
En lanzamientos y versiones posteriores, CICS pudo explotar nuevas funciones de explotación de Sysplex en VSAM/RLS, [41] MQ para zOS [42] y colocó sus propias tablas de datos, recursos TD y TS en el administrador de recursos compartidos diseñado para el Sysplex -> Coupling Facility o CF, prescindiendo de la necesidad de la mayoría de los ROR. El CF proporciona una vista mapeada de los recursos, incluida una base de tiempo compartida, grupos de búfer, bloqueos y contadores con asistencia de mensajería de hardware que hizo que compartir recursos en todo el Sysplex fuera más eficiente que el sondeo y confiable (utilizando un CF de respaldo semisincronizado para su uso en caso de falla).
En ese momento, la línea CMOS tenía cajas individuales que excedían la potencia disponible de la caja ECL más rápida con más procesadores por CPU. Cuando estos se acoplaran, 32 o más nodos podrí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 Sysplex de mainframe en dos ubicaciones en Phoenix, AZ, cada uno con 32 nodos impulsados por una carga de trabajo CICS/DB/2 compartida para soportar el gran volumen de Solicitudes de consulta de clientes web anteriores a la burbuja 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 IBM uno por uno. [43] [44]
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. [45] Si la región CICS se cerró en lugar de fallar, realizará un inicio "en caliente" aprovechando el punto de control escrito durante el cierre. También se puede forzar a la región CICS a un inicio "en frío", lo que recarga todas las definiciones y borra el registro, dejando los recursos en cualquier estado en el que se encuentren.
Según CICS, a continuación se detallan algunos de los recursos que se consideran recuperables. Si se desea que estos recursos sean recuperables, se deben especificar opciones especiales en las definiciones CICS pertinentes:
CICS también ofrece amplias funciones de recuperación/reinicio para que los usuarios establezcan su propia capacidad de recuperación/reinicio en su sistema CICS. Las funciones de recuperación/reinicio más utilizadas incluyen:
Cada región CICS comprende una tarea principal en la que se ejecuta cada transacción, aunque ciertos servicios, como el acceso a datos de IBM Db2, utilizan otras tareas (TCB). Dentro de una región, las transacciones son cooperativamente multitarea : se espera que se comporten bien y produzcan CPU en lugar de esperar. Los servicios CICS manejan esto automáticamente.
A cada " tarea " o transacción CICS única se le asigna su propia memoria dinámica en el inicio y las solicitudes posteriores de memoria adicional se manejan mediante una llamada al "programa de control de almacenamiento" (parte del núcleo CICS o " kernel "), 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. [46]
El núcleo CICS original constaba de varios módulos funcionales escritos en ensamblador 370 hasta V3:
A partir de V3, el núcleo 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 preocupaciones y, por lo tanto, tenía muchas dependencias entre programas que generaban errores a menos que se realizara un análisis exhaustivo del código. La nueva estructura era más modular y resistente porque era más fácil de cambiar sin impacto. Los primeros dominios a menudo se creaban con el nombre del programa anterior pero sin la "P" final. Por ejemplo, dominio de control de programa (DFHPC) o dominio de datos transitorios (DFHTD). El kernel funcionó como un conmutador para solicitudes entre dominios; inicialmente esto resultó costoso para dominios llamados con frecuencia (como Trace), pero al utilizar macros PL/AS, estas llamadas se alinearon sin comprometer el diseño del dominio separado.
En versiones posteriores, se agregaron dominios completamente rediseñados como Logging Domain DFHLG y Transaction Domain DFHTM que reemplazaron al Journal Control Program (JCP).
Además de las funciones en línea, CICS tiene varios programas de soporte que se ejecutan como trabajos por lotes. [47] : págs. 34-35
Los siguientes componentes de CICS dan soporte al desarrollo de aplicaciones. [47] : págs. 35–37
EXEC CICScomandos en llamadas a funciones CICSDiferentes países tienen diferentes pronunciaciones [48]
CICS DDM ya no está disponible en IBM y el soporte se interrumpió el 31 de diciembre de 2003. CICS DDM ya no está disponible en CICS TS desde la versión 5.2 en adelante.
El soporte para CICS Distributed Data Management (DDM) está estabilizado en CICS TS para VSE/ESA V1.1.1. En una versión futura de CICS TS para z/VSE, IBM tiene intención de suspender el soporte para CICS DDM.
CICS Distributed Data Management (CICS/DDM) no es compatible con CICS TS para z/VSE V2.1.
Familia de computadoras personales IBM XT/370