CICS

IBM CICS ( Customer Information Control System ) ist eine Familie von Anwendungsservern mit gemischten Programmiersprachen , die Online- Transaktionsmanagement und Konnektivität für Anwendungen auf IBM-Großrechnersystemen unter z/OS und z/VSE bieten .

Die Produkte der CICS-Familie sind als Middleware konzipiert und unterstützen die schnelle Online-Transaktionsverarbeitung großer Datenmengen . Eine CICS- Transaktion ist eine Verarbeitungseinheit, die durch eine einzelne Anfrage initiiert wird und ein oder mehrere Objekte betreffen kann. ^{[ 2 ]} Diese Verarbeitung erfolgt üblicherweise interaktiv (bildschirmorientiert), aber auch Hintergrundtransaktionen sind möglich.

Der CICS Transaction Server (CICS TS) bildet die zentrale Komponente der CICS-Familie und stellt Dienste bereit, die die Funktionen des Betriebssystems erweitern oder ersetzen. Diese Dienste können effizienter als die allgemeinen Betriebssystemdienste sein und sind für Programmierer einfacher zu verwenden, insbesondere im Hinblick auf die Kommunikation mit verschiedenen Endgeräten.

Für CICS entwickelte Anwendungen können in verschiedenen Programmiersprachen geschrieben werden und nutzen von CICS bereitgestellte Spracherweiterungen, um mit Ressourcen wie Dateien, Datenbankverbindungen und Terminals zu interagieren oder Funktionen wie Webdienste aufzurufen. CICS verwaltet die gesamte Transaktion, sodass im Falle eines Fehlers alle wiederherstellbaren Änderungen rückgängig gemacht werden können.

Während CICS TS vor allem bei großen Finanzinstituten wie Banken und Versicherungen weit verbreitet ist, nutzen auch viele Fortune-500- Unternehmen und Regierungsbehörden CICS. Kleinere Unternehmen setzen ebenfalls auf CICS TS und andere Produkte der CICS-Familie. CICS ist regelmäßig im Hintergrund zu finden, beispielsweise in Bankautomaten-Anwendungen, Geldautomatensystemen , industriellen Produktionssteuerungssystemen, Versicherungsanwendungen und vielen anderen interaktiven Anwendungen.

Die jüngsten Verbesserungen von CICS TS umfassen neue Funktionen zur Optimierung der Entwicklererfahrung, darunter die Auswahl von APIs, Frameworks, Editoren und Build-Tools. Gleichzeitig wurden Aktualisierungen in den Schlüsselbereichen Sicherheit, Ausfallsicherheit und Management bereitgestellt. In früheren CICS TS-Versionen wurde bereits Unterstützung für Webdienste und Java , Ereignisverarbeitung , Atom -Feeds und RESTful -Schnittstellen eingeführt.

CICS wurde von einem früheren, einsträngigen Transaktionsverarbeitungssystem , IBM MTCS, abgelöst . Später wurde eine „MTCS-CICS-Brücke“ entwickelt, um die Ausführung dieser Transaktionen unter CICS ohne Änderungen an den ursprünglichen Anwendungsprogrammen zu ermöglichen. IBMs Customer Information Control System (CICS) wurde 1966 in Zusammenarbeit mit Michigan Bell entwickelt. ^{[ 3 ]} Ben Riggins war IBM-Systemingenieur bei Virginia Electric Power Co., als er die Idee für das Online-System entwickelte. ^{[ 4 ]}

CICS wurde ursprünglich in den USA, genauer gesagt im IBM-Entwicklungszentrum in Des Plaines, Illinois , entwickelt. Die Entwicklung begann 1966, um den Anforderungen der Energieversorgungsbranche gerecht zu werden. Das erste CICS-Produkt, das Public Utility Customer Information Control System (PU-CICS), wurde 1968 angekündigt. Schnell zeigte sich jedoch, dass es auch in vielen anderen Branchen Anwendung finden konnte. Daher wurde der Zusatz „Public Utility“ mit der Veröffentlichung der ersten Version des CICS- Programmprodukts am 8. Juli 1969, kurz nach dem Datenbankmanagementsystem IMS , weggelassen .

In den folgenden Jahren wurde CICS in Palo Alto weiterentwickelt und galt als weniger wichtiges, „kleineres“ Produkt im Vergleich zu IMS, das IBM damals als strategisch wichtiger einstufte. Der Kundendruck sicherte jedoch das Fortbestehen von CICS. Als IBM 1974 beschloss, die Entwicklung von CICS einzustellen, um sich auf IMS zu konzentrieren, übernahm der IBM-Standort Hursley in Großbritannien die Verantwortung für die CICS-Entwicklung. Dieser hatte die Arbeit am PL/I -Compiler gerade abgeschlossen und kannte daher viele der gleichen Kunden wie CICS. Die Kernentwicklung wird bis heute in Hursley fortgeführt, unterstützt durch Beiträge von IBM-Laboren in Indien und den USA.

CICS unterstützte ursprünglich nur wenige IBM-Geräte, wie beispielsweise das 1965 erschienene, auf einer Schreibmaschine basierende Terminal IBM 2741 Selectric (Golfball-Terminal). Die Videoterminals IBM 2260 ( 1964) und IBM 3270 (1972) fanden später weite Verbreitung.

In den Anfängen der IBM-Großrechner war die Computersoftware kostenlos – sie war ohne Aufpreis in der Hardware enthalten . Das Betriebssystem OS/360 und Anwendungssoftware wie CICS waren für IBM-Kunden schon lange vor der Open-Source- Initiative frei zugänglich. Unternehmen wie Standard Oil of Indiana (Amoco) leisteten wichtige Beiträge zu CICS.

Das IBM-Team in Des Plaines versuchte, Unterstützung für gängige Fremdgeräte wie den ASCII- Fernschreiber Modell 33 ASR zu integrieren, doch das kleine, budgetschwache Softwareentwicklungsteam konnte sich die Hardwarekosten von 100 US-Dollar pro Monat für die Tests nicht leisten. Die IBM-Führungskräfte gingen fälschlicherweise davon aus, dass die Zukunft wie die Vergangenheit sein würde, mit Stapelverarbeitung mittels herkömmlicher Lochkarten .

IBM stellte nur widerwillig minimale Mittel zur Verfügung, als Versorgungsunternehmen, Banken und Kreditkartenfirmen ein kosteneffektives interaktives System (ähnlich dem IBM Airline Control Program von 1965 , das vom Sabre -Computerreservierungssystem der American Airlines verwendet wurde ) für den schnellen Datenzugriff und die Aktualisierung von Kundendaten für ihre Telefonisten forderten (ohne auf die nächtliche Stapelverarbeitung von Lochkartensystemen warten zu müssen).

