IMS und CICS: Warum der Vergleich als Synonyme zu kurz greift

Im Austausch über Mainframe Architekturen stellt sich häufig die Frage, wie eng IMS und CICS tatsächlich miteinander verwandt sind. Dabei entsteht nicht selten der Eindruck, IMS lasse sich als ältere, stärker datenbankorientierte Variante von CICS einordnen.

Solche Aussagen sind eingängig. Sie greifen aber zu kurz.

Der entscheidende Unterschied zwischen IMS und CICS liegt nicht darin, dass das eine System „moderner“ oder „mehr online“ wäre als das andere. Der Unterschied liegt tiefer: im jeweiligen Ausführungs- und Steuerungsmodell.

Die Verwechslung ist nachvollziehbar

Dass beide Systeme häufig in einen Topf geworfen werden, ist zunächst verständlich. Sowohl IMS als auch CICS sind in hochverfügbaren Mainframe-Landschaften zu Hause. Beide verarbeiten geschäftskritische Workloads. Beide stehen für Stabilität, hohe Transaktionsraten und lange gewachsene Anwendungssysteme.

Wer nur von außen auf diese Plattformen blickt, sieht deshalb oft vor allem die Gemeinsamkeiten: Online-Verarbeitung, Datenbankzugriffe, Transaktionen, Integration mit weiteren Subsystemen. Genau daraus entsteht schnell der Eindruck, es handele sich um zwei Varianten derselben Idee.

Doch eine ähnliche Verwendung bedeutet nicht, dass das zugrunde liegende Modell identisch ist.

CICS denkt in Tasks und Programmkontrolle

CICS ist, technisch betrachtet, ein allgemeiner Transaktionsserver. Für jeden Request erzeugt CICS eine eigene Task und übergibt die Kontrolle an das für die Transaktion definierte Initialprogramm. Dieses Programm kann während der Laufzeit weitere Programme über LINK aufrufen.

Programmkontrolle erfolgt in CICS bewusst strukturiert. LINK übergibt die Kontrolle an ein Programm auf der nächsttieferen logischen Ebene; XCTL überträgt sie endgültig auf derselben logischen Ebene und gibt das aufrufende Programm frei.

Auch der Datentransport folgt diesem Modell. Zwischen Programmen werden Daten klassisch über COMMAREA oder moderner über Channels und Containers weitergegeben. Damit ist die Leitfrage in CICS oft: Wie soll diese Transaktion innerhalb des CICS-gemanagten Task-Kontexts aufgebaut, aufgerufen und kontrolliert ausgeführt werden?

IMS denkt in Nachrichten, Queues und Scheduling

Bei IMS – genauer: im transaktionalen Umfeld von IMS TM – liegt das Gravitationszentrum an einer anderen Stelle. IMS stellt dafür eigene dependent regions bereit: separate Address Spaces, in denen IMS die Anwendungen schedult, die Transaktionen verarbeiten. In MPP-Regionen erhalten Programme ihren Input aus den Message Queues und können Antworten wieder an Terminals oder andere Anwendungen ausgeben.

Das bedeutet auch: Die Verarbeitung wird stärker aus dem Nachrichtenfluss heraus gedacht. Nicht zuerst „Welches Unterprogramm rufe ich als Nächstes auf?“, sondern eher: Wie bewegt sich diese Nachricht durch Queueing, Scheduling, Programmausführung und Datenzugriff?

Passend dazu stellt IMS TM eigene DL/I-System-Service-Calls bereit. Diese Aufrufe sind ausdrücklich für IMS-Transaction-Manager-Funktionen vorgesehen und beziehen sich auf die jeweilige TM-Verarbeitung.

Wo der Unterschied praktisch sichtbar wird

Die Unterschiede bleiben nicht theoretisch. Sie werden im Alltag sehr konkret sichtbar. In CICS zeigt sich das in Programmlinkage, logischen Ebenen, Task-Kontext und der kontrollierten Weitergabe von Daten und Steuerung. In IMS zeigt es sich dort, wo Scheduling, Nachrichtenfluss, Message Classes und die Zuordnung von Arbeit zu Regionen im Vordergrund stehen.

IBM beschreibt das sehr deutlich: Ein Scheduling-Algorithmus bestimmt in IMS, wie Anwendungen eingeplant werden, um die Last auf den Queues zu verarbeiten. Genau dort liegt ein wesentlicher architektonischer Schwerpunkt, der sich von der typischen CICS-Denkweise unterscheidet.

Fazit: IMS und CICS sind keine Varianten desselben Systems, sondern folgen grundlegend unterschiedlichen Verarbeitungsmodellen.

 

Über den Autor: Marcel Heß ist Anwendungsentwickler bei der Finanz Informatik GmbH & Co. KG (FI) und bringt über ein Jahrzehnt Erfahrung im Mainframe-Umfeld mit. Seine Leidenschaft gilt der Verbindung von tiefem Fachwissen und neuen Impulsen – er steht für eine junge Generation von Mainframern, die er unter dem Hashtag #GenZOS zusammenfasst.