TWS and WebSphere

by Pete Meechan

Starting with TWS 8.3 IBM introduced some major architectural changes to the Tivoli Workload Scheduler (TWS) for the distributed platforms. Amongst these changes was the introduction of WebSphere Application Server (WAS).

WAS is now installed as part of the standard installation of the TWS engine for the Master Domain Manager (MDM) and Backup Master Domain Manager (BMDM). This is commonly referred to within the TWS documentation as the “application server” or the “embedded application server (eWAS)”.

Another change introduced with TWS 8.3 and later versions is the web-based Tivoli Dynamic Workload Console (TDWC). Whilst TDWC is an optional component and an alternative to the java based Job Scheduling Console (JSC), the introduction of event based scheduling with TWS 8.4 and later, means that more customers are now looking to install the TDWC than with previous TWS versions. The TDWC also requires WAS, but depending upon the TWS version cannot use the eWAS installed as part of the MDM/BMDM.

To further complicate matters, the integration of WAS by TWS has evolved with each TWS version, resulting in changes to default installation paths and users, making it less than obvious at times which WAS instance needs to be used and with which user login. This article highlights the differences in the integration between TWS and WAS for the TWS versions 8.3, 8.4 and 8.5.

It should be noted that in large production TWS environments it is not recommended to install the TDWC on the MDM for performance reasons. However, in non-production environments this should not be a problem.

TWS 8.3

Common WebSphere (WAS) instance for TWS and TDWC No
Integrated start of WAS with TWS (conman) No

TWS eWAS Start and Stop Commands

The twsuser is the user used to install (execute) TWS, probably maestro or twsuser. $TWS_HOME is the installation directory, by default the home directory of twsuser (e.g. /home/maestro)

Start command (must be run as root user)

$TWS_HOME/StartUp -appsrv

or

$TWS_HOME/wastools/startWas.sh

Stop command (must be run as root user)

$TWS_HOME/wastools/stopWas.sh -user twsuser -password twsuser

To enable stopping of WAS without specifying user and password see later in the article.

TDWC Start and Stop Commands

The tdwcuser is the user used to install the TDWC WAS instance, by default this is iscadmin. $TDWC_HOME is the installation directory for the TDWC WAS instance, by default this is /opt/IBM/ISC on Linux

TDWC Start Command (must be run as root)

$TDWC_HOME/AppServer/bin/startServer.sh ISC_Portal -user tdwcuser -password tdwcuser

TDWC Stop Command (must be run as root)

$TDWC_HOME/AppServer/bin/startServer.sh ISC_Portal -user tdwcuser -password tdwcuser

To enable stopping of WAS without specifying user and password see later in the article.

TWS 8.4

In TWS 8.4 the eWAS is more integrated with TWS as it can now be started and stopped directly using conman, without needing access to root user. However, in times of troubleshooting it is useful to know where the eWAS is installed and the native WebSphere command for managing the application server. If the TDWC is installed on the MDM or BMDM, it requires a separate WAS instance as the eWAS is not compatible.

Common WebSphere (WAS) instance for TWS and TDWC No
Integrated start of WAS with TWS (conman) Yes

TWS eWAS Start, Stop and Status Commands

The twsuser is the user used to install (execute) TWS, probably maestro or twsuser. $TWS_HOME is the installation directory, by default the home directory of twsuser (e.g. /home/maestro)

Start command (run as twsuser user)

$TWS_HOME/StartUp -appsrv

or

conman startappserver

or

$TWS_HOME/wastools/startWas.sh

or (run as root user)

$TWS_HOME/appserver/bin/startServer.sh server1

Stop command (run as twsuser user)

conman stopappserver

or

$TWS_HOME/wastools/stopWas.sh

or

$TWS_HOME/appserver/bin/stopServer.sh server1 -user twsuser -password twsuser

Using the conman commands to start and stop WAS does not require specification of a user and password. To enable stopping of WAS using the WAS scripts without specifying user and password see later in the article.

Status command (run as twsuser user)

To check if the eWAS server is currently executing use the command below

$TWS_HOME/appserver/bin/serverStatus.sh server1 -user twsuser -password twsuser

TDWC Start, Stop and Status Commands

