Accessing DB2 for z/OS from WebSphere applications
In this chapter, we describe the structure of enterprise Java applications accessing DB2 data through WebSphere Application Server.
This chapter covers the following topics:
For more information, refer to WebSphere Application Server V8.5 Concepts, Planning, and Design Guide, SG24-80222.
2.1 Application server infrastructure
WebSphere Application Server provides the environment to run your solutions and to integrate them with every platform and system. The core component in WebSphere Application Server is the application server runtime environment. An application server provides the infrastructure for running the applications that run your business. It insulates the infrastructure from the hardware, operating system, and network (Figure 2-1).
Figure 2-1 Basic presentation of an application server and its environment
An application server provides a set of services that business applications can use, and serves as a platform to develop and deploy these applications. The application server acts as middleware between back-end systems and clients. It provides a programming model, an infrastructure framework, and a set of standards for a consistent designed link between them. As business needs evolve, new technology standards become available. Since 1998, WebSphere Application Server has grown and adapted itself to new technologies and to new standards. It provides an innovative and cutting-edge environment so that you can design fully integrated solutions and run your business applications.
WebSphere Application Server is a key SOA building block, providing the role of the business application services (circled in Figure 2-2) in the SOA reference architecture.
Figure 2-2 Position of business application services in an SOA reference architecture
From an SOA perspective, you can perform the following functions with WebSphere Application Server:
•Build and deploy reusable application services quickly and easily
•Run services in a secure, scalable, highly available environment
•Connect software assets and extend their reach
•Manage applications effortlessly
•Grow as your needs evolve, reusing core skills and assets
WebSphere Application Server is available on a range of platforms and in multiple packages to meet specific business needs. By providing an application server to run specific applications, it also serves as the base for other WebSphere products and many other IBM software products.
The packaging options available for WebSphere Application Server provide a level of application server capabilities to meet the requirements of various application scenarios. Although these options share a common foundation, each provides unique benefits to meet the needs of applications and the infrastructure that supports them. At least one WebSphere Application Server product fulfills the requirements of any particular project and its supporting infrastructure. As your business grows, the WebSphere Application Server family provides a migration path to more complex configurations.
The following packages are available:
•WebSphere Application Server—Express V8.5
•WebSphere Application Server—Base V8.5
•WebSphere Application Server for Developers V8.5
•WebSphere Application Server Network Deployment V8.5
•WebSphere Application Server for z/OS V8.5
Figure 2-3 summarizes various WebSphere Application Server packaging options.
Figure 2-3 WebSphere Application Server editions
Figure 2-4 summarizes the main components that are included in each WebSphere Application Server package.
Figure 2-4 Packaging Structure WebSphere Application Server V8.5
2.2 Related products
IBM offers complementary software products for WebSphere Application Server that provide a simplified development process, enhanced management features, and a high performance runtime environment. This section provides information about the following related products:
2.2.1 WebSphere Application Server Community Edition
WebSphere Application Server Community Edition is a lightweight single-server Java EE application server that is built on Apache Geronimo, which is the open source application server project of the Apache Software Foundation. This edition of WebSphere Application Server is based on open source code and is available for download at no charge.
 
Product information: The code base of WebSphere Application Server Community Edition is different from the code base for WebSphere Application Server. WebSphere Application Server Community Edition is not a different packaging option for WebSphere Application Server. It is a separate product.
WebSphere Application Server Community Edition is a powerful alternative to open source application servers and has the following features:
•Brings together the best related technologies across the broader open source community to support Java EE specifications such as the following examples:
 – Apache Aries
 – Apache MyFaces
 – Apache OpenEJB
 – Apache Open JPA
 – Apache ActiveMQ
 – TranQL
•Includes support for Java EE 6 and Java SE 6
•Supports the JDK from IBM and Oracle
•Can be used as a run time for Eclipse with its plug-in
•Includes an open source Apache Derby database, which is a small-footprint database server with full transactional capability
•Contains an easy-to-use administrative console application
•Supports product binary files and source code as no-charge downloads from the IBM website
•Provides optional fee-based support for WebSphere Application Server Community Edition from IBM Technical support teams
•Can be included in advanced topologies and managed with the Intelligent Management functionality of WebSphere Application Server V8.5
For more information and the option to download WebSphere Application Server Community Edition, see:
2.2.2 WebSphere eXtreme Scale
WebSphere eXtreme Scale provides the technology to enhance business by extending the data-caching concept with advanced features. With WebSphere eXtreme Scale, business applications can process large volumes of transactions with efficiency and linear scalability. WebSphere eXtreme Scale operates as an in-memory data grid that dynamically caches, partitions, replicates, and manages application data and business logic across multiple servers. It provides transactional integrity and not apparent fail over to ensure high availability, high reliability, and consistent response times.
For more information about WebSphere eXtreme Scale, see:
2.2.3 Rational Application Developer for WebSphere Software V8.5
Rational Application Developer for WebSphere Software is a full-featured Eclipse-based IDE that includes a comprehensive set of tools to improve developer productivity. It is the only Java IDE tool that you must design, develop, and deploy your applications for WebSphere Application Server.
Rational Application Developer for WebSphere Software adds functions to Rational Application Developer Standard Edition (Figure 2-5).
Figure 2-5 Rational development tools
Rational Application Developer for WebSphere Software includes the following functions:
•Concurrent support for Java Platform, Enterprise Edition 1.2, 1.3, 1.4, Java EE 5, and Java EE 6 specifications and support for building applications with JDK 5 and JRE 1.6
•EJB 3.1 productivity features
•Visual editors such as:
 – Domain modeling
 – UML modeling
 – Web development
•Web services and XML productivity features
•Portlet development tools
•Relational data tools
•WebSphere Application Server V6.1, V7, V8, and V8.5 test servers
•Web 2.0 development features for visual development of responsive Rich Internet Applications with Ajax and Dojo
•Integration with the Rational Unified Process and the Rational tool set, which provides the end-to-end application development lifecycle
•Application analysis tools to check code for coding practices
Examples are provided for preferred practices and issue resolution.
•Enhanced runtime analysis tools, such as memory leak detection, thread lock detection, user-defined probes, and code coverage
•Component test automation tools to automate test creation and manage test cases
•WebSphere Adapters support, including CICS, IBM IMS, SAP, Siebel, JD Edwards, Oracle, and PeopleSoft
•Support for Linux and Microsoft Windows operating systems.
For more information about Rational Application Developer for WebSphere Software V8, see:
2.3 Core concepts of WebSphere Application Server
The following concepts are central to understanding the architecture of WebSphere Application Server V8.5:
A person in an administrative role must understand these concepts to manage WebSphere Application Server regularly. Understanding these concepts and how they apply to your environment facilitates designing and troubleshooting.
This section provides information about these concepts. You can find additional concepts about WebSphere Application Server that build on these core concepts in 2.4, “Server configurations” on page 41.
2.3.1 Applications
At the heart of WebSphere Application Server is the ability to run applications, including the following types:
•Enterprise
•Business-level
•Middleware
Figure 2-6 illustrates the applications that run in the Java virtual machine (JVM) of WebSphere Application Server.
Figure 2-6 Applications running in WebSphere Application Server
Java Platform, Enterprise Edition applications
Java Platform, Enterprise Edition (Java EE) is the standard for developing, deploying, and running enterprise applications.
WebSphere Application Server V8.5 supports the Java EE 6 specification. New and existing enterprise applications can take advantage of the capabilities added by Java EE 6. If you decide not to use the Java EE 6 capabilities, portable applications continue to work with identical behavior on the current version of the platform.
 
Version note: IBM WebSphere SDK Java Technology Edition V6.0 is installed by default with WebSphere Application Server V8.5. Optionally, you can install IBM WebSphere SDK Java Technology Edition V7.0 in addition to the default Java version by using IBM Installation Manager. In WebSphere Application Server V8.5, you can select between Java SDK V6 and V7.
The Java EE programming model has the following types of application components:
•Enterprise JavaBeans (EJB)
•Servlets and JavaServer Pages (JSP) files
•Application clients (Java Web Start Architecture 1.4.2)
The primary development tool for WebSphere Application Server Java EE 6 applications is IBM Rational Application Developer for WebSphere V8.5. It contains tools to create, test, and deploy Java EE 6 applications. Java EE applications are packaged as enterprise archive (EAR) files.
For more information about Java EE 6 supported specifications, see the JSR page on the Java Community Process website at:
For more information about web application specifications, see the following resources:
•JSR 154, 53 and 315 (Java Servlet 3.0 specification)
•JSR 252 and127 (Apache MyFaces JSF 2.0 specification)
•JSR 318 (EJB 3.1 specification)
For more information, see the following resources:
•Reference information about developing enterprise OSGi applications for WebSphere Application Server:
•IBM Education Assistance an online presentation about developing modular and dynamic OSGi applications:
•Preferred practices for working with OSGi applications:
•Supported specifications for OSGi applications:
2.3.2 Containers
Containers are specialized to run specific types of applications and can interact with other containers by sharing session management, security, and other attributes. Figure 2-7 illustrates applications that run in different containers inside the JVM. Containers provide runtime support for applications.
Figure 2-7 WebSphere Application Server V8.5 container services
WebSphere Application Server V8.5 includes the following logical containers:
•The web container processes servlets, JSPs, and other types of server-side objects.
Each application server run time has one logical web container. Requests are received by the web container through the web container inbound transport chain. The chain consists of a Transmission Control Protocol (TCP) inbound channel that provides the connection to the network, an HTTP inbound channel that serves HTTP 1.0 and 1.1 requests. It also includes a web container channel over which requests for servlets and JSPs are sent to the web container for processing. Requests for HTML and other static content that are directed to the web container are served by the web container inbound chain.
•The Enterprise JavaBeans (EJB) container provides all of the runtime services that are needed to deploy and manage enterprise beans.
This container is a server process that handles requests for both session and entity beans. The container provides many low-level services, including transaction support. From an administrative viewpoint, the container manages data storage and retrieval for the contained enterprise beans. A single container can host more than one JAR file.
•The Batch container, new in WebSphere Application Server V8.5, is where the job scheduler runs jobs that are written in XML job control language (xJCL).
The batch container provides an execution environment for the execution of batch applications that are based on Java EE. Batch applications are deployed as EAR files and follow either the transactional batch or compute-intensive programming models.
The following containers are logical extensions of the web container main function:
•The portlet container provides the runtime environment to process JSR 286-compliant portlets. A simple portal framework is built on top of the web container to render a single portlet into a full browser page.
•The SIP container processes applications that use at least one SIP servlet that are written to the JSR 289 specification. It provides network services over which it receives requests and sends responses. It determines which applications to start and in what order. The container supports the UDP, TCP, and TLS/TCP protocols.
•The OSGi Blueprint container processes OSGi applications that are based on the OSGi framework. The OSGi Blueprint is separate from Java EE technology. However, they can be combined to deploy modular applications that use both Java EE 6/7 and
OSGi R4 V4.2 technologies.
2.3.3 Application servers
At the core of each product in the WebSphere Application Server family is an application server. The application server is the platform on which Java language-based applications run (Figure 2-8). It provides services that can be used by business applications, such as database connectivity, threading, and workload management.
Figure 2-8 Relationship between applications and WebSphere Application Server
The following packaging options of the WebSphere Application Server family are presented in this section:
•IBM WebSphere Application Server Express V8.5, referred to as Express
•IBM WebSphere Application Server V8.5, referred to as Base
•IBM WebSphere Application Server Network Deployment V8.5, referred to as Network Deployment or ND
•IBM WebSphere Application Server Hypervisor Edition V7, referred to as
Hypervisor Edition
•IBM WebSphere Application Server for z/OS V8.5, referred to as WebSphere Application Server for z/OS
Each member has essentially the same main architectural structure that is shown in Figure 2-9. They are built on a common code base. The difference between the options involves licensing terms and platform support.
Figure 2-9 WebSphere Application Server architecture for Base and Express
The Base and Express platforms are limited to stand-alone application servers. With the Network Deployment configuration (Figure 2-10), more advanced topologies provide the following advantages:
•Workload management
•Scalability
•Near-continuous availability
•Central management of multiple application servers
These advantages are important for mission-critical applications. You can also manage multiple base profiles centrally, but you do not have workload management and the same capabilities for those base profiles.
Figure 2-10 WebSphere Application Server architecture - Network Deployment configuration
Stand-alone application servers
All WebSphere Application Server packages support a single stand-alone server environment. With a stand-alone configuration, each application server acts as a unique entity, functioning independently from other application servers. An application server runs one or more applications, and provides the services that are required to run these applications. Each stand-alone server is created by defining an application server profile (Figure 2-11).
Figure 2-11 Stand-alone application server configuration
A stand-alone server can be managed from its own administrative console. You can also use the wsadmin scripting facility in WebSphere Application Server to perform every function that is available in the administrative console application.
Multiple stand-alone application servers can exist on a system. You can either use independent installations of the WebSphere Application Server product binary files, or create multiple application server profiles within one installation. However, stand-alone application servers do not provide workload management or fail over capabilities. They are isolated from each other.
With WebSphere Application Server for z/OS, you can use workload load balancing and response time goals on a transactional base. You can also use balancing on a special clustering mechanism, the multiple servant regions, with a stand-alone application server.
 
Remember: With WebSphere Application Server V8.5, you can manage stand-alone servers from a central point by using administrative agents and a job manager.
Distributed application servers
With Network Deployment, you can build a distributed server configuration to enable central administration, workload management, and fail over. In this environment, you integrate one or more application servers into a cell that is managed by a central administration instance, a deployment manager. For more information, see 2.3.7, “Deployment manager” on page 41. The application servers can be on the same system as the deployment manager or on multiple separate systems. Administration and management are handled centrally from the administration interfaces of the deployment manager (GUI or scripting) as illustrated in Figure 2-12.
Figure 2-12 Distributed application servers with WebSphere Application Server V8.5
With a distributed server configuration, you can create multiple application servers to run unique sets of applications, and manage those applications from a central location. More importantly, you can cluster application servers to allow for workload management and fail over capabilities. Applications that are installed in the cluster are replicated across the application servers. The cluster can be configured so when one server fails, another server in the cluster continues processing. Workload is distributed among containers in a cluster by using a weighted round-robin scheme.
 
Tip for z/OS: The weighted round-robin mechanism is replaced by the integration of WebSphere Application Server for z/OS in the Workload Manager (WLM). The WLM is a part of the operating system. Requests can be dispatched by using this configuration to a cluster member according to real-time load and regardless of whether the member reaches its defined response time goals.
Application servers types
WebSphere Application Server V8.5 provides the following server types, which can be defined and configured by using the administrative console:
•WebSphere Application Server
•Generic server
•On-demand router
•PHP server
•WebSphere proxy server
•WebSphere MQ server
•Community Edition server
•Web server
With the mixed server environment and mixed node definitions, other existing server types can be added and administered. These types include external WebSphere application servers, Apache Server, and Custom HTTP Server.
2.3.4 Profiles
WebSphere Application Server runtime environments are built by creating set of configuration files, named profiles, that represent a WebSphere Application Server configuration. The following categories of WebSphere Application Server files are available, as illustrated in Figure 2-13:
•Product files are a set of read-only static files or product binary files that are shared by any instances of WebSphere Application Server.
•Configuration files (profiles) are a set of user-customizable data files. This file set includes WebSphere configuration, installed applications, resource adapters, properties, and log files.
Figure 2-13 Anatomy of a profile
The Customization Toolbox allows you to create separate environments, such as for development or testing, without a separate product installation for each environment. Different profile templates are available in WebSphere Application Server V8.5 through the Customization Toolbox Profile Management Tool (PMT):
•Cell
A cell template contains a federated application server node and a deployment manager.
•Deployment manager
The Network Deployment profile provides the necessary configuration for starting and managing the deployment manager server.
•Default profile (for stand-alone servers)
This server default profile provides the necessary configuration file for starting and managing an application server, and all the resources that are needed to run
enterprise applications.
•Administrative agent
This profile is used to create the administrative agent to administer multiple stand-alone application servers.
•Default secure proxy
This profile is available when you install the DMZ secure proxy server feature.
•Job manager
This profile coordinates administrative actions among multiple deployment managers, and administers multiple stand-alone application servers. It also asynchronously submits jobs to start servers, and completes various other tasks.
•Custom
This profile, also known as Empty Node because it has no application server inside, can be federated to a deployment manager cell later. It is used to host application servers, clusters, an on-demand router, and other Java processes.
 
The Liberty profile: Do not confuse the Liberty profile with the concept of a profile that is created by the PMT in previous versions of WebSphere Application Server. The Liberty profile provides a composable and dynamic application server runtime environment on WebSphere Application Server V8.5. The Liberty profile is a subset of base functions of the WebSphere Application Server, which is installed separately.
You can create compressed files that contain all or subsets of the Liberty profile server installation. You can then extract these files on other target hosts as a substitute for the product installation.
With a simpler configuration model based on XML, you do not need to create a profile by using the PMT to create Liberty profile application servers.
Each profile contains files that are specific to that run time (such as logs and configuration files). You can create profiles during and after installation. After you create the profiles, you can perform further configuration and administration by using WebSphere
administrative tools.
Each profile is stored in a unique directory path (Figure 2-14), which is selected by the user when the profile is created. Profiles are stored in a subdirectory of the installation directory by default, but can be located anywhere.
Figure 2-14 Profiles directory structure of WebSphere Application Server V8.5 on a Windows system
By creating various profiles, you can create a distributed server configuration by using one of the following methods:
•Create a deployment manager profile to define the deployment manager, and then create one or more custom node profiles. The nodes that are defined by each custom profile can be federated into the cell that is managed by the deployment manager. You can federate these nodes during profile creation, or manually later. The custom nodes can exist inside the same operating system image as the deployment manager or in another operating system instance. You can then create application servers by using the administrative console or wsadmin scripts.
This method is useful when you want to create multiple nodes, multiple application servers on a node, or clusters.
•Create a deployment manager profile to define the deployment manager. Then, create one or more application server profiles, and federate these profiles into the cell that is managed by the deployment manager. This process adds both nodes and application servers into the cell. The application server profiles can exist on the deployment manager system or on multiple separate systems or z/OS images.
This method is useful in development or small configurations. Creating an application server profile gives you the option of having the sample applications installed on the server. When you federate the server and node to the cell, any installed applications can be carried into the cell with the server.
•Create a cell profile. This method creates both a deployment manager profile and an application server profile. The application server node is federated to the cell. Both profiles are on the same system.
This method is useful in a development or test environment. Creating a single profile provides a simple distributed system on a single server or z/OS image.
2.3.5 Nodes, node agents, and node groups
This section provides details about the concepts of nodes, node agents, and node groups.
Nodes
A node is an administrative grouping of application servers for configuration and operational management within one operating system instance. You can create multiple nodes inside one operating system instance, but a node cannot leave the operating system boundaries. A stand-alone application server configuration has only one node. With Network Deployment, you can configure a distributed server environment that consists of multiple nodes that are managed from one central administration server.
From the administrative console, you can also configure middleware nodes (defined into a generic server cluster) to manage middleware servers by using a remote agent.
Figure 2-15 illustrates nodes that are managed from a single deployment manager.
Figure 2-15 Node concept - WebSphere Application Server Network Deployment configuration
Node agents
In distributed server configurations, each node has a node agent that works with the deployment manager to manage administration processes. A node agent is created automatically when you add (federate) a stand-alone application server node to a cell. Node agents are not included in the Base and Express configurations because a deployment manager is not needed in these architectures. In Figure 2-15, each node has its own node agent that communicates directly or remotely with the deployment manager. The node agent is an administrative server that runs on the same system as the node. It monitors the application servers on that node, routing administrative requests from the deployment manager to those application servers.
Node groups
A node group is a collection of nodes within a cell that have similar capabilities in terms of installed software, available resources, and configuration. A node group is used to define a boundary for server cluster formation so that the servers on the same node group host the same applications.
A node group validates that the node can run certain functions before allowing them. For example, a cluster cannot contain both z/OS nodes and non-z/OS nodes. In this case, you can define multiple node groups, one for the z/OS nodes and one for non-z/OS nodes. A DefaultNodeGroup is created automatically. The DefaultNodeGroup contains the deployment manager and any new nodes with the same platform type. A node can be a member of more than one node group.
 
Sysplex on z/OS: On the z/OS platform, a node must be a member of a system complex (sysplex) node group. Nodes in the same sysplex must be in the same sysplex node group. A node can be in one sysplex node group only. A sysplex is the z/OS implementation of a cluster. This technique uses distributed members and a central point in the cluster. It uses a coupling facility for caching, locking, and listing. The coupling facility runs special firmware, the Coupling Facility Control Code (CFCC). The members and the coupling facility communicate with each other by using a high-speed InfiniBand memory-to-memory connection of up to 120 Gbps.
Figure 2-16 shows a single cell that contains multiple nodes and node groups.
Figure 2-16 Examples of a node and node group
2.3.6 Cells
A cell is a grouping of nodes into a single administrative domain. A cell encompasses the entire management domain. In the Base and Express configurations, a cell contains one node, and that node contains one server. The left side of Figure 2-17 on page 40 illustrates a system with two cells that are each accessed by their own administrative console. Each cell has a node and a stand-alone application server.
In a Network Deployment environment (the right side of Figure 2-17), a cell can consist of multiple nodes and node groups. These nodes and groups are all administered from a single point, the deployment manager. Figure 2-17 shows a single cell that spans two systems that are accessed by a single administrative console. The deployment manager is administering the nodes.
Figure 2-17 Cells representation in stand-alone and network deployment environments
A cell configuration that contains nodes that are running on the same platform is called a homogeneous cell.
It is also possible to configure a cell that consists of nodes on mixed platforms. With this configuration, other operating systems can exist in the same WebSphere Application Server cell. Cells can span z/OS sysplex environments and other operating systems. For example, z/OS nodes, Linux nodes, UNIX nodes, and Windows system nodes can exist in the same WebSphere Application Server cell. This configuration is called a heterogeneous cell. A heterogeneous cell requires significant planning.
Figure 2-18 shows a heterogeneous cell, where node groups are defined for different operating systems.
Figure 2-18 A heterogeneous cell with the coexistence of distributed and z/OS nodes
2.3.7 Deployment manager
The deployment manager is the central administration point of a cell that consists of multiple nodes and node groups in a distributed server configuration. It is similar to the configuration shown in Figure 2-15 on page 38. The deployment manager communicates with the node agents of the cell that it is administering to manage the applications servers within the node. The deployment manager provides management capability for multiple federated nodes, and can manage nodes that span multiple systems and platforms. A node can be managed by a single deployment manager, and the node must be federated to the cell of that
deployment manager.
The configuration and application files for all nodes in the cell are centralized into the master repository. This centralized repository is managed by the deployment manager and regularly synchronized with local copies that are held on each of the nodes. If the deployment manager is not available in the cell, the node agents and the application servers cannot synchronize configuration changes with the master repository. This limitation continues until the connection with deployment manager is reestablished.
 
 
Version note: A high availability deployment manager is available in WebSphere Application Server V8.5. You can configure a hot-standby deployment manager to recover failures of the currently active deployment manager.
2.4 Server configurations
With WebSphere Application Server, you can build various server environments that consist of single and multiple application servers that are maintained from central
administrative points.
A system is defined as one of the following types:
•A server system (a physical machine) that contains only one operating system
•An operating system virtual image where the host server system contains multiple operating system images
•A z/OS image
With WebSphere Application Server, you can create two types of configurations in a single cell environment:
•Single system configurations
•Multiple systems configurations
Single system configurations
With the Base, Express, and Network Deployment packages, you can create a cell that contains only a single node with a single application server (Figure 2-19).
Figure 2-19 Single cell configuration in Base and Express packages
Single system is the only configuration option with Base and Express. The cell is created when you create the stand-alone application server profile.
A node agent at each node is the contact point for the deployment manager during cell administration. A single system configuration in a distributed environment includes all processes in one system as illustrated in Figure 2-20.
Figure 2-20 Cell configuration option in Network Deployment: Single system
Multiple system configurations
A Network Deployment environment allows you to install the WebSphere Application Server components on systems and locations that suit your requirements. With the Network Deployment package, you can create multiple systems configurations.
Figure 2-21 shows the deployment manager that is installed on one system (System A) and each node on a different system (System B and System C). The servers can be mixed platforms or the same platform. In this example, System A can be an IBM AIX® system, System B can be a Windows operating system, and System C can be a z/OS image.
Figure 2-21 Cell configuration option in Network Deployment: Multiple systems
Using the same logic, other combinations can be installed. For example, you can install the deployment manager and a node on one system with additional nodes installed on
separate systems.
2.5 Clusters and high availability
A cluster is a collection of servers that are managed together. With clusters, enterprise applications can scale beyond the amount of throughput that can be achieved with a single application server. Also, enterprise applications are made highly available because requests are automatically routed to the running servers in the event of a failure. The servers that are members of a cluster can be on different host systems. A cell can include no clusters, one cluster, or multiple clusters.
WebSphere Application Server provides clustering support for the following types of servers:
•Application server clusters
•Proxy server clusters
•Generic server clusters
•Dynamic clusters
An application server cluster is a logical collection of application server processes that provides workload balancing and high availability. It is a grouping of application servers that run an identical set of applications that are managed so that they behave as a single application server (parallel processing). WebSphere Application Server Network Deployment or WebSphere Application Server for z/OS is required for clustering.
Application servers that are a part of a cluster are called cluster members. When you install, update, or delete an application, the updates (changes) are distributed automatically to all cluster members. By using the rollout update option, you can update and restart the application servers on each node. This process can be done one node at a time, providing continuous availability of the application to the user.
Application server clusters have the following important characteristics:
•A cluster member can belong to only a single cluster.
•Clusters can span server systems and nodes, but they cannot span cells.
•A cluster cannot span from distributed platforms to z/OS.
•A node group can be used to define groups of nodes that have enough in common to host members of a cluster. All cluster members in a cluster must be in the same node group.
2.5.1 Vertical cluster
When cluster members are on the same system, the topology is known as vertical scaling or vertical clustering. Figure 2-22 illustrates a simple example of a vertical cluster.
Figure 2-22 Vertical cluster
Vertical clusters offer fail over support within one operating system image, provide processor level fail over, and increase resource usage.
2.5.2 Horizontal cluster
Horizontal scaling or horizontal clustering refers to cluster members that are spread across different server systems and operating system types (Figure 2-23). In this topology, each system has a node in the cell that is holding a cluster member. The combination of vertical and horizontal scaling is also possible.
Figure 2-23 Horizontal cluster
Horizontal clusters increase availability by removing the bottleneck of using only one physical system and increasing the scalability of the environment. Horizontal clusters also support system fail over.
2.5.3 Mixed cluster
Figure 2-24 illustrates a cluster that has four cluster members and combines vertical and horizontal clustering. The cluster uses multiple members inside one operating system image (on one system) and that are spread over multiple physical systems. This configuration provides a mix of fail over and performance.
Cluster members cannot span cells.
Figure 2-24 Vertical and horizontal clustering
2.5.4 Mixed-node versions in a cluster
A WebSphere Application Server Network Deployment V8.5 cluster can contain nodes and application servers from WebSphere Application Server V7 and V8. The topology that is illustrated in Figure 2-25 on page 47 contains mixed version nodes within a cluster. You can upgrade any node in the cell and leave the other nodes at a previous release level. Consider using this feature only for migration scenarios.
Figure 2-25 Mixed version nodes that are clustered in a cell
2.5.5 Dynamic cluster
Dynamic clusters are application deployment targets that operate at the application layer virtualization. Dynamic clusters provide capabilities to better manage dynamic workload by using the on-demand router server.
Keep in mind the following key points about dynamic clustering:
•Dynamic clusters grow and shrink depending on the workload demand.
•Dynamic clusters work closely with the on-demand router to ensure even distribution of workload among the cluster members.
2.5.6 Cluster workload management
This section highlights cluster workload management on distributed systems. It also addresses considerations for the z/OS platform.
Cluster workload management on distributed systems
Workload management, which is implemented by the use of application server clusters, optimizes the distribution of client processing requests. WebSphere Application Server can handle the workload management of servlet and EJB requests. HTTP requests can be workload-managed by using tools similar to a load balancer.
Using an HTTP traffic-handling device, such as IBM HTTP Server and the web server plug-in, is a simple and efficient way to front end the WebSphere HTTP transport.
WebSphere Application Server implements a server-weighted round-robin routing policy to ensure a balanced routing distribution. The policy is based on the set of server weights that is assigned to members of a cluster. In horizontal clustering, where each node is on a separate server system, the loss of one server system does not disrupt the flow of requests. Instead, requests are routed to cluster members on other nodes. In a horizontal cluster, the loss of the deployment manager has no impact on operations and primarily affects configuration activities. You can still use administration scripts to manage the WebSphere Application Server environment.
Cluster workload management consideration on z/OS
Workload management for EJB containers that run on z/OS can be performed by configuring the web container and EJB containers on separate application servers. Multiple application servers with the EJB containers can be clustered, enabling the distribution of enterprise bean requests between EJB containers on different application servers.
Instead of using a static round-robin procedure, workload management on the z/OS platform introduces a finer granularity and the use of real-time performance data. You can use these features to determine which member to process a transaction on.
 
Remember: Workload management is achieved by using the WLM subsystem in combination with the Sysplex Distributor (SD) component of z/OS. The Sysplex Distributor receives incoming requests through a Dynamic Virtual IP address and prompts WLM to indicate to which cluster member the request should be transmitted. WLM tracks how well each cluster member is achieving its performance goals in terms of response time. Therefore, it chooses the one that has the best response time to process the work.
You can classify incoming requests according to their importance. For example, requests that come from a platinum-ranked customer can be processed with higher importance (and therefore faster) than a silver-ranked customer.
When resource constraints exist, the WLM component can ensure that the member that processes a higher prioritized request gets additional resources. This system protects the response time of your most important work.
 
WLM changes: The WLM component can change the amount of processor, I/O, and memory resources that are assigned to the different operating system processes (the address spaces). To decide whether a process is eligible for receiving additional resources, the system checks whether the process meets its defined performance targets, and whether more important work is in the system. This technique is run dynamically so that there is no need for manual interaction after the definitions are made by the system administrator (the system programmer).
2.6 Database access from WebSphere Application Server
Java Platform, Enterprise Edition components that are deployed in a WebSphere Application Server often require access to data stored in databases such as DB2 for z/OS.
Accessing data out of a Java EE environment (which WebSphere Application Server is) involves a key concept that is important to understand -- the specifics of the actual data system are hidden from the application; they are hidden behind a standardized layer of abstraction. What the Java EE specification provides is a standardized API for accessing data, with the vendor of the actual data system responsible for implementing the code behind the API layer. The implementation that is offered by the vendors is called a “connector” as shown in Figure 2-26.
Figure 2-26 Accessing data from Java applications on WebSphere
The standardized API for relational databases is defined by what is called Java Database Connectivity Specification (JDBC).
2.6.1 JDBC driver types
The role of the JDBC driver is to implement the objects, methods, and data types that are defined in the JDBC specification. Currently DB2 for z/OS supports the following driver types:
Type 2
Type 2 drivers are written partly in the Java programming language and partly in native code. These drivers use a native client library specific to the data source to which they connect. JDBC type 2 connectivity should be used only when running Java applications - whether stand-alone Java applications or applications running in WebSphere Application Server on z/OS - on z/OS accessing DB2 data on z/OS in the same LPAR. This type of connectivity is recommended when the applications are deployed in WebSphere Application Server on z/OS accessing data on DB2 for z/OS on the same LPAR.
Type 4
Type 4 drivers are written in pure Java and implement the database protocol for a specific data source. The client connects directly to the data source. DRDA is the protocol that is used when connecting to a DB2 system as a data source. The type 4 driver is fully portable because it is written purely in Java.
The IBM implementation of these drivers is called IBM Data Server Driver for JDBC and SQLJ. For details, see 3.2, “IBM Data Server Drivers and Clients” on page 87.
2.6.2 Concept of JDBC providers
JDBC provider is way to define to WebSphere Application Server - irrespective of platform - the location of the Java classes that must be used by the application server when connecting to the database. There are two types of providers that WebSphere Application Server supports when it comes to JDBC access to DB2 for z/OS. They are the
•DB2 Universal JDBC Driver Provider
•DB2 Universal JDBC Driver Provider (XA)
The DB2 Universal JDBC Driver Provider (XA) should be used only if applications running in WebSphere Application Server meet the two following criteria:
•Require global transaction support
•Want to use JDBC type 4 access to DB2 for z/OS
The DB2 Universal JDBC Driver Provider should be used only if applications running in WebSphere Application Server meet the either of the following criteria:
•Applications running on WebSphere Application Server on z/OS and access DB2 for z/OS on the same LPAR using JDBC type 2 access. This provider supports both 1-phase and 2-phase commit processing
•Applications running on WebSphere Application Server (irrespective of platform) that need access to DB2 for z/OS and do not require global transaction support
2.6.3 Concept of data sources
Applications that run in WebSphere Application Server look at a DB2 server through a data source object, which is logically addressable through a name, recommended to be in the form jdbc/data-name called the JNDI name. The purpose of the data source is to define to WebSphere Application Server, the connection information of the database such as the database name, the type of connection to use (type 2 or type 4), IP address where the database is located, the port number the database uses to receive connections and the user ID and password to use when the application server establishes a connection to the database. The data source definition in WebSphere Application Server also allows users to define the following important settings:
•Connection Pool configuration
•Prepared Statement Cache setting
•IBM Data Server Driver for JDBC and SQLJ custom properties, such as current schema
Data sources are defined to JDBC providers in WebSphere Application Server.
2.6.4 WebSphere Application Server connection pooling
Connection pooling can improve the response time of any application requiring connections to access a data source, especially web-based applications. To avoid the impact of acquiring and closing connections, WebSphere Application Server provides connection pooling for connection reuse (caching of JDBC connections). WebSphere Application Server enables administrators to establish a pool of database connections that can be reused. They are defined with the panel shown in Figure 2-27.
Figure 2-27 WebSphere Application Server database connections
The following is a brief description of the properties:
Connection Timeout How long to attempt connection creation before timeout
Max Connections Maximum number of connections from JVM instance
Min Connections Lazy minimum number of connections in the pool
Reap Time How often cleanup of pool is scheduled in seconds
Unused Timeout How long to let a connection sit in the pool unused
Aged Timeout How long to let a connection live before recycling
Purge Policy After StaleConnection, does the entire pool get purged or only individual connection
Information about these properties can be found at the following websites:
To get the most out of connection pooling, consider the following items:
•If an application creates a resource, the application should explicitly close it after the resource is no longer being used
All JDBC resources that have been obtained by an application should be explicitly closed by the same application. These include connections, CallableStatements, PreparedStatements, ResultSets, and others. Be sure to close resources even in the case of a failure. For example, each PreparedStatement object in the cache can have one or more result sets associated with it. If a result set is opened and not closed, even though you close the connection, that result set is still associated with the prepared statement in the cache. Each of the result sets has a unique JDBC cursor that is attached to it. This cursor is kept by the statement and is not released until the prepared statement is cleared from the WebSphere Application Server prepared statement cache.
•Obtaining and closing the connection in the same method.
When possible, we recommend that an application obtains and closes its connection in the same method in which the connection is requested. This keeps the application from holding resources that are not being used, and leaves more available connections in the pool for other applications. Additionally, it removes the temptation to use the same connection for multiple transactions. There might be times in which this is not feasible, such as when using BMP.
•Do not reuse the statement handle without closing it first.
To prevent resource leakage, close prepared statements before reusing the statement handle to prepare a different SQL statement with the same connection.
•Set WebSphere Application Server connection Unused Timeout to a value smaller than DB2 for z/OS idle thread timeout to avoid stale connection conditions.
•Consider setting min connections to 0 (zero)
•Consider setting WebSphere Application Server “aged timeout” to less than 5 min, recommended 120 sec to reduce exposure of long living threads
Heterogeneous connection pooling
WebSphere Application Server also provides what is called a heterogeneous connection pool. Heterogeneous pooling is the ability to share one data source and hence one connection pool among different applications that are deployed in the same WebSphere Application Server that try to access the data in DB2 for z/OS. This feature helps customers address the impact of having to manage connections at individual data sources and also helps them avoid a proliferation of data source definitions in WebSphere Application Server going to the same DB2 for z/OS. There are some rules that must be followed for this to work
•Applications must use resource references when they look up a data source
•Defer to each application definition of application-specific non-core data source properties such as
 – currentSchema
 – currentFunctionPath
•The core properties have to be identical such as
 – Username
 – Host and port
The following link in WebSphere Application Server information center explains the extended properties that can be set for each application
The benefits of heterogeneous connection pooling are:
•Reduction in memory consumption in WebSphere.
•Creating one data source versus multiple data sources.
•Reduction in memory consumption in DB2 (threads, connection) and hence improved performance.
2.6.5 WebSphere connection pooling combined with sysplex workload balancing for JDBC type 4 connectivity
The DB2 primary approach for scalability and high availability is to use the clustering capabilities of the System z Parallel Sysplex. In a DB2 data sharing environment, multiple instances of DB2 data sharing member can all access the same databases. Workload can be spread across the different members of the data sharing groups based on factors such as:
•Current workload of the DB2 member
•Current health and state of the DB2 member,
•Current capacity of the LPAR in which DB2 is running
Applications that are deployed in WebSphere Application Server that use IBM Data Server Driver for SQLJ and JDBC and use a JDBC type 4 connection to DB2 for z/OS can be enabled to be sysplex aware.
In Figure 2-28, we can see the logical connections are managed by WebSphere Application Server while the transports, which are the actual connections to DB2 for z/OS, are managed by the IBM Data Server Driver for JDBC and SQLJ. As shown in the figure below, the logical connections are disassociated from the transports at commit/rollback boundaries (transaction boundaries). This allows for transaction level workload balancing.
Figure 2-28 Logical connections and Transports
To enable sysplex workload balancing, the following items must configured
•Data source custom property enablesysplexWLB must be added with a value of true.
•DB2 for z/OS data sharing must be set up following the preferred
practice recommendation
•The group DVIPA address of the DB2 data sharing group must be specified as the server host name in the data source definition
The following is a brief description of how sysplex workload balancing works
1. The initial connection to DB2 is made by using the group dynamic virtual IP address. This resolves to any available member based on WLM
2. The initial connection returns a member IP list of all available DB2 data sharing group members with WLM weights
3. Any following connection uses client sysplex workload balancing algorithm to determine which member to use if reuse is OK. Transports that have the following are not eligible
for reuse:
a. Transports have open WITH HOLD cursor
b. Declared global temporary tables must not exist. Declared global temp tables must be explicitly or implicitly dropped
c. Packages that are bound with KEEPDYNAMIC YES
When connection errors happen, the following behavior occurs:
•If first SQL stmt in transaction fails and reuse OK
 – No errors reported back to application
 – SET statements that are associated with the logical connection are replayed with first SQL on another transport
•If subsequent SQL fails and reuse OK
 – 30108 reuse error returned to application (transaction is rolled back and reconnected).
 – SET statements are replayed on another transport to recover connection state
 – Up to application to retry transaction
•If subsequent SQL and reuse not OK
30081 connection failed error returned to application.
Connection returned to initial (default) state
Application needs to reestablish connection state and retry transaction
•If all members in the member list are tried and none seems to be available, the initial data source group DVIPA address is retried to make sure that really no member is available.
Considerations
We list here considerations for best practices:
•Ensure that the application handles the above mentioned SQL codes and take appropriate action
•WebSphere Application Server provides a feature that pretests a connection by running a SQL statement. This is to avoid stale connections. If sysplex workload balancing is used, it is recommended to disable this feature as the IBM Data Server Driver for JDBC and SQLJ ensures that a valid connection is returned. This pretest can be disabled as shown in Figure 2-29 by leaving the boxes for validation cleared.
Figure 2-29 Disabling pretest connection
•If sysplex workload balancing is exploited, then it is recommended to disable the WebSphere Application Server connection pool properties Reap Time, Unused Timeout and Aged Timeout by setting the values to zero as shown in Figure 2-30 on page 57. The reason being that the actual physical connections are handled by the IBM Data Server Driver for JDBC and SQLJ and the connections that are handled by WebSphere Application Server are logical connections.
Figure 2-30 Disabling properties Reap Time, Unused Timeout, and Aged Timeout
2.6.6 WebSphere Application Server prepared statement cache
WebSphere Application Server manages a cache of previously created prepared statement objects at a connection level. When a new prepared statement is requested on a connection, by the application, the cached prepared statement object is returned if it is available on that connection. Creating a new prepared statement object is costly in Java. WebSphere Application Server prepared statement cache does not store any DB2 specific information. The cache is solely used by WebSphere to reduce processor consumption for creating a Java object. Customers should monitor the number of distinct SQL statements that are used by the application and then come up with a number to define the size of the statement cache. This is at a connection level and hence has an impact on WebSphere Application Server heap size.
WebSphere Application Server prepared statement cache with DB2 Dynamic Statement cache
The WebSphere Application Server statement cache function works together with DB2 dynamic statement caching. When the prepared statements are cached in the DB2 for z/OS (DSNZPARM CACHEDYN=YES), recalculation of the access path can be avoided if the statement in the DB2 dynamic statement cache can be reused by a subsequent execution. This saving is in addition to saving the JDBC precompiled SQL cost that WebSphere Application Server statement caching (caching the prepared statement object) offers. This is depicted in Figure 2-31.
Figure 2-31 WebSphere Application Server: caching the prepared statement object
When the application runs the prepareStatement() JDBC API, WebSphere Application Server looks for existence of the Java preparedStatement object in the statement cache that exists in WebSphere Application Server. This cache is unique to each connection in the connection pool. It must be remembered that it is a Java preparedStatement object and has nothing to do with the prepare that happens in DB2 for z/OS. In this case, because this statement is prepared for the first time, WebSphere Application Server cannot find it in the cache. It creates a Java preparedStatement object and stores it in its cache.
•When using JDBC type 2 connectivity to DB2 for z/OS, the driver will immediately send the SQL statement to DB2 to be prepared. DB2 will first look in “local cache” to see whether it can find the SQL statement. In this case, it does not exist. DB2 then looks for the statement in global dynamic statement cache. In this case, the statement is not found in the global dynamic statement cache. DB2 does what is called a “full prepare” during which it checks the validity of the SQL, determines the access path to be used, and so on.
If the SQL statement is valid, the DB2 then stores the statement in the global statement cache called “global cache” in Figure 2-31 on page 58. DB2 also stores information about the prepared statement in thread storage that is created in DB2. Then, it returns to WebSphere Application Server, which then returns the Java prepared statement object back to the application. The application then runs the statement and then issues a commit. When the commit is issued, the prepared statement artifacts that are stored in the DB2 thread storage that is known as “local cache” are also deleted and the DB2 thread is ready for reuse
•When using JDBC type 4 connectivity to DB2 for z/OS, the driver by default will not send the SQL statement immediately to DB2 for z/OS. Instead, the WebSphere Application Server returns a Java preparedStatement object to the application. This behavior is controlled by a JDBC property called “deferPrepares”. By default this property is to true and is only valid for the JDBC type 4 connectivity to DB2 on z/OS. This helps to optimize the number of trips to DB2 on z/OS over the network. When the application issues the preparedtStaement.execute command, the JDBC driver will then send the SQL statement to DB2 on z/OS. DB2 will look for the statement in global dynamic statement cache. In this case, the statement is not found in the global dynamic statement cache. DB2 does what is called a “full prepare” during which it checks the validity of the SQL, determines the access path to be used, and so on.
If the SQL statement is valid, DB2 then stores the statement in the global statement cache called “global cache” in Figure 2-31 on page 58. DB2 also stores information about the prepared statement in thread storage that is created in DB2. This is called “local cache”. DB2 then runs the SQL statement and then returns control back to the WebSphere Application Server and to the application. The application then issues a commit. When the commit is issued, the prepared statement artifacts that are stored in the DB2 thread storage (“local cache”) are also deleted and the DB2 thread is ready for reuse
Now, the next application thread comes along and the same code to prepare the SQL statement is ran. WebSphere Application Server, looks in the statement cache in WebSphere Application Server. In this case, it finds the preparedStatement object in the cache and the object construction is avoided
•When using JDBC type 2 connectivity to DB2 on z/OS, the driver immediately sends the SQL statement to DB2 to be prepared. DB2 first looks in “local cache” to see whether it can find the SQL statement. In this case, it does not exist. DB2 then looks for the statement in global dynamic statement cache. In this case, the statement is found in the global dynamic statement cache. DB2 does what is called a “short prepare” during which it actually copies the artifacts from the global statement cache to the thread (“local cache”). Then, it returns to WebSphere Application Server, which then returns the Java prepared statement object back to the application. The application then runs the statement and then issues a commit. When the commit is issued, the prepared statement artifacts that are stored in the DB2 thread storage that is known as “local cache” are also deleted and the DB2 thread is ready for reuse.
•When using JDBC type 4 connectivity to DB2 for z/OS, the driver by default does not send the SQL statement immediately to DB2 for z/OS. Instead, the WebSphere Application Server returns a Java preparedStatement object to the application. This behavior is controlled by a JDBC property called “deferPrepares”. By default this property is set to true and is only valid for the JDBC type 4 connectivity to DB2 for z/OS. This helps to optimize the number of trips to DB2 on z/OS over the network. When the application issues the preparedtStaement.execute command, the JDBC driver will then send the SQL statement to DB2 for z/OS. DB2 first looks in “local cache” to see whether it can find the SQL statement.
In this case, it does not exist. DB2 then looks for the statement in global dynamic statement cache. In this case, the statement is found in the global dynamic statement cache. DB2 does what is called a “short prepare” during which it actually copies the artifacts from the global statement cache to the thread known as “local cache”. DB2 then runs the SQL statement and then returns control back to the WebSphere Application Server and to the application. The application then issues a commit. When the commit is issued, the prepared statement artifacts that are stored in the DB2 thread storage that is known as “local cache” are also deleted and the DB2 thread is ready for reuse.
This behavior of copying artifacts from global dynamic statement cache to local cache is also followed when using static SQL applications. Instead of copying from global statement cache, the artifacts are copied from the static application packages in the EDM pool to
thread storage.
This shows the benefits of having a prepared statement cache in WebSphere Application Server and also how it works with DB2 global dynamic statement cache.
WebSphere Prepared Statement Cache and DB2 KEEPDYNAMIC option
In the previous section, we talked about WebSphere Prepared Statement cache. In that section, we mentioned “local cache”. In this section, we talk about the “local cache” and how it is useful and how best to use it.
The local cache is associated with an individual thread in DB2. When an application runs a SQL statement, the contents of the global dynamic statement cache are copied into the local cache in DB2 thread storage. This cache is “destroyed” when the application issues a commit. Then, the application runs the SQL statement again, the process of copying is repeated and after the application issues a commit, the “destroy” is also repeated. This copying of contents from the global dynamic statement cache into local cache becomes expensive (CPU time) if this happens over and over again.
To keep the local cache across commit boundaries, the following steps must be completed:
•DB2 provides a bind option called KEEPDYNAMIC. The JDBC/SQLJ packages that are provided by IBM must bound with KEEPDYNAMIC(YES) bind option. Typically you should bind these packages to a different collection than the ones used for applications that do not use the KEEPDYNAMIC option. For example, let the collection name be “MYCOLL1”.
•If you use SQLJ / IBM pureQuery® applications, then those application packages also must be bound with KEEPDYNAMIC option to a different collection name. For example, let the collection name be “MYCOLL2”.
•If the application is using JDBC type 4 connectivity, the above collection names must be specified as part of the “currentPackagePath” data source property. For example, the value specified in the “currentPackagePath” property looks like “MYCOLL1.*,MYCOLL2.*”.
•If the application is using JDBC type 2 connectivity, then the above collection names must be specified as part of the “pkList” data source property. For example, the value specified in the “pkList” property looks like “MYCOLL1.*,MYCOLL2.*”.
•Specify the “keepDynamic” property in the data source custom property and set the value to 1
After the above steps are completed, then WebSphere prepared statement cache, DB2 “local cache” (which is nothing but thread storage in DB2) and the DB2 global dynamic statement cache work together as shown in Figure 2-32.
Figure 2-32 preparedStatement object loaded in cache
As we can see, in the first case the application issues the prepareStatement() JDBC API. WebSphere Application Server looks for the Java preparedStatement object in the cache. If it does not find it, a new preparedStatement object is constructed and put it in the cache. Then, the SQL statement is sent to DB2 for z/OS. DB2 looks for the SQL statement in the thread storage. It is not found in thread storage, DB2 then looks for the SQL statement in the global statement cache. It is not found there as well, DB2 then does a “full prepare” which entails validating the SQL statement and coming up with an optimal access path. DB2 then puts this SQL statement in the global statement cache. It then also stores the artifacts in the DB2 thread storage. Then, control is returned to the application. The application then runs the statement and then issues a commit.
Notice that because keepDynamic is enabled, the information in thread storage is not destroyed, and the DB2 thread is still available for reuse. The same thread is used for this work in DB2. Now the application again issues a preparedStatement with the same SQL statement. WebSphere Application Server finds the java preparedStatement object in cache. It then sends the SQL statement to DB2 for prepare. Because “keepDynamic” is enabled, the SQL statement is found in thread storage and DB2 then returns control back to the application, which then runs SQL statement.
It is not a problem if the Java application issues the prepare again, the statement is “absorbed” by the driver and not routed DB2. This is different from other languages, like COBOL, where you cannot issue the prepare again after the commit. If you do, the local cached copy is destroyed and you do not get the benefit of keepDynamic.
Advantages of using keepDynamic:
•Reduction in CPU time as the short prepares are avoided
Disadvantages of using keepDynamic
•Because the statements are kept in thread storage, DB2 environments that have storage constraints should be careful in using this. Virtual storage should be monitored
•Sysplex workload balancing is not available if keepDynamic is used
The keepDymamic option is best for applications that have a limited number of SQL statements that are used heavily.
2.6.7 Trusted context support in WebSphere Application Server
In typical applications that run on WebSphere Application Server, the authentication is done at the WebSphere Application Server layer. These applications often access data in DB2 for z/OS. The connection to the DB2 from WebSphere Application Server uses a JAAS alias. The alias contains the user ID and password. Figure 2-33 depicts a typical scenario
Figure 2-33 The standard security layers
The above setup presents the following challenges for customers:
•The user ID is never passed to DB2 for z/OS.
•The user ID defined in the JAAS alias often has significant privileges to access DB2 for z/OS data.
•Anyone who knows the user ID and password can use it to access the data in DB2 for z/OS and this compromises security.
The DB2 Trusted Context support in WebSphere Application Server provides an elegant solution for this problem. A trusted context is an object the database administrator defines that contains a system authorization ID and a set of trust attributes. The relationship between a database connection and a trusted context is established when the connection to the database server is first created, and that relationship remains for the life of the database connection. This feature allows WebSphere Application Server to use the trusted DB2 Connection under a different user without reauthenticating the new user at the database server (assuming the Trusted Context is created without authentication option being required).
There are two ways to set this up:
•There is nothing to be done from a WebSphere Application Server. In DB2, a Trusted Context is created with the system authid. This user ID is only granted access to connect to DB2. This user ID is used in the JAAS alias that the data source uses to connect to DB2. A ROLE is created in DB2, which has the required privileges to the application needs to access data in DB2. The user ID is then granted the role.
Benefits of this approach
 – The user ID and password in the JAAS alias can be used only to access DB2 data from the WebSphere Application Server
 – Nothing needs to be configured in WebSphere Application Server
Cons of this approach
 – The user ID is still not available in DB2
•Configure WebSphere Application Server to pass the user ID to DB2 for z/OS. In DB2, a Trusted Context is created with the system authid. This user ID is only granted access to connect to DB2. This user ID is used in the JAAS alias that the data source uses to connect to DB2. In the trusted context definition in DB2, user ID/groups should be added. Authentication requirements can be added to the trusted context definition. A ROLE is created in DB2, which has the required privileges to the application needs to access data in DB2. The added user ID/groups are then granted the role.
The application should use resource references. In the resource definition panel, as part of the Modify Resource Authentication Method, Use Trusted Connection can be selected and a JAAS alias, which has the system user ID from the trusted context definition in DB2 specified.
Benefits of this approach
 – The user ID and password in the JAAS alias can be used only to access DB2 data from the WebSphere Application Server
 – The user ID is available in DB2
Cons of this approach
 – The user ID must be defined in the SAF environment
More information about this topic can be found at
2.6.8 Transaction Isolation Level support in WebSphere Application Server
During database access, transaction isolation determines the nature of locks to be acquired, which ultimately determines the transactional integrity. In addition, isolation level is a significant factor in determining whether two separate transactions can read or update the same data and how long the acquired locks prevent other transactions from performing specific tasks. The effects of transaction isolation can be described as the length of time the lock is held, known as lock duration, and the exclusiveness of the lock, which is known as the lock mode.
The default isolation level that is used in WebSphere Application Server 8.5 when accessing DB2 for z/OS is Read Stability (RS). To customize the default isolation level, you can use the webSphereDefaultIsolationLevel custom property for the data source.
Information about isolation level settings can be found at 6.8, “Locking” on page 331 and at:
2.6.9 Transactions in WebSphere Application Server
A transaction is a set of work for which either all individual work items or no items are performed. A failure of a subset requires that the entire work set is undone. This all-or-none attribute is called atomic. For example, assume an application attempts to update three tables within a transaction. A failure during the update of the third table would undo all updates to the first and second table within the transaction. This atomic attribute ensures that all dependent operations are completed in full. A transaction is also known as a Logical Unit of Work (LUW)
As an implementation of the Java Platform, Enterprise Edition specification, WebSphere Application Server supports both local and global transactions and can be either a transaction manager or a resource (manager) within a transaction. WebSphere Application Server is a transaction manager and supports the following types of transactions
•Resource Manager Local Transactions
•Local Transactions
•Global Transactions
Information on transaction support in WebSphere Application Server can be found at
On distributed platforms, the transaction service in WebSphere Application Server handles both local and global transactions. If WebSphere Application Server on z/OS and the applications accesses DB2 by using JDBC type 2 connectivity, the transaction services in WebSphere Application Server defer to the z/OS Recoverable Resource Services (RRS) to handle local and global transactions. If JDBC type 4 access to DB2 is used, RRS is not used and the transaction service in WebSphere Application Server handles both global and
local transaction
2.7 WebSphere Application Server - DB2 high availability configuration options
High availability is also known as resiliency. High availability is the ability of a system to tolerate a number of failures and remain operational. It is achieved by adding redundancy in the infrastructure to support failures. It is critical that your infrastructure continues to respond to client requests regardless of the circumstances and that you remove any single points of failure. Planning for a highly available system takes planning across all components of your infrastructure because the overall infrastructure is only available when all of the components are available. As part of the planning, you must define the level of high availability that is needed in the infrastructure.
2.7.1 WebSphere Application Server - DB2 for z/OS recommended high availability configuration when using JDBC type 4 connectivity
WebSphere Application Server Network Deployment configuration (on all platforms) is a recommended to be set up for high availability and scalability. We can have as many nodes as required in a single cell, to meet availability and scalability requirements.
Table 2-1 lists the implementation steps and provides a link to where the steps are described in this book.
Table 2-1 List of sections describing the JDBC type 4 implementation steps
JDBC type 2 - Implementation step number and definition
Cross-reference to where described
WebSphere
1. Build at a minimum a WebSphere Application Server Network Deployment configuration spread across two nodes/LPARs following the preferred practice information.
2. Build a DB2 for z/OS data sharing environment with at least two members that are spread across two LPARS on z/OS.
 
3. Configure either a DB2 Universal JDBC Provider or DB2 Universal JDBC Provider (XA) depending on transaction requirements. Use DB2 Universal JDBC Provider (XA) if the application requires global transaction support using JDBC type 4 connection only.
4. During the definition of the data source, make sure to provide the group DVIPA address for the server name property. This is important for high availability and scalability.
5. Configure WebSphere Application Server data source connection pool properties depending on application requirements.
6. Enable sysplex workload balancing.
7. Use the high performance DBAT features available in DB2 10. Bind the JDBC packages to a different collection name with the RELEASE(DEALLOCATE) option. Configure the data source to use this collection. If the application uses SQLJ or pureQuery and uses static SQL, remember to bind those packages as well with the RELEASE(DEALLOCATE) and provide those collection names as well in the data source custom property.
8. Set client accounting information on the data source custom properties as shown at a minimum. This helps identify connection on which the SQL statements come into DB2.
9. Define trusted context and roles in DB2. Define only connection privilege to the user ID that is specified on the data source. Define the required privileges to the role in DB2.
10. Set up a profile table in DB2 (if using DB2 10) to monitor and control connections coming into DB2 from WebSphere Application Server.
11. Set the appropriate isolation level
12. Configure prepared statement cache in WebSphere Application Server
By doing all the following steps above, one gets the following capabilities
•High availability
•Scalability
•Workload balancing
•Ability to track which SQL is coming from which application
•Ability to better classify individual application workload to WLM on z/OS
•Security, as the data sources user ID id cannot be misused
We set up the environment as recommended above and validated the following items:
•Trusted Context
•Sysplex Workload Balancing
•Client connection Strings
•High Availability
Figure 2-34 on page 67 represents the HA configuration that we built for JDBC type 4 connectivity following the recommendation above.
Figure 2-34 High availability configuration for JDBC type 4 connectivity
Validating high availability and sysplex workload balancing
We used the dayTradeEE6 application for this scenario. We configured the data source to be a JDBC type 4 data source. We set the client accounting information. We enabled sysplex workload balancing. We set the maximum connections in the connection pool properties in WebSphere Application Server for the JDBC type 4 data source to 50. We used workload simulator to start the workload and started 50 concurrent clients.
It is difficult to show that workload is truly balanced. We captured the output from the DISPLAY DDF DETAIL command in both the DB2 members. We saw the workload was distributed between both the data sharing members. See Example 2-1.
The following are our observations:
•The difference between ADBAT and DSCDBAT tells you how many threads are active currently in the DB2 subsystem. For DB0Z2, we see it is 20 - 9, which is 11.
•We see that the weights returned by WLM are the same for both the members.
Example 2-1 DISPLAY DDF DETAIL output
DSNL101I WT IPADDR IPADDR
DSNL102I 32 ::9.12.4.142
DSNL102I 32 ::9.12.4.138
 
DSNL080I -D0Z2 DSNLTDDF DISPLAY DDF REPORT FOLLOWS:
DSNL081I STATUS=STARTD
DSNL082I LOCATION LUNAME GENERICLU
DSNL083I DB0Z -NONE -NONE
DSNL084I TCPPORT=39000 SECPORT=0 RESPORT=39003 IPNAME=IPDB0Z
DSNL085I IPADDR=::9.12.4.153
DSNL086I SQL DOMAIN=d0zg.itso.ibm.com
DSNL086I RESYNC DOMAIN=d0z2.itso.ibm.com
DSNL089I MEMBER IPADDR=::9.12.4.142
DSNL090I DT=I CONDBAT= 10000 MDBAT= 200
DSNL092I ADBAT= 20 QUEDBAT= 0 INADBAT= 0 CONQUED= 0
DSNL093I DSCDBAT= 9 INACONN= 39
DSNL100I LOCATION SERVER LIST:
DSNL101I WT IPADDR IPADDR
DSNL102I 32 ::9.12.4.142
DSNL102I 32 ::9.12.4.138
DSNL105I CURRENT DDF OPTIONS ARE:
DSNL106I PKGREL = COMMIT
DSNL099I DSNLTDDF DISPLAY DDF REPORT COMPLETE
•We had set the max connections in the data source connection pool property to be 50. We started a workload that had 50 clients. The JDBC type 4 driver opens 50 transports to each data sharing member. The DISPLAY LOCATION report in Example 2-2 shows you how many transports have been created. We can see that for the member D0Z2 we created 50 connections from a client at location 9.12.4.142. All 50 connections are workload balanced as shown by workload balancing. It also shows that all the 50 connections were coming from an XA driver.
Example 2-2 DISPLAY LOCATION report
DSNL200I -D0Z2 DISPLAY LOCATION REPORT FOLLOWS-
LOCATION PRDID T ATT CONNS
::9.12.4.142 JCC03640 S        50
WLB    50
XA     50
::9.12.6.9 JCC03640 S         0
DISPLAY LOCATION REPORT COMPLETE
•We looked at the DISPLAY DDF output of Example 2-3 to validate the thread information.
 – The difference between ADBAT and DSCDBAT tells you how many threads are active currently in the DB2 subsystem. For DB0Z1, we see it is 29 -23, which is 6.
 – We see that the weights (WT) returned by WLM is almost the same for both the members.
Example 2-3 DISPLAY DDF report
DSNL101I WT IPADDR IPADDR
DSNL102I 33 ::9.12.4.138
DSNL102I 31 ::9.12.4.142
 
DSNL080I -D0Z1 DSNLTDDF DISPLAY DDF REPORT FOLLOWS:
DSNL081I STATUS=STARTD
DSNL082I LOCATION LUNAME GENERICLU
DSNL083I DB0Z -NONE -NONE
DSNL084I TCPPORT=39000 SECPORT=0 RESPORT=39002 IPNAME=IPDB0Z
DSNL085I IPADDR=::9.12.4.153
DSNL086I SQL DOMAIN=d0zg.itso.ibm.com
DSNL086I RESYNC DOMAIN=d0z1.itso.ibm.com
DSNL089I MEMBER IPADDR=::9.12.4.138
DSNL090I DT=I CONDBAT= 10000 MDBAT= 200
DSNL092I ADBAT= 29 QUEDBAT= 0 INADBAT= 0 CONQUED= 0
DSNL093I DSCDBAT= 23 INACONN= 44
DSNL100I LOCATION SERVER LIST:
DSNL101I WT IPADDR IPADDR
DSNL102I 33 ::9.12.4.138
DSNL102I 31 ::9.12.4.142
DSNL105I CURRENT DDF OPTIONS ARE:
DSNL106I PKGREL = COMMIT
DSNL099I DSNLTDDF DISPLAY DDF REPORT COMPLETE
•We had set the max connections in the data source connection pool property to be 50. We started a workload that had 50 clients. The JDBC type 4 driver opens 50 transports to each data sharing member. The DISPLAY LOCATION report in Example 2-4 shows you how many transports have been created. We can see that for the member D0Z1 we created 50 connections from a client at location 9.12.4.142. Out of this 50 all 50 are workload balanced as shown by WLB. It also shows that all the 50 connections were coming from an XA driver.
Example 2-4 DISPLAY LOCATION report
DSNL200I -D0Z1 DISPLAY LOCATION REPORT FOLLOWS-
LOCATION PRDID T ATT CONNS
::9.12.6.9 JCC03640 S 50
WLB 50
XA 50
::9.30.28.118 JCC04130 S 0
DISPLAY LOCATION REPORT COMPLETE
We then brought down D0Z2.
We saw the text in Example 2-5 in the WebSphere Application Server log. The JDBC driver automatic client reroute feature kicks in and it follows the behavior described earlier. We get an SQL code of -30108. This tells us that the current transaction failed and the application has the option to retry the logic (if the application was written to do so). Our DayTrader application was not written to handle the -30108 error code and hence some transactions failed, but the workload continued successfully to the other member.
Example 2-5 WebSphere Application Server log
Trace: 2012/08/10 20:52:57.176 02 t=7C0268 c=UNK key=P8 tag= (13007004)
SourceId: com.ibm.ejs.j2c.ConnectionEventListener
ExtendedMessage: J2CA0056I: The Connection Manager received a fatal connection error from the Resource Adapter for resource jdbc/T radeDataSource.
The exception is: com.ibm.db2.jcc.am.ClientRerouteException:
[jcc][t4][20142][11212][3.64.97] A connection failed but has been re-established.
The host name or IP address is "d0z1.itso.ibm.com" and the service name or port number is 39,000. ERRORCODE=-30108, SQLSTATE=08506
Validating trusted context
We used a simple web service app to validate trusted context. The application name is D0ZG_WASTestClientInfo. We secured it to use basic form authentication. This application issues uses a data source. We configured it to be a JDBC type 4 data source following the best practice configuration. We then installed the application on the server. We then enabled the application to use a trusted connection. We set the client application information to dwsClientinformationDS. In DB2 we created a trusted context. Then we ran the application. It prompted us for a user ID. We used “wastest”. We then captured the output from a -DIS THREAD(*) SCOPE(GROUP) command.
Example 2-6 shows the output from the command.
Example 2-6 -DIS THREAD(*) output
DSNV473I -D0Z2 ACTIVE THREADS FOUND FOR MEMBER: D0Z1
NAME ST A REQ ID AUTHID PLAN ASID TOKEN
SERVER SW * 16 db2jcc_appli RAJESH DISTSERV 00FB 11240
 V485-TRUSTED CONTEXT=CTXWASTESTT4,
