518 WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
This interruption can have the following results:
The thread can be freed.
In this case, the user whose request hung receives an exception. The administrator can
define the type of action to take (none, svcdump, javacore, or traceback).
The thread cannot be freed.
If a thread cannot be freed, the system action depends on the administrator settings. The
options are as follows:
– Abend the servant.
– Keep the servant up and running.
– Perform a memory dump.
The basic options are still the same as in previous versions of WebSphere Application Server
for z/OS. If a thread cannot be freed, the decision about whether a servant is abended or kept
alive depends on the following factors:
The amount of processor time that is used by the thread (looping or just hanging)
Whether the servant is the last servant available
The number of threads that are already in a hung state, within this servant
If a thread that was reported to the control region as hung completes, the control region is
notified. The thread is no longer considered in the threshold determination.
The DISPLAY command
The DISPLAY,THREADS command shows the dispatch threads that are currently active. This
command shows every dispatch thread in every servant region that is associated with the
specified control region.
16.2 Functions in WebSphere Application Server for z/OS V8.5
This section highlights the functions in WebSphere Application Server for z/OS V8.5. See
Chapter 2, “Concepts of WebSphere Application Server” on page 21, for an overview of the
general concepts, functions, and features for WebSphere Application Server.
The following features are specific to WebSphere Application Server for z/OS V8.5:
WebSphere optimized local adapter high availability support
Resource Workload Routing
Improved reliability, availability, and serviceability (RAS) granularity for work requests
High Performance Extensible Logging (HPEL)
Distributed identity mapping using System Authorization Facility (SAF)
16.2.1 WebSphere optimized local adapter
The WebSphere optimized local adapter is a high speed cross-memory exchange that was
introduced with WebSphere Application Server for z/OS V7.0.0.4. It was enhanced with
support for Information Management System (IMS) in the V7.0.0.12 fix pack and proxy
function in V8.0.0.1. WebSphere optimized local adapter now allows for callers and targets to
be located separately on operating system instances other than z/OS. Callers and targets
include CICS regions, IMS regions, z/OS UNIX System Services processes, batch programs,
and airlines line control (ALCS) regions.
Chapter 16. WebSphere Application Server for z/OS 519
The WebSphere optimized local adapter is built on a cross-memory service that WebSphere
Application Server for z/OS uses for internal IIOP calls between servers on the same LPAR.
This service bypasses the TCP/IP stack, avoiding network and serialization latency. This
service is externalized so that programs in external address spaces can access
cross-memory service to communicate with WebSphere Application for z/OS Java programs
(Figure 16-8).
Figure 16-8 WebSphere optimized local adapter communication
The WebSphere optimized local adapter provides bidirectional communication from
WebSphere Application Server to external address spaces (outbound) and from external
address spaces to WebSphere Application Server (inbound). Shared memory space
exchange control blocks owned by daemon are above the 2 GB bar and 64-bit native callable
APIs for C/C++ are available.
Using the WebSphere optimized local adapter provides the following benefits:
Performance improvement
The ability to pass parameter data by using binary techniques provides a performance
improvement. The transport-level support that the adapters provide uses z/OS
cross-memory services. These services are used to optimize performance of calls to
applications deployed on a locally accessible WebSphere Application Server for z/OS
server.
The optimized local adapters also provide a high performance local binding for existing
application, middleware, and subsystems on z/OS platforms.
Identity context propagation
For inbound requests to WebSphere Application Server using optimized local adapter
APIs, the user ID on the existing z/OS thread is always propagated and asserted in the
WebSphere Application Server EJB container.

Get WebSphere Application Server V8.5 Concepts, Planning, and Design Guide now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial