La commande TRCINT (Trace Internal) de i5/OS collecte de nombreux types de traces de composantes LIC (Licensed Internal Code). La série Dépanner TCP/IP se poursuit par l’examen du petit sous-ensemble de points de trace de composantes de sockets qui vous montrent les API sockets. Toute application réseau active sur votre système utilise des API sockets et, si vous comprenez ces points de trace, vous pourrez facilement cibler les problèmes de communications et les résoudre prestement.
Les points de trace des API sockets que j’explique ici sont apparus pour la première fois dans OS/400 V4R4. De nombreux changements et de nombreuses mises à jour de ces points de trace ont eu lieu au fil des ans et des releases successives. Une mise à jour de la V5R1 a ajouté le nom de l’API socket à chacun des points de trace afin de faciliter son débogage. En effet, sans le nom de chaque API dans les données des points de trace, il est très difficile de savoir ce que l’application accomplit.
C’est pourquoi je recommande de n’examiner une trace que sur une version V5R1 ou ultérieure. J’ai créé la sortie TRCINT de cet article sur un système en V5R4. Si vous collectez une trace d’API socket sur une release pré-V5R4, vous constaterez peut-être de petites différences. Certains des numéros de points de trace ont été changés en V5R3 lorsque de nouvelles API sockets ont été ajoutées au système. IBM a également ajouté des données de débogage à ces points de trace dans chaque release V5Rx. Par conséquent, ne vous attendez pas à ce qu’une sortie de points de trace pré-V5R4 ressemble exactement aux figures de cet article. IBM pourrait fort bien modifier l’information de trace interne dans les futures releases de i5/OS, s’il s’avère que des informations supplémentaires aideraient à déboguer les problèmes réseau.
Contenus complémentaires :
Article iTPro.fr : Les API : guide pour débutants
TCP/IP et sockets en RPG |
Les API sockets sont l’interface de programmation par laquelle les applications réseau envoient et reçoivent des données sur un réseau TCP/IP. Les API sockets s’interfaçent soit avec la couche transport soit directement avec la couche réseau de la pile de communication (figure 1). Une application peut utiliser les API sockets pour des transferts de données par connexion (TCP) et sans connexion (User Datagram Protocol – UDP), ainsi que pour la communication interprocessus avec d’autres jobs et processus tournant sur le même système. En quelque sorte, l’API socket est l’intermédiaire entre ce qu’une application utilisateur montre et les données qui s’écoulent hors de la boîte. Une application client/serveur simple est créée à l’aide des API socket(), bind(), listen(), accept(), connect(), send()/write(), recv()/read() et close() (figure 2).
Faites très attention à l’ordre des appels dans la figure 2 et recherchez ces appels dans une trace. Vous saurez alors ce que votre application fait – et ne fait pas. Toutes les applications n’appellent pas les mêmes API. Les applications de type UDP sans connexion, par exemple, n’appellent pas listen() ou accept(), donc le débogage est plus facile si ces concepts vous sont familiers. J’explique ces API et d’autres quand je m’intéresse à la sortie TRCINT du serveur et client FTP i5/OS. Pour plus d’informations sur les API sockets i5/OS, lisez « TCP/IP and Sockets in RPG » (www.itpro.fr Club abonnés, iSeries News juillet-août 2006), ou allez à l’IBM Information Center . Chaque API socket renverra -1 en cas de défaillance et définira une valeur errno (numéro d’erreur) globale. Cette variable a des valeurs prédéfinies sur toutes les plates-formes et i5/OS n’est pas différent à cet égard. Vous trouverez une liste des valeurs errno i5/OS dans l’IBM Information Center ().
Téléchargez cette ressource
Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
