Une transaction CICS n'est pas une requête HTTP

La modernisation CICS la plus dangereuse est celle qui paraît évidente. Une équipe trouve un code de transaction, emballe son entrée dans du JSON, lui donne une route POST et considère que la frontière est comprise. Les écrans fonctionnent en démonstration. Puis, avec le trafic réel, arrivent les envois en double, les états périmés, les commits prématurés et les mises à jour distribuées incomplètes.

Une transaction CICS est une tâche avec des ressources gérées par CICS, des règles de reprise et une fin précise. Une requête HTTP est un échange de transport dont le serveur peut perdre le client avant que l'un ou l'autre sache ce qui s'est passé. Les deux peuvent porter la même commande métier, mais ne définissent pas la même unité de travail. Une réécriture sûre conserve la machine à états métier et rend la frontière de commit explicite au lieu de laisser le framework web l'inventer.

La frontière de la tâche détermine la sémantique

Une transaction CICS commence lorsque CICS attache une tâche et se termine quand le programme de plus haut niveau rend le contrôle ou quand la tâche s'arrête. Cette tâche peut appeler plusieurs programmes avec LINK ou transférer le contrôle avec XCTL. Ces appels ne créent pas de nouvelles transactions simplement parce que le contrôle franchit une frontière de module. L'identifiant de transaction choisit un point d'entrée. Il ne décrit ni une méthode de requête, ni une ressource, ni un contrat de réponse.

HTTP fournit une enveloppe différente. Une requête a des en-têtes, un corps, une connexion et une réponse, mais le protocole ignore quelles écritures en base constituent une seule action métier. Un serveur peut committer avant d'envoyer la réponse. Le client peut dépasser son délai après le commit et réessayer. Un proxy peut répéter une requête que l'application n'a jamais déclarée sûre. Aucun de ces événements n'a d'équivalent direct dans le modèle de tâche CICS.

La première question de conception n'est donc pas de savoir quelle URL remplacera un identifiant de transaction à quatre caractères. Demandez quelles modifications récupérables doivent réussir ou échouer ensemble, quelle entrée déclenche cette décision et quel fait durable prouve son achèvement. Une route ne peut représenter honnêtement la commande qu'après ces réponses.

Cette distinction évite aussi une erreur fréquente de granularité. Une interaction avec un écran peut exécuter une tâche CICS, plusieurs programmes liés et des mises à jour dans Db2 ainsi que dans des ressources CICS récupérables. Transformer chaque programme en service réseau ajoute des points de panne au milieu d'une unité qui échouait auparavant en bloc. Regrouper plusieurs étapes pseudo-conversationnelles dans une longue requête HTTP produit l'erreur inverse: le travail reste ouvert pendant qu'une personne réfléchit.

Considérez le graphe d'appels historique comme une preuve, pas comme l'architecture cible. Marquez les débuts de tâches, les arêtes LINK et XCTL, les mises à jour de fichiers et de bases, les messages sortants, les points de synchronisation explicites et les retours de plus haut niveau. Les contours tracés autour du travail récupérable correspondent rarement aux écrans ou aux limites des programmes.

La pseudo-conversation libère la tâche entre les écrans

Une application pseudo-conversationnelle ressemble à une session pour l'utilisateur, mais s'exécute comme une suite de tâches courtes. Une tâche reçoit une entrée, reconstruit le contexte nécessaire à son traitement, envoie l'écran suivant, nomme la transaction qui traitera la prochaine entrée, transmet les données de continuation et rend le contrôle à CICS. Pendant que l'utilisateur lit l'écran, aucune tâche applicative n'attend sa réponse.

La documentation CICS d'IBM décrit ce fonctionnement comme des transactions non conversationnelles incorporées dans une séquence. Cette conception économise la mémoire et évite de retenir des ressources exclusives pendant le temps de réflexion humain. Cette formulation compte, car la conversation apparente relève de l'expérience utilisateur, pas d'une transaction continue.

Une sortie COBOL simplifiée a souvent cette forme:

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

Dans le cas ordinaire, RETURN TRANSID n'appelle pas immédiatement AC02. Il indique à CICS quelle transaction doit recevoir la prochaine entrée du terminal. La tâche courante se termine. À l'arrivée de cette entrée, CICS attache une nouvelle tâche et le premier programme peut adresser la COMMAREA transmise. Un channel peut aussi remplir ce rôle de continuation.

