PQ49215: THIS APAR ADDRESSES DEFECTS IN WEBSPHERE APPLICATION SERVER V4.0 FOR Z/OS AND OS/390. | |||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description This APAR addresses defects in 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 PQ49215 addresses various problems * * in WebSphere Application Server V4.0 * * for z/OS and OS/390. * **************************************************************** * RECOMMENDATION: * **************************************************************** APAR PQ49215 addresses the following problems in WebSphere Application Server V4.0 for z/OS and OS/390: The default setting for SSL RACF Keyring in inputcreateserver.xml does not match that of the Administration Application. The default in the script is blank, and the Administration Application has CBKeyring as the default. The SM Scripting API call 'startserver' produces error messages even though the call itself succeeds. SM Scripting messages like the following will be received: message.1 BBON3199E Method start failed. message.2 BBON3179E Attribute 0 is unknown for Serverinstance Status The SM Scripting API points to another index other than the status of the server instance. The SM Scripting API call 'start' produces error messages and the call itself fails. SM Scripting mesages like the following will be received: message.1 BBON3199E Method start failed. message.2 BBON3142E Server instance BBOASR1A has invalid state. The SM Scripting API points to another index other than the status of the server instance. A faulty error message is returned when issuing a SM Scripting API call 'createserver'. SM Scripting API call 'createserver' with the attribute 'isolationpolicy' set to an non-valid value produces an error which does not specify the wrong value. The output will look like the following: message.1 BBON3199E Method createserver failed. message.2 BBON3175E Attribute is unknown for Isolation Policy The error message does not show the attribute value. There are two blanks in "BBON3175E Attribute is...", The 'changelrm' API call succeeds where it should fail. The LRM subsystem type has an invalid value (e.g. "lrmsubsystemtype=NOT_VALID"). The API call is executed and all other values are changed correctly. But the subsystem type change is ignored an the old value is kept. There is a routine in bboocomm.cpp, comm_outbound_locate, that has memory leaks of SupportedSecurities objects (lengths x'a68') The code in routine comm_outbound_locate new's up a SupportedSecurities object and saves it into the security area hung off of the comm Session object. The "saving" does not look for a prior SupportedSecurities object being there. If it already points to a SupportedSecurities then we will leak that object. Also, this code is not properly serialized. Two threads attempting to get/free a SupportedSecurities object simultaneously may result in one thread to 1) leak the object by overlaying the pointer set by the other thread and 2) to free the object already freed by the other thread. If naming registration fails for a new server and the server is then deleted, adding it back in a new conversation might fail with the following messages: BBON0402E J2EEServer BBOASR4 is already defined. BBON1002E The Server object, BBOASR4, is already defined. The problem is that naming registration failed before for the new server. What happened is the following: Create J2EE server, install J2EE applications on it, commit, activate. This writes naming registration entries for the server the IMRoot home (which is installed on each server), and for the various components that have been installed. These naming registration entries have action type "Create". Start the new J2EE server, naming registration fails for some reason. At that point, it might be the case that the IMRoot home has already been registered successfully. i.e., the associated naming registration entry has been removed. The remaining naming registration entries for components and server are still there with their action type "Create". Create conversation, delete J2EE server , commit, activate. This calculates naming registration entries for the server, based on the old entries in the Data Base, and the new action "Delete". The logic that is used here assumes that if a naming registration entry with action type "Create" is in the Data Base, then nothing has been registered for it; if the new action is "Delete", then nothing needs to be deregistered, and therefore, the naming registration entry is just removed from the database. Unfortunately, this reasoning is also applied to the server entry. The result is that the server naming registration entry is removed, and nothing gets deregistered for the server. Create conversation, create J2EE server with the same name leads to an exception "server already defined" because nothing was deregistered for the server (especially not the IMRoot entries in CORBA naming). When attempting to create a server instance with the scripting API, command similar to the following: CB390CFG( -action 'createserverinstance' -xmlinput 'inputcreateserverinstance.xml' -input 'smapi_input3' -output 'smapi_output' ) The content of smapi_output could be: message.1 BBON3199E Method createserverinstance failed. message.2 BBON3114E Attribute logstreamname = xxx.xxxxxxxx is invalid. Only OS/390 letters and digits are allowed. SM Scripting only accepts alphanumerics for logstreamname. It rejects the '.' used to separate the members of the DS name "xxx.xxxxxxxx". SMAPI should accept all valid characters for a fully qualified dataset. After a number of SM Scripting API calls a script will fail with error messages BBON3004 or BBON3007. After reaching a maximum number of file descriptors the system cannot open the next file. This behavior is caused by a missing close statement in file XMLGEN. This REXX function is for generating the temporary input file. When using the prepare for cold start processing, the bootstrap may fail in step 10 of phase 2 because there exists an invalid link to an ear file which is created for the reinstallation of the J2EE application. The invalid link is created using a path/filename which was stored in the ear file field during the bootstrap phase 1. It is missing a 0 (NULL) termination char.Problem conclusion inputcreateserver.xml is changed. Attribute 'sslracfkeyring' is set to 'CBKeyring' as default value. For SM Scripting API call 'startserver' processing the properties that are returned from the Systems Management call "DisplayImageServerInstance" have been changed. The SM Scripting API pointed to another index other than the status of the server instance. Now, the call is executed without any error message. For SM Scripting API call 'start' processing the properties that are returned from the Systems Management call "DisplayImageServerInstance" have been changed. The SM Scripting API pointed to another index other than the status of the server instance. Now, the call is executed without any error message. Support has been changed so that the non-valid attribute value and message number are returned to the script. This will result in the proper issuance of message BBON3175E. Method changelrm has been modified. The input for Systems Management was not generated correctly. Instead of taking the specified LRM subsystem type value from the default XML file respective the REXX script the old value was taken. The code change corrects this behavior. The specified value is now taken as input. That means that the call is not executed and an error message "BBON3174E Attribute XXXXXXXXXX is unknown for LRM Subsystem Type". Code in module bboocomm.cpp, method comm_outbound_locate() has been modified to use the macro CS (Compare & Swap) to check if the Session is already pointing to a security object. If this is the case then the SupportedSecurities already anchored will be reused and the one that was new'ed up will be deleted. If the Session doesn't have a security object, then the one that was newly created will be used. Support has been modified for server naming registration entries failures so that deregistration takes place in any case. Input parameter checking for parameter logstreamname has been modified to accept all valid characters for a fully qualified dataset. File XMLGEN has been modified with the addition of a close statement (close fd). This statement will correct the problem where XMLGEN was causing the system to run out of file descriptors. Module bbomib80.cpp has been modified to correct ear file name string termination. APAR PQ49215 is associated with SERVICE LEVEL W400014 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: UQ54755 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 #: PQ49215
IBM Group: Software Group
Modified date: Jul 3, 2001
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.