400 IBM WebSphere Application Server V8 Concepts, Planning, and Design Guide
To take advantage of the enhanced HA manager discovery and failure mechanism, the
following requirements must be satisfied. Otherwise, you must use the default policy.
Configure the z/OS IBM VTAM® component to start XCFINIT=YES to enable TCP/IP to
use the XCF service.
Ensure that all core group members are at WebSphere Application Server V7 or later.
Ensure that all core group members are running on the z/OS platform.
If the core group is bridged to another core group, ensure that all bridged groups reside on
z/OS in the same sysplex.
From an architectural side, using XCF adds the components shown in Figure 14-6 to a
WebSphere Application Server environment.
Figure 14-6 Architectural changes when using XCF support
Figure 14-6 illustrates the following main changes:
The internal failure detection of the HA manager is factored out of the DCS structure.
Instead, the XCF failure detection is used to notify the HA manager.
The Discovery Service, which is used to communicate with the HA manager, now
communicates with the XCF component of z/OS.
XCF plugs into the Distribution and Consistency Service to perform the alive check and to
disable the TCP/IP ping-based heartbeat.
14.1.10 z/OS Fast Response Cache Accelerator
You can configure WebSphere Application Server for z/OS to use the fast response cache
accelerator (FRCA) facility of the z/OS Communications Server TCP/IP. The FRCA has been
used for years inside IBM HTTP Server to cache static content, such as pictures or HTML files.
Default HA Manager
HA Manager with XCF
Chapter 14. WebSphere Application Server for z/OS 401
You can use the high-speed cache to cache static and dynamic contents, such as servlets
and JavaServer Pages (JSP) files, instead of using the WebSphere Application Server
Figure 14-7 shows the changed flow of a request for a JSP that can be answered from the
cache, assuming that IBM HTTP Server also resides on z/OS:
Without Fast Response Cache Accelerator, a request must be processed by TCP/IP and
then by IBM HTTP Server on z/OS until WebSphere Application Server can answer the
request from its Dynacache.
With Fast Response Cache Accelerator, a request to a cached JSP is recognized in the
TCP/IP processing and is answered directly.
Compared to dynamic cache, the benefits of using the FRCA are a reduced response time
and a reduced processor cost for the serving of requests. Tests have shown that a request
served from the FRCA uses approximately 8% of the processor time than the same request
consumed in a dynamic cache environment. These advantages come from its structure,
because the FRCA cache can serve incoming TCP/IP requests directly (Figure 14-7).
Figure 14-7 Overview of Fast Response Cache Accelerator
Attention: The FRCA function requires z/OS 1.9 or later. IBM is not planning to include
this support through a program temporary fix (PTF) for earlier versions of z/OS.
The z/OS Communications Server TCP/IP service updates to the FRCA support are required
for this function to work on z/OS Version 1.9. If the updated FRCA services are not available
on the system, the application server issues a BBOO0347E or BBOO0348E error message.
TCP/IP uses communications storage manager (CSM) storage to maintain the cache.
Connections support: At the time of writing this book, the FRCA cache supports only
non-Secure Sockets Layer (SSL) connections.
With FRCA exploitation:
With FRCA exploitation: