Considérations sur SNA avec LUA

Cette section explique les informations SNA que vous devez prendre en compte lors de l’écriture d’applications d’unités logiques (LUA).

Vérification BIND

Pendant l’initialisation de la session LU, l’hôte envoie à l’application LUA un message BIND qui contient des informations telles que les tailles d’unités de requête/réponse (RU) à utiliser par la session lu. Microsoft® Host Integration Server retourne ce message à l’application LUA sur RUI_READ. L’application LUA doit vérifier que les paramètres spécifiés sur le BIND sont appropriés. L’application dispose des options suivantes :

• Il peut accepter le BIND tel qu’il est, en émettant RUI_WRITE contenant une réponse OK à bind. Aucune donnée BIND supplémentaire ne peut être envoyée sur la réponse.

• Il peut essayer de négocier un ou plusieurs paramètres BIND. (Cela n’est autorisé que si le BIND est négociable.) Pour ce faire, l’application émet des problèmes RUI_WRITE contenant une réponse OK, mais incluant la liaison modifiée en tant que données.

• Il peut rejeter la liaison en émettant des RUI_WRITE contenant une réponse négative, en utilisant un code de sens SNA approprié en tant que données.

  La validation des paramètres BIND et la garantie que tous les messages envoyés sont cohérents avec eux sont de la responsabilité de l’application LUA. Toutefois, les deux restrictions suivantes s’appliquent :

• Host Integration Server rejette toute RUI_WRITE qui spécifie une longueur de RU supérieure à la taille spécifiée sur le bind.

• Host Integration Server exige que bind spécifie que l’unité logique secondaire est le gagnant de la contention et que la récupération d’erreur est la responsabilité du perdant de contention.

  Notes

  Pour SLI, une application doit spécifier qu’elle utilisera SLI_BIND_ROUTINE sur le SLI_OPEN si elle effectue une vérification BIND.

Remerciements de courtoisie

Host Integration Server conserve un enregistrement des demandes reçues de l’hôte pour mettre en corrélation toute réponse envoyée par l’application avec la requête appropriée. Lorsque l’application envoie une réponse, Host Integration Server met en corrélation la réponse avec les données de la requête d’origine, puis peut libérer le stockage qui lui est associé.

Si l’hôte spécifie une réponse d’exception uniquement (une réponse négative peut être envoyée, mais qu’une réponse positive ne doit pas être envoyée), Host Integration Server doit toujours conserver un enregistrement de la demande au cas où l’application envoie par la suite une réponse négative. Si l’application n’envoie pas de réponse, le stockage associé à cette demande ne peut pas être libéré.

Pour cette raison, Host Integration Server permet à l’application LUA d’émettre une réponse positive à une demande d’exception-réponse uniquement de l’hôte. (Il s’agit d’un accusé de réception de courtoisie.) La réponse n’est pas envoyée à l’hôte, mais est utilisée par LUA pour effacer le stockage associé à la demande.

Distinguer les codes de sens SNA des autres codes de retour secondaires

Un code de retour secondaire qui n’est pas un code sense contient toujours une valeur de zéro dans ses deux premiers octets.

Un code de sens SNA contient toujours une valeur différente de zéro dans ses deux premiers octets. Le premier octet donne la catégorie de code sense et le second identifie un code de sens particulier au sein de cette catégorie. (Les troisième et quatrième octets peuvent contenir des informations supplémentaires ou être zéro.)

Informations sur les codes de sens SNA

Si vous avez besoin d’informations sur un code de sens retourné, consultez

• État/Message d’erreur

• Codes d’erreur et de détection

Réponses négatives et codes de sens SNA

Les codes de sens SNA peuvent être retournés à une application LUA dans les cas suivants :

• Lorsque l’hôte envoie une réponse négative à une requête de l’application LUA, il inclut un code de sens SNA indiquant la raison de la réponse négative. Cela est signalé à l’application lors d’une RUI_READ ou d’une SLI_RECEIVE ultérieure avec les informations suivantes.

  Sens du code	Description
  Code de retour principal	LUA_OK.
  Indicateur de demande/réponse, indicateur de type de réponse et indicateur de données incluses de sens	Tous définis sur 1, indiquant une réponse négative qui inclut des données de sens.
  Données retournées	Code de sens SNA.

