Eine CICS-Transaktion ist keine HTTP-Anfrage

Die gefährliche CICS-Modernisierung ist die, die offensichtlich aussieht. Ein Team findet einen Transaktionscode, verpackt seine Eingabe in JSON, gibt ihm eine POST-Route und erklärt die Grenze für verstanden. In einer Demo funktionieren die Masken. Unter echtem Verkehr treten dann doppelte Übermittlungen, veralteter Status, zu frühe Commits und nur teilweise abgeschlossene verteilte Aktualisierungen auf.

Eine CICS-Transaktion ist ein Task mit von CICS verwalteten Ressourcen, Wiederherstellungsregeln und einem klaren Ende. Eine HTTP-Anfrage ist ein Transportaustausch, bei dem der Server den Client verlieren kann, bevor eine Seite weiß, was geschehen ist. Beide können denselben Geschäftsbefehl tragen, definieren aber nicht dieselbe Arbeitseinheit. Eine sichere Neufassung bewahrt den fachlichen Zustandsautomaten und macht die Commit-Grenze sichtbar, statt sie dem Web-Framework zu überlassen.

Die Taskgrenze bestimmt die Semantik

Eine CICS-Transaktion beginnt, wenn CICS einen Task anlegt, und endet, wenn das oberste Programm die Kontrolle zurückgibt oder der Task abbricht. Dieser Task kann mit LINK mehrere Programme aufrufen oder mit XCTL die Kontrolle übergeben. Solche Programmaufrufe erzeugen nicht schon deshalb neue Transaktionen, weil die Kontrolle eine Modulgrenze überschreitet. Die Transaktions-ID wählt einen Einstiegspunkt. Sie beschreibt weder eine Anfragemethode noch eine Ressource oder einen Antwortvertrag.

HTTP liefert eine andere Hülle. Eine Anfrage hat Header, Body, Verbindung und Antwort, aber das Protokoll weiß nicht, welche Datenbankschreibvorgänge zu einer Geschäftsaktion gehören. Ein Server kann committen, bevor er die Antwort sendet. Der Client kann nach dem Commit in einen Timeout laufen und es erneut versuchen. Ein Proxy kann eine Anfrage wiederholen, die die Anwendung nie als sicher eingestuft hat. Keines dieser Ereignisse hat im CICS-Taskmodell eine direkte Entsprechung.

Die erste Entwurfsfrage lautet daher nicht, welche URL eine vierstellige Transaktions-ID ersetzen soll. Klären Sie, welche wiederherstellbaren Änderungen gemeinsam gelingen oder scheitern müssen, welche Eingabe diese Entscheidung auslöst und welcher dauerhafte Fakt ihren Abschluss beweist. Erst danach kann eine Route den Befehl ehrlich darstellen.

Diese Unterscheidung verhindert auch einen häufigen Fehler bei der Granularität. Eine Maskeninteraktion kann einen CICS-Task, mehrere verknüpfte Programme und Aktualisierungen in Db2 sowie wiederherstellbaren CICS-Ressourcen ausführen. Wer jedes Programm in einen Netzwerkdienst zerlegt, setzt Fehlerstellen mitten in eine Einheit, die früher gemeinsam scheiterte. Wer mehrere pseudokonversationelle Schritte zu einer langen HTTP-Anfrage verbindet, macht den umgekehrten Fehler und hält Arbeit offen, während ein Mensch nachdenkt.

Behandeln Sie den alten Aufrufgraphen als Beleg, nicht als Zielarchitektur. Markieren Sie Taskstarts, LINK- und XCTL-Kanten, Datei- und Datenbankänderungen, ausgehende Nachrichten, explizite Syncpoints und Rückgaben der obersten Ebene. Die Grenzen um wiederherstellbare Arbeit stimmen nur selten mit Masken oder Programmgrenzen überein.

Die Pseudokonversation gibt den Task zwischen Masken frei

Eine pseudokonversationelle Anwendung wirkt für den Benutzer wie eine Sitzung, läuft aber als Folge kurzer Tasks. Ein Task empfängt eine Eingabe, rekonstruiert genug Kontext für deren Verarbeitung, sendet die nächste Maske, benennt die Transaktion für die nächste Eingabe, übergibt Fortsetzungsdaten und kehrt zu CICS zurück. Während der Benutzer die Maske liest, wartet kein Anwendungstask auf seine Antwort.

Die CICS-Dokumentation von IBM beschreibt dies als nichtkonversationelle Transaktionen, die in eine Sequenz eingebettet sind. Der Entwurf spart Speicher und hält exklusive Ressourcen nicht während der Denkzeit eines Menschen fest. Diese Formulierung ist wichtig, denn die scheinbare Konversation ist ein Benutzererlebnis und keine durchgehende Transaktion.

Ein vereinfachter COBOL-Ausstieg sieht oft so aus:

       EXEC CICS SEND MAP('ACCT1') MAPSET('ACCT')
       END-EXEC
       EXEC CICS RETURN
            TRANSID('AC02')
            COMMAREA(WS-CONTINUATION)
            LENGTH(WS-CONTINUATION-LEN)
       END-EXEC

RETURN TRANSID ruft AC02 im Normalfall nicht sofort auf. Der Befehl teilt CICS mit, welche Transaktion die nächste Terminaleingabe erhalten soll. Der aktuelle Task endet. Wenn diese Eingabe eintrifft, legt CICS einen neuen Task an, und das erste Programm kann die übergebene COMMAREA adressieren. Ein Channel kann dieselbe Fortsetzungsrolle übernehmen.

Wer diese Folge einem einzelnen HTTP-Sitzungsobjekt zuordnet, verdeckt meist zwei unabhängige Dinge. Der Browser hat Darstellungsstatus wie die aktuelle Seite und bearbeitbare Felder. Die Anwendung hat Workflowstatus wie das gewählte Konto, die gelesene Version, die geprüften Berechtigungen und die danach erlaubten Befehle. Die zweite Kategorie braucht eine versionierte serverseitige Darstellung oder ein manipulationssicheres Token. Eine sitzungsbezogene Map im Prozess ist dafür weder dauerhaft noch klar genug.

Die moderne Grenze sollte jede Benutzerentscheidung als kurzen Befehl bereitstellen. Ein GET kann eine Projektion zur Anzeige holen. Ein POST kann eine Entscheidung gegen eine Workflowversion einreichen. Keine Datenbanktransaktion bleibt offen, während der Browser wartet. Das entspricht der betrieblichen Absicht einer Pseudokonversation, obwohl der Transport ganz anders aussieht.

Eine COMMAREA ist ein Fortsetzungsvertrag, keine Sitzung

Eine COMMAREA ist ein Byte-Vertrag zwischen Programmen oder aufeinanderfolgenden Tasks. Das Copybook gibt diesen Bytes Bedeutung. Sie kann einen Funktionscode, Kennungen, Flags, Anzeigefelder, Rückgabecodes und Daten enthalten, die der nächste Task braucht. Sie kann auch historischen Ballast enthalten, den kein aktiver Pfad mehr liest. Die ganze Struktur als Sitzungsstatus zu bezeichnen, umgeht genau die Analyse, die eine Migration verlangt.

Bei einer Pseudokonversation hält CICS die übergebene COMMAREA für das erste Programm des nächsten Tasks bereit. IBM dokumentiert eine wichtige Grenze: Die COMMAREA ist nicht wiederherstellbar. Wenn ein Task eine Datenbankänderung committet und danach Fortsetzungsbytes vorbereitet, werden diese Bytes nicht Teil derselben wiederherstellbaren Ressource, nur weil CICS sie weitergibt.

Die praktische Größenbegrenzung warnt ebenfalls davor, sie als Objektspeicher zu behandeln. Die dokumentierte theoretische Obergrenze für RETURN liegt bei ungefähr 32 KB, wobei IBM traditionell eine niedrigere sichere Größe empfohlen hat. Channels und Container beseitigen die Größenbegrenzung einer einzelnen COMMAREA und geben Daten benannte Fächer, machen Fortsetzungsdaten aber nicht zur dauerhaften Geschäftswahrheit.

