Résolution des problèmes de Host Integration Server événement 23 avertissements

Résumé

Lorsque vous configurez un Host Integration Server (HIS) pour se connecter à un ordinateur central IBM ou les iSeries (AS / 400) système, vous installez et configurez un ou plusieurs services de liaison.  Les services de liaison assurer la communication entre les serveur SNA Server service pilotes de périphérique et, pour prendre en charge les communications SNA sur les différents types de lien.

Une fois les services de liaison sont installés et configurés, vous devez définir les connexions de l’hôte sur lequel le service du serveur SNA va communiquer avec les systèmes hôtes IBM d’accéder aux applications de l’entreprise. Les connexions tel que défini dans la configuration HIS assurent la connexion de niveau liaison SNA utilisée pour communiquer avec le système hôte IBM.

Si le service de liaison sous-jacente détecte un problème avec le lien physique au système hôte IBM, un code d’interruption est généré. Ce code d’arrêt est retourné pour le service du serveur SNA. Lorsqu’il est averti qu’une interruption de la connexion s’est produite, le service du serveur SNA effectue les actions suivantes :

-Connecte un avertissement d’événement 23 dans le journal des événements application

-Nettoie les sessions SNA actives sur la connexion concernée.

-Émet un message de demande de Close(LINK) pour le service de liaison pour fermer la connexion

Lorsqu’une panne de connexion se produit, toutes les sessions de SNA (lu) actives définies sur cette connexion sont fermées qui signifie que les utilisateurs finaux de perdre leur connectivité aux applications back-end IBM à laquelle ils ont été interagir avec.

Détails de l’événement 23

L’événement 23 indique qu’une connexion d’hôte a échoué. Les détails inclus dans le message fournissent plus de détails sur la raison de l’échec des événements. Le format du message d’événement est illustré ici :

L’ID d’événement : 23
Source : Le serveur SNA
Description :
Échec de la connexion
Connexion = nom de la connexion
Service de liaison = nom de service de liaison
Qualificateur = code de panne

Explication
Un service de liaison a signalé un échec de connexion au nœud. Voir ci-dessous pour plus d’informations sur le code de la panne qui a provoqué l’échec de la connexion.

TOKEN RING, ETHERNET OU FDDI

0029



Le système distant ne répond pas à la tentative d’activation d’une connexion SNA par l’ordinateur Host Integration Server.

00AE

La connexion a échoué en raison d’un (1) un délai de connexion, en raison des délais de réponse du système à distance, ou (2), le système distant a désactivé la connexion par l’envoi d’une trame de DISC(connect) ou DM Service de SNA Host Integration Server.

Si le problème de lenteur du système distant est suspectée, les minuteurs de t1 et ti de connexion hôte intégration serveur SNA doivent être augmentées.

Si vous vous connectez à un AS / 400 et il n’active sessions utilisateur, l’AS / 400 va supprimer la connexion si l’AS / 400 APPC contrôleur « Commutation déconnecter » est défini sur Oui.

Pour isoler le problème, une trace du Moniteur réseau Microsoft (ou un utilitaire similaire) doit être utilisé pour capturer une occurrence de l’erreur.

00AF

La connexion au système distant a été perdue. Cela peut se produire suite à une erreur de média sur votre réseau local, une panne d’un pont intermédiaire ou d’un routeur, ou si le système distant a cessé de répondre.

00AC

Le pilote DLC de Windows NT a a détecté une erreur de protocole DLC dans une trame reçue par le système distant et a envoyé une trame rejeter (FRMR) à l’origine de la connexion à la fin. L’événement 228 doit être consigné lorsque cette erreur se produit. Consultez le code FRMR dans 228 de l’événement pour plus d’informations décrivant la raison pour laquelle la FRMR s’est produite.

00AD

Le système distant a a détecté une erreur de protocole DLC dans une trame envoyée par Windows NT et il a envoyé une trame rejeter (FRMR) à l’origine de la connexion à la fin. L’événement 227 doit être consigné lorsque cette erreur se produit.

Notez relatifs aux services de liaison IP-DLC: connexions à l’aide d’un service de liaison IP-DLC également consigner les avertissements d’événement en cas d’échec de la connexion. Dans ces cas, les deux codes de panne qui peuvent être enregistrés sont 0029 et service de liaison 00AE qui présentent le même sens comme ils le font pour les connexions utilisant un DLC 802.2. Dans le cas d’une panne de 00AE pour IP-DLC, les informations concernant les minuteurs DLC t1 et ti ne s’appliquent pas sont des paramètres spécifiques DLC.

Le message d’événement 23 lors de l’affichage dans le journal des événements d’Application comprend également les codes de panne pour les services de liaison SDLC. Les pannes SDLC ne sont pas abordées ici, car l’utilisation des services de liaison SDLC est rare.



Dépannage des échecs de connexion événement 23

En général, les échecs de connexion de Host Integration Server qui résultent de la journalisation des avertissements d’événement 23 se produisent en raison des conditions externes au système serveur HIS. Par conséquent, des étapes de dépannage nécessitent généralement les actions à prendre externe pour le serveur HIS.

Interruptions de connexion 23 d’événement sont les plus courantes dans les environnements de Host Integration Server qui utilisent le service de liaison DLC 802.2 pour la connexion à des systèmes hôtes IBM via le protocole DLC. Il y avait auparavant un certain nombre d’interruptions de connexion événement 23 avec SNA Server et environnements de Host Integration Server à l’aide de SDLC ou X.25 lier des services, mais l’utilisation de protocoles SDLC et X.25 est rare de nos jours. L’utilisation des services de liaison IP-DLC se multiplient, cependant, nous ne voyons événement 23 avertissements consignés souvent dans ces environnements. Le service de liaison IP-DLC enregistre un certain nombre de ses propres messages d’événement spécifique lorsqu’il a des problèmes avec les connexions TCP/IP sous-jacent qu’il utilise pour les communications. Un événement de 23 est susceptible de se produire pour une interruption prolongée qui empêche l’établissement de ses sessions TCP/IP requises pour le serveur de nœud de réseau (NNS) le service de liaison IP-DLC.

Pour les environnements de Host Integration Server à l’aide de DLC 802.2 et IP-DLC lier les services, les traces suivantes sont généralement requises pour aider à déterminer la cause des échecs de connexion qui résultent de la journalisation des avertissements d’événement 23 :

- Les traces de host Integration Server

o que ces traces sont capturées à l’aide de l’utilitaire de Trace SNA (snatrace.exe)

- Les traces du réseau

utilitaires de capture o réseau tel que moniteur réseau Microsoft, Wireshark, Ethereal sont communs utilisés.

L’idée de base est de permettre des traces réseau et son avant un échec de connexion. Lorsqu’un échec de connexion se produit, vous devez arrêter les traces dès que possible pour éviter que les données de trace qui contient l’échec d’un écrasement.



Traces de Host Integration Server

Les étapes suivantes mettent en avant les traces de Host Integration Server à capturer pour une interruption de la connexion :

1. Exécutez snatrace.exe.

2. Cliquez sur l’onglet de Propriétés globales de traçage .

3. changez le paramètre de Longueur du retournement du fichier Trace (octets) 20000000 à 200000000 (ajout d’un 0 à la longueur de la valeur par défaut).

4. activer l’option Permettre son aux administrateurs d’effectuer le suivi .

5. Cliquez sur Appliquer.

6. Cliquez sur l’onglet Suivi .

7. Mettez en surbrillance le nom du service de liaison (SNAIP1, SNADLC1, etc.) spécifié dans l’avertissement d’événement 23 et puis cliquez sur Propriétés.

8. Cliquez sur l’onglet Suivi du Message .

9. activer les Messages de niveau 2 , puis sur OK.

10. Sélectionnez SnaServer dans Liste des éléments de Trace , puis cliquez sur Propriétés.

11. Cliquez sur l’onglet Suivi du Message .

12. activer le Contrôle de liaison de données et puis cliquez sur OK.

13. vous pouvez réduire l’utilitaire de Trace SNA à ce stade que les traces sont activées. Remarque: Si vous fermez l’utilitaire de Trace SNA, vous serez invité par une boîte de dialogue avertissement indiquant que laisser de traces activées peut avoir un impact sur les performances du serveur. Vous pouvez cliquez sur OK et fermez la fenêtre si vous choisissez.

14. une fois l’erreur de connexion se produit, restaurer (ou ouvrir) la fenêtre Utilitaire de Trace SNA et cliquez sur le bouton Effacer toutes les Traces pour désactiver le suivi. Vous souhaitez faire dès que possible, car les traces HIS sont écrites dans les fichiers de trace circulaire. Les données seront remplacées si les traces de continuent à s’exécuter. Sur les serveurs occupés, les traces peuvent être disposés rapidement.

Traces du réseau

La procédure d’activation d’une trace réseau dépend de l’utilitaire de capture de réseau que vous souhaitez utiliser. Par conséquent, étapes de capture réseau spécifique ne sont pas incluses ici. Au lieu de cela, une vue d’ensemble de ce qui doit être capture est fourni :

1. la capture réseau doit inclure les données qui transitent entre le système de Host Integration Server et le système d’hôte IBM (mainframe ou iSeries). Si vous utilisez le service de liaison DLC 802.2, vous voulez capturer le trafic de réseau DLC. S’il existe plusieurs cartes réseau dans le système de Host Integration Server, vous devez vous assurer que l’utilitaire de capture de réseau est suivi de la carte réseau appropriée si la trace de réseau est en cours de capture sur le système de Host Integration Server.

Vous pouvez configurer un filtre pour limiter la quantité de trafic en cours de capture. Si vous utilisez un filtre, une option consiste à capturer le trafic réseau vers/à partir de l’adresse MAC (si vous utilisez DLC) ou l’adresse TCP/IP (si vous utilisez IP-DLC) du système hôte IBM à distance.

Le risque avec l’utilisation de filtres est qu’il est possible que le filtre ne peut capturer tout le trafic qui est pertinent pour les problèmes de connexion. Cela est plus susceptible de se produire avec les connexions TCP/IP. Un filtre peut manquer de redirection ICMP ou Destination des cadres inaccessibles. Ces types d’images peuvent se produire lorsque le chemin d’accès de réseau entre le serveur HIS et le système hôte d’IBM est confronté à un problème ou lorsqu’un routeur entre ne dispose pas de l’installation correcte ou a perdu la connectivité.

Ces types de trames sont envoyées à partir d’une autre adresse TCP/IP (par exemple, l’adresse du routeur) et peuvent se perdre, lorsque vous utilisez un programme d’installation de filtre avec son adresse de TCP/IP et d’hôte IBM système adresse TCP/IP.



2. Si le système de Host Integration Server et au système hôte IBM sont séparés sur un WAN (routeurs, commutateurs, ponts entre les systèmes, par exemple), il est recommandé d’effectuer au moins des traces réseau simultanées sur les segments de réseau de Host Integration Server et réseau du système hôte IBM. Cela donne une visibilité sur le trafic réseau sur chaque segment de réseau. Cela vous permet de voir si les paquets réseau se font sur le réseau étendu. Ayant une trace réseau sur le segment de réseau qu’un seul ne donne pas une image complète, car vous ne pouvez pas déterminer avec certitude si un paquet manquant atteint l’autre segment de réseau, ou si une réponse a été perdue dans l’autre sens.



3. Si les échecs de connexion sont aléatoires, il se peuvent que les traces deviez exécuter pendant une période prolongée. Dans ces cas, vous souhaiterez le programme d’installation de l’utilitaire de capture de réseau pour enregistrer des traces réseau à certains intervalles au cas où les traces ne peut pas être arrêtés immédiatement lorsqu’une panne survient. Ainsi, pour vous assurer que les données pertinentes sont capturées.



4. lorsqu’un échec de connexion se produit, vous souhaitez arrêter et enregistrer la trace réseau dès que possible.



Analyse du suivi

L’équipe de support de Microsoft Host Integration Server utilise les données de trace qui en résulte pour isoler la cause des échecs de connexion. Dans la plupart des cas, le problème est provoqué par l’une des opérations suivantes :

: Problème de configuration

adresses de réseau Incorrect o

o Incorrect Service de Points d’accès (SAP)

paramètres de pare-feu incorrects o (IP-DLC)

-Des problèmes de réseau

problèmes de réseau temporaires o

problèmes de mise en forme du routeur/commutateur/paquet o

-Pannes du système hôte IBM

fenêtres de maintenance normales o

pannes inattendues o sur des systèmes mainframe ou iSeries



En règle générale, les traces réseau sont les principaux outils de résolution des problèmes de ces types de problèmes car ils sont normalement externes pour Host Integration Server. Les traces HIS sont utiles pour afficher le flux de données conduisant à la panne. Les traces de message lien service niveau 2 incluent également les codes retour DLC (pour les services de liaison DLC 802.2) qui peuvent également être utiles. L’article suivant de la Base de connaissances décrit comment le DLC renvoient les codes sont interprétées à l’aide de ces traces :

INFORMATIONS : Code de panne DLC 802.2 de SNA Server niveau 2 Trace interprétation



Pour les échecs de connexion 802.2 DLC, le code d’arrêt dans l’événement 23 indique pourquoi la connexion interrompue. Si vous faites référence aux descriptions ci-dessus d’interruption de service, vous verrez vous faire une idée sur ce que vous recherchez dans les traces.

Les traces aident à vérifier ou à prouver la cause sous-jacente, comme indiqué par le code de la panne.

Par exemple, un code d’arrêt de 0029 (système distant ne répond ne pas) indique généralement que le service de liaison DLC 802.2 ne reçoit pas de réponse au TEST DLC ou qu’il envoie au système distant pour établir la connexion DLC des commandes XID. Dans ces cas, vous devez également voir un avertissement d’événement 230 consigné dans le journal des événements de l’Application qui indique si le problème se produit en raison d’une commande TEST ou XID. Dans ce cas, les traces réseau servent à vérifier que la commande de TEST et/ou XID est envoyée sur le réseau par le service de liaison DLC 802.2. Si les traces réseau simultanées ont été capturés, vous pouvez voir si les commandes TEST ou XID atteint le segment de réseau distant. Si tel est le cas, vous devez voir une réponse TEST ou XID est renvoyée. Si vous voyez la réponse dans la trace de réseau distant mais pas dans l’autre trace réseau, puis les paquets ont été supprimées/perdu lors du parcours du réseau étendu. À ce stade, dépannage continue avec votre équipe de prise en charge réseau.

Pour les codes de panne qui indiquent un cadre rejeter (FRMR) envoyées ou reçues, vous recherchez via la trace réseau la FRMR et puis en arrière pour visualiser la séquence qui a conduit au rejeter les trames envoyées. Dans ces cas, causes typiques sont les cadres DLC transmises hors séquence, les numéros de séquence incorrecte, une taille de cadre DLC incorrecte. Des détails supplémentaires seront afficheront dans un avertissement d’événement 227 correspondant, qui comprend un code de rejet de trame qui indique la raison que du rejet de trame a été envoyée.


Propriétés

ID d'article : 2824716 - Dernière mise à jour : 26 janv. 2017 - Révision : 1

Commentaires