Incidents d'administration liés à l'outil de scriptage wsadmin

Utilisez ces informations si vous rencontrez des incidents lors du démarrage ou de l'utilisation de l'outil wsadmin.

Type d'incident
Si votre incident ne figure pas ici :
  • [AIX Solaris HP-UX Linux Windows][IBM i]Si vous ne pouvez pas entrer le mode de commande wsadmin, tentez d'exécuter wsadmin -c "$Help wsadmin" pour savoir si vous avez entré la commande correctement.
  • [z/OS]Si vous ne pouvez pas entrer le mode de commande wsadmin, tentez d'exécuter wsadmin -c "$Help wsadmin" pour savoir si vous avez entré la commande correctement.
  • Si vous n'obtenez pas l'invite de commande wsadmin, entrez $Help help pour vous assurer que vous utilisez les commandes correctement.
  • Les commandes wsadmin sont une version élaborée de Jacl (Java Command Language), qui est à son tour une implémentation Java du langage de commande Tcl. Pour plus de détails sur la syntaxe Jacl au-delà des commandes wsadmin, reportez-vous au site Tcl developer Xchange. Pour des détails spécifiques sur l'implémentation Java de Tcl, reportez-vous au site The Tcl/Java Project.
  • Recherchez des indices dans le fichier rép_install/profiles/nom_profil/logs/wsadmin.traceout.
    • N'oubliez pas que wsadmin.traceout est actualisé (les enregistrements de journal existants sont supprimés) lorsqu'une nouvelle session wsadmin est lancée.
    • Si l'erreur renvoyée par wsadmin ne semble pas concerner la commande que vous avez entrée, par exemple si vous recevez l'erreur WASX7023E indiquant qu'une connexion n'a pas pu être créée pour l'hôte "myhost" et que vous n'avez pas indiqué "-host myhost" sur la ligne de commande, examinez les fichiers de propriétés utilisés par wsadmin pour déterminer les propriétés qui ont été indiquées. Si vous ne savez pas quels fichiers de propriétés ont été chargés, consultez les messages WASX7326I du fichier wsadmin.traceout. L'un de ces messages s'affichera pour chaque fichier de propriétés chargé.

[AIX Solaris HP-UX Linux Windows][IBM i] Lorsqu'aucune de ces opérations ne résout l'incident, vérifiez dans le support disponible en ligne (conseils et astuces, notes techniques et correctifs) s'il a été identifié et documenté. Si vous n'y trouvez aucune information utile, veuillez contacter le support technique IBM.

WASX7016E, WASX7017E ou WASX7209I: Erreur du langage de script Jython

Les erreurs suivantes surviennent lorsque vous exécutez ce script Jython :

script Jython

"profile_root/bin/wsadmin.sh -lang jython -profile profile_name -host host_name -f script_file.py"

Messages d'erreur

WASX7209I : Connecté au processus "server1" sur le noeud
nom_noeud en utilisant le connecteur SOAP ; le type de processus est :
UnManagedProcess
WASX7016E: Exception reçue lors de la lecture du fichier
"fichier_script.py"; informations sur l'exception :
sun.io.MalformedInputException
WASX7017E: Exception reçue lors de l'exécution du fichier
"fichier_script.py"; informations sur l'exception :
com.ibm.bsf.BSFException : exception de Jython : Traceback
(innermost last):   File "<string>" line 89, in ? NameError: log
Ces erreurs peuvent se produire car le fichier contient des caractères UTF-8 qui ne sont pas valides. La page de codes par défaut pour RHEL 3 est UTF-8 (en_US.UTF-8). Lors de la création d'un fichier texte avec le code Java™, le programme présuppose que tous les caractères sont encodés au format UTF-8. Le fichier peut contenir un ou plusieurs caractères qui ne font pas partie de la spécification UTF-8, ce qui provoque l'échec du chargement. Pour déterminer simplement si un caractère non valide est à l'origine de l'erreur, il suffit d'entrer export LANG=C et d'exécuter à nouveau le script. Si vous savez que l'incident est dû à un caractère non valide :
  1. Ouvrez un nouveau lecteur de texte sur le fichier.
  2. Lisez-le caractère par caractère.
  3. Imprimez le caractère qui n'est pas valide.
  4. Lorsque vous appuyez sur les caractères arrière, vous recevez l'exception et saurez ensuite quel caractère est à l'origine de l'erreur.
  5. Supprimez tous les caractères non valides, puis exécutez à nouveau le script