The tdwcuser is the user used to install the TDWC WAS instance, by default this is wasadmin. $TDWC_HOME is the installation directory specified for the TDWC WAS instance at TDWC installation, by default /opt/IBM/TDWC on Linux.

TDWC Start Command (must be run as root)

$TDWC_HOME/AppServer/bin/startServer.sh tdwcserver

TDWC Stop Command (must be run as root)

$TDWC_HOME/AppServer/bin/startServer.sh tdwcserver -user tdwcuser -password tdwcuser

To enable stopping of WAS without specifying user and password see later in the article.

TDWC Status command (must be run as root)

To check if the TDWC server is currently executing use the command below

$TDWC_HOME/AppServer/bin/serverStatus.sh stdwcserver -user tdwcuser -password tdwcuser

TWS 8.5 and above

In TWS 8.5 and above the eWAS and TDWC can now (optionally) use the same eWAS instance, which makes the management much simpler if the TDWC is installed on the MDM or BMDM. The instructions in this section are only applicable if both the TWS and TDWC use the same eWAS instance. For troubleshooting purposes it is still useful to know the native WebSphere commands for managing the eWAS instance.

Common WebSphere (WAS) instance for TWS and TDWC Yes
Integrated start of WAS with TWS (conman) Yes

TWS and TDWC eWAS Start, Stop and Status Commands

The twsuser is the user used to install (execute) TWS, probably maestro or twsuser. $TWS_HOME is the installation directory for TWS, by default this is /opt/ibm/TWA/TWS. $TDWC_HOME is the installation directory for TDWC, by default this is $TWS_HOME/../TDWC

Start command (run as twsuser user)

StartUp script now starts eWAS by default, if -appsrv is specified it is ignored.

$TWS_HOME/StartUp

or

conman startappserver

or

$TWS_HOME/../wastools/startWas.sh

or (run as root user)

$TWS_HOME/../eWAS/profiles/twaprofile/bin/startServer.sh twaserver

Stop command (run as twsuser user)

conman stopappserver

or

$TWS_HOME/../wastools/stopWas.sh

or (run as root user)

$TWS_HOME/../eWAS/profiles/twaprofile/bin/stopServer.sh twaserver -user twsuser
-password twsuser

Using the conman commands to start and stop eWAS does not require specification of a user and password. To enable stopping of eWAS using the eWAS scripts without specifying user and password see later in the article.

Status command (run as twsuser user)

To check if the eWAS server is currently executing use the command below

$TWS_HOME/../eWAS/profiles/twaprofile/bin/serverStatus.sh twaserver -user twsuser
-password twsuser

Configuring WAS instances to start and stop without specifying a user and password

The WebSphere instances need to have a user and password specified when certain actions are performed, usually when stopping or verifying the status of the application server. The IBM Redbook Getting Started with IBM Tivoli Workload Scheduler V8.3 (SG24-7237-00) provides a solution for achieving this for the TWS 8.3 embedded application server.

Using this same technique, it is possible to configure the TDWC instance of WAS in the same way. The most important consideration when making these configuration changes is to ensure that you are editing the files for the correct instance of WebSphere. Use the information in the previous sections of this article to determine the WebSphere instance that you want to configure.

To supress the requirement for user and password on the WebSphere scripts for starting, stopping, etc. you need to edit the properties file for the specific WebSphere instance. Using the path as determined by the previous sections of this article, change to the WAS instance properties directory. The table below lists the default directories based upon the TWS version and WAS function.

Version WAS Path to properties directory
8.3 embedded $TWS_HOME/appserver/profiles/twsprofile/properties
  TDWC $TDWC_HOME/AppServer/profiles/tdwcserver/properties
8.4 embedded $TWS_HOME/appserver/profiles/twsprofile/properties
  TDWC $TDWC_HOME/AppServer/profiles/tdwcserver/properties
8.5.x both $TWS_HOME/../eWAS/profiles/twaprofile/properties

Before starting this procedure, ensure that you have stopped the WebSphere instance using the appropriate command from the earlier sections.

From a shell command prompt, change into the WAS properties directory and make a backup of the files we are about to modify in case we encounter problems. Use the commands shown below to copy the files.

cp -p sas.client.props sas.client.props.original
cp -p soap.client.props soap.client.props.original

Edit the sas.client.props file using your favourite editor and locate the following lines in the file.

com.ibm.CORBA.loginSource=prompt
				
