Access To CICS From WebSphere Application Server Using CTG- zJournal 1209

and monitoring, and new enhancements C, C++, COBOL, or COM interfaces.
Access to CICS in CTG V7.1 and V7.2.
To help you determine the best way JCA and CTG Topology
From to access CICS from WAS, this article
also covers a new offering in WAS on
Before we delve into CTG topology
and available resource adapters, let‘s
WebSphere z/OS V7 called WebSphere Application
Server for z/OS Optimized Local
review JCA, which defines a standard
for connecting Java 2 Enterprise Edition
Application Adapters (WOLA). This new method of
cross-memory local communications
(J2EE) to heterogeneous Enterprise
Information Systems (EISs) such as
Server Using between WAS for z/OS and CICS has
bi-directional capability, so you can
CICS. The architecture defines a set of
scalable, secure, and transactional
CICS leverage WAS Enterprise JavaBean (EJB)
assets as local services from CICS.
mechanisms that enable the integration
of EISs with application servers and
Transaction Overview
enterprise applications. WAS, as a pro-
prietary J2EE application server, can be
Gateway CTG is a set of client and server soft-
ware components that enable a Java
extended to support the resource adapt-
er architecture and is then assured of
application to invoke services in an seamless connectivity to multiple EISs.
attached CICS server. Remote Java cli- IBM provides a standard resource
By Elena Nanos ents can call CICS applications using
ECI Support and Distribute Program
adapter with the capability to plug into
any application server that supports the

M ost organizations today are trying
to maintain a delicate balance
between staying competitive and meet-
Link (DPL) using COMMAREA or
channels and containers (if supported,
depending on the CICS and CTG
connector architecture. The Qualities of
Service (QoS) provided by the JCA vary,
depending on the topology in use.
ing demanding business needs, while level). Figure 1 shows CTG and WAS topology
keeping development costs down. To CTG is a widely used J2EE connec- choices.
help meet customer demands and pro- tor for CICS Transaction Server (CICS With topology 1, WAS and CTG are
tect your investment in CICS legacy TS) and, in conjunction with WAS, pro- deployed on a distributed platform.
applications, IBM continues to enhance vides a high-performing, secure, scal- Both ECI and External Presentation
CICS Transaction Gateway (CTG), able, tightly integrated access method in Interface (EPI) resource adapters can be
which runs on z/OS, Linux, Linux on CICS. CTG is scalable, performs well used in this configuration. To exploit
System z, AIX, Solaris, HP-UX, and with minimum overhead, and usually CTG V7, WAS must be at V6.1 or high-
Windows. doesn’t require any changes to existing er.
This article provides an overview of CICS applications. By using CTG, you With topology 2, WAS is deployed
architectural choices using different can expand the value of your existing on a distributed platform and CTG is
CTG topology to integrate CICS and CICS legacy applications and take on z/OS. Using this configuration, you
WebSphere Application Server (WAS) advantage of WAS functionality. can exploit CTG V7 with WAS V6.0
on z/OS and distributed platforms, CTG provides a range of networking using CTG remote mode. This topology
modes of implementation, and J2EE options and a choice of Java and non- offers several advantages:
Connection Architecture (JCA) resource Java client programming interfaces. The
adapters. It also examines the tools client application can be a Java applica- • CTG scalability and availability
available for problem determination tion or non-Java application using either enhancements
• IP workload management functions,
including Sysplex Distributor and
TCP/IP port sharing
• Two-Phase Commit (TPC) support
• Optimized TCP/IP networking, which
provides faster response times in high-
bandwidth networks
• Storm drain avoidance for fine-grained
control of health updates to Workload
Manager (WLM)
• Extended real-time monitoring of
CTG, which provides advanced capac-
ity planning and problem determina-
tion facilities
• Interval-based statistics and offline
recording to System Management
Facility (SMF)
• Ability to reduce the CPU cost of the
gateway daemon processing, which is
written in the Java language, by
exploiting System z Application Assist
Figure 1: Topology Choices With CTG and WAS Processor (zAAP) specialty engines.

42 • z/Journal • December 2009/January 2010 z/Journal • December 2009/January 2010 • 42

(Specifically, using the External Call ning CTG in remote mode. provided for use with CTG on z/OS:
Interface [EXCI] protocol, 40 percent
of the workload is zAAP-eligible. Resource Adapters • cicseci.rar: This CICS ECI non-XA
While using CTG V7.2 and the IP CTG uses the CICS ECI resource resource adapter provides one-phase
Interconnectivity (IPIC) protocol, 90 adapter, which is a system-level software transactional support (known as local
percent of the workload is zAAP-eli- driver that a Java application uses to transaction support) when deployed
gible.) connect to an EIS. A resource adapter is into WAS on any supported platform.
installed into an application server and This adapter avoids the overhead of
With topology 3, WAS and CTG provides connectivity between the EIS, unnecessary XA flows.
both run on z/OS. CTG runs on the the application server, and the enter- • cicsecixa.rar: The CICS ECI XA
same Logical Partition (LPAR) as WAS prise application. These adapters come resource adapter provides two-phase
for z/OS and only the CICS ECI resource with CTG and are installed under WAS transactional global support when
adapter is supported. This solution pro- for z/OS when running in a local mode. deployed into WAS on any supported
vides many of the same benefits as The Resource Adapter Archives (RAR platform. It should be used when there
topology 2, plus CTG can run under files) are supplied in the <install_path>/ are updates to two or more resource
WAS for z/OS JVM, using cross-memo- deployable directory. managers (i.e., CICS and DB2) as part
ry communication for substantial per- The following resource adapters are of a global transaction. This adapter
formance improvements.

Modes of Operation
There are two modes of operation
with CTG and WAS: local and remote.
In local mode, CTG runs inside WAS
for z/OS servants such as Java Virtual
Machines (JVMs). Using CTG in local
mode is desirable if you want to use
Resource Recovery Services (RRS) for
optimized TCP recovery, automatic
ThreadIdentity, and the lowest path
length.
When CTG is on the same LPAR as
WAS for z/OS, it’s more efficient to use
the CTG classes in WAS for z/OS for
gateway functionality. This mode lets
WAS for z/OS manage the connections
and threads, and reduces communica-
tions overhead using cross-memory
communication. Figure 2 demonstrates
running CTG in local mode.
It’s possible to run in a local mode
when WAS is deployed on Linux on Figure 2: CTG in Local Mode
System z. This configuration provides a
highly flexible, scalable environment
based on the virtualization capabilities
of IBM z/VM and Linux systems. One
of the advantages of this configuration
is that you can use the IBM HiperSockets
hardware feature to provide a highly
efficient, cross-memory transport for
TCP/IP-based communication into
CICS. The JCA QoS for this configura-
tion is the same as described for topol-
ogy 1 (see Figure 3).
Remote mode of operation is when
CTG runs stand-alone and has gateway
daemon. On z/OS, it runs under z/OS
UNIX System Services as a started task.
Using the gateway in stand-alone mode
on z/OS allows building of a High
Availability (HA) configuration. It also
provides support for remote clients,
Secure Sockets Layer (SSL) support,
systems monitoring statistics, and SMF
recording. Figure 4 demonstrates run- Figure 3: CTG and WAS on Linux on System z


has more overhead. An EXCI pipe is a virtual session maximum concurrent threads is equal
used for cross-memory communica- to the maximum number of pipes
A word of caution about using a tions; the EXCI itself is the Application divided by the number of servers. If
non-XA resource adapter: If your appli- Program Interface (API) used by the you need predictable usage, consider
cation is doing read-only in CICS, you batch client, such as the CTG. The using this setting. This model provides
may wish to consider turning the CICS maximum number of pipes the EXCI optimum performance, but once a
call into a SYNCONRETURN call to can use was raised to 250. In CTG V6.0, pipe has been allocated, it remains
prevent RRS from coordinating a unit a new enhancement was introduced to allocated to this particular region and
of work, since EXCI calls to CICS always reuse EXCI pipes. isn’t available for use with other CICS
participate in TPC, even if CICS is The CICS J2EE connectors, when regions.
doing read-only. (IBM recommends run in conjunction with WAS for z/OS,
wrapping the call to CICS inside a create a cache of EXCI pipes instantiat- If you’d like to be alerted when
UOWAction object and passing it to ed inside the WAS servant address approaching a limit on EXCI pipes in
UOWManager.runUnderUOW with space. The CTG creates and controls CICS, you can use CICS user-replicable
U O W _ T Y P E _ L O C A L _ this cache. In addition to the EXCI pipe exit, DFHXCURM, to write a warning
TRANSACTION. This applies only to cache, WebSphere controls a pool of message to the console.
calls from container-managed transac- connections obtained from the J2C
tions marked as transactional if the Connection Factory, the attributes of IPIC
requests are non-transactional which are set during deployment of the With CICS TS 3.2, IBM introduced a
[NotSupported or Never]; then syncon- CICS resource adapter. new IPIC option that provides CICS
return calls will be issued to CICS any- In WAS, EXCI pipes can be opti- communications support over TCP/IP
way.) Rollback exceptions in WAS can mized based on throughput or concur- as an alternative to that provided over
occur for z/OS global transactions using rency. Usage can be controlled by InterSystem Communication (ISC) and
the non-XA resource adapter and configuring the following WAS envi- Multi-Region Operation (MRO).
include CICS read-only calls in Message- ronment variables: Shortly after CICS TS V3.2 became gen-
Driven Bean (MDB) Unit Of Work erally available, IBM delivered CTG
(UOW) that also does updates to • CTG_PIPE_REUSE=ONE lets you V7.1, the first release to support IP con-
WebSphere MQ (WMQ) and DB2. You allocate one pipe per thread. With this nectivity from the gateway daemon or
can address this issue by separating setting, the maximum concurrent the resource adapter directly to CICS
CICS calls in a local transaction UOW. number of threads depends on the TS V3.2 or higher.
When using the CTG in a local maximum available number of pipes. With CTG V7.1 came much-antici-
mode with WAS for z/OS, either cicseci. The EXCI cache should be limited to pated support for channels and contain-
rar or cicseciXA.rar can be used; both one pipe per thread (of the servant ers. The IPIC option now lets you send
support the RRS transaction support in region) to avoid pipes being allocated and receive more than 32KB of applica-
WAS for z/OS. beyond the CICS EXCI pipe limit. tion data in a single ECI request and
Also, using this setting will prevent provides additional transaction tracking
EXCI Pipes WAS on z/OS from allocating more capabilities. Also, the IPIC networking
Once you have a working CTG con- pipes than there are threads in the ser- capabilities of CICS TS provide addi-
figuration, you can start focusing on vant region. tional support for SSL and XA TPC
tuning. EXCI pipe settings can impact • CTG_PIPE_REUSE=ALL lets you connections directly from WAS into
your throughput rate and performance. reuse all the pipes. Using this setting, CICS and have a fully zAAP-enabled
code path.
Another important benefit of using
IPIC is that WAS on z/OS and CICS
need not reside in the same LPAR
because XA requests are sent directly to
CICS from the CICS ECI XA resource
adapter.

CTG V7.2
CTG V 7.2, available since late 2008,
runs Java 5 and supports WAS V6.1 and
V7.0. When used in remote mode only,
it requires the correct resource adapter
for the level of WebSphere being used,
and also WAS for multi-platforms V6.0,
V6.1, and V7.0.
CTG V7.2 delivered improved inte-
gration for new and existing client run-
time environments and a new type of
remote client support using the capabil-
ities of the gateway daemon. A set of C
run-time libraries and language bind-
Figure 4: CTG in Remote Mode ings were provided, enabling lightweight


client support for ECI requests from A CICS request exit also can be used using CICSPlex System Manager (SM).
remote client environments providing to enable dynamic selection of CICS Each Java client application can have its
access to CICS COMMAREA-based servers for workload balancing. own APPLID and APPLID qualifier
applications. This support enables SupportPac CA1T provides a configu- uniquely identifying it to the gateway
potential use in a wide variety of client rable failover solution using CICS daemon. This information can then be
run-time environments, including C++, request exits and offers the ability to used as part of the original data func-
COBOL, and Microsoft .NET. build an HA solution and request vali- tionality, which is part of the new IPIC
CTG for z/OS V7.2 delivers enhanced dation policies. functionality. New transaction monitor-
capability to build HA system architec- ing exits can be configured in remote
ture by integrating with the z/OS Sysplex Tuning Statistics and local mode. This provides an infra-
Distributor and RRS. New features can CTG is no longer a “black box,” and structure for tracing transactions and
help your company improve your avail- starting with CTG 7.0, new monitoring monitoring the CTG.
ability and have greater control in man- capabilities were introduced using CTG 7.2 further enhances monitor-
aging your overall infrastructure. You remote mode. CTG V7.0 introduced ing capabilities and can now integrate
can now extend cloned gateway config- real-time monitoring capabilities and with the CICS Explorer, a common,
urations across the Parallel Sysplex provided the ability to analyze system intuitive Eclipse Rich Client Platform
when providing XA support for global utilization metrics and perform online (RCP)-based environment for systems
transactions from WAS. problem determination. It enables administration. Also, a new Java API for
You should be aware of some impor- access to key statistics about gateway systems monitoring is provided,
tant restrictions when using CTG V7.2 daemon, CICS status, connections, enabling access to the CTG run-time
in a Sysplex environment: threads, and protocol handlers. This is statistics from remote Java clients.
the first CTG release that lets you For more information on CTG mon-
• The CICS Transaction Gateway retrieve online statistics by issuing a itoring, please refer to IBM Redbook
instance must run on the same LPAR z/OS system MODIFY command Exploring Systems Monitoring for CICS
as the CICS region to which it’s send- against the gateway daemon address Transaction Gateway V7.1 for z/OS at
ing requests if you’re using EXCI CICS space or use an API to do it program- www.redbooks.ibm.com/abstracts/
server connections with the ECI matically. sg247562.html?Open.
resource adapter, global transactions, CTG V7.1 further extended real-
or a remote client application with time monitoring and provides advanced CTG SupportPac CH51 Monitoring Utility
extended Logical Unit of Work (LUW) capacity planning and problem deter- If you’re running CTG in local mode
requests. mination facilities, and added SMF111 and can’t take advantage of monitoring
• An IPIC connection between CTG records and analysis via CICS capabilities available in remote mode
and CICS region must not be load bal- Performance Analyzer (PA) V2.1. With only, consider using SupportPac CH51,
anced through any TCP/IP port shar- CICS PA SupportPac CP12, you can which is a simple monitoring utility
ing or load balancing software. now use Excel to chart statistical data based on the CTG request monitoring
• A gateway daemon in a gateway group such as average response times, time- exits. It’s designed for auditing purposes
can be started in any LPAR in the out counts, and peak thread usage indi- and to analyze performance-related
Sysplex, but you must ensure the same cators. Figure 5 shows sample output. issues. This support pac is applicable to
RRS logging group is used in each CTG 7.1 also enables you to do CTG in local and remote mode.
LPAR. advanced workload monitoring and get The output of the exit is kept to a
point-of-origin information and trans- minimum so the performance impact is
EXCI user-replaceable module DFHXCURM action correlation for IPIC requests as low as possible. The utility generates
and CICS request exit
IBM made several enhancements to
help you build an HA solution with
CTG; you can now use EXCI user-
replaceable module DFHXCURM,
which enables you to retry an EXCI
request to another CICS region when an
EXCI error occurs. EXCI calls
DFHXCURM every time it needs to
open a new “pipe” to CICS for an initial
ECI call for each thread or on pipe re-
allocation (if using CTG_PIPE_
REUSE=ONE). Note that DFHXCURM
is limited to EXCI/COMMAREA
requests only.
IBM also provides a “DFHXCURM”
equivalent with CICS TG 7.2, which
supports IPIC. It’s a Java-based user exit
called “cicsrequestexit” that allows
requests to be redirected. This exit has
some advantages over DFHXCURM,
but it’s available in remote mode only. Figure 5: Performance Data Using CICS PA


a one-line message for each ECI request Definition > Servant > Java Virtual CICS, as well as batch programs and
that flows through the gateway. This Machine > Custom Properties. UNIX Systems Services programs.
message lists the total response time for • Run CTG client launch test: You can Key advantages:
gateway processing along with the CICS use the IBM launchClient tool for
call response time and individual details WAS to test CTG connectivity run- • Efficient cross-memory transfer from
about each request (see Figure 6). ning J2EE application clients. The WAS to the external address space or
launchClient batch command starts from the external address space into
Problem Determination the application client run-time that WAS
When running CTG in local mode initializes the client run-time, loads • Bi-directional capability: You can
under WAS on z/OS to debug EXCI the class, and runs the main method leverage WAS EJB assets as local ser-
call-related issues, you have these of the application client program. vices from external address spaces
options: such as CICS or batch programs. CTG
Welcome, WOLA provides only outbound to CICS sup-
• Set J2C trace: You can do this via the If you’re just starting to develop new port.
WAS administrators console by set- interfaces between CICS and WAS for • Security propagation: From WAS, you
ting “WAS.j2c*=all” in Application z/OS and are looking for an alternative can flow the user ID, servant ID, or
servers > server > Logging and Tracing to CTG (and the costs associated with EJB role ID into the external address
> Change Log Detail Levels. WAS the license), new functionality in WAS space; or from the external address
server restart is needed to pick up this for z/OS V7 may be an alternative, space, you can flow the client ID or, in
change. To verify that J2C trace is depending on requirements and if con- the case of CICS, the CICS region ID
enabled, check for message nectivity between WAS and CICS is on or the CICS task userid.
BBOO0222I: TRAS0017I: The start- the same LPAR. • Transaction propagation: When oper-
up trace state is *=info:WAS.j2c*=all. WOLA is a new function provided ating from CICS into WAS, WAS can
• Set CTG trace: You can do this via with WAS for z/OS maintenance level participate in a CICS UOW for TPC
WAS admin console by setting gate- 7.0.0.4. It provides cross-memory local processing. However, in the initial
way.T.trace custom Property to ‘on’ at communications between WAS for z/OS release of WOLA in Version 7.0.0.4,
Application servers > Process and external address spaces such as transaction processing isn’t supported
for flows from WAS into CICS, other-
wise known as “outbound” from
WAS.

CTG vs. WOLA
Key differences between CTG and
WOLA include:

• CTG provides the ability to access
CICS resources from WAS in another
LPAR, or platform. WOLA is used
only for same-LPAR, cross-memory.
• WOLA can’t route requests to differ-
ent CICS regions on different LPARs
in the event of a region loss locally.
CTG is designed to support HA archi-
tecture.
• CTG provides the ability for CICS to
Figure 6: Sample CH51 Monitoring Utility Output participate in TPC; WOLA currently
supports only outbound from WAS
into CICS.
• CTG uses CICS EXCI API; WOLA
has its own API. Some custom code
exploiting the WOLA APIs is needed.

IBM positions WOLA not as a
replacement for CTG, but as a comple-
ment to CTG. Figure 7 highlights advan-
tages of using WOLA and CTG.
For more information, refer to IBM
techdoc WP101490, “A Brief
Introduction to WebSphere for z/OS
Optimized Local Adapters,” available at
www-03.ibm.com/support/techdocs/
atsmastr.nsf/WebIndex/WP101490.

Figure 7: Relative Advantages of WOLA and CTG Conclusion


CTG lets you evolve applications
without re-inventing the existing busi-
ness logic. IBM continues to enhance
CTG functionality, performance, avail-
ability, system management, and moni-
toring. CTG support for JCA allows
J2EE applications running in WAS to
exploit proven qualities of CICS. Using
the JCA simplifies application develop-
ment by providing a familiar, standard
interface that programmatically
manages transactions, connections, and
security. Z

Acknowledgement
Thanks to Phil Wakelin from IBM CICS Strategy and
Planning and Don Bagwell from IBM Advanced
Technical Support for their help reviewing the article
and providing advice on its technical content.

About the Author
Elena Nanos is a certified solution expert in CICS
Web enablement, WebSphere Application Server
ND administration, and MQSeries. She has 27 years
of experience in infrastructure support, system
architecture, integration, and middleware planning,
implementation, and support. She specializes in
WebSphere for z/OS, MQSeries, CICS TS, and CTG.
She has published numerous technical articles and
presented at IBM conferences.
Email: elena.nanos@comcast.net

Callout: WOLA is a new
method of cross-memory
local communications
between WAS for z/OS and
external address spaces such
as CICS.


Access To CICS From WebSphere Application Server Using CTG- zJournal 1209

More Related Content

Similar to Access To CICS From WebSphere Application Server Using CTG- zJournal 1209

More from Elena Nanos

Recently uploaded

Access To CICS From WebSphere Application Server Using CTG- zJournal 1209