"WASX7023E: Erreur lors de la création de la connexion "SOAP" à l'hôte" ou erreur similaire lors de la tentative de lancement de l'utilitaire de ligne de commande wsadmin

Par défaut, l'utilitaire wsadmin tente d'établir une connexion avec un serveur d'applications lorsque celui-ci démarre. Cela est dû au fait que certaines commandes sont exécutées au lancement des serveurs d'applications. Cette erreur indique qu'aucune connexion n'a été établie.

Pour résoudre ce problème :
  • [AIX Solaris HP-UX Linux Windows][IBM i]Si vous n'êtes pas certain qu'un serveur d'applications est exécuté, démarrez-le en entrant startserver nomserveur à l'invite de commande. Si le serveur est déjà lancé, une erreur similaire à "ADMU3027E: Une instance du serveur est déjà en cours d'exécution" s'affiche.
  • [z/OS]Si vous n'êtes pas certain qu'un serveur d'applications est exécuté, démarrez-le en entrant startserver.sh nom abrégé du serveur à l'invite de commande. Si le serveur est déjà lancé, une erreur similaire à "ADMU3027E: Une instance du serveur est déjà en cours d'exécution" s'affiche.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Si vous exécutez une configuration de WebSphere Application Server, Network Deployment, commencez par lancer le gestionnaire de déploiement en exécutant la commande "startManager" ou "startManager.sh" à partir du répertoire rép_installation/bin. Vous pouvez ensuite lancer immédiatement wsadmin pour vous connecter au gestionnaire de déploiement ou bien démarrer un noeud et un serveur d'applications pour vous y connecter.
  • [z/OS]Si vous exécutez une configuration de z/OS, commencez par lancer le gestionnaire de déploiement en exécutant la commande suivante à partir d'une invite de commande sur la console MVS :
    START dmgr_proc_name,JOBNAME=server_short_name,
          ENV=cell_short_name.node_short_name.server_short_name
    Remarque : Cette commande doit être entrée sur une seule ligne. Elle se présente ici sur plusieurs lignes pour une meilleure lisibilité.

    Vous pouvez ensuite lancer immédiatement wsadmin pour vous connecter au gestionnaire de déploiement ou bien démarrer un noeud et un serveur d'applications pour vous y connecter.

  • Si un serveur d'applications est en cours d'exécution et que vous recevez l'erreur suivante :
    • Si l'exécution se fait à distance (c'est-à-dire sur un poste différent de celui sur lequel fonctionne WebSphere Application Server), vous devez utiliser l'option -host nom_hôte avec la commande wsadmin pour diriger wsadmin vers le serveur physique approprié.
    • Si vous utilisez l'option -host, essayez d'envoyer une commande ping au poste serveur à partir de la ligne de commande sur le poste sur lequel vous tentez de lancer wsadmin pour vérifier qu'il n'existe aucun incident de connectivité tel que des pare-feux.
    • Vérifiez que vous utilisez le bon numéro de port pour vous connecter au processus WebSphere Application Server :
      • Si vous n'indiquez aucun numéro de port (avec l'option -port) lors du démarrage de l'outil wsadmin, ce dernier utilise le port par défaut spécifié dans le fichier rép_install/profiles/nom_profil/properties/wsadmin.properties, nom propriété=com.ibm.ws.scripting.port (valeur par défaut = 8879).
      • Le port sur lequel wsadmin doit effectuer des envois dépend du processus serveur auquel wsadmin tente de se connecter.

        Pour une installation à serveur unique, wsadmin tente de se connecter au processus de serveur d'applications par défaut. Pour vérifier le numéro de port :
        • Dans le fichier racine_profil/config/cells/"nom_cellule"/nodes/nom_noeud/serverindex.xml, recherchez une balise contenant la propriété serverType="APPLICATION_SERVER".
        • Dans cette balise, recherchez une entrée contenant la propriété endPointName="SOAP_CONNECTOR_ADDRESS".
        • Recherchez une propriété "port" dans cette balise. Il s'agit du port sur lequel wsadmin doit effectuer des envois.
        Dans une installation WebSphere Application Server, Network Deployment, wsadmin a lancé, à partir du répertoire bin de l'installation WebSphere Application Server, Network Deployment, des tentatives d'envoi de demandes au gestionnaire de déploiement par défaut. Pour vérifier le numéro de port :
        • Recherchez le nom d'hôte du noeud sur lequel le gestionnaire de déploiement est installé.
        • A l'aide du nom d'hôte, recherchez dans le fichier racine_profil/config/cells/nom_cellule/nodes/nom_noeud/serverindex.xml une balise contenant la propriété serverType="DEPLOYMENT_MANAGER".
        • Dans cette balise, recherchez une entrée contenant une propriété endPointName="SOAP_CONNECTOR_ADDRESS".
        • Recherchez aussi une propriété "port". Il s'agit du port sur lequel l'outil wsadmin doit effectuer des envois.
    • [z/OS]Si la sécurité est activée, vérifiez que l'ID utilisateur TSO ou telnet appelant le client de scriptage comporte un fichier de clés dont le nom est indiqué dans le fichier ssl.client.props. Le fichier de clés doit être correct pour pouvoir établir la connexion SSL. Le nom par défaut du fichier de clés est WASKeyring. Ce fichier de clés contient le certificat d'autorité de certification pour le serveur d'administration.

