Problèmes des mainframes affectant la récupération des transactions
Dans certains cas, TI ne peut pas traiter de nouvelles transactions avec un environnement distant. Il peut s’agir d’un comportement correct. Par exemple, si l’exception TI 1227 est retournée à une application cliente ou enregistrée dans un événement, et que le HRESULT est 8004D110, cela indique que les nouvelles transactions avec cet environnement distant ne peuvent pas être acceptées, car les transactions précédentes n’ont pas été résolues après un échec de communication.
Lorsque le processus de validation en deux phases ne se termine pas, CICS doit conserver la transaction dans l’état In-Doubt jusqu’à ce que les communications soient rétablies. Ensuite, TI effectuera des protocoles de récupération pour s’assurer que la transaction est dans le même état à tous les nœuds. CICS doit être configuré correctement pour que cela se produise.
Si CICS se termine de manière inattendue, puis qu’il est redémarré à froid, il n’y a pas de mémoire dans son journal des transactions qui n’ont pas été effectuées. Par conséquent, ces transactions ne peuvent pas être récupérées automatiquement à un état cohérent. Vérifiez que toutes les transactions sont terminées avant d’arrêter CICS, ou configurez CICS pour un redémarrage à chaud à l’aide du même journal afin que toutes les transactions en attente puissent être récupérées.
Le serveur de transactions CICS permet à l’administrateur de spécifier un temps d’attente dans les attributs In-Doubt d’une transaction. Veillez à spécifier une valeur qui est adéquate pour permettre aux communications d’être rétablies dans la plupart des cas. Si ce délai d’expiration s’écoule avant que toutes les transactions restantes à l’état In-Doubt aient été récupérées, CICS prend une décision heuristique de les résoudre localement. Si cette décision est en conflit avec la décision prise pour les transactions par Microsoft DTC (Distributed Transaction Coordinator), les nouvelles transactions ne peuvent pas être démarrées tant que le résultat des transactions précédentes n’a pas été remplacé manuellement.
Dans les versions CICS antérieures au serveur de transaction CICS, il n’y a pas de temps d’attente dans les attributs De récupération. L’attribution de la valeur Wait à l’attribut In-Doubt n’oblige pas CICS à placer la transaction dans l’état demandé par TI lors de la tentative de récupération. Si vous utilisez ces versions de CICS, définissez l’attribut In-Doubt sur Backout ou Commit. Si une décision heuristique résultante est incorrecte et empêche le début de nouvelles transactions, remplacez le résultat de la transaction à l’aide de DTC.
Examinez le journal des événements Windows pour les messages du service SNA LU 6.2 Resync TP indiquant que les transactions n’ont pas été récupérées avec succès. Suivez les actions suggérées. Utilisez la fenêtre Liste des transactions de Microsoft Transaction Server pour afficher les transactions en attente. Cliquez avec le bouton droit sur la transaction pour afficher ses propriétés. Résolvez-le pour accepter l’état que CICS a été configuré pour sélectionner heuristiquement, ou avec l’état sauvegardé ou abandonné si CICS s’est arrêté de manière inattendue et a démarré à froid. L’événement dans le journal identifie la transaction et l’état choisi par CICS.
Notes
Cela ne s’applique pas aux transactions TCP/IP, car TCP/IP ne prend pas en charge les transactions ACID (atomiques, cohérentes, isolées et durables).