Données entrantes

Cette section décrit les flux de données entrants de l’application vers le nœud local. 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 les aspects plus complexes (tels que l’utilisation du mode de requête différé) ne s’appliquent qu’à la connexion PLU.

L’application peut envoyer des données entrantes sur l’une des connexions, comme suit :

• Les 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) codées par caractères destinées au SSCP hôte doivent être envoyés au nœud local sur la connexion SSCP.

• Les données FMD destinées à l’hôte PLU doivent être envoyées au nœud local sur la connexion PLU.

  L’application ne peut pas utiliser les messages de données pour envoyer des messages de demande de contrôle de flux de données (DFC) ou de contrôle de session à l’hôte. Au lieu de cela, il doit utiliser les messages Status-Control . (Pour plus d’informations, consultez Status-Control Message.)

  Pour toutes les connexions, l’application doit renseigner certains champs clés dans l’en-tête du message de données . En particulier, il doit :

• Définissez le type de message sur DATAFMI.

• Allouez une nouvelle clé de message pour les messages de données entrants sur cette connexion.

• Définissez le champ ACKRQD si nécessaire.

• Définissez les indicateurs d’application. (Pour plus d’informations, consultez Indicateurs d’application.)

  Les champs nxtqptr, hdreptr et numelts dans l’en-tête du message, et les champs elteptr et startd dans les éléments de message, sont configurés par les routines de gestion des mémoires tampons du Host Integration Server. (Pour plus d’informations, consultez l’interface DL-BASE/DMOD.) L’application est chargée de définir le champ endd.

  Si l’application n’a pas accès à ces routines (par exemple, lorsque l’environnement d’exploitation ne prend pas en charge les appels de procédure intertask et la mémoire partagée), tous les champs de l’en-tête doivent être définis par l’application.

  Les indicateurs d’en-tête de transmission (TH) et d’en-tête de réponse (RH) ne sont pas disponibles pour l’application sur les messages de données entrants. L’application doit définir les indicateurs d’application appropriés dans l’en-tête de message pour contrôler le chaînage, la direction, et ainsi de suite. Pour obtenir une description des indicateurs d’application disponibles pour les données entrantes et les rubriques ultérieures de cette section pour obtenir une description de la façon dont les indicateurs sont utilisés pour contrôler les flux de données entrants, consultez Indicateurs d’application.

  Pour les données entrantes, le premier octet est RU[0] pour l’interface de gestion des fonctions standard (FMI).

  La clé de message fournie par l’application dans l’en-tête de message de données entrantes est utilisée par le nœud local pour indiquer quel message de données sur cette connexion un Statut-Acquittement sortant fait référence. L’application doit conserver une séquence de clés de message unique pour le flux de données entrant sur chaque connexion qu’elle possède avec le nœud local, afin que l’application puisse utiliser la clé de message pour mettre en corrélation les messages de données entrants et les messages d’état de réception sortants sur la connexion. Note que l'application doit également fournir une clé de message sur les messages de Requête de Contrôle de Statut pour différencier plusieurs messages RQE LUSTAT.

  Le protocole d’accusé de réception des données entrantes reflète le protocole de réponse de chaîne secondaire et le mode de requête en cours d’utilisation sur la session, comme suit :

• Les messages de données entrants avec ACKRQD définis dans l’en-tête génèrent des requêtes RQD .

• Les messages de données entrants sans ACKRQD définis dans l’en-tête génèrent des requêtes RQE ou RQN en fonction du protocole de réponse de chaîne.

• L’application doit uniquement définir ACKRQD sur les messages de données dont l’indicateur d’application ECI (End Chain Indicator) est défini.

• Si la session spécifie que le secondaire utilise le mode de demande immédiate, l’application peut toujours envoyer d’autres messages de données après l’envoi de données avec ACKRQD défini, même s’il n’a pas reçu de message Status-Acknowledge pour ce message de données . Les messages sont mis en file d’attente dans le nœud local et sont envoyés progressivement à mesure que des réponses positives sont reçues.

