zOS Installation Configuration Guide
zOS Installation Configuration Guide
P u bli s h i ng I nfo r m a t i o n
Chordiant Tools Platform Installation and Configuration Guide: Custom er Suppor t
z/OS® and WebSphere Application Server [email protected]
EMEA:
+44 (0) 20 8580 0400
Contents
Preface ....................................................................................................................................................... v
iii
Type 2 JDBC Driver .................................................................................................................... 21
iv
Preface
The Chordiant Tools Platform Installation and Configuration Guide provides information and
procedures to install and setup Chordiant development and production environments on z/OS®
platform. This information includes installing and configuring third-party applications required
to run Chordiant, steps to verify your installation, and troubleshooting tips.
Manual Organization
The Chordiant Tools Platform Installation and Configuration Guide is organized in the following
manner:
v
Additional Documentation
To install and configure a Chordiant Foundation Server, you should read and be familiar with the
following:
• IBM WebSphere Application Server Documentation
• DB2 Documentation
• Chordiant Applications Installation Guide for z/OS® platform for both WebSphere and DB2
documentation lines
• Chordiant Applications Deployment Guide
• Chordiant Servicing Applications Installation Guide
• Be familiar with deploying your custom Chordiant application(s)
Typographical Conventions
This section explains how to interpret the font changes and notes that you see in this manual.
CONVENTION EXAMPLE
System filenames and pathnames Readme.txt is a text file that is stored on the
application server in the /etc (for UNIX) or
C:\ (for Windows NT) directory.
Document names and module names See the “Security” section within the Ongoing Tasks
document, or the online help from within the
Security module.
Names of code elements and small pieces of code Use the getInfo method
- or -
Onscreen text and text typed on the keyboard Type the password cmyk.
Screen element labels, including buttons and menus Click OK. Then from the File menu, select Save.
- or -
Keys that you press on the keyboard To save the information on the page, press CTRL +
SHIFT + s.
Variables that you must define based on your own {JAVA_HOME}/com/chordiant/jxw
settings
Note: A note shows important information that you should be sure to read. Many notes
refer to other sections for more information.
Tip: A tip gives suggestions on how you can use the application faster or more
efficiently.
Caution: A caution statement warns of steps you should take, or avoid, so you do not
damage your equipment, data, or system reliability.
Preface vii
Chapter 1
Introduction
The Chordiant Tools Platform Installation and Configuration Guide provides the information you need
to install Chordiant Foundation Server and setup your development environment so you can
begin developing Chordiant solutions.
The development environment is to be setup in Windows XP or Windows Vista and for more
information refer to tech stack page of the Chordiant Mesh®.
1
2
3 4
6 7
1
4. Setup third-party products for the Chordiant development environment.
5. Verify the installation.
6. Install and configure Chordiant application(s) to be customized.
7. Install third-party software for production.
The Tools Platform runs under MyEclipse/RAD, an open integrated development environment,
enabling tool integration, productivity enhancement tools, and support for open technologies.
Third-party software, such as an application server, database, and security must be successfully
installed and verified before Chordiant can be installed. Be sure to note the installation and
configuration settings for your supporting software, which you will be asked to supply when
configuring your development environment.
Refer to the MyEclipse/RAD Guide to finish the installation process. When the installation
process is finished, you must perform a few tasks before you can begin using the Chordiant Tools
Platform to develop applications or package them for deployment.
After you have configured your development environment for Chordiant, you can install your
application, configure the development environment to run it, and begin using the Tools Platform
to extend and customize it. The Chordiant Servicing Applications Installation Guide provides general
steps to install applications and configure the development environment for them. Some
applications also provide additional, application-specific installation and deployment documents
on the installation CD.
Chapter 1: Introduction 2
Chordiant Tools Platform
C H O RD I A N T TO O L S P L A T FO R M
The Chordiant Tools Platform provides a robust development environment in which to create,
modify, and extend Chordiant applications. The Tools Platform provides:
• A Foundation Server runtime
• Source code necessary to develop applications
• Third-party software needed for runtime execution
• Tools to aid in application development
Some tools, such as the Business Process Designer, are fully integrated with the Tools Platform.
Others can optionally install to the environment, and still others operate as standalone tools
outside the Chordiant solution. You can further extend the development environment by
installing other third-party plug-ins. MyEclipse/RAD modular structure simplifies installing
features, updates, and additional plug-ins through native installers or the MyEclipse/RAD
Update Manager.
All tools listed in the tech stack page on the Chordiant Mesh® or on your installation CD are either
required or recommended for performing specific solution design and implementation functions.
The following Chordiant and third-party tools can be integrated with the Chordiant Tools
Platform:
• Business Component Generator—Creates application components from any modeler. See the
Chordiant Foundation Server Application Components Developer’s Guide for information about
details on creating your model, on using the Foundation UML, and on generating your
application components.
• Business Process Designer—A fully integrated tool that lets you build workflows graphically.
Refer to the Chordiant Tools Platform Business Process Designer Developer’s Guide for more
information about creating workflows.
• Application Packaging Manager—Packages application WARs, EJBs, and other components
in a deployable EAR file. See the Chordiant Applications Deployment Guide for more information
about using the APM to package your applications for deployment.
C H O RD I A N T M E S H ®
The Chordiant Mesh® is Chordiant’s online community of developers and users. Visit the
Chordiant Mesh®, located at https://www.chordiant.net to:
• Download daily builds or milestone releases
• Participate in online discussions about new or existing features
• Learn about new features being developed
• Participate in new feature development
• Read documentation
• Log a bug
• Fix a bug
• Find out how you can participate
Go to the Chordiant Mesh® site to learn more about how you can be part of the solution.
Chapter 1: Introduction 4
Chapter 2
Preparing the Development
Environment
This chapter describes preparation tasks required to setup a development environment for
running Chordiant Applications. To do so, you must install and configure third-party applications
on your development system. These products include your application server, database, security,
and JMS. In addition, your application may require the installation of other supporting software.
D E V E L O P M E N T E NV I RO N M E N T S E T U P
The development environment of Chordiant can be configured either on WebSphere/MyEclipse
or WebSphere/RAD environment. The procedure is similar to the steps detailed in the existing
documentation set.
For additional information on Installation and configuration refer to the following guides:
• Chordiant Tools Platform Installation and Configuration Guide - RAD and WebSphere Application
Server
• Chordiant Tools Platform Installation and Configuration Guide - MyEclipse and WebSphere
Application Server
• Chordiant Applications Deployment Guide for WebSphere Application Server
5
Chapter 3
Preparing a Production Environment on
z/OS®
This chapter describes configuring third-party applications in your production environment. You
need to note information about your third-party application installations. This information is
needed to configure Chordiant for production. Appendix A provides a checklist of the
information required.
Be sure to read your third-party installation and setup instructions carefully. You
may need to set environment variables and download patches or fixes in order to
complete your installation successfully.
All softwares must be licensed and legally installed from the appropriate parties.
When installing third-party applications, we strongly recommend that you note your settings on
the form provided in Appendix A. You will need this information when you build your EAR file.
C O N F I G U R I N G T H I RD -P A R T Y A P P L I C A T I O N S
Before you can deploy an application to production, you must install and configure third-party
applications on your production system. These products include your application server, database
and LDAP. In addition, your application may require the installation of other supporting
software.
Note: Installation of third-party software is not covered in this document. Please refer to
the appropriate third-party documentation for installation steps.
DATABASE SETUP
This section describes creating and configuring DB2 database for z/OS® platform.
6
Database Setup
Assumptions:
1. z/OS® DB2 Subsystem environment is setup and made accessible by the z/OS® System
Administrator.
2. DB2 Connect Software is installed in the remote environment to connect to z/OS® subsystem.
For more information on DB2 Connect installation procedures, refer to the IBM DB2
documentation available with the software.
Here, the <node_name> denotes the name by which the z/OS® server is identified on the local
windows machine.
For example, db2 catalog tcpip node 240cfs remote x.x.x.10 server 4019 ostype OS390
3. To catalog the z/OS® subsystem, run the following statement:
db2 catalog database <subsystem_name> as <subsystem_alias> at node <node_name> authentication server
For example, db2 catalog database cfs240db as cfs240db at node 240cfs authentication server
4. To catalog the Database Connection Services (DCS) database, run the following statement:
db2 catalog dcs database <subsystem_alias> as <subsystem_alias>
Note: The above command stores information about remote host or System i™
databases in the Database Connection Services (DCS) directory. These databases
are accessed through an Application Requester (AR), such as DB2® Connect™.
Having a DCS directory entry with a database name matching a database name in
the system database directory invokes the specified AR to forward SQL requests
to the remote server where the database resides.
Database Creation
In the scripts the default database name is CHRD and the schema name is
CCSOWN. Modify the defaults appropriate to the environment.
Once connected to the DB2 Subsystem through DB2 Connect, execute the following steps for
creating the DB2 Foundation Server database on z/OS® machine:
1. Database creation scripts are part of the CFS_on_zOS.zip and located under {Foundation
Third Party}/Database/data/database/zOS folder. Unzip the contents from
CFS_on_zOS.zip into a staging directory in the remote environment.
2. Change to staging directory.
3. To create the Foundation Server database, run the statement:
db2 –tvf 01_create_database.ddl –z 01_create_database.out
4. To create tables in the Foundation Server database using explicit tablespaces, run the
statements mentioned below:
db2 -tvf 02_create_tablespaces.ddl -z 02_create_tablespaces.out
db2 -tvf 03_create_tables_in_tbsp.ddl -z 03_create_tables_in_tbsp.out
To create the tables using implicit tablespaces, run the statement mentioned below:
db2 –tvf 03_create_tables_default.ddl –z 03_create_tables_default.out
Note: Appropriate sizes need to be set for PRIQTY and SECQTY parameters when
tablespaces are created explicitly. Please check the DB2 for z/OS® documentation
for more details on creating tablespaces and related parameter settings.
By default, z-parm values are used and may not be sufficient for some Tables.
For example:
Create tablespace cfsflx18 in Foundation Server using stogroup sysdeflt priqty 12 erase
yes bufferpool bp8k0 segsize 16 logged locksize any close no
Refer your DB2 documentation for more details on creating tablespaces and
tablespace parameters.
Note: Do not run the Unique Indices script for implicit tablespaces.
11. To insert out of the box data into tables, run the statement:
db2 -tvf 09_insert_data.sql -z 09_insert_data.out
12. Verify logs for any errors to confirm the successful creation of database.
13. Connect to the database and use the following statement to verify the installed database
components information:
db2 "select schemaversion, installtype from schemainfo”
Note: The drop scripts provided can be used to drop the database and the sequences.
I N S T A L L I N G L DA P
To install LDAP, refer to either the Chordiant Tools Platform Installation and Configuration Guide -
MyEclipse and WebSphere Application Server or the Chordiant Tools Platform Installation and
Configuration Guide - RAD and WebSphere Application Server.
Note: z/OS® does not support the SUN ONE/ Open DS LDAP Servers and therefore
LDAP needs to be installed on Windows XP SP2 or Solaris 10 environment or the
setup scripts need to be modified as appropriate for other LDAP vendors or
environments.
Note: The distributed platforms (non-z/OS® platforms) are built on a single process
model. The entire server runs in one single Java Virtual Machine (JVM) process.
However, WebSphere z/OS® is built using a federation of JVMs, each executing in
a different operating system process that collectively represents a single server
instance.
Each JVM in the federation is not identical because one JVM is given preference
and holds the external endpoints of the server. This JVM is called the controller
(controller region). The other JVMs are either servants (servant regions) or adjunct
(control region adjunct process). The adjunct is a special case of a servant process.
Customer-installed applications execute only in the servant regions. The adjunct
process houses the platform messaging component.
To configure the application server setup, generate the export.zip file by referring to the
“Running Third-Party Application Setup Scripts” from Chordiant Application Deployment Guide for
WebSphere Application Server.
2. To run the application server setup scripts execute the following command:
{WAS_Install_Root}/profiles/default/bin/ws_ant.sh -verbose -f setup.xml
>/tmp/out 2>&1
The build successful message appears. Open the log file to check for any errors.
C O N F I G U R E TY P E 4 J D B C C O N N E C T I O N
This section covers the steps to configure Type 4 JDBC connection for Chordiant applications.
Note: For JDBC driver recommendation, refer Appendix C, “Type 4 vs Type 2 JDBC
Driver Recommendation”.
For Type 4 connection, you need to set the WebSphere environment variables and configure JDBC
provider as described in the section below.
E nv i ro n m e n t Va r i a bl e
1. Load the WebSphere admin console.
2. From the WebSphere Application Server Admin panel, select Environment |Manage
WebSphere Variables | Node Level.
3. Set the DB2UNIVERSAL_JDBC_DRIVER_PATH pointing to the directory containing JDBC
driver files.
For example, if JDBC driver is installed at /usr/lpp/jcc, set the environment variable to the
location as specified below:
DB2UNIVERSAL_JDBC_DRIVER_PATH = /usr/lpp/jcc/classes
C o n f i g u r i n g J D B C P rov i d e r
From the WebSphere Application Server Admin console, click Resources | JDBC Providers
1. Set the environment variable for ChordiantXAds and ChordiantNoXAds as below:
${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc.jar
${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc_license_cisuz.jar
2. Verify that the settings for other parameters are correct and click OK.
3. To set the Custom Properties of the connection, select Resources |JDBC Providers |DB2
Universal JDBC Provider | Data Sources | Custom Properties
4. In the Custom Properties dialog box, specify the following values as shown in Figure 3-1:
• DatabaseName - Set the value to the z/OS® subsystem name in which the DB2 database is
located.
• DriverType - Set the value to 4 to indicate a JDBC Type-4 connection.
• ServerName - Set the value to IP address (nn.nn.nn.nn) or the hostname
(hostname.domainname) of the DRDA server (DB2 server) system.
• PortNumber - Set the value to the port number of DRDA server (DB2 server) system.
D E P L OY I N G T H E E A R F I L E
Deploy the Chordiant EAR file following standard WebSphere Application Server procedures.
WO R K L O A D M A N A G E M E N T
Workload management (WLM) is a new feature of WebSphere Application Server for z/OS®
systems. It is used to manage the performance of WebSphere applications. WLM optimizes the
distribution of incoming work requests to the application servers, enterprise beans, servlets, and
other objects that can most effectively process the requests. It also provides failover when servers
are not available, improving application availability.
For more information on Workload management feature, refer the Workload management for
z/OS®.
Refer to Appendix D, “Configure Multiple Server Instance for Foundation Server” for instructions
on how to leverage the Workload management features for Chordiant applications.
I N S T A L L I N G C H O RD I A N T D E C I S I O N M A N A G E M E N T ( C D M )
WITH FOUNDATION SERVER
To integrate CDM with Foundation Server, refer to either the Chordiant Tools Platform Installation
and Configuration Guide - MyEclipse and WebSphere Application Server or the Chordiant Tools Platform
Installation and Configuration Guide - RAD and WebSphere Application Server.
When installing and configuring supporting third-party software, record the information
described in the following tables. This information will be required when you configure your
Chordiant installation in the Tools Platform.
Application Server
14
Database
J D K ( D ev e l o p m e n t o n ly )
Troubleshooting
WE B S P H E R E
Data source test connection from Admin console fails when
setting up
Be sure that the JDBC Provider and data sources are configured at the right scope levels.
Test connection fails when the JDBC provider is configured at server scope and data sources at cell
scope. Here, when the deployment manager tries to test the connection, it is unable to find the JAR
files for the driver as no JDBC provider definitions are available.
18
Database
Note: It is recommended that you define the JDBC Provider on a higher level.
To avoid these errors on the server logs follow the below steps:
1. Locate web-app_2.3.dtd under {WAS_INSTALL_ROOT}/properties/schema/j2ee
directory.
2. Create a jar such that the web-app_2.3.dtd exists in javax.servlet.resources package within the
jar file.
3. Open the WebSphere Application Server Administration console and create a shared library
pointing to the jar file created above.
4. Go to Servers | Server Types | WebSphere application servers | {Server Name} | Java and
Process Management | Class Loader.
5. Create a new class loader with classes loaded with the local class loader first (parent last)
option.
6. Select the created class loader and access Shared library references, and assign the shared
library created in Step 3.
7. Save the Configuration and re-start the server.
DATABASE
When using a DB2 for z/OS® messaging data store, the tables are not created dynamically. These
tables must be created manually before starting the messaging engine.
You can find the sibDDLGenerator.sh in the AppServer/bin directory of WebSphere. To have
separate message stores for the cluster setup for the two buses, you need to run everything twice.
Below are the commands to generate the DDL files:
./sibDDLGenerator.sh -system db2 -version 8.1 -platform zos -schema CHRDOWN -database SIBCHRD -user
CHRDOWN -statementend ';' -storagegroup SYSDEFLT >/tmp/sibDDL_CHRDOWN.txt
./sibDDLGenerator.sh -system db2 -version 8.1 -platform zos -schema CCSOWNER -database SIBCCSO -user
CCSOWNER -statementend ';' -storagegroup SYSDEFLT >/tmp/sibDDL_CCSOWNER.txt
Use the DB2 Connect to connect to DB2 and submit the DDL scripts from the command to create
the tables specific to the messaging engine.
Chapter B: 20
Appendix C
Type 4 vs Type 2 JDBC Driver
Recommendation
This chapter provides recommendation on the JDBC driver that can be configured with
Foundation Server.
Ty p e 4 J D B C D r i v e r
Chordiant recommends the use of Type 4 JDBC driver with Foundation Server when the
Application Server and the Database Server are on different machines. The Type 4 JDBC driver
directly connects to the remote database and is much faster than the Type 2 JDBC driver.
Type 4 JDBC driver is much simpler to install and use when compared to Type 2 .
Ty p e 2 J D B C D r i v e r
It is recommended to use Type 2 JDBC driver when both the Application Server and the Database
Server are on the same machine. The Type 2 JDBC driver is optimized for this topology as it
utilizes CPU specific features such as memory sharing across processes. This reduces TCP/IP
network calls to remote databases.
In case the Application Server and the Database Server are configured with Type 2 JDBC driver on
different machines, the internal database mandates alias to be created for all remote database
tables. Due to the complexity involved with this approach, it is not recommended to configure
Type 2 driver with this configuration.
21
Appendix D
Configure Multiple Server Instance for
Foundation Server
This chapter describes how to configure Multiple Server Instances for Foundation Server to
leverage the Workload Management feature. This feature is provided by WebSphere Application
Server for z/OS ®.
22
Configure Multiple Server Instance
4. Click Apply and then click Save and Synchronize to update your changes.
Reference Documents
Refer to the following sections from IBM Information Centre for more information:
• For configuration and control of number of server instances, refer to the Controlling the
number of servants section.
• For enabling the multiple server instances, refer to the Enabling multiple servants on z/OS®
section.
• For configuring WLM even distribution of HTTP session objects across the multiple servant
processes, refer to the Configuring an application server to use the WLM even distribution of
HTTP requests function section.
Po r t S h a r i n g
Ensure that the Foundation Server ports have been shared at the profile dataset to avoid port
conflicts during server startup. This is a mandatory step for Foundation Server to work in an
environment with Multiple Server Instances.
Appendix D: 24