PH18892: CORRECTIONS ARE NEEDED TO THE DOCUMENTATION IN THE KNOWLEDGE CENTER FOR IBM WEBSPHERE APPLICATION SERVER VERSION 8.5

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 November, 2019.
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  This APAR provides a cumulative list of     *
  *                  the documentation issues for November 2019  *
  *                  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 skill              *
  *                      cases or 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 https://www.ibm.com/support/knowledgecenter/en 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: 2285 (GHE)
  Problem: The maximum amount of heap memory needs updating in
  topic, Configuring core group memory utilization.  In two
  places in this topic the maximum heap memory size is
  documented as 250MB, which is inaccurate.
  Resolution: Topic,Configuring core group memory utilization,
  is updated as follows:
  (1) In the Before you begin section: "The maximum value for
  this setting is 250 MB." is changed to read "The maximum
  value for this setting is the size of the java heap."
  
  (2) In the Procedure section: "The maximum value
  that can be specified for this setting is 250MB."  is
  changed to read: "The maximum value that can be specified for
  this setting is the size of the java heap."
  
  This update also applies to the V9.0.5 knowledge center.
  ---------------
  
  ID: #2318 (GHE)
  Problem: Topic, Cell custom properties, does not document the
  custom property,  IBM_CLUSTER_REUSE_ORIGINAL_IOR, and it
  should. The V9.0 level of this topic documents this property,
  but the V8.5 level of this topic does not.
  Resolution: Topic, Cell custom properties, is updated to
  include a description of IBM_CLUSTER_REUSE_ORIGINAL_IOR, which
  reads:
  IBM_CLUSTER_REUSE_ORIGINAL_IOR
  
  Specifies whether a Java(tm) thin client or server
  process can make continuous connection attempts until the
  cluster data is available to pass back to the client. The
  cluster data is then used for all future attempts.
  
  ------------|----------------------------------|
  Information    Value
  ------------|----------------------------------|
  Property       IBM_CLUSTER_REUSE_ORIGINAL_IOR
  ------------|----------------------------------|
  Data type      Boolean
  ------------|----------------------------------|
  Default        false
  ------------|----------------------------------|
  
  This ONLY applies to V8.5.5 level of the knowlege center
  
  
  -----------
  ID: 2355 (GHE)
  Problem: In a WebSphere Application Server for z/OS
  environment, preparing TCP/IP on z/OS can lead to potentially
  port conflict problems. Some ports, such as the ORB SSL port
  and the server startup status port, are obtained dynamically.
  We need to inform about how these dynamically configured ports
  can cause problems.
  Resolution: Topic, Preparing TCP/IP on z/OS, is updated to add
  a note concerning the potential for port conflicts.
  Specifically, a note is added to the task bullet:
  - Some ports, such as the ORB SSL port and the server startup
  status port, are obtained dynamically. -  which reads:
  
  NOTE: To prevent intermittent port clashes between dynamically
  allocated ports and those ports that are explicitly
  configured, consider adjusting your TCP/IP network. Modify the
  TCP/IP configuration port reservations that are not
  dynamically allocated in the WebSphere Application Server for
  z/OS cell address spaces.
  
  This update also applies to V9.0 level of the knowledge center.
  --------
  
  ID: #2353 (GHE)
  Problem: Topic, Monitoring overall system health, is missing
  some knowledge center information that should be included as
  related to scripting to log data for the Tivoli Performance
  Viewer and scripting to use the PerfServlet.  This information
  should be included in the topic.
  Resolution: Topic, Monitoring overall system health, is updated.
  Step 2 is expanded to read:
  Use Tivoli Performance Viewer or other performance monitoring
  and management solutions to monitor performance. These other
  solutions include wsadmin scripting, PerfServlet, IBM Tivoli
  Composite Application Manager for WebSphere Application
  Server, third-party performance monitoring and management
  tools, or your own monitoring applications.
  AND two subtopics are added:
  (1) Logging Tivoli Performance Viewer data by using scripting
  (2) Retrieving performance data with PerfServlet
  
  This update also applies to the V9.0 level of the knowledge
  center.
  --------
  
  ID: #2258 (GHE)
  Several topics have errors and need correction.
  (1) Topic, Object request broker troubleshooting tips
  (2) Topic, Enabling trace on client and stand-alone applications
  (3) Topic, Object Request Broker service settings
  
  Resolution:
  (1) Topic, Object request broker troubleshooting tips
  documents two components to ORB tracing
  ORBRas--general method tracing
  CommTrace  ORB communication data tracing
  (2) Topic, Enabling trace on client and stand-alone applications
  Under the subtopic, Using the TraceSettings.properties file,
  steps 3 and 4 are reworked to read:
  Step 3- Specify the trace spec string(s).
  Within the TraceSettings.properties file, specify a trace spec
  string similar to that available on the server (for example,
  WLM*=all). To trace multiple components, enter each individual
  trace string, one per line without any colons (:). For example,
  WLM*=all
  Naming=all
  Note ORB trace cannot be enabled through the
  TraceSettings.properties file. Instead add the following
  system properties to the client startup script or command line
  invocation:
  -Dcom.ibm.CORBA.Debug=true
  -Dcom.ibm.CORBA.CommTrace=true
  -Dcom.ibm.CORBA.Debug.Output=filename
  If enabling both ORB and WebSphere component trace (for
  example, Naming=all), ensure the filename specified in
  com.ibm.CORBA.Debug.Output is the same as that specified by
  the traceFileName property within the TraceSettings.properties
  file.
  
  Step 4 -Specify the TraceSettings.properties file and
  logManager
  properties on the command line.
  Add the following system properties to the startup script or
  command of the client application.
  -DtraceSettingsFile=filename
  -Djava.util.logging.manager=com.ibm.ws.bootstrap.WsLogManager
  -Djava.util.logging.configureByServer=true
  filename is the TraceSettings.properties file created in step
  #1.
  The java.util.logging.manager and
  java.util.logging.configureByServer system properties
  configure Java logging to use a WebSphere Application
  Server-specific LogManager class and to use the configuration
  from the file specified by the traceSettingsFile property. The
  default Java Logging properties file, located in the Java SE
  Runtime Environment, is not be applied.
  Example
  java -DtraceSettingsFile=MyTraceSettings.properties
  -Djava.util.logging.manager=com.ibm.ws.bootstrap.WsLogManager
  -Djava.util.logging.configureByServer=true
  -Dcom.ibm.CORBA.Debug=true
  -Dcom.ibm.CORBA.CommTrace=true
  -Dcom.ibm.CORBA.Debug.Output=c:\\MyTraceFile.log
  com.ibm.samples.MyClientProgram
  
  (3) Object Request Broker service settings is updated. Under
  the section ORB tracing, the short description now reads:
  Enables the tracing of ORB General Inter-ORB Protocol (GIOP)
  messages that includes both ORBRas=all trace and ORB
  CommTrace. A note is added that reads:
  NOTE: This setting requires a server restart.
  
  This update also applies to V9.0 level of the knowledge center.
  ------
  
  ID: #2212 (GHE)
  Problem: The knowledge center should provide information about
  how to manage core group with scripting
  Resolution: A new topic is added to the knowledge center,
  Scripting to manage preferred coordinators in a core group
  and reads:
  You can define an ordered list of preferred core group servers
  and manage that list to optimize how best the high
  availability manager coordinators will run. Also, you can use
  the administrative console or use scripting to manage
  preferred coordinators in a core group
  About this task
  Use the wsadmin tool and the Jython scripting language with
  the AdminConfig object to manage preferred coordinators in a
  core group.
  Procedure
  
  1)  Log into the administrative console.
  2)  From the administrative console page, click Servers >
  Core
  Groups > Core group settings > New, or select an existing core
  group, and then click Preferred coordinator servers.
  3)  Use Add and Remove to move servers into and out of the
  list of core group servers on which coordinator service will
  run. Use Move up and Move down to adjust the order within this
  list. Make sure that the most preferred server is at the top
  of the list and the least preferred server is at the bottom.
      To accomplish a similar result using scripting, see the
  following Jython script sample:
  
      #Get and assign the defaultCoreGroup name
      wsadmin>defaultCoreGroup =
  AdminTask.getDefaultCoreGroupName()
      #
      #Assign the path to the core group in which preferred
  coordinators
      #will be assigned
      wsadmin>core =
  AdminConfig.getid("/Cell:<cell_name>/CoreGroup:" +
  defaultCoreGroup + "/")
      #
      #Assign the id of the server to use as a preferred
  coordinator
      wsadmin>serverCoreID =
  AdminConfig.getid("/CoreGroupServer:<server_name>/")
      #
      #Assign preferred corrdinators to the core group
      wsadmin>AdminConfig.modify( core,
  [['preferredCoordinatorServers', serverCoreID]])
      #
      # Save to Master Repository.
      wsadmin>AdminConfig.save()
      #
      # Sync all active nodes
      wsadmin>AdminNodeManagement.syncActiveNodes()
  
  This update also applies to the V9.0 knowledge center
  

Temporary fix

Comments

APAR Information

• 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