Teilen Sie jede COMMAREA beim Decodieren in drei Kategorien. Zur Geschäftsidentität gehören stabile Werte wie Kundennummer, Schadens-ID oder Auftrags-ID. Zur Workflowsteuerung gehören Phase, Funktionscode, vorherige Aktion und optimistische Version. Zum Darstellungsrest gehören kopierte Beschriftungen, Maskenliterale, Cursorentscheidungen und erneut abrufbare Felder. Speichern Sie den Geschäftsstatus dauerhaft, modellieren Sie die Workflowsteuerung ausdrücklich und verwerfen Sie Darstellungsreste, sofern das beobachtbare Verhalten nicht davon abhängt.

Die Längenbehandlung gehört in den Vertrag. Ein empfangendes COBOL-Programm prüft oft EIBCALEN, bevor es DFHCOMMAREA liest. Spätere Copybook-Versionen können Felder anhängen. Ein JSON-Decoder, der jedes neue Feld zwingend erwartet, kann weniger kompatibel sein als das alte Programm. Halten Sie akzeptierte Längen, Initialisierungsregeln, Konventionen für Leerzeichen und Nullen, EBCDIC-Konvertierung, Packed-Decimal-Formate und REDEFINES-Zweige fest, bevor Sie einen typisierten Ersatz entwerfen.

Serialisieren Sie das Copybook nicht als riesiges JSON-Dokument und nennen Sie das Bewahrung. Damit wird das Speicherlayout zur öffentlichen API, Clients erhalten Kontrolle über unzulässige Felder, und jede Copybook-Änderung wird zur API-Änderung. Übersetzen Sie die Bytes in einen Befehl mit klarer Absicht. Behalten Sie die Roheingabe nur in Test-Fixtures und Prüfnachweisen, soweit die Richtlinien dies erlauben.

Ein Syncpoint committet eine Arbeitseinheit, keine Antwort

CICS committet wiederherstellbare Änderungen an einem Syncpoint. Die Anwendung kann EXEC CICS SYNCPOINT ausführen, und CICS setzt außerdem einen impliziten Syncpoint, wenn ein Task der obersten Ebene normal endet. Ein Abbruch löst für Änderungen an wiederherstellbaren Ressourcen in der aktuellen Arbeitseinheit normalerweise einen dynamischen Transaktions-Backout aus. Dieser Lebenszyklus hat keine automatische Beziehung dazu, ob eine HTTP-Antwort ihren Aufrufer erreicht hat.

In einem Wrapper übersieht man die Folge leicht. Angenommen, der Task aktualisiert Db2, schreibt in eine wiederherstellbare Queue, kehrt normal zurück und das Gateway verliert die Verbindung, bevor es die Antwort ausliefert. CICS hat committet. Der Aufrufer sieht einen Timeout. Wenn der Ersatz einen Timeout als Fehlschlag interpretiert und den Befehl ohne Idempotenzregel wiederholt, führt er die Geschäftsaktion zweimal aus.

Auch der umgekehrte Fehler ist möglich. Ein Webhandler kann einen Status 200 OK in einen Puffer schreiben und danach scheitern, wenn sein Datenbank-Commit erst nach Rückkehr des Anwendungscodes läuft. Framework-Abstraktionen lassen die Erstellung einer Antwort wie Abschluss aussehen, obwohl der dauerhafte Abschluss noch nicht geschehen ist. Der Ersatz muss Erfolg als committetes Geschäftsergebnis definieren und die Antwortausgabe daran ausrichten.

Erfassen Sie jeden expliziten Syncpoint, statt nur vom Taskende auszugehen. Ein expliziter Syncpoint beendet die aktuelle Arbeitseinheit und startet eine neue, während der Task weiterläuft. Ein Rollback kann nur Änderungen seit dem letzten Syncpoint zurücknehmen, nicht alles, was der Task je getan hat. Wenn ein Programm auf halbem Weg eine Auditzeile committet und später eine Kontoänderung zurücknimmt, verändert eine Neufassung mit einer einzigen Datenbanktransaktion um den ganzen Handler das sichtbare Wiederherstellungsverhalten.