• Lorsque Host Integration Server reçoit des données non valides de l’hôte, il envoie généralement une réponse négative à l’hôte et ne transmet pas les données non valides à l’application LUA. Cela est signalé à l’application sur un RUI_READ,SLI_RECEIVE, RUI_BID ouSLI_BID avec les informations suivantes :

  Sens du code	Description
  Code de retour principal	LUA_NEGATIVE_RESPONSE.
  Code de retour secondaire	Code de sens SNA envoyé à l’hôte.

• Dans certains cas, Host Integration Server détecte que les données fournies par l’hôte ne sont pas valides, mais ne peut pas déterminer le code de sens correct à envoyer. Dans ce cas, il transmet les données non valides dans une demande d’exception (EXR) à l’application LUA sur RUI_READ ou SLI_RECEIVE avec les informations suivantes.

  Sens du code	Description
  Indicateur de demande/réponse	Défini sur 0, indiquant une demande.
  Indicateur Détecter les données incluses	Défini sur 1, indiquant que les données de sens sont incluses. (Cet indicateur est normalement utilisé uniquement pour une réponse.)
  Données de message	Code de sens SNA suggéré.

  L’application doit ensuite envoyer une réponse négative au message. Il peut utiliser le code sense suggéré par Host Integration Server, ou il peut modifier le code sense.

• Host Integration Server peut envoyer un code sense à l’application pour indiquer que les données fournies par l’application n’étaient pas valides. Cela est signalé à l’application sur RUI_WRITE ou SLI_SEND avec les informations suivantes.

  Sens du code	Description
  Code de retour principal	LUA_UNSUCCESSFUL.
  Code de retour secondaire	Code de sens SNA.

  Les codes de sens qui peuvent être retournés en tant que codes de retour secondaires sur les verbes LUA sont répertoriés dans WINLUA. Fichier d’en-tête H. Pour ce fichier, consultez Host Integration Server ou le Kit de développement logiciel (SDK) SNA.

Rythme

Le rythme est géré par l’interface LUA. Une application LUA n’a pas besoin de contrôler le rythme et ne doit jamais définir l’indicateur d’indicateur de rythme.

Si le rythme est utilisé sur les données envoyées de l’application LUA à l’hôte (déterminé par le bind), RUI_WRITE ou SLI_SEND peut prendre un certain temps. Cela est dû au fait que LUA doit attendre une réponse dynamique de l’hôte avant qu’il puisse envoyer plus de données.

Si une application LUA transfère de grandes quantités de données dans une direction, soit vers l’hôte, soit à partir de l’hôte (par exemple, une application de transfert de fichiers), la configuration de l’hôte doit spécifier que le rythme est utilisé dans cette direction. Cela garantit que le nœud recevant les données n’est pas inondé de données et n’est pas à court de stockage de données.

Purge des données jusqu’à la fin de la chaîne

Lorsque l’hôte envoie une chaîne d’unités de requête à une application LUA, l’application peut attendre que la dernière RU de la chaîne soit reçue avant d’envoyer une réponse, ou elle peut envoyer une réponse négative à une ru qui n’est pas la dernière de la chaîne. Si une réponse négative est envoyée au milieu de la chaîne, LUA vide toutes les unités de requête suivantes de cette chaîne et ne les envoie pas à l’application.

Lorsque LUA reçoit la dernière RU dans la chaîne, il l’indique à l’application en définissant le code de retour principal de RUI_READ ou RUI_BID sur LUA_NEGATIVE_RESPONSE avec un code de retour secondaire zéro.

L’hôte peut terminer la chaîne en envoyant un message tel que CANCEL dans la chaîne intermédiaire. Dans ce cas, le message CANCEL est retourné à l’application sur RUI_READ. Le code de retour LUA_NEGATIVE_RESPONSE n’est pas utilisé.

Segmentation

La segmentation des unités de requête est gérée par l’interface LUA. LUA transmet toujours des unités de requête complètes à l’application, et l’application doit passer des unités de requête complètes à LUA.