"com.ibm.bsf.BSFException : Erreur lors de l'évaluation de l'expression JACL : aucune méthode nom commande de la classe com.ibm.ws.scripting.AdminConfigClient" n'a été renvoyée par la commande wsadmin.

Cette erreur est provoquée habituellement par un nom de commande mal orthographiée. Utilisez la commande $AdminConfig help pour obtenir des informations sur les commandes disponibles. Les majuscules et les minuscules sont différenciées dans les noms de commande.

[AIX Solaris HP-UX Linux Windows][IBM i]

WASX7022E renvoyée après l'exécution de la commande wsadmin -c ..., qui indique une commande non valide

Si la commande suivant -c semble valide, l'incident peut être dû au fait que lorsque wsadmin -c est utilisé sous Unix pour appeler une commande qui comporte des signes dollar, le shell tente d'effectuer une substitution variable. Pour confirmer que le problème est bien là, vérifiez que la commande contient bien un signe dollar de commande, par exemple : wsadmin -c "$AdminApp install ...."

Pour éliminer cet incident, placez une barre oblique inverse devant le signe dollar. Par exemple : wsadmin -c "\$AdminApp install ...".

[z/OS]

WASX7022E renvoyée après l'exécution de la commande "wsadmin -c ...", qui indique une commande non valide

Si la commande suivant -c semble valide, l'incident peut être dû au fait que le shell tente d'effectuer une substitution de variable. Une substitution de variable peut se produire sur des services de système Unix lorsque wsadmin -c est utilisé pour appeler une commande entre guillemets qui comporte des signes dollar. Pour confirmer que le problème est bien là, vérifiez que la commande contient bien un signe dollar de commande, par exemple : wsadmin -c "$AdminApp install ...."

Pour éliminer cet incident, placez une barre oblique inverse devant le signe dollar. Par exemple : wsadmin -c "\$AdminApp install ...".
Remarque : Lorsque la commande est placée entre apostrophes, le shell n'essaye pas de substituer les variables. Il n'est donc pas nécessaire de placer une barre oblique inverse devant le signe dollar. Exemple : wsadmin.sh -c "$AdminApp install ..."