SYSTEM AUTHID=WASTEST,
ROLE=WASTESTDEFAULTROLE
V437-WORKSTATION=WTSC64, USERID=wastest,
APPLICATION NAME=dwsClientinformationDS
V429 CALLING FUNCTION=DB2R3.GRACFGRP,
PROC= , ASID=0000, WLM_ENV=DSNWLMDB0Z_GENERAL
For details about setting up trusted context, see Chapter 4, “DB2 infrastructure setup” on page 99.
2.7.2 WebSphere Application Server - DB2 z/OS recommended high availability configuration when using JDBC type 2 connectivity
There are three possible HA configurations when using WebSphere Application Server on z/OS and using JDBC type 2 connectivity to DB2 for z/OS:
Configuring multiple members of the DB2 data sharing group on each LPAR
You can have multiple members of the DB2 data sharing group on each LPAR. After you have multiple members of the DB2 data sharing group in the same LPAR, and the data source custom property ssid is configured with the group attach name, then the IBM Data Server Driver for JDBC and SQLJ automatically fails over to the second member if one member goes down.
It is important to note that it will not fail back after the original failed member comes back up again. It is also important to note that there is no workload balancing between two DB2 members on the same LPAR when we use JDBC type 2 connectivity. It is also important to note that the IBM Data Server Driver for JDBC and SQLJ picks one member randomly and does not have any special algorithm available.
Exploiting the Resource Adapter Failover feature
You can configure WebSphere Application Server to exploit the Resource Adapter Failover feature. This is new since WebSphere Application Server V8.
Figure 2-35 represents what is a common highly available clustered WebSphere Application Server and JDBC type 2 connectivity to DB2 for z/OS.
Figure 2-35 Highly available WebSphere Application Server with and JDBC type 2
When one of the DB2 member fails as shown in Figure 2-36, there is a potential outage as the front end router does not know that DB2 is down.
Figure 2-36 DB2 failure not notified to router
The solution is to configure what is called an alternate JDBC type 4 data source. WebSphere Application Server is smart enough to know that DB2 is down and will start to use the type 4 connection to the second DB2 member of the same data sharing group in the other LPAR
Figure 2-37 shows the alternate JDBC type 4 data source configured.
Figure 2-37 Alternate JDBC type 4 data source configuration
Then Figure 2-38 shows how, when the DB2 member goes down, existing connections and transactions fail but new connections use the alternate JDBC type 4 connection to available DB2 data sharing members and work is not affected.
Figure 2-38 Alternate JDBC type 4 connection used to surviving DB2 member
Now when the failed DB2 member is brought up, WebSphere Application Server is smart enough to know that DB2 is back up, and starts using the JDBC type 2 connection. In this case, it is smart that it does not fail any existing transactions on the JDBC type 4 connection, instead it quiesces the current work and starts to using the JDBC type 2 connection for new work. There is a custom property resourceAvailabilityTestRetryInterval that can be configured to tell WebSphere Application Server how often to check if the failed DB2 member is up. See Figure 2-39.
Figure 2-39 Reactivating the type 2 connection
Detailed step by step guidance can be found in the document at this url:
Using new failure custom properties
Starting with WebSphere Application Server V8, a couple of custom properties were added to the data source connection pool custom properties. These are the failureNotificationActionCode and failureThreshold. The failure notification is option must be carefully evaluated. If the failureNotificationActionCode is set to 1, then a BBOJ0130I is issued to the operator log. Then using automation, appropriate recovery action can be taken.
Figure 2-40 shows the failure of a member causing the message notification when the failureNotificationActionCode is set to 1.
Figure 2-40 failureNotificationActionCode is set to 1
If the failureNotificationActionCode is set to 2, then an automatic pause listener command is issued. This command closes the ports on the server and the front end router is smart enough to know this and does not route work to this server. This means all the applications in this server are not available for work. This option is best if all the applications in that server require access to DB2. Figure 2-41 shows what happens when the failureNotificationActionCode is set to 2.
Figure 2-41 failureNotificationActionCode is set to 2
If the failureNotificationActionCode is set to 3, then WebSphere Application Server stops all applications that access that specific DB2 for z/OS. This means that all other applications which do not access DB2 for z/OS are available.
A highly intelligent front end router such as the On Demand Router (a WebSphere Application Server feature available in V8.5) is needed to recognize that the application is stopped and stop routing work to that server. Normal HTTP servers are not smart enough to know applications are stopped in the servers, they only know if a server is stopped. Figure 2-42 shows what happens when the failureNotificationActionCode is set to 3.
Figure 2-42 failureNotificationActionCode is set to 3
These factors must be taken into consideration before selecting this options.
Information about these properties can be found in the WebSphere Application Server information center at
All three options are viable and depend on each customers environment and requirement. Hence it is difficult to really pick one as the recommendation.
Best practices to build a HA environment for JDBC type 2 connections
In general the following are best practices on how to build a HA environment.
Table 2-2 lists the implementation steps and provides a link to where the steps are described in this book.
Table 2-2 List of sections describing the JDBC type 2 implementation steps
JDBC type 2 - Implementation step number and definition
Cross reference to where described
WebSphere
1. WebSphere Application Server Network Deployment configuration (on all platforms) is a recommended to be set up for high availability and scalability. We can have as many nodes as required in a single cell, to meet availability and scalability requirements. Build at a minimum a WebSphere Application Server Network Deployment configuration spread across 2 nodes/LPARs following the best practice information found in the following.
2. Build a DB2 for z/OS data sharing environment with at least two members spread across 2 LPARS on z/OS.
 
3. Configure a DB2 Universal JDBC Provider.
4. Define a data source.
5. Define the ssid custom property. Make sure to give the group attach name as the value.
6. Configure WebSphere Application Server data source connection pool properties depending on application requirements.
7. Configure WebSphere Application Server data source prepared statement cache size depending on application requirements.
8. Set client accounting information on the data source custom properties as shown at a minimum. This will help identify connection on which the SQL statements come into DB2.
9. Define trusted context and roles in DB2. Define only connection privilege to the user ID that is specified on the data source. Define the required privileges to the role in DB2.
10. Set the appropriate isolation level
By doing all the steps above, you get the following capabilities
•High availability
•Scalability
•Ability to track which SQL is coming from which application
•Ability to better classify individual application workload to WLM on z/OS
•Security, as the data source user ID id cannot be misused
We set up the environment as recommended above and validated the following:
The following validation sections used the HA configuration we built for JDBC type 2 connectivity following the recommendation above. Because we had only two data sharing members, we brought up both on the same LPAR to validate fail over.
Validating fail over capability
We used the dayTradeEE6 application for this scenario. We configured the data source to be a JDBC type 2 data source. We set the ssid to use the group attach name as recommended. We set the client accounting information. We enabled sysplex workload balancing. We set the max connections in the connection pool properties in WebSphere Application Server for the JDBC type 2 data source to 50. Because we had only 2 data sharing members, we brought up both on the same LPAR to validate fail over. We used workload simulator to start the workload and started 50 concurrent clients.
We issued the -DISPLAY THREAD(*) SCOPE(GROUP) command when we started the workload. We noticed from the output listed in Example 2-7 that all JDBC type 2 connections went to a single member (D0Z2) as expected. D0Z1 did not have any connections from the
DayTrader application.
Example 2-7 -DISPLAY THREAD(*) SCOPE(GROUP) output
DSNV401I -D0Z1 DISPLAY THREAD REPORT FOLLOWS -
DSNV402I -D0Z1 ACTIVE THREADS -
NAME ST A REQ ID AUTHID PLAN ASID TOKEN
RRSAF T 115 D0Z1ADMT_DMN D0Z1ADMT ?RRSAF 00AD 2
V437-WORKSTATION=RRSAF, USERID=D0Z1ADMT,
APPLICATION NAME=D0Z1ADMT_DMN
RRSAF T 5 D0Z1ADMT_II D0Z1ADMT ?RRSAF 00AD 6
V437-WORKSTATION=RRSAF, USERID=D0Z1ADMT,
APPLICATION NAME=D0Z1ADMT_II
TSO T * 3 RAJESH RAJESH 009D 38
V437-WORKSTATION=TSO, USERID=RAJESH,
APPLICATION NAME=RAJESH
TSO T 970 DB2R3 DB2R3 ADB 00B0 17
V437-WORKSTATION=TSO, USERID=DB2R3,
APPLICATION NAME=DB2R3
DISPLAY ACTIVE REPORT COMPLETE
DSNV473I -D0Z1 ACTIVE THREADS FOUND FOR MEMBER: D0Z2
NAME ST A REQ ID AUTHID PLAN ASID TOKEN
DISCONN DA * 28 NONE NONE DISTSERV 00A2 14
V471-IPDB0Z.P85B.CA061AE373AA=14
RRSAF TD 18005 MZSR014S RAJESH ?RRSAF 00B2 27
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
***
RRSAF T * 23674 MZSR014S RAJESH ?RRSAF 00B2 28
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF T * 2659 MZSR014S RAJESH ?RRSAF 00B2 29
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF TD 3359 MZSR014S RAJESH ?RRSAF 00B2 30
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF TD 9842 MZSR014S RAJESH ?RRSAF 00B2 31
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF T * 14650 MZSR014S RAJESH ?RRSAF 00B2 32
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF TD 5621 MZSR014S RAJESH ?RRSAF 00B2 33
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF TD 26928 MZSR014S RAJESH ?RRSAF 00B2 34
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF TD 2153 MZSR014S RAJESH ?RRSAF 00B2 35
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
***
We then brought down D0Z2. We then validated the fail over by issuing the -DISPLAY THREAD(*) SCOPE(GROUP) command again. In Example 2-8 we see that all the connections are now to member D0Z1.
Example 2-8 Validating the fail over with -DISPLAY THREAD(*) SCOPE(GROUP)
DSNV401I -D0Z1 DISPLAY THREAD REPORT FOLLOWS -
DSNV402I -D0Z1 ACTIVE THREADS -
NAME ST A REQ ID AUTHID PLAN ASID TOKEN
RRSAF T * 4888 MZSR014S RAJESH ?RRSAF 00B2 45
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF T * 6539 MZSR014S RAJESH ?RRSAF 00B2 46
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF T * 10223 MZSR014S RAJESH ?RRSAF 00B2 47
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF T * 6274 MZSR014S RAJESH ?RRSAF 00B2 48
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF T * 9043 MZSR014S RAJESH ?RRSAF 00B2 49
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF T * 6176 MZSR014S RAJESH ?RRSAF 00B2 50
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
APPLICATION NAME=TraderClientApplication
RRSAF T * 8188 MZSR014S RAJESH ?RRSAF 00B2 51
V437-WORKSTATION=TraderClientWorkst, USERID=TraderClientUser,
***
Validating trusted context
We used the dayTraderEE6 application to validate trusted context. We configured it to be a JDBC type 2 data source following the best practice configuration. The JAAS alias we used had a user ID MZADMIN. This user ID had only connect privileges to DB2. It had a DB2 Role assigned to it that gave it the required privileges to access the application tables. We set the client application information to TraderClientApplication1.
In DB2 we created a trusted context. Then we ran the application. It prompted us for a user ID. We used “wastest”. We then captured the output from a -DIS THREAD(*) command. Example 2-9 shows the output from the command.
Example 2-9 -DIS THREAD(*) output
RRSAF TD 20335 MZSR014S MZADMIN ?RRSAF 00CF 6549
V485-TRUSTED CONTEXT=CTXDTRADET2,
SYSTEM AUTHID=MZADMIN,
ROLE=DTRADEROLE
V437-WORKSTATION=TraderClientWorkst, USERID=1TraderClientUse,
APPLICATION NAME=TraderClientApplication1
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset