APAR status
Closed as documentation error.
Error description
This APAR describes the issues that customers encountered with IBM WebSphere Application Server Version 8.5. These issues were resolved as knowledge center updates in March, 2018.
Local fix
N/A
Problem summary
**************************************************************** * USERS AFFECTED: This APAR provides a cumulative list of * * the documentation issues for March, 2018 * * that affect users of IBM WebSphere * * Application Server Version 8.5. * **************************************************************** * PROBLEM DESCRIPTION: The Knowledge Centers for WebSphere * * Application Server Version 8.5 need * * to reflect customer enhancement * * requests received in problem * * management records (PMRs). These * * enhancements can include fixing * * technical inaccuracies or clarifying * * vague information. * **************************************************************** * RECOMMENDATION: * **************************************************************** See the Problem conclusion section for a description of the issues, which are described in customer PMRs, and the documentation change or changes that will address these issues.
Problem conclusion
Note: As we update our knowledge centers, the following Version 8.5 modifications will be available. To access the latest on-line documentation, go to the product library page at http://www.ibm.com/software/webservers/appserv/library and select the version and product that is appropriate for your WebSphere Application Server environment. The following Version 8.5 issues will be addressed: ID: 252778 (RTC) Problem: The ejbRemote-3.2 feature is also included in WebSphere Application Server Liberty Base offering. The WebSphere Liberty Base port documentation does not include the iiopPorts descriptions and it should. Resolution: Topic, Liberty: Default port numbers, is update to include the iiopPorts descriptions to read: Feature ejbRemote-3.2 Default port and configuration example IIOP port: 2809 IIOP/SSL port: 9402 <iiopEndpoint id="defaultIiopEndpoint" iiopPort="2809"> <iiopsOptions iiopsPort="9402" sslRef="defaultSSLConfig"/> </iiopEndpoint> This update also applies to V9.0 level of the knowledge center. ------------ ID: 786121 Problem: The behavior of AdminConfig.modify while updating control-region using "start commands arguments" is confusing. The behavior is different between 8.0.0.13 and 8.5.5.12. WebSphere Application Sever V8.5.5.12 has duplicated start command arguments. Clarify and fix. Resolution: Topic, Configuring processes using scripting, is updated. A new paragraph is added to the end of step 2c and before Step 3 that reads: The following example shows how to reset the process command argument values such as startCommandArgs, stopCommandArgs, executableArguments, and terminateCommandArgs. Use AdminConfig.resetAttributes() command to reset startCommandArgs with new value: Using Jacl: $AdminConfig resetAttributes $processDef {{"startCommandArgs", "JOBNAME=CCCCC,ENV=WAS00.NDN1.BBOS001,REUSASID=YES"}} Using Jython: AdminConfig.resetAttributes(processDef, '[[startCommandArgs "JOBNAME=CCCCC,ENV=WAS00.NDN1.BBOS001,REUSASID=YES"]]') Use AdminConfig.modify() command to unset and reset the attribute value: Using Jacl: $AdminConfig modify $processDef {{"startCommandArgs", ""}} $AdminConfig modify $processDef {{"startCommandArgs", "JOBNAME=CCCCC,ENV=WAS00.NDN1.BBOS001,REUSASID=YES"}} Using Jython: AdminConfig.modify(processDef ,'[[startCommandArgs ""]]') AdminConfig.modify(ProcessDef, '[[startCommandArgs "JOBNAME=BBOS0011,ENV=WAS00.NDN1.BBOS001,REUSASID=YES"]]') This update also applies to V8.0 and V9.0 -------- ID: 786202 Problem: The node metadata property of the managed node will not be updated at the deployment manager side by restarting the nodeagent if the dmgr is not running at that time. This would result in CWLCA0012E error when we try to change the java of the managed ndoe. The property update at the deployement manager side will occur when the nodeagent recognizes the running deployement manager. Topic, managesdk command, needs to indicate that the deployement manager needs to be running for property update to occur on the deployment manager side. Resolution: Topic, managesdk command, is updated. A current ATTENTION note will now read: If you use the managesdk command in a federated cell, and enable an SDK on a node, the SDK is not found by the command unless the node agent has been restarted while the deployment manager is running. This update also applies to V8.0 and V9.0. ------- ID: 253479 (RTC) Problem: Customer is running some scripts and login passwords contain exclamation point (!), which in a Windows environment are stripped off the character strings..... As a result, the scripts returned "null" and did not work. For the windows environment, the exclamation point needs to be escaped in the string to be preserved and not get stripped off. Resolution: Topic, Customizing the Liberty environment, is update. Replace the following NOTE bullet in this topic: - There are no escape characters; all characters are literal, including back-slashes and leading and trailing white space. WITH - All characters are literal except for "?" in Windows when it is used to escape a variable expansion character like the exclamation point. This update also applies to V9.0 ------- ID: 253484 (RTC) Problem: WSSubject description in this topic is inadequate. Liberty's WSSubject.getRootLoginException() is always returning null, where tWAS WSSubject.getRootloginException() is returning exception thrown from programmatic login. ----The Liberty topic needs more information about this exception. Resolution: Topic, Liberty:Security public APIs, is updated. The description: WSSubject This class provides utility methods for querying and setting the security thread context. All methods from the traditional WSSubject are supported in Liberty. IS REPLACED WITH WSSubject This class provides utility methods for querying and setting the security thread context. All methods from the traditional WSSubject are supported in Liberty except getRootLoginException(). In Liberty, you can look for login exceptions in the server logs and traces using the following trace specification: com.ibm.websphere.security.*=all:com.ibm.ws.security.*=all This update also applies to V9.0. ------ ID: 786747 Problem: Topic, Daemon Secure Sockets Layer, describes using WebSphere variables, but does not gives instructions on how to set these variables using the administrative console. These instructions need to be added to the topic. Resolution: Topic, Daemon Secure Sockets Layer, is updated with the following instructions for setting WebSphere variables using the administrative console: <*****> You set the cell-level WebSphere variables using the adminstrative console as follows: -Open the administrative console. -Expand the Environment drop-down list; click on the plus sign (+). -Click WebSphere variables. -Expand Scope; click on the plus sign (+). -Check the box that says --- Show scope selection drop-down list with the all scopes option. -Select the cell from the drop-down list to apply WebSphere variables. -Click the NEW button to add the WebSphere variables. <*****> This update also applies to V9.0. ------ ID: 786873 Problem: Need to document property, com.ibm.CORBA.ConnectionMultiplicity Resolution: Topic, Object Request Broker custom properties, is update with the property to read: com.ibm.CORBA.ConnectionMultiplicity Specifies the number of concurrent TCP connections between the client and server Object Request Brokers. The default for this property is 1. A value of 1 indicates that there will be at most only one connection between the client and each server ORB port. All the requests between the client and the server ORB will be multiplexed across those single connections. This can lead to a performance bottleneck in J2EE deployments where there are a large number of concurrent requests between the client and server ORBS. Setting this value to a number greater than one <n> causes the client ORB to multiplex communications to each server ORB port over <n> multiple connections rather than a single connection. There will be no more than <n> concurrent sockets to each separate server ORB port at any one time. This can increase throughput under certain circumstances, particularly on a long-running, mulch-threaded client process. Since the number of parallel connections will never exceed the number of requesting client threads, the number of concurrent client request threads is therefore a sensible maximum limit for this property. Important: ConnectionMultiplicity is a client side property and is not intended for use on the server ORB, unless the server ORB also acts as a client to another ORB. Side Effects Additional resources can be needed in both the client and server JVMs where CM >1. These resources can include additional elements such as: Reader threads for that connection on both the client and server File descriptors (for the socket) on both client and server CPU processing time in handling additional threads Heap/memory for additional threads Other Considerations Fine-tuning may be needed to balance increasing the desired throughput against the additional resources required Understand the server-side ramifications of increasing CM on clients, particularly if there is a large pool of clients. Increasing CM on a pool of clients can result in a marked increase of connections on the server(s). ORB connection cache settings. Increasing the ORB property com.ibm.CORBA.MaxOpenConnections on both clients and servers may be needed in order to prohibit thrashing (continual adding/deleting of connections) of the ORB connection table. Read the following article for best practices on tuning this property: http://www.ibm.com/support/docview.wss?uid=swg21669697 Information Value Valid Range 0-2147483647 Default 1 This update applies also to V9.0 ---- ID: PI94535 Problem: Topic, Installing and uninstalling SDK Java Technology Edition Version 7.0 or 7.1 on distributed operating systems, is in accurate in specifying for version 8.5.5.11, the default versions of Java are Java SE6 or Java SE8. Resolution: Topic, Installing and uninstalling SDK Java Technology Edition Version 7.0 or 7.1 on distributed operating systems, is updated to read: Note: Starting in version 8.5.5.11, the default versions of Java are Java SE6 or Java SE8. As such, you can accept the default and install either Java SE 6 or Java SE 8 as the version of Java SE contained in the /java and /java64 directories in WebSphere Application Server and used by default during server and node configuration. ------ <*** Additional issues are documented in CONTINUATION ****> <*** DOC APAR PH05192 ****>
Temporary fix
Comments
APAR Information
APAR number
PI94535
Reported component name
WEBSPHERE APP S
Reported component ID
5724J0800
Reported release
850
Status
CLOSED DOC
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2018-03-02
Closed date
2018-03-20
Last modified date
2018-11-13
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Applicable component levels
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.5","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
02 November 2021