Données sortantes

Cette section décrit les flux de données sortants du nœud local vers l’application. La structure globale des protocoles décrits s’applique aux connexions de point de contrôle des services système (SSCP) et d’unité logique principale (PLU), mais certaines fonctionnalités (telles que l’utilisation du mode de requête différé) sont uniquement applicables à la connexion PLU.

Le nœud local présente les données en provenance de l’hôte à l’application sur des connexions différentes, en fonction de la session SNA sur laquelle les données circulent, comme suit :

• Les données des services de réseau de données de gestion des fonctions (FMD NS) (services de session) et les données de gestion des fonctions (FMD) provenant de l’hôte et dirigées vers l’unité logique (LU) Host Integration Server (LU) sont envoyées à l’application sur la connexion SSCP.

• Les données FMD provenant de la PLU hôte et dirigées vers une LU de serveur SNA sont envoyées à l’application sur la connexion PLU.

  Pour toutes les connexions, seules les requêtes FMD sont présentées à l’application en tant que messages Data (avec message-type = DATAFMI). Les requêtes de contrôle de session et DFC sont utilisées pour générer des messages Status-Control. (Pour plus d’informations, consultez Message de contrôle d’état.)

  Le nœud local effectue les modifications de l’état de contrôle du flux de données requises par les indicateurs d’en-tête de réponse (RH) dans la requête, avant d’envoyer un message Data à l’application.

  Les indicateurs d’en-tête de transmission de requête SNA (TH) et RH ne sont pas disponibles pour l’application sur les messages Data sortants. Au lieu de cela, le nœud local fournit des indicateurs d’application dans l’en-tête de message Data qui reflètent les paramètres d’un sous-ensemble des indicateurs RH, mais qui sont interprétés par le nœud local pour protéger l’application contre les aspects plus obscurs de l’utilisation du chaînage et des crochets. Pour obtenir une description des indicateurs disponibles et la façon dont le nœud local les utilise sur les données sortantes, consultez Indicateurs d’application.

  Pour les données sortantes, le premier octet est RU[0] pour l’interface de gestion des fonctions standard (FMI) et TH[0] pour la variante LUA (application d’unité logique) de FMI.

  Tous les messages Data du nœud local à une application contiennent une clé de message. Le nœud local conserve une séquence de clés de message unique pour chaque flux de données sortantes vers une application. Lorsque le nœud local envoie un message Data à une application sur une connexion particulière, il place la clé de message suivante dans la séquence sortante dans l’en-tête du message, définit les indicateurs de l’application et envoie le message à l’application. Cela signifie que la clé de message identifie de façon unique un message Data sur une connexion particulière entre le nœud local et l’application. Notez que le nœud local place également des clés de message sur les messages de requête Status-Control sortants.

  Le protocole d’accusé de réception appliqué par Host Integration Server reflète le protocole de réponse de chaîne et le mode de requête en cours d’utilisation sur la session SNA, comme suit :

• Les demandes RQD sortantes génèrent des messages Data avec ACKRQD défini dans l’en-tête de message.

• Les demandes RQE sortantes génèrent des messages Data sans ACKRQD défini.

• Les demandes RQN sortantes génèrent des messages Data sans ACKRQD défini.

• Si la session utilise le mode de requête immédiate primaire, un message Data avec ACKRQD défini doit être accepté par l’application avant que d’autres messages Data puissent être reçus.

• Si la session utilise le mode de requête différée primaire, un message Data avec ACKRQD défini n’a pas besoin d’être immédiatement accepté par l’application. Les messages Data continueront à être reçus.

  Notez qu’Host Integration Server applique l’équivalent du mode de réponse immédiate pour le protocole d’accusé de réception de données sortantes pour toutes les connexions. L’application doit envoyer les accusés de réception dans l’ordre.

  Si le nœud local définit le champ ACKRQD dans l’en-tête d’un message Data pour l’application, cela indique qu’un accusé de réception pour ce message Data est requis. L’application accuse réception d’un message Data sortant en envoyant un message Status-Acknowledge au nœud local sur la même connexion, qui contient les mêmes champs de clé de message et de numéro de séquence que le message Data.

  À la réception de Status-Acknowledge(Ack), le nœud local met en corrélation la clé de message avec les messages sortants en suspens et génère une réponse SNA positive à la requête SNA appropriée.

  L’application doit utiliser le message Status-Acknowledge(Nack-1) comme accusé de réception négatif. À la réception de Status-Acknowledge(Nack-1) , le nœud local met en corrélation le message avec les messages sortants en suspens et génère une réponse SNA négative plus des données de sens pour la requête SNA appropriée. L’application fournit les données de sens qui doivent accompagner la réponse négative dans le cadre du message Status-Acknowledge(Nack-1) et doit inclure les mêmes clés de message, indicateurs d’application et champs de numéro de séquence que le message Data, pour lequel il s’agit d’un accusé de réception négatif.

  Les messages Status-Control provoqués par des requêtes de flux expédiées peuvent être envoyés à tout moment et n’affectent pas l’envoi d’accusés de réception positifs ou négatifs aux messages Data sortants ordinaires. Le fait qu’ils puissent se produire entre un message Data sortant et le message Status-Acknowledge correspondant est purement fortuit. Pour plus d’informations sur les messages Status-Control qui correspondent aux demandes SNA, consultez Message Status-Control.

  Si des erreurs sont détectées dans le format d’une requête de flux normale de la part de l’hôte ou si la requête n’est pas appropriée pour l’état de la session, le nœud local génère un message Data d’erreur pour l’application avec les caractéristiques suivantes :

• Les indicateurs d’application SDI et ECI sont définis.

• Le code de détection associé à l’erreur occupe les quatre premiers octets du message Data. (Pour plus d’informations, consultez Message de contrôle d’état.)

• ACKRQD est défini.

  L’application doit renvoyer Status-Acknowledge(Ack) et le nœud local génère une réponse négative qui porte le code de détection approprié pour l’erreur détectée. Ce mécanisme effectue ce qui suit :

• Informe l’application de l’erreur détectée.

• Permet à l’application de répondre à toutes les données précédemment reçues avant que le nœud local n’envoie la réponse négative à ce message Data.

  Sur les sessions où l’application reçoit une série de chaînes RQE, le nœud local conserve les informations de corrélation pour chaque chaîne (si l’application souhaite envoyer des réponses négatives à l’une des chaînes). Si le nœud local manque d’entrées de table de corrélations, il tentera d’allouer plus d’entrées et (en cas d’échec) sera forcé de terminer les sessions. Pour éviter cela, l’application doit fournir des messages Status-Acknowledge(Ack) pour les données RQE qu’elle ne souhaite pas rejeter dans ce cas. Une réponse après cinq chaînes RQE consécutives devrait suffire. Ces messages sont appelés accusés de réception de courtoisie et ne donnent pas lieu à une réponse à l’hôte, mais représentent simplement des données de corrélation internes gratuites.

  Les six figures suivantes illustrent le protocole d’accusé de réception de données appliqué entre le nœud local et l’application, et indiquent les effets de l’application générant des messages d’état positif et négatif pour les messages Status-Acknowledge.

  Les illustrations montrent :

• Les indicateurs RH pertinents dans les requêtes/réponses SNA.

• Numéro de séquence des requêtes/réponses SNA.

• Toutes les données de détection (indiquées par « SENSE=... ») sur les requêtes/réponses SNA et les messages Status-Acknowledge.

• Champ ACKRQD dans les messages Data.

• Champ clé du message dans les messages Data.

  Par souci de simplicité, tous les messages sont considérés comme des données FM qui circulent sur la même session PLU.

  Dans l’illustration suivante, l’application accepte un message Data correspondant à un RU à réponse définie.

  
  L’application envoie un message Data correspondant à un RU à réponse définie

  Dans l’illustration suivante, l’application accepte un message Data correspondant à une chaîne à réponse définie à plusieurs RU.

  
  L’application accepte un message Data correspondant à une chaîne à réponse définie à plusieurs RU

  Dans l’illustration suivante, l’application rejette un message Data correspondant à une chaîne à réponse définie.

  
  L’application rejette un message Data correspondant à une chaîne à réponse définie

  Dans l’illustration suivante, l’application rejette un message Data correspondant à une chaîne à réponse définie à plusieurs RU.

  
  L’application rejette un message Data correspondant à une chaîne à réponse définie à plusieurs RU

  Dans l’illustration suivante, le nœud local applique le mode de réponse immédiate. Les réponses doivent être envoyées en séquence. L’application rejette la deuxième chaîne d’exception-réponse et accepte la chaîne de réponse définie, ce qui implique l’acceptation de la troisième chaîne d’exception-réponse.

  
  Le nœud local applique le mode de réponse immédiate

  Dans l’illustration suivante, le nœud local détecte une erreur de chaînage (RQD mais pas EC) dans les données destinées à l’application. (Cet exemple nécessite que les case activée 0x4007 de réception soient en vigueur. Pour plus d’informations, consultez Ouverture de la connexion SSCP.)

  
  Le nœud local détecte une erreur de chaînage dans les données destinées à l’application

Voir aussi

Données entrantes
Données entrantes provenant d’applications LUA