eFix (APAR): PQ62229 Status: efix Release: WebSphere 4.0.2, 4.0.3, and 4.0.4 CMVC defect: PQ62229 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) >>>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). 6) Restart WebSphere 7) 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: ============================= APAR: PQ59624 Version: 400 Abstract: HTTP SERVER PORT HARDCODED: SHOULD BE CONFIGURABLE. 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. Local Fix: Maintain a list of Websphere Instances along with all the TCP/IP ports used by that Instance and manually configure a different port for each AppServer created. Logically Dependent Apars: Users Affected: WebSphere Application Server user running WAS4.0.2 or later needing to configure HTTP server port. Problem Description: The default PORT for a given App Server is hardcoded to 9080. For the creation of a new HTTP Transport; the last used port starting from 9080 will be incremented. Recommendation: Problem Summary: When installing multiple instances of WAS on one physical node per the 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 one 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. Problem Conclusion: With this fix, it is now possible to configure the "LastUsedPort" attribute on the Node via WSCP the same way any attribute can be accessed. EX: wscp> Node show /Node:myNode1/ {Name myNode1} {FullName /Node:myNode1/} {CurrentState Running}{DesiredState Running} {StartTime 1025038723374} {OsName {Windows 2000}} {HostName NT2} {HostSystemType x86} {ProcessId 1656}{InstallRoot {C:\WebSphere\AppServer}} {LastUsedPort 9082} wscp> Node modify /Node:myNode1/ -attribute {{LastUsedPort 9100}} (patch available for was4.0.2 and was4.0.3, code will integrate in PTF5) Comments: This is working as the design in 4.0. In 3.5x, the HTTP server port is hardcoded to be 9080 and the user does not allow to change or configure a new port value for an application server. The design is changed in WAS 4.0. The default port for an HTTP transport is 9080 and the value will be incremented by 1 for each new transport created. The lastusedport value is stored in the Node table and the user is able to configure a different or add a new port through the admin console, wscp or XMLConfig. The new configured port value is stored in the EJBServer table and will not overwrite the lastusedport value in the Node table. We hardcoded the HTTP transport as 9079 and does not expose the new configured port value to avoid the port value conflict and easily tracking for the users whenever in single or multi-node environment. The design has been working since 4.0.1 and we do not think that it is necessary to change the existed behavior in the apar or ptf release because most of users/customers use to the behavior since 4. 0.1. It is just like we hardcode the bootstrap port as 900 and lsdport as 9000. The customer can change the HTTP transport through the adminGUI or write a simple wscp script to set up the transport values as they need in creating the application servers. ============================= APAR: PQ60522 Version: 400 Abstract: ADDRESS REMOVE SERVER TO ENSURE DB UPDATES OCCUR IN A SINGLE TRANSACTION. Error Description: fix to Server.ejbRemove is to move activeObject invocation into new (After-commit-task) thread such that the original ejbRemove is guranteed to be transactional (single transaction). Local Fix: Logically Dependent Apars: Users Affected: All WebSphere Application Server 4.0* users. Problem Description: WebSphere admin server fails to start and reports the following: AdminServer X WSVR0009E: Error during Startup com.ibm.ejs.exception. RemoteException: ADMR3016E:Failed to get the server group name Recommendation: Problem Summary: The problem is really one of inconsistency in the WAS repository. This was caused by a code sequence that should have occurred within a single transaction but was actually split into multiple transactions. The first part of the sequence was committed, but the second part failed and the accompanying rollback could not undo the earlier updates. The current version of the dbcheck tool can detect (but not correct) the inconsistency in the database. The only safe recovery is to reconstruct the repository. Problem Conclusion: Modified code so that sequence of operations is performed within a single transaction. Test fix sent to customer and checked into CMVC for inclusion in next PTF. ============================= APAR: PQ60657 Version: 400 Abstract: EAR FILE NOT EXPANDED AFTER INSTALL WITH REMOTE ADMIN CONSOLE Error Description: When using a remote admin console to install an Ear file that is local to the adminserver the adminclient is connecting to, the final screen informs the user that the file is local to the install node and will be expanded in the installedApps direc tory. This however does not occur. The application is visible in the console, but will not run properly because the code has not been expanded into the installedApps directory. The error "CNTR0020E" appears when trying to start or access info on the i nstalled application. Customer receives feedback that the install was successful, without being told that the EARexpander has to be run against the EAR file before the application is fully installed. This is a false positive. Local Fix: Manually expand the ear file in the installedApps directory. Logically Dependent Apars: Users Affected: WebSphere Application Server users running 4.0.2 or later with a multi-node environment (where multiple nodes share the same remote repository) wishing to install enterprise Applications via a remotely connected console Problem Description: In a multi-node environment, when using a remote admin console to install an Ear file that is local to the adminserver the adminclient is connecting to, the final screen informs the user that the file is local to the install node and will be expanded in the installedApps directory. This however does not occur, EAR does not expand and no directory is created. Recommendation: Problem Summary: In multi-node environment, EAR fails to expand when installed through a remote admin console. The installation appears to succeed, the application is visible in the console, but will not run properly because the code has not been expanded into the installedApps directory. The error "CNTR0020E" appears when trying to start or access info on the installed application. User receives feedback that the install was successful, without being told that the EARexpander has to be run against the EAR file before the application is fully installed. This is a false positive. Problem Conclusion: The current requirements for expanding an EAR file on a particular system are: 1. EAR file to install exists on intended node 2. Admin server servicing the request to expand the EAR file is running on same node 3. Node on which EAR file is expanded is same as for #1 and #2 above. With this fix, expanding the EAR file will be determined only by: - node on which EAR file resides and node on which EAR file is to be expanded are the same, node on which admin server is running will not be a factor! As a result, the user can have a local console connect to a local adminserver and install EAR on remote nodes in the multi-node cluster without needing to manually expand the EAR. The console has been modified to correctly display the proper message. If EAR file resides on a node other than the one intended to install on, user will need to manually expand the EAR on the intended node. This is the expected behavior of WebSphere. A console provides message to inform user. ============================= APAR: PQ60843 Version: 400 Abstract: CANNOT USE THE NODENAME PROPERTY. EAR WILL NOT EXPAND PROPERLY Error Description: Customer explanation of the problem is as follows: For configuring WAS on a machine with multiple NIC's, I add the following line to the admin.config file: com.ibm.ejs.sm.adminServer.nodeName=mydevnode I start WAS for the first time, and open the admin console. Everything looks fine, the node name is dev203e However, when I install an Enterprise Application the files do notget installed into /usr/WebSphere/AppServer/installedApps. I stopped WAS, dropped the admin database, and removed the extra line from the admin.config. I changed initial.config and createTables in admin.config. Started WAS and opened the admin console. I installed the same application, and it worked correctly, expanding the .ear to the local disk. I repeated this cycle from the beginning, and it seems that when the nodeName is set manually, Enterprise Applications do not expand to the /usr/WebSphere/AppServer/installedApps directory on the local machine. Is this expected? I need to use the nodeName property. Original PMR 52994,370,000. PMR 70824,370,000 is a continuation of PMR 52994,370,000. Local Fix: Customer is using a testfix, newtest.jar provided by L3 as a temporary fix until the APAR can be provided. newtest.jar located in wasdoc0/pmrs/70824370000/05,03,02_testfix Logically Dependent Apars: Users Affected: WebSphere Application Server 4.02 users with multiple network interface cards in their system(s). Problem Description: When user has multiple network interface cards in the system and goes to install a WebSphere Enterprise Application, the .ear file may not expand into the correct directory. Recommendation: Problem Summary: Note: Only applicable in systems with multiple network interface cards! WebSphere uses the value returned by the UNIX/Windows hostname command as its node name. This will generally be the primary NIC (network interface card) on the machine, which is a problem if you need it to bind to the secondary NIC. In this case, after installing an enterprise application on a WebSphere system, the contents of the .ear file are not placed in the $WAS_HOME/installedApps directory. Problem Conclusion: Changed the code in method installOnNode(), in file: com\ibm\ejs\sm\beans\EnterpriseAppBean.java so that .ear file will expand properly. ============================= APAR: PQ62229 Version: 400 Abstract: WSCP CORRUPTS 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 rebuildthe admin repository. Local Fix: The only workaround at this time is to drop and rebuild the admin repository. Logically Dependent Apars: Users Affected: WebSphere Application Server 4.0.x users of WSCP. Problem Description: WSCP is causing the repository to become corrupt. Recommendation: Problem Summary: When a running WebSphere Enterprise App is deleted via wscp (before it is stopped), the WebSphere repository becomes inconsistent. The repository must then be dropped and recreated. Problem Conclusion: Added code so that we only remove enterprise app's associated objects and relations if it is stopped. If not stopped we do not remove those and, instead, throw remote exception. ============================= APAR: PQ62333 Version: 400 Abstract: ADMIN CONSOLE INDICATES ENTERPRISE APPLICATION IS STARTED, HOWEVER, WHEN CHECKED WITH WSCP IT SHOWS STOPPED. Error Description: Here is the test senerio for WSCP: 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. Local Fix: If the Enterprise Application is running, WSCP will show stopped as the current status, however, it wil lhave a StartTime. If the Enterprise Application is stopped, there will be no StartTime. So by viewing the StartTime field, the customer can determine if the Enterprise Application is actually running. OR Use the Console and View Status. Logically Dependent Apars: Users Affected: WebSphere Application Server users running 4.0.2 or later using WSCP to check current status of enterpriseApp or module Problem Description: Admin console indicates enterprise application is started/running, however when checked using WSCP is shows it is stopped. Recommendation: Problem Summary: Here is the test senerio for WSCP: 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 WSCP output shows stopped but the console shows "Running" by right-clicking on the application->show status on the GUI. Issuing a WSCP show command on a module also returns incorrect state. Problem Conclusion: Application of eFix PQ62333 allows customer to use WSCP to learn the status of the EnterpriseApps by issuing the "show" command and look at the "currentState" attribute. ***NOTE**** The console "show status" on Application is really reporting a table with status of each server each module is installed on. The reason for this is because when the App is installed on a ServerGroup, various permutations of the state of servers and modules can exist on the EnterpriseApp. Consequently, WSCP show on EnterpriseApp reports status of the App based on the status of servers and modules: An EnterpriseApp is "running" if at least one of the Modules it contains is running. A Module is "running" if all the servers it is installed on are running. This fix also address same incorrect current status reported on Modules using WSCP Module show command. ============================= APAR: PQ62494 Version: 350 Abstract: ADMIN SERVER SHOULD RECONNECT TO RUNNING APP SERVERS RUNNING AND/OR STARTED Error Description: The expected behavior for the AdminServer is to reconnect to appservers that are already running . There should not be any new process created. But currently, Websphere AdminServer always considers a START as NEW WAS start and goes ahead and starts the appservers. (WAS has to consult with admin DB to decide if it has to start appserver or not). There is a flag which will tell the adminserver if that is a restart, which is never set, since the startupServer script is used to start the Adminserver, Websphere considers it as a normal start and creates a new appserver process. Local Fix: NA Logically Dependent Apars: Users Affected: All WebSphere Application Server users. Problem Description: If admin server is restarted, it fails to connect to running app servers. This may result in multiple copies of app servers running simultaneously. Recommendation: Problem Summary: Several problems were corrected so that admin server can successfully check for existence of and connect to running app servers. To have this behavior, it is required that the user add the following to line to admin.config: forceReconnectProp=com.ibm.ejs.sm.adminServer.forceReconnect Problem Conclusion: Test fix sent to customer and feedback was reported good. Code dropped for inclusion in future updates. ============================= APAR: PQ62586 Version: 400 Abstract: PORTING PQ53566 TO WAS 4.0- ALLOW ADMIN SERVER STATEFUL SESSION BEANS TO BE PERSISTED TO A DIRECTORY CONFIGURABLE BY THE USER. Error Description: PROBLEM: 'BeanIDxxxx" files getting created in the 'bin' directory due to stateful session beans in the admin server. The customer would like to specify a different directory for these files so that they do not clutter up- and in the worst case, actually use up the complete disk space- the file system on which the 'bin' directory is located. PQ53566 already does this for WAS 3.5. Need to port it to WAS 4.0. Local Fix: Stop admin server; delete the files from the bin directory; restart admin server. Logically Dependent Apars: Users Affected: WebSphere Application Server users of stateful EJBs. Problem Description: WebSphere is incorrectly setting the stateful EJB's passivation directory for admin server beans in admin.config Recommendation: Problem Summary: Websphere is putting temp bean files in washome\bin directory for the stateful EJB. Problem Conclusion: Add an entry in the admin.config file: com.ibm.ejs.sm.adminserver.containerStatefulBeanPassivationDir=< directory_name> where is the path and directory for stateful bean passivation. files. Create a directory with this name if it does not already exist. Stop and restart the Admin Server. ============================= APAR: PQ62793 Version: 350 Abstract: NODE FOR RESTART OPTION FAILS TO KILL JVM PROCESS ID OF APPSERVER THAT FAILS ON STARTUP. Error Description: When customer uses xmlconfig to perform a node for restart on a node, and that particular node has a jvm that failed to start on startup but started succesfully afterwards, the process id for that jvm remains after the node has been restarted. Customer has to perform a kill - 9 on the process id in order for it to go away. On Windows 2K, a reboot is in order for the process to go away. To recreate this problem, rename a jar file for an ejb in an application server. Startup that application server and it will fail due to the Local Fix: can not locate the jar. After renaming the jar file and then starting the ejb the appserver is fine. The appserver actually starts but there is an error with the ejb container initially. Local fix is to perform a kill -9 on the stray java process or on NT reboot. Logically Dependent Apars: Users Affected: WebSphere Application Server 3.5 and 4.0 users Problem Description: Node "stop for restart" option fails to kill application server jvm process id. Recommendation: Problem Summary: When using xmlconfig/wscp/admin console to perform a "node for restart" on a node, and that particular node has a jvm that failed to start on startup (application server initialization failure), the process id for that jvm remains after the node has been restarted. Users have to perform a kill -9 on the process id in order for it to go away. On windows 2K, a reboot is in order for the process to go away. Problem Conclusion: The application server process will never be stopped using the node "stop for restart" option in any admin client once the application server fails to start due to the application failure or other reason. The problem is the admin server does not update/restore the ejbserver state in the object configuration thus causing the stop function to fail to stop the application server process. ============================= APAR: PQ63158 Version: 400 Abstract: ENTRIES IN WELCOME FILE LIST FOR WEB MODULE DD DO NOT SHOW UP IN "VIEW DEPLOYMENT" IN ADMINCONSOLE NOR IN THE AAT. Error Description: war file, has three entries in it's welcome file list in it deployment descriptor (in web.xml). Of these three filesthird normally exists, but get a file not found on the 2nd or third file names. Only when he creates a file called index.html, which is first name in welcome list in proper directory does find the file. Local Fix: Logically Dependent Apars: Users Affected: WebSphere Application Server users of 4.0.x using console to view deployment descriptor on deployed web module. Problem Description: Not all entries in the welcome-file list for web module DD show up in "view deployment" in adminconsole. Recommendation: Problem Summary: If a war file has multiple entries in its welcome-file list in the deployment descriptor (in web.xml), only the first one shows up on the console with "view deployment descriptor". When using AAT, all of the files are listed correctly. Problem Conclusion: Problem is caused by error in the web.xsl style sheet for web.xml which caused incorrect parsing and transformation of the xml file to html. Problem resolved by correcting the style sheet specification for "welcome-file" to anticipate more than one entry. ============================= APAR: PQ63523 Version: 400 Abstract: WHEN AN ENTERPRISE APP IS REMOVED, THE ENTRY UNDER INSTALLEDAPPS IS NOT REMOVED AND IS A SYMBOLIC LINK TO ANOTHER FILESYSTEM. Error Description: Upon removal of enterprise bean WAS 4.0.2 is not removing the subdirectory under /installedApps directory. This directory is a symbolic link to another filesystem. If the customer doesn't use this sysmbolic link , the entry under installedApps directory will be removed with no problem. WAS4.0.2 AIX 4.3.3 Local Fix: No Work Around . Logically Dependent Apars: Users Affected: WebSphere Application Server users running 4.0.2 with "/installedApp" or other WebSphere directories set up as symbolic links Problem Description: Upon removal of enterprise bean on WebSphere 4.0.2, the subdirectory under /installedApps directory is not being removed if the directory is a symbolic link to another filesystem. Recommendation: Problem Summary: If a user has set up their environment with WebSphere "/installedApp" directory as symbolic link to another file system for the purpose such as centralizing data for ease of management, when enterprise applications are uninstalled, WebSphere does not recursivly follow the symbolic link to delete the files on the remore file system. Problem Conclusion: Follow symbolic link when deleting directories should not be the " standard behavior". Systems do not follow symbolic link when deleting files to prevent critical files and directories from accidentally being deleted if not mindful. However from a usability stand point, "not follow symbolic link" as the absolute behavior is too restrictive. This fix allows a configurable property in admin. config to turn on and off "follow symbolic link" when deleting directories. By default this is set to false (off). ============================= APAR: PQ65214 Version: 400 Abstract: APPLICATION SERVER COMMAND LINE ARGUMENTS CONTAINING SPACE CHARACTERS WITHIN QUOTED STRINGS ARE NOT PARSED CORRECTLY. Error Description: When a command line argument for an app server has quoted text with a blank, the string is split at the space when the command line is parsed. This prevents the app server from starting. Local Fix: No workaround available. Logically Dependent Apars: Users Affected: WebSphere Application Server Users of spaces in Command line arguments. Problem Description: The application server won't start if command line argument has a blank in the quoted text. Recommendation: Problem Summary: When a command line argument for an appserver has quoted text with a blank, the string is split at the space when the command line is parsed. This prevents the appserver from starting. Problem Conclusion: Command Line arguments are parsed to retain the spaces when enclosed in quotes. ============================= APAR: PQ65232 Version: 400 Abstract: IF YOU CREATE A GENERIC SERVER BEFORE AN APPLICATION SERVER, THE APPLICATION SERVER ERRORS OCCURRED DURING DUPLICATE PORT CHECK Error Description: 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. If you create the application servers before the generic server then everything is fine. Local Fix: To work around this problem create the application servers before you create the generic server Logically Dependent Apars: Users Affected: WebSphere Application Server users of 4.0.3 using generic servers and app servers in the environment Problem Description: If user creates app servers after generic servers, errors are produced and app server creation could fail. Recommendation: Problem Summary: When creating an application server after creating a generic server, errors occur during Duplicate Port Check. If using the console, the application server is created but the Transport is erroneous (fixed to 9080). However, if this is done with XML imports, the application server is not created at all. The same Duplicate Port Check failures occur when creating the app server when there are already generic servers. Problem Conclusion: The fix corrects the problems encountered during Duplicate Port Check when creating app servers. Prior to the fix Duplicate Port Check iterates through ALL servers on the Node including the generic servers which is not correct. ============================= APAR: PQ65491 Version: 400 Abstract: FOR A GENERIC SERVER, WE DO NOT PROVIDE THE ABILITY TO SET THE NODE-START-STATE Error Description: There is no node-start-state option for Generic Servers Local Fix: none Logically Dependent Apars: Users Affected: WebSphere Application Server users of 4.0.3 who create and run generic servers. Problem Description: On WAS 4.0.4 and earlier, there is not an option to configure the NodeStartState for a Generic Server Recommendation: Problem Summary: Currently NodeStartState configurability is only available on application servers, and not on Generic Servers. Whenever a node restarts, the state of the generic servers are default to its last (current) state only. Problem Conclusion: 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. Generic Servers NodeStartState is configured through a new system property in admin. config file. com.ibm.ejs.sm.adminServer.GenericServerNodeStartState=Current|Running|Stopped ============================= APAR: PQ65647 Version: 400 Abstract: APPSERVER ARGUMENTS SEQUENCE WRONG WHEN TRYING TO SETUP SPLIT SECURITY. Error Description: I discussed the problem with our L3 WebSphere security team. They indicated this is a known problem and provided the following corrections/additions to the instructions in the InfoCenter: ******************** There is a system management problem reading from the ConfigURL file. The properties get overwritten by the one's passed in from the command line when the process gets launched. To disable security in appserver, add the following line to the JVM settings in the appserver (for LTPA) com.ibm.CORBA.SSLTypeIClientAssociationEnabled=false com.ibm.CORBA.LocalOSClientAssociationEnabled=false com.ibm.CORBA.LTPAClientAssociationEnabled=false com.ibm.CORBA.DCEClientAssociationEnabled=false com.ibm.CORBA.SSLTypeIServerAssociationEnabled=true com.ibm.CORBA.LocalOSServerAssociationEnabled=false com.ibm.CORBA.LTPAServerAssociationEnabled=true Modify the sas.server.props as shown in the InfoCenter: add the following line the sas.server.props # Client Association properties com.ibm.CORBA.SSLTypeIClientAssociationEnabled=true com.ibm.CORBA.LocalOSClientAssociationEnabled=false com.ibm.CORBA.LTPAClientAssociationEnabled=true # Server Association properties com.ibm.CORBA.SSLTypeIServerAssociationEnabled=true com.ibm.CORBA.LocalOSServerAssociationEnabled=false com.ibm.CORBA.LTPAServerAssociationEnabled=true . The work-around does work in the customers environment. The problem is that the cleaner and proper way of implementing the property settings is to use the param: "-Dcom.ibm.CORBA.ConfigURL=file:///usr/WebSphere/AppServer/properties/sas.appserver.props" Local Fix: commands must be entered individually instead of in the props file. Logically Dependent Apars: Users Affected: Problem Description: Recommendation: Problem Summary: Problem Conclusion: ============================= APAR: PQ66574 Version: 400 Abstract: IN A MULTINODE ENVIRONMENT Error Description: Problem: After PTF 3 was applied, the nanny.trace file contained multiple instaces of the message "NMSV0602E: Naming Service unavailable. A communications error occurred." and when any one node is down, unable to successfully regen the plug-in. PQ61462 did not affect the situation. Error in the nanny's file: 5/14/02 14:53:17:370 CDTf4cb Nanny E error getting nodeHome for : ejsadmin/homes/NodeHome : java.lang.NullPointerException 5/14/02 14:53:18:387 CDTf4cb WsnInitCtxFac W NMSV0602E: Naming Service unavailable. A communications error occurred. 5/14/02 14:53:18:388 CDTf4cb Nanny W SMTL0012W: Waiting for initial context javax.naming.CommunicationException: Caught CORBA.COMM_FAILURE when resolving initial reference=WsnNameService. Root exception is org.omg.CORBA.COMM_FAILURE: minor code: 3 completed: No Error in the XML Export: ExceptionUtil X CNTR0019E: Non-application exception occurred while processing method findAll: InvalidBeanOStateException(current = DESTROYED, expected = POOLED) at com.ibm.ejs.container.EJSHome.getFinderBeanO(EJSHome.java(Compil ed Code)) ExceptionUtil X CNTR0020E: Non-application exception occurred while processing method listInstances on bean BeanId(admin#repository.jar#ClientAccess, null): java.rmi.RemoteException: ; nested exception is: javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0 No; nested exception is: org.omg.CORBA.TRANSACTION_ROLLEDBACK: com.ibm.websphere.csi.CSITransactionRolledbackException: null; nested exception is: InvalidBeanOStateException(current = DESTROYED, expected = POOLED) and the plug-in trace shows: 7/22/02 17:27:41:080 CDT 40405c3 AEPluginCfg W PLGN0063W: An exception occurred while generating the plugin configuration for module default_app. The plugin configuration file will not contain an entry for this module. and the dbcheckprop.sh generates: COM.ibm.db2.jdbc.DB2Exception: IBM CLI Driver DB2/6000 SQL0204N "WAS40.TYPE_TABLE" is an undefined name. SQLSTATE=42704 at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_SQLException(SQ LExcepti onGenerator.java:269) at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_SQLException(SQ LExcepti onGenerator.java:206) at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.check_return_code(SQL Exceptio nGenerator.java:457) at COM.ibm.db2.jdbc.app.DB2Statement.execute2(DB2Statement.java:617 ) at COM.ibm.db2.jdbc.app.DB2Statement.executeQuery(DB2Statement.java :434) at com.ibm.ws.dbcheck.util.WriteDBProps.readDb(WriteDBProps.java:11 0) at com.ibm.ws.dbcheck.util.WriteDBProps.write(WriteDBProps.java:193 ) at com.ibm.ws.dbcheck.util.WriteDBProps.main(WriteDBProps.java:72) Local Fix: None Logically Dependent Apars: Users Affected: WebSphere Application Server users on 4.0.3 or later who regenerate the plugin configuration in multinode environment Problem Description: On WAS 4.0.x, regenerate plugin failures occurs in multinode environment Recommendation: Problem Summary: Regenerate plugin does not complete and fails if any node is down in the multinode environment Problem Conclusion: This eFix is a cross-component fix between System Management and Engine to improve code logic to detect and skip a node if it is down and also properly handle the exceptions when such problem occurs. These improvements prevent the entire plugin regen procedure from failing completely and provide more graceful error handling for the user.