• Si la session spécifie que la partie secondaire utilise le mode de requête différée, après l’envoi d’un message de données avec ACKRQD activé, l’application peut continuer à envoyer des messages de données.

  Si l’application définit le champ ACKRQD dans l’en-tête de message d’un message De données , il indique qu’il nécessite un accusé de réception à ce message de données . Le nœud local reconnaît un message de données entrant en envoyant un message Status-Acknowledge à l’application sur la même connexion et en utilisant la même clé de message que le message de données . (Pour obtenir une illustration, consultez la première figure à la fin de cette rubrique.)

  Le nœud local traite les messages de données entrants de l’application via ses ordinateurs d’état interne, affecte le numéro de séquence SNA approprié ou un identificateur pour ce flux et envoie les données dans une demande à l’hôte. Le type de réponse chaîne de la requête dépend de la définition d’ACKRQD dans le message de données et les paramètres de session.

  Le nœud local mappe une réponse positive de l’hôte à un Status-Acknowledge(Ack) à l’application. L’application peut utiliser la clé de message dans Status-Acknowledge pour mettre en corrélation l’accusé de réception avec le message de données d’origine. Par conséquent, la réception d’un status-acknowledge(Ack) pour un message de données particulier implique que le nœud local a reçu une réponse SNA positive de l’hôte à la demande SNA entrante. (Pour obtenir une illustration, consultez la deuxième figure à la fin de cette rubrique.)

  Veuillez noter que les réponses sont absorbées lors de la session SSCP-PU.

  Notez que les messages Status-Acknowledge(Ack) sortants contiennent des indicateurs d’application et un numéro de séquence. Les indicateurs d’application reflètent les indicateurs RH dans la réponse. Le numéro de séquence est le numéro de séquence SNA de la réponse et fournit un mécanisme pour les applications utilisant le profil TS (Transmission Service Profile) 4 pour suivre le numéro de séquence secondaire SNA correspondant à une unité de travail.

  Le nœud local mappe une réponse négative de l’hôte à un message Status-Acknowledge(Nack-1) à l’application. L’application peut utiliser la clé de message dans Status-Acknowledge pour mettre en corrélation l’accusé de réception négatif avec le message Données d’origine. Le message Status-Acknowledge(Nack-1) sortant contient les codes de sens SNA et le numéro de séquence de la réponse négative. (Pour obtenir une illustration, consultez les troisième et quatrième chiffres à la fin de cette rubrique.)

  Si le nœud local détecte une erreur au format d’un message de données entrant ou si le message de données n’est pas approprié à l’état actuel de la session, il envoie un Status-Acknowledge(Nack-2) à l’application contenant un code d’erreur. (Pour obtenir la liste des codes d’erreur, consultez Codes d’erreur et de sens.) Le nœud local n’envoie pas de requête à l’hôte correspondant au message de données en erreur et n’avance pas le numéro de séquence SNA pour la session. L’application peut utiliser n’importe quelle clé de message dans son prochain message de données entrantes (en supposant que l’erreur n’entraîne pas de défaillance critique).

  Exemple d’erreur de chaînage grave, où l’application envoie un message de données avec ACKRQD , mais sans ECI dans les indicateurs d’application, est illustré dans la dernière figure à la fin de cette rubrique. Notez qu’après avoir détecté cette erreur particulière, le nœud local marque la connexion de l’application comme ayant échoué de manière critique, ferme la connexion et envoie une requête TERM-SELF au SSCP pour déclencher une liaison UNBIND. (Pour plus d’informations, consultez Recovery.)

  Les messages de contrôle d’état entrant, qui provoquent la génération de demandes de flux accélérées, peuvent être envoyés à tout moment et n’affectent pas l’envoi d’un accusé de réception positif ou négatif aux messages de données entrants. Pour plus d’informations sur les messages Status-Control correspondant aux demandes de flux accélérées SNA, consultez Status-Control Message.

  Les cinq figures suivantes présentent des exemples de protocoles d'accusé de réception des données entrantes (et des protocoles SNA sous-jacents) pour différents types de réponses en chaîne et modes de demande de session secondaire.

  Les chiffres montrent :

• Champ ACKRQD sur les messages de données .

• Clé de message sur messages de données.

• Tous les indicateurs d’application pertinents sur les Data messages.

• Codes d’erreur (indiqués sous la forme « ERROR=... ») sur les messages de données .

• Indicateurs RH pertinents sur les demandes/réponses SNA.

• Numéros de séquence sur les requêtes/réponses SNA.

• Codes de sens (affichés sous la forme « SENSE=....... ») sur les requêtes/réponses SNA.

  Par souci de simplicité, tous les messages sont supposés circuler sur la même session PLU.

  Dans la figure suivante, l’application envoie avec succès un message Data.

  
  L’application envoie correctement un message de données

  Dans la figure suivante, l’application envoie avec succès une chaîne de messages de données .

  
  L’application envoie correctement une chaîne de messages de données

  Dans la figure suivante, l’hôte rejette une chaîne de messages de données .

  
  L’hôte rejette une chaîne de messages de données

  Dans la figure suivante, l’hôte rejette la première chaîne de réponse définie et rejette la troisième chaîne de réponse d’exception sur une session de requête retardée. Notez que la réponse négative à la troisième chaîne implique une réponse positive à la deuxième chaîne.

  
  L’hôte rejette la première chaîne de réponse définie

  Dans la figure suivante, le nœud local détecte l’utilisation non valide de ACKRQD sans l’indicateur ECI sur un message Data. Notez qu’aucune donnée n’est envoyée à l’hôte. Toutefois, étant donné que l’erreur est critique, le nœud local envoie un message TERM-SELF au SSCP.

  
  Le nœud local détecte l’utilisation non valide d'ACKRDQ par l'application sans l’indicateur d’application ECI sur un message de données.

Voir aussi

Données sortantes
Données entrantes à partir d’applications LUA