eFix (APAR): PQ60796 Status: efix Release: WebSphere 4.0.3 Supersedes eFixes: PQ60191 PQ61172 PQ59279, PQ59624 CMVC defect: PQ60796 Byte size of APAR: 1,130k bytes Date: 07/19/2002 Title: Upon removal of enterprise bean WAS 4.0.2 is not removing the subdirectory under /installedApps directory. Error Description: Title: Upon removal of enterprise bean WAS 4.0.2 is not removing the subdirectory under /installedApps directory. 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. 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 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.