PI94535: 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 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 is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels