eFix (APAR): PQ62229 Status: efix Release: WebSphere 4.0.3 Supersedes eFixes: PQ60191 PQ61172 PQ59279, PQ59624, PQ60796, PQ60843, PQ62333, PQ62793, PQ59006, PQ60064, PQ65232, PQ65491 CMVC defect: PQ62229 Byte size of APAR: 1,254,196 bytes Date: 08/23/2002 Title: wscp produces inconsistency in WAS repository Error Description: WSCP appears to allow modifications to a running webapp. However the procedure corrupts the repository making it neccessary for the customer to drop and rebuild the admin repository. 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. (From PQ62333) 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 . 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. (From PQ62793) When performs a node "stop for restart" on a node, and that particular node has an application server that failed to start on startup but started succesfully afterwards, the application server process id for that application server remains after the node has been restarted. Customer has to perform a kill - 9 on the process id in order for the process to go away. On Windows 2K, a reboot is in order for the process to go away. (From PQ59006) Title: This fix makes the Admin Server retry starting the application Server a specified number of times. Description/symptom of problem: If an Application Server is detected to go down, the Admin Server tries to start it again. if this attempt fails (for example, if the repository database is down), no more attempts are made to restart the Application Server. This fix makes the Admin Server retry to start the Application Server a specified number of times. The default is to retry 5 times in 60 second intervals. This can be modified by adding lines into admin.config as follows: com.ibm.ejs.sm.adminServer.nannyThread.maxRetries= com.ibm.ejs.sm.adminServer.nannyThread.waitTime= The app server start will retry forever if a negative number is set as . (From PQ60064) Title: DataSource passwords are seen in plain text when connecting with 4.0.1 client Description/symptom of problem: This efix encodes the DataSource passwords in the repository so that clients will not be able to read the passwords. Since this change modifies persistent data, the rebind_datasources,tcl script from PQ57046 should be run to actually encode the data, although simply installing the efix will show the password as encoded from the Admin Console and wscp. Note that this efix being provided for security concerns only; attaching a client from an eariler version to a server of a later version is not a supported configuration. (From PQ65232) Title: DUPLICATE PORT CHECK FAILURE IF APPLICATION SERVER CREATED AFTER GENERIC SERVER. Description/symptom of problem: When creating an application server after creating a generic server the Errors occurred during duplicate port check is produced. If you are using the console the application server is created but the Transport is 9080. BUT if you do this with XML imports the application server is not create at all. Creating application server with generic server already existing on node can produce same error. (From PQ65491) Title: Add NodeStartState configurability for Generic Servers. Description/symptom of problem: Currently NodeStartState configurability is only available on application servers, this eFix adds the configurability for Generic Servers. After applying eFix customer can specify the state of Generic Servers as [Current|Running|Stopped] when the Node restarts. NOTE: 1. Generic Servers NodeStartState is configured through a new system property in admin.config file. com.ibm.ejs.sm.adminServer.GenericServerNodeStartState = [Current|Running|Stopped] Customer needs to add the following text to the admin.config file in addition to applying the eFix jar: # NodeStartState of generic servers: [Current|Running|Stopped] com.ibm.ejs.sm.adminServer.GenericServerNodeStartState = (NodeStartState) NodeStartState options: Current - Each Generic Server will be in its last state prior to Node restart Running - Each Generic Server will be in Running state regardless of last state Stopped - Each Generic Server will be in Stopped state regardless of last state 2. This property applies to Generic Servers as a whole. Property specified affects every Generic Server created on the Node. This property does not affect Generic Servers created on other Nodes.