This page contains problems encountered and their associated fixes.
WEA
431 Workarounds
WEA
430 Workarounds
WEA
421 Workarounds
AIX Machine
Network Configuration
Cannot
Telnet To An AIX Machine
Cannot Mount NAS
Security
Not Enabled During WEA Install
ToolTalk
Message Server Could Not Be Started
DB2e
Startup Workaround
DMS
Incremental Installation
Symbol
Resolution (aio) Error
FOR AIX ONLY
1. Login as the db2 user.
2. Export EXTSHM to ON in the db2 user's login
profile. Commands to be added to the .profile file are
EXTSHM=ON
export EXTSHM
3. Set the DB2 environment of the db2 user to
include the environment variable EXTSHM. Command to be executed is
db2set DB2ENVLIST=EXTSHM
4. Stop DB2 instance. Command to be executed is
db2stop
5. Source the login profile of the user. Execute . ./.profile from the home directory.
6. Start the DB2 instance. Command to be executed
is
db2start
FOR BOTH AIX AND SOLARIS
1. Login as root user.
2. Stop WAS admin server.
3. Modify WAS startup script to include the DB2 driver in the classpath. Edit startupServer.sh and add $DB2_HOME/java12/db2java.zip at the end of the DB_CLASSPATH for Oracle. Here DB2_HOME is the UDB installation directory (/usr/lpp/db2_07_01 on AIX and /opt/IBMdb2/V7.1 on Solaris).
4. Source the login profile of the db2 user. Change directory to the db2 user's home directory and execute . ./.profile.
5. Start WAS admin server.
When installing DMS incrementally, you must assure the "DISPLAY" environment
variable is set propertly
When starting Oracle® (e. g. the server manager or listener) and
it fails with messages like "Symbol resolution failure", the problem is
probably due to the fact that the asynchronous I/O feature of the operating
sytem is not activated. This can be corrected by performing one of the
following procedures as "root". You can temporarily or permanently set
the AIO .
Setting the Asynchronous I/O Permanently
1) From the AIX command prompt type "smitty aio".
2) Select "Change / Show Characteristics of Asynchronous I/O".
3) For the "State to be configured at system start time" field,
press the "Tab" key to change the value to "available", press the "Enter"
key, then reboot the machine when the "Command: OK" appears.
Setting the Asynchronous I/O Temporarily
1) From the AIX command prompt type "smitty aio".
2) Select "Configure Defined Asynchronous I/O". This will turn on asynchronous
I/O support only as long as the machine is not rebooted (This
feature will be turned off if the system is rebooted).
INS
Server Startup Workaround
Web Server Start
Problem
DMS
Device Enrollment
Installer
Already Running On AIX
In the event from a browser connected to your Portal server on the INS page group you get the message "Unable to contact the server. Try again later or contact your administrator.", there are some steps you might use to correct the problem.
1) Assure the "db2jd 6789" process is running or start if if not so (i.e. "su - wasinst" and "db2jstrt 6789").
2) From the WAS Admin Console, you must stop and restart the "INS Portlet_WPS_PA" WAS Enterprise Application.
3) From an AIX window, from the "/usr/WebSphere/INS/bin" directory, start the ADM process giving the machine name as the only parameter (i.e. "./startADM wea2aix1"), and leave this AIX window open as a logging console.
4) From another AIX window, from the "/usr/WebSphere/INS/bin" directory, start the HA process with no parameter (i.e. "./startHA"), and leave this AIX window open as a logging console.
5) From the supported browser of your choice, connect to your Portal Server, logon, click on the "Intelligent Notification" tab.
6) From the Intelligent Notification portlet click on the "Administration" tab.
7) In the Manage Servers porlet, click on "Run all Server" to start all of the INS servers. After several seconds the "Status" of each server should reflect "Running".
8) You should now be able to perform normal INS
functions.
Web Server Start Problem (defect 29936)
During Setup Manager installation, after the 14 steps, a manual operation was required to regenerate the web server plugin. The following instructions describe a test/workaround to cure this problem, which includes installing 3 additional WAS eFixes.
1) Rename CD 5 something else (i.e. "mv CD5 CD55"). This will cause the installation to stop and request you insert the CD. Do not do so.)
2) When SUM stops and requests the insertion of CD5, perform the following workaround.
3) Shutdown WAS if it is running.
5) Create and change to a temporary directory for installing the eFix'es (i.e. "mkdir /tmp/WebSphere/efix" and "cd /tmp/WebSphere/efix".)
6) Copy the eFix'es to your temporary directory (i.e "cp /nasimgs/cd3-1/was/eFixes/PQ67566_eFix_AEServer_AEsServer.jar .", "cp /nasimgs/cd3-1/was/eFixes/WAS_CM_09-26-2002_4.0.x_cumulative_eFix.jar .", and "cp WAS_Security_10-07-2002_4.0.4-4.0.3-4.0.2_AE_cumulative_eFix.jar .").
7) Install the first eFix using the Java installed with WAS (i.e. "/usr/WebSphere/AppServer/java/bin/java -jar PQ67566_eFix_AEServer_AEsServer.jar").
8) When prompted, enter the WAS directory "/usr/WebSphere/AppServer".
9) Rename the extract log file to avoid it being overwritten by subsequent eFix installations (i.e. "mv Extractor.Log PQ67566.Extractor.log").
10) Install the second eFix using the Java installed with WAS (i.e. "/usr/WebSphere/AppServer/java/bin/java -jar WAS_CM_09-26-2002_4.0.x_cumulative_eFix.jar).
11) When prompted, enter the WAS directory "/usr/WebSphere/AppServer".
12) Rename the extract log file to avoid it being overwritten by subsequent eFix installations (i.e. "mv Extractor.Log WAS_CM_09-26-2002_4.0.x_cumulative_eFix.Extractor.Log").
13) Install the second eFix using the Java installed with WAS (i.e. "/usr/WebSphere/AppServer/java/bin/java -jar WAS_Security_10-07-2002_4.0.4-4.0.3-4.0.2_AE_cumulative_eFix.jar").
14) When prompted, enter the WAS directory "/usr/WebSphere/AppServer".
15) Rename the extract log file (i.e."mv Extractor.Log WAS_Security_10-07-2002_4.0.4-4.0.3-4.0.2_AE_cumulative_eFix.jar.Extractor.Log").
16) Restart WAS.
17) Change the CD5 back to it's original name (i.e "mv CD55 CD5"),
and click the button in Setup Manager to continue the installation.
DMS Device Enrollment (Defect 38135)
This problem is where you cannot enroll a Pocket PC on DMS, due to not having a fully qualified domain name for the DMS server. This problem is due to the"/usr/IBMWPO/scripts/dmsinstall.script" not having the fully qualified path value in the "SysHostName" parameter.
ps -ef | grep WebSphere | awk '{print $2}' | xargs kill -9
1) To confirm, go to "<DMS_Host>/bin" (i.e "/usr/WebSphere/DMS/bin"), and execute the command "./deviceclass.sh -list", to list your current device configurations.
2) If the entry for Device Class "Wince" does not have the fully qualified path name (including "raleigh.ibm.com"), perform the next step.
3) From the same directory, use the same command to modify the
Wince Device Class. "./deviceclass.sh -modify <device_class_name> -enroll
http://<host>/dmserver/DeviceEnrollmentServlet", where "<device_class_name>"
should be in "Wince", and "<host>" should be your fully qualifed machine
name (i.e. "wea2aix1.raleigh.ibm.com"). (e.g. "./deviceclass.sh -modify
Wince -enroll http://wea2aix1.raleigh.ibm.com/dmserver/DeviceEnrollmentServlet")
Installer Already Running On AIX
If you attempt to run the installer on a machine, on which someone (or yourself) has already attempted an installation, you might be told "An instance of the installer is already running". This could be caused by at least 2 things. One, there is a java process, the Setup Manager (SUM), already running. In this case, find the process and figure out who started it on YOUR machine, or stop taking drugs that make your forget you started the installer once before on this machine. In this case you can "kill -9" the java process you started, or go find the window in which you started it and proceed from there.
The second is when there is not a java SUM process running, but a previous
installation had aborted for some reason. In this case, remove the directory
"/usr/IBMWPO" (i.e. "cd", then "rm -r /usr/IBMWPO"). Then restart
the SUM.
INS Workaround
Mount
Fails on AIX 5.1.x With WEA 421
INS installation requires a Java version that has been repaired. A script "wea430INSfix" exists in "/WEA/tools/shayden/wea430/INS" which installs this Java and copies repaired "startADM" and "startHA" files to the "/usr/WebSphere/INS/bin" directory. The script follows:
# INS workaround for WEA r430. This script is
for correcting Java problem
# This script copies a new version of Java, untars
it, and copies
# 2 updated files (startADM and startHA) to the
/usr/WebSephere/INS/bin
# directory. These files have been modifed to
point to the new Java
echo 'Correcting INS Java Problem'
echo 'Installing updated Java'
cd /
mkdir newJava
cd newJava
cp /WEA/tools/shayden/wea430/INS/ca131fix_sdk.tar
.
tar -xvf ca131fix_sdk.tar
echo 'Updating INS server scripts (startADM and
startHA)'
cd /usr/WebSphere/INS/bin
mv startADM startADM.orig
mv startHA startHA.orig
cp /WEA/tools/shayden/wea430/INS/startADM .
cp /WEA/tools/shayden/wea430/INS/startHA .
echo 'INS Workaround Complete'
echo 'New Java available, startADM and startHA
are modified'
Mount Fails on AIX 5.1.x With WEA 421
Symptom: On an AIX 51_1 WEA 4.21 install, mounts fail.
Solution: Perform an software installation upgrade to ML3.
When you updated to ML3 the mount problem was resolved.
However, the system could not be successfully installed because
of the package bos.net.ipsec.keymgt.
Symptom: AIX 513 WEA 4.21 fails to upgrade bos.net.ipsec.keymgt
Solution:
DB2 added user accounts with a UID of 201. Unfortunately,
the ipsec
update requires UID 201 for the new account that it creates
ipsec.
The user must do: smitty chuser, then change db2fenc1
from
an UID of 201 to an unused UID, maybe 210. After
making that change,
change all files currently owned by UID 201 to 210.
First make a user "ipsec" with a UID of 201. "mkuser id=201 ipsec"
Next, change all existing owned 201 files back to db2fenc1.
" find / -user ipsec -exec chown db2fenc1 {} \; "
Cannot Telnet To An AIX Machine
(included FTP info just for kicks, it might not work)
1) Assure /etc/services has a "telnet" entry (i.e "telnet 23/tcp") (or "ftp 21/tcp" for FTP).
2) Assure "inetd" is running (from command prompt "lssvc -a | grep inetd" or "ps -ef | grep inetd")
3) Assure "telnet" (and/or "ftp") entry is in file "/etc/inetd.conf". If it is not, ftp to another machine and get one.
4) Stop the "inetd" service (i.e. "stopsrc -s inetd").
5) Start the "inetd" service (i.e. "startsrc -s inetd").
6) Try telnetting again.
This problem happened on an AIX 4.3.3 virgin OS install.
1) From an AIX command prompt, type "smitty mktcpip".
2) In the "Available Network Interface" portion of the panel, select the "Standard Ethernet Network Interface", then press "Enter".
3) In the "Minimum Configuration & Startup" panel, enter the following values in the associated fields:
HOSTNAME
[(enter your fully qualified box name here)]
Internet Address
[(enter the IP address of this machine)]
Network MASK
[255.255.252.0]
NAMESERVER
Internet ADDRESS
[9.42.106.3]
DOMAIN Name
[raleigh.ibm.com]
Default Gateway
Address
[9.42.64.1]
START Now
yes (might need to hit "Tab" key to change this)
4) After you get the COMMAND "OK" response, exit smitty, and from the AIX command prompt assure (or make) a directory in the root path ("/") you wish to mount to NAS with (i.e. "mkdir /nas").
5) Also from the AIX command prompt mount the disk (i.e. "mount nas300:/staging /nas").
6) Git to work!
Security Not Enabled During WEA Install
You might be able to recover from the "disaster" that you find during the WEA install 13-steps the WAS Security is not enabled.
The steps are the following:
1. make sure that LDAP is up and running, w/ the needing entries (using DMT), if not, you can at least stop LDAP, WAS, find the WPSConfig.ldif and run
ldif2db -i WPSConfig.ldif
to get the LDAP ready
2. make sure that WAS is up and running,
3. start the WAS admin console
4. Console->Security Center
5. on the "General" tab, check the "Security"
6. go to the "Authentication" panel, select "LTPA xxxx", the domain
would be "raleigh.ibm.com" (your network?, this is at least the value we
use in the testlab)
7. in the LDAP section, enter the following values:
Server ID: uid=wpsbind, cn=users, dc=raleigh, dc=ibm, dc=com
Port: 389
password: wpsbind
BaseDN: dc=raleigh, dc=ibm, dc=com
Server: <your_LDAP_server>
Bind DN: cn=wpsadmin
LDAP type: custom
BindDN password: <password>
Here,
a. the BaseDN is assumed to be the default "de=raleigh,dc=ibm,dc=com",
substitute with the value you entered into WEA SUM (or find it from WPSConfig.ldif)
b. the BindDN is the value you use to bind into DMT or the LDAP admin
interface, and the password
8. click "Apply", click "Ok" to close the WAS Security Center,
Note that you may be asked to enter the LTPA password, which could
be found in one of the .rsp files (do a search of "Ltpa" in the *.rps files
9. restart WAS, and you should be back
AIX Machine Network Configuration
This problem exhibits itself by not being able to connect to anything (ping, telnet, ftp, etc.)
1) Determine which network interface is physically connected to the network. From the AIX command prompt type "netstat -v > /netstat.list", which will create a file "/netstat.list" which will contain the output of the command "netstat -v").
2) Edit the file "/netstat.list", and search for the text string "Link Status: Up". (note, there might be several ethernet interfaces on your machine, and for each, there will be a section of this file reflecting that interface's configuration. Normally, only one will be physically connected to the network. Once you find the "Link Status: Up" string, search backward from that point and find a string "ETHERNET STATISTICS", and the value beside this string will reflect your link that is physically connected (i.e. "ent1"). (If you have the wrong interface physically connected or you want to change that physical connection, see Removing Ethernet Interface)
3) Again, from the AIX command prompt type "smitty tcpip".
4) Move the cursor to the item "Minimum Configuration & Startup", then press "Enter".
5) In the "Available Network Interfaces" section of the panel, choose the (new) network interface you wish to use (i.e. "en1"), then press "Enter".
6) In the following fields, enter the associated values:
HOSTNAME
(enter the name of the machine you are on, i.e. "wea2aix8")
Internet ADDRESS (enter the IP
address of your machine)
Network MASK
(normally "255.255.252.0", but this is for Test Cell 6 machines. Other
networks might use a different mask)
NAMESERVER
Internet ADDRESS (normally 9.42.106.3
DOMAIN Name
raleigh.ibm.com
Default Gateways
Address
9.42.64.1
START Now
yes
The following examples assume you are removing interface "en0". For your situation, determine the interface you wish to remove and substitute it in the examples below.
1) From the AIX command prompt detach the interface you wish to remove (i.e. from the prompt type "ifconfig en0 down detach" (assuming the interface you wish to remove/disable is "en0")).
2) Again, from the AIX command prompt, type "rmdev -dl en0".
3) Again, from the AIX command prompt, type "rmdev -dl ent0"
4) Again, from the AIX command prompt, type "cfgmgr".
Your interface has been removed.
ToolTalk Message Server Could Not Be Started
When connecting to an AIX machine with DSView, and the display is a funky dark gray with a window "ToolTalk Message Server Could Not Be Started", and a "dtterm" window displayed on the GUI, you have probably lost your network connectivity.
Put in an SES request providing the machine name/IP address, and have the AIX OS installed from CD's and the networking configured. Dont bother using this machine until this is done. After the OS is reinstalled, a normal NIM can PROBABLY be performed.