Nicht wiederherstellbare Effekte brauchen eine eigene Behandlung. Ein Aufruf eines externen Dienstes, eine an ein nichttransaktionales System übergebene E-Mail oder ein Schreiben an ein nicht wiederherstellbares Ziel wird nicht zurückgenommen, nur weil die Db2-Arbeit zurückgerollt wird. Die alte Anwendung kann sich bei solchen Effekten auf Reihenfolge, Wiederholungen oder eine Reparatur durch Operatoren verlassen. Bewahren Sie das Ergebnis, nicht die beruhigende Fiktion, eine Transaktion auf Sprachebene kontrolliere jede Ressource.

Zwei-Phasen-Commit lässt sich nicht durch hoffnungsvolle Wiederholungen ersetzen

Zwei-Phasen-Commit koordiniert wiederherstellbare Ressourcenmanager in einer verteilten Arbeitseinheit. In Phase eins bereiten sich die Teilnehmer vor und versprechen, die Entscheidung ausführen zu können. In Phase zwei weist der Koordinator sie an, zu committen oder zurückzurollen. Fällt die Kommunikation nach der Vorbereitung aus, kann ein Teilnehmer im Zweifel bleiben, bis er die Entscheidung des Koordinators erfährt. Diese Unsicherheit ist ein Protokollstatus und kein gewöhnlicher Anwendungsfehler.

CICS kann verteilte Arbeit über geeignete Ressourcen und Konversationen hinweg koordinieren. Die Syncpoint-Dokumentation von IBM sagt, ein verteilter Prozess solle einen Syncpoint-Initiator haben, während Agenten die Anfrage akzeptieren oder einen Rollback erzwingen können. Der Recovery Manager protokolliert genug Status, um Arbeit nach Rückkehr einer Verbindung zu resynchronisieren. Eine Kette von HTTP-Aufrufen besitzt dieses Verhalten nicht von selbst.

Wer eine verteilte Arbeitseinheit durch Dienst A ruft Dienst B auf und wiederholt bei Fehler ersetzt, schafft eine Lücke ohne Besitzer. Wenn B committet und A die Antwort verliert, kann A nicht ableiten, ob es wiederholen, kompensieren oder Erfolg melden soll. Eine Wiederholung kann den Effekt verdoppeln. Eine Kompensation kann eine Aktion umkehren, die nie stattfand. Eine Fehlermeldung kann dem Benutzer sagen, die Aktion sei gescheitert, obwohl sie abgeschlossen wurde.

Es gibt zwei ehrliche Ersatzmuster. Halten Sie atomare Arbeit innerhalb einer Transaktionsgrenze, wenn die Daten unter einem Ressourcenmanager liegen können. Wenn Dienste getrennte Daten besitzen müssen, verwenden Sie einen ausdrücklichen Workflow mit dauerhaften Befehlen, idempotenten Konsumenten, einer Outbox oder einem gleichwertigen atomaren Nachrichteneintrag und als Geschäftsaktionen entworfenen Kompensationen. Das zweite Muster gibt sofortige Atomarität auf und muss die Zustände ausstehend, abgeschlossen, abgelehnt und Reparatur offenlegen.

Nennen Sie das zweite Muster nicht Zwei-Phasen-Commit. Eine Saga koordiniert getrennte Commits und mögliche Kompensationen. Zwei-Phasen-Commit koordiniert eine Entscheidung über vorbereitete Teilnehmer. Wer beides vermischt, verspricht atomisches Verhalten und implementiert nachträgliche Reparatur.

Der bekannte Wrapper-Fehler hat eine genaue Abfolge

Die nützlichste Fehleranalyse verfolgt einen Befehl über die Grenze und hält fest, was jede Seite wissen kann. Nehmen wir einen über einen POST-Endpunkt bereitgestellten CICS-Zahlungstask. Der Task prüft das Konto, aktualisiert Db2, schreibt einen wiederherstellbaren Datensatz für die weitere Verarbeitung und kehrt normal zurück.

1. Der Client sendet eine Anfrage mit der Zahlungsreferenz P7319.
2. Das Gateway startet den CICS-Task und wartet.
3. Der Task aktualisiert beide wiederherstellbaren Ressourcen und erreicht seinen Syncpoint am Taskende.
4. CICS committet, aber die Gateway-Verbindung schließt sich, bevor die Antwort den Client erreicht.
5. Der Client wiederholt wegen des beobachteten Timeouts, und ein zweiter Task erhält denselben Geschäftsbefehl.

