Et si la ligne est défaillante ?

quand la ligne de communication est rétablie et que la connexion du journal à distance est revalidée. Par conséquent, une défaillance de la communication n’arrête pas les applications sur le système de production. Et ce n’est d’ailleurs pas ce que vous souhaitez.

La figure 2 montre une voie de communication coupée et l’accumulation échelonnée correspondante des changements journalisés en attente du rétablissement de la connexion.

Il est vrai que si vous avez choisi de configurer un mode d’envoi de journal à distance synchrone, le niveau de communication sous-jacent risque fort d’effectuer quelques retentatives héroïques avant de conclure que la ligne est vraiment en panne. Il est tout aussi vrai pour un journal à distance synchrone que cette tentative de réessai se produira au-dessous de vos programmes d’application, ce qui les mettra en suspens pendant la durée de l’opération. Pourvu que la durée de ces retentatives ne soit pas exagérée, c’est une bonne chose.

Pour éviter que de telles tentatives de réessai ne bloquent vos applications, IBM a amélioré le support du journal à distance en V5R1, de telle sorte que le temps de réessai soit peu important. Si vous utilisez une release antérieure à la V5R3, il vaudra mieux atteindre et réduire les tentatives de réessai (par exemple, avec la commande CHGTCPA).

Par certaines mesures, vous pouvez éviter que le tuyau de communication entre la machine source et la machine cible ne transporte des données parasites qui seront jugées inutiles à l’arrivée côté cible. Dans un prochain article, je recenserai quelques-unes des bonnes pratiques garantissant que les données circulant dans le tuyau sont packagées le plus efficacement possible.