WSRR Configuration Linux on zSeries

WebSphere Services Registry and Repository V6.3

Configuring WSRR on Linux for Configuring WSRR on Linux for Configuring WSRR on Linux for Configuring WSRR on Linux for

zSeries Utilizing DB2 on z/OSzSeries Utilizing DB2 on z/OSzSeries Utilizing DB2 on z/OSzSeries 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

[email protected]

WP101567 – Configuring WSRR on Linux for zSeries

© 2009, IBM Washington Systems Center Americas Advanced Technical Support - 2 - ibm.com/support/techdocs

Version Date: Monday, October 12, 2009

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 e-mail to Paul Houde at [email protected]




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




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.

Application Server

Application Server

Deployment Manager

Nodeagent Nodeagent

Nodes federated into dmgr

Linux 1 Linux 2 Linux 3

Cluster




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- Deutsch

->2- English

3- EspaÃ±ol

4- FranÃ§ais

5- Italiano

6- PortuguÃªs (Brasil)

CHOOSE LOCALE BY NUMBER: 2

====================================================================




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

:

====================================================================




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-db-sqlid, 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, • createdbsib.sql • createsched.sql

• createdbact.sql • createdbts.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




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




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




LU USIBMWZ.WSCDB2A1

GENERICLU USIBMWZ.WSCDBP0

DOMAIN wsc1

TCPPORT 446

SECPORT 448

RESPORT 5021

IPNAME -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




# e.g. WSRR


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




# e.g. WSRR





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/




- 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


# Database Instance username - only needed for UNIX

# Not used on z/OS

db2.instid=db2inst1


# DB2 Instance home directory - only needed for UNIX

# Not used on z/OS

db2.instancehome=/home/${db2.instid}


# 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




- 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}

# *****************************************************************************




# * 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




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 don’t 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




- 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.




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.




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 > Buses > ServiceRegistryBus > Messaging Engines to see if it started or not.

- 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

- Buses > ServiceRegistryBus > Bus members > Messaging engines for DQDC_A001 > DQDC_A001-ServiceRegistryBus > Message Store

- Data sources > WSRR_SIB_DS > Custom properties change currentSchema/currentSQLID

o 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/




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.




- 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/html/config_admin_activity_collection.html

o 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".




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

WSRR Configuration Linux on zSeries

Documents

j2c authentication

supporttechdocs

master address

db2mstr address

windows based

websphere

wp101567 configuring

websphere