WebSphere Services Registry and Repository V6.

Configuring WSRR on Linux for zSeries Utilizing DB2 on z/OS

This document can be found on the web at: www.ibm.com/support/techdocs Search for document number WP101567 under the category of "White Papers"

Version Date: October 12, 2009

See "Document Change History" on page 21 for a description of the changes in this version of the document

Paul Houde Advanced Technical Support phoude@us.ibm.com

WP101567 Configuring WSRR on Linux for zSeries

Many thanks to Nicole Hargrove, David Roberts, Chris Dudley, and Tony Duong for all of their guidance in the development of this document. For questions or comments regarding this document, send email to Paul Houde at phoude@us.ibm.com

2009, IBM Washington Systems Center Americas Advanced Technical Support

-2-

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries

Table of Contents
Linux and WebSphere Environment Prior to WSRR ......................................................................... 4 Software and Hardware Requirements................................................................................................ 4 Architecture ......................................................................................................................................... 4 Installing Base Code............................................................................................................................ 5 Obtain the WSRR Code ...................................................................................................................... 5 Running the Install Script..................................................................................................................... 5 Creating Database Objects in DB2 for z/OS....................................................................................... 7 Create the DDL ................................................................................................................................... 7 Run the DDL........................................................................................................................................ 7 Customizing wsrrdeployment.properties........................................................................................... 9 Sample Properties File With Explanations ........................................................................................... 9 Running The installall.sh Configuration Script ............................................................................... 17 Install Verification and Solutions to Common Issues ..................................................................... 18 Document Change History................................................................................................................ 21

2009, IBM Washington Systems Center Americas Advanced Technical Support

-3-

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries

Linux and WebSphere Environment Prior to WSRR

WebSphere Service Registry and Repository (WSRR) is an application that runs on top of WebSphere Application Server (WAS). Since WSRR requires WAS, the WAS environment must be configured before the installation of WSRR can begin. Software and Hardware Requirements For the latest required levels of operating system, application server and database management system, please refer to the link below. This URL also provides the hardware and disk space requirements to run WSRR on Linux for zSeries. http://www-01.ibm.com/support/docview.wss?rs=3163&uid=swg27015640 Architecture In our sandbox environment, we wanted to create an environment that would best reflect the architecture of a production WSRR environment. In order to replicate this type of setup, the WebSphere Application Server Network Deployment software was used. A deployment manager was built on the first Linux image that is used to manage additional nodes that are running on separate Linux images. Once the deployment manager was constructed, two additional nodes were created on two separate Linux images. The nodes were subsequently federated into the deployment manager running on the first Linux image. After federating all the nodes that were to be used for running WSRR, a cluster of application servers was built. The cluster was built to create a level of high availability that would be used in a production environment.

Linux 1 Deployment Manager

Linux 2 Application Server Nodeagent Cluster

Nodes federated into dmgr

Linux 3 Application Server Nodeagent

2009, IBM Washington Systems Center Americas Advanced Technical Support

-4-

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries

Installing Base Code

Now that the WebSphere Application Server environment has been setup, WebSphere Service Registry and Repository can now be deployed to the WAS cluster. Obtain the WSRR Code The IBM product number for WebSphere Service Registry Repository version 6.3 is CZ28IML. WebSphere Servcie Registry and Repository V6.3 for Linux on zSeries Multilingual (CZ28IML) Once CZ28IML.tar is obtained, FTP/SCP it to the Linux on zSeries image that the deployment manager is running on. The WSRR code must be installed on the deployment manager system when running in a Network Deployment environment. Attempting to install the WSRR code individually on any of the federated nodes will cause the installation to fail. Running the Install Script After the WSRR download (CZ28IML) has been downloaded and expanded (tar xvf CZ28IML.tar), the WSRR install script will be available to run. The install script is one of the expanded files called WSRRServer_linux_390.bin. The GUI wizard for the WSRR installer is not currently supported on Linux for zSeries as of the creation of this document. Instead, the installer utilizes the text based, console mode installer. Console mode offers the same prompts as the GUI installation wizard so the process of installation is exactly the same. Start up the console based installer by running WSRRServer_linux_390.bin from the directory where the install code was expanded. The first screen prompts the user for the language the installer should be run in. We chose English. The next prompt brings up the license agreement. Accept the license agreement to continue.
==================================================================== Launching installer... Graphical installers are not supported by the VM. The console mode will be used instead... Preparing CONSOLE Mode Installation... ==================================================================== Choose Locale... ---------------1->23456Deutsch English Espaol Franais Italiano Portugus

(Brasil)

CHOOSE LOCALE BY NUMBER: 2 ====================================================================

2009, IBM Washington Systems Center Americas Advanced Technical Support

-5-

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries

After accepting the license agreement, the installer prompts for install location for WSRR. The default location for the WSRR code is /opt/IBM/WebSphere/ServiceRegistry but this can be overridden. To accept the default location, just press enter. To override the default install path, enter the custom path on the command line and then hit enter. A path relative to the current directory cannot be used. Custom paths must be the full path name from the root.
==================================================================== Choose Install Folder --------------------Please choose a destination folder for this installation. Where would you like to install? Default Install Folder: /opt/IBM/WebSphere/ServiceRegistry ENTER AN ABSOLUTE PATH, OR PRESS <ENTER> TO ACCEPT THE DEFAULT : ====================================================================

2009, IBM Washington Systems Center Americas Advanced Technical Support

-6-

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries

Creating Database Objects in DB2 for z/OS

Setting up DB2 on z/OS as a back end database for use with WebSphere Service Registry and Repository is slightly different that using DB2 on distributed platforms. The GUI installer and installall.sh scripts do not create the database objects automatically on DB2 for z/OS. They have to be created manually instead. Create the DDL The first step in creating the database objects for WSRR is to generate the necessary data definition language (DDL). A script is provided with the WSRR code that customizes the DDL for the specifics of the DB2 its running on. The script is called genddl.sh and can be found in /opt/IBM/WebSphere/ServiceRegistry/install/database/sql/db2_zos. The final directory in the path (db2_zos), did not exist in 6.3.0 of WSRR. At the time, the directory had to be sent separately by development. The development team opened a defect in order to fix this error. Genddl.sh can be passed a variety of parameters that are used to customize the DDL that gets created. During the creation of our sandbox environment, the parameters we passed were: ./genddl.sh -ddl-path /opt/IBM/WebSphere/ServiceRegistry/install/ddl -wsrr-db-sqlid valid_sqlid -wsrr-db-user valid_RACF_ID -sib-db-user valid_RACF_ID -schd-db-user valid_RACF_ID The ddl-path is the directory on Linux for zSeries where the customized DDL files will be copied to. A few parameters allow you to pass IDs that are used for DB2 object ownership. wsrr-dbsqlid, wsrr-db-user, sib-db-user, schd-db-user can all be the same ID if three databases used by WSRR should be owned by the same ID. No database names were specified so the defaults are taken. When the defaults are used, the database names are WSRR630 (WSRR database), WSRR630A (Activity logging database) and WSRR630B (Service integration bus and scheduler database). For a full list of genddl.sh parms, refer to the WSRR Infocenter located at: http://publib.boulder.ibm.com/infocenter/sr/v6r3/index.jsp?topic=/com.ibm.sr.zos.doc/twsr_zos_ activating_dbs.html If the resulting DDL does not fit the requirements of the DB2 that it will be run on, the DDL can be either generated again by passing genddl.sh different parameters or by editing the DDL manually. After the script runs, six DDL files are created which all must be run on the target DB2 for z/OS. The location of these files depend on the value given to ddl-path when running the genddl.sh script. The six DDL files are: createact.sql, createdbact.sql createdbsib.sql createdbts.sql createsched.sql createsib.sql

Run the DDL Now that the DDL has been customized, it can be sent over to the z/OS LPAR that DB2 is running on. The six files can be sent by whatever method your z/OS LPAR supports (FTP, SCP, PCOMM file transfer, etc). If a Windows based PC is being used as an intermediary transfer point for the
2009, IBM Washington Systems Center Americas Advanced Technical Support

-7-

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries

files, make sure they are transferred in ASCII format from the Linux on zSeries image to the Windows based PC. Once the six DDL files are on the z/OS LPAR, the DDL can be run through SPUFI or in batch using DSNTEP2. Running the DDL in batch can be particularly useful for some of the larger DDL jobs. A sample DSNTEP2 job has been provided below. The parameters in blue will have to be customized for the LPAR that the job is running on. The DDL that is part of the files sent to the LPAR is placed at the end of the job. Sample DSNTEP2 Batch Job
//YOUR JOBCARD //JOBLIB DD DISP=SHR,DSN=HLQ.SDSNLOAD // DD DISP=SHR,DSN=HLQ.SDSNEXIT //* //STEP10 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(SSID) RUN PROGRAM(DSNTEP2) PLAN(DSNTEP91) LIB('HLQ.RUNLIB.LOAD') //SYSIN DD * PLACE YOUR DDL HERE

2009, IBM Washington Systems Center Americas Advanced Technical Support

-8-

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries

Customizing wsrrdeployment.properties
The primary location for storing the values that are used for configuring WSRR is a file called wsrrdeployment.properties. This file contains information about all aspects of the WSRR configuration such as database information (DB2, Oracle or SQL Server), WAS cell information and various other deployment options. The wsrrdeployment.properties file is located in /opt/IBM/WebSphere/ServiceRegistry/install (may be different if you overwrote the default install location) Sample Properties File With Explanations Editing the wsrrdeployment.properties file is a fairly straightforward process but there are a few parameters that can cause the installer to trip up. In order to clarify how to fill in the values that make up the wsrrdeployment.properties correctly, a sample file has been included below. This sample file includes extended descriptions of the parameters that have caused people to have issues running the installall.sh script. In order to differentiate the extended comments from the comments provided with the file, the extended comments have been entered in red.
############################## # WSRR Deployment Properties # ############################## # ***************************************************************************** # * Database Installation Information * # ***************************************************************************** # # # # # Database type If the database is on Windows or UNIX then the possible values are: db2v9, db2v8, sqlserver, oracle10g, oracle11g or cloudscape If the database is on z/OS then the possible choices are: db2v8zos or db2v9zos

db.type=db2v9zos The db.type value is very self explanatory. Use db2v9zos if you are running DB2 version 9 on z/OS and db2v8zos for version 8.

# WSRR Database name # For Cloudscape this should be the full path to the database directory # e.g. c:/program files/websphere/appserver/derby/databases/WSRR # For other databases it should just be the name of the database # e.g. WSRR # For DB2 for z/OS it should be the the location name of the DB2 subsystem DDF wsrr.db.name=WSCDBP0 The DB2 location name can be found in the DB2 master address space. Go into SDSF and browse the DB2MSTR address space. The master address space name will vary depending on the environment. It is best to do a prefix on *MSTR in SDSF to find the DB2 master address space. Search on DDF START once inside the address space. A section like the example below should be displayed. Use the LOCATION shown here as the value for wsrr.db.name. -DBP1 DDF START COMPLETE 082 LOCATION WSCDBP0
-9ibm.com/support/techdocs Version Date: Monday, October 12, 2009

2009, IBM Washington Systems Center Americas Advanced Technical Support

WP101567 Configuring WSRR on Linux for zSeries LU GENERICLU DOMAIN TCPPORT SECPORT RESPORT IPNAME USIBMWZ.WSCDB2A1 USIBMWZ.WSCDBP0 wsc1 446 448 5021 -NONE

# WSRR Database username wsrr.db.user=DNET564 This is the ID that will be used on the J2C authentication entry in WAS to access the data source. All connections from WAS/WSRR to DB2 on z/OS will use this ID. Make sure the ID is valid and has authority to the DB2 objects that were defined for WSRR.

# WSRR Database Hostname wsrr.db.hostname=zserveros.demos.ibm.com Set this value to the host name of the LPAR that DB2 is running on. .

# SIBus Database name # For Cloudscape this should be the full path to the database directory # e.g. c:/program files/websphere/appserver/derby/databases/WSRR # For other databases it should just be the name of the database # e.g. WSRR # For DB2 for z/OS it should be the the location name of the DB2 subsystem DDF sib.db.name=${wsrr.db.name} In most cases, all three databases defined for WSRR will reside in the same DB2 subsystem. If this is the case, then it is best to leave sib.db.name set to ${wsrr.db.name}. If the service integration bus database resides in a different DB2 subsystem, then set this value to the DB2 location name of that separate DB2 subsystem.

# SIBus Database username sib.db.user=${wsrr.db.user} This only needs to be changed from the default if the service integration bus database resides on a separate DB2 subsystem from the WSRR database. If it does reside on a separate DB2 subsystem, remember that this is the ID that will be used on the J2C authentication entry in WAS to access the data source. All connections from WAS/WSRR to DB2 on z/OS will use this ID. Make sure the ID is valid and has authority to the DB2 objects that were defined for the service integration bus database.

# SIBus Database Hostname sib.db.hostname=${wsrr.db.hostname} This only needs to be changed from the default if the service integration bus database resides on a separate DB2 subsystem from the WSRR database. If it does, set this value to the host name of the LPAR that DB2 is running on. Activity Logging Database name For Cloudscape this should be the full path to the database directory e.g. c:/program files/websphere/appserver/derby/databases/WSRR For other databases it should just be the name of the database e.g. WSRR
- 10 ibm.com/support/techdocs Version Date: Monday, October 12, 2009

# # # # #

2009, IBM Washington Systems Center Americas Advanced Technical Support

WP101567 Configuring WSRR on Linux for zSeries # For DB2 for z/OS it should be the the location name of the DB2 subsystem DDF act.db.name=${wsrr.db.name} In most cases, all three databases defined for WSRR will reside in the same DB2 subsystem. If this is the case, then it is best to leave act.db.name set to ${wsrr.db.name}. If the activity logging database resides in a different DB2 subsystem, then set this value to the DB2 location name of that separate DB2 subsystem.

# Activity Logging Database username act.db.user=${wsrr.db.user} This only needs to be changed from the default if the activity logging database resides on a separate DB2 subsystem from the WSRR database. If it does reside on a separate DB2 subsystem, remember that this is the ID that will be used on the J2C authentication entry in WAS to access the data source. All connections from WAS/WSRR to DB2 on z/OS will use this ID. Make sure the ID is valid and has authority to the DB2 objects that were defined for the activity logging database.

# Activity Logging Database Hostname act.db.hostname=${wsrr.db.hostname} This only needs to be changed from the default if the activity logging database resides on a separate DB2 subsystem from the WSRR database. If it does, set this value to the host name of the LPAR that DB2 is running on.

# Skip Database configuration # Set this to false if you have created the database manually already. # This will then assume the database exists and has all tables and # tablespaces correctly configured. # On z/OS, the database is always created manually, but configdb=false # some of the database parameters. configdb=false This should always be set to false when utilizing DB2 on z/OS since the DB2 objects have already been created there. Setting this to true will cause the installall.sh script to fail.

# Skip WebSphere configuration # Set this to false if you do not want to configure WebSphere Application Server # at this time. configwas=true Set this to true to configure WAS for use with WSRR

# To just configure the database set configdb=false # To just configure WAS set configdb=false # To both configure the database locally and configure WAS set configdb=false # ***************************************************************************** # * DB2-Specific Database Installation Information * # ***************************************************************************** # DB2 Install directory #db2.home=c:/Program Files/IBM/SQLLIB db2.home=/usr/lpp/db2/db2910/db2910_jdbc/

2009, IBM Washington Systems Center Americas Advanced Technical Support

- 11 -

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries The installer should ignore the db2.home parameter when using DB2 on zOS but did not as of WSRR 6.3.0. The directory structure had to be created on the Linux for zSeries image to trick the installall.sh script into bypassing this parameter. WSRR development is currently working on a fix for this that will be available with upcoming maintenance.

# DB2 Port db2.port=5446 The DB2 TCP/IP port can be found in the DB2 master address space. Go into SDSF and browse the DB2MSTR address space. The master address space name will vary depending on the environment. It is best to do a prefix on *MSTR in SDSF to find the proper address space. Search on DDF START once inside the address space. A section like the example below should be displayed. Use the TCPPORT shown here as the value for db2.port. -DBP1 DDF START COMPLETE 082 LOCATION WSCDBP0 LU USIBMWZ.WSCDB2A1 GENERICLU USIBMWZ.WSCDBP0 DOMAIN wsc1 TCPPORT 446 SECPORT 448 RESPORT 5021 IPNAME -NONE

# DB2 Tablespace directory # Not used on z/OS #db2.tsdir=c:/DB2TS db2.tsdir=${db2.instancehome}/DB2TS Ignore for DB2 on z/OS