Erzeugt das Programm bei jedem Aufruf eine neue Referenz, kann der zweite Task den ersten nicht erkennen. Prüft es nur den aktuellen Saldo, können beide Versuche trotzdem durchgehen. Erzeugt die HTTP-Schicht ein Idempotenz-Token, legt es aber nicht im selben Commit wie die Geschäftsänderung ab, kann ein Absturz Token und Zahlung in widersprüchlichem Zustand hinterlassen.

Die Korrektur beginnt mit einer clientstabilen Befehls-ID und einem atomaren Anspruch auf diese ID. Speichern Sie in der Einheit, die die Zahlung committet, Befehls-ID, Anfragefingerabdruck, Status und Ergebnisreferenz. Ein Duplikat mit demselben Fingerabdruck liefert das gespeicherte Ergebnis. Eine doppelte ID mit anderem Inhalt ist ein Konflikt. Eine Anfrage mit noch ausstehendem Ergebnis erhält eine wahrheitsgemäße Pending-Antwort statt einer blinden Wiederholung.

Eine minimale Grenzantwort könnte so aussehen:

{
  "command_id": "P7319",
  "workflow_version": 12,
  "status": "completed",
  "result_ref": "PAY-88421"
}

Dieser Datensatz unterdrückt nicht nur Duplikate. Er gibt dem Betrieb eine dauerhafte Antwort, wenn das Transportprotokoll mehrdeutig ist. Außerdem kann ein Ersatz damit das committete Ergebnis des alten Systems treffen, ohne so zu tun, als seien TCP-Auslieferung und Commit ein Ereignis.

Modellieren Sie die Grenze als Befehle und Zustände

Die Ersatzgrenze sollte Geschäftsabsicht, Workflowstatus und Commit-Verantwortung sichtbar machen. Beginnen Sie mit einer Zustandsübergangstabelle und nicht mit Controllern. Benennen Sie für jeden Befehl erlaubte Ausgangszustände, erforderliche Version, Validierung, wiederherstellbare Schreibvorgänge, nicht wiederherstellbare Effekte, Zielzustand und Duplikatverhalten.

Eine brauchbare Befehlshülle ist bewusst kleiner als die COMMAREA:

{
  "command_id": "7f6c2b1a",
  "workflow_id": "CLAIM-2048",
  "expected_version": 4,
  "action": "approve",
  "input": {
    "amount": "125.00",
    "currency": "USD"
  }
}

Der Handler lädt CLAIM-2048, prüft Version 4 und den Übergang approve, wendet die Geschäftsregeln an, schreibt den neuen Status samt Befehlsergebnis in einer lokalen Transaktion und liefert danach das gespeicherte Ergebnis zurück. Kann nachgelagerte Arbeit dieser Transaktion nicht beitreten, schreibt derselbe Commit einen Outbox-Eintrag. Ein Dispatcher kann die Auslieferung wiederholen, ohne den Geschäftsübergang zu wiederholen.

Halten Sie Protokollkonzepte aus dem Domänenmodell heraus. HTTP-Statuscodes beschreiben den Anfrageaustausch und sollten aus Domänenergebnissen abgeleitet werden. Eine veraltete Workflowversion kann 409 Conflict ergeben. Ein bereits abgeschlossener Befehl mit gleichem Fingerabdruck kann sein ursprüngliches Ergebnis liefern. Ein neuer, zur asynchronen Verarbeitung angenommener Befehl kann 202 Accepted mit einer Statusreferenz zurückgeben. Diese Zuordnungen sind Grenzrichtlinien und keine Konto- oder Schadensregeln.

Die nächste Transaktions-ID der Pseudokonversation wird zu einer Entscheidung über erlaubte Übergänge und nicht zu einer als Geschäftslogik verkleideten Weiterleitung. Die neue Oberfläche fragt die Workflowdarstellung, welche Aktionen verfügbar sind. Der Server setzt sie weiterhin durch. Ein Aufrufer kann nicht von der Prüfung zum Abschluss springen, indem er eine Route errät.

