CICS

Inicialmente, CICS solo era compatible con algunos dispositivos de la marca IBM, como el terminal de máquina de escribir IBM 2741 Selectric (con forma de bola de golf) de 1965. Los terminales de visualización de vídeo IBM 2260 de 1964 y IBM 3270 de 1972 se utilizaron ampliamente más adelante.

En los inicios de los mainframes de IBM, el software era gratuito y se incluía sin coste adicional con el hardware . El sistema operativo OS/360 y el software de soporte de aplicaciones, como CICS, eran de acceso libre para los clientes de IBM mucho antes de la iniciativa de software de código abierto . Empresas como Standard Oil de Indiana (Amoco) realizaron importantes contribuciones a CICS. 

El equipo de IBM Des Plaines intentó añadir compatibilidad con terminales populares que no eran de IBM, como el Teletipo ASCII Modelo 33 ASR, pero el pequeño equipo de desarrollo de software, con un presupuesto reducido, no podía permitirse el hardware de 100 dólares al mes necesario para probarlo. Los ejecutivos de IBM creían erróneamente que el futuro sería como el pasado, con el procesamiento por lotes utilizando tarjetas perforadas tradicionales .

IBM, a regañadientes, proporcionó 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 IBM Airline Control de 1965 utilizado por el sistema de reservas informáticas Sabre de American Airlines ) para el acceso y la actualización de datos de alta velocidad a la información del cliente para sus operadores telefónicos (sin tener que esperar a los sistemas de tarjetas perforadas de procesamiento por lotes nocturno).

Cuando CICS se entregó a Amoco con soporte para el Teletype Model 33 ASR, provocó el fallo de todo el sistema operativo OS/360 (incluidos los programas de aplicación que no eran de CICS). La mayor parte del Programa de Control de Terminales de CICS (TCP , el núcleo de CICS) y parte de OS/360 tuvieron que ser rediseñados y reescritos minuciosamente por Amoco Production Company en Tulsa, Oklahoma. Posteriormente, se devolvió a IBM para su distribución gratuita. 

El Sistema de Control de Información del Cliente (CICS) es uno de los productos de software de IBM con mayor éxito comercial. En los años posteriores a su lanzamiento, el monitor de procesamiento de transacciones se convirtió en un pilar fundamental de la estrategia de mainframes de IBM, generando finalmente más de 60 mil millones de dólares en ingresos por hardware. Al facilitar el procesamiento de transacciones de alto volumen y confiable, CICS consolidó su posición como un componente crítico del entorno informático empresarial y sigue siendo un motor clave del ecosistema de mainframes de IBM.

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 principal arquitecto de las primeras versiones), 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 producto generador de ingresos hasta que la ley federal exigió la desagregación del software . En 1980, los ejecutivos de IBM no tuvieron en cuenta las firmes sugerencias de Ben Riggins de que IBM proporcionara su propio sistema operativo basado en EBCDIC y un chip microprocesador de circuito integrado para su uso en la IBM Personal Computer como terminal inteligente CICS (en lugar del chip Intel incompatible y el MS-DOS relativamente inmaduro ).

Debido a la capacidad limitada incluso de los procesadores más potentes de aquella época, cada instalación de CICS requería el ensamblaje del código fuente de todos los módulos del sistema CICS tras completar un proceso similar a la generación del sistema (sysgen), denominado CICSGEN , para establecer los valores de las sentencias condicionales en lenguaje ensamblador. Este proceso permitía a cada cliente excluir de CICS cualquier función que no tuviera intención de utilizar, como la compatibilidad con dispositivos de tipos de terminal que no se utilizaban.

CICS debe su popularidad inicial a su implementación relativamente eficiente cuando el hardware era muy caro, a su arquitectura de procesamiento multihilo, a su relativa simplicidad para desarrollar aplicaciones de transacciones en tiempo real basadas en terminales y a las numerosas contribuciones de código abierto de los clientes, que incluyen tanto la depuración como la mejora de funciones.