# DB2 Instance name - only needed for UNIX # Not used on z/OS db2.instance=db2inst1 Ignore for DB2 on z/OS

# Database Instance username - only needed for UNIX # Not used on z/OS db2.instid=db2inst1 Ignore for DB2 on z/OS

# DB2 Instance home directory - only needed for UNIX # Not used on z/OS db2.instancehome=/home/${db2.instid} Ignore for DB2 on z/OS

# WAS SIBus schema name # This is the schema name for the WAS SIBus message store tables # Leave set to the default unless you require a specific schema name # Not used on DB2 for z/OS, use wsrr.db.schema below was.sibschema=DNET564
2009, IBM Washington Systems Center Americas Advanced Technical Support ibm.com/support/techdocs Version Date: Monday, October 12, 2009

- 12 -

WP101567 Configuring WSRR on Linux for zSeries Although the comments state otherwise, was.sibschema actually does get used on z/OS. If installing WSRR 6.3.0, specify a schema name here. It is often set to be the same as the wsrr.db.user. Development has opened a defect to have the comments and Infocenter changed.

# ***************************************************************************** # * z/OS DB2-Specific Database Installation Information * # ***************************************************************************** # Database Schema name - only used for z/OS databases # defaults to the database username wsrr.db.schema=${wsrr.db.user} wsrr.db.schema defaults to the wsrr.db.user. Only change this value if you want to use something other than the wsrr.db.user.

# Act Database Schema name - only used for z/OS databases # defaults to the database username act.db.schema=${act.db.user} act.db.schema defaults to the act.db.user. The act.db.user was set to the wsrr.db.user earlier in the wsrrdeployment.properties file. Only change this value if you want to use something other than the wsrr.db.user.

# # # #

***************************************************************************** * Oracle-Specific Database Installation Information * * This document does not cover using an Oracle database * *****************************************************************************

# Oracle install directory #oracle.home=c:/oracle/product/10.2.0/Db_1 oracle.home=/home/oracle/product/10.2.0/Db_1 # Oracle Port oracle.port=1521 # Oracle Admin User oracle.adminuser=oracle # Oracle Service Name # If set to anything other than null then the JDBC driver will use the service name # for the connection URL, otherwise it will use the database SID (db.name). # If oracle.service=null then the connection URL will be: # jdbc:oracle:thin:@${db.hostname}:${oracle.port}:${db.name} # If oracle.service != null then the URL will be: # jdbc:oracle:thin:@(description=(address=(protocol=TCP)(Host=${db.hostname})(Port =${oracle.port}))(connect_data=(service_name=${oracle.service}))) wsrr.oracle.service=null sib.oracle.service=${wsrr.oracle.service} act.oracle.service=${wsrr.oracle.service} # *****************************************************************************
2009, IBM Washington Systems Center Americas Advanced Technical Support

- 13 -

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries # * SQLServer-Specific Database Installation Information * # * This document does not cover using a SQLServer database * # ***************************************************************************** # SQLServer Port sqlserver.port=1433 # SQLServer install directory sqlserver.home=C:/Program Files/Microsoft SQL Server/MSSQL.1 # ***************************************************************************** # * WebSphere Application Server Installation Information * # ***************************************************************************** # WAS Base Installation Directory was.installdir=/opt/IBM/WebSphere/V6R1 was.installdir should point to the location of the WAS base code. It should not point to the profile directory.

# WAS PROFILE NAME #was.profile=wsdmnode was.profile=wsdmgr was.profile should be set to the profile name of the deployment manager. The profile name does not always match the name of the profiles directory. To retrieve the proper profile name, issue: ./manageprofiles.sh -listprofiles

# WAS NODE NAME # if installing to a standalone server, then this can be left set to null # if installing to a cluster this can also be left set to null # this is only needed if installing to a federated server via a DMGR was.node=null In our test case, we installed WSRR into a WAS cluster so we set the was.node to null.

# WAS SERVER NAME was.server=null In our test case, we installed WSRR into a WAS cluster so we set the was.server to null. This value only needs to be changed if WSRR is being installed into a stand alone application server.

# WAS SOAP CONNECTOR ADDRESS PORT # This is the SOAP port for the target server # If installing to a cluster then this should be set to the SOAP port of # the deployment manager (normally 8879) was.port=20003 In our test case, we installed WSRR into a WAS cluster so we set the was.port to the SOAP port of the deployment manager. The SOAP port can be found in the WAS administrative console under System Administration > Deployment Manager > Ports

