Redirection après envoi d’une réponse négative

Lorsqu’une application utilisant le protocole flip-flop semi-duplex envoie une réponse négative à une chaîne sortante (ou envoie un Status-Acknowledge(Ack) à un message DATAFMI avec SDI défini) qui ne fait pas référence à une course, l’application doit supposer un état d’attente de récupération d’erreur. Les codes de détection utilisés pour les conditions de concurrence qui ne nécessitent pas la transition vers l’état d’attente de récupération d’erreur sont répertoriés dans le tableau suivant.

Sens du code	Description
0x080B	Erreur de course entre crochets
0x0813	Rejet de l’enchère entre crochets (pas de RTR à venir)
0x0814	Rejet de l’enchère entre crochets (RTR à venir)
0x081B	Récepteur en mode de transmission

L’application doit donc examiner le code de sens sur un message SDI pour détecter ces races.

L’état d’attente de récupération d’erreur diffère de l’état de réception sur un seul point : l’application peut transmettre des informations de sens à l’hôte à l’aide de Status-Control (LUSTAT). (Pour plus d’informations, voir LUSTATs.) L’indicateur LUSTAT ne doit pas avoir les indicateurs de direction de modification (CD) ou de crochet de fin (EB). (L’hôte a déjà une direction, et le crochet ne doit pas être arrêté prématurément par l’application.) Host Integration Server permet également à l’application FMI (Function Management Interface) d’envoyer Status-Control (LUSTAT) dans l’état de réception.

Une application utilisant le protocole de contention semi-duplex n’a pas d’état d’attente de récupération d’erreur et doit entrer un état de conflit chaque fois qu’elle envoie une réponse négative.

Notes

Si la chaîne est annulée par l’hôte avec le CD sur CANCEL , l’application doit supposer l’état d’envoi.

Voir aussi

CANCEL généré par une application
Redirection après réception d’une réponse négative
Échec critique
RQR et CLEAR
STSN
Échec du service de liaison
Échec du nœud local
Échec du client