PH07946: RUNNING MANAGESDK ON A NODE WORKS BUT IT MODIFIES A JVM ON ANOTHER NODE

9.0.0.11: WebSphere Application Server traditional V9.0 Fix Pack 11
9.0.5.0: WebSphere Application Server traditional Version 9.0.5 Refresh Pack
9.0.5.1: WebSphere Application Server traditional Version 9.0.5 Fix Pack 1
9.0.5.2: WebSphere Application Server traditional Version 9.0.5 Fix Pack 2
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
9.0.5.3: WebSphere Application Server traditional Version 9.0.5 Fix Pack 3
8.5.5.20: WebSphere Application Server V8.5.5.20
8.5.5.18: WebSphere Application Server V8.5.5 Fix Pack 18
8.5.5.19: WebSphere Application Server V8.5.5 Fix Pack 19
8.5.5.16: WebSphere Application Server V8.5.5 Fix Pack 16
8.5.5.21: WebSphere Application Server V8.5.5.21

APAR status

• Closed as program error.

Error description

• Problem recreation steps:
  1. Set the app servers in the cluster to Java 8
  
  2. Confirm that you see variable
  JAVA_HOME=${JAVA_LOCATION_1.8_64} under the jvm's
  
  3. On one of the nodes, run this on just 1 of the
  servers/nodes/binaries: ./managesdk.sh -enableProfileAll
  -sdkName 1.8_64 -enableServers
  
  4. Check in dmgr log to see which files changed - expect to see
  updates to just nodes/jvms that exist under that set of
  binaries where you are running it, but I think you'll see that
  for jvm's that were already set to java 8 it modifies one of
  the other jvm's in the cluster on a different node.
  
  5. Check in console to see what version each of the JVM's in
  the cluster is now set to - would expect them both to still be
  at 8 since they were set to 8 before, but I think you'll find
  that the side that *wasn't* changed is now set to Java 7.
  
  6. Check the variables for the JVMs the JAVA_HOME location got
  removed out of the jvm on the node that wasn't supposed to
  change which reverted it back to the node default of java 7
  
  The systemOut.log shows when it was saved, we see the
  modification to the app server on lqa99n1s2 even though the
  command above says lqa99n1s1:
  [10/3/18 12:08:26:153 EDT] 000000c5 FileRepositor A  ADMR0016I:
  User OVDRealm/ovdwas modified document
  cells/lqa99/nodes/lqa99n1s1/variables.xml.
  
  [10/3/18 12:08:26:153 EDT] 000000c5 FileRepositor A  ADMR0016I:
  User OVDRealm/ovdwas modified document
  cells/lqa99/nodes/lqa99n1s2/servers/tenv3_mqr_lqa99/variables.xm
  l.
  
  [10/3/18 12:09:17:010 EDT] 000000ea FileRepositor A  ADMR0016I:
  User OVDRealm/lid8qqo modified document
  cells/lqa99/nodes/lqa99n1s2/servers/tenv3_mqr_lqa99/variables.xm
  l.
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server Network Deployment                   *
  ****************************************************************
  * PROBLEM DESCRIPTION: The AdminTask.setNodeDefaultSDK and     *
  *                      managesdk commands clear a              *
  *                      server-level SDK setting in the wrong   *
  *                      node.                                   *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  In a multi-node cell when a server name is used by two or
  more servers in different nodes,
  AdminTask.setNodeDefaultSDK() command with the
  "clearServerSDKs" option may clear a server-level SDK
  setting
  in an unspecified node. This also can happen while a
  managesdk command with the "enableServers" option is used to
  enable a SDK for a profile.
  

Problem conclusion

• Fixed the command implementation to prevent the server-level
  SDK setting being cleared for the wrong node.
  
  The fix for this APAR is currently targeted for inclusion in
  fix pack 8.5.5.16 and 9.0.5.0.  Please refer to the
  
  Recommended Updates page for delivery information:
  http://www.ibm.com/support/docview.wss?
  rs=180&uid=swg27004980
  

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

• Fixed component name

  WEBS APP SERV N

• Fixed component ID

  5724H8800

Applicable component levels

• R850 PSY

     UP