IBM Communications Server for Windows
Version 6.4
Readme


© Copyright International Business Machines Corp. 2009
All Rights Reserved
Eléments sous licence - Propriété d'IBM
US Government Users Restricted Rights - Use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Table des matières
1 A propos de cette version
Nouveautés de cette version, historique des correctifs, compatibilité
2 Informations sur l'installation
Configuration matérielle et logicielle requise, installation
3 Informations de désinstallation
4 Informations sur les sites Web
5 Informations sur la version
Fonctions d'IBM Communications Server version 6.4, du client API SNA et du client d'administration éloignée
6 Limitations
7 Remarques et marques


1 A propos de cette version

Communications Server for Windows fournit la connectivité SNA aux systèmes Windows, ce qui leur permet de se connecter à IBM z/OS Communications Server et à d'autres implémentations SNA prenant en charge les connexions LLC2, SDLC, X.25 et Enterprise Extender. Communications Server for Windows fournit également une interface pour les cartes OEM.

IBM Communications Server for Windows Version 6.4 est une version de mise à niveau de la version 6.1.3, qui inclut les nouvelles fonctions Progressive ARB, Retard de changement de chemin, la prise en charge d'IPv6 pour TN3270E et SNA API Client, Java pour la prise en charge CPI-C de Java 1.6. Il fournit également les dernières mises à jour de maintenance à partir de la version 6.1.2 & 6.1.3. La version 6.4 est une version d'installation complète ; si une version précédente antérieure à 6.1.3 est installée, cette version précédente doit être désinstallée avant de pouvoir installer la version 6.4.

Ce document contient des informations supplémentaires qui complètent l'aide en ligne et les publications. Il décrit les fonctions, les conseils, les astuces, les restrictions et les corrections nouvellement ajoutés.

Merci d'avoir choisi IBM Communications Server.

[Revenir en haut de la page] [Table des matières]


1.1 Nouveautés de cette version

IBM Communications Server for Windows Version 6.4 prend en charge les nouvelles fonctions suivantes :

[Revenir en haut de la page] [Table des matières]


1.2 Historique des correctifs du produit

Pour obtenir les dernières informations concernant ce produit, consultez les sites Web indiqués à la section 4.

[Revenir en haut de la page] [Table des matières]


1.3 Compatibilité du produit

Si vous utilisez EE (HPR/IP) vers z/OS v1r8, v1r9 ou v1r10, le correctif pour z/OS APAR OA26490 doit être appliqué au système z/OS. Vous trouverez le niveau de modification provisoire du logiciel pour cet APAR dans :

[Revenir en haut de la page] [Table des matières]


2 Informations sur l'installation

Communications Server for Windows version 6.4 est fourni sur CD-ROM ou sous forme de package à télécharger.

[Revenir en haut de la page] [Table des matières]


2.1 Configuration matérielle requise

Communications Server for Windows, version 6.4 fonctionne sur n'importe quel système d'exploitation 32 bits pris en charge par Windows XP, Windows Server 2003 (Standard Edition ou Enterprise Edition), Windows Vista, ou Windows Server 2008. En fonction de l'environnement réseau et de la plateforme Windows utilisés (poste de travail/serveur), un processeur plus rapide et davantage de mémoire peuvent être nécessaires.

L'espace disque requis est de 5 Mo sur un disque de démarrage et de 175 Mo sur une unité de disque dur pour une utilisation permanente.

Les clients API SNA fonctionnent en mode 32 bits sur tout matériel requis sous Windows XP, Windows Server 2003 (Standard Edition ou Enterprise Edition), Windows Vista, ou Windows Server 2008. L'espace disque requis par un client API SNA est de 25 Mo sur une unité de disque dur pour une utilisation permanente.

Les clients d'administration éloignée fonctionnent sur tout matériel requis sur les systèmes d'exploitation 32 bits sous Windows XP, Windows Server 2003 (Standard Edition ou Enterprise Edition), Windows Vista, ou Windows Server 2008.

[Revenir en haut de la page] [Table des matières]


2.2 Configuration logicielle requise

Communications Server for Windows fonctionne avec les systèmes d'exploitation Microsoft 32 bits suivants :

De plus :

Pour installer Communications Server à l'aide du tableau de bord, vous devez utiliser l'un des navigateurs suivants :

Le client API SNA requiert l'un des éléments suivants :

[Revenir en haut de la page] [Table des matières]


2.3 Installation

Table des matières de la sous-section
2.3.1 Installation de la version 6.4
2.3.2 Remarques relatives à l'installation
2.3.3 Nettoyage après installation
2.3.4 Maintenance du produit
2.3.5 Activation de la consignation de Windows Installer

[Revenir en haut du document] [Table des matières]

2.3.1 Installation de la version 6.4
Les instructions d'installation sont indiquées dans le Guide d'initiation disponible à l'adresse http://www.ibm.com/software/network/commserver/windows/library/index.html

Vous pouvez également accéder au Guide d'initiation à partir du package d'installation.

[Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

2.3.2 Remarques relatives à l'installation

Fermeture des autres applications
Fermez les autres applications avant d'installer Communications Server pour éviter les interactions entre Communications Server et les autres produits installés sur votre système, ainsi que pour permettre le redémarrage après l'installation.

Exécution automatique du CD
Cette fonctionnalité fonctionne sous Windows XP, Windows Server 2003 (Standard Edition ou Enterprise Edition), Windows Vista et Windows Server 2008.

Communications Server et Microsoft SNA Server
Communications Server et Microsoft SNA Server ne peuvent pas être installés sur la même partition principale. La compatibilité inter-produit n'est pas assurée pour de nombreux services communs utilisés par les deux produits.

Droits d'accès d'administrateur requis
Un utilisateur administrateur de Communications Server doit disposer des droits d'accès d'utilisateur avancé Charger et décharger des pilotes de périphérique, comme indiqué dans le Gestionnaire des utilisateurs Windows. Affichez le menu Stratégies > Droits de l'utilisateur, avec l'option Afficher les droits avancés des utilisateurs activée. Vous pouvez ajouter explicitement ce droit à chaque utilisateur. Vous pouvez également ajouter ce droit d'utilisateur au groupe d'utilisateurs IBMCSADMIN.

Installation du contrôleur de domaine
Lorsque vous installez Communications Server sur un contrôleur principal ou secondaire de domaine, vous devez activer le droit d'utilisateur Ouvrir une session localement pour les groupes d'utilisateurs locaux IBMCSADMIN et IBMCSAPI.

[Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

2.3.3 Nettoyage après installation
Le redémarrage est nécessaire après l'installation du serveur.

[Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

2.3.4 Maintenance du produit

Communications Server 6.4 étant une version complète du produit, après son installation, seuls les correctifs CSD de la version 6.4 peuvent être installés.

IBM permet une maintenance de correction en fournissant :

Disponibilité des correctifs APAR et CSD

Correctif APAR :

Communications Server est fourni avec des correctifs APAR spécifiques permettant de résoudre certains défauts du produit. Un correctif APAR destiné à un composant déterminé remplace tous les correctifs APAR précédents de ce composant. Les correctifs APAR ne fonctionnent que si le dernier correctif CSD est installé.

Correctif CSD :

Un CSD est une mise à jour du produit qui inclut tous les APAR. Il s'agit d'une version complète à installer, mais le correctif CSD est installé dans le même répertoire avec les mêmes fonctions que celles du niveau précédent après la désinstallation du niveau précédent.

Vous trouverez les derniers fixpacks et correctifs CSD pour Communications Server for Windows sous la marque Websphere dans le centre des correctifs :
http://www.ibm.com/support/fixcentral/

[Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

2.3.5 Activation de la consignation de Windows Installer
La consignation de l'installation des produits Communications Server est définie lorsque l'installation est lancée, soit à partir du tableau de bord, soit à partir de la ligne de commande en indiquant explicitement la consignation.

Avec Windows Installer 4.0 sous Windows Vista et versions ultérieures, la consignation de l'installation et de la désinstallation est activée par défaut en mode prolixe pour les produits Communications Server. Mais sur les systèmes Windows antérieurs à Vista, les désinstallations lancées à partir de la fonction "Ajout/suppression de programmes" ne sont pas consignées par défaut.

Pour activer la consignation des désinstallations effectuées à l'aide de la fonction "Ajout/Suppression de programmes" sur les systèmes antérieurs, ajoutez l'entrée suivante au registre :

Pour plus d'informations sur l'activation de la consignation, consultez les instructions fournies par Microsoft : http://support.microsoft.com/kb/223300

Pour consigner une désinstallation : avant de désinstaller l'un des trois produits Communications Server, mettez à jour le registre en exécutant msilogging_add.reg (qui se trouve dans le répertoire Outils, dans le répertoire d'installation principal de Communications Server).

Remarque : Comme la consignation de Windows Installer s'applique à tous les produits installés et désinstallés sur le système, si vous laissez la consignation activée, cela peut affecter les performances et réduire l'espace disque disponible.

Après la désinstallation, exécutez msilogging_remove.reg pour supprimer l'entrée. Après la désinstallation du produit, les fichiers msilogging sont conservés dans le répertoire Outils du répertoire d'installation principal de Communications Server. Ces fichiers ne sont pas supprimés avec le produit.

Les journaux d'installation sont placés dans le répertoire des journaux sélectionné lors de l'installation du produit. Si vous désinstallez le produit à l'aide de la fonction "Ajout/suppression de programmes", le journal de désinstallation est placé dans le répertoire TEMP du système. Le nom du fichier journal sera au format MSI***.log où *** est un nombre. Pour identifier le fichier journal qui correspond à la désinstallation de Communications Server, consultez la date du fichier.

[Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]


3 Informations de désinstallation

Suppression des versions précédentes de Communications Server

L'APAR JR21456 de Communications Server version 6.1.2 fournit un module de nettoyage qui supprime le code de Communications Server de la version 6.1.2 et des versions antérieures, ainsi que les informations de registre. Pour effectuer la désinstallation complète des versions précédentes de Communications Server, vous pouvez télécharger le module de nettoyage (JR21546) à l'adresse http://www.ibm.com/support/docview.wss?rs=2262&uid=swg24009834

Les instructions de désinstallation sont indiquées dans le Guide d'initiation disponible à l'adresse http://www.ibm.com/software/network/commserver/windows/library/index.html

Vous pouvez également accéder au Guide d'initiation sur le support d'installation.

Si Personal Communications est installé sur la même machine que Communications Server, vous devez désinstaller Personal Communications avant Communications Server.

En cas d'échec de la désinstallation de Personal Communications, accédez à la page d'assistance sur Communications Server indiquée ci-dessous et consultez les notes techniques pour obtenir plus d'informations :
http://www.ibm.com/support/search.wss?tc=SSHQNF&rs=2262&rank=8&dc=DB520+D800+D900+DA900+DA800+DB560&dtm

Vous devez fermer toutes les applications utilisant Communications Server avant de désinstaller le produit. Si vous tentez de désinstaller Communications Server alors qu'une application (par exemple, APING ou Personal Communications) est en cours d'exécution, le processus de désinstallation s'interrompt tant que l'application n'est pas fermée.

Suppression des versions précédentes de Communications Server for Client Access

Pour supprimer la version 6.1.2 ou une version antérieure, exécutez regsvr32.exe sur cwbzzodb.dll et cwbzzidx.dll. Pour plus d'informations, reportez-vous à la rubrique Réparation avant l'installation ou la désinstallation de Client Access.

Pour supprimer la version 6.1.3, ouvrez Ajout/suppression de programmes, puis sélectionnez le programme et supprimez-le.

[Revenir en haut du document] [Table des matières]


4 Informations sur les sites Web

Informations sur les produits
Pour obtenir les dernières informations sur les produits de la famille IBM Communications Server, visitez le site Web de Communications Server à l'adresse

http://www.ibm.com/software/network/commserver.

Ce site Web fournit des informations et des liens vers des informations importantes, des fiches techniques, des questions courantes, des formations, etc.

Support produit
Pour obtenir les dernières informations de support, visitez le site Web du support de Communications Server à l'adresse

http://www.ibm.com/software/network/commserver/support.

Ce site Web fournit des informations et des liens vers des correctifs de code programme, des conseils, des groupes de discussion, des informations de maintenance, etc.

Notes techniques
Recherchez des notes techniques dans la base de données du support IBM à l'adresse http://www.ibm.com/support/search.wss?tc=SSHQNF&rs=2262&rank=8&dc=DB520+D800+D900+DA900+DA800+DB560&dtm.

FixCentral
Vous trouverez les derniers Fixpack, correctifs CSD ou informations sur la version de mise à jour pour Communications Server for Windows sous la marque Websphere dans le centre des correctifs :
http://www.ibm.com/support/fixcentral/

[Revenir en haut de la page] [Table des matières]


5 Informations sur la version

Table des matières de la section
5.1 Fonctions de la version 6.4
5.2 Fonctions de la version 6.1.3
5.3 Fonctions de la version 6.1.2
5.4 SNA API Client
5.5 Administration éloignée
5.6 Configuration du programme APINGD

[Revenir en haut de la page] [Table des matières]


5.1 Fonctions de la version 6.4

Table des matières de la sous-section
5.1.1 Prise en charge d'IPv6 pour TN3270E et SNA API Client
5.1.2 Prise en charge d'APPC Cancel Conversation
5.1.3 Amélioration de la synchronisation du programme transactionnel
5.1.4 Prise en charge de la suppression du nom de l'unité physique sous ACTPU
5.1.5 Progressive ARB
5.1.6 Retard de changement de chemin
5.1.7 Désactivation de la prise en charge de l'activation d'une liaison à distance

5.1.1 Prise en charge d'IPv6 pour TN3270E et SNA API Client
Le serveur TN3270E prend en charge les clients IPv4 et IPv6 via le protocole IPv6 installé sur la machine serveur. Le protocole IPv6 peut être installé sous Windows XP et versions ultérieures du système d'exploitation Windows. IBM SNA API Client prend également en charge IPv6.

REMARQUE : AnyNet SNA over IP ne prend pas en charge l'adressage IPV6. La fonction AnyNet de Communications Server for Windows est obsolète dans la version suivante. Vous devriez remplacer cette fonction par Enterprise Extender ou une implémentation de SNA API Client.

[Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

5.1.2 Prise en charge d'APPC Cancel Conversation
L'instruction CANCEL_CONVERSATION est une instruction de contrôle qui annule une connexion entre une LU locale et une LU partenaire à l'aide d'un programme transactionnel (tp_id) et d'une conversation (conv_id) spécifiques.

La structure VCB de l'instruction CANCEL_CONVERSATION se définit comme suit :

typedef struct cancel_conversation
{
unsigned short opcode; /* code de fonctionnement de l'instruction */
unsigned char opext; /* code d'extension de l'instruction */
unsigned char format; /* format */
unsigned short primary_rc; /* code retour principal */
unsigned long secondary_rc; /* code retour secondaire */
unsigned char tp_id[8]; /* identificateur TP */
unsigned long conv_id; /* identificateur de conversation */
} CANCEL_CONVERSATION;
Consultez le guide de programmation client-serveur pour obtenir des informations sur l'utilisation de cette instruction. [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

5.1.3 Amélioration de la synchronisation du programme transactionnel
La version précédente de Communication Server for Windows prend uniquement en charge trois niveaux de synchronisation (Tous, Aucun & Confirmation). Deux niveaux (SYNCPT négociable et SYNCPT requis) ont été ajoutés à la définition du programme transactionnel.

  • SYNCPT négociable Le programme transactionnel prend en charge le niveau de synchronisation Aucun, Confirmation ou Point de synchronisation.
  • SYNCPT requis Le programme transactionnel prend en charge un niveau de synchronisation Point de synchronisation.

    Le niveau de synchronisation requis peut être sélectionné lors de la définition du programme transactionnel à partir du panneau de base de l'application de configuration du noeud.

    [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

    5.1.4 Prise en charge de la suppression du nom de l'unité physique sous ACTPU
    En règle générale, Communications Server for Windows identifie le nom de l'unité physique dans le message REQACTPU lors de l'activation des unités physiques du demandeur de LU dépendante. Définissez le mot clé NO_PUNAME_TO_HOST pour désactiver l'envoi de cette identification. Le mot clé NO_PUNAME_TO_HOST du fichier .ACG fait partie de la définition NODE.

    Ce paramètre peut être défini ou annulé dans l'interface graphique de configuration sous le panneau Avancé de la définition du noeud, ainsi que dans le fichier .ACG.

    [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

    5.1.5 Progressive ARB
    IBM Communications Server for Windows prend habituellement en charge tous les algorithmes ARB disponibles sur les connexions RTP : standard, mode réactif et mode progressif. Pour utiliser le traitement RTP normal, de sorte que Communications Server for Windows utilise le mécanisme RTP le mieux adapté aux fonctions du système distant, définissez ce paramètre sur ANY.

    Pour personnaliser le fonctionnement du protocole RTP, indiquez l'une des valeurs suivantes pour le mot clé ARB_SUPPORT ci-dessus dans la section NODE :

  • FORCE_STANDARD_ARB :
    Si cette valeur est définie, Communications Server for Windows prend uniquement en charge l'algorithme ARB standard et non l'algorithme en mode réactif ou progressif.
  • NO_PROGRESSIVE_ARB :
    Si cette valeur est définie, Communications Server for Windows prend en charge les algorithmes ARB standard et en mode réactif et non l'algorithme en mode progressif.

    [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

    5.1.6 Retard de changement de chemin
    Retard minimal, en secondes, avant un changement de chemin dans les connexions RTP. La spécification d'un retard évite les tentatives de changement de chemin inutiles provoquées par un manque en ressources temporaires sur le système distant, en particulier lorsqu'aucune autre route n'est disponible.

    La valeur par défaut pour ce paramètre est de zéro. Elle indique qu'une tentative de changement de chemin peut se produire aussitôt que le protocole indique qu'elle est nécessaire.

    Consultez le chapitre 23, section RTP_TUNNING du manuel de référence des fichiers de configuration pour plus d'informations.

    [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

    5.1.7 Désactivation de la prise en charge de l'activation d'une liaison à distance
    Un nouveau paramètre, DISABLE_REMOTE_ACT, a été ajouté à l'enregistrement de la définition Liaison. Il empêche le noeud distant d'activer le poste de liaison. Les valeurs possibles sont les suivantes :
    • DISABLE_REMOTE_ACT=1, YES. Le poste de liaison peut uniquement être activé par le noeud local ; si le noeud distant tente de l'activer, CS Windows rejettera la tentative ;
    • DISABLE_REMOTE_ACT=0, NO (par défaut). Le poste de liaison peut être activé par le noeud distant.

    Le mot clé DISABLE_REMOTE_ACT du fichier .ACG fait partie de la définition LINK_STATION. Ce paramètre peut être défini ou annulé dans la définition Poste de liaison sous le panneau de réactivation.

    [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]


    5.2 SNA API Client

    Table des matières de la sous-section
    5.2.1 L'application ne redémarre pas
    5.2.2 Prise en charge de plusieurs utilisateurs
    5.2.3 Configuration sous Windows Terminal Client (WTC)
    5.2.4 Remarques sur le traçage et la consignation des messages pour SNA API Client
    5.2.5 Modifications du serveur d'annuaire LDAP

    5.2.1 L'application ne redémarre pas
    Si l'application ne redémarre pas correctement après la perte d'une connexion entre le client API SNA et le serveur, il se peut que les fichiers exécutables et les DLL du client API SNA n'aient pas été correctement déchargés de la mémoire. Dans ce cas, il se peut que l'application ne redémarre pas, même après le rétablissement de la connexion.

    Vous devez alors arrêter manuellement les exécutables du client API SNA. L'utilitaire en mode ligne de commande resetapi.exe est installé avec les API client Windows. Cette utilitaire arrête les exécutables du client API SNA sans redémarrage du client.

    [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

    5.2.2 Prise en charge de plusieurs utilisateurs
    Les systèmes s'exécutant dans l'environnement Windows Terminal Server (WTS) avec SNA API client peuvent prendre en charge plusieurs utilisateurs. Le scénario ci-dessous présente l'utilisation de clients Windows Terminal Server, tel que Remote Desktop, avec une connexion vers un WTS incluant Personal Communications et le client API SNA dans un environnement multi-utilisateur.

    Clients bureautiques distants <====> WTS avec Personal Communications et SNA API Client <====> CS/Windows <====> Hôte z/OS

    [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

    5.2.3 Configuration sous Windows Terminal Client (WTC)
    Aucune configuration spéciale n'est requise sur WTC. Connectez-vous à WTS à l'aide du client Remote Desktop ou de tout autre logiciel WTC. Utilisez la session Personal Communications définie sur le WTS.

    La configuration sur WTS s'effectue comme suit :

    1. Configurez le client API SNA pour les sessions LUA. Cette configuration peut être effectuée pour chaque utilisateur.
      1. Choisissez Configuration INI locale.
      2. Configurez les données globales telles que l'ID utilisateur, le mot de passe, etc. Pour plus d'informations, reportez-vous au Guide d'initiation.
      3. Créez une définition LUA comprenant le nom de session LUA, l'adresse IP du serveur, etc. Pour plus d'informations, reportez-vous au Guide d'initiation.
      4. Enregistrez la configuration.
        • Si vous souhaitez enregistrer cette configuration pour un utilisateur particulier, créez un répertoire au nom de cet utilisateur (par exemple, utilisateur1) et enregistrez le fichier de configuration sous le nom de cet utilisateur ( par exemple, utilisateur1.ini). Pour achever la configuration, reportez-vous à la section 3 ci-dessous "pour configurer un fichier .INI différent pour chaque utilisateur."
        • Si vous souhaitez que la configuration soit identique pour tous les utilisateurs, enregistrez le fichier à l'emplacement par défaut sous le nom par défaut. La seule modification est la prise en charge de la configuration multi-utilisateur.
    2. Configurez Personal Communications pour l'utilisation du client API SNA. La procédure reste inchangée, avec ou sans prise en charge de WTS.
      1. Choisissez l'interface Client API.
      2. Choisissez la connexion LUA0,1,2,3 via WINRUI.
      3. Cliquez sur Paramètres de liaison et choisissez le nom de la session configurée sur le client API SNA.
      4. Conservez les valeurs par défaut pour les autres paramètres.
    3. Pour configurer un fichier .INI différent pour chaque utilisateur, procédez comme suit :
      1. Connectez-vous au système sous l'identité de l'utilisateur pour lequel le fichier .INI doit être configuré.
      2. Accédez au panneau Propriétés système > Avancé et cliquez sur Variables d'environnement.
      3. Cliquez sur Variables utilisateur > Nouveau.
      4. Tapez CSNTAPI pour la valeur de la variable et entrez le chemin du fichier .INI.

        Par exemple si la configuration utilisateur 1 se trouve dans le fichier C:\utilisateur1\utilisateur1.ini et la configuration utilisateur 2 se trouve dans le fichier C:\utilisateur2\utilisateur2.ini, vous devez effectuer la configuration comme suit :

        • Pour l'utilisateur 1, entrez CSNTAPI pour la valeur de la variable et C:\utilisateur1\utilisateur1.ini pour le chemin
        • Pour l'utilisateur 2, entrez CSNTAPI pour la valeur de la variable et C:\user2\user2.ini" pour le chemin

    La procédure de configuration n'a pas été modifiée. La configuration des sessions LUA, des programmes de transaction, etc. est conservée. Il n'est pas nécessaire de modifier la configuration de Personal Communications. Les étapes de la configuration de Personal Communications ou de toute application restent inchangées.

    [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

    5.2.4 Remarques sur le traçage et la consignation des messages pour SNA API Client
    • Si l'option Trace activée pour toutes les API de la fonction de trace est choisie, les traces de débogage sont également consignées dans le fichier pcatrace.dat. Lors de la collecte des traces de débogage, sélectionnez l'option Trace activée pour toutes les API. Cliquez sur Démarrer pour lancer le traçage. La trace de débogage s'arrête lors que le traçage est arrêté ou lorsque l'utilisateur quitte l'interface de l'utilitaire de trace.
    • Les journaux de messages sont toujours stockés dans le fichier MsgLog.dat. Les fichiers journaux de messages (MsgLog.dat) seront collectés dans deux fichiers de 131 Ko chacun. Cela permet de réduire la taille de chaque fichier journal de messages, ce qui facilite la gestion. Le programme de groupage d'informations collecte les deux fichiers journaux de messages.
    • La fonction de trace peut être lancée par les administrateurs, ainsi que par les utilisateurs n'ayant pas les droits d'administration.
    • La trace détaillée (pcatrace.dat) est collectée dans plusieurs fichiers. La taille par défaut de chaque fichier est de 100 Ko et le nombre maximal de fichiers est 999.
    • Les valeurs par défaut (taille de fichier et nombre maximal de fichiers) peuvent être modifiées à l'aide de la commande tracedg /s FileSize /n MaxNum. Cette valeur est globale. La valeur définie par un utilisateur sera appliquée à tous les utilisateurs.

      Par exemple, tracedg /s 92160 /n 20 entraîne la création de fichiers pcatrace d'une taille de 90 ko et le nombre maximal de fichiers créés est 20. Ensuite, le 21ème fichier créé écrase le premier fichier.

    • L'emplacement par défaut de Msglog.dat et pcatrace.dat est le répertoire défini par "APPDATA" (collecte distincte pour chaque utilisateur). Cela peut être modifié en configurant la variable d'environnement CSNTAPITRCLOG.
    • Le programme de groupage d'informations est fourni avec cette version pour capturer les principaux fichiers client requis pour le diagnostic des incidents. Lors de l'identification et la résolution d'un incident avec IBM, exécutez-le et envoyez le résultat à IBM. Pour exécuter le programme de groupage d'informations, accédez au répertoire d'installation du client API SNA (par exemple, C:\CSNTAPI) sur la ligne de commande. Exécutez INFOB.exe à partir de la ligne de commande. Par exemple :

      C:>INFOB

      Il effectue une procédure de 13 étapes et collecte les informations (11 documents mentionnés ci-dessous) dans cspd.exe. Celui-ci est placé dans le répertoire d'installation (par défaut C:\Program Files\IBM\CS SNA API Client).

      Lorsque vous signalez un incident à IBM, exécutez le programme de groupage d'informations et envoyez le fichier cspd.exe au service d'assistance IBM.

      Récapitulatif des fonctions du programme de groupage d'informations pour le client API SNA :

      1. Fichier MsgLog.dat (fichiers journaux de messages d'erreur)
      2. Fichier pcatrace.dat (fichiers de données de trace de débogage)
      3. Fichier CSNTAPI.TRC (fichier de données de trace non formatées)
      4. Fichier CSNTAPI.FMT (fichier de données de trace formatées)
      5. Fichier APIERROR.LOG (fichier journal d'erreurs api)
      6. Ensemble de journaux d'événement
      7. Fichier journal Dr.Watson
      8. Fichier CSNTAPI.INI
      9. Ensemble des clés de registre. Les variables d'environnement utilisateur et les variables d'environnement système font partie des paramètres du registre. Les variables d'environnement utilisateur correspondent à l'utilisateur exécutant le programme de groupage d'informations.
      10. Listes de répertoires CSNTAPI
      11. Listes de répertoires Windows\system32. Cet élément est utile lorsque vous déterminez si l'application utilise le fichier WINRUI32.DLL, WINAPPC32.DLL, etc. à partir de l'installation du client API SNA ou de l'installation Microsoft Windows. Nous avons observé que si ces API sont utilisées à partir de l'installation Microsoft Windows, l'application ne fonctionne pas.

    [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

    5.2.5 Modifications du serveur d'annuaire LDAP
    Les informations relatives à la configuration du client API SNA peuvent être conservées dans un répertoire LDAP. Les serveurs d'annuaire pris en charge pour cette version sont Netscape Directory Server Version 4.0, IBM Directory Server Version 3.1.1 et Lotus Domino Version 5.0.

    Les extensions du schéma sont fournies pour Netscape Directory Server et doivent être ajoutées à la configuration du serveur avant de la configuration des clients API SNA. Les autres serveurs d'annulaire pris en charge contiennent déjà les définitions de schéma nécessaires. Le contrôle d'accès pour les entrées et les attributs doit être vérifié à l'aide de l'utilitaire d'administration du serveur d'annuaire.

    L'utilitaire de configuration LDAP API SNA vous permet de modifier les entrées étendues. L'ID utilisateur employé avec cet utilitaire doit posséder le droit d'écriture dans l'annuaire. Vous pouvez utiliser l'ID d'administrateur d'annuaire (qui possède ces droits d'accès) lors de l'exécution de l'utilitaire de configuration du client.

    Pour ajouter les extensions de schéma au serveur Netscape, ajoutez les lignes suivantes au fichier slapd.conf, qui est situé dans le répertoire \config du serveur d'annuaire Netscape.

    include ibmcs-oc-ns.conf
    include ibmcs-at-ns.conf

    Le nom de chemin exact de cet annuaire dépend de l'emplacement d'installation du serveur d'annuaire et du nom du serveur d'annuaire. Voir l'exemple suivant :

    lettre_unité:\netscape\suitespot\slapd-nom_hôte\config

      [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]


      5.3 Administration éloignée

      5.3.1 Accès au fichier journal des messages
      Vous pouvez consulter le fichier de messages sur une machine distante exécutant Communications Server. Mappez l'unité sur laquelle Communications Server est installé. Ouvrez ensuite l'Afficheur de journaux de Communications Server et ouvrez le fichier journal distant pcwmsg.mlg.

      [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

      5.3.2 Administration de plusieurs versions de serveur
      La configuration à distance permet de configurer uniquement la même version de Communications Server. Par exemple, la fonction de configuration à distance de la version 6.1.3 permet uniquement de configurer un noeud Communication Server Version 6.1.3.

      [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

      5.4 Configuration du programme APINGD
      Pour effectuer un APING sur un noeud SNA, le programme de transaction APINGD doit être correctement défini dans le fichier de configuration. Lors de la création d'un fichier de configuration, un programme de transaction APINGD est défini dans le répertoire d'installation de Communications Server. Si vous copiez un fichier de configuration depuis un autre emplacement ou une autre version installée dans un autre répertoire, mettez à jour le chemin d'accès de APINGD. Par exemple, pour utiliser un fichier de configuration de la version 6.1.3 dont le chemin d'installation par défaut est C:\IBMCS avec la version 6.4 dont le chemin d'installation par défaut est C:\Program Files\IBM\Communications Server, modifiez :
      PATHNAME=C:\IBMCS\apingd.exe
      pour obtenir :
      PATHNAME=C:\Program Files\IBM\Communications Server\apingd.exe
      

      Pour effectuer cette modification, vous pouvez éditer le fichier de configuration .acg ou bien utiliser l'interface graphique de configuration accessible dans "CPIC et APPC -> Programmes de transaction"

      [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]


      6 Limitations

      6.1 SLP et différents niveaux de chiffrement
      Une session client qui vise un port TN3270 Haute sécurité à l'aide d'une requête SLP peut être connecté à un port TN3270 Authentification seulement, ou vice versa, si tous deux sont configurés sur le même serveur.

      Communications Server for Windows vous permet de configurer différents niveaux de chiffrement (Elevé, Moyen, Authentification seulement) lors de la définition d'un port TN3270(E) ou TN5250. Ces niveaux de chiffrement sont indiqués dans le panneau Sécurité de la boîte de dialogue Définition de définitions de port TN3270E.

      Certains clients TN3270 ou TN5250 (par exemple, Host On-Demand Version 5) n'utilisent pas l'intégralité des informations SSLv3 que Communications Server publie dans un paquet SLP. Ces clients se connectent au premier port avec le niveau, le secteur, le groupe et la charge SSL qu'ils ont demandés, indépendamment du niveau de chiffrement. La connexion résultante peut produire une session qui se connecte à un port possédant un niveau de chiffrement différent de celui prévu.

      Pour éviter cette situation, utilisez un seul niveau de chiffrement (Elevé, Moyen ou Authentification seulement) pour chaque machine ou secteur. Les ports d'un serveur déterminé peuvent être ciblés uniquement en activant et désactivant la sécurité et l'authentification client.

      [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]

      6.2 Utilisation de SNA API Client
      Le client API SNA est bien adapté aux environnements constitués de succursales car il permet à un petit nombre d'utilisateurs de se connecter. Si vous regroupez plusieurs succursales sur un centre de données, ou si vous utilisez une application de serveur Web, nous vous recommandons d'utiliser un serveur plutôt qu'un client API SNA.

      [Revenir en haut de la sous-section] [Revenir en haut du document] [Table des matières]


      7 Remarques et marques

      AnyNet, IBM, S/390, WebSphere et z/OS sont des marques d'IBM Corporation aux Etats-Unis et/ou dans certains autres pays.

      Tivoli et Tivoli License Management sont des marques de Tivoli Systems Inc. ou d'IBM Corporation aux Etats-Unis et/ou dans certains autres pays.

      Lotus et Domino sont des marques de Lotus Development Corporation aux Etats-Unis et/ou dans certains autres pays.

      Microsoft, Windows, Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista et Windows Server 2008 sont des marques de Microsoft Corporation aux Etats-Unis et/ou dans certains autres pays.

      VMware est une marque de VMware, inc. [Revenir en haut de la page] [Table des matières]