Tivoli and web sphere application server on z os sg247062
1. Front cover
Tivoli and WebSphere
Sphere
Application Server for
on
z/OS
Comprehensive management of
WebSphere Application Server
From performance and
availability to security
Extensive examples and
scenarios
Budi Darmawan
Foulques de Valence
Daniela Chersoni
ibm.com/redbooks
20. Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
ibm.com® ™ Redbooks (logo) ™
z/OS® IBM® RACF®
zSeries® IMS™ RMF™
CICS® Lotus® Tivoli Enterprise™
Database 2™ MVS™ Tivoli Enterprise Console®
Domino™ NetView® Tivoli®
DB2 Universal Database™ OS/390® VTAM®
DB2® Redbooks™ WebSphere®
The following terms are trademarks of the International Business Machines Corporation and the Rational
Software Corporation, in the United States, other countries, or both:
Rational®
The following terms are trademarks of other companies:
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, and service names may be trademarks or service marks of others.
xviii Tivoli and WebSphere Application Server for z/OS
22. Budi Darmawan is a Project Leader at the International Technical
Support Organization, Austin Center. He writes extensively and
teaches IBM classes worldwide in all areas of Tivoli systems
management products. Before joining the ITSO four years ago,
Budi worked in IBM Indonesia Integrated Technology Services as
lead implementer and solution architect. His expertise is in general
Tivoli systems management, z/OS system programming, and
database administration. He currently specialize in Business Service
Management and availability management.
Foulques de Valence is a WebSphere for z/OS Specialist with
IBM Global Services. Currently based in Paris, France, he works at
the French customer Technical Support Center within the CICS
and WebSphere for z/OS team. In previous years, he provided
customer support on Lotus® Domino™ for OS/390® and UNIX
System Services. Prior to IBM, Foulques served as the IT Manager
of a small manufacturing company in the San Francisco bay area.
He received his Master's degree in Computer Science and Engineering from
Ensimag in France. He furthered his education at the State University of New
York at Buffalo, and at Stanford University USA.
Daniela Chersoni is an IT Systems Management Specialist with
IBM Global Services Strategic Outsourcing Italy. She has worked
on mainframe systems VM, MVS™, z/OS and networking since
1982. She has several years experience with IBM System
Automation for OS/390 and IBM Tivoli NetView® for OS/390. She
works in IGS Vimercate (Italy), at the Server System Operation
(SSO) organization within the Infrastructure Platform & Tivoli team.
Her areas of expertise include systems management and support for outsourcing
clients.
Thanks to the following people for their contributions to this project:
Axel Buecker and Wade Wallace
International Technical Support Organization, Austin Center
Rich Conway and Bob Haimowitz
International Technical Support Organization, Poughkeepsie Center
Scott Henley
IBM Australia, Tivoli Software.
Mari Heiser
IBM US
xx Tivoli and WebSphere Application Server for z/OS
23. Become a published author
Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You'll team with IBM technical professionals,
Business Partners and/or customers.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our Redbooks™ to be as helpful as possible. Send us your comments
about this or other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:
redbook@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. 0SJB Building 003 Internal Zip 2834
11400 Burnet Road
Austin, Texas 78758-3493
Preface xxi
24. xxii Tivoli and WebSphere Application Server for z/OS
26. 1.1 Managing WebSphere Application Server for z/OS
As enterprises move to Web-enable most applications they have, some
applications with strong mainframe ties tend to stay in the mainframe. IBM
WebSphere Application Server for z/OS is a very popular choice as the agent of
change for legacy applications.
IBM WebSphere Application Server for z/OS has strong back-end ties with
legacy z/OS subsystems, such as CICS and DB2. It also interfaces well with
WebSphere MQ for z/OS for enabling message queueing applications. The
complexity of managing new subsystems that are becoming more critical over
time and technology that is (mostly) unfamiliar to the z/OS system programming
team introduces a significant friction in adopting IBM WebSphere Application
Server for z/OS.
Systems management of IBM WebSphere Application Server for z/OS should be
approached in a holistic view. There are more management issue than just
performance monitoring. This redbook will describe the approach that Tivoli has
taken to managing performance, security, and operation of IBM WebSphere
Application Server for z/OS. The redbook discusses implementation and usage
of IBM/Tivoli tools to manage IBM WebSphere Application Server for z/OS.
1.2 IBM automation blueprint
The IBM Tivoli solution is the basis for providing automation for the overall
system management of the OnDemand world. Automation is critical for
businesses to achieve resiliency, efficiency, responsiveness, and flexibility. The
IBM automation platform provides the structure of the automation components
for providing on demand automation capability.
The IBM automation blueprint is shown in Figure 1-1 on page 3.
2 Tivoli and WebSphere Application Server for z/OS
27. Business Service Management
Policy Based Orchestration
Availability Assurance Optimization Provisioning
Virtualization
Software Resources System Resources
Figure 1-1 IBM automation blueprint
The IBM automation blueprint is a game-changing plan for reducing the
complexity of technology, allowing more focus on the business goals, and
allowing the application of resources to business objectives rather than the
management of technology. The blueprint enables enterprises to implement
automation in an evolutionary fashion that acknowledges the heterogeneous
nature of the infrastructure.
At the bottom of the blueprint is the foundation: the Software and System
Resources with native automation capabilities required for higher level
automation functions. Many of these resources may be virtualized to the other
capabilities. Here, the key point is that in order to achieve the highest levels of on
demand automation, resources need to be virtualized so that they can be
dynamically provisioned as business policies require.
Above the resources are the key automation capabilities:
Availability helps ensure that systems are available 24x7.
Reliance on security keeps your systems protected from threats and provides
the functions for a great user experience in accessing applications and data
they need – while keeping out unwelcome users.
Chapter 1. Introduction 3
28. Optimization provides tools to make the most of the resources you have – so
that they are running at peak performance and efficiency and providing you
with the maximum return on your investment.
Provisioning focuses on the self-configuring, dynamic allocation of individual
elements of your IT infrastructure so that Identities or Storage or Servers are
provisioned as business needs dictate.
The next layer, Policy-based Orchestration, helps customers automatically
control all the capabilities of the four areas we just discussed so that the entire IT
infrastructure is responding dynamically to changing conditions according to
defined business policies. This orchestration builds on the best practices of the
customer’s collective IT experience, and helps to ensure that complex
deployments are achieved with speed and quality on demand.
Finally, Business-driven Service Management capabilities provide the tools you
need to manage service levels, meter system usage and bill customers for that
usage, as well as model, integrate, connect, monitor, and manage your business
processes end-to-end for complete linkage of IT and business processes. Being
able to view IT resources in context of business systems is a unique capability
that we need.
The management tools that we discuss in this redbook primarily involve
providing an Availability and Assurance (Security) solution for IBM WebSphere
Application Server for z/OS. Operation support and provisioning in z/OS are
available from the operating systems functions, such as Workload Manager and
other subsystems, such as IBM Tivoli Workload Manager, which are not
discussed in this redbook.
1.3 Our operating environment
This redbook project was written at the IBM International Technical Support
Organization (ITSO) in Austin center, with mainframe z/OS systems residing in
the ITSO Poughkeepsie center. We used a SYSPLEX environment called
WTSCPLX1 with system SC61 and SC62.
The managed systems run IBM WebSphere Application Server for z/OS Version
4.0.1. The management application that we discuss and used in this redbook
are:
IBM Tivoli Monitoring for Web Infrastructure Version 5.1.1, which allows
monitoring of IBM WebSphere Application Server for z/OS internal metrics to
ensure that no bottleneck exists
4 Tivoli and WebSphere Application Server for z/OS
29. IBM Tivoli Monitoring for Transaction Performance Version 5.2, which allows
multiple agents to be placed around the network to see the performance
profile of transactions to the application server
IBM System Automation for z/OS Version 2.2, which provides message
automation, automatic controlled startup, shutdown automation, address
space cleanup, and recovery (restart or reallocate)
IBM Tivoli Access Manager for e-business Version 4.1, which allows coarse
or granular security definitions for access authorization and authentication
through RACF® and Web-enabled attributes.
Our overall systems management environment is shown in Figure 1-2.
z/OS SC61
IBMTIV2 LDAP Server CICS DB2
Policy Server
Web Portal Mgr
Authentication Server
WebSphere Application
IBM HTTP Server
Server for z/OS
Web Seal
SC61N
IBM Tivoli NetView for z/OS
IBM System Automation for z/OS
management
agents
z/OS SC62
CICS DB2
management
agents
WebSphere Application
IBM HTTP Server
Server for z/OS
management
agents SC62N
IBM Tivoli NetView for z/OS
IBM System Automation for z/OS
tmtp-linux
Tivoli internet management IBMTIV1
server (TIMS)
ITM for
WebSphere
Application Server TBSM task server
TMR Server
Gateway
Endpoint
Figure 1-2 Overall management environment
In Figure 1-2, the different patterns signify the different products that we use.
Chapter 1. Introduction 5
30. Additional products that we use are:
On z/OS:
– z/OS Version 1.4
– IBM Tivoli NetView for z/OS Version 5
– IBM Database 2™ for z/OS Version
– CICS Transaction Server Version 1.3
– IBM HTTP Server for z/OS
– IBM WebSphere Application Server for z/OS Version 4.0.1
On distributed platform
– Tivoli Management Framework Version 4.1
– IBM Tivoli Monitoring Version 5.1.1
– IBM Tivoli Monitoring Component Services Version 5.1
– IBM Tivoli Business Systems Manager Version 2.1.1
– DB2 Universal Database™ Version 7.1
1.4 Document organization
The document consists of the following chapters:
Chapter 1, “Introduction” on page 1, this chapter, explains the general
objective of the book, and introduces the environment that we operate.
Chapter 2, “Our WebSphere Application Server for z/OS environment” on
page 9 describes the setup of our WebSphere environment and the
application that we installed in it.
Chapter 3, “IBM Tivoli Monitoring for Web Infrastructure: the inside-out
viewpoint” on page 41 explains the implementation for IBM Tivoli Monitoring
for Web Infrastructure: WebSphere Application Server and also provides
some illustration of scenarios.
Chapter 4, “ITM for Transaction Performance: the outside-in view” on page 95
explains the implementation of the IBM Tivoli Monitoring for Transaction
Performance and also provides some illustration of scenarios.
Chapter 5, “System Automation for z/OS: automation & high availability” on
page 155 outlines the IBM System Automation for z/OS concepts and
implementation for managing WebSphere Application Server for z/OS.
Chapter 6, “IBM Tivoli Access Manager: securing WebSphere for z/OS” on
page 235 shows the sample implementation of an integrated Web security
6 Tivoli and WebSphere Application Server for z/OS
31. implementation using the IBM Tivoli Access Manager for e-business with
authorization to IBM Security Server for z/OS (formerly RACF).
Appendixes that discusses a range of topics that do not fit well into the
content of the book, such as:
– Appendix A, “Tivoli Management Framework: a short overview” on
page 295 provides an overview of Tivoli Management Framework.
– Appendix B, “IBM Tivoli NetView for z/OS: a short overview” on page 303
gives a short description of IBM Tivoli NetView for z/OS.
– Appendix C, “The SMEUI: overview and concepts” on page 307 explains
basic concepts of the System Management Environment User Interface for
managing WebSphere Application Server for z/OS Version 4.
– Appendix D, “LDAP z/OS native authentication for TAM files” on page 317
provides listing of files that we use for native authentication with IBM Tivoli
Access Manager.
Chapter 1. Introduction 7
32. 8 Tivoli and WebSphere Application Server for z/OS
34. 2.1 WebSphere Application Server for z/OS environment
Our operating environment consists of two z/OS logical partitions in a SYSPLEX.
Each partition runs a HTTP server, a WebSphere Application Server for z/OS
runtime and J2EE servers instances, a CICS region, and a DB2 database.
This architecture is not the recommended architecture as far as security is
concerned. In a real-life e-business architecture, HTTP servers should be
separated from the applications servers with firewalls ensuring that only HTTP
flow coming from designated HTTP servers reach the zSeries server. In this
book, we would like to focus on the WebSphere Application Server for z/OS,
hence we use the HTTP server on z/OS to avoid networks considerations and
delays between HTTP servers and WebSphere Applications Servers for z/OS.
This architecture is appropriate for testing, developing, or benchmarking Web
applications.
The two WebSphere Application Servers for z/OS runtimes are in the host cluster
configuration. This means that the WebSphere for z/OS SYSPLEX configuration
appears to be a single system to systems and application programs outside of
the SYSPLEX even though there may be two or more physical systems within the
SYSPLEX. The benefits of such a configuration include:
You can balance the workload across multiple systems, thus providing better
performance management for your applications.
As your workload grows, you can add new systems to meet demand, thus
providing a scalable solution to your processing needs.
By replicating the runtime and associated business application servers, you
provide the necessary system redundancy to assure availability for your
users. Thus, in the event of a failure on one system, you have other systems
available for work.
You can upgrade WebSphere for z/OS from one release or service level to
another without interrupting service to your users.
To send requests from the HTTP servers to the WebSphere Application Servers,
the WebSphere for z/OS HTTP plug-in is being used. This plug-in is provided by
WebSphere for z/OS. Equivalent plug-ins for other platforms are also provided
and the plug-in configuration file is the same on all platforms so that you can
easily switch from using IBM HTTP servers for z/OS to HTTP servers on
distributed platforms like Apache. Once you have WebSphere for z/OS and your
Web server and plug-in properly configured, you can route requests from your
browser, through the Web server and plug-in, to one of the WebSphere for z/OS
J2EE server instances defined in the ServerGroup element in the plugin-cfg.xml
file. New requests will get sprayed across these server instances, but once a
session is established, requests will get routed back to the correct HTTP(S)
10 Tivoli and WebSphere Application Server for z/OS
35. transport handler based on the CloneID the WebSphere for z/OS Web container
assigned to the original request. If one J2EE server instance is down, the plug-in
automatically re-routes requests to other J2EE server instances available.
Figure 2-1 shows our WebSphere Application Server for z/OS environment.
HTTP Requests
z/OS z/OS
SC61 SC62
HTTP Server
WebSphere z/OS plugin
Trade 2 J2EE Trader J2EE Trade 2 J2EE Trader J2EE
Server Server Server Server
CTG CTG
WebSphere for z/OS WebSphere for z/OS
CICS CICS
DB2 DB2
Figure 2-1 WebSphere Application Server for z/OS environment
We chose Trade2 and Trader as sample applications deployed in our J2EE
application servers. Trade2 is deployed in one J2EE server and Trader is
deployed in another J2EE server.
Trade2 models an online brokerage application providing Web-based services
such as login, buy, sell, get quote, and more. It uses a servlet to drive a
session EJB that calls a data bean, which executes a JDBC call to DB2, then
returns data to a JSP that generates the HTML. This Web application is
mainly used for benchmarking purposes. It provides a useful servlet called
TradeScenarioServlet that randomly calls one of the Trade2 functions. This
way, repeatedly calling the same servlet simulates using all the brokerage
application functions.
Trader is a stock trading application that allows a user to buy and sell shares
in numerous companies. Trader is a CICS business logic program, and in our
case, a WebSphere Application Server for z/OS presentation logic program.
Chapter 2. Our WebSphere Application Server for z/OS environment 11
36. This application requires the CICS Transaction Gateway in local mode to
communicate with the CICS Transaction Server.
2.2 IBM HTTP server and WebSphere z/OS HTTP plug-in
In our operating environment, we decided to use the z/OS HTTP plug-in
available with WebSphere service level W401500. This plug-in allows
connections through the HTTP(S) Transport Handler between a WebSphere for
z/OS Web container and the IBM HTTP server for z/OS and OS/390.
Similar plug-ins for Web servers running on a non-z/OS platform are also
available to allow connections with WebSphere for z/OS. You can read the
complete list of supported Web servers and platforms in the documentation for
the new WebSphere HTTP plug-in for z/OS introduced with APAR PQ68250,
available on the WebSphere for z/OS support Web site:
http://www.ibm.com/software/webservers/appserv/zos_os390/support/
On the HTTP server side, only the httpd.conf file needs to be customized. The
location of this UNIX System Services file can be found in the JCL of your IBM
HTTP Server by looking at the procedure parameters. Example 2-1 shows the
directives we added to our httpd.conf file.
Example 2-1 Sample httpd.conf file directives
ServerInit /WebSphere/WebServerPlugIn/bin/ihs390WASPlugin_http.so:init_exit /web/tiv1/was401_pl
ugin-cfg.xml
Service /PolicyIVP/* /WebSphere/WebServerPlugIn/bin/ihs390WASPlugin_http.so:service_exit
Service /WebSphereSamples/* /WebSphere/WebServerPlugIn/bin/ihs390WASPlugin_http.so:service_exit
Service /TraderWeb/* /WebSphere/WebServerPlugIn/bin/ihs390WASPlugin_http.so:service_exit
ServerTerm /WebSphere/WebServerPlugIn/bin/ihs390WASPlugin_http.so:term_exit
For printing purposes, the ServerInit directive is displayed on two lines. These
directives must all stay on one line.
The ServerInit and ServerTerm directives relate to the WebSphere z/OS
HTTP plug-in only. These tell the HTTP server how to start and stop the
plug-in during startup and shutdown of the HTTP server.
The Service directives relate to the Web Application that run on WebSphere
Application Server for z/OS. You need one Service directive per Web
application. The Service directive specifies the high-level URI for the Web
application.
Keep in my mind that any high-level translation rule like:
Pass /* /web/pub/*
12 Tivoli and WebSphere Application Server for z/OS
37. should be placed after the WebSphere directives. If placed before, the
WebSphere directive may not be taken into account.
On the WebSphere z/OS HTTP plug-in side, one must create the plugin-cfg.xml
file. The path to this file and the file name must match the information provided in
the third part of the ServerInit directive in the httpd.conf file. This file tells the
plug-in how to redirect requests from virtual hosts with certain URIs to the right
application servers. Example 2-2 shows the content of our plugin-cfg.xml file.
Example 2-2 Sample plugin-cfg.xml file
<?xml version="1.0"?>
<Config>
<Log LogLevel="Warn" Name="/tmp/was401_plugin.trace"/>
<VirtualHostGroup Name="default_host">
<VirtualHost Name="*:6100"/>
</VirtualHostGroup>
<ServerGroup Name="PolicyIVP_Servers">
<Server Name="Server_PolicyIVP_SC61">
<Transport Hostname="wtsc61" Port="8080" Protocol="http"/>
</Server>
<Server Name="Server_PolicyIVP_SC62">
<Transport Hostname="wtsc62" Port="8085" Protocol="http"/>
</Server>
</ServerGroup>
<ServerGroup Name="Trade2_Servers">
<Server Name="Server_Trade2_SC61">
<Transport Hostname="wtsc61" Port="8081" Protocol="http"/>
</Server>
<Server Name="Server_Trade2_SC62">
<Transport Hostname="wtsc62" Port="8086" Protocol="http"/>
</Server>
</ServerGroup>
<ServerGroup Name="Trader_Servers">
<Server Name="Server_Trader_SC61">
<Transport Hostname="wtsc61" Port="8082" Protocol="http"/>
</Server>
<Server Name="Server_Trader_SC62">
<Transport Hostname="wtsc62" Port="8087" Protocol="http"/>
</Server>
</ServerGroup>
<UriGroup Name="PolicyIVP_UriGroup">
<Uri Name="/PolicyIVP/*"/>
</UriGroup>
<UriGroup Name="Trade2_UriGroup">
<Uri Name="/WebSphereSamples/*"/>
</UriGroup>
<UriGroup Name="Trader_UriGroup">
<Uri Name="/TraderWeb/*"/>
Chapter 2. Our WebSphere Application Server for z/OS environment 13
38. </UriGroup>
<Route ServerGroup="PolicyIVP_Servers" UriGroup="PolicyIVP_UriGroup"
VirtualHostGroup="default_host"/>
<Route ServerGroup="Trade2_Servers" UriGroup="Trade2_UriGroup"
VirtualHostGroup="default_host"/>
<Route ServerGroup="Trader_Servers" UriGroup="Trader_UriGroup"
VirtualHostGroup="default_host"/>
</Config>
You can check that your WebSphere z/OS HTTP plug-in is properly configured
and sending HTTP requests to the PolicyIVP IVP application server. For this
purpose, make sure that your IVP application server is started, then use a
browser to open the following URL:
http://<http_server_hostname>:<port>/PolicyIVP/cebit.html
If this operation is successful, you should see a window like Figure 2-2.
Figure 2-2 WebSphere Application for z/OS PolicyIVP window
14 Tivoli and WebSphere Application Server for z/OS
39. 2.3 WebSphere Application Server for z/OS and DB2
In order to observe the behavior of WebSphere Application Server interacting
with DB2, we choose to use the Trade2 sample application. Trade2 is a popular
sample application mainly used for benchmarking purposes. Figure 2-3 shows
Trade2 components and flow.
WebSphere for z/OS
Trade2 J2EE server
Web container EJB container
Trade2
Trade2
Trade2 Account
servlets
servlets
servlets entity EJB
Portfolio
Trade entity EJB
HTTP Access
session
client Beans Trade2
EJB Quote database
entity EJB
Trade2
Trade2
Trade2
servlets Buy
servlets
JSPs entity EJB
Figure 2-3 Trade2 components and flow
We choose to install the Trade2 application in a separate J2EE server so that we
do not interfere with any other already deployed application and so that we can
monitor Web applications independently. For example, when deploying a Web
application, when the conversation is activated, the J2EE server that runs this
application needs to be restarted. For availability concerns, you may not want
other Web applications to share the same J2EE server so that they would not
need to be stopped.
2.3.1 Creating a new J2EE server
Creating a new J2EE server with WebSphere Application Server for z/OS
requires five steps:
1. Define a new J2EE server with the SMEUI.
If you are a first time SMEUI user, refer to Appendix C, “The SMEUI: overview
and concepts” on page 307 to know where to download it and to understand
its main concepts.
In this step you must create a J2EE Server and a J2EE Server Instance as
well. You can use the BBOASR2 IVP server as an example. We suggest you
to use the same identities as the identities defined for BBOASR2 so that you
simplify your RACF customization.
Chapter 2. Our WebSphere Application Server for z/OS environment 15
40. Tip: If you want to use the HTTP transport handler included in Service Level
W401500, do not forget to add the server instance environment variable
BBOC_HTTP_PORT associated with the port number you want to activate.
2. Add a new Workload Manager (WLM) application environment. Use the WLM
administration ISPF dialog from TSO. The main menu from WLM
administration menu is shown in Figure 2-4.
EsssssssssssssssssssssssssssssssssssssssssssssN
e Choose Service Definition e
e e
e Select one of the following options. e
e __ 1. Read saved definition e
e 2. Extract definition from WLM e
e couple data set e
e 3. Create new definition e
e e
e F1=Help F2=Split F5=KeysHelp e
e F9=Swap F12=Cancel e
DsssssssssssssssssssssssssssssssssssssssssssssM
ENTER to continue
Figure 2-4 WLM administration main menu
We choose menu option 2 to extract the definition from the WLM couple data
set, choose option 9 to manage the application environment, and choose
option 1 to create a new application environment, as shown in Figure 2-5 on
page 17.
16 Tivoli and WebSphere Application Server for z/OS
41. Application-Environment Notes Options Help
--------------------------------------------------------------------------
Create an Application Environment
Command ===> ______________________________________________________________
Application Environment . . . TIOTRAD_________________________ Required
Description . . . . . . . . . Application environment TIOTRAD
Subsystem Type . . . . . . . . CB__ Required
Procedure Name . . . . . . . . TIOTRADS
Start Parameters . . . . . . . IWMSSNM=&IWMSSNM________________________
________________________________________
___________________________________
Limit on starting server address spaces for a subsystem instance:
1 1. No limit
2. Single address space per system
3. Single address space per sysplex
Figure 2-5 Creating a new WLM application environment
3. Set up the UNIX System Services configuration files
There are four configuration files for each J2EE server inside <WebSphere
home>/CB390/controlinfo/envfile/<plex name>/<instance name>:
current.env, jvm.properties, webcontainer.conf, and trace.dat. The
current.env file is generated by the SMEUI and does not need any
customization here. jvm.properties, webcontainer.conf, and trace.dat can be
taken from the IVP server directory and customized so that the
<instancename> is correct and so that the host name is right inside the
webcontainer.conf file.
Attention: If you use the z/OS HTTP plug-in to redirect requests from the
IBM HTTP server to the HTTP transport handler, then you have to specify
(for the host.<virtual_hostname>.alias directive in the webcontainer.conf
file) the host name with the port number and the host name without the port
number. For example:
host.default_host.alias=wtsc61.ibm.com:8081, wtsc61.ibm.com
4. Set up your RACF security.
Example 2-3 on page 18 shows the RACF commands that we issued. This
can be embedded in a JCL or issued from a TSO session. We are using the
default user IDs from the IVP process for the users that granted access.
Chapter 2. Our WebSphere Application Server for z/OS environment 17
42. Example 2-3 Sample RACF security setup
RDEFINE SERVER CB.*.TIOTRAD UACC(NONE)
PERMIT CB.*.TIOTRAD CLASS(SERVER) ID(CBASRU2) ACC(READ)
RDEFINE CBIND CB.BIND.TIOTRAD UACC(READ)
PERMIT CB.BIND.TIOTRAD CLASS(CBIND) ID(CBCTL1) ACCESS(CONTROL)
RDEFINE CBIND CB.TIOTRAD UACC(READ)
RDEFINE STARTED TIOTRAD.* STDATA(USER(CBACRU2) GROUP(CBCTL1)
RDEFINE STARTED TIOTRADS.* STDATA(USER(CBASRU2) GROUP(CBASR2)
SETROPTS RACLIST(CBIND, SERVER, STARTED) GENERIC(SERVER, STARTED) REFRESH
In Example 2-3, the following profiles are defined:
– SERVER class for CB.*.TIOTRAD. The SERVER class profile enables a
server region to get exclusive access to the request queue in WLM
created by the control region. A server region needs to be able to select
and dequeue requests from the WLM queue created by the associated
server control region. The profile is called
CB.<server_instance_name>.<server_name>. The server region should
have READ access, while everyone else no access.
– The CBIND class profiles are used by WebSphere to control which clients
can access a particular WebSphere Application Server for z/OS runtime or
application server. A profile is defined in the CBIND class, which indicates
which users can request access to application services related to this
control region. RACF profile format is CB.BIND.<server_name>. Everyone
should be able to READ this profile, while the control region needs a
CONTROL access.
– A second profile is defined in the CBIND class, which indicates which
users can request access to application components that run in server
regions related to this control region. RACF profile format is
CB.<server_name>. Ordinarily, this profile has a Universal access of
READ.
– STARTED class for assigning user ID to started tasks TIOTRAD and
TIOTRADS.
5. Create the procedures to start the application server control region and
server region. Once again, we strongly recommend using the IVP server
procedures as an example. Example 2-4 on page 19 shows a sample
procedure JCL for the control region.
18 Tivoli and WebSphere Application Server for z/OS
43. Example 2-4 Sample JCL for the control region procedure
//TIOTRAD PROC SRVNAME='TIOTRADA',
// PARMS=''
// SET RELPATH='controlinfo/envfile'
// SET CBCONFIG='/WebSphereTI/CB390'
//TIOTRAD EXEC PGM=BBOCTL,REGION=0M,
// PARM='/ -ORBsrvname &SRVNAME &PARMS'
//STEPLIB DD DISP=SHR,DSN=DB7K7.SDSNEXIT
// DD DISP=SHR,DSN=DB7K7.SDSNLOAD
//BBOENV DD PATH='&CBCONFIG/&RELPATH/&SYSPLEX/&SRVNAME/current.env'
//CEEDUMP DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE
//SYSOUT DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE
//SYSPRINT DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE
Example 2-5 shows a sample procedure JCL for the server region.
Example 2-5 Sample JCL for the server region procedure
//TIOTRADS PROC IWMSSNM='TIOTRADA',PARMS='-ORBsrvname '
// SET CBCONFIG='/WebSphereTI/CB390'
// SET RELPATH='controlinfo/envfile'
//TIOTRADS EXEC PGM=BBOSR,REGION=0M,TIME=NOLIMIT,
// PARM='/ &PARMS &IWMSSNM'
//STEPLIB DD DISP=SHR,DSN=BBO61.SBBOULIB
// DD DISP=SHR,DSN=DB7K7.SDSNEXIT
// DD DISP=SHR,DSN=DB7K7.SDSNLOAD
//BBOENV DD PATH='&CBCONFIG/&RELPATH/&SYSPLEX/&IWMSSNM/current.env'
//CEEDUMP DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
2.3.2 Installing the Trade2 application
The instructions for setting up and running the Trade2 application with
WebSphere Application Server for z/OS are available at:
http://www.ibm.com/software/webservers/appserv/zos_os390/doc/v401/pstore/trade.
html
The following steps explain additional information from the Web page.
1. Downloading the Trade2 application
The Trade 2 Application is contained in the TradeSample.ear file included in
the DB2_AE.zip file. This EAR file, along with an Installation Readme, is
available at:
http://www-4.ibm.com/software/webservers/appserv/wpbs_download.html
Chapter 2. Our WebSphere Application Server for z/OS environment 19