eFix (APAR): PQ62333 Status: efix Release: WebSphere 4.0.3 Supersedes eFixes: PQ60191 PQ61172 PQ59279, PQ59624, PQ60796, PQ60843 CMVC defect: PQ62333 Byte size of APAR: 1,151,477 bytes Date: 07/25/2002 Title: WSCP SHOW command reports incorrect currentState on EnterpriseApp and Modules installed on ServerGroup Abstract: Using WSCP with "EnterpriseApp show" command returns incorrect current state of the EnterpriseApp and same incorrect result for Module. This problem does not occur on stand alone server and only occurs when EnterpriseApp/Modules are installed on a ServerGroup . Description/symptom of problem: Error Description: Here is the test senerio: Install EnterpriseApp on a ServerGroup with multiple servers/clones. wscp> EnterpriseApp show /EnterpriseApp:intlbl/ {Name intlbl} {FullName /EnterpriseApp:intlbl/} {CurrentState Stopped} DesiredState Running} {StartTime 1021486630789} {OrigEarFile /apps/apl/intlbl/servlets/intlbl.ear} {OrigNodeName rcdaix10} The output shows stopped but the console shows Running by right click on EnterpriseApp and "showStatus". The discrepency applies to Modules as well. EnterpriseApp is in running state if at least one of the Modules it contains is running. A Module is in running state iff all of the servers it is installed on are running. If server accessed by remote client, eFix should be applied to both machines. Directions to apply efix: 1) Create temporary "efix" directory to store the jar file: AIX: /tmp/WebSphere/efix Solaris/Linux: /tmp/WebSphere/efix Windows: c:\temp\WebSphere\efix 2) Copy jar file to the directory 3) Shutdown WebSphere 4) Run the jar file with the following command answering questions/prompts as they appear: java -jar 5) Restart WebSphere 6) The temp directory may be removed but the jar file should be saved. Do not remove any files created and stored in the /WebSphere/AppServer/efix/ directories. These files are required if an efix is to be removed. Directions to remove an efix: NOTE: EFIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED. DO NOT REMOVE AN EFIX UNLESS ALL EFIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED. YOU MAY REAPPLY ANY REMOVED EFIX. Example: If your system has efix1, efix2, and efix3 applied in that order and efix2 is to be removed, efix3 must be removed first, efix2 removed, and efix3 re-applied. 1) Change directory to the efix location (/WebSphere/AppServer/efix/). 2) Shutdown WebSphere 3) Run the backup jar file with the following command: java -jar 4) Restart WebSphere Directions to re-apply an efix: Follow the instructions for applying an efix. If the backup files still exist (from the previous efix application), you will be prompted to overwrite. Answer "yes" at the overwrite prompts. Additional Information: ------------------------------------------------------------------ This is a cumulative efix. In addition to the description above, applying this efix solves the following problems: (From PQ60796) Abstract: The subdirectory under installedApps is not removed when uninstalling an enterprise bean on AdminConsole, XML and WSCP. Description/symptom of problem: On WAS 4.0.2 using XML, WSCP, or Admin Console, deploy an Enterprise Application. . At some point the need to remove the Enterprise Application and WAS is not removing the subdirectory under /InstalledApps. It can also be removed by any of three methods (XML, WSCP, Admin Console) and you receive the same results. . This causes problems when they try to update the Application as there is old information left on their systems. (From PQ60191) Abstract: wscp always exits with a return code of 0. Description/symptom of problem: The wscp script always exits with a return code of 0 so there is no way to programatically check to see whether or not the command was successful. This test fix changes the behavior when wscp is run in command mode, e.g.: wscp -c "ApplicationServer list" or when wscp is run in script mode: wscp -f myscript.tcl so that a non-zero code is returned if an error is detected. >>>PLEASE NOTE: TO HAVE wscp RETURN A CODE BASED ON WHETHER OR NOT AN >>>ERROR WAS DETECTED, IT IS NECESSARY TO SET THE SYSTEM PROPERTY: >>> wscp.useNewRetCode >>>TO SOME NON-NULL VALUE. THIS MAY BE DONE IN THE SAME WAY THAT: >>> wscp.traceString >>>IS SET (PLEASE SEE 6.6.0.2.2.3.7 OF THE WEBSPHERE 4.0 InfoCenter). (From PQ61172) Abstract: Allow disable Hotspot JVM on HP-UX JDK from Admin Console with "-classic" command line and "Disable JIT" checkbox. Description/symptom of problem: This APAR completes the APAR PQ58961 problem to allow switching server's JVM mode from HotSpot to Classic on HP-UX Java. PQ58961 corrected the exceptions generated when disabling HotSpot so that the application server would start up correctly, but the fix did not enable the ability to switch from HotSpot mode to Classic mode. This APAR allows the "-classic" command line option and the "Disable JIT" checkbox to both switch the JVM mode from HotSpot to Classic. (From PQ59279) Abstract: Ensures when removing application from node, the JNDI name is also removed from naming space. Description/symptom of problem: Error Description: Removal of application from node does not remove JNDI name from naming space. -Create server group -Install Ear into server group -Clone application from server group onto 2 seperate nodes -Verify that namespace exists for clone on each node with dumpNa meSpace utility. -Remove application -Restart admin server on both nodes just to make sure there isn' t an old JNDI name left in cache. -run dumpNameSpace again just to verify that the application was remov ed from the node in the admin console, but still exists in the J NDI name space. . This worked for the customer at 4.01, but fails on 4.02. (From PQ59624) Abstract: MAKE HTTP PORT CONFIGURABLE NOT HARDCODED Error Description: The default PORT for a given WebSphere Application Server is hardcoded to 9080. For the creation of a new HTTP Transport; the last used port [ starting from 9080] will be incremented. . Customer installing multiple instances of WAS on 1 physical node per IBM Websphere' coexistance recommendation will have to manually configure and maintain a list of TCP/IP ports used by difference instances of WAS. . The current implementation assumes that only 1 instance of WAS will be on a physical machine therefore a hardcoded starting port for HTTP Transports is acceptable; However this does not allow for multiple instances to be maintained and increases the administration work for Websphere. The fix allows customer to configure the Node attribute "LastUsedPort" via WSCP. (From PQ60843) Abstract: Cannot use the nodename property, the ear file not expand properly. Description/symptom of problem: For configuring WAS on a machine with multiple NIC's, add the following line to the admin.config file: com.ibm.ejs.sm.adminServer.nodeName=mydevnode Everything looks fine, the node name is mydevnode However, when I install an Enterprise Application the files do not get installed into /usr/WebSphere/AppServer/installedApps.