Als CICS mit Unterstützung für Teletype Model 33 ASR an Amoco ausgeliefert wurde, stürzte das gesamte Betriebssystem OS/360 ab (einschließlich aller Nicht-CICS-Anwendungen). Der Großteil des CICS-Terminalsteuerungsprogramms (TCP – das Herzstück von CICS) und Teile von OS/360 mussten von der Amoco Production Company in Tulsa, Oklahoma, aufwendig neu entwickelt und geschrieben werden. Anschließend wurde es an IBM zur kostenlosen Weitergabe zurückgegeben.

Das Customer Information Control System (CICS) zählt zu den kommerziell erfolgreichsten Softwareprodukten von IBM. In den Jahren nach seiner Einführung entwickelte sich der Transaktionsverarbeitungsmonitor zu einem Eckpfeiler der IBM-Mainframe-Strategie und generierte letztendlich über 60 Milliarden US-Dollar an Hardware-Umsätzen. Durch die Ermöglichung einer zuverlässigen Verarbeitung großer Transaktionsvolumina festigte CICS seine Position als kritische Komponente der Unternehmens-IT-Landschaft und ist nach wie vor ein Haupttreiber des IBM-Mainframe-Ökosystems.

1972 war CICS in drei Versionen erhältlich: DOS-ENTRY (Programmnummer 5736-XX6) für DOS/360- Rechner mit sehr begrenztem Speicher, DOS-STANDARD (Programmnummer 5736-XX7) für DOS/360-Rechner mit mehr Speicher und OS-Standard v2 (Programmnummer 5734-XX7) für die größeren Rechner, auf denen OS/360 lief. ^{[ 5 ]}

Anfang 1970 zogen einige der ursprünglichen Entwickler, darunter Ben Riggins (der Hauptarchitekt der frühen Versionen), nach Kalifornien und setzten die CICS-Entwicklung im IBM- Entwicklungszentrum in Palo Alto fort . IBM-Manager erkannten den Wert von Software als umsatzgenerierendes Produkt erst, nachdem ein Bundesgesetz die Entbündelung von Software vorschrieb. 1980 ignorierten sie Ben Riggins' dringende Empfehlung, ein eigenes EBCDIC -basiertes Betriebssystem und einen eigenen Mikroprozessor für den Einsatz im IBM Personal Computer als intelligentes CICS-Terminal (anstelle des inkompatiblen Intel-Chips und des vergleichsweise unausgereiften MS-DOS ) bereitzustellen .

Aufgrund der begrenzten Kapazität selbst großer Prozessoren jener Zeit musste bei jeder CICS-Installation der Quellcode für alle CICS-Systemmodule kompiliert werden. Dies geschah nach einem Prozess ähnlich der Systemgenerierung (sysgen), genannt CICSGEN , um Werte für bedingte Assembler-Anweisungen festzulegen. Dadurch konnte jeder Kunde die Unterstützung von CICS für nicht benötigte Funktionen, wie beispielsweise die Geräteunterstützung für nicht verwendete Terminaltypen, ausschließen.

CICS verdankt seine frühe Popularität seiner vergleichsweise effizienten Implementierung in Zeiten, als Hardware sehr teuer war, seiner Multithread-Verarbeitungsarchitektur, seiner relativen Einfachheit bei der Entwicklung terminalbasierter Echtzeit-Transaktionsanwendungen und zahlreichen Open-Source-Beiträgen von Kunden, darunter sowohl Debugging- als auch Funktionserweiterungen.

Ein Teil von CICS wurde in den 1980er und 1990er Jahren in Zusammenarbeit mit dem Oxford University Computing Laboratory unter der Leitung von Tony Hoare mithilfe der Z-Notation formalisiert . Ib Holm Sørensen leitete das Transaction Processing Project an der Universität Oxford von dessen Beginn im Jahr 1982 an (später umbenannt in CICS-Projekt ^{[ 6 ]} ), in Zusammenarbeit mit IBM Hursley . ^{[ 7 ]} Diese Arbeit wurde 1992 mit dem Queen’s Award for Technological Achievement ausgezeichnet. ^{[ 8 ] [ 9 ]} Im Rahmen des CICS-Projekts erweiterte Sørensen Edsger Dijkstras Guarded Command Language , indem er die Verwendung der Z-Schema-Notation als abstrakte Befehle ermöglichte. ^{[ 10 ]}

1986 kündigte IBM die CICS-Unterstützung für die datensatzorientierten Dateidienste der Distributed Data Management Architecture (DDM) an. Dies ermöglichte es Programmen auf entfernten, netzwerkverbundenen Rechnern, Dateien zu erstellen, zu verwalten und darauf zuzugreifen, die zuvor nur in den Transaktionsverarbeitungsumgebungen CICS/MVS und CICS/VSE verfügbar waren. ^{[ 11 ]}

In neueren CICS-Versionen wurde die Unterstützung für DDM entfernt. Die Unterstützung für die DDM-Komponente von CICS z/OS wurde Ende 2003 eingestellt und ab Version 5.2 aus CICS für z/OS entfernt. ^{[ 12 ]} In CICS TS für z/VSE wurde die DDM-Unterstützung ab Version 1.1.1 stabilisiert, mit der angekündigten Absicht, sie in einer zukünftigen Version einzustellen. ^{[ 13 ]} Ab CICS für z/VSE 2.1 wird CICS/DDM nicht mehr unterstützt. ^{[ 14 ]}

Der CICS Transaction Server führte in Version 1.2 erstmals eine native HTTP- Schnittstelle sowie eine Web-Bridge-Technologie ein, um terminalbasierte Programme mit grüner Bildschirmdarstellung in eine HTML-Oberfläche zu integrieren. Die CICS Web- und Dokument-APIs wurden in CICS TS V1.3 erweitert, um die Entwicklung webfähiger Anwendungen zu ermöglichen, die effektiver mit Webbrowsern interagieren.

Die CICS TS-Versionen 2.1 bis 2.3 konzentrierten sich auf die Einführung von CORBA- und EJB- Technologien in CICS und boten neue Möglichkeiten zur Integration von CICS-Ressourcen in verteilte Anwendungskomponentenmodelle. Diese Technologien basierten auf dem Hosting von Java- Anwendungen in CICS. Die Java-Hosting-Umgebung wurde über mehrere Releases hinweg mehrfach verbessert. Mit CICS TS Version 4.1 wurde eine Multithread-fähige JVM-Ressource namens JVMSERVER eingeführt, die in Version 5.1 auf 64-Bit-JVM-Technologie umgestellt wurde. Version 5.1 führte außerdem den WebSphere Liberty Profile Webcontainer ein. Schließlich wurde WebSphere Liberty in Version 5.3 vollständig in den CICS Transaction Server integriert. Zahlreiche webbasierte Technologien konnten nun mithilfe von Java in CICS gehostet werden, was letztendlich zur Abschaffung der nativen CORBA- und EJB-Technologien führte.

CICS TS V3.1 führte eine native Implementierung der SOAP- und WSDL -Technologien für CICS sowie clientseitige HTTP-APIs für die ausgehende Kommunikation ein. Diese beiden Technologien ermöglichten eine einfachere Integration von CICS-Komponenten in andere Unternehmensanwendungen und fanden weite Verbreitung. Es wurden Tools bereitgestellt, mit denen sich herkömmliche CICS-Programme, die in Sprachen wie COBOL geschrieben waren , mit geringem oder gar keinem Programmänderungsaufwand in WSDL-definierte Webdienste konvertieren ließen. Diese Technologie wurde in den nachfolgenden CICS-Versionen regelmäßig verbessert.

Mit CICS TS V4.1 und V4.2 wurden weitere Verbesserungen der Webkonnektivität erzielt, darunter eine native Implementierung des Atom -Veröffentlichungsprotokolls.

Viele der neueren webbasierten Technologien wurden für frühere CICS-Versionen über alternative Bereitstellungsmodelle abseits der traditionellen Produktveröffentlichung bereitgestellt. Dies ermöglichte es frühen Anwendern, konstruktives Feedback zu geben, das die endgültige Gestaltung der integrierten Technologie beeinflussen konnte. Beispiele hierfür sind die SOAP-Technologievorschau SupportPac für TS V2.2 oder der ATOM SupportPac für TS V3.1. Mit diesem Ansatz wurde die JSON- Unterstützung für CICS TS V4.2 eingeführt – eine Technologie, die später in CICS TS V5.2 integriert wurde.

Die JSON- Technologie in CICS ähnelt der früheren SOAP- Technologie. Beide ermöglichten es, in CICS ausgeführte Programme mit einer modernen Benutzeroberfläche zu versehen. Die JSON-Technologie wurde wiederum in z/OS Connect Enterprise Edition, einem IBM-Produkt zur Erstellung von JSON-APIs, das Ressourcen aus verschiedenen Mainframe-Subsystemen nutzen kann, weiterentwickelt.

Viele Partnerprodukte wurden ebenfalls zur Interaktion mit CICS eingesetzt. Gängige Beispiele hierfür sind die Verwendung des CICS Transaction Gateways für die Verbindung von JCA- kompatiblen Java-Anwendungsservern mit CICS sowie IBM DataPower Appliances zum Filtern des Webverkehrs , bevor dieser CICS erreicht.

Moderne CICS-Versionen bieten vielfältige Möglichkeiten zur Integration bestehender und neuer Software-Assets in verteilte Anwendungsabläufe. CICS-Assets können von entfernten Systemen aus aufgerufen werden und selbst auf entfernte Systeme zugreifen; Benutzeridentitäten und Transaktionskontexte können weitergegeben werden; RESTful-APIs lassen sich erstellen und verwalten; Geräte, Benutzer und Server können mithilfe standardbasierter Technologien mit CICS interagieren; und die IBM WebSphere Liberty-Umgebung in CICS fördert die schnelle Einführung neuer Technologien.

Im Januar 1985 kündigte ein 1969 gegründetes Beratungsunternehmen, das bereits umfangreiche Online-Systeme für Hilton Hotels, FTD Florists, Amtrak und Budget Rent-a-Car entwickelt hatte, die Gründung von MicroCICS an . ^{[ 15 ]} Der anfängliche Fokus lag auf den IBM XT/370 und IBM AT/370 . ^{[ 16 ]}

Wenn von CICS die Rede ist, meinen die meisten Menschen den CICS Transaction Server. Die CICS-Familie bezeichnet jedoch ein Portfolio von Transaktionsservern, Konnektoren (genannt CICS Transaction Gateway) und CICS-Tools.

CICS auf verteilten Plattformen – nicht auf Mainframes – heißt IBM TXSeries . TXSeries ist eine Middleware für die verteilte Transaktionsverarbeitung . Sie unterstützt Anwendungen in C, C++, COBOL, Java™ und PL/I in Cloud-Umgebungen und traditionellen Rechenzentren. TXSeries ist für die Plattformen AIX , Linux x86, Windows , Solaris und HP-UX verfügbar . ^{[ 17 ]} CICS ist auch für andere Betriebssysteme erhältlich, insbesondere für IBM i und OS/2 . Die z/OS-Implementierung (d. h. CICS Transaction Server für z/OS) ist mit Abstand die beliebteste und wichtigste.

Für VM/CMS waren zuvor zwei Versionen von CICS verfügbar , die jedoch beide inzwischen eingestellt wurden. 1986 veröffentlichte IBM CICS/CMS [ ^{18 ] [ 15 ] ,} eine Einzelplatzversion von CICS für Entwicklungszwecke. Die Anwendungen wurden später für den Produktiveinsatz auf ein MVS- oder DOS/VS- System übertragen. ^{[ 19 ] [ 20 ]} 1988 folgte CICS/VM . ^{[ 21 ] [ 22 ]} CICS/VM war für den Einsatz auf dem IBM 9370 vorgesehen , einem Low-End-Mainframe für den Einsatz in Abteilungen. IBM positionierte CICS/VM auf Abteilungs- oder Zweigstellen-Mainframes zur Verwendung in Verbindung mit einem zentralen Mainframe, auf dem CICS für MVS lief. ^{[ 23 ]}

Die Bereitstellung, Verwaltung und Analyse von CICS-Systemen und -Anwendungen erfolgt mithilfe der CICS-Tools. Dies umfasst sowohl das Performance-Management als auch die Bereitstellung und Verwaltung von CICS-Ressourcen. Im Jahr 2015 wurden die vier grundlegenden CICS-Tools (sowie das CICS Optimization Solution Pack für z/OS) mit der Veröffentlichung des CICS Transaction Server für z/OS 5.3 aktualisiert. Die vier grundlegenden CICS-Tools sind: CICS Interdependency Analyzer für z/OS, CICS Deployment Assistant für z/OS, CICS Performance Analyzer für z/OS und CICS Configuration Manager für z/OS.

CICS Transaction Server für z/OS hat die folgenden Versionsnummern verwendet:

Für die Unterstützung mehrerer gleichzeitiger Transaktionsthreads mussten interaktive Transaktionsanwendungen für mehrere Benutzer quasi - wiederverwendbar sein . Ein Software-Programmierfehler in einer Anwendung konnte alle Benutzer vom System ausschließen. Dank des modularen Aufbaus der wiederverwendbaren CICS-Steuerungsprogramme konnten durch gezieltes „Pruning“ mehrere Benutzer mit mehreren Anwendungen auf einem Computer mit nur 32 KB teurem Magnetkernspeicher (einschließlich Betriebssystem ) ausgeführt werden .

CICS-Anwendungsprogrammierer mussten erhebliche Anstrengungen unternehmen, um ihre Transaktionen so effizient wie möglich zu gestalten. Eine gängige Methode bestand darin, die Größe einzelner Programme auf maximal 4.096 Byte (4 KB) zu begrenzen, damit CICS den von nicht genutzten Programmen belegten Speicher problemlos für andere Programme oder andere Anwendungsspeicherbedürfnisse wiederverwenden konnte. Mit der Einführung des virtuellen Speichers in OS/360 im Jahr 1972 gewann die 4-KB-Strategie noch mehr an Bedeutung, um den durch unnötige Ressourcenkonflikte verursachten Overhead durch Paging und Thrashing zu reduzieren.

Die Effizienz kompilierter COBOL- und PL/I-Programme in höheren Programmiersprachen ließ zu wünschen übrig. Viele CICS-Anwendungsprogramme wurden weiterhin in Assembler geschrieben, selbst nachdem COBOL- und PL/I-Unterstützung verfügbar war.

Da Hardware-Ressourcen in den 1960er- und 1970er-Jahren teuer und knapp waren, entwickelte sich unter Systemoptimierungsanalysten ein regelrechter Wettbewerb. Sobald der kritische Pfad identifiziert war, wurde ein Codeabschnitt von einem Analysten zum nächsten weitergegeben. Jeder musste entweder (a) die benötigte Code-Byte-Zahl oder (b) die benötigte Anzahl an CPU- Zyklen reduzieren. Jüngere Analysten lernten von erfahreneren Kollegen. Sobald niemand mehr (a) oder (b) umsetzen konnte, galt der Code als optimiert, und man widmete sich anderen Abschnitten. Kleine Unternehmen mit nur einem Analysten erlernten die CICS-Optimierung nur sehr langsam (oder gar nicht).

Da Anwendungsprogramme von vielen gleichzeitig laufenden Threads gemeinsam genutzt werden konnten, war die Verwendung von statischen Variablen, die in ein Programm eingebettet sind (oder die Nutzung des Betriebssystemspeichers), (nur aufgrund einer Konvention) eingeschränkt.

Leider wurden viele dieser „Regeln“ häufig missachtet, insbesondere von COBOL-Programmierern, die die Interna ihrer Programme möglicherweise nicht verstanden oder die notwendigen restriktiven Kompilierzeitoptionen nicht nutzten . Dies führte zu nicht wiederaufladbarem Code, der oft unzuverlässig war und zu fälschlichen Speicherzugriffsverletzungen sowie zum Absturz ganzer CICS-Systeme führte.

Ursprünglich wurde die gesamte Partition bzw. der Multiple Virtual Storage (MVS)-Bereich mit demselben Speicherschutzschlüssel betrieben, einschließlich des CICS-Kernelcodes. Programm- und CICS-Kontrollblockbeschädigungen waren häufige Ursachen für Systemausfälle. Ein Softwarefehler in einem Anwendungsprogramm konnte den Speicher (Code oder Daten) einer oder aller aktuell laufenden Anwendungstransaktionen überschreiben. Die Lokalisierung des fehlerhaften Anwendungscodes bei komplexen, vorübergehenden Timingfehlern konnte für Betriebssystemanalysten eine sehr schwierige Aufgabe darstellen.

Diese Mängel blieben trotz ihrer Schwere und der hohen Nachfrage nach hochqualifizierten CICS-Fachkräften über mehr als 20 Jahre hinweg in mehreren neuen CICS-Versionen bestehen. In den Versionen TS V3.3, V4.1 und V5.2 wurden sie mit den Funktionen „Speicherschutz“, „Transaktionsisolation“ und „Subspace“ behoben. Diese nutzen Hardwarefunktionen des Betriebssystems, um Anwendungscode und Daten im selben Adressraum zu schützen , obwohl die Anwendungen nicht für eine Trennung konzipiert wurden. CICS-Anwendungstransaktionen sind weiterhin geschäftskritisch für viele Energieversorgungsunternehmen, Großbanken und andere Finanzinstitute mit einem Volumen von mehreren Milliarden Dollar.

Bei der ersten Veröffentlichung von CICS wurden nur in IBM 360 Assembler geschriebene Anwendungstransaktionsprogramme unterstützt . Die Unterstützung für COBOL und PL/I wurde erst Jahre später hinzugefügt. Aufgrund der anfänglichen Assembler-Ausrichtung wurden Anfragen an CICS-Dienste mithilfe von Assembler- Makros gestellt . Beispielsweise könnte die Anfrage zum Lesen eines Datensatzes aus einer Datei durch einen Makroaufruf an das „Dateisteuerungsprogramm“ von CICS folgendermaßen aussehen:

DFHFC TYPE=READ,DATASET=myfile,TYPOPER=UPDATE,....etc. 

Dies führte zur späteren Bezeichnung „ CICS auf Makroebene “.

Mit der Einführung der Unterstützung für höhere Programmiersprachen wurden die Makros beibehalten und der Code mithilfe eines Präprozessors in die entsprechenden COBOL- oder PL/I-CALL-Anweisungen umgewandelt. Die Erstellung einer Anwendung für höhere Programmiersprachen entsprach somit effektiv einem zweistufigen Kompilierungsprozess  – die Ausgabe des Präprozessors diente als Eingabe für den Compiler.

COBOL-Überlegungen : Im Gegensatz zu PL/I ermöglicht IBM COBOL normalerweise keine Manipulation von Zeigern (Adressen). Um COBOL-Programmierern den Zugriff auf CICS-Steuerblöcke und dynamischen Speicher zu ermöglichen, griffen die Entwickler auf einen im Wesentlichen unkonventionellen Ansatz zurück. Die COBOL- Linkage-Sektion wurde üblicherweise für die Kommunikation zwischen Programmen, wie z. B. die Parameterübergabe, verwendet. Der Compiler generiert eine Liste von Adressen, die jeweils als Base Locator for Linkage (BLL) bezeichnet werden und beim Start des aufgerufenen Programms gesetzt werden. Der erste BLL entspricht dem ersten Eintrag in der Linkage-Sektion usw. CICS ermöglicht dem Programmierer den Zugriff und die Manipulation dieser Adressen, indem die Adresse der Liste als erstes Argument an das Programm übergeben wird. Die BLLs können dann dynamisch, entweder von CICS oder von der Anwendung, gesetzt werden, um den Zugriff auf die entsprechende Struktur in der Linkage-Sektion zu ermöglichen. ^{[ 40 ]}

In den 1980er Jahren entwickelte IBM in Hursley Park eine Version von CICS, die das unterstützte, was später als „Command-level CICS“ bekannt wurde. Diese unterstützte weiterhin die älteren Programme, führte aber einen neuen API-Stil für Anwendungprogramme ein.

Ein typischer Befehlsaufruf könnte wie folgt aussehen:

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

Die im Befehl SEND MAPSET angegebenen Werte entsprechen den Namen des ersten DFHMSD-Makros in der unten stehenden Map-Definition für das MAPSET-Argument und des DFHMSI-Makros für das MAP-Argument. Dies wird durch eine Batch-Übersetzung vor der Kompilierung vorverarbeitet, die die eingebetteten Befehle (EXECs) in Aufrufe einer Stub-Subroutine umwandelt. Die Vorbereitung von Anwendungsprogrammen für die spätere Ausführung erforderte daher weiterhin zwei Schritte. Es war möglich, Anwendungen im „ gemischten Modus “ zu schreiben, die sowohl Makro- als auch Befehlsebenenanweisungen verwendeten.

Ursprünglich wurden die Befehle auf Kommandoebene zur Laufzeit mithilfe eines Laufzeitübersetzers, dem „EXEC Interface Program“, in den alten Makroaufruf umgewandelt, der dann von den weitgehend unveränderten CICS-Kernprogrammen ausgeführt wurde. Mit der Neuentwicklung des CICS-Kernels für TS V3 wurde EXEC CICS jedoch zur einzigen Möglichkeit, CICS-Anwendungen zu programmieren, da sich viele der zugrundeliegenden Schnittstellen geändert hatten.

Das Anfang der 1990er-Jahre eingeführte , ausschließlich auf Befehlsebene basierende CICS bot einige Vorteile gegenüber früheren Versionen. IBM stellte jedoch gleichzeitig die Unterstützung für Makro-basierte Anwendungsprogramme ein, die für ältere Versionen geschrieben worden waren. Dies bedeutete, dass viele Anwendungsprogramme konvertiert oder komplett neu geschrieben werden mussten, um ausschließlich EXEC-Befehle auf Befehlsebene verwenden zu können.

Zu diesem Zeitpunkt gab es weltweit vermutlich Millionen von Programmen, die in vielen Fällen bereits seit Jahrzehnten im Einsatz waren. Ihre Neuentwicklung führte oft zu neuen Fehlern, ohne zwangsläufig neue Funktionen hinzuzufügen. Eine beträchtliche Anzahl von Nutzern, die CICS V2-Anwendungsbereiche (AORs) verwendeten, nutzten diese auch noch viele Jahre nach dem Wechsel zu V3, um weiterhin Makrocode auszuführen.

Es war auch möglich, alte Programme auf Makroebene mithilfe von Konvertierungssoftware wie beispielsweise Command CICS von APT International auszuführen . ^{[ 41 ]}

Zu den jüngsten Erweiterungen des CICS Transaction Servers gehört die Unterstützung einer Reihe moderner Programmierstile.

CICS Transaction Server Version 5.6 ^{[ 42 ]} bietet verbesserte Java-Unterstützung für ein Cloud-natives Entwicklungserlebnis. Die neue CICS Java API ( JCICSX ) ermöglicht beispielsweise einfachere Unit-Tests mit Mocking und Stubbing und kann remote auf dem lokalen Rechner des Entwicklers ausgeführt werden. CICS-Artefakte auf Maven Central erlauben die Auflösung von Java-Abhängigkeiten mit gängigen Abhängigkeitsverwaltungstools wie Apache Maven und Gradle . Plug-ins für Maven ( cics-bundle-maven ) und Gradle ( cics-bundle-gradle ) vereinfachen die automatisierte Erstellung von CICS-Bundles in bekannten IDEs wie Eclipse , IntelliJ IDEA und Visual Studio Code . Die Node.js- Unterstützung für z/OS wurde in Version 12 erweitert und bietet nun einen schnelleren Start, optimierte Heap-Limits, Aktualisierungen der V8-JavaScript-Engine und mehr. Auch Jakarta EE 8 wird unterstützt.

Mit CICS TS 5.5 wurde die Unterstützung für das IBM SDK für Node.js eingeführt. Damit werden eine vollständige JavaScript-Laufzeitumgebung, serverseitige APIs und Bibliotheken bereitgestellt, um effizient leistungsstarke und hochskalierbare Netzwerkanwendungen für IBM Z zu erstellen.

CICS Transaction Server Version 2.1 führte die Unterstützung für Java ein. CICS Transaction Server Version 2.2 unterstützte das Software Developers Toolkit (SDT). CICS bietet denselben Laufzeitcontainer wie die IBM WebSphere-Produktfamilie, sodass Java-EE-Anwendungen zwischen CICS und WebSphere portierbar sind und gemeinsame Werkzeuge für die Entwicklung und Bereitstellung von Java-EE-Anwendungen zur Verfügung stehen.

Darüber hinaus legte CICS Wert darauf, bestehende Anwendungsprogramme in moderne Schnittstellen einzubetten, um etablierte Geschäftsfunktionen in modernere Dienste zu integrieren. Dazu gehören WSDL-, SOAP- und JSON-Schnittstellen, die Legacy-Code umschließen, sodass Web- oder Mobilanwendungen die zentralen Geschäftsobjekte abrufen und aktualisieren können, ohne dass die Backend-Funktionen grundlegend überarbeitet werden müssen.

Eine CICS-Transaktion ist eine Gruppe von Operationen, die gemeinsam eine Aufgabe ausführen. In der Regel handelt es sich bei den meisten Transaktionen um relativ einfache Aufgaben, wie beispielsweise das Anfordern einer Inventarliste oder das Buchen einer Soll- oder Habenbuchung auf einem Konto. Ein Hauptmerkmal einer Transaktion ist ihre Atomarität . Auf IBM Z -Servern unterstützt CICS problemlos Tausende von Transaktionen pro Sekunde und ist damit ein fester Bestandteil der Unternehmens-IT.

CICS-Anwendungen umfassen Transaktionen, die in zahlreichen Programmiersprachen geschrieben werden können , darunter COBOL, PL/I, C, C++, IBM Basic Assembly Language, Rexx und Java.

Jedes CICS-Programm wird mithilfe einer Transaktionskennung gestartet. CICS-Bildschirme werden üblicherweise als Map-Konstrukt übertragen, ein Modul, das mit Assembler-Makros des Basic Mapping Support (BMS) oder mit Drittanbieter-Tools erstellt wird. CICS- Bildschirme können Text enthalten, der je nach verwendetem Terminaltyp hervorgehoben, farblich unterschiedlich dargestellt und/oder blinkt. Ein Beispiel für die Übertragung einer Map über COBOL ist unten aufgeführt. Der Endbenutzer gibt Daten ein, die dem Programm durch den Empfang einer Map von CICS zugänglich gemacht werden.

EXEC CICS RECEIVE MAPSET ( 'LOSMATT' ) MAP ( 'LOSATT' ) INTO ( OUR-MAP ) END-EXEC .

Aus technischen Gründen müssen die Argumente mancher Befehlsparameter in Anführungszeichen gesetzt werden, andere hingegen nicht, je nachdem, worauf Bezug genommen wird. Die meisten Programmierer arbeiten zunächst mit einem Nachschlagewerk, bis sie das Prinzip verstanden haben, welche Argumente in Anführungszeichen gesetzt werden müssen. Alternativ verwenden sie in der Regel eine vorgefertigte Codevorlage, deren Beispielcode sie einfach kopieren und einfügen und anschließend anpassen.

Die Basic Mapping Support definiert das Bildschirmformat mithilfe von Assembler-Makros wie den folgenden. Diese wurden assembliert, um sowohl den physischen Map-Satz  – ein Lademodul in einer CICS-Ladebibliothek – als auch einen symbolischen Map-Satz  – eine Strukturdefinition oder DSECT in PL/I, COBOL, Assembler usw. – zu generieren, der in das Quellprogramm kopiert wurde. ^{[ 43 ]}

