How To
Summary
Step by step instructions to change the SDK level for servers and commands if they were previously set to either a non-bundled SDK level or an old bundled SDK version.
Objective
The preferred way to upgrade to the bundled version of the SDK after 8.5.5.14 and higher is to use setupProfileSDK.sh as described at
https://www.ibm.com/support/pages/node/794207
https://www.ibm.com/support/pages/node/794207
If this fails then this document describes how to use the managesdk script to accomplish the same goal.
Steps
Step by step instructions on how to change the SDK to the bundled Java 1.8 64-bit version for commands and servers
DeploymentManager is abbreviated with dmgr in the following instructions
1. Stop the cell completely
2. From the <dmgr_home>/bin (or <dmgr_home>/profiles/default/bin) directory issue the following commands to ensure that managesdk.sh will use the new default Java SDK:
export USE_COMMAND_OVERRIDE_SDK=true
export COMMAND_OVERRIDE_SDK=1.8_64_bundled
3. Next issue these commands
managesdk.sh -setCommandDefault -sdkName 1.8_64_bundled
managesdk.sh -enableProfile -sdkName 1.8_64_bundled -profileName default
The first command sets the SDK level to be used by commands and scripts under the dmgr directory.
The second command sets the SDK level to be used by the dmgr node.
To confirm the settings issue
managesdk.sh -listEnabledProfileAll -verbose
4. Start the DMGR
5. With the Nodes still down go to the <AppServer_home>/bin (or <AppServer_home>/profiles/default/bin) directory, and issue the following commands to ensure that managesdk.sh will use the new default Java SDK:
export USE_COMMAND_OVERRIDE_SDK=true
export COMMAND_OVERRIDE_SDK=1.8_64_bundled
managesdk.sh -setCommandDefault -sdkName 1.8_64_bundled
6. Manually synchronize the node with the dmgr:
Login to USS with the WebSphere administrative id.
This is to ensure the correct keyring and signer certificate are used for outbound SSL in syncNode.sh and managesdk.sh
This is to ensure the correct keyring and signer certificate are used for outbound SSL in syncNode.sh and managesdk.sh
Issue the following command to synchronize the node.
syncNode.sh <dmgr hostname> <dmgr port> -username <wsadmin_userid> -password <wsadmin_id_Password>
For a managed node, the managesdk -enableProfile command contacts the the deployment manager to make the change. Since the deployment manager does not yet "know" that the managed node has access to a new bundled SDK, you need to issue the syncNode.sh command to update the deployment manager's view of the managed node, before you can run the next command.
7. Issue the following command to set the node default SDK:
managesdk.sh -enableProfile -sdkName 1.8_64_bundled -profileName default -enableServers -username <wsadmin_userid> -password <wsadmin_id_Password>
To confirm the settings issue
managesdk.sh -listEnabledProfileAll -verbose
8. Start the Node agent
Repeat steps 5 - 8 for each Application Server node in the cell. Make sure that each node agent is still down before you run those steps.
Additional Information
More information can be found here:
1. IBM WebSphere Application Server for z/OS managesdk command
https://www.ibm.com/docs/en/was-zos/8.5.5?topic=tools-managesdk-command
2. Support Forum article on switching SDK levels for a cell
https://www.ibm.com/mysupport/s/question/0D50z00006VObDs/how-can-i-switch-an-existing-websphere-application-server-version-85-node-to-the-new-embedded-java-8
Note: If you run the commands as a superuser, make sure to check permission settings on the file systems, as pointed out in this section under (Attention) in the first link:
* If a root user runs the managesdk command against a non-root profile, non-root users might encounter a Permission denied error when they attempt to start the server or run the managesdk command. To resolve this error, reassign profile ownership to the non-root user. For more information, see Assigning profile ownership to a non-root user.
File changes
Here is a list of what files are changed by some of the managesdk commands, which we checked after you had issued the commands:
From <WAS_HOME>/Deploymentmanager/profiles/default/bin
managesdk.sh -setCommandDefault -sdkName 1.8_64_bundled
will update:
<WAS_HOME>/Deploymentmanager/properties/sdk/cmdDefaultSDK.properties
with
COMMAND_DEFAULT_SDK=1.8_64_bundled
------
managesdk.sh -enableProfile -sdkName 1.8_64_bundled -profileName default
will update:
<WAS_HOME>/profiles/default/bin/sdk/_setupSdk.sh
with
PROFILE_COMMAND_SDK=1.8_64_bundled
------
managesdk.sh -enableProfile -sdkName 1.8_64_bundled -profileName default -enableServers
This will create the variable JAVA_LOCATION_1.8_64_bundled at the Application Server Node scope to point to:
Environment -> WebSphere Variables -> Scope: Application Server Node .
JAVA_LOCATION_1.8_64_bundled=${WAS_INSTALL_ROOT}/java64"
and
JAVA_HOME=${JAVA_LOCATION_1.8_64_bundled}
NOTE: This does not change any JAVA_HOME variables if set at the node agent server scope, or application server scope.
If a server still sees the incorrect JVM, it may be that a server scoped JVM is taking precedence over the node scope change.
Document Location
Worldwide
[{"Type":"MASTER","Line of Business":{"code":"LOB67","label":"IT Automation \u0026 App Modernization"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SS7K4U","label":"WebSphere Application Server for z\/OS"},"ARM Category":[{"code":"a8m0z000000cwK5AAI","label":"WebSphere Application Server traditional-All Platforms-\u003EWebSphere z\/OS specific"}],"ARM Case Number":"","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"8.5.5"}]
Was this topic helpful?
Document Information
Modified date:
07 May 2024
UID
ibm16832934