PQ75957: THIS APAR ADDRESSES DEFECTS IN WEBSPHERE APPLICATION SERVER V5.0 FOR Z/OS. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description Local fix Problem summary **************************************************************** * USERS AFFECTED: * * All users of WebSphere Application Server * * V5.0 for z/OS * **************************************************************** * PROBLEM DESCRIPTION: APAR PQ75957 addresses various defects * * in WebSphere Application Server V5.0 * * for z/OS. * **************************************************************** * RECOMMENDATION: * **************************************************************** APAR PQ75957 addresses the following defects in WebSphere Application Server V5.0 for z/OS: (MD15508) If WebSphere V5.0 for z/OS is using the SAF registry and a web user is unauthenticated, WebSphere does not build an unauthenticated credential using the ID specified by com.ibm.security.SAF.unauthenticated in the administrative console (default=WSGUEST). (MD16744) ABENDS0C4/ABEND0C4 in DLL BBOBOA, BBO_BOA::context_association. The BOA keeps track of transactions in the Controller for routing work and timeout processing. The BOA maintains a GTID table (bboogtid.h) which has entries hashed by two hash tables. The two tables are hashed by RRS Context Token and hashed by GTID. If an entry (GTID_Row is hashed by both tables (the normal condition) then both hash tables physically point to the same GTID_Row entry representing the Global Transaction. GTID_Row's are added to the table when OTS code drives BBO_BOA::context_association (bbooboai.h) and removed on calls to BBO_BOA::context_disassociation. If multiple context_association calls with the same RRS context token are made without a context_disassociation between, then the BOA GTID table will be corrupted. This corruption leads to ABEND0C4's in accesses to the GTID table. (MD17165) The following problems exist in the current WebSphere Application Server V5.0 for z/OS CSIv2 implementation: 1. The server's IOR a. has an incorrect length field for the realm name b. has an errant, asserted identify type, supported c. does not comply with exporting port zero as the general port of access when CSIv2 requires SSL connections d. erred by requiring trust in target e. does not check the Admin Console derived flag for supporting Asserted Identity. (No specific abends or errors occur due to these problems.) 2. The defaults taken for requiring and supporting supplemental client authentication were changed from true to false. (Clients that do not wish to use userid and password authentication are barred from accessing z/OS servers.) 3. An abend will occur when a server attempts to assert a distinguished name, ( CEEDUMP code 04060030 reason code ec3) 4. The code sent CSIv2 service contexts on transport only connections. (No specific errors of abend codes occur due to this error.) (MD17232) The following security related problems exist in the WebSphere V5.0 for z/OS J2C connector support: - A Utoken is required for IMS & CICS connectors when security in disabled and instead an exception is being thrown. - The connector code was unable to access the WSLocalzOSExtensionImpl from the security component. - There should only be one subject created per credential, instead a new subject is being created every time a getConnection() is called. This has implications for connection pooling. - The GenericCredential (Utoken) should be saved in the subject as a private credential and is currently being saves as a public credential. (MD17237) When daeamon is stopped it produces "BBOO0037E Function IWMDISC failed with RC=4, REASON=03030409" message. The daemon is errouneous attempting to disconnect for WLM. This disconnect should not be issued, since the daemon never connects to WLM. (MD17284) ClassCastException on narrow() of object in Finder. PortableRemoteObject.narrow() throws a ClassCastException when narrowing a stub that has been returned by a finder. (MD17306) IJP will fail if the messagingserver namespace is not in the server.xml. When configuring IJP using the WebSphere for z/OS Customization, there is a job to add the JMSServer stanza into the AppServer's server.xml. However, the job does not add the messagingserver namespace. This will be a problem if the user has performed the following, prior to the application of this PTF: 1. Configure AppServer, then do some administrative console processing to cause the "server.xml" to be updated. Since the code flatten and compress the XMI namespace to remove any namespace that is not used, the messagingserver namespace will be removed. 2. Configure IJP, and the JMSServer stanza will be added to server.xml. 3. Server will fail with an error similar to the following because the messagingserver namespace is missing from the server.xml: BossLog: { 0001} 2003/06/04 18:16:53.636 01 SYSTEM=SY1 SERVER=BBOS001 PID=0X04000021 TID=0X2732B940 00000000 c=UNK /bborjtr.cpp+812 ... BBOO0222I WSVR0300I: Problems found in /WebSphere/V5R0M0/AppServer/config/cells/SY1/nodes/SY1/servers /server1/server.xml BossLog: { 0002} 2003/06/04 18:16:53.660 01 SYSTEM=SY1 SERVER=BBOS001 PID=0X04000021 TID=0X2732B940 00000000 c=UNK /bborjtr.cpp+812 ... BBOO0221W WSVR0307W: Invalid namespace, messagingserver, at line 54 BossLog: { 0003} 2003/06/04 18:16:53.666 01 SYSTEM=SY1 SERVER=BBOS001 PID=0X04000021 TID=0X2732B940 00000000 c=UNK /bborjtr.cpp+812 ... BBOO0221W WSVR0305W: Invalid attribute, queueNames, at line 55 SERVER=BBOS001 PID=0X04000021 TID=0X2732B940 00000000 c=UNK /bborjtr.cpp+812 ... BBOO0221W WSVR0100W: An error occurred initializing, com.ibm.ws.runtime.config.BaseServerConfigLoc ator@2ac3bc8c com.ibm.ws.exception.ConfigurationError at com.ibm.ws.runtime.config.BaseServerConfigLocator. initialize(BaseServerConfigLocator.java:29) (MD17137) Variable com_ibm_CSI_claimIdentityAssertionSupported does not show up in the was.env. There was not transform for the variable. (MD17430) gsk_secure_soc_read fails with rc=410 or 411 when processing an IIOP fragmented request. During the receive of an IIOP fragmented request over an SSL socket, raw TCP/IP message are lost on the receiving side, resulting in 410 and 411 return codes for the SSL receives. (PQ74974) Inbound GIOP CANCEL request causes WebSphere Application Server V5.0 for z/OS to log minor code C9C21011 RSN=00000007 and stop listening. Currently, In WebSphere V5.0, there is no code to handle a GIOP inbound cancel request so the request gets thrown away. WebSphere will stop listening on the socket and as a result no further GIOP requests are received and processed. (WS17156.01) Users an not install large application because HTTP transport is limited to 10 MB. Users will see messages similar to the following:Problem conclusion APAR PQ75957 fixes various defects in WebSphere Application Server V5.0 for z/OS. (MD15508) Code was added to build the unauthenticated credential using the ID specified by com.ibm.security.SAF.unauthenticated. If this value is not specified or is not a valid SAF userid, WebSphere fall back to the ID specified by security.remote.identity. (MD16744) Code has been modified in BBO_BOA::context_association to verify that the RRS Context Token is not already in the GTID Table before proceeding. If the RRS Context token is found to be in the table, then the request will be failed. (MD17165) WebSphere V5.0 for z/OS CSIv2 code has been updated to comply with the CSIv2 and CORBA specifications. (MD17232) The following changes were made to the WebSphere V5.0 for z/OS J2C connector support: - When security is disabled use the LocalOS Server Credential to establish a Utoken. - The WSLoginLocalOSExtensionFactory class was added to allow the J2C code to access the WSLocalzOSExtensionImpl from the security component. - get/setSubject in the WSCredentialImpl so that only one Subject will be created per credential. - The GenericalCredential (Utoken) is saved as a private credential within the subject created. (MD17237) Code has been modified to remove the WLM disconnect call on daemon stop. (MD17284) Type-checking code was modified to remove the ClassCastException. (MD17306) Dialog code has been be updated such that when the JMSServer stanza is inserted, the messagingserver namespace will be inserted as well. If you observe the errors described in the Summary, you can configure the IJP server successfully after applying this PTF. (MD17317) The necessary transform was added for variable com_ibm_CSI_claimIdentityAssertionSupported. (MD17430) The buffering scheme that handled raw TCP/IP requests was fixed to not lose packets. (PQ74974) Support was added to recognize GIOP inbound cancel request and reset asynchronous peek. (WS17156.01) Support was modified to make the message limit configurable and update bbooboat.cpp to check the size against the limit before sending the response. (WS17165.02) Support was added to provide an environment variable, protocol_http_large_data_inbound_buffer, that provides the size of a serially reusable input buffer for http requests larger than 10 MB. Module bbochttp.cpp was changed to use the http large data input buffer if it is available. This APAR requires changes to the WebSphere V5.0 for z/OS documentation. A change to V5 WebSphere for z/OS: Messages, GA22-7915-00 and a WebSphere for z/OS V5 InfoCenter article update will be available in the next refresh of the documentation. To access the latest online documentation, go to the product library page at: www.ibm.com/software/webservers/appserv/zos_os390/library/ **************************************************************** Additions to the InfoCenter: Version 5 introduces a new environment variables: protocol_http_large_data_inbound_buffer The variable, protocol_http_large_data_inbound_buffer, Specifies in bytes the length of a serially reusable inbound buffer used for HTTP requests larger than 10 MB. Inbound HTTP requests larger than this value are rejected. Default is zero which indicates no buffer is needed and requests larger than 10 mega bytes are rejected. protocol_http_large_data_response_buffer Specifies in bytes the maximum length of the response buffer used for HTTP requests. Requests larger than this value are rejected. The minimum is 10MB. The default is 100MB. **************************************************************** Additions to the WebSphere V5 for z/OS: Messages, GA22-7915-00: ________________________________________________________________ Chapter 1, pg. 40 (new message) BBOO0243W HTTP LARGE DATA INPUT BUFFER LENGTH number COULD NOT BE OBTAINED. Explanation: Control region could not obtain storage for the HTTP large data input buffer. User Response: If the buffer is required, decrease the storage used by the server or decrease the value specified on the protocol_http_large_data_inbound_buffer variable and re-start the server. ________________________________________________________________ Chapter 1, pg. 40 (new message) BBOO0244W HTTP LARGE DATA INPUT BUFFER LENGTH number LESS THAN LARGE CELL SIZE number Explanation: Control region did not allocate a HTTP large data input buffer because the requested length is not greater than the large cpool cell size. User Response: If the buffer is required, increase the value specified on the protocol_http_large_data_inbound_buffer variable and re-start the server. ________________________________________________________________ APAR PQ75957 is associated with SERVICE LEVEL W500102 of WebSphere Application Server V5.0 for z/OS.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: UQ78241 Modules/Macros
Publications Referenced
|
Document Information |
Current web document: swg1PQ75957.html
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server for z/OS
Operating system(s):
Software version: 500
Software edition:
Reference #: PQ75957
IBM Group: Software Group
Modified date: Aug 6, 2003
(C) Copyright IBM Corporation 2000, 2009. All Rights Reserved.