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 certains aspects plus complexes (comme l’utilisation du mode de requête différé) sont uniquement applicables à la connexion PLU.

L’application peut envoyer des données entrantes sur n’importe quelle connexion, comme suit :

• Les données des services de réseau de données de gestion des fonctions (FMD BS) (services de session) et les données de gestion des fonctions (FMD) codées à caractères destinées à l’hôte doivent être envoyées au nœud local sur la connexion SSCP.

• Les données du 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 des messages de données pour envoyer des messages de contrôle de flux de données (DFC) ou de requête de contrôle de session à l’hôte. Au lieu de cela, elle doit utiliser des messages Status-Control. (Pour plus d’informations, consultez Message Status-Control.)

  Pour toutes les connexions, l’application doit remplir certains champs clés dans l’en-tête du message Data. Il doit en particulier :

• Définissez le type de message sur DATAFMI.

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

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

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

  Les champs nxtqptr, hdreptr et numelts dans l’en-tête de message, ainsi que les champs elteptr et startd dans les éléments de message sont configurés par les routines de gestion de mémoire tampon d’Host Integration Server. (Pour plus d’informations, consultez 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 intertâche et la mémoire partagée), tous les champs de l’en-tête doivent être définis par l’application.

  L’en-tête de transmission (TH) et les indicateurs d’en-tête de réponse (RH) ne sont pas disponibles pour l’application sur les messages Data 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, le sens, etc. Pour obtenir une description des indicateurs d’application disponibles pour les données entrantes et les rubriques ultérieures dans cette section pour obtenir une description de la façon dont les indicateurs sont utilisés pour contrôler les flux de données entrantes, 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 du message Data entrant est utilisée par le nœud local pour indiquer le message Data de la connexion auquel le message Status-Acknowledge 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 corréler les messages Data entrants et les messages Status-Acknowledge sortants sur la connexion. Notez que l’application doit également fournir une clé de message sur les messages Status-Control Request pour faire la distinction entre 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 Data entrants avec ACKRQD défini dans l’en-tête génèrent des requêtes RQD.

• Les messages Data entrants sans ACKRQD défini dans l’en-tête génèrent des requêtes RQE ou RQN selon le protocole de réponse de chaîne.

• L’application doit uniquement définir ACKRQD sur les messages Data pour lesquels l’indicateur d’application d’indicateur de chaîne de fin (ECI) est défini.

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

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

  Si l’application définit le champ ACKRQD dans l’en-tête de message d’un message Data, elle indique qu’elle requiert un accusé de réception pour ce message Data. Le nœud local accuse réception d’un message Data 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 Data. (Pour obtenir une illustration, reportez-vous à la première figure à la fin de cette rubrique.)

  Le nœud local traite les messages de données entrantes à partir de l’application par le biais de ses ordinateurs d’état interne, attribue le numéro de séquence SNA correct ou un identificateur pour ce flux, puis envoie les données dans une requête à l’hôte. Le type de chaîne de réponse de la requête varie selon que ACKRQD a été défini ou non dans le message Data et les paramètres de session.

  Le nœud local mappe une réponse positive de l’hôte à un message Status-Acknowledge(Ack) pour 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 Data d’origine. Par conséquent, la réception d’un message Status-Acknowledge(Ack) pour un message Data particulier implique que le nœud local a reçu une réponse SNA positive de l’hôte à la requête SNA entrante. (Pour obtenir une illustration, reportez-vous à la deuxième figure à la fin de cette rubrique.)

  Notez que les réponses sont absorbées sur la session SSCP-PU.

  Notez que les messages Status-Acknowledge(Ack) 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 de service de transmission (profil TS) 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 Data d’origine. Le message Status-Acknowledge(Nack-1) contient les codes de détection 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 figures à la fin de cette rubrique.)

  Si le nœud local détecte une erreur de format d’un message Data entrant ou si le message Data ne convient pas à l’état actuel de la session, il envoie Status-Acknowledge(Nack-2) à l’application avec un code d’erreur. (Pour obtenir la liste des codes d’erreur, consultez Codes d’erreur et de détection.) Le nœud local n’envoie pas de requête à l’hôte correspondant au message Data erroné 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 le message Data entrant suivant (en supposant que l’erreur ne provoque pas d’échec critique).

  Un exemple d’erreur de chaînage grave, où l’application envoie un message Data 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 étant défaillante de manière critique, ferme la connexion et envoie une requête TERM-SELF au SSCP pour obtenir UNBIND. (Pour plus d’informations, voir Récupération.)

  Les messages Status-Control entrants, qui provoquent la génération de requêtes expédié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 Data entrants. Pour plus d’informations sur les messages Status-Control qui correspondent aux requêtes de flux expédiées SNA, consultez Message Status-Control.

  Les cinq figures suivantes illustrent des exemples de protocoles d’accusé de réception des données entrantes (et les protocoles SNA sous-jacents) pour différents types de chaîne-réponse et modes de requête de session secondaires.

  Les illustrations montrent :

• Champ ACKRQD sur les messages Data.

• Clé de message sur les messages Data.

• Indicateurs d’application pertinents sur les messages Data.

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

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

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

• Codes de détection (affichés comme « SENSE=...... ») sur les requêtes/réponses SNA.

  Par souci de simplicité, tous les messages sont considérés comme circulant sur la même session PLU.

  Dans l’illustration suivante, l’application envoie correctement un message Data.

  
  L’application envoie correctement un message Data

  Dans l’illustration suivante, l’application envoie correctement une chaîne de messages Data.

  
  L’application envoie correctement une chaîne de messages Data

  Dans l’illustration suivante, l’hôte rejette une chaîne de messages Data.

  
  L’hôte rejette une chaîne de messages Data

  Dans l’illustration suivante, l’hôte rejette la première chaîne de réponse définie et rejette la troisième chaîne d’exception-réponse 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.

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

  Dans l’illustration suivante, le nœud local détecte l’utilisation non valide d’ACKRQD par l’application sans l’indicateur d’application 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 Data

Voir aussi

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