Dieser Entwurf beseitigt auch Terminalaffinität, ohne die Reihenfolge zu verlieren. Jede Dienstinstanz kann den nächsten Befehl verarbeiten, weil der dauerhafte Status Workflowversion und Ergebnis trägt. Muss ein Teil des Status privat beim Client bleiben, signieren und versionieren Sie ihn, prüfen sein Alter und rechnen mit Wiederholungen durch den Benutzer. Legen Sie keine Autorität, Preise oder Berechtigungsentscheidungen in ein unsigniertes Browser-Token.

Idempotenz braucht einen Wiederherstellungsvertrag

Ein Idempotenz-Header allein macht einen Befehl nicht sicher. Das System braucht Regeln für Geltungsbereich, Speicherung, Inhaltsabgleich, gleichzeitige Ankunft, Aufbewahrung und Wiederherstellung. Sonst ist der Header nur Dekoration um denselben mehrdeutigen Fehler.

Begrenzen Sie den Schlüssel auf Akteur und Operation, damit unabhängige Clients nicht kollidieren. Binden Sie ihn an einen kanonischen Anfragefingerabdruck. Erzwingen Sie Eindeutigkeit in der Datenbanktransaktion, die die Geschäftsänderung besitzt. Geben Sie das gespeicherte Ergebnis nur bei passendem Fingerabdruck zurück. Bestimmen Sie die Aufbewahrungszeit nach dem fachlichen Wiederholungsfenster und nicht nach einem bequemen Cache-Ablauf.

Bei gleichzeitigen Duplikaten darf es einen Gewinner geben. Eine Unique Constraint oder eine gesperrte Befehlszeile kann die Ausführung beanspruchen. Andere Versuche sollten pending sehen und pollen oder innerhalb einer strengen Grenze warten, statt die Arbeit neu zu starten. Stürzt der Gewinner vor dem Commit ab, sollten Anspruch und Geschäftsänderungen gemeinsam zurückrollen. Stürzt er nach dem Commit ab, müssen spätere Versuche den abgeschlossenen Datensatz finden.

Die Wiederherstellung braucht auch für Operatoren sichtbare Zustände. received, completed und rejected decken den sauberen Pfad ab, während dispatch_pending, compensation_pending und manual_review Arbeit beschreiben, die eine nichttransaktionale Grenze überschritten hat. Fassen Sie sie nicht alle als HTTP 500 zusammen. Ein Operator braucht Befehls-ID, Workflow-ID, letzten dauerhaften Übergang, versuchten Effekt und die sichere nächste Aktion.

Wiederholungen gehören auf die Ebene, die weiß, ob eine Operation wiederholbar ist. Eine Transportbibliothek darf den Verbindungsaufbau oder einen schreibgeschützten Abruf wiederholen. Sie sollte einen zustandsändernden POST nicht still wiederholen, sofern die Anwendung keinen Idempotenzvertrag liefert. Innerhalb des Systems kann ein Outbox-Dispatcher eine Nachricht erneut senden, weil der Konsument anhand der Nachrichten-ID dedupliziert und der Produzent die Absicht bereits committet hat.

Das ist strenger als bei vielen CICS-Wrappern, beschreibt aber Schutz, den CICS früher durch Task-Wiederherstellung und koordinierte Syncpoints lieferte. Sobald die Arbeit über einfaches HTTP und unabhängige Datenbanken läuft, muss die Anwendung die Unsicherheit ausdrücklich besitzen.

Der Adapter muss den Besitzer des Commits benennen

Ein HTTP-Adapter kann außerhalb von CICS, innerhalb einer CICS-Region oder über Gateway und Distributed Program Link laufen. Die Platzierung verändert Latenz und Betrieb, aber die Commit-Verantwortung ist wichtiger. Die Komponente, die Erfolg meldet, muss wissen, ob die Arbeitseinheit committet hat. Sie darf nie andeuten, ein Fernaufruf nehme an ihrer lokalen Transaktion teil, sofern kein unterstützter Koordinator dies wirklich sicherstellt.