Parte de CICS se formalizó utilizando la notación Z en las décadas de 1980 y 1990 en colaboración con el Laboratorio de Computación de la Universidad de Oxford , dirigido por Tony Hoare . Ib Holm Sørensen dirigió el Proyecto de Procesamiento de Transacciones en la Universidad de Oxford , desde su inicio en 1982 (posteriormente renombrado como Proyecto CICS ^{[ 6 ]} ), en colaboración con IBM Hursley . ^{[ 7 ]} Este trabajo ganó un Premio de la Reina al Logro Tecnológico en 1992. ^{[ 8 ] [ 9 ]} Como parte del proyecto CICS, Sørensen extendió el Lenguaje de Comandos Protegidos de Edsger Dijkstra al permitir el uso de la notación de esquema Z como comandos abstractos. ^{[ 10 ]}

En 1986, IBM anunció la compatibilidad de CICS con 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 anteriormente solo estaban disponibles dentro de los entornos de procesamiento de transacciones CICS/MVS y CICS/VSE. ^{[ 11 ]}

En versiones más recientes de CICS, se eliminó la compatibilidad con DDM. La compatibilidad con el componente DDM de CICS z/OS se suspendió a finales de 2003 y se eliminó de CICS para z/OS a partir de la versión 5.2. ^{[ 12 ]} En CICS TS para z/VSE, la compatibilidad con DDM se estabilizó en el nivel V1.1.1, con la intención anunciada de suspenderla en una versión futura. ^{[ 13 ]} A partir de CICS para z/VSE 2.1, CICS/DDM no es compatible. ^{[ 14 ]}

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 encapsular programas basados ​​en terminales de pantalla verde con una interfaz HTML . Las API web y de documentos de CICS se mejoraron en CICS TS V1.3 para permitir que las aplicaciones web interactuaran de forma más eficaz con los navegadores web.

Las versiones 2.1 a 2.3 de CICS TS se centraron en la introducción de las tecnologías CORBA y EJB en CICS, ofreciendo nuevas formas de integrar los recursos 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 de Java experimentó numerosas mejoras a lo largo de varias versiones. Se introdujo un recurso JVM multihilo llamado JVMSERVER durante el lanzamiento de la versión 4.1 de CICS TS, que se mejoró aún más para utilizar 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. Numerosas tecnologías orientadas a la web podí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 incorporó 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 dos tecnologías facilitaron la integración de los componentes de CICS con otras aplicaciones empresariales y tuvieron una amplia acogida. Se incluyeron herramientas para convertir programas tradicionales de CICS escritos en lenguajes como COBOL en servicios web definidos por WSDL, con pocos o ningún cambio en el código. Esta tecnología se mejoró periódicamente en las sucesivas versiones de CICS.

Las versiones 4.1 y 4.2 de CICS TS 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 recientes se pusieron a disposición en versiones anteriores de CICS mediante modelos de entrega distintos al lanzamiento tradicional de un producto. Esto permitió a los primeros usuarios proporcionar comentarios constructivos que influyeron en el diseño final de la tecnología integrada. Algunos ejemplos son el paquete de soporte de la versión preliminar de Soap para CICS (TS V2.2) o el paquete de soporte de ATOM para TS V3.1. Este enfoque se utilizó para introducir la compatibilidad con JSON en CICS TS V4.2, tecnología que posteriormente se integró en CICS TS V5.2.

La tecnología JSON en CICS es similar a la tecnología SOAP anterior , ambas permitieron que los programas alojados en CICS se integraran con una interfaz moderna. La tecnología JSON se mejoró posteriormente en z/OS Connect Enterprise Edition, un producto de IBM para la creación de API JSON que pueden aprovechar los recursos de varios subsistemas de mainframe.

También se han utilizado muchos productos de socios 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 los dispositivos IBM DataPower para filtrar el tráfico web antes de que llegue a CICS.

Las versiones modernas de CICS ofrecen numerosas maneras de integrar tanto los recursos de software existentes como los nuevos en flujos de aplicaciones distribuidas. Se puede acceder a los recursos de CICS desde sistemas remotos y, a su vez, acceder a ellos; se puede propagar la identidad del usuario y el contexto transaccional; se pueden componer y gestionar API RESTful; los dispositivos, usuarios y servidores pueden interactuar con CICS mediante tecnologías basadas en estándares; y el entorno IBM WebSphere Liberty de CICS fomenta la rápida adopción de nuevas tecnologías.

En enero de 1985, una empresa de consultoría 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 convertiría en MicroCICS . ^{[ 15 ]} El enfoque inicial fue el IBM XT/370 y el IBM AT/370 . ^{[ 16 ]}

Si bien cuando se menciona CICS, la gente suele referirse a CICS Transaction Server, la familia CICS hace referencia a una cartera de servidores de transacciones, conectores (denominados CICS Transaction Gateway) y herramientas CICS.

CICS en plataformas distribuidas —no en mainframes— se llama IBM TXSeries . TXSeries es un middleware de procesamiento de transacciones distribuidas . Admite aplicaciones en C, C++ , COBOL, Java™ y PL/I en entornos de nube y centros de datos tradicionales. TXSeries está disponible en las plataformas AIX , Linux x86, Windows , Solaris y HP-UX . ^{[ 17 ]} CICS también está disponible en otros sistemas operativos, en particular IBM i y OS/2 . La implementación para z/OS (es decir, CICS Transaction Server para z/OS) es, con diferencia, la más popular e importante.

Anteriormente, existían dos versiones de CICS disponibles para VM/CMS , pero ambas fueron descontinuadas. En 1986, IBM lanzó CICS/CMS , ^{[ 18 ] [ 15 ]} una versión de CICS para un solo usuario diseñada para el desarrollo, cuyas aplicaciones se transferían posteriormente a un sistema MVS o DOS/VS para su ejecución en producción. ^{[ 19 ] [ 20 ]} Más tarde, en 1988, IBM lanzó CICS/VM . ^{[ 21 ] [ 22 ]} CICS/VM estaba destinado a ser utilizado en el IBM 9370 , un mainframe de gama baja dirigido al uso departamental; IBM posicionó CICS/VM ejecutándose en mainframes departamentales o de sucursales para su uso junto con un mainframe central que ejecutaba CICS para MVS. ^{[ 23 ]}

Las herramientas CICS permiten el aprovisionamiento, la gestión y el análisis de sistemas y aplicaciones CICS. Esto incluye la gestión del rendimiento, así como el despliegue y la gestión de los recursos CICS. En 2015, las cuatro herramientas CICS fundamentales (y el paquete de soluciones de optimización CICS para z/OS) se actualizaron con el lanzamiento de CICS Transaction Server para z/OS 5.3. Las cuatro herramientas CICS principales son: 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:

Los programas de aplicación de transacciones interactivas multiusuario debían ser cuasi reentrantes para admitir múltiples hilos de transacción concurrentes. Un error de codificación en una aplicación podía bloquear el acceso de todos los usuarios al sistema. El diseño modular de los programas de control reentrantes/reutilizables de CICS permitía que, con una selección adecuada, se pudieran ejecutar múltiples usuarios con múltiples aplicaciones en un ordenador con tan solo 32 KB de costosa memoria física de núcleo magnético (incluido el sistema operativo ).

Los programadores de aplicaciones CICS debían realizar un esfuerzo considerable para optimizar al máximo sus transacciones. Una técnica común consistía en limitar el tamaño de los programas individuales a no más de 4096 bytes (4 KB), de modo que CICS pudiera reutilizar fácilmente la memoria ocupada por cualquier programa que no estuviera en uso para otro programa o para las necesidades de almacenamiento de otras aplicaciones. Cuando se incorporó la memoria virtual a las versiones de OS/360 en 1972, la estrategia de los 4 KB cobró aún más importancia para reducir la sobrecarga improductiva de paginación y contención de recursos.

La eficiencia de los programas compilados en lenguajes COBOL y PL/I de alto nivel dejaba mucho que desear. Muchos programas de aplicación de CICS continuaron escribiéndose en lenguaje ensamblador, incluso después de que se dispusiera de soporte para COBOL y PL/I.