# RMI/IIOP user identity
com.ibm.CORBA.loginUserid=
com.ibm.CORBA.loginPassword=

Change the lines to the following, specifying the appropriate user (as identified in the earlier sections) and the password for that user. After completing the updates we will encrypt the password prior to it being used.

com.ibm.CORBA.loginSource=properties
				
# RMI/IIOP user identity
com.ibm.CORBA.loginUserid=twsuser
com.ibm.CORBA.loginPassword=orbdata

Save the changes to the file. Now open the file soap.client.props in your favourite editor and locate the lines shown below.

com.ibm.SOAP.securityEnabled=false
com.ibm.SOAP.loginUserid=
com.ibm.SOAP.loginPassword=

Change the lines to the following, specifying the appropriate user (as identified in the earlier sections) and the password for that user. After completing the updates we will encrypt the password prior to it being used.

com.ibm.SOAP.securityEnabled=false
com.ibm.SOAP.loginUserid=twsuser
com.ibm.SOAP.loginPassword=orbdata

Save the changes to the file. For TWS 8.5 the changes to the soap.client.props file were already present (with the password already encrypted).

Encrypting the password in the properties files

The method to encrypt the password in the properties files varies depending upon the WAS instance and the version of TWS being used. TWS supplies a utility script (encryptProfileProperties.sh) to encrypt the password fields of the properties files for the embedded WAS application server, but not for the TDWC WebSphere instance. Consequently, for the TDWC 8.3 or 8.4 the individual property files will need to be encrpyted using the command line WebSphere utility PropFilePasswordEncoder.sh. If you are using the common embedded eWAS instance for TWS and TDWC in 8.5 the encryptProfileProperties.sh script will be sufficient. If you have installed TDWC 8.5 in a separate WAS instance you will need to use the PropFilePasswordEncoder.sh script instead.

encryptProfileProperties.sh

The encryptProfileProperties.sh script can be found in the $TWS_HOME/wastools directory. The script must be executed as root user and does not require any parameters. It can be executed as shown below.

Version Command
8.3/8.4 $TWS_HOME/wastools/encryptProfileProperties.sh
8.5 $TWS_HOME/../wastools/encryptProfileProperties.sh

You will receive output similar to that shown below.


[ root@linkwood properties]# /opt/ibm/TWA/wastools/encryptProfileProperties.sh
NOTE: all specified passwords already encoded in target file
==
/opt/ibm/TWA/eWAS/profiles/twaprofile/properties/sas.stdclient.properties
NOTE: all specified passwords already encoded in target file ==
/opt/ibm/TWA/eWAS/profiles/twaprofile/properties/sas.tools.properties
[ root@linkwood properties]#

Make sure that the files listed are NOT the files you have just edited!

PropFilePasswordEncoder.sh

 

The PropFilePasswordEncoder.sh script can be found in the $TDWC_HOME/AppServer/bin directory. The script must be executed as root user once for each file containing a password to encrypt. It should be executed as shown below.

Version Command
8.3/8.4 $TDWC_HOME/AppServer/bin/PropFilePasswordEncoder.sh <path_to_properties_file>/soap.client.props com.ibm.SOAP.loginPassword
  $TDWC_HOME/AppServer/bin/PropFilePasswordEncoder.sh <path_to_properties_file>/sas.client.props -SAS
8.5.x $TDWC_HOME/../eWAS/bin/PropFilePasswordEncoder.sh <path_to_properties_file>/soap.client.props com.ibm.SOAP.loginPassword
  $TDWC_HOME/../eWAS/bin/PropFilePasswordEncoder.sh <path_to_properties_file>/sas.client.props -SAS

You will not receive any output from the command unless there is an error. If you receive output similar to that shown below, the password is already encrypted in the properties file. The command is wrapped over the first two lines!


[ root@linkwood properties]# /opt/ibm/TWA/eWAS/bin/PropFilePasswordEncoder.sh
soap.client.props com.ibm.SOAP.loginPassword
NOTE: all specified passwords already encoded in target file ==
/opt/ibm/TWA/eWAS/profiles/twaprofile/properties/soap.client.props
				

All of the above information was taken during testing for this article using TWS/TDWC versions 8.3, 8.4 and 8.5.x running on Linux x86 and x64.

Visits: 800