LOSMATT DFHMSD TYPE = MAP , X MODE = INOUT , X TIOAPFX = YES , X TERM = 3270 - 2 , X LANG = COBOL , X MAPATTS = ( COLOR , HILIGHT ), X DSATTS = ( COLOR , HILIGHT ), X STORAGE = AUTO , X CTRL = ( FREEKB , FRSET ) * LOSATT DFHMDI SIZE = ( 24 , 80 ), X LINE = 1 , X COLUMN = 1 * LSSTDII DFHMDF POS = ( 1 , 01 ), X LENGTH = 04 , X COLOR = BLUE , X INITIAL = 'MQCM' , X ATTRB = PROT * DFHMDF POS = ( 24 , 01 ), X LENGTH = 79 , X COLOR = BLUE X ATTRB = ASKIP , X INITIAL = 'PF7- 8- 9- 10- X 11 - 12 - CANCEL ' * DFHMSD TYPE = FINAL END

In der z/OS- Umgebung besteht eine CICS-Installation aus einer oder mehreren „ Regionen “ (allgemein als „CICS-Region“ bezeichnet) ^{[ 44 ]} , die sich über ein oder mehrere z/OS-Systemabbilder erstrecken. Obwohl interaktive Transaktionen verarbeitet werden, wird jede CICS-Region üblicherweise als Batch-Adressraum mit Standard -JCL- Anweisungen gestartet: Es handelt sich um einen Job, der bis zum Herunterfahren unbegrenzt läuft. Alternativ kann jede CICS-Region als gestartete Aufgabe gestartet werden . Unabhängig davon, ob es sich um einen Batch-Job oder eine gestartete Aufgabe handelt, können CICS-Regionen Tage, Wochen oder sogar Monate laufen, bevor sie für Wartungsarbeiten (MVS oder CICS) heruntergefahren werden. Beim Neustart bestimmt ein Parameter, ob der Start „Kaltstart“ (ohne Wiederherstellung) oder „Warmstart“/„Notfallstart“ (mittels warmem Herunterfahren oder Neustart aus dem Protokoll nach einem Absturz) erfolgen soll. Kaltstarts großer CICS-Regionen mit vielen Ressourcen können lange dauern, da alle Definitionen neu verarbeitet werden.

Installationen werden aus einer Vielzahl von Gründen in mehrere Adressräume unterteilt, zum Beispiel:

• Anwendungstrennung
• Funktionstrennung
• Vermeidung der Workload-Kapazitätsbeschränkungen einer einzelnen Region, eines Adressraums oder einer Mainframe-Instanz im Falle von az/OS SysPlex.

Eine typische Installation besteht aus mehreren separaten Anwendungen, die einen Dienst bilden. Jeder Dienst verfügt üblicherweise über mehrere „Terminal-Owning Regions“ (TORs), die Transaktionen an mehrere „Application-Owning Regions“ (AORs) weiterleiten. Andere Topologien sind jedoch möglich. Beispielsweise führen die AORs möglicherweise keine Datei-E/A durch. Stattdessen gäbe es eine „File-Owning Region“ (FOR), die die Datei-E/A im Auftrag von Transaktionen in der AOR durchführt – vorausgesetzt, eine VSAM-Datei unterstützte zu diesem Zeitpunkt nur wiederherstellbaren Schreibzugriff aus jeweils einem Adressraum.

Nicht alle CICS-Anwendungen nutzen VSAM als primäre Datenquelle (oder historisch gesehen andere Datenspeicher mit jeweils nur einem Adressraum, wie z. B. CA Datacom) – viele verwenden entweder IMS/DB oder Db2 als Datenbank und/oder MQ als Warteschlangenmanager. In all diesen Fällen können TORs Transaktionen auf Gruppen von AORs verteilen, die dann direkt die gemeinsam genutzten Datenbanken/Warteschlangen verwenden. CICS unterstützt XA-Zwei-Phasen-Commit zwischen Datenspeichern, sodass beispielsweise Transaktionen, die sich über MQ, VSAM/RLS und Db2 erstrecken, mit ACID-Eigenschaften möglich sind.

CICS unterstützt verteilte Transaktionen mittels des SNA LU6.2-Protokolls zwischen Adressräumen, die auf demselben oder auf verschiedenen Clustern ausgeführt werden können. Dies ermöglicht ACID-konforme Aktualisierungen mehrerer Datenspeicher durch kooperierende verteilte Anwendungen. In der Praxis treten jedoch Probleme auf, wenn ein System- oder Kommunikationsausfall auftritt, da der Transaktionsverlauf (Backout oder Commit) unklar sein kann, falls einer der kommunizierenden Knoten nicht wiederhergestellt ist. Daher hat sich die Nutzung dieser Funktionen nie sehr verbreitet.

Zum Zeitpunkt der Veröffentlichung von CICS ESA V3.2 Anfang der 1990er Jahre stand IBM vor der Herausforderung, CICS so zu gestalten, dass es die neue z/OS Sysplex Mainframe-Reihe optimal nutzte.

Der Sysplex sollte auf CMOS (Complementary Metal Oxide Silicon) anstatt auf der bestehenden ECL -Hardware (Emitter Coupled Logic) basieren . Die Skalierung der Mainframe-spezifischen ECL-Technologie war deutlich teurer als die von CMOS, das von einem Keiretsu mit Massenanwendungen wie der Sony PlayStation entwickelt wurde, um die Stückkosten der CPUs jeder Generation zu senken. Der Betrieb der ECL-Technologie war für die Anwender ebenfalls teuer, da der Gate-Drain-Strom so viel Wärme erzeugte, dass die CPU in ein spezielles Modul, das sogenannte Thermal Conduction Module (TCM ^{[ 45 ]} ), eingebaut werden musste. Dieses Modul enthielt Inertgaskolben und benötigte eine Kühlung mit großem Volumen an Kühlwasser. Die CPU-Geschwindigkeit der luftgekühlten CMOS-Technologie war anfangs jedoch deutlich geringer als die der ECL-Technologie (insbesondere bei den von den Mainframe-Klonherstellern Amdahl und Hitachi angebotenen Geräten ). Dies war für IBM im CICS-Kontext besonders besorgniserregend, da fast alle großen Mainframe-Kunden CICS einsetzten und es für viele von ihnen die primäre Mainframe-Anwendung darstellte.

Um auf einem Sysplex den gleichen Transaktionsdurchsatz zu erreichen, müssten für jede Arbeitslast mehrere Server parallel betrieben werden. Der Adressraum von CICS konnte jedoch aufgrund seines quasi-wiederverwendbaren Programmiermodells nicht mehr als etwa 1,5 Prozessoren pro Server gleichzeitig nutzen – selbst mit MVS-Subtasks. Ohne verbesserte Parallelität würden Kunden bei der Skalierung ihrer CICS-Arbeitslasten eher zu IBM-Konkurrenten wechseln, anstatt Sysplex einzusetzen. Innerhalb von IBM gab es erhebliche Diskussionen darüber, ob der richtige Ansatz darin bestünde, die Aufwärtskompatibilität für Anwendungen aufzugeben und zu einem vollständig wiederverwendbaren Modell wie IMS/DC zu wechseln oder den von Kunden gewählten Ansatz zur besseren Ausnutzung der Leistung eines einzelnen Mainframes mithilfe des Multi-Region-Betriebs (MRO) zu erweitern.

