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

APAR status

• Closed as documentation error.

Error description

• This APAR describes the issues that customers encountered with
  IBM WebSphere Application Server Version 9.0.5. These issues
  were resolved as knowledge center updates in August, 2019.
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  This APAR provides a cumulative list of     *
  *                  the documentation issues for August 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.
  APAR responder text: Problem conclusion
  

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 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 9.0 issues will be addressed:
  
  ID: #1782 (GHE)
  Problem: With the addition of non-persistent timer and
  asynchronous method support to the embeddable container in v9,
  this is behaving as we would expect. Per the EJB spec (EJB 3.2
  section 18.2.4), this work is only canceled upon shutdown of
  the embeddable container either explicitly through a call to
  close() or implicitly by using a try-with-resources statement
  when acquiring the container instance. If using close(), as in
  the customer's example, it is best to put this in a finally
  block to ensure that the container is always properly shut
  down even if an exception is encountered.
  Resolution: Three examples in topic, Developing applications
  using the embeddable EJB container, will be updated so there
  is a try statement after the call to createEJBContainer() and
  a finally block for the call to ec.close().
  Example 1 in step 2:
  //EmbeddableContainerSample.java
  import java.util.HashMap;
  import java.util.Map;
  import javax.ejb.embeddable.EJBContainer;
  import my.pkg.MyBeanIface; // this is the local business
  interface of the
                             // enterprise bean
  public class EmbeddableContainerSample {
     public static void main(String[] args) throws Throwable {
        // Create a properties map to pass to the embeddable
  container:
        Map<String,Object> properties = new
  HashMap<String,Object>();
        // Specify that you want to use the WebSphere embeddable
  container:
        properties.put(EJBContainer.PROVIDER,
  "com.ibm.websphere.ejbcontainer.EmbeddableContainerProvider");
        // Create the container instance, passing it the
  properties map:
        EJBContainer ec =
  EJBContainer.createEJBContainer(properties);
        try {
           // Use the container context to look up a bean:
           MyBeanIface bean = ec.getContext().lookup(
  "java:global/MyEJBModule/MyBean!my.pkg.MyBeanIface");
           // Invoke a method on the bean instance:
           bean.doStuff();
            ...
        } finally {
           // Close the embeddable container:
           ec.close();
        }
  }
  Example 2 in step 5:
  import java.util.HashMap;
  import java.util.Map;
  import javax.ejb.EJBContainer;
  import my.pkg.MyBeanIface; // this is the local business
  interface of the
                             // enterprise bean
  public class EmbeddableContainerSample {
  
     public static void main(String[] args) throws Throwable {
        // Create a properties map to pass to the embeddable
  container:
        Map<String,Object> properties = new
  HashMap<String,Object>();
        // Specify that you want to use the WebSphere embeddable
  container:
        properties.put(EJBContainer.PROVIDER,
  "com.ibm.websphere.ejbcontainer.EmbeddableContainerProvider");
        // Specify that you want security checking enabled:
        properties.put("com.ibm.websphere.securityEnabled",
  "true");
        // Assign the users bob, fred, and mary to the role
  employee:
        props.put("role.employee", "bob, fred, mary");
        // Assign the user fred to the role manager:
        props.put("role.manager", "fred");
        // The user fred will be used for the runAs role manager:
        props.put("role.runAs.manager", "fred");
        // The user fred will be used for role authorization
  when invoking
        // methods on the EJB:
        props.put("user.invocation", "fred");
        // Create the container instance, passing it the
  properties map:
        EJBContainer ec =
  EJBContainer.createEJBContainer(properties);
        try {
           // Use the container context to look up a bean:
           MyBeanIface bean = ec.getContext().lookup(
  "java:global/MyEJBModule/MyBean!my.pkg.MyBeanIface");
           // Invoke a method on the bean instance:
           bean.doStuff();
           ...
        } finally {
           // Close the embeddable container:
           ec.close();
        }
  }
  Example 3 in step 6:
  import java.util.HashMap;
  import java.util.Map;
  import javax.ejb.EJBContainer;
  import my.pkg.MyBeanIface; // this is the local business
  interface
                             // of the enterprise bean
   public class EmbeddableContainerSample {
     public static void main(String[] args) throws Throwable {
        // Create a properties map to pass to the embeddable
  container:
        Map<String,Object> properties = new
  HashMap<String,Object>();
        // Specify that you want to use the WebSphere embeddable
  container:
        properties.put(EJBContainer.PROVIDER,
  
  "com.ibm.websphere.ejbcontainer.EmbeddableContainerProvider");
        // Specify that you want the LTC resolver
  container-at-boundary:
  properties.put("Bean.myApp1#moduleA#bean101.LocalTransaction.Res
  olver",
  "ContainerAtBoundary");
        // Specify that you want the LTC unresolved action commit:
  properties.put("Bean.myApp1#moduleA#bean101.LocalTransaction.Unr
  esolvedAction",
                                                        "Commit");
        // Create the container instance, passing it the
  properties map:
        EJBContainer ec =
  EJBContainer.createEJBContainer(properties);
  
        try {
           // Use the container context to look up a bean:
           MyBeanIface bean = ec.getContext().lookup(
  "java:global/MyEJBModule/MyBean!my.pkg.MyBeanIface");
           // Invoke a method on the bean instance:
           bean.doStuff();
           ...
        } finally {
           // Close the embeddable container:
           ec.close();
        }
  }
  ---------------
  ID: #1767 (GHE)
  Problem: Customer upgraded to WAS v9 Fixpack 3 and Java
  v8.0-5.35. When new provisioning workflow started, a failure
  occurred in the step that runs zpmt. The reason is that it
  cannot find java: ERROR:  zpmt.sh command failed with return
  code 127 /B0/usr/lpp/zWebSphere/V9R0/java/8.0/jre/bin/java:
  /usr/lpp/zWebSphere/V9R0/bin/zpmt.sh 395: FSUM7351 not found
  This was because the unmask caused the
  /[WAS-install-dir]/V9R0/java directory to have permission bits
  740 instead 0f 775.
  Resolution: Topic, Installing WebSphere Application Server for
  z/OS, is updated. A note that identified " For
  transitioning users" is changed to "Important" and expanded
  by adding a second paragraph.  The entire note reads:
  IMPORTANT:
  IBM SDK, Java ? ?   ? ? Technology Edition, Version 8 is the Jav
  version for WebSphere Application Server Version 9.0. However,
  IBM SDK, Java Technology Edition is no longer embedded with
  any WebSphere Application Server offerings. The Java SDK is
  available as a separate offering that must be installed when
  you install the product.
  
  Installation of IBM SDK, Java Technology Edition, recognizes
  the current setting of the file permissions mask (umask). If
  umask is set to disallow world read access (for example, with
  a umask setting of 007), the installed Java SDK files are not
  world readable. Instead, install the IBM Java SDK with umask
  setting of 002 (for a group-mode Installation Manager) or 022
  (for an admin-mode or user-mode Installation Manager) so that
  the resulting Java files are world-readable.
  ----------
  ID: #1847 (GHE)
  Problem: During the migration process, some configuration
  elements in source might be adjusted so that the target has a
  possibility to have a different value. The migration code
  issues a message to inform user of the change. The
  documentation needs to explain this adjustment.
  
  Resolution: Topic, Troubleshooting migration, is updated. The
  following note will be placed in the second bullet of the
  procedure, within sub-bullet 1.
  
  ATTENTION: In general, the migration process brings over to
  the target version the values for all configuration elements
  that exist in both versions. However, the migration process
  does adjust some configuration element values in cases where
  the older version value is known to cause issues in the target
  version environment. For each value adjustment made, the
  migration process issues a message to the migration log
  indicating what setting is changed and why the change was made.
  ----------
  ID: #1767 (GHE)
  Problem: upgrading to WAS v9 Fixpack 3 and Java v8.0-5.35.
  When starting a new provisioning workflow, failure occurs
  in the step that runs zpmt. Cannot find java: ERROR:
  This was because the unmask caused the
  /[WAS-install-dir]/V9R0/java directory to have permission bits
  740 instead 0f 775.
  Resolution: Topic, Installing WebSphere Application Server for
  z/OS, is updated.  The About this Task section has a note that
  is updated to read:
  <Important>
  IBM SDK, Java ? &#187;   &#162; ? Technology Edition, Version 8 is the Jav
  version for WebSphere Application Server Version 9.0. However,
  IBM SDK, Java Technology Edition is no longer embedded with
  any WebSphere Application Server offerings. The Java SDK is
  available as a separate offering that must be installed when
  you install the product.
  
  Installation of IBM SDK, Java Technology Edition, recognizes
  the current setting of the file permissions mask (umask). If
  umask is set to disallow world read access (for example, with
  a umask setting of 007), the installed Java SDK files are not
  world readable. Instead, install the IBM Java SDK with umask
  setting of 002 (for a group-mode Installation Manager) or 022
  (for an admin-mode or user-mode Installation Manager) so that
  the resulting Java files are world-readable.
  ------
  ID: 1699 (GHE)
  Problem: Opening paragraph of Topic, Server Name Indication,
  is inaccurate and misleading.
  Resolution: Opening paragraph of Topic, Server Name
  Indication, reads:
  You can configure a separate certificate label with Server
  Name Indication (SNI) support for IBM HTTP Server, based on
  the hostname requested by the client. The configuration can be
  done either by defining name-based SSL virtual hosts or by
  using the SSLSNIMap directive. You cannot use other
  handshake-related settings from a name-based virtual host with
  SNI.
  and third bullet in section, requirements for SNI now reads:
  Non-default virtual hosts for a name-based virtual host must
  not contain directives from this module other than
  SSLServerCert and SSLEnable directives.
  ---------
  

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