com.ibm.ws.scripting.ScriptingException: WASX7025E: La chaîne """" est incorrecte. Impossible de créer ObjectName.

Cette erreur est peut-être due au fait qu'une chaîne vide a été indiquée pour un nom d'objet. Elle peut se produire si vous utilisez une instruction de scriptage pour créer un nom d'objet et l'instruction suivante pour utiliser ce nom, peut-être dans une commande "invoke" ou "getAttribute" mais que vous ne vous assurez pas que la première instruction a effectivement renvoyé un nom d'objet. Par exemple (les exemples suivants utilisent les commandes Jacl de base en plus des extensions Jacl wsadmin pour effectuer un exemple de script) :

#let's misspell "Server" 
set serverName [$AdminControl queryNames type=Srever,*] 
$AdminControl getAttributes $serverName 

Pour corriger cette erreur, assurez-vous, avant d'utiliser les chaînes de nom d'objet, que celles-ci contiennent des valeurs. Par exemple :

set serverName[$AdminControl queryNames node=mynode,type=Server,name=server1,*]
if {$serverName == """"} {puts "queryNames returned empty - check query argument"} 
else {$AdminControl getAttributes $serverName} 

Pour plus de détails sur la syntaxe Jacl au-delà des commandes wsadmin, reportez-vous au site des développeurs Tcl http://www.tcl.tk.

[AIX Solaris HP-UX Linux Windows][IBM i]

L'erreur "La ligne d'entrée est trop longue" a été renvoyée par la commande wsadmin sur une plateforme Windows.

Cette erreur indique que la longueur de ligne de commande Windows de 2048 caractères a été dépassée. Cette situation peut être due à un long chemin de profil utilisé dans la commande wsadmin.bat. Vous pouvez obtenir cette erreur lors de l'exécution de wsadmin dans une invite de commande Windows ou lors de l'appel de la commande wsadmin à partir d'un fichier .bat file, d'un fichier de génération ant ou de l'outil de gestion de profils. Si cette erreur est due à l'exécution de la commande wsadmin autrement qu'à partir de l'outil de gestion de profils, vous pouvez éviter le problème en utilisant la commande subst Windows qui permet de mapper un chemin entier vers une unité virtuelle. Pour consulter la syntaxe de la commande subst, entrez help subst à partir d'une invite de commande Windows.

Par exemple, si le produit se trouve dans le répertoire racine_serveur_applis, modifiez le fichier racine_serveur_applis\bin\setupCmdLine.bat comme suit :
SET CUR_DIR=%cd%
cd /d "%~dp0.."
SET WAS_HOME=%cd%
cd /d "%CUR_DIR%"

@REM add the following two lines to workaround Windows 2K command line length limit
subst w: %WAS_HOME%
set WAS_HOME=w:
...
...
Puis modifiez le fichier setupCmdLine.bat qui se trouve dans le répertoire bin du profil comme suit :
SET WAS_USER_PROFILE=...
SET USER_INSTALL_ROOT=...
SET WAS_HOME=app_server_root
SET JAVA_HOME=app_server_root\java

@REM add the following three lines to workaround Windows 2K command line length limit
subst w: %WAS_HOME%
set WAS_HOME=w:
set JAVA_HOME=%WAS_HOME%\java
...
...

Si cette erreur s'est produite lors de l'exécution de l'outil de gestion de profils, vous devez exécuter ce dernier à nouveau pour avoir un chemin de profil plus court avec un nom de profil plus court. If this does not fix the problem, follow the same instructions to edit the setupCmdLine.bat file in the bin directory of your WebSphere Application Server installation. Une fois le fichier modifié, exécutez à nouveau l'outil de gestion de profils. Si le problème persiste, réinstallez WebSphere Application Server avec un chemin de répertoire principal plus court.

Le support technique IBM possède des documents permettant de gagner du temps lors de la collecte des informations requises pour résoudre cet incident. Avant d'ouvrir un PMR, consultez la page IBM Support.

WASX701E: Exception reçue lors de l'exécution du fichier "scriptName.jacl" ; informations sur l'exception : com.ibm.bsf.BSFException: erreur lors de l'évaluation de l'expression Jacl : crochet de fin manquant

Cette erreur est due à une association de la page de codes attendue par le client de scriptage et le page de codes dans laquelle le script Jacl a été écrite.

Pour résoudre ce problème, indiquez la page de codes du script Jacl pour l'option -Dscript.encoding=page de codes du script dans le fichier wsadmin.sh ou wsadmin.bat. Les instructions suivantes permettent de déterminer plus facilement la page de codes du script :
  • Si le script a été rédigé dans l'interface OMVS à l'aide de l'éditeur OEDIT, la page de codes est IBM-037. Dans ce cas, définissez l'option de la manière suivante : -Dscript.encoding=Cp037
  • Si le script a été rédigé dans une session telnet de l'interface OMVS à l'aide de l'éditeur VI, la page de codes est IBM-1047. Dans ce cas, définissez l'option de la manière suivante : -Dscript.encoding=Cp1047
  • Si le script a été rédigé sur un ordinateur personnel ou sur une autre machine ASCII puis transféré vers l'hôte en tant que fichier texte, la page de codes est IBM-1047. Dans ce cas, définissez l'option de la manière suivante : -Dscript.encoding=Cp1047
  • Si le script a été rédigé sur un ordinateur personnel ou sur une autre machine ASCII puis transféré vers l'hôte au format binaire, la page de codes est ISO-8859-1 (ASCII). Dans ce cas, il n'est pas nécessaire de définir l'option car la valeur par défaut est ASCII. Consultez les autres causes possibles de cette erreur.
[AIX Solaris HP-UX Linux Windows][IBM i]

WASX7015E: Exception lors de l'exécution de la commande : "source c: ..." ; informations sur l'exception : com.ibm.bsf.BSFException: erreur lors de l'évaluation de l'expression Jacl : impossible de lire le fichier "c: ..."

Cette erreur est provoquée par l'utilisation d'une barre oblique inversée ( \ ) à la place d'une barre oblique ( / ) lors de l'exécution de la commande wsadmin afin d'intégrer un script Jacl à un environnement Windows®. Le chemin du fichier ne peut pas contenir une barre oblique inversée ( \ ) ; par exemple, wsadmin > source c:\temp\test.jacl. Le chemin du fichier doit utiliser la barre oblique ( / ) comme séparateur du chemin ; par exemple, wsadmin > source c:/temp/test.jacl.

Pour corriger cet incident, utilisez la barre oblique ( / ) dans le chemin du fichier lors de l'utilisation de la commande wsadmin afin d'intégrer un script Jacl à un environnement Windows :

app_server_root\bin>wsadmin
WASX7209I: Connected to process "dmgr" on node sunCellManager01
using SOAP connector;  The type of process is:
DeploymentManager WASX7029I: For help, enter: "$Help help"
wsadmin>source c:/temp/test.jacl

Erreur CWSIV0806E inattendue dans le journal WebSphere suite à la suppression d'un service sortant

Cette erreur se produit quand une exception est émise pour une destination MPOutBoundServicePortDestination, sur le moteur de messagerie trueliesNode01.server1-FVTSIBus01, le bus FVTSIBus01, pour l'activation du point de contact :

com.ibm.websphere.sib.exception.SINotPossibleInCurrentConfigurationException: CWSIP0111E : La destination ayant le nom MPOutBoundServicePortDestination est supprimée sur le moteur de messagerie {1}.

Vous pouvez ignorer cette erreur, car elle est bénigne.

Exception du séparateur

Vous devez utiliser des barres obliques (/) comme séparateur dans le chemin d'accès. Les barres obliques inversées (\) ne fonctionnent pas.

Activation de l'authentification dans le service de transfert de fichiers

Le service de transfert de fichiers fournit une authentification basée sur les rôles. Deux versions de l'application Web de transfert de fichier sont fournies. Par défaut, la version qui n'identifie pas l'appelant est installée. Cette installation par défaut garantit la compatibilité entre la version 5.0 ou 5.0.1 et les versions ultérieures de WebSphere Application Server, Network Deployment. L'activation de l'authentification du transfert de fichier est recommandée pour empêcher l'utilisation abusive de l'application de transfert de fichier. Cependant, si votre environnement WebSphere Application Server, Network Deployment comporte des clients de la version 5.0 alors que la sécurité globale est activée, ceux-ci ne pourront pas communiquer avec l'application de transfert de fichier sécurisé.

Dans WebSphere Application Server version 6.x, les cellules mixtes sont prises en charge et le transfert de fichier est devenu une application système. Si tous les noeuds de la cellule ont été créés dans une version supérieure ou égale à la version 5.0.1, vous pouvez activer l'authentification dans le service de transfert de fichiers en redéployant l'application de transfert de fichier dans le gestionnaire de déploiement. La version compatible est est fournie dans le répertoire ${racine_serveur_applis}/systemApps/filetransfer.ear. La version sécurisée est fournie dans le répertoire ${racine_serveur_applis}/systemApps/filetransferSecured.ear.

Un script Jacl wsadmin est offert pour vous aider à redéployer le transfert de fichier. Il s'agit du script redeployFileTransfer.jacl que se trouve dans le répertoire ${racine_serveur_applis}/bin. Dès que le gestionnaire de déploiement et que tous les noeuds disposent de la version 5.0.1 ou d'une version supérieure, vous pouvez déployer le service de transfert de fichier sécurisé en exécutant le script. La syntaxe d'exécution du script à partir du répertoire bin est la suivante :

wsadmin -profile redeployFileTransfer.jacl -c "fileTransferAuthenticationXxx 
cell_name node_name server_name

"Xxx" est "On" ou "Off".

Par exemple, lors de l'exécution du script pour activer le fichier filetransferSecured.ear, la syntaxe est similaire à l'exemple suivant :
wsadmin -profile redeployFileTransfer.jacl -c 
"fileTransferAuthenticationOn managedCell managedCellManager dmgr"
ou
wsadmin -profile redeployFileTransfer.jacl -c 
"fileTransferAuthenticationOn baseCell base server1"
Si vous souhaitez revenir afin d'exécuter le service de transfert de fichiers sans authentification, vous pouvez exécuter le script comme indiqué dans l'exemple suivant :
wsadmin -profile redeployFileTransfer.jacl -c 
"fileTransferAuthenticationOff managedCell managedCellManager dmgr"
ou
wsadmin -profile redeployFileTransfer.jacl -c 
"fileTransferAuthenticationOff baseNodeCell baseNode server1"

Le format de la sortie "$AdminConfig list" a changé dans la version 6.0

Si vous possédez un script qui analyse la sortie de $AdminConfig list, telle que $AdminConfig list Node, vous risquez de recevoir des erreurs, telles que "Noeud introuvable". Les scripts ne doivent pas analyser la sortie de $AdminConfig. Cependant, si vous possédez un script qui effectue cette analyse, il doit être mis à jour pour WebSphere Application Server V6.0 afin d'intégrer les changements du format de sortie.

Vous n'êtes pas invité à entrer l'ID utilisateur et le mot de passe après avoir appliqué un service V6.0.2 si vous utilisez un profil 6.0 existant

Si la sécurité est activée, l'exécution d'un fichier .bat nécessitera un ID utilisateur et un mot de passe. La version 6.0.2 contient une nouvelle fonction qui vous invite à saisir un ID utilisateur et un mot de passe, s'ils ne sont pas fournis dans la ligne de commande. Cependant, cette fonction n'est pas disponible pour les profils qui ont été créés au niveau 6.0.

Les fichiers de propriété des profils créés au niveau de la version 6.0 ne sont pas mis à jour après avoir appliqué le groupe de mise à jour de la version 6.0.2.

Il existe deux solutions pour cet incident :
  1. Créer un nouveau profil après avoir appliqué le service de la version 6.0.2. Ce nouveau profil contient tous les fichiers de propriété mis à jour. Vous serez ensuite invité à saisir un ID utilisateur et un mot de passe.
  2. Si vous souhaitez garder le profil V6.0 existant et utilisez la nouvelle fonction d'invite, vous devez mettre à jour ces fichiers manuellement :
    • pour racine_serveur_applis/properties/soap.client.props, ajoutez la ligne suivante :

      com.ibm.SOAP.loginSource=prompt

    • pour racine_serveur_applis/properties/wsjaas_client.conf, ajoutez les lignes suivantes :
      WSAdminClientLogin {
        com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy required del
      egate=com.ibm.ws.security.common.auth.module.WSAdminClientLoginModuleImpl;
      };
    • pour racine_serveur_applis/bin/setupCmdLine.bat, ajoutez la ligne suivante :

      SET JAASSOAP=-Djava.security.auth.login.config=racine_serveur_app/properties/wsjaas_client.conf