Nach Rücksprache mit der CICS-Nutzergemeinschaft wurde schließlich der zweite Weg gewählt. Die Nutzergemeinschaft lehnte es vehement ab, die Aufwärtskompatibilität zu beeinträchtigen, da sie zu diesem Zeitpunkt mit dem Jahr-2000-Problem konfrontiert war und keinen Nutzen darin sah, Millionen von Zeilen hauptsächlich COBOL-, PL/I- oder Assembler-Code neu zu schreiben und zu testen.

Die von IBM empfohlene Struktur für CICS auf Sysplex sah vor, dass auf jedem Sysplex-Knoten mindestens eine CICS-Terminal-Owning-Region (CICS TOR) platziert wurde, die Transaktionen an zahlreiche Application-Owning-Regions (AORs) im gesamten Sysplex verteilte. Um auf gemeinsam genutzte Ressourcen zuzugreifen, nutzten diese Anwendungen entweder einen Sysplex-fähigen Datenspeicher (wie IBM Db2 oder IMS/DB ) oder konzentrierten die Ressourcenanforderungen durch Funktionsübertragung in jeweils eine Resource-Owning-Region (ROR), darunter File-Owning-Regions (FORs) für VSAM und CICS-Datentabellen sowie Queue-Owning-Regions (QORs) für MQ , CICS Transient Data (TD) und CICS Temporary Storage (TS). Dies gewährleistete die Kompatibilität mit bestehenden Anwendungen, führte jedoch zu einer erhöhten Komplexität bei der Konfiguration und Verwaltung der vielen CICS-Regionen.

In späteren Versionen konnte CICS neue Sysplex-Funktionen in VSAM/RLS ^{[ 46 ]} und MQ für z/OS ^{[ 47 ]} nutzen und seine eigenen Datentabellen, TD- und TS-Ressourcen in den eigens für den Sysplex entwickelten Shared Resource Manager, die Coupling Facility (CF), integrieren. Dadurch entfielen die meisten RORs. Die CF bietet eine übersichtliche Darstellung der Ressourcen, einschließlich einer gemeinsamen Zeitbasis, Pufferpools, Sperren und Zählern, unterstützt durch Hardware-Messaging. Dies ermöglichte eine effizientere und zuverlässigere Ressourcennutzung im gesamten Sysplex als das Polling (durch die Verwendung einer semi-synchronisierten Backup-CF für den Ausfallfall).

Zu diesem Zeitpunkt verfügte die CMOS-Fertigungslinie über Einzelgeräte, deren Leistung die der schnellsten ECL-Geräte mit mehr Prozessoren pro CPU übertraf. Durch die Kopplung dieser Geräte konnten 32 oder mehr Knoten die Gesamtleistung für eine einzelne Arbeitslast um zwei Größenordnungen steigern. Beispielsweise betrieb Charles Schwab im Jahr 2002 einen „MetroPlex“, bestehend aus zwei redundanten Mainframe-Sysplexen an zwei Standorten in Phoenix, Arizona. Jeder Sysplex umfasste 32 Knoten, die von einer gemeinsamen CICS/DB/2-Arbeitslast gesteuert wurden, um das enorme Volumen an Web-Client-Anfragen vor dem Platzen der Dotcom-Blase zu bewältigen.

Der Übergang zur CMOS-basierten Technologie, die sich durch geringere Kosten und verbesserte Skalierbarkeit auszeichnet, veränderte die Wettbewerbslandschaft für IBM-Großrechnersysteme grundlegend. Dieser technologische Wandel, verstärkt durch einen schrumpfenden Markt und die erheblichen Investitionen, die für die Nachbildung proprietärer 64-Bit-Architekturen erforderlich waren, schuf prohibitive Markteintrittsbarrieren. Infolgedessen sahen sich unabhängige Hersteller von IBM-kompatiblen Großrechnersystemen nach und nach gezwungen, den Markt zu verlassen. ^{[ 48 ] [ 49 ]}

Ziel der Wiederherstellung/des Neustarts in CICS ist es, Schäden am Online-System im Fehlerfall zu minimieren oder möglichst vollständig zu beseitigen, um die System- und Datenintegrität zu gewährleisten. ^{[ 50 ]} Wurde die CICS-Region heruntergefahren, anstatt auszufallen, führt sie einen Warmstart durch, bei dem der beim Herunterfahren erstellte Prüfpunkt genutzt wird. Alternativ kann die CICS-Region auch zu einem Kaltstart gezwungen werden, bei dem alle Definitionen neu geladen und das Protokoll gelöscht werden, sodass die Ressourcen ihren aktuellen Zustand beibehalten.

Im Rahmen von CICS gelten unter anderem folgende Ressourcen als wiederherstellbar. Sollen diese Ressourcen wiederherstellbar sein, müssen in den entsprechenden CICS-Definitionen spezielle Optionen angegeben werden:

• VSAM-Dateien
• CMT CICS-verwaltete Datentabellen
• Intrapartition TDQ
• Warteschlange für temporären Speicher im Hilfsspeicher
• E/A-Nachrichten von/zu Transaktionen in einem VTAM-Netzwerk
• Andere Datenbank-/Warteschlangenressourcen, die mit CICS verbunden sind und das XA-Zwei-Phasen-Commit-Protokoll unterstützen (wie IMS/DB, Db2, VSAM/RLS).

CICS bietet zudem umfangreiche Wiederherstellungs-/Neustartfunktionen, mit denen Benutzer ihre eigene Wiederherstellungs-/Neustartfähigkeit in ihrem CICS-System einrichten können. Zu den häufig verwendeten Wiederherstellungs-/Neustartfunktionen gehören:

• Dynamischer Transaktionsrücklauf (DTB)
• Automatischer Transaktionsneustart
• Ressourcenwiederherstellung mithilfe des Systemprotokolls
• Ressourcenwiederherstellung mithilfe des Journals
• Systemneustart
• Erweiterte Erholungseinrichtung

Jede CICS-Region umfasst eine Hauptaufgabe, auf der alle Transaktionen ausgeführt werden. Bestimmte Dienste, wie beispielsweise der Zugriff auf IBM Db2 -Daten, nutzen jedoch andere Aufgaben (TCBs). Innerhalb einer Region werden Transaktionen kooperativ parallel verarbeitet  – sie verhalten sich erwartungsgemäß und stellen die CPU zur Verfügung, anstatt zu warten. Die CICS-Dienste steuern dies automatisch.

Jeder einzelnen CICS-„ Task “ oder Transaktion wird beim Start ein eigener dynamischer Speicher zugewiesen , und nachfolgende Anfragen nach zusätzlichem Speicher werden durch einen Aufruf des „Storage Control Programms“ (Teil des CICS - Kernels ) bearbeitet, das analog zu einem Betriebssystem ist .

