PQ50956: THIS APAR ADDRESSES DEFECTS IN WEBSPHERE APPLICATION SERVER V4.0 FOR Z/OS AND OS/390. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description All users of WebSphere Application Server V4.0 for z/OS and OS/390.Local fix Problem summary **************************************************************** * USERS AFFECTED: All users of WebSphere Application Server * * V4.0 for z/OS and OS/390. * **************************************************************** * PROBLEM DESCRIPTION: APAR PQ50956 addresses various problems * * in WebSphere Application Server V4.0 * * for z/OS and OS/390. * **************************************************************** * RECOMMENDATION: * **************************************************************** The sequence of new-delete-new (readd) does not work for an application within the same conversation. If an application or EAR file is installed, deleted and installed within the same conversation, the dialog token of all objects imported are set to "changed", though they are actually new objects and should be handled as new objects during naming registration. As it is now, RegisterHomesInNMLC will try to find the "base" homes/components for the new homes/components in the base conversation. This will fail with an exception as the homes/components are actually new, leading to a failure of activate with messages BBON1049E/BBON1115E. If an application or EAR file is reinstalled that contains less homes/components than its previous version, the "difference" never get uninstalled. This might lead to problems for client applications. Cancelling DAEMON doesn't bring all server regions down because the Open Edition Kernel doesn't kill threads with linkage stacks. RM name (resource manager name) used during registration with RRS contains the current system name instead of the configured system name. This dependency on the system name keeps WebSphere from retrieving incomplete units of recovery from the restart log when the server is started on a different system because the RM name changes. When servers are first started and Naming Registration is done for any new/changed/deleted information that needs to go into the name space. Currently message BBOU0694I NAMING REGISTRATION STARTED FOR SERVER XYZ is recorded in the job log for the application server for which the registration is being done. The corresponding message BBOU0695I NAMING REGISTRATION COMPLETED FOR SERVER XYZ only appears in the System Management server region and the SDSF log / mvs console. If there is a failure, you see message BBOU0652E NAMING REGISTRATION FAILED FOR SERVER XYZ in the application server's job log. So you get the started/failed messages together in the same job log for a failure. For successful cases, all you see in the application server's joblog is the "started" message and you have to go searching for the "completed" message. There needs to be consistency in the destination of these messages. Exceptions raised in beforeCompletion may not rollback the trasaction. Distributed transaction contexts that are imported into a J2EE server (ie. transaction originated in another server) may not be marked for rollback only if an exception is thrown during pre-prepare/beforeCompletion phase of the transaction out of the subordinate J2EE server. In particular, exceptions thrown out of ejbStore for CMP beans may not cause the transaction to rollback. In such a case, an IllegalStateException is thrown from the JTA transaction manager. Data array queries returning columns representing managed objects fail to commit and are rolled back by the system. The specific problem is that in bbosqqe6.cpp, method qes_get_interfaceNameOfMO_from_home_ptr(ahome) calls ahome->getMetadata() with an incorrect type for ahome causing an CORBA::NO_IMPLEMENT exception, resulting in the rollback. WebSphere System Management support does not distinguish EJB methods for home and remote interfaces. For methods that have the same name and signature in home and remote interfaces an incorrect transaction attribute might be reported for CMT. The current design for storing EJB methods and their transaction attributes in the System Mangement Database for retrieval via the CDM (Context Data Manager) does not include that fact, that we are dealing with two interfaces (home and remote) for each EJB that we maintain. Therefore, we cannot distinguish between methods, that have been defined on beans home, or on the beans remote interface. This does not hurt, as long as nobody defines methods that have the same name and signature on the home and remote interface. However, for methods that have the same name and signature in home and remote interface an incorrect transaction attribute might be reported for CMT. A storage overlay occurs in method loadAndInit in module bbolsys.cpp. This storage overlay can only occur if the Application Debugger Options are set. When the debugger options are set a trace record does a string concatenation and may overlay some storage. TransactionRolledback exceptions are not always thrown from UserTransaction.commit() when the transaction outcome is rollback. In particular, if a BMT session bean calls another bean that marks the transaction for rollback only, the exception is not raised as it should be. RMI/IIOP C++ bridge does not handle non-double aligned return parameters. The create_and_invoke_request method (bbooejsb.cpp) receives the marshalled response from the GIOP message by calling CORBA::Request::access_encap (bbooreq.cpp). access_encap returns the address of it's buffer and the length. However, access_encap does not consider that the encap may also be holding a pad value which is used to account for marshalled parameter streams that are not double word aligned. This may cause a number of different problems when de-marshalling the encap (ie. java.lang.OutOfMemoryError, java.lang.ArrayIndexOutOfBoundsException, ...). Not all beans of one module are installed if they have the same ejb class name (<ejb-class>). This problem comes up under these circumstances: 1. Ear file A with one jar jarA. jarA contains several beans with distinct ejb names (<ejb-name>) but the same ejb class name (<ejb-class>) for all beans. 2. Since <ejb-class> is not unique, only one of the beans is actually installed. The others are not available. This problem might have several symptoms. Typical scenario: Ear file B contains a jar jarB that holds references to the beans of jarA. When you select the ejb-refs on the reference tab of the Administration application for WebSphere for z/OS, the JNDI name column contains only one entry. It should show the entries for all the beans of jarA. The following intermittent exceptions can be received out of javax.naming.InitalContext.lookup()in multi threaded server regions: javax.naming.NamingException in method getObjectInstance javax.naming.InvalidNameException in method javax.naming.NameNotFoundException in method java.lang.StringIndexOutOfBoundsException WsnLdapContextImpl.java part contains a private static attribute for the NameFormatHelper. The instance of that class was being used across multi threads. There was an string attribute SinoStringConversionSource in the class that was being newed on entry to method string_to_name. Since the instance of the NameFormatHelper was being used across all thread the new of the string was probably making the string go away on another active thread and causing the index out of bounds exception. Multi thread issues in WsnLdapContextImpl.java were addessed by changing private static attribute for NameFormatHelper to a regular attribute. When using BMT Session beans in an application, the caller's transaction context, if any, is suspended before the BMT bean is dispatched. If the BMT bean touches any transactional resource (such as a DB2 table through JDBC) and does not commit or roll it back, the unit of work boundary checking and enforcement code does not detect the dangling local transaction. This can cause problem at of method dispatch or when starting a global transaction. PolicyIVP J2EE cebit.jsp webpage file does not reflect the correct client type to be displayed on webpage. The JSP webpage indicates it is using a "Servlet Client..." instead of "JSP Client...". Storage leaks exist in Java client bridge. bbooejsb.cpp leaks storage in the create_and_invoke_request method. The size of the leaks vary depending on the parameters to the method. Method EJSDeployedSupport.setContainer being driven too late out of EJSContainer.preInvoke(...). This causes incorrect exception mapping when an exception is raised prior to the current call. If an exception is raised during the first portion of EJSContainer.preInvoke(...), the exception mapping support in the container would raise a NullPointerException which would cause the container incorrectly throw an exception masking the exception which caused the error condition in the first place.Problem conclusion To address the problem with the sequence of new-delete-new for an application within the same conversation, if the base home/component cannot be found, it will be registered as new. To address the problem with application or EAR file reinstallment, before an application or EAR file is reinstalled, it will be flagged it as "to be deleted" first. Thus, only those objects that are actually present in the new version will be "undeleted". Support has been added to set PrliF1TermT in control and server regions so that the Open Edition kernel will unconditionally kill threads with linkage stacks. The Open Edition kernel was changed to honor this flag in APAR OW48547, thus this APAR is required to addressed the report Daemon cancel problem. RM name (resource manager name) is now built to contain the configured system name instead of the current system name. To provide the configured system name, a new generated environment variable "CONFIGURED_SYSTEM" will be added to every server instance's environment file. This will contain the name of the system to which the server instance was originally configured to. The new evironmental variable is for WebSpere V4.0 internal use only. It is not meant to be set or modified by the customer installation. The new environment variable is printed to the job output. It is not displayed on the Administration application for WebSphere for z/OS variable list for sysplex, server and server instance, and cannot be set there either. During activate, it is added automatically to each server instance's environment file. Support has been changed to write messages about naming registration started, completed and failed to both the application server control region and the System Management server region job log (and of course only once to the console). Additionally, the System Management server region job log contains the detailed information about home and component registration. The J2EE runtime code was changed to always mark the transaction for rollback only during beforeCompletion when an exception is thrown out of any java synchronization object that is registered with the transaction. Query module bbosqqe6.cpp and bbosqos.cpp have been modified to properly call method qes_get_interfaceNameOfMO_from_home_ptr(). Code has been added to distinguish between home and remote interface methods in the EAR file processor. The context data manager offers two getTxPolicy interfaces. The first is the old interface passing AMC key and mangeled method name, and returning the transaction policy. However, if more than one method qualifies (i.e., if there are methods having the same name and signature in home and remote interface), TX_Supports is returned. This makes WebSphere do the right thing in the server region. The second interface passes AMC key, mangeled method name and a flag "IsHomeMethod". As soon as ORB offers interfaces to access the target of an request (home or bean), WebSphere will start using this new interface, and get back the actual transaction policy in all cases. Module bbolsys.cpp has been modified to change the way the messages are displayed thus eliminating the string concatenation. javax.transaction.TransactionRolledbackException is now thrown from UserTransaction.commit when the transaction has rolled back. The create_and_invoke_request method has been updated to include the pad value in the header returned to the Java ORB (which is right before the marshalled parameters). On the Java side, invoke method of ClientDelegate.java, code was changed to extract the pad from the header and consume that many bytes after the *PADPAD* value of the header. This will ensure that the buffer is correctly aligned for the caller (which is an RMI/IIOP stub). The Ear file processor has been updated to use <ejb-name> instead of <ejb-class> in order to identify and store a component in BBO.BBOMT82_COMPONENT. Multi thread issues in WsnLdapContextImpl.java were addessed by changing private static attribute for NameFormatHelper to a regular attribute. The runtime code was changed to place a local transaction containment on the thread of execution prior to dispatching a BMT session bean. This containment code results in the correct tx boundary checking behavior. PolicyIVP J2EE cebit.jsp webpage file was updated to reflect correct client type to be displayed on webpage. Module bbooejsb.cpp has been modified to deleted the storage when it is no longer used. EJSContainer.java has been modified to call setContainer()at the top of EJSContainer.preInvoke(...). This will ensure that the exception mapping support is properly initialized to handle any exceptions, including system exceptions, for return to the client. The following publications were revised as a result of APAR PQ50956: NOTE: Periodically, we refresh the documentation on our Web site, so the changes might have been made before you read this text. To access the latest on-line documentation, go to the product library page at: http://www.ibm.com/software/webservers/appserv/ ________________________________________________________________ Document Name: WebSphere Application Server V4.0 for z/OS and OS/390 Messages and Diagnosis Document Number: GA22-7837-00 ________________________________________________________________ Chapter 12, pg. 297 (changed) BBOU0652E NAMING REGISTRATION FAILED FOR SERVER string Explanation:Naming registration failed for the specified server. As applications installed on the server do not work properly without being registered in naming, the server must be abended. User Response: Check accompanying messages in the job log of the System Management server region that processed naming registration for more details. ________________________________________________________________ Chapter 12, pg. 311 (new message) BBOU0732I NAMING REGISTRATION: NOTHING TO DO FOR SERVER string Explanation: Naming registration started for the specified server, but nothing needs to be registered. User Response: None. This message is for information only. **************************************************************** Document Name: WebSphere Application Server V4.0 for z/OS and OS/390: Installation and Customization Document Number: GA22-7834-01 ________________________________________________________________ On page 372, Table 58, add a new row for the environment variable CONFIGURED_SYSTEM. Place "R(1)" under each control region and server region column in the table and add the following footnote: (1) This environment variable is automatically added to each server instance's environment file and should not be edited. On page 380, add the following: CONFIGURED_SYSTEM Specifies the name of the system to which the server instance was originally configured. During prepare for cold start, cold start, and server activation, the run time adds this environment variable to each server instance's environment file automatically. RULE: Do not manually add or change this environment variable at any time, such as: o In the initial environment file before bootstrap o Through the Administration application (SM EUI) o In an existing server environment file APAR PQ50956 is associated with SERVICE LEVEL W400026 of WebSphere Application Server V4.0 for z/OS and OS/390.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: UQ57051 Modules/Macros
|
Document Information |
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server for z/OS
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ50956
IBM Group: Software Group
Modified date: Sep 5, 2001
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.