# WAS CLUSTER NAME # If you are not installing to a cluster then leave this set to "null" # Otherwise set it to the name of your cluster
2009, IBM Washington Systems Center Americas Advanced Technical Support

- 14 -

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries was.cluster=DQDC_A001 In our test case, we installed WSRR into a WAS cluster so we had to set the was.cluster value. This value is found in the administrative console under Servers > Clusters

# WAS Admin Username # leave set to null if security is disabled was.user=null The WSRR configuration was done in out test scenario with security disabled so we set was.user to null. If security is enabled, set this value to the WebSphere administrative user ID.

# Use Soap properties? # If set to true, password for the was admin user will be read from # soap.client.props usesoapprops=false If security is enabled and you dont want to have to enter a password for the WAS administrative user, set usesoapprops to true so the password gets read from soap.client.props.

# WAS JMS User ID # The userID to use for JMS authentication was.jmsuser=${was.user} # # * # # # # # # # # # # # # Set this ID if java messaging will be used with WSRR. By default, it is set to the was.user. ***************************************************************************** * J2EE User-Role Mappings ***************************************************************************** * Users and groups that should be granted each of the roles * * defined by the service registry deployment descriptor. * * Each xxx.user variable can be set to one of: * * {NONE, EVERYONE, ALL_AUTHENTICATED, <any-valid-user-name>} * * If using LDAP, the user name must be the short version of the user name * * Each xxx.group variable can be set to the name of a group or to NONE * * if using LDAP, the group name must be the fully qualified group name * * * * (where xxx is either administrator or user) * * Only one value for each user or group can be specified * *****************************************************************************

administrator.user=ALL_AUTHENTICATED user.user=ALL_AUTHENTICATED administrator.group=NONE user.group=NONE

# ***************************************************************************** # * WSRR Deployment Debug * # ***************************************************************************** # Setting debug=true will enable tracing in WAS before running the WSRR preload # This setting should only be needed if requested by a support representative. debug=false
2009, IBM Washington Systems Center Americas Advanced Technical Support

- 15 -

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries

Set debug to false unless extra tracing is required for problem determination.

# ***************************************************************************** # * WSRR Skip preload * # ***************************************************************************** # Setting skippreload=true will run the whole deployment process apart from # the preload step. This will mean that your repository will not contain the # data necessary to work. The preload step MUST be performed before trying to # use your WSRR instance. This is an advanced configuration option and should # not normally need to be used. skippreload=false Set skippreload to false unless directed otherwise by IBM level 2.

2009, IBM Washington Systems Center Americas Advanced Technical Support

- 16 -

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries

Running The installall.sh Configuration Script

Now that the wsrrdeployment.properties is fully customized for the environment, it is time to complete the configuration by running installall.sh. Before running this script, make sure the deployment manager has started successfully. Installall.sh can be passed any of the variables that are present in wsrrdeployment.properties. Rather than passing the variables to the script, we just made sure that wsrrdeployment.properties was updated with all of the values that were needed in the environment. Remember that configdb should be set to false since this step does not need to be run with DB2 running on z/OS. The database objects were created ahead of time and do not get effected by the script. Running the installall script should look something like this: /opt/IBM/WebSphere/ServiceRegistry/install/installall.sh configwas true configdb false Installall.sh takes a while to complete. It should finish in about 30 minutes but the actual run time will depend on various environmental factors. When the script finishes, the following message is displayed: BUILD SUCCESSFUL Total time: 25 minutes 27 seconds If the script fails, the following will be presented: BUILD FAILED Error messages. Total time: 8 minutes 40 seconds The error messages will vary. For more detailed errors that may help in debugging the issue, check the install.log file. Also, read the next section of this document titled Install Verification and Solutions to Common Issues for some possible causes to the installall.sh failure. Once you get the BUILD SUCCESSFUL message, the configuration is complete. Although the configuration is complete, the success of the installation has not been determined yet. The next section covers some of the installation verification procedures that will determine if WSRR is working properly.

2009, IBM Washington Systems Center Americas Advanced Technical Support

- 17 -

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries

Install Verification and Solutions to Common Issues