Ein CICS-System besteht aus dem Online- Kern , Batch-Unterstützungsprogrammen und Anwendungsdiensten. ^{[ 51 ]}

Der ursprüngliche CICS-Kern bestand bis Version 3 aus einer Reihe von Funktionsmodulen, die in 370-Assembler geschrieben waren:

• Aufgabensteuerungsprogramm (KCP)
• Speicherkontrollprogramm (SCP)
• Programmsteuerungsprogramm (PCP)
• Programmunterbrechungssteuerungsprogramm (PIP)
• Intervallsteuerungsprogramm (ICP)
• Dump Control Program (DCP)
• Terminal Control Program (TCP)
• Dateiverwaltungsprogramm (FCP)
• Transient Data Control Program (TDP)
• Temporäres Speicherkontrollprogramm (TSP)

Ab Version 3 wurde der CICS-Kern in eine Kernel- und Domänenstruktur unter Verwendung der IBM- Sprache PL/AS umgeschrieben – die in Assembler kompiliert wird.

Die vorherige Struktur gewährleistete keine Trennung der Zuständigkeiten und wies daher viele Abhängigkeiten zwischen Programmen auf, was ohne umfassende Codeanalyse zu Fehlern führte. Die neue Struktur war modularer und somit robuster, da sie sich leichter und ohne Auswirkungen ändern ließ. Die ersten Domänen wurden oft nach dem Vorgängerprogramm benannt, jedoch ohne das angehängte „P“. Beispiele hierfür sind die Programmsteuerungsdomäne (DFHPC) oder die Domäne für transiente Daten (DFHTD). Der Kernel fungierte als Umschalter für domänenübergreifende Anfragen. Dies erwies sich anfänglich für häufig aufgerufene Domänen (wie z. B. Trace) als ressourcenintensiv. Durch die Verwendung von PL/AS-Makros konnten diese Aufrufe jedoch inline integriert werden, ohne die separate Domänenarchitektur zu beeinträchtigen.

In späteren Versionen wurden komplett neu gestaltete Domänen hinzugefügt, wie die Protokollierungsdomäne DFHLG und die Transaktionsdomäne DFHTM, die das Journal Control Program (JCP) ersetzten.

Zusätzlich zu den Online-Funktionen verfügt CICS über mehrere Unterstützungsprogramme, die als Batch-Jobs ausgeführt werden. ^{[ 52 ] : S. 34–35}

• Präprozessor für Hochsprachen (Makros)
• Befehlssprachenübersetzer
• Dump-Dienstprogramm – gibt formatierte Dumps aus, die von der CICS-Dumpverwaltung generiert wurden.
• Trace-Dienstprogramm – Formatiert und gibt die CICS-Trace-Ausgabe aus
• Journalformatierungs-Dienstprogramm – gibt im Fehlerfall einen formatierten Auszug der CICS-Region aus.

Die folgenden Komponenten von CICS unterstützen die Anwendungsentwicklung. ^{[ 52 ] : S. 35–37}

• Basic Mapping Support (BMS) bietet geräteunabhängige Terminal-Ein- und Ausgänge.
• APPC-Unterstützung bietet API-Unterstützung für LU6.1 und LU6.2 zur Zusammenarbeit verteilter Anwendungen, die Zwei-Phasen-Commit unterstützen.
• Das Data Interchange Program (DIP) bietet Unterstützung für programmierbare Geräte vom Typ IBM 3770 und IBM 3790.
• Die 2260-Kompatibilität ermöglicht es, für IBM 2260- Anzeigegeräte geschriebene Programme auf 3270-Anzeigen auszuführen.
• EXEC-Schnittstellenprogramm – das Stub-Programm, das von EXEC CICSBefehlen generierte Aufrufe in Aufrufe von CICS-Funktionen umwandelt.
• Integrierte Funktionen – Tabellensuche, phonetische Konvertierung, Feldprüfung, Feldbearbeitung, Bitprüfung, Eingabeformatierung, gewichtete Suche

In verschiedenen Ländern gibt es unterschiedliche Aussprachen ^{[ 53 ].}

• Innerhalb von IBM (insbesondere Tivoli ) wird es als / ˈ k ɪ k s / bezeichnet .
• In den USA wird es üblicherweise ausgesprochen, indem man jeden Buchstaben einzeln rezitiert / ˌ siː ˌ aɪ ˌ siː ˈ ɛ s / .
• In Australien, Belgien, Kanada, Hongkong, Großbritannien und einigen anderen Ländern wird es / ˈ k ɪ k s / ausgesprochen .
• In Dänemark wird es „Kicks“ ausgesprochen .
• In Finnland wird es [kiks] ausgesprochen.
• In Frankreich wird es [se.i.se.ɛs] ausgesprochen .
• In Deutschland, Österreich und Ungarn wird es [ˈtsɪks] und seltener [ˈkɪks] ausgesprochen .
• In Griechenland wird es „kiks“ ausgesprochen .
• In Indien wird es „kicks“ ausgesprochen .
• Im Iran wird es „Kicks“ ausgesprochen .
• In Italien wird es [ˈtʃiks] ausgesprochen .
• In Polen wird es [ˈkʲiks] ausgesprochen .
• In Portugal und Brasilien wird es [ˈsiks] ausgesprochen .
• In Russland wird es „kiks“ ausgesprochen .
• In Slowenien wird es „kiks“ ausgesprochen .
• In Spanien wird es [ˈθiks] ausgesprochen .
• In Schweden wird es „Kicks“ ausgesprochen .
• In Uganda wird es „kicks“ ausgesprochen .
• In der Türkei wird es „kiks“ ausgesprochen .

• IBM TXSeries (CICS auf verteilten Plattformen)
• IBM WebSphere
• IBM 2741
• IBM 2260
• IBM 3270
• OS/360 und Nachfolger
• Source Program Maintenance Online II (früher Online-Editor unter CICS)
• Transaktionsverarbeitungszentrum
• Virtuelle Speicherzugriffsmethode (VSAM)

• Offizielle Website
• Warum Sie den CICS Transaction Server für neue IT-Projekte wählen sollten  – IBM CICS Whitepaper
• IBM Software – CICS – 35-jähriges Jubiläum (2004) in der Wayback Machine (archiviert am 4. Februar 2009)
• Supportforum für CICS-Programmierung
• Website der CICS-Benutzergemeinschaft für Neuigkeiten, Ankündigungen und Diskussionen rund um CICS. Archiviert am 5. August 2008 im Internet Archive (Wayback Machine).
• Bob Yelavichs Website mit Schwerpunkt auf CICS. (Diese Website verwendet Frames, aber auf hochauflösenden Bildschirmen kann der linke Frame mit dem Seitenindex ausgeblendet sein. Scrollen Sie innerhalb des Frames nach rechts, um dessen Inhalt zu sehen.) (Archiviert am 5. Februar 2005 in der Wayback Machine )