Message d’état de contrôle

Les messages Status-Control fournissent un accès aux protocoles de contrôle de session et de contrôle de flux de données sur la session d’unité logique principale (PLU) à l’aide de la connexion PLU. Elles ne sont pas utilisées sur les autres connexions. Les messages Status-Control sont directement mappés aux unités de requête/réponse du contrôle de session SNA équivalentes et du contrôle de flux de données.

Tous les messages Status-Control qui correspondent aux requêtes SNA sur le flux normal, à l’exception de l’exception de requête envoyée LUSTAT (RQE) et les messages Status-Control correspondant aux requêtes CLEAR et STSN sur le lux expédié, ont le jeu de champs ACKRQD (accusé de réception requis). Les messages Status-Control qui correspondent aux requêtes SNA sur le flux expédié (à l’exception de CLEAR et STSN) n’ont pas le champ ACKRQD défini par le nœud local. Toutefois, l’application peut définir ACKRQD lors de l’envoi de ces messages Status-Control. La dernière figure de cette rubrique résume les requêtes Status-Control dont ACKRQD est toujours défini.

Si une requête Status-Control a ACKRQD défini dans l’en-tête de message, le destinataire doit fournir une réponse Status-Control (Acknowledge, Negative-Acknowledge-1 ou Negative-Acknowledge-2) avant que l’expéditeur envoie des messages Données supplémentaires ou des requêtes Status-Control supplémentaires sur le flux. L’expéditeur peut toujours envoyer des réponses Status-Control, messages Status-Acknowledge, Status-Error et Status-Resource sur le flux. Cela s’applique à la fois aux flux normaux et expédiés et à tous les modes de requête (y compris le mode de requête différée). La clé de message reçue sur la requête doit être retournée dans la réponse. (Cela permet de faire d’autoriser que plusieurs messages RQE LUSTAT soient en attente.) Le nœud local incrémente la clé de message sur les requêtes Status-Control et les messages DATAFMI qu’il envoie à l’application sur la connexion PLU.

Pour la variante LUA (application Logical Unit) de l’interface de gestion de fonction (FMI), le champ de clé de message est utilisé d’une façon différente, comme suit :

• Pour les requêtes de flux entrantes expédiées, le nœud local définit le numéro de séquence SNA sur la valeur fournie par l’application dans le champ clé du message. L’application doit s’assurer que ce champ est défini sur le numéro de séquence correct.

• Pour les réponses Status-Control entrants, le nœud local définit le numéro de séquence SNA sur la valeur fournie par l’application dans le champ clé du message. L’application doit s’assurer que ce champ est défini sur le numéro de séquence de la requête pour laquelle une réponse est envoyée.

  Sauf en cas de Status-Control(LUSTAT) , si une requête Status-Control n’a pas de ACKRQD définie, l’application ne doit pas répondre, car une réponse positive a déjà été envoyée par le nœud local.

  Par exemple, si l’application envoie une Requête Status-Control (QC) avec ACKRQD défini (correspondant à une requête SNA sur le flux normal), cela bloque les requêtes données et Status-Control supplémentaires correspondant au flux normal entrant jusqu’à ce que la réponse Status-Control(QC) soit reçue. Elle ne bloque pas les autres messages sur le flux normal, ni les messages sur le flux expédié. Par exemple, l’application peut toujours envoyer Status-Control (SIGNAL) .

  La réception de la réponse Status-Control implique un accusé de réception pour tous les messages en attente (y compris les messages Données) sur le flux.

  L’utilisation de ACKRQD sur les messages Status-Control applique efficacement le mode de réponse définie et de requête immédiate. Cela est approprié pour :

• Messages Status-Control qui correspondent aux requêtes SNA CLEAR et STSN (car le flux expédié est RQD).

• Messages Status-Control correspondant à toutes les requêtes DFC (qui sont RQD), à l’exception de LUSTAT (qui peut être RQE).

  L’application peut définir ACKRQD sur les requêtes Status-Control qui correspondent aux demandes SNA sur le workflow expédié, même si ACKRQD n’est pas requis. Par exemple, lorsqu’une application signale la direction (par exemple, un émulateur 3270 avec un opérateur de terminal appuyant à plusieurs reprises sur la touche ATTN), elle peut générer plusieurs messages de Requête Status-Control(SIGNAL) , ce qui aurait un impact négatif sur les performances des autres utilisateurs. L’application peut définir ACKRQD sur la première Requête Status-Control(SIGNAL) et ignorer les événements qui pourraient entraîner des messages Requête Status-Control(SIGNAL) jusqu’à ce que la Réponse Status-Control(SIGNAL) soit reçue du nœud local.

  Le message passe dans les six figures suivantes : les séquences de Status-Control sortantes et entrantes avec et sans ACKRQD et les unités de commande SNA correspondantes.

  Dans la première figure, l’application envoie Status-Control (CHASE) .

  
  L’application envoie Status-Control(CHASE)

  Dans l’illustration suivante, l’hôte envoie une requête BID.

  
  L’hôte envoie une requête BID

  Dans l’illustration suivante, l’application envoie Status-Control (SHUTC) .

  
  L’application envoie Status-Control(SHUTC)

  Dans l’illustration suivante, l’hôte envoie une requête SIGNAL SNA.

  
  L’hôte envoie une requête SIGNAL SNA

  Dans l’illustration suivante, l’hôte envoie plusieurs requête LUSTAT RQE et l’application rejette la première.

  
  L’application rejette la première requête RQE LUSTAT

  Dans l’illustration suivante, l’application envoie Status-Control (LUSTAT) NOACKRQD.

  
  L’application envoie Status-Control (LUSTAT) NOACKRQD

  Le tableau suivant récapitule les requêtes Status-Control prises en charge par le nœud local et les requêtes de contrôle de session et de contrôle de flux de données SNA (DFC). Pour chaque requête Status-Control, la table donne :

• Catégorie SNA de la requête SNA correspondante (SC ou DFC).

• Le flux utilisé par la requête SNA correspondante (normale ou expédiée).

• Profils TS ou FM sur lesquels la requête SNA correspondante est prise en charge.

• Directions pour lesquelles elle est valide (NODE <–> APPL).

• Indique s’il requiert ACKRQD. Notez que l’application peut définir ACKRQD sur une requête Status-Control qui ne l’exige pas.

• Code hexadécimal utilisé dans le champ de type de contrôle du message Status-Control. (Pour plus d’informations, consultez Formats de message FMI.)

Les requêtes figurant dans le tableau suivant sont utilisées uniquement avec LUA. (Pour plus d’informations, consultez Concepts de FMI.)

L’utilisation de messages Status-Control particuliers est décrite dans les rubriques suivantes de cette section, dans le contexte de protocoles de session PLU tels que le chaînage, les crochets, la récupération, etc.

Pour les formats des messages Status-Control , consultez Status-Control.

Dans cette section

• Message d’état de contrôle (ACKLUA)