Chaînage entrant

La répartition des données d’application dans les messages Data et le contrôle du chaînage entrant sont la responsabilité de l’application.

La taille d’unité de requête d’envoi maximale secondaire pour la session est un paramètre dans BIND à partir de l’hôte et est disponible dans le bloc de contrôle d’informations de liaison (BICB) du message Open(PLU) OK Confirm. L’application doit s’assurer que chaque message Data entrant correspond à une seule unité de requête. Elle ne contient pas plus de données que la taille maximale d’unité de requête indiquée dans le BICB.

L’application doit utiliser les indicateurs d’application BCI (Begin Chain Indicator) et ECI (End Chain Indicator) dans les en-têtes de message Data pour contrôler le chaînage. (Pour plus d’informations, consultez Indicateurs d’application.) La chaîne est l’unité de récupération et, si des erreurs récupérables se produisent dans la chaîne, l’application doit assumer la responsabilité de la récupération. (Pour plus d’informations, voir Récupération.)

Une chaîne entrante peut se terminer de l’une des manières suivantes :

  • La chaîne complète est envoyée sans erreurs. Tous les messages Data de la chaîne ont été transmis à l’hôte. Si la session autorise le serveur secondaire à envoyer des chaînes à réponse définie et que l’application définit le champ ACKRQD dans le dernier message Data de la chaîne, l’application reçoit Status-Acknowledge(Ack) du nœud local lorsque l’hôte fournit une réponse.

  • Le nœud local détecte une erreur critique dans le format d’un message Data de l’application ou dans l’état de la session. Le nœud local rejette le message Data avec Status-Acknowledge(Nack-2) contenant un code d’erreur et ferme la connexion PLU. Notez que le nœud local génère une requête CANCEL entrante avant de fermer la connexion PLU. Le nœud local envoie une requête TERM-SELF à l’hôte pour obtenir BIND.

  • L’hôte envoie une réponse négative à une requête dans la chaîne. Le nœud local envoie un message Status-Acknowledge(Nack-1) à l’application avec les codes de sens et le numéro de séquence de la réponse négative. Si l’hôte rejette une requête qui ne contient pas l’indicateur d’application ECI et que l’application ne spécifie pas l’option d’annulation de l’application dans le CICB de la PLU, le nœud local génère également une requête CANCEL entrante. Lorsque l’application spécifie l’annulation de l’application, elle doit envoyer EC ou Status-Control(CANCEL) pour terminer la chaîne. Toutes les chaînes entrantes suivantes sont rejetées avec un Status-Acknowledge(Nack-2) non critique, et un code de détection 0x2002 ou 0x2004 (chaînage ou sens). Lorsque l’application reçoit le message Status-Acknowledge(Nack-1) , elle doit arrêter d’envoyer des données après cette chaîne pour les sessions de basculement en semi-duplex, car le sens est passé à l’hôte. (Pour plus d’informations, consultez Sens.)

  • L’application annule la chaîne lors de l’envoi en envoyant un message Status-Control(CANCEL) au nœud local. Le nœud local envoie une requête CANCEL à l’hôte et envoie un accusé de réception de Status-Control(CANCEL) à l’application lors de la réception d’une réponse positive de l’hôte. Les réponses de l’hôte aux requêtes envoyées avant CANCEL génèrent des messages Status-Acknowledge appropriés pour l’application si le champ ACKRQD est défini pour les messages Data d’origine.

  • L’application ferme la connexion PLU lors de l’envoi de la chaîne. Le nœud local envoie une réponse Close(PLU) à l’application. Les réponses de l’hôte aux requêtes envoyées avant le message Close(PLU) ne génèrent pas de messages Status-Acknowledge vers l’application. Notez que le nœud local génère également une requête CANCEL entrante et une requête TERM-SELF pour obtenir UNBIND.

    Si le nœud local détecte une erreur non critique dans le format d’un message Data de l’application ou d’état de session, il ne ferme pas la connexion PLU. Au lieu de cela, il rejette le message Data erroné avec un message Status-Acknowledge(Nack-2) contenant un code d’erreur approprié. Aucune donnée n’est envoyée à l’hôte.

    Si une chaîne entrante se termine par une erreur, lorsque la session utilise des protocoles semi-duplex, l’application doit supposer un état de réception. (Pour plus d’informations, voir Récupération.)

    Les six figures suivantes illustrent les protocoles de chaînage entrant 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 entrante complète est envoyée sans erreur et acceptée par l’hôte. Notez qu’après avoir reçu Status-Acknowledge(Ack) , l’application abandonne le sens à l’hôte.

    Image montrant une chaîne entrante envoyée sans erreur et acceptée par l’hôte.
    La chaîne entrante est envoyée sans erreur et acceptée par l’hôte

    Dans l’illustration suivante, le nœud local détecte une erreur critique dans le format du deuxième message Data de la chaîne (ACKRQD sans l’indicateur d’application ECI), envoie Status-Acknowledge(Nack-2) à l’application avec le code d’erreur approprié et ferme la connexion PLU. Notez que le nœud local génère uniquement CANCEL si le profil de gestion des fonctions (FM) de la session prend en charge CANCEL.

    Image montrant comment un nœud local détecte une erreur, envoie un message d’état et ferme la connexion PLU.
    Le nœud local détecte une erreur, envoie un message d’état et ferme la connexion PLU

    Dans la figure suivante, une chaîne entrante complète est envoyée sans erreur, mais elle est rejetée par l’hôte. Après la réponse négative, l’application doit entrer l’état de réception, en attente de récupération après erreur. (Pour plus d’informations, voir Récupération.)

    Image montrant comment une chaîne entrante est envoyée sans erreur, mais rejetée par l’hôte.
    La chaîne entrante est envoyée sans erreur mais est rejetée par l’hôte

    Dans l’illustration suivante, l’application annule la chaîne en envoyant Status-Control(CANCEL) . Notez que l’application a toujours le sens et peut démarrer une nouvelle chaîne.

    Image montrant comment une application annule la chaîne avec un Contrôle d’état (CANCEL).
    L’application annule la chaîne avec Status-Control(CANCEL)

    Dans l’illustration suivante, l’application ferme la session PLU lors de l’envoi de la chaîne. Le nœud local génère CANCEL uniquement si le profil FM de la session prend en charge CANCEL.

    Image montrant comment une application ferme la connexion PLU lors de l’envoi de la chaîne.
    L’application ferme la connexion PLU lors de l’envoi de la chaîne

    Dans l’illustration suivante, le nœud local détecte une erreur non critique dans le format du deuxième message Data de la chaîne et envoie Status-Acknowledge(Nack-2) à l’application avec le code d’erreur approprié.

    Image montrant comment un nœud local détecte une erreur non critique et envoie un Status-Acknowledge(Nack-2).
    Le nœud local détecte une erreur non critique et envoie Status-Acknowledge(Nack-2)

Voir aussi

Ouverture de la connexion PLU
Session PLU
Chaînage sortant
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