Chaînage sortant

Le nœud local vérifie que les chaînes sortantes des requêtes sont conformes à la bonne utilisation de SNA, à l’utilisation du chaînage pour la session et à l’état actuel de la session. Le nœud local accepte les chaînes de données sortantes valides de l’hôte si l’une des conditions suivantes est vraie :

• Le trafic de données est actif sur une session en duplex intégral.

• La session est dans un état où elle peut recevoir des données.

• La session est entre crochets sans demi-session en cours d’envoi, ou la session est en conflit pour une session de conflit en semi-duplex. (Pour plus d’informations, consultez Crochets.)

• La session attend que l’hôte lance une procédure de récupération. Par exemple, le nœud local a envoyé une réponse négative à une chaîne sortante. (Pour plus d’informations, voir Récupération.)

  Le nœud local envoie un message Data à l’application pour chaque requête sortante, mais notez les effets de l’application en spécifiant l’option de remise de segment dans le bloc de contrôle d’informations de connexion. (Pour plus d’informations, consultez Livraison de segment.) Si l’application ne spécifie pas la livraison de segment, les indicateurs d’application BCI (Begin Chain Indicator) et ECI (End Chain Indicator) dans l’en-tête de message reflètent les indicateurs de chaînage dans l’en-tête de la requête.

  Une chaîne sortante peut se terminer de plusieurs façons :

• La chaîne est reçue au complet et sans erreur. Toutes les requêtes de la chaîne ont été transmises à l’application en tant que messages Data et ont fait l’objet d’un accusé de réception, le cas échéant.

• L’application détecte une erreur dans un message Data lors de la réception de la chaîne. L’application doit envoyer Status-Acknowledge(Nack-1) avec les données de sens associées au nœud local, qui envoie une réponse négative plus les données de sens à l’hôte pour la requête correspondant au message Data de l’erreur. Le nœud local n’efface pas le reste de la chaîne, de sorte que l’application voit la fin de chaîne (EC). L’hôte peut également arrêter la chaîne à l’aide d’un message CANCEL, qui est remis à l’application en tant que Status-Control(CANCEL) avec ACKRQD défini.

• Le nœud local détecte une erreur dans une requête et présente à l’application un message Data d’erreur système détectée pour signaler la fin prématurée de la chaîne. Ce message contient les indicateurs d’erreur système (SDI) et d’application ECI détectés, les codes de détection pour l’erreur et l’indicateur ACKRQD. Il ne transporte pas de données utilisateur. Lorsque l’application répond avec Status-Acknowledge(Ack), le nœud local génère une réponse négative à la chaîne en utilisant le code de détection approprié. L’application peut utiliser les codes de détection signalés pour générer des informations de diagnostic pour l’utilisateur. (Par exemple, un émulateur 3270 générerait des codes de vérification PROG.) Le nœud local purge le reste de la chaîne, de sorte que l’application peut ne pas voir EC. L’hôte peut également arrêter la chaîne à l’aide d’un message CANCEL, qui est remis à l’application en tant que Status-Control(CANCEL) avec ACKRQD défini.

• L’hôte peut annuler la chaîne lors de l’envoi, en envoyant la requête CANCEL. Le nœud local envoie un message Status-Control(CANCEL) à l’application, dont l’application doit accuser réception.

  Si une erreur se produit lors de la réception d’une chaîne et que la session utilise des protocoles de basculement semi-duplex, l’application doit supposer un état d’attente de récupération d’erreur. (Pour plus d’informations, voir Récupération.)

  Pour une session utilisant les protocoles de basculement semi-duplex, si les indicateurs d’application du dernier message Data de la chaîne ont l’indicateur CDI (changement de direction) défini :

• Si la chaîne a été reçue sans erreur, l’application a le sens.

• Si l’application a rejeté un message de la chaîne, l’hôte conserve le sens.

  Les quatre figures suivantes illustrent les protocoles de chaînage sortant entre le nœud local et l’application et la façon dont ces protocoles sont liés aux protocoles SNA sous-jacents.

  Dans la première figure, une chaîne sortante complète est reçue sans erreur et acceptée par l’application. Notez qu’après l’envoi de Status-Acknowledge(Ack) , l’application dispose du sens.

  
  Chaîne sortante reçue sans erreur et acceptée par l’application

  Dans l’illustration suivante, une chaîne sortante complète est reçue sans erreur, mais elle est rejetée par l’application. Notez que, bien que la chaîne transporte le déploiement continu, l’application n’a pas de direction.

  
  Chaîne sortante reçue sans erreur, mais rejetée par l’application

  Dans l’illustration suivante, le nœud local détecte l’utilisation non valide de RQD sans EC et convertit la requête en message Data avec l’indicateur d’application SDI défini, ainsi qu’ACKRQD et les codes de sens appropriés. Le message Status-Acknowledge(Ack) de l’application engendre la réponse négative à l’hôte. Cet exemple part du principe que la vérification de réception 4007 a été spécifiée dans CICB sur Open(SSCP) .

  
  Le nœud local détecte une utilisation non valide et convertit la requête

  Dans l’illustration suivante, l’hôte annule la chaîne sortante.

  
  Hôte qui annule la chaîne sortante

Voir aussi

Ouverture de la connexion PLU
Session PLU
Chaînage entrant
Livraison de segment
Brackets
Sens
Rythme et segmentation
Confirmation et rejet des données]
Arrêt et mise en suspens
Récupération
Terminaison initié par l’application
LUSTATs]
Données de la surveillance des temps de réponse