Ein dünner Adapter außerhalb von CICS sollte die alte Transaktion als Befehlsprozessor mit mehrdeutigem Transportergebnis behandeln. Er sendet eine stabile Befehls-ID, wartet auf ein Ergebnis und kann dieses nach einem Timeout abfragen. Er eröffnet nicht lokal eine Datenbanktransaktion, ruft CICS auf, aktualisiert seine eigene Tabelle und nimmt an, beide Commits bildeten eine Aktion. Ohne verteilte Koordination sind das zwei Commits mit einer Fehlerlücke dazwischen.

Ein Adapter mit Distributed Program Link verlangt dieselbe Sorgfalt. Ein verknüpftes Serverprogramm besitzt den Syncpoint nicht immer. IBM dokumentiert, dass ein DPL-Server ohne SYNCONRETURN keinen unabhängigen Syncpoint ausführen kann. Der Client besitzt die verteilte Arbeitseinheit. Mit SYNCONRETURN kann der Server bei der Rückgabe unabhängig committen, trennt seine Änderungen damit aber auch von früherer Arbeit des Aufrufers. Diese Option ist eine Transaktionsentscheidung und kein Performance-Schalter.

Schreiben Sie vor der Platzierungsentscheidung die Antworten auf vier Fragen auf:

• Welcher Prozess vergibt die stabile Befehls-ID?
• Welche Ressource speichert das maßgebliche Befehlsergebnis?
• Welcher Koordinator deckt gegebenenfalls alle wiederherstellbaren Teilnehmer ab?
• Wie löst ein Aufrufer einen Timeout auf, ohne den Effekt zu wiederholen?

Wenn die Antworten zwei unabhängige Datenbanken und keinen Koordinator nennen, entwerfen Sie eine asynchrone Grenze. Committen Sie Befehl und Outbox-Eintrag gemeinsam auf der initiierenden Seite. Lassen Sie die CICS-Seite die Befehls-ID beanspruchen und ihr Ergebnis zusammen mit der alten Aktualisierung speichern. Gleichen Sie Bestätigungen ab, ohne ihre Zustellung als Geschäfts-Commit zu behandeln. Das fügt Zustände hinzu, doch diese Zustände beschreiben bereits vorhandene Unsicherheit.

Synchrones HTTP kann weiterhin vor diesem Workflow liegen. Der Adapter kann kurz auf completed oder rejected warten und danach 202 Accepted zurückgeben, falls die Verarbeitung weiterläuft. Eine Statusabfrage meldet das dauerhafte Befehlsergebnis. Im Normalfall sieht der Benutzer einen schnellen Abschluss und bei Verzögerungen einen ehrlichen Pending-Status. Halten Sie die HTTP-Verbindung nicht unbegrenzt offen, um einen konversationellen Task nachzuahmen.

Sicherheitsgrenzen sollten demselben ausdrücklichen Modell folgen. Authentifizieren Sie den Aufrufer am Webrand, übergeben Sie aber nur einen eingeschränkten Principal und autorisierten Befehlskontext an den Transaktionshandler. Vertrauen Sie einer Kontonummer, Operatorkennung oder einem Berechtigungs-Flag nicht allein deshalb, weil der Wert früher in einer geschützten COMMAREA lag. Werte aus Browser oder Message Broker müssen bei der Instanz erneut geprüft werden, die den Übergang anwendet.

Bewahren Sie den ursprünglichen CICS-Antwortcode und Diagnosekontext im Nachweisdatensatz des Adapters auf und ordnen Sie beides dann einem kleinen öffentlichen Fehlervertrag zu. Jeder offengelegte EIBRESP-Wert koppelt Aufrufer an die Implementierung. Alle Werte zu verwerfen erschwert Paritätsanalyse und Operatorreparatur. Die Grenze braucht beide Sichten: ein stabiles Domänenergebnis für Aufrufer und genug Altdetails für das Team, das gleichwertiges Verhalten belegt.

Paritätstests müssen unterbrochene Konversationen einschließen

Ein Vergleich der Felder im Erfolgsfall beweist diese Migration nicht. Der Paritätsharness muss committetes Verhalten über Taskgrenzen, Wiederholungen, Abbrüche, veraltete Fortsetzungsdaten und Fehler nahe am Syncpoint vergleichen. Eine Maske mit denselben Summen kann trotzdem eine andere Arbeitseinheit verbergen.

Erzeugen Sie Traces aus aufgezeichnetem Produktionsverkehr nur nach den Datenverarbeitungsregeln der Organisation. Erfassen Sie pro Fall dauerhaften Ausgangsstatus, Eingabebytes und decodierte Felder, aufgerufene Transaktion, Ressourcenänderungen, Syncpoint-Positionen, Ausgabefelder, nächste Transaktion und dauerhaften Endstatus. Maskierung muss Unterschiede erhalten, die Verzweigungen steuern, etwa Leerzeichen gegenüber Low Values oder zwei Codes mit derselben Anzeigebezeichnung.

Führen Sie alten und neuen Pfad gegen isolierte, zurücksetzbare Daten aus. Vergleichen Sie Geschäftsergebnisse und nicht Implementierungsrauschen. Zeitstempel, erzeugte Kennungen und Datensatzreihenfolge können Normalisierung brauchen. Beträge, Status, Berechtigungsentscheidungen und committete Nebeneffekte müssen exakt übereinstimmen.

Die Fehlermatrix sollte mindestens diese Prüfungen enthalten:

• Wiederholen Sie denselben Befehl vor und nach seinem Abschluss.
• Verwerfen Sie die Antwort nach dem Commit und wiederholen Sie mit derselben Befehls-ID.
• Erzwingen Sie einen Fehler vor dem Syncpoint und direkt nach einem nicht wiederherstellbaren Effekt.
• Senden Sie einen gültigen Befehl mit veralteter Workflowversion.
• Setzen Sie mit jeder unterstützten COMMAREA-Länge und -Version fort.

CodeHero nutzt beim Neuschreiben von CICS und angrenzendem Altcode einen Paritätsharness gegen aufgezeichneten Produktionsverkehr, weil Ähnlichkeit auf Quelltextebene solche Wiederherstellungsunterschiede nicht zeigt. Derselbe Harness sollte vor Schreibzugriffen Grenzfehler injizieren und nicht nur saubere Anfragen abspielen.

Verhalten bewahren, ohne den Zufall zu bewahren

Korrekte Modellierung verlangt nicht, CICS in einem Webdienst nachzubauen. Sie verlangt die Regeln zu bewahren, die Benutzer und verbundene Systeme beobachten können: welche Befehle erlaubt sind, welche Änderungen gemeinsam committen, wie sich ein Duplikat verhält, wie unfertige Arbeit erscheint und wie die Wiederherstellung einen bekannten Zustand erreicht.

Einige alte Details dürfen verschwinden. Eine vierstellige Transaktions-ID muss kein Routenname werden. Ein COMMAREA-Layout muss keine öffentliche Nutzlast werden. Terminalaffinität muss nicht als Sticky Session weiterleben. Eine Ressourcenmanagergrenze sollte so lange bestehen bleiben, bis das Team ihre Atomarität bewusst durch ein Workflow- und Reparaturmodell ersetzt hat.

Schreiben Sie für jeden Geschäftsbefehl eine Grenzspezifikation. Halten Sie stabile Identität, akzeptierten Ausgangszustand, Versionsregel, Transaktionsbesitzer, Effekte innerhalb des Commits, Effekte außerhalb, Duplikatergebnis und Reparaturaktion des Operators fest. Prüfen Sie das Dokument mit den Menschen, die heute CICS-Fehler diagnostizieren. Sie finden im ersten Entwurf meist einen impliziten Syncpoint, ein Queue-Verhalten oder eine Neustartannahme, die fehlt.

Der harte Test ist eine verlorene Antwort nach erfolgreichem Commit. Wenn der neue Entwurf genau sagen kann, was der Client wiederholt, was der Server liest, welches Ergebnis er zurückgibt und warum sich kein Geschäftseffekt wiederholt, ist die Grenze wahrscheinlich echt. Hängt die Antwort davon ab, dass Anfrage und Transaktion gemeinsam enden, verwechselt der Entwurf HTTP weiterhin mit CICS.