APAR status
Closed as documentation error.
Error description
This APAR describes the issues that customers encountered with IBM WebSphere Application Server Version version_number. These issues were esolved as knowledge center updates in Jan., 2019
Local fix
N/A
Problem summary
**************************************************************** * USERS AFFECTED: This APAR provides a cumulative list of * * the documentation issues for January, 2019 * * that affect users of IBM WebSphere * * Application Server Version 9.0. * **************************************************************** * PROBLEM DESCRIPTION: The Knowledge Centers for WebSphere * * Application Server Version 9.0 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 9.0 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 9.0 issues will be addressed: ID: PH07693 and #552 (GHE) Problem: One of the PMI counter, PercentUsed, for threadPools is is not documented in the knowlege enter topic, Thread Pool Counters, and it should be documented. Resolution: Topic, Thread Pool Counters, is updated to add the PMI counter, Percent Used - and reads: Name: PercentUsed Key: threadPoolModule.percentUsed Description: The average percent of the pool that is in use. The value is based on the total number of configured threads in the ThreadPool and not the current pool size. Granularity: Per thread pool Type: BoundedRangeStatistic Level: All Overhead: High ID: 10 This update also applies to V855 level of the knowledge center. ------ ID: 790532 and #620 (GHE) Problem: Topic, Process execution settings, has a description of UMASK, which is strict in its description and has raised questions about whether other UMASK settings are possible and whether they can be successfully used. The UMASK description needs to add some clarification in the description. Resolution: Topic, Process execution settings, is updated. The second paragraph in the UMASK description now reads: BEST PRACTICES: To support system management functions, the deployment manager and application servers need to run with the stated UMASK default value (007 for z/OS and 022 for UNIX). You can change the default value of UMASK for the deployment manager and applications server(027 for UNIX), but this change can have unintended consequences for stack products, add-ons, non-IBM products, and legacy scripts and processes. This update also applies to V8.5 level of the knowledge center. --------- ID: #738 (GHE) Problem: Topic, JavaServer Faces, documents specific details related to the WebSphere Application Server JSF engine determines if the SUN RI or Apache MyFaces is used. This particular information is no longer applicable or useful in WebSphere Applicaton Server Version 9.0, because SUN RI is removed in that release. The SUN RI information needs to be removed from the knowledge center to avoid confusion. Resolution: Topic, JavaServer Faces, is updated as follows: Paragraph, For using different implementations of JSF, the WebSphere Application Server JSF engine determines if the SUN RI or Apache MyFaces is used from the application server run time. After the JSF engine determines the implementation that is used, the correct listener class is registered with the web container. You do not need to add the com.sun.faces.ConfigureListener or the org.apache.myfaces.StartupConfigureListener to the web.xml file. is changed to read: If an application uses the provided JSF MyFaces implementation, it does not need to add the org.apache.myfaces.webapp.StartupServletContextListener to its web.xml file. ------- ID: #1181 Problem: Customer needs to be able to define and customize the values of heartbeat and controller read time out, but nodejs does not have server.xml like a liberty member. The closest file to use is the json file called join.json that has some of the collective details and is used during the join process. The knowledge center is deficient in providing this information to the user. Resolution: Topic, apiconnect-collective-member wlpn-server and wlpn-collective commands, is updated with the following NOTE: NOTE:If you want to modify the heart beat interval in a nodeJS member, you need to add the following to the member's join.json file: { "hostName": "HOST_NAME", "userDir": "USER_DIR", "serverName": "SERVER_NAME", "keystorePassword": "PASSWORD", "controllerList": [ "https//controller_host:controller_https_port" ], "clusterName": "CLUSTER_NAME", "appPort": "9090", "adminPort": "9453", <b> "heartBeatInterval": "15"</b> } By default, the heartBeatInterval value defaults to 30 seconds (and is implicitly configured). After you have made an the adjustment above to the heartBeatInterval, restart the nodeJS member. ------- ID: #1198 (GHE) Problem: The server.start.wait.time property is explained in topic, Specifying Liberty bootstrap properties, but it is inaccurate and confusing. This can lead to errors in usage. Resolution: Topic, Specifying Liberty bootstrap properties, is updated. The section in this topic, Use custom properties to configure server start wait time, is updated. Item #1 is reworked to read as follows: ------- Specify the server.start.wait.time property in the bootstrap.properties file. The following example sets the server start time to 25 seconds. server.start.wait.time = 25 This setting defines how much time (in this example, 25 seconds) the start process can wait for the initiation of the main server process. NOTE: This property is not applicable when the server is started using the "server run" command. If you do not add the server.start.wait.time property to the bootstrap.properties file, the default server start wait time is internally set to 30 seconds. ------- ID: #1230 (GHE) Problem: Topic, Configuring LDAP user registries in Liberty, has a step 3: (optional) section that refers to sslAlias attribute, but this attribute does not exist and the correct attribute should be sslRef in this Step 3. Use of sslAlias will cause errors. Resolution: Topic, Configuring LDAP user registries in Liberty, is updated. Optional step #3 now reads: 3. Optional: Copy the truststore to the server configuration directory. For example, you can use the ${server.config.dir} variable. For SSL communication with an LDAP server to succeed, the Signer certificate for the LDAP server must be added to the truststore that is referenced by the sslRef attribute of the <ldapRegistry> element. In the following examples, the Signer certificate must be added to the LdapSSLTrustStore.jks. -----
Temporary fix
Comments
APAR Information
APAR number
PH07693
Reported component name
WEBSPHERE APP S
Reported component ID
5724J0800
Reported release
900
Status
CLOSED DOC
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2019-01-24
Closed date
2019-02-05
Last modified date
2019-04-12
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":"9.0","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
02 November 2021