Debido a que los recursos de hardware de las décadas de 1960 y 1970 eran costosos y escasos, se desarrolló un "juego" competitivo entre los analistas de optimización de sistemas. Cuando se identificaba el código de la ruta crítica , un fragmento de código se pasaba de un analista a otro. Cada persona debía (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 los mentores con más experiencia. Finalmente, cuando nadie podía lograr (a) o (b), el código se consideraba optimizado y pasaban a otros fragmentos. Las empresas pequeñas con un solo analista aprendían la optimización de CICS muy lentamente (o nunca la aprendían).

Debido a que los programas de aplicación podían ser compartidos por muchos subprocesos concurrentes , el uso de variables estáticas integradas en un programa (o el uso de la memoria del sistema operativo) estaba restringido (únicamente por convención).

Lamentablemente, muchas de las "reglas" se infringían con frecuencia, especialmente por programadores de COBOL que quizás desconocían el funcionamiento interno de sus programas o no utilizaban las opciones de compilación restrictivas necesarias . Esto generaba código "no reentrante" que a menudo era poco fiable, lo que provocaba errores de almacenamiento y fallos completos del sistema CICS.

Originalmente, toda la partición , o región de Almacenamiento Virtual Múltiple (MVS), operaba con la misma clave de protección de memoria, incluido el código del núcleo CICS. La corrupción de programas y de bloques de control CICS era una causa frecuente 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 en ejecución. Localizar el código de la aplicación que causaba errores de temporización transitorios complejos podía ser un problema muy difícil para un analista de sistemas operativos.

Estas deficiencias persistieron en múltiples versiones de CICS durante más de 20 años, a pesar de su gravedad y de la alta demanda y escasez de profesionales altamente cualificados en CICS. Se abordaron en las versiones TS V3.3, V4.1 y V5.2 con las funciones de Protección de Almacenamiento, Aislamiento de Transacciones y Subespacio, respectivamente, que utilizan las 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 hayan diseñado para estar separadas. Las transacciones de las aplicaciones CICS siguen siendo de vital importancia para muchas empresas de servicios públicos, grandes bancos y otras instituciones financieras multimillonarias.

Cuando se lanzó CICS por primera vez, solo admitía programas de transacciones de aplicaciones escritos en IBM 360 Assembler . La compatibilidad con COBOL y PL/I se añadió años después. Debido a su orientación inicial al lenguaje ensamblador, las solicitudes de servicios de CICS se realizaban mediante macros en lenguaje ensamblador . Por ejemplo, la solicitud para leer un registro de un archivo se realizaba mediante una llamada a la macro "Programa de control de archivos" de CICS, que podría tener este aspecto:

DFHFC TIPO=LECTURA,CONJUNTO DE DATOS=miarchivo,TIPOPER=ACTUALIZACIÓN,....etc.

Esto dio origen a la terminología posterior de " CICS a nivel macro ".

Cuando se añadió compatibilidad con lenguajes de alto nivel, se conservaron las macros y el código se convirtió mediante un precompilador que las expandió a sus equivalentes en sentencias CALL de COBOL o PL/I. De este modo, la preparación de una aplicación HLL se convertía, en la práctica, en una compilación en dos etapas: la salida del preprocesador se introducía en el compilador HLL como entrada. 

Consideraciones sobre COBOL : a diferencia de PL/I, IBM COBOL normalmente no permite la manipulación de punteros (direcciones). Para que los programadores de COBOL pudieran acceder a los bloques de control y al almacenamiento dinámico de CICS, los diseñadores recurrieron a una solución poco ortodoxa. 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 denominada Localizador Base para Enlace (BLL), que se establecían 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 del programa. Los BLL pueden entonces establecerse 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. ^{[ 40 ]}

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 a nivel de comandos", que seguía siendo compatible con los programas 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 tener el siguiente aspecto:

EXEC CICS SEND MAPSET ( 'LOSMATT' ) MAP ( 'LOSATT' ) END-EXEC

Los valores proporcionados en el comando SEND MAPSET corresponden a los nombres utilizados en la primera macro DFHMSD de la definición de mapa que se muestra a continuación para el argumento MAPSET, y en 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 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 a nivel de macro como a nivel de comando.

Inicialmente, durante la ejecución, los comandos a nivel de comando se convertían, mediante un traductor en tiempo de ejecución, el "Programa de Interfaz EXEC", a la antigua llamada a nivel de macro, que luego era ejecutada por los programas centrales de CICS, que permanecían prácticamente sin cambios. Sin embargo, cuando el núcleo de CICS se reescribió para TS V3, EXEC CICS se convirtió en la única forma de programar aplicaciones CICS, dado que muchas de las interfaces subyacentes habían cambiado.

La versión de CICS que solo admitía comandos , introducida a principios de la década de 1990, ofrecía algunas ventajas sobre las versiones anteriores. Sin embargo, IBM también dejó de dar soporte a los programas de aplicación de nivel macro escritos para versiones anteriores. Esto significó que muchos programas de aplicación tuvieron que ser convertidos o reescritos por completo para usar únicamente comandos EXEC de nivel de comando.

Para entonces, existían probablemente millones de programas en todo el mundo que llevaban décadas en producción en muchos casos. Reescribirlos a menudo introducía nuevos errores sin necesariamente añadir nuevas funcionalidades. Un número significativo de usuarios que gestionaban regiones propietarias de aplicaciones (AOR) de CICS V2 continuaron ejecutando código macro durante muchos años después del cambio a la versión V3.

También era posible ejecutar programas antiguos a nivel de macro utilizando software de conversión como Command CICS de APT International . ^{[ 41 ]}

Las recientes mejoras de CICS Transaction Server incluyen compatibilidad con varios estilos de programación modernos.

CICS Transaction Server versión 5.6 ^{[ 42 ]} introdujo soporte mejorado para Java para brindar una experiencia nativa en la nube a los desarrolladores de Java. Por ejemplo, la nueva API de Java de CICS ( JCICSX ) permite pruebas unitarias más sencillas mediante enfoques de simulación y stubing, y se puede ejecutar de forma remota en la estación de trabajo local del desarrollador. Un conjunto de artefactos de CICS en Maven Central permite a los desarrolladores resolver dependencias de Java utilizando herramientas populares de gestió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 compilación automatizada de paquetes CICS, utilizando IDE conocidos como Eclipse , IntelliJ IDEA y Visual Studio Code . Además, se mejoró el soporte para Node.js z/OS en la versión 12, lo que proporciona un inicio más rápido, mejores límites de heap predeterminados, actualizaciones del motor JavaScript V8, etc. También se incluye soporte para Jakarta EE 8.

CICS TS 5.5 introdujo la compatibilidad con IBM SDK para Node.js, proporcionando un entorno de ejecución completo de JavaScript, API del lado del servidor y bibliotecas para crear de manera eficiente aplicaciones de red de alto rendimiento y altamente escalables para IBM Z.

La versión 2.1 de CICS Transaction Server introdujo la compatibilidad con Java. La versión 2.2 de CICS Transaction Server incorporó la compatibilidad con el 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 existe un conjunto común de herramientas para el desarrollo e implementación de aplicaciones Java EE.

Además, CICS hizo hincapié en la integración de programas de aplicación existentes en interfaces modernas, de modo que las funciones empresariales tradicionales puedan incorporarse a servicios más modernos. Esto incluye interfaces WSDL, SOAP y JSON que encapsulan el código heredado, permitiendo que una aplicación web o móvil obtenga y actualice los objetos empresariales principales sin necesidad de reescribir en gran medida las funciones de back-end.

El soporte de mapeo básico define el formato de pantalla mediante macros de ensamblador como la siguiente. Esto se ensambló para generar tanto el conjunto de mapas físicos ( un módulo de carga en una biblioteca de carga de 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. ^{[ 43 ]}   

LOSMATT DFHMSD TIPO = MAPA , X MODO = ENTRADA /SALIDA , X TIOAPFX = SÍ , X TERMINAL = 3270 - 2 , X LENGUAJE = COBOL , X MAPATTS = ( COLOR , RESALTE ), X DSATTS = ( COLOR , RESALTE ), X ALMACENAMIENTO = AUTOMÁTICO , X CTRL = ( FREEKB , FRSET ) * LOSATT DFHMDI TAMAÑO = ( 24 , 80 ), X LÍNEA = 1 , X COLUMNA = 1 * LSSTDII DFHMDF POSICIÓN = ( 1 , 01 ), X LONGITUD = 04 , X COLOR = AZUL , X INICIAL = 'MQCM' , X ATTRB = PROT * DFHMDF POSICIÓN = ( 24 , 01 ), X LONGITUD = 79 , X COLOR = AZUL X ATTRB = SALTAR , X INICIAL = 'PF7- 8- 9- 10- X 11 - 12 - CANCELAR ' * DFHMSD TIPO = FINAL FIN

El núcleo original de CICS consistía en una serie de módulos funcionales escritos en lenguaje ensamblador 370 hasta la versión 3:

• Programa de Control de Tareas (KCP)
• Programa de Control de Almacenamiento (PCA)
• Programa de Control de Programas (PCP)
• Programa de control de interrupciones del programa (PIP)
• Programa de Control por Intervalos (PCI)
• Programa de Control de Vertidos (DCP)
• Programa de Control de Terminal (TCP)
• Programa de Control de Archivos (FCP)
• Programa de control de datos transitorios (TDP)
• Programa de Control de Almacenamiento Temporal (TSP)

A partir de la versión 3, el núcleo de CICS se reescribió en una estructura de kernel y dominio utilizando el lenguaje PL/AS de IBM , que se compila en lenguaje ensamblador. 

La estructura anterior no garantizaba la separación de responsabilidades, lo que generaba numerosas dependencias entre programas y, por consiguiente, errores a menos que se realizara un análisis exhaustivo del código. La nueva estructura era más modular y, por lo tanto, más robusta, ya que resultaba más fácil modificarla sin afectar su funcionamiento. Los primeros dominios solían crearse 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 núcleo funcionaba como un conmutador para las solicitudes entre dominios ; inicialmente, esto resultaba costoso para los dominios de uso frecuente (como Trace), pero mediante el uso de macros PL/AS, estas llamadas se integraban en el código sin comprometer el diseño de dominios separados. 

En versiones posteriores, se añadieron dominios completamente rediseñados, como el Dominio de Registro DFHLG y el Dominio de Transacciones DFHTM, que sustituyeron al Programa de Control de Diario (JCP).

Además de las funciones en línea, CICS cuenta con varios programas de soporte que se ejecutan como trabajos por lotes. ^{[ 52 ] : pp.34–35}

• Preprocesador de lenguaje de alto nivel (macro)
• Traductor de lenguaje de comandos
• Utilidad de volcado : imprime volcados formateados generados por la gestión de volcados de CICS.
• Utilidad de rastreo : formatea e imprime la salida de rastreo de CICS.
• Utilidad de formato de diario : imprime un volcado formateado de la región CICS en caso de error. 

Los siguientes componentes de CICS dan soporte al desarrollo de aplicaciones. ^{[ 52 ] : pp.35–37}

• El soporte de mapeo básico (BMS) proporciona entrada y salida de terminal independientes del dispositivo.
• Soporte APPC que proporciona soporte para las API LU6.1 y LU6.2 para aplicaciones distribuidas colaborativas que admiten la confirmación en dos fases.
• El programa de intercambio de datos (DIP) ofrece soporte para los dispositivos programables IBM 3770 e IBM 3790.
• La compatibilidad con el modelo 2260 permite que los programas escritos para dispositivos de visualización IBM 2260 se ejecuten en pantallas 3270.
• Programa de interfaz EXEC : el programa auxiliar que convierte las llamadas generadas por comandos en llamadas a funciones de CICS. EXEC CICS
• Funciones integradas : búsqueda en tabla, conversión fonética, verificación de campos, edición de campos, comprobación de bits, formato de entrada, recuperación ponderada.