Arrêt initié par l’application

Une application sur une session avec le profil FM (Function Management) 3 ou 4 peut demander l’arrêt de la session de l’unité logique principale (PLU). Elle ne doit le faire que si elle s’est déjà assurée qu’elle est dans un état dans lequel la session PLU peut être arrêtée, c’est-à-dire entre chaînes et entre crochets. L’arrêt de la session PLU n’affecte pas l’état de la session du point de contrôle des services système (SSCP).

Notez qu’une application peut émettre une commande LOGOFF formatée par champ ou à codage à caractères sur la session SSCP ou envoyer une requête Close(PLU) pour demander au nœud local d’envoyer TERM-SELF au nom de l’application. Toutes ces opérations entraînent UNBIND, immédiatement ou après le nettoyage de la session dans l’hôte.

L’application demande l’arrêt de la session PLU en envoyant une requête Status-Control(RSHUTD) au nœud local, qui génère une requête SNA RSHUTD à l’hôte.

Après l’envoi de la requête Status-Control(RSHUTD) , l’application doit rester en mesure d’accepter et de répondre à toutes les données sortantes qu’elle reçoit. L’application peut maintenant s’attendre à l’un des deux messages suivants, selon que l’état de la session PLU autorise ou non son arrêt et que l’hôte souhaite ou non mettre fin à la session PLU :

  • Si l’état de la session PLU autorise son arrêt et que l’hôte souhaite terminer la session PLU, l’hôte génère une réponse positive à la requête RSHUTD, qui peut être suivie d’une requête UNBIND. Le nœud local ferme la connexion PLU. Pour plus d’informations, consultez Fermeture de la connexion PLU.

  • Si l’état de la session PLU ne permet pas son arrêt (par exemple, si la session est dans un crochet), ou si l’hôte ne souhaite pas mettre fin à la session PLU pour l’instant, l’hôte génère une réponse négative à la requête RSHUTD, que le nœud local présente à l’application en tant que Status-Control(RSHUTD) Negative-Acknowledge-1 avec les codes de détection fournis sur la réponse négative. Cela indique que la requête d’arrêt de la session PLU a été rejetée par l’hôte et que la communication sur la session PLU n’est pas affectée.

    Les deux figures suivantes illustrent le protocole d’arrêt initié par l’application entre le nœud local et l’application, ainsi que la liaison entre ce protocole et les protocoles SNA sous-jacents.

    Dans la première figure, l’application demande l’arrêt de la session PLU et l’hôte envoie UNBIND. Le nœud local ferme la connexion PLU.

    Image montrant l’application demande l’arrêt de la session PLU et l’hôte envoie UNBIND.
    L’application demande l’arrêt de la session PLU et l’hôte envoie UNBIND

    Dans l’illustration suivante, l’application demande l’arrêt de la session PLU, mais la session n’est pas dans un état approprié. L’hôte envoie une réponse négative à la requête RSHUTD, que le nœud local présente en tant que Status-Control(RSHUTD) Negative-Acknowledge-1. La communication se poursuit sur la session PLU.

    Image montrant l’application demande l’arrêt de la session PLU, mais la session n’est pas dans un état approprié.
    L’application demande l’arrêt de la session PLU, mais la session n’est pas dans un état approprié

Voir aussi

Ouverture de la connexion PLU
Fermeture de la connexion PLU
Session PLU
Chaînage sortant
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
LUSTATs]
Données de la surveillance des temps de réponse