Chapter 3. CICS connectivity options 57
3.4.1 Local CICS connection: Attributes
Figure 3-5 Local connection attributes
A local connection, as in Figure 3-5, provides better performance than a remote
connection because no network overhead is involved in processing the request.
Using a local CICS TG uses less CPU capacity than a remote connection CICS
TG daemon because there is no separate CICS address space. The protocol is
more efficient through the use of the cross-memory services.
You also eliminate the network latency from the WebSphere application to the
CICS TG daemon. Performance also depends on the number of threads open,
due to the amount of memory they use.
Within CICS there is a resource definition that defines the EXCI connection into
CICS. The resource definition consists of a
connection definition and a sessions
definition. The CICS systems programmer should ensure that the number of
sessions defined for the EXCI connection is greater than the number of EXCI
pipes which are allocated by the WebSphere servant regions. The maximum
number of sessions for an EXCI connection is 999.
Another factor indirectly limiting the number of threads and pipes through the
EXCI to CICS is the number of Java threads in a servant region. This number
cannot be set directly. The number of threads depends on the choice of
Workload Profile.
Best end-to-end performance
Uses less memory than external
Takes advantage fo EXCI efficiencies
RACF can be used for this
Thread Identity available for local
resources via WebSphere
Vertical scaling with zSeries
Single z/OS image with two points
of failure
Full two-phase commit
58 WebSphere for z/OS Connectivity Architectural Choices
Performance is affected by the number of pipes, threads and the number of
servant regions. Because there are multiple limitations for the pipes, threads and
number of servant regions, careful planning is required for a demanding
workload. Also the workload heaviness, sheer volume, on the WebSphere and
the CICS side influences how many servant regions are needed to optimize the
throughput. It might be necessary to increase the number of servant regions,
obtaining more threads, to achieve high workload levels.
Queuing work in the WebSphere servant regions uses excessive memory and
drastically degrades the performance of the system. It is better to ensure that any
queuing takes place in the HTTP Server in front of WebSphere.
On a single LPAR, a local connection has two points of failure:
򐂰 WebSphere Application Server
򐂰 the local CICS
There is no backup solution in this single LPAR case.
Transactional capabilities
This is a full-function, two-phase commit process with RRS coordinating the
Resource Managers.
A local mode configuration is one that follows the traditional z/OS authentication
model. That is, you authenticate at the entry point to z/OS. For a J2EE
application it is normally in an HTTP Server or in WebSphere for z/OS. After
authentication, your security identity, for example a Recourse Access Control
Facility (RACF®) user ID, flows with you as you run work in different parts of the
If you have a J2EE application using J2CA to connect to CICS applications and
you want to be able to identify the originator of the transactions running in CICS,
however you authenticate in WebSphere, you need to associate a RACF user ID
with the request to CICS.
Note: Use of a server isolation policy provides you the choice of running one
transaction or multiple transactions per region. Executing more threads in an
address space will provide better performance, but potentially at the cost of
thread contention, which would be application-dependent. The thread value
with the isolation policy is set in the ORB Services Advanced Setting.

Get WebSphere for z/OS Connectivity Architectural Choices now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.