This section is dedicated to documenting some of the common issues that have been experienced during the installation, configuration and verification of WSRR. This is not a complete list of errors encountered but a few of the more common errors that are seen during a WSRR configuration. The contents of this section should serve as a living document that is updated as we see others who may encounter difficulty in configuring WSRR. Installall.sh fails and ServiceRegistryBus does not start Start the problem diagnosis by checking to see if the ServiceRegistryBus started successfully. o Check the administrative console under Service Integration ServiceRegistryBus > Messaging Engines to see if it started or not. > Buses >

The screen shot shows the ServiceRegistryBus started. If it is in stopped status (red X in the Status field), then look in SystemOut.log for this error o [9/17/09 10:34:37:463 CDT] 00000033 SibMessage E [ServiceRegistryBus:DQDC_A001.000-ServiceRegistryBus] CWSIS0002E: The messaging engine encountered an exception while starting. Exception: com.ibm.ws.sib.msgstore.PersistenceException: CWSIS1501E: The data source has produced an unexpected exception: java.lang.IllegalStateException: CWSIS1532E: The table, WSRRSIB.SIBOWNER, is missing.

In this case, the SIB database was defined with wrong schema name (On our server, WSRRSIB should be DNET564). There are two options to fix this issue o Update admin console in these two locations with correct schema o Buses > ServiceRegistryBus > Bus members > Messaging engines for DQDC_A001 > DQDC_A001-ServiceRegistryBus > Message Store Data sources > WSRR_SIB_DS > Custom properties change currentSchema/currentSQLID

Or, redefine the database objects with the schema name in the error message

Loading a WSDL through the WSRR console (Administrator perspective) fails One simple way to determine if WSRR is functioning is to load a WSDL into WSRR via the WSRR console. Start by logging on to the WSRR console using the URL o Format: http://your.hostname:WC_defaulthost_port/ServiceRegistry/
- 18 ibm.com/support/techdocs Version Date: Monday, October 12, 2009

2009, IBM Washington Systems Center Americas Advanced Technical Support

WP101567 Configuring WSRR on Linux for zSeries

o -

Sample: http://sandbox.demos.ibm.com:20000/ServiceRegistry/

Once logged on to the Administrator perspective, find the Load Documents section of the page. It looks like the following:

Point the menu to a local WSDL file or a WSDL file on the Linux for zSeries server. Provide the menu with a document type of WSDL, a document description and version. Click OK.

The next screen shows the WSDL file that was provided. Click Finish to load the document to WSRR. If the loading of the WSDL is successful, a screen similar to the following will be displayed

If the load of the WSDL fails, an error will be displayed.

2009, IBM Washington Systems Center Americas Advanced Technical Support

- 19 -

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries

To determine the cause of the error, check the SystemOut.log of the application server where WSRR is running. In our case, there was a bug with the activity logging database. A -514 error was returned to WSRR from DB2. o [9/18/09 10:53:57:783 CDT] 00000047 api E com.ibm.serviceregistry.ServiceRegistryActivityLoggingDBBean createAPICall GSR5000I: Captured exception [88]: com.ibm.websphere.ce.cm.StaleConnectionException: DB2 SQL Error: SQLCODE=514, SQLSTATE=26501, SQLERRMC=SQL_CURLH300C1, DRIVER=3.52.110

WSRR development is looking into the cause of this issue. The exact cause is not known as of the publishing of this document. A temporary fix for this is error to turn off activity logging. o Turn off Activity Logging as described here http://publib.boulder.ibm.com/infocenter/sr/v6r3/index.jsp?topic=/com.ibm.sr.webui.doc/h tml/config_admin_activity_collection.html Check that the WSRR_ACT_DS data source has pretest connections set to true. The query should be something like "SELECT 1 FROM SR_ACTIVITY_CONTAINER WHERE version = 0".

2009, IBM Washington Systems Center Americas Advanced Technical Support

- 20 -

ibm.com/support/techdocs Version Date: Monday, October 12, 2009

WP101567 Configuring WSRR on Linux for zSeries

Document Change History

Check the date in the footer of the document for the version of the document.
October 12, 2009 Original document.

End of WP101567

2009, IBM Washington Systems Center Americas Advanced Technical Support

- 21 -

ibm.com/support/techdocs Version Date: Monday, October 12, 2009