Mise en correspondance des programmes transactionnels appelants et appelables (CPI-C)
Chaque service SNA tient à jour une liste de noms de programme de transaction (TP) invokables disponibles et de tous les alias d’unité logique (LU) à associer aux noms TP. Ces informations sont obtenues comme suit :
Pour les TPs invokables automatiquement, les variables de registre ou d’environnement identifient un nom TP contenant un maximum de huit caractères et peuvent spécifier une lu associée. Ces informations sont envoyées du client au serveur qui parraine le client. Un client apprend le domaine par le biais d’une connexion de sponsor à un serveur. Les clients doivent établir la connexion du sponsor avant de procéder à d’autres tâches.
Pour les TPS invokables démarrés par l’opérateur, un nom TP (avec un maximum de 64 caractères) est spécifié dans Specify_Local_TP_Name. Le nom TP est tronqué à huit caractères et envoyé du client au serveur qui parraine le client, ainsi que l’alias d’une unité logique associée si elle a été configurée via un registre ou une variable d’environnement.
Notes
Si vous souhaitez qu’un nom TP soit unique, il est recommandé de limiter le nom à huit caractères ou moins, ou de le rendre unique dans les huit premiers caractères. Cela est dû au fait que le routage préliminaire des demandes d’allocation est effectué à l’aide des huit premiers caractères. Bien qu’une correspondance supplémentaire soit effectuée par la suite entre les noms tp complets, il est inefficace de permettre au routage préliminaire de réussir quand, dans certains cas, la correspondance ultérieure échoue.
L’étape suivante dans la mise en correspondance des TPs appelants et appelants est la création d’une table d’informations latérales à partir des paramètres dans le nom de destination symbolique. Ensuite, le TP appelant émet l’appel d’allocation et une demande d’allocation flux vers l’unité logique partenaire spécifiée dans la table d’informations latérales, en indiquant le nom du TP invocable qui a été demandé (également répertorié dans la table d’informations latérales).
Lorsqu’une demande d’allocation arrive, le service SNA compare le nom tp invocable et l’alias lu demandés à la liste des fournisseurs de services d’appel disponibles (qui peuvent inclure des alias de LU associés). La comparaison peut être modifiée par des variables de Registre, mais est effectuée par défaut comme suit :
Bien que le nom TP demandé dans le nom de destination symbolique puisse comporter 64 caractères, tout nom reçu par le biais d’un registre ou d’une variable d’environnement est limité à huit caractères ou moins. Par conséquent, seuls les huit premiers caractères des noms TP sont utilisés dans les comparaisons.
La comparaison est effectuée en premier sur le nom TP et l’alias lu. Un TP invokable pour lequel il existe une correspondance à la fois sur le nom de TP et l’alias lu est choisi avant un TP pour lequel aucun alias lu n’a été configuré via un registre ou une variable d’environnement. Un TP pour lequel aucun alias de lu n’a été configuré peut être mis en correspondance avec toute requête qui spécifie ce nom TP, car il ne peut pas y avoir de non-correspondance basée sur l’alias lu.
La comparaison des noms TP demandés et disponibles est effectuée dans un ordre spécifique :
Le service SNA recherche d’abord les fournisseurs de services d’appel invokables démarrés par l’opérateur sur le système local (le serveur d’intégration hôte local).
Si aucune correspondance n’est trouvée, le service SNA recherche les TPS invokables démarrés automatiquement sur le système local (le serveur d’intégration d’hôte local).
Si aucune correspondance n’est trouvée, le service SNA recherche les programmes d’appelables démarrés par l’opérateur sur d’autres ordinateurs exécutant Host Integration Server ou des clients.
Si aucune correspondance n’est trouvée, le service SNA recherche les TPS invokables démarrés automatiquement sur d’autres ordinateurs exécutant Host Integration Server ou des clients.
Cette comparaison peut être légèrement modifiée par les entrées de Registre pour le service SnaServr. Les entrées sont appelées DloadMatchTPOnly et DloadMatchLocalFirst.
Si une correspondance est trouvée, le service SNA signale au système contenant le TP demandé pour se connecter à ce service SNA. Si aucune correspondance n’est trouvée, le service SNA rejette la requête entrante.
Pour obtenir des suggestions sur les façons spécifiques de gérer les noms de TP et les alias de lu, consultez Organisation des programmes de transaction au sein d’un réseau SNA.
Notes
En raison du fonctionnement de l’interface de programmation commune pour les communications (CPI-C), une demande d’allocation ne circule pas tant que les mémoires tampons de données locales ne sont pas saturées ou qu’un appel Confirm ou Flush est effectué. Cela peut signifier que la demande d’allocation ne circule pas avant un certain temps après que l’appel d’allocation soit effectué. Par conséquent, tout échec d’allocation provoqué par le rejet de la demande d’allocation au niveau de l’unité logique partenaire sera observé comme l’échec d’un appel ultérieur avec l’un des codes de retour d’échec d’allocation.