Lors de l'exécution de la commande $AdminApp searchJNDIReferences avec le nom JNDI (Java Naming and Directory Interface) d'une destination de message, la référence de la destination de message n'est pas renvoyée

Cet incident se produit lorsque la commande $AdmnApp searchJNDIReferences est exécutée avec le nom JNDI d'une destination de message. La commande ne peut pas collecter une référence de destination de message définie dans le descripteur de déploiement d'application. La destination de message que vous avez configurée pour le serveur d'applications est définie dans un lien de destination de message qui se trouve non pas sur un mais sur deux éléments : un bean géré par message et une référence de destination de message.

A l'heure actuelle, il n'existe toujours pas de solution à cet incident. La commande $AdmnApp searchJNDIReferences ne peut pas renvoyer une référence pour une destination de message définie sur deux éléments.

AWXJR0006E : Impossible de trouver le fichier, {0}.

Cet incident se produit lorsque vous tentez de configurer un fournisseur JACC pour Tivoli Access Manager à l'aide de l'outil wsadmin dans un environnement du gestionnaire de déploiement avec ou sans ajout de noeuds. Entrez un nom de noeud du gestionnaire de déploiement, par exemple, t54Manager, au lieu d'un astérisque (*) pour tous les noeuds. La commande wsadmin s'exécute avec succès mais lorsque vous essayez d'ajouter un nouveau noeud et de le démarrer ou de démarrer un noeud existant, vous recevez une erreur dans le fichier SystemOut.log de l'agent de noeud semblable à la suivante :
[12/7/05 17:09:51:266 CST] 0000000a SystemOut     O AWXJR0006E   Le fichier de propriétés, 
C:\cc_was602\WebSphere\AppServer\profiles\AppSrv01\etc\tam\amwas.t54Node01_.amjacc.pr
, n'a pas été trouvé.
[12/7/05 17:09:51:266 CST] 0000000a distSecurityC E   SECJ0391E: Erreur lors de la définition 
de l'objet de règle dans l'implémentation de la règle des fournisseurs {0}. L'exception est 
{1}.
[12/7/05 17:09:51:281 CST] 0000000a distSecurityC E   SECJ0324E: Erreur lors de 
l'initialisation de la sécurité Java 2 et de la stratégie dynamique. 
Pour résoudre cet incident, annulez la configuration Tivoli Access Manager existante et configurez-le à nouveau à l'aide d'un astérisque (*) pour le nom du noeud, par exemple :
wsadmin.bat -user wsadmin -password pw1 -f enableTAM.jacl "*" TAMHostName:7135 
""TAMHostName:7136:1""   "cn=wsadmin,o=ibm,c=us" "o=ibm","c=us sec_master"
sec_master pw1 "9990:9999"
[AIX HP-UX Solaris]

WASX7022E : Un incident est survenu lors de l'exécution de la commande "import sys" -- informations sur l'exception : com.ibm.bsf.BSFException : impossible de charger le langage

Ce problème peut être causé par une limitation appliquée à quelques plateformes UNIX, par exemple, Linux, lors de la tentative d'utilisation du langage Jython.

Pour résoudre cet incident, effectuez les tâches suivantes :
  1. Vérifiez le nombre de fichiers que vous êtes autorisé à stocker dans votre machine, par exemple : ulimit -a
  2. Vérifiez le nombre de fichiers que vous avez définis sur votre machine. La valeur par défaut est 1024.
  3. Utilisez, par exemple, un nombre plus élevé : ulimit -n 2048
  4. Essayez d'utiliser l'outil wsadmin à nouveau avec le langage Jython.
[z/OS]

WASX7017E: Exception received while running file "<application stopping script>"

WASX7017E : Exception reçue lors de l'exécution du fichier "<application stopping script>" ; informations sur l'exception : javax.management.MBeanException com.ibm.ws.exception.RuntimeWarning : L'application <appname> n'est pas ouverte.

Lors de l'utilisation des scripts, cette erreur est envoyée lorsque vous arrêtez une application qui est déjà fermée ou que vous démarrez une application déjà lancée.


Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_wsadminprobs
Nom du fichier : rtrb_wsadminprobs.html