Associer cette séquence à un unique objet de session HTTP masque généralement deux éléments indépendants. Le navigateur possède un état de présentation, comme la page courante et les champs modifiables. L'application possède un état de workflow, comme le compte sélectionné, la version lue, les droits vérifiés et les commandes désormais autorisées. Cette seconde catégorie exige une représentation versionnée côté serveur ou un jeton protégé contre les modifications. Une table de session en mémoire du processus n'est ni assez durable ni assez claire.

La frontière moderne doit exposer chaque décision de l'utilisateur sous forme de commande courte. Un GET peut récupérer une projection à afficher. Un POST peut soumettre une décision sur une version du workflow. Aucune transaction de base ne reste ouverte pendant l'attente du navigateur. Cette approche reste proche de l'intention opérationnelle de la pseudo-conversation, même si le transport est très différent.

Une COMMAREA est un contrat de continuation, pas une session

Une COMMAREA est un contrat binaire transmis entre des programmes ou des tâches successives. Son copybook donne un sens à ces octets. Elle peut contenir un code de fonction, des identifiants, des indicateurs, des champs d'affichage, des codes de retour et les données nécessaires à la tâche suivante. Elle peut aussi contenir des restes historiques qu'aucun chemin actif ne lit. Appeler toute la structure «état de session» évite l'analyse dont la migration a justement besoin.

Dans une pseudo-conversation, CICS garde la COMMAREA transmise à disposition du premier programme de la tâche suivante. IBM documente une limite importante: la COMMAREA n'est pas récupérable. Si une tâche committe une modification de base puis prépare des octets de continuation, ces octets n'intègrent pas la même ressource récupérable au seul motif que CICS les transmet.

La limite pratique de taille avertit également qu'il ne faut pas la traiter comme un magasin d'objets. La limite théorique documentée pour RETURN est d'environ 32 Ko, et IBM a historiquement recommandé une taille sûre plus faible. Les channels et containers suppriment la contrainte de taille d'une COMMAREA unique et rangent les données dans des compartiments nommés, mais ils ne transforment pas les données de continuation en vérité métier durable.

Au décodage, classez chaque COMMAREA en trois catégories. L'identité métier comprend les valeurs stables telles que numéro de client, identifiant de sinistre ou identifiant de commande. Le contrôle du workflow comprend l'étape, le code de fonction, l'action précédente et la version optimiste. Les résidus de présentation comprennent les libellés copiés, les constantes d'écran, les choix de curseur et les champs qui peuvent être relus. Stockez durablement l'état métier, modélisez explicitement le contrôle du workflow et supprimez les résidus de présentation sauf si le comportement observable en dépend.

La gestion de la longueur fait partie du contrat. Un programme COBOL récepteur vérifie souvent EIBCALEN avant de lire DFHCOMMAREA; les versions ultérieures d'un copybook peuvent ajouter des champs. Un décodeur JSON qui exige tous les nouveaux champs peut être moins compatible que l'ancien programme. Relevez les longueurs acceptées, les règles d'initialisation, les conventions d'espaces et de zéros, la conversion EBCDIC, les formats décimaux compactés et les branches de redéfinition avant de concevoir un remplacement typé.

Ne sérialisez pas le copybook dans un énorme document JSON en prétendant préserver le comportement. Vous exposeriez la disposition mémoire comme API publique, transporteriez des champs que les clients ne doivent jamais contrôler et transformeriez chaque évolution du copybook en changement d'API. Traduisez les octets en une commande à l'intention nommée, puis ne gardez l'entrée brute que dans les jeux de test et les preuves d'audit, lorsque la politique l'autorise.

Un point de synchronisation committe une unité de travail, pas une réponse

CICS committe les modifications récupérables à un point de synchronisation. L'application peut lancer EXEC CICS SYNCPOINT, et CICS place aussi un point implicite quand une tâche de plus haut niveau se termine normalement. Un arrêt anormal déclenche en général le backout dynamique des modifications apportées aux ressources récupérables dans l'unité de travail courante. Ce cycle de vie n'a aucun rapport automatique avec l'arrivée d'une réponse HTTP chez l'appelant.

La conséquence passe facilement inaperçue dans un wrapper. Supposons que la tâche mette à jour Db2, écrive dans une file récupérable, revienne normalement et que la passerelle perde sa connexion avant de remettre la réponse. CICS a committé. L'appelant voit un délai dépassé. Si le remplacement interprète ce délai comme un échec et répète la commande sans règle d'idempotence, il exécute deux fois l'action métier.

L'échec inverse est également possible. Un gestionnaire web peut écrire un statut 200 OK dans un tampon, puis échouer lorsque le commit de sa base intervient après le retour du code applicatif. Les abstractions du framework peuvent faire passer la construction de la réponse pour un achèvement alors que l'achèvement durable n'a pas eu lieu. Le remplacement doit définir le succès comme un résultat métier committé et organiser l'émission de la réponse autour de ce fait.

Inventoriez chaque point de synchronisation explicite au lieu de supposer que la fin de tâche est le seul. Un point explicite clôt l'unité de travail courante et en commence une autre pendant que la tâche continue. Un rollback ne peut annuler que les modifications depuis le dernier point, pas tout ce que la tâche a fait. Si un programme committe une ligne d'audit à mi-parcours puis annule plus tard une mise à jour de compte, entourer tout le gestionnaire d'une seule transaction de base change le comportement de reprise visible.

Les effets non récupérables demandent un traitement séparé. Un appel vers un service externe, un e-mail remis à un système non transactionnel ou une écriture vers une destination non récupérable ne sera pas annulé avec le travail Db2. L'ancienne application peut compter sur l'ordre, les nouvelles tentatives ou une réparation manuelle autour de ces effets. Conservez le résultat, pas la fiction rassurante qu'une transaction du langage contrôle chaque ressource.

Le commit en deux phases ne se remplace pas par des tentatives optimistes

Le commit en deux phases coordonne des gestionnaires de ressources récupérables dans une unité de travail distribuée. Pendant la première phase, les participants se préparent et promettent de pouvoir honorer la décision. Pendant la seconde, le coordinateur leur ordonne de committer ou d'annuler. Si la communication tombe après la préparation, un participant peut rester dans le doute jusqu'à connaître la décision du coordinateur. Cette incertitude est un état de protocole, pas une erreur applicative ordinaire.

CICS peut coordonner du travail distribué entre des ressources et conversations compatibles. La documentation d'IBM sur les points de synchronisation indique qu'un processus distribué doit avoir un initiateur, tandis que les agents peuvent accepter la demande ou imposer un rollback. Le gestionnaire de reprise journalise assez d'état pour resynchroniser le travail au retour d'une connexion. Une chaîne d'appels HTTP ne possède pas ce comportement par défaut.

Remplacer une unité de travail distribuée par le service A appelle le service B, puis réessaie en cas d'erreur crée un vide sans responsable. Si B committe et qu'A perd la réponse, A ne peut pas déduire s'il faut réessayer, compenser ou annoncer le succès. Une nouvelle tentative peut doubler l'effet. Une compensation peut inverser une action qui n'a jamais eu lieu. Une erreur peut dire à l'utilisateur que l'action a échoué alors qu'elle s'est achevée.

Deux modèles de remplacement sont honnêtes. Gardez le travail atomique dans une seule frontière transactionnelle lorsque les données peuvent dépendre d'un seul gestionnaire de ressources. Si les services doivent posséder des données séparées, utilisez un workflow explicite avec des commandes durables, des consommateurs idempotents, une outbox ou un enregistrement de message atomique équivalent et des compensations conçues comme des opérations métier. Ce second modèle abandonne l'atomicité instantanée et doit exposer les états en attente, terminé, rejeté et à réparer.

N'appelez pas ce second modèle commit en deux phases. Une saga coordonne des commits distincts et d'éventuelles compensations. Le commit en deux phases coordonne une décision unique entre des participants préparés. Les confondre conduit une équipe à promettre un comportement atomique tout en mettant en place une réparation ultérieure.

L'échec classique du wrapper suit une séquence précise

L'analyse de panne la plus utile suit une commande à travers la frontière et note ce que chaque côté peut savoir. Prenons une tâche de paiement CICS exposée par un point d'accès POST. Elle vérifie le compte, met à jour Db2, écrit un enregistrement récupérable destiné au traitement aval et revient normalement.

1. Le client envoie une requête avec la référence de paiement P7319.
2. La passerelle démarre la tâche CICS et attend.
3. La tâche met à jour les deux ressources récupérables et atteint son point de synchronisation de fin.
4. CICS committe, mais la connexion de la passerelle se ferme avant que la réponse atteigne le client.
5. Le client réessaie après le délai dépassé, et une seconde tâche reçoit la même commande métier.

Si le programme crée une nouvelle référence à chaque appel, la seconde tâche ne peut pas reconnaître la première. S'il vérifie uniquement le solde courant, les deux tentatives peuvent encore passer. Si la couche HTTP crée un jeton d'idempotence sans le placer dans le même commit que la mise à jour métier, une panne peut laisser le jeton et le paiement en désaccord.

La correction commence par un identifiant de commande stable côté client et une réservation atomique de cet identifiant. Dans l'unité qui committe le paiement, stockez l'identifiant, une empreinte de la requête, le statut et la référence du résultat. Un doublon avec la même empreinte reçoit le résultat enregistré. Le même identifiant avec un contenu différent est un conflit. Une requête dont le résultat reste en attente reçoit un statut sincère plutôt qu'une nouvelle tentative aveugle.

Une réponse minimale à la frontière peut ressembler à ceci:

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

Cet enregistrement ne se contente pas de supprimer les doublons. Il donne aux opérations une réponse durable quand la trace du transport est ambiguë. Il permet aussi au remplacement de reproduire le résultat committé de l'ancien système sans prétendre que la livraison TCP et le commit formaient un seul événement.

Modélisez la frontière avec des commandes et des états

La nouvelle frontière doit rendre visibles l'intention métier, l'état du workflow et la responsabilité du commit. Commencez par une table de transitions plutôt que par des contrôleurs. Pour chaque commande, nommez les états antérieurs permis, la version requise, la validation, les écritures récupérables, les effets non récupérables, l'état obtenu et le comportement en cas de doublon.

Une enveloppe de commande utile est volontairement plus petite que la COMMAREA:

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

Le gestionnaire charge CLAIM-2048, vérifie la version 4 et la transition approve, applique les règles métier, écrit le nouvel état avec le résultat de la commande dans une transaction locale, puis renvoie le résultat enregistré. Si le travail aval ne peut pas rejoindre cette transaction, le même commit écrit une entrée d'outbox. Un dispatcher peut réessayer la livraison sans répéter la transition métier.

Écartez les concepts de protocole du modèle de domaine. Les codes de statut HTTP décrivent l'échange de requête et doivent découler des résultats du domaine. Une version périmée du workflow peut produire 409 Conflict. Une commande déjà achevée avec la même empreinte peut rendre son résultat d'origine. Une nouvelle commande acceptée pour un traitement asynchrone peut renvoyer 202 Accepted avec une référence de statut. Ces correspondances sont des règles de frontière, pas des règles de compte ou de sinistre.

L'identifiant de la prochaine transaction pseudo-conversationnelle devient une décision sur les transitions permises, pas une redirection déguisée en logique métier. La nouvelle interface demande à la représentation du workflow quelles actions sont disponibles. Le serveur continue de les imposer. Un appelant ne peut pas passer de l'examen à l'achèvement simplement en devinant une route.

Cette conception supprime aussi l'affinité au terminal sans perdre la séquence. N'importe quelle instance du service peut traiter la commande suivante, car l'état durable porte la version du workflow et le résultat. Si un état doit rester privé chez le client, signez-le, versionnez-le, vérifiez son âge et supposez que l'utilisateur peut le rejouer. Ne placez ni autorité, ni prix, ni décision de permission dans un jeton de navigateur non signé.

L'idempotence exige un contrat de reprise

Un en-tête d'idempotence ne suffit pas à sécuriser une commande. Le système a besoin de règles sur la portée, la persistance, la correspondance du contenu, les arrivées concurrentes, la conservation et la reprise. Sinon, l'en-tête décore la même panne ambiguë.

Limitez la clé à l'acteur et à l'opération pour éviter les collisions entre clients indépendants. Liez-la à une empreinte canonique de la requête. Imposez l'unicité dans la transaction de base qui possède le changement métier. Ne rendez le résultat stocké que si l'empreinte correspond. Fixez la durée d'autorité des enregistrements selon la fenêtre métier de répétition, pas selon une expiration de cache commode.

Parmi des doublons concurrents, un seul doit gagner. Une contrainte unique ou une ligne de commande verrouillée peut réserver l'exécution. Les autres tentatives doivent observer pending et interroger l'état, ou attendre dans une limite stricte, au lieu de redémarrer le travail. Si le gagnant tombe avant le commit, sa réservation et ses écritures métier doivent être annulées ensemble. S'il tombe après le commit, les tentatives suivantes doivent trouver l'enregistrement terminé.

La reprise demande aussi des états visibles par les opérateurs. received, completed et rejected couvrent le chemin normal, tandis que dispatch_pending, compensation_pending et manual_review décrivent le travail qui a franchi une frontière non transactionnelle. Ne réduisez pas tout à HTTP 500. Un opérateur a besoin de l'identifiant de commande, de l'identifiant du workflow, de la dernière transition durable, de l'effet tenté et de l'action suivante sûre.

Les nouvelles tentatives appartiennent à la couche qui sait si l'opération peut être répétée. Une bibliothèque de transport peut réessayer une connexion ou une lecture seule. Elle ne doit pas répéter silencieusement un POST qui change l'état sans contrat d'idempotence fourni par l'application. Dans le système, un dispatcher d'outbox peut renvoyer un message parce que le consommateur déduplique par identifiant et que le producteur a déjà committé l'intention.

Cette discipline est plus stricte que celle de nombreux wrappers CICS, mais elle exprime une protection auparavant fournie par la reprise des tâches et la synchronisation coordonnée de CICS. Dès que le travail traverse du HTTP simple et des bases indépendantes, l'application doit prendre explicitement en charge l'incertitude.

L'adaptateur doit désigner le propriétaire du commit

Un adaptateur HTTP peut s'exécuter hors de CICS, dans une région CICS ou au travers d'une passerelle et d'un Distributed Program Link. Son emplacement change la latence et l'exploitation, mais la propriété du commit compte davantage. Le composant qui annonce le succès doit savoir si l'unité de travail a committé et ne doit jamais laisser croire qu'un appel distant rejoint sa transaction locale si aucun coordinateur pris en charge ne l'assure réellement.

Un adaptateur léger hors de CICS doit traiter la transaction historique comme un processeur de commandes au résultat de transport ambigu. Il envoie un identifiant stable, attend un résultat et peut interroger ce résultat après un délai dépassé. Il ne démarre pas une transaction locale, n'appelle pas CICS, ne met pas à jour sa propre table en supposant que les deux commits forment une action. Sans coordination distribuée, cette séquence comporte deux commits et une zone de panne entre eux.

Un adaptateur qui utilise Distributed Program Link exige la même prudence. Un programme serveur lié ne possède pas toujours le point de synchronisation. IBM précise qu'un serveur DPL sans SYNCONRETURN ne peut pas lancer un point indépendant; le client possède l'unité de travail distribuée. Avec SYNCONRETURN, le serveur peut committer de manière indépendante à son retour, mais cela sépare également ses modifications du travail antérieur de l'appelant. Cette option est un choix de conception transactionnelle, pas un réglage de performances.

Avant de choisir l'emplacement, écrivez les réponses à quatre questions:

• Quel processus attribue l'identifiant stable de commande?
• Quelle ressource conserve le résultat de commande qui fait autorité?
• Quel coordinateur couvre tous les participants récupérables, s'il en existe un?
• Comment l'appelant résout-il un délai dépassé sans répéter l'effet?

Si les réponses citent deux bases indépendantes et aucun coordinateur, concevez une frontière asynchrone. Committez ensemble la commande et l'entrée d'outbox du côté initiateur. Laissez le côté CICS réserver l'identifiant et enregistrer son résultat avec la mise à jour historique. Réconciliez les accusés de réception sans confondre leur livraison avec le commit métier. Cela ajoute des états, mais ils décrivent une incertitude déjà présente.

HTTP synchrone peut toujours se placer devant ce workflow. L'adaptateur peut attendre brièvement completed ou rejected, puis rendre 202 Accepted si le traitement continue. Une lecture de statut rapporte le résultat durable de la commande. L'utilisateur obtient un achèvement rapide dans le cas normal et un état d'attente sincère lors d'un retard. Ne gardez pas la connexion HTTP ouverte indéfiniment pour imiter une tâche conversationnelle.

Les frontières de sécurité doivent suivre le même modèle explicite. Authentifiez l'appelant à l'entrée web, mais ne transmettez au gestionnaire de transaction qu'un principal limité et un contexte de commande autorisé. Ne faites pas confiance à un numéro de compte, un code opérateur ou un indicateur d'autorisation sous prétexte qu'il se trouvait autrefois dans une COMMAREA protégée. Les valeurs qui traversent un navigateur ou un courtier de messages doivent être validées à nouveau par l'autorité qui applique la transition.

Conservez le code de réponse CICS d'origine et le contexte de diagnostic dans le dossier de preuve de l'adaptateur, puis traduisez-les vers un petit contrat d'erreur public. Exposer chaque valeur EIBRESP couple les appelants à l'implémentation. Les jeter complique le diagnostic de parité et la réparation manuelle. La frontière a besoin des deux vues: un résultat de domaine stable pour les appelants et assez de détails historiques pour l'équipe qui prouve l'équivalence.

Les tests de parité doivent casser les conversations

Comparer les champs sur le chemin normal ne prouvera pas cette migration. Le banc de parité doit comparer le comportement committé à travers les frontières de tâches, les nouvelles tentatives, les arrêts anormaux, les données de continuation périmées et les pannes près du point de synchronisation. Un écran qui affiche les mêmes totaux peut masquer une unité de travail différente.

Construisez des traces à partir du trafic de production enregistré seulement après application des règles de traitement des données de l'organisation. Pour chaque cas, capturez l'état durable initial, les octets d'entrée et les champs décodés, la transaction invoquée, les changements de ressources, les emplacements des points, les champs de sortie, la transaction suivante et l'état durable final. Le masquage doit conserver les différences qui commandent les branches, comme les espaces face aux valeurs basses ou deux codes ayant le même libellé.

Exécutez les anciens et nouveaux chemins sur des données isolées et réinitialisables. Comparez les résultats métier, pas le bruit d'implémentation. Les horodatages, identifiants générés et ordres d'enregistrement peuvent demander une normalisation, mais les montants, statuts, décisions d'autorisation et effets secondaires committés doivent correspondre exactement.

La matrice de panne doit au moins contenir ces contrôles:

• Répétez la même commande avant et après son achèvement.
• Perdez la réponse après le commit, puis recommencez avec le même identifiant.
• Forcez une panne avant le point de synchronisation et juste après un effet non récupérable.
• Soumettez une commande valide avec une version de workflow périmée.
• Reprenez avec chaque longueur et version de COMMAREA prise en charge.

CodeHero utilise un banc de parité avec du trafic de production enregistré lors de la réécriture de CICS et du code historique voisin, car une ressemblance du code source ne révèle pas ces différences de reprise. Le même banc doit injecter des pannes de frontière, pas seulement rejouer des requêtes propres, avant que quiconque ne confie des écritures au remplacement.

Conservez le comportement, pas les accidents historiques

Une modélisation correcte n'impose pas de recréer CICS dans un service web. Elle impose de conserver les règles observables par les utilisateurs et les systèmes reliés: commandes autorisées, modifications committées ensemble, traitement d'un doublon, représentation du travail inachevé et retour de la reprise à un état connu.

Certains détails historiques peuvent disparaître. Un identifiant à quatre caractères n'a pas besoin de devenir un nom de route. Une disposition COMMAREA n'a pas besoin de devenir une charge utile publique. L'affinité au terminal n'a pas besoin de devenir une session persistante. Une frontière de gestionnaire de ressources doit subsister jusqu'à ce que l'équipe ait sciemment remplacé son atomicité par un modèle de workflow et de réparation.

Rédigez une spécification de frontière pour chaque commande métier. Incluez son identité stable, son état antérieur accepté, sa règle de version, le propriétaire de la transaction, les effets dans le commit, les effets hors commit, le résultat d'un doublon et l'action de reprise de l'opérateur. Relisez ce document avec les personnes qui diagnostiquent aujourd'hui les pannes CICS. Elles trouvent souvent dans le premier brouillon un point implicite, un comportement de file ou une hypothèse de redémarrage manquante.

Le test difficile est une réponse perdue après un commit réussi. Si la nouvelle conception peut dire précisément ce que le client répète, ce que le serveur lit, quel résultat il rend et pourquoi aucun effet métier ne se répète, la frontière est probablement réelle. Si la réponse suppose que la requête et la transaction se terminent ensemble, la conception confond encore HTTP et CICS.