This section explains problems found in the Administration and Monitoring Console, and provides workarounds, where available.
The embedded Web server (LWI) web container used by AMC relies on UTF-8 for encoding its messages. This encoding is capable to represent every character in the Unicode standard but causes problems when messages are logged in the Windows command prompt. The reason is that the prompt uses the default code page (encoding) of the machine, specified by the language for non-Unicode applications configured in 'Control Panel > Regional and Language Options' (Advanced tab). Thus, for example, when a Japanese message is logged it is encoded by LWI using UTF-8 and transferred to the console which displays it using the default Japanese encoding (code page 930). This causes the message to appear incorrectly. For TDI messages we have overridden the LWI behavior to use the default encoding of the machine, so there should be no problem to display, for instance, Japanese messages on a Japanese machine. Please note that, if the option for non-Unicode programs in the Control Panel differs from the language used by TDI, it must be modified accordingly.
When AMC is started, several LWI and ISC messages can be seen in the console. They are not under the control of TDI, so if users need to see them properly, they must comment the following line in file TDI_install_dir/lwi/conf/logging.properties:
java.util.logging.ConsoleHandler.encoding=UTF-8
This way, the default encoding of the machine will be used instead of UTF-8, so all message should appear normally.
Another option is to change the code page used by the console to UTF-8 by entering command 'chcp 65001' in the console. Please note, though, that this may cause problems when executing the AMC bat scripts.
If Action Manager is running on a machine other than the machine where Administration and Monitoring Console is running (for example, Action Manager on zOS), then we should either the use IP Address or the Domain Name Server name
while registering TDI servers. Administration and Monitoring Console is shipped with a default local TDI Server registered using 'localhost'. You should re-register this server using either the IP Address or the DNS name.
We can configure Action Manager rules for a Solution View, so that one rule references some other rule. If one rule references another rule in the Solution View, then we cannot delete either the Solution View or the server that is running the Solution View. To avoid this problem, we can reference one rule to another rule if you associate either of the following with the rule:
To delete a TDI server where one rule references another in the Solution View:
To delete the TDI Solution Views where one rule references another in the Solution View:
The following string is truncated in the Start AssemblyLine window: The attributes exposed for the selected operation.
This problem occurs only in Internet Explorer, and only in Korean.
When using Simplified Chinese locale in AMC and working with Internet Explorer some text fields might overlap the near images. This is not observed with Mozilla Firefox.
If the TDI server error log contains the following exception it could mean that a port required by WebSphere Application Server (WAS) is already in use:
ORBX0390E: Cannot create listener thread. Exception=[ > java.net.BindException: Address already in use: NET_Bind ].
This error might also occur if we have Google Web Accelerator installed on the system from which you are attempting to start the Administration and Monitoring Console. You may need to uninstall Google Web Accelerator to resolve this problem.
AMC can communicate with the TDI server over SSL. This is the default mode of communication between AMC and a TDI Server. For SSL communication the certificates have to be added in the trust store of WAS to enable it to trust the certificates. If this is not done, Websphere throws the following exception:
[5/8/08 14:39:39:984 IST] 00000021 SystemOut O CWPKI0022E: SSL HANDSHAKE FAILURE: A signer with SubjectDN "CN=host IP, O=IBM, C=US" was sent from target host:port "*:9043". The signer may need to be added to local trust store "${WAS_HOME}\systemApps\isclite.ear\tdiamc.war\testadmin.jks" located in SSL configuration alias "DefaultSystemProperties" loaded from SSL configuration file "System Properties". The extended error message from the SSL handshake exception is: "No trusted certificate found".
In order to resolve the above mentioned error we have to follow the steps mentioned below:
On some UNIX platforms (for example, SLES 10) AMC in ISE SE fails consistently to authenticate users, even when correct credentials are specified. Such behavior is observed when AMC is run as a non-root user and the operating system uses a password database (for example, a /etc/shadow file).
To work around this problem, run AMC as a user that has read permissions to the password database. For example, on systems that use shadow passwords we should try adding the user to the shadow group.
Here is an explanation:
By default on UNIX platforms LWI uses a JAAS module that authenticates users through the PAM stack on the machine (see TDI_install_dir/lwi/security/jaas/jaas.config). PAM is not normally a part of the operating system kernel, so it runs with the permissions of the calling process. To authenticate a user on a system that uses a password database, PAM has to verify the specified password against the password database. This task requires read access to the password database. To work around this restriction, some PAM modules use a special utility which is able to run with root permissions regardless of the caller (an executable whose setuid bit is set and whose owner is root). For example the "pam_unix.so" module available in RHEL 5 uses the "unix_chkpwd" tool to access the password database. Yet there exist PAM modules that do not employ such a mechanism and therefore require the calling process to have read access to the password database.
On systems that use so called "shadow passwords", passwords are stored in hashed form in the /etc/shadow file. To verify a password one needs read access to that file. Usually /etc/shadow is associated with a group named "shadow", whose members are given read access to the file.