Redbooks Paper
Chris Rayns
Madhu B Ananthapadmanabh
Andrew Bates
Iain Boyle
TXSeries for Multiplatforms
Version 6 Revealed!
The Next Generation of
Distributed CICS
This IBM Redpaper provides a high-level introduction to TXSeries® for
Multiplatforms V6. In this Redpaper we describe the value proposition of this
product and how you can use it to build robust enterprise middleware solutions.
We cover the following topics:
򐂰 What is new in Version 6?
򐂰 Common deployment scenarios.
򐂰 Deployment, development, and administration choices.
򐂰 Comparing Mainframe Transaction Processing Monitors with Distributed
Transaction Processing Monitors.
© Copyright IBM Corp. 2006. All rights reserved.
ibm.com/redbooks
1
Introduction to TXSeries for Multiplatforms V6.0
TXSeries for Multiplatforms is IBMs premier distributed transaction processing
software for business critical applications.
򐂰 Being part of the CICS® family of products, it shares the same value
proposition: robust, secure, extendable, and scalable.
򐂰 You can use it to write new business applications, reuse existing applications,
access data from a variety of enterprise information systems (EIS), and even
extend your applications to the web and web services.
򐂰 As a true distributed transaction processing system, it allows you to distribute
both data and function across heterogeneous systems.
򐂰 TXSeries integrates well with other IBM® and IBM Business Partner products
allowing you to develop numerous different types of business solutions.
The latest version, TXSeries for Multiplatforms Version 6, provides the base
CICS functionality of previous versions of distributed CICS, but without the DCE
or Encina® prerequisites. This vastly simplifies the installation, configuration, and
administration of your TXSeries systems.
Introduction to distributed transaction processing
Every enterprise has a requirement for concurrent access to shared resources
and data. Most often, these shared resources are distributed across geographies
and even heterogeneous platforms. Applications written to do operations on
shared resources must maintain data integrity and consistency. To achieve this,
it may be required that a group of operations on shared resources be treated as
a single unit of work. This grouping is also called a transaction or a logical unit of
work (LUW).
Transaction is defined as a set of operations that transforms data from one
consistent state to another, and it has the following properties, popularly known
as ACID properties:
򐂰 Atomicity: A transaction's changes are atomic: either all operations that are
part of the transaction happen or none happen.
򐂰 Consistency: A transaction moves data between consistent states.
򐂰 Isolation: Even though transactions can be executed concurrently, no
transaction sees another transaction's work in progress. The transactions
appear to run serially.
򐂰 Durability: After a transaction completes successfully, its changes survive
subsequent failures.
2
Revealed! The Next Generation of Distributed CICS
Some examples of business transactions are banking, stock trading, a railway
reservation system, and so on. Let us consider a railway reservation system.
Following are the steps involved to make a reservation:
1. Verify the seat availability.
2. Get payment clearance from the bank.
3. Update seat availability information.
4. Print and mail the ticket.
You can group the above steps as a single transaction.
The following issues are involved when building a transactional application:
򐂰 The application should ensure atomicity by reverting the whole operation if
there is a failure in any one of the above steps. For example, if there is a
system failure while updating the seat availability information, the system rolls
back step 2, that is the payment received has to be credited back to the
requester.
򐂰 The application and database servers should implement a mechanism
whereby changes to databases are undone without loss of consistency of
data. If a reservation failed for some reason, the user should see the correct
information (bank balance and seat availability) during his next attempt.
򐂰 If there are multiple reservation requests for the same train, the system
ensures isolation by letting only one transaction update the seat availability
information at a time.
򐂰 The changes made by the application must be durable, meaning that it should
survive subsequent failures.
򐂰 If the business logic and data are distributed, it has to deal with network
protocols and inter system communications.
As we can see, it is very complex to build a transactional application from
scratch.
Distributed transaction processing system provides a framework for writing
business applications. As part of the framework it provides the following
functions:
System runtime functions: An execution environment that ensures the
integrity, availability, and security of data; fast response time; and high
transaction throughput.
System administration functions: Administrative support that lets users
configure, monitor, and manage their transaction systems.
3
Application development functions: Transaction processing monitors provide
functions for use in custom business applications, including functions to access
data, to perform inter-system communications, and to design and manage the
user interface.
By utilizing all the functionalities provided by a distributed transaction processing
system an application developer can better concentrate on business logic
without having to worry about other issues.
4
Revealed! The Next Generation of Distributed CICS
Technical value of TXSeries for Multiplatforms
TXSeries is positioned as an entry-level transaction server as well as a rapid
deployment, transactional integration platform. It can provide the critical
transaction and integration capabilities required to support your business goals.
As the IBM premier middleware product for distributed transaction processing in
traditional programming languages, TXSeries can serve as a critical component
of your SOA by enabling you to connect otherwise disparate applications and
data—helping you to run your business more smoothly and serve your
customers more effectively.
TXSeries delivers a managed environment for enterprise applications, enabling
developers to focus on business logic rather than failure detection, failure
recovery, and synchronizing access to shared data. It is the ideal program for
both stand-alone deployments, and also larger solutions that require tight
integration with other enterprise information systems such as CICS Transaction
Server, WebSphere® Application Server, and centralized System z9™ or
zSeries® infrastructures. It is the only distributed transaction-processing solution
designed to enable you to scale your applications to CICS Transaction Server on
the mainframe if your business requirements grow. And because it follows the
CICS programming paradigm, it is an ideal companion product for mainframe
CICS users with distributed application or integration requirements.
As part of the CICS family of products, TXSeries shares the value proposition of
being robust, secure, extendable, and scalable. You can build new applications
using procedural or object-oriented programming models across a range of
supported programming languages. It also provides a set of tools to debug your
applications including source level debugging.
TXSeries is designed to do distributed transaction processing. It runs on a wide
range of distributed platforms, giving you the flexibility to choose the most
suitable platform for your business. It runs on AIX®, Solaris™, HP-UX, and
Microsoft® Windows®. It supports full CICS intersystem communication with
high-data integrity. You can distribute both function and data across platforms.
TXSeries enables transactional access to external resource managers for
database and messaging systems. It supports a number of databases such as
DB2®, Oracle, Informix®, Microsoft SQL server, and Sybase. Full-data integrity
is provided through support of the XA interface, the industry-standard interface
defined by X/Open for managing commitment and recovery of transactional data,
including the two-phase commit process. For more information about XA and
X/Open standards refer to the following Web site:
http://www.opengroup.org
5
TXSeries is positioned as both a rapid deployment non-J2EE integration server,
and an entry-level non-J2EE transaction server.
Inter-operability with other CICS family of products lets you optimize your
applications’ cost, performance, and qualities of service by choosing the
appropriate set of
CICS clients, gateways, and servers to match your business needs. It is the ideal
program for both stand-alone deployments, and also larger solutions that require
tight integration with other enterprise information systems such as CICS
Transaction Server, WebSphere Application Server, and centralized System z9
or zSeries infrastructures. You can re-platform applications developed in
TXSeries to CICS Transaction Server for z/OS® if your business requirements
demand it.
To summarize, you can use TXSeries for Multiplatforms to do the following:
򐂰 Build new applications using both traditional and modern languages like C,
C++,PL/I, COBOL and JAVA.
򐂰 Reuse existing applications and application programming skill sets in your
organization.
򐂰 Extend CICS applications to the Web and Web services via the CICS
Transaction Gateway and WebSphere Application Server.
򐂰 Access data and applications in various distributed and back-end systems
including CICS and IMS™.
What is different about TXSeries for Multiplatforms Version 6.0
TXSeries for Multiplatforms V6.0, the next generation of distributed CICS,
removes all dependencies on separate Encina and DCE technologies.
Equivalent function is now provided in the following two core components:
򐂰 Entry-level CICS On-Line Transaction Processor (OLTP)
򐂰 Integrated CICS Structured File Server (SFS)
Product simplification
The core theme of TXSeries for Multiplatforms Version 6.0 is simplification. All
CICS users, especially the System Administrators, can now benefit from a
significantly simplified environment enabling them to be considerably more
productive.
CICS processes now communicate using secure shared memory, which
enhances performance and security with zero configuration or administration
required. Another core part of the product simplification is the Encina component
integration. The Encina prerequisite was removed and is no longer required or
6
Revealed! The Next Generation of Distributed CICS
supplied with TXSeries. Major functionality is now fully integrated with the base
CICS OLTP server that is supplied with the TXSeries product. As a result of
Encina integration and DCE removal, the product install is simplified. It is now a
single product install.
Simplified security
Security handling was also simplified, when using TXSeries in conjunction with a
mainframe, by introducing a new External Authentication Manager (EAM)
module that uses the Lightweight Directory Access Protocol (LDAP) to integrate
with Resource Access Control Facility (RACF®). You can now centrally define
and maintain all of the system users in a RACF repository.
Enhanced installation
Installation and version-to-version migration is now significantly enhanced by
utilizing Install Shield Multiplatform (ISMP) as the installer on all platforms. This
simplifies the installation process and, using an industry standard installation
program, allows quick and easy customization of the installation.
There is an optional installation verification procedure (IVP) that creates and
starts a region with SFS as a file manager. The results of IVP are communicated
to the user.
Overhauled documentation library
Major revision to the documentation library provides a much clearer product
overview that leads to faster and easier product deployment and administration.
This documentation library was fully incorporated into the standard Eclipse
based information center, which provides many benefits including the ability to
search all installed Eclipse based IBM information centers in one search.
Extended product support
TXSeries for Multiplatforms Version 6.0 extends support for the most recent
versions of other products that are commonly used by TXSeries customers,
including databases, communications subsystems, and system compilers for all
supported programming languages. Also added is support for Acucorp open
systems COBOL, ACUCOBOL-GT. ACUCOBOL-GT is a COBOL development
system that includes a compiler, a source-level interactive debugger, and nearly
a dozen support utilities. ACUCOBOL-GT lets you write a program once, and run
it in any other TXSeries platform without recompiling.
Other enhancements include a new system function diagnostic facility that
provides additional internal state information than was previously available. This
helps with problem determination by assisting IBM support representatives to
remotely diagnose potential problems.
7
Core components of TXSeries
TXSeries for Multiplatforms provides the following two core components:
򐂰 An entry level CICS Online Transaction Processor
򐂰 An integrated CICS Structured File Server
Entry-level CICS Online Transaction Processor
The entry-level CICS Online Transaction Processor (OLTP) supports the base
level CICS application programming interface (API) that provides the ACID
properties of atomicity, consistency, isolation, and durability. By delivering these,
TXSeries allows developers to focus on the application logic, rather than failure
detection, failure recovery, and synchronizing access to shared data. Without the
ACID properties, the integrity of the organizations data cannot be guaranteed.
Integrated CICS Structured File Server
The integrated CICS Structured File Server (SFS) is a VSAM emulating
record- oriented file system that can provide indexed, relative, and sequential
access to file based data. It allows developers to store fully recoverable file
based data that can be processed in a batch environment. The CICS SFS files
can be shared among TXSeries, CICS Transaction Server and non-CICS
applications, such as IMS. This maximizes the ability to interoperate in an
enterprise environment.
8
Revealed! The Next Generation of Distributed CICS
Common TXSeries deployment scenarios
TXSeries for Multiplatforms is ideally suited to deployment in two common
business-value scenarios:
򐂰 TXSeries as a rapid deployment, transactional integration server
򐂰 TXSeries as a transaction server
TXSeries as a rapid deployment transactional integration server
TXSeries for Multiplatforms has extensive support for many enterprise
information systems (EIS) including IBM CICS Transaction Server, IMS, DB2,
WebSphere MQ, and WebSphere Application Server. It can use both TCP/IP
and SNA based communication protocols. The ability to run intelligent business
logic in a mid-tier environment that supports the same languages and APIs as
the systems that require the integration enables a complex integration solution to
be deployed extremely rapidly. Following are the three most common integration
server deployment scenarios:
򐂰 A consolidating mid-tier terminal server
򐂰 An intelligent mid-tier gateway between a J2EE™ application server and
more than one EIS
򐂰 A comprehensive mid-tier integration server
A consolidating mid-tier terminal server
In this scenario TXSeries acts as a relatively simple terminal concentrator
between conventional terminal based end-users and an Enterprise Information
System such as CICS. TXSeries supports a number of locally connected industry
standard graphical or screen based terminals, providing users with fast
responses and reduced network traffic. Any transactions or requests for work
that the users submit are simply routed to the EIS for execution. In general all
data and business logic remains on the EIS. The only exceptions are routing
data required by TXSeries to make routing based decisions and local
transactions involved in routing the requests to the EIS.
If we consider a banking solution where all of their applications run on
Mainframe, TXSeries can be used as a client concentrator in every branch office
of the bank. See Figure 1 on page 10. Bank staff or Client Service
Representatives (CSRs) in the branch office use industry specific graphical or
screen-based terminals connected to the local TXSeries server. Any transactions
the users enter are routed to the CICS Transaction Server located in the bank’s
central data centre for execution.
9
TXSeries is effectively taking the entire client load and reducing the number of
connections to mainframe.
Key features of this deployment are as follows:
򐂰 Reduced number of connections to the EIS, since many terminal connections
are replaced with one connection from TXSeries.
򐂰 EIS is protected from client originated network disruptions.
򐂰 Takes advantage of the wide range of terminals supported by TXSeries.
򐂰 No duplication of business data on the TXSeries environment.
TXSeries
CICS TS
CUC
SNA
HOD
TCP/IP
TN3270
CORBA
Figure 1 Consolidating mid-tier terminal server
An intelligent mid-tier gateway
TXSeries can provide excellent integration with one or more EIS. Its ability to
handle transactions makes it an ideal intelligent mid-tier gateway. There is a vast
range of business application intelligence that you can build into TXSeries; for
example, it can perform security checks, do smart routing based on client
request, and it can even run decision making transactions to achieve intelligent
routing. The conventional terminal-based client interfaces can be extended to the
Internet using the facilities of WebSphere Application Server and CICS
Transaction Gateway. This scenario is widely used in very large deployments,
where a number of the mission critical applications run on Mainframe.
10
Revealed! The Next Generation of Distributed CICS
This scenario builds upon the previous scenario in three important areas.
1. Using the facilities offered by WebSphere Application Server and CICS
Transaction Gateway, organizations can extend the conventional
terminal- based interfaces provided by TXSeries to include intuitive and rich
World Wide Web interfaces on the Internet.
2. Acting as an entry level online transaction processing system, TXSeries is
capable of making intelligent business decisions on its own.
3. TXSeries has the ability to access and update multiple EIS systems in a
transactional coordinated manner without loosing or corrupting data.
By coupling these three capabilities with the previous scenario, refer to Figure 2
on page 12, TXSeries can act as an intelligent gateway between many different
users and multiple EIS systems. TXSeries can now make business decisions
based upon business data retrieved from multiple EIS systems and present the
decisions to users in a number of different ways.
Consider an insurance company where most of the critical data is stored on
Virtual Storage Access Manager (VSAM) and Information Management System
(IMS). All the vital business logic runs on CICS TS, as shown in Figure 2 on
page 12. This company can provide a rich web interface for customers to
transact business such as getting insurance quotes or paying premiums online.
We can have WebSphere manage the presentation logic giving the users rich
Web interface. Agents could use conventional terminals connected directly to
TXSeries and get access to a greater range of business transactions such as
listing their client portfolio.
TXSeries plugs into the middle tier and performs intelligent routing to either IMS
or CICS TS. For intelligent routing, TXSeries does the following things before
routing the request:
򐂰 Authenticates clients
򐂰 Caches data locally on a DB2 server to do data validation
򐂰 Routes to IMS or CICS TS based on client request
Key features of this deployment:
򐂰 Reduced resource consumption on the EIS as TXSeries takes over a number
of business operations.
򐂰 Intuitive and rich Web based interfaces are now available to users.
򐂰 Consolidated data from multiple EIS systems before presentation to users.
11
IMS
Web browsers
WebSphere+CTG
HTTP
TXSeries
SNA
CICS TS
CUC
DB2
DB2
HOD
TN3270
VCAM
Figure 2 An intelligent mid-tier gateway
A comprehensive mid-tier integration server
As organizations change and evolve either organically or through mergers and
acquisitions, the location of critical business data may become dispersed on a
number of heterogeneous EIS systems. TXSeries is an effective mid-tier
integration solution for consolidating, summarizing, and presenting essential
business information to parts of the organization. Information can be seamlessly
summarized in a single location avoiding the need to consolidate existing EIS
systems or duplicate essential business data across multiple systems.
Consider a large bank, “Bank A”, that decides to acquire two other banks, “Bank
B” and “Bank C”. “Bank A” has more than 3000 branches across the country.
Most of the critical business logic runs on CICS TS. It also provides rich Web
interface for its customers. “Bank B” also runs its core business on CICS TS but
supports only 3270 client-based terminals. “Bank C” has a total non-IBM
solution. Because of the acquisition, there is a a requirement to provide senior
management with consolidated data and information taken from all three existing
heterogeneous EIS.
12
Revealed! The Next Generation of Distributed CICS
The extensive integration capabilities of TXSeries makes it an ideal choice as a
mid-tier integration server. As shown in Figure 3, TXSeries integrates with CICS
TS on z/OS (“Bank A” and “Bank B”), MQSeries®, and a non-IBM solution (“Bank
C”) to fulfill all the requirements.
Bank A
CICS TS
Bank B
Websphere + CTG
Web browsers
CICS TS
3270 Terminals
Bank C
TXSeries
M
Q
S
e
r
i
e
s
Non-IBM
Solution
Clients
Figure 3 A comprehensive mid-tier integration server
Key features of this deployment:
򐂰 Essential business information taken from multiple EIS systems are
consolidated, summarized, and made available in one place.
򐂰 Rapid integration of heterogeneous EIS systems without the need to
consolidate these systems.
TXSeries as a transaction server
TXSeries for Multiplatforms provides the base level CICS programming
interfaces, enabling industry specific COBOL, C, C++, PL/I, and Java™
specialists to create simple solutions for transaction processing. It is the only
distributed OLTP that IBM designed to enable you to scale up to CICS
Transaction Server on the mainframe if your business requirements grow.
TXSeries supports screen-based interfaces and graphical user interfaces,
13
depending on the business requirement. You can access data from the
integrated CICS Structured File Server, from a local or remote Relational
Database Management System (RDMS) such as IBM DB2, or from a messaging
product such as MQSeries. With excellent enterprise integration support,
TXSeries is ideal for creating mainframe value-add or stand-alone distributed
transaction processing solutions. The three most common application server
deployment scenarios are as follows:
򐂰 An entry level, stand-alone transaction server
򐂰 Non-J2EE server in a mixed workload environment
򐂰 A distributed server with mainframe connectivity
An entry level, stand-alone transaction server
In this scenario, TXSeries acts as an entry level online transaction processing
system running applications written in Cobol, C, C++, PL/I, and Java. See
Figure 4 on page 15. All application data is stored locally in one of the supported
Relational Database Management Systems or the CICS Structured File Server.
Any CICS internal data required for operational integrity of the CICS system is
stored in the Structured File Server, DB2, or Oracle. TXSeries has full
responsibility for applications running on the system and is not dependent on any
other EIS for data or transactional work. TXSeries provides a wide range of
functions, tools, and facilities to help users and system administrators run their
applications and manage the environment.
This scenario has access to all the features of TXSeries including transactional
capabilities, authentication and authorization security, and data access. It is
ideally suited for small scale deployments such as a small finance company,
automobile dealers and container shipping companies.
As an example, consider a business solution for a small automobile dealer
operating a number of franchises in a city. Assume the dealer has one central
office and a number of car showrooms. Some of the requirements that TXSeries
can satisfy might include the following:
򐂰 Most users of the system are located in a limited number of locations and use
3270 based terminals.
򐂰 Any client orders are tracked and managed from the time the order is placed
to delivery of the car.
򐂰 An inventory of spare parts stored in the various workshops with the ability to
reorder parts from the car manufacturers.
The automotive dealer either writes their own applications or, more likely,
purchases a custom-built application based upon TXSeries and DB2.
14
Revealed! The Next Generation of Distributed CICS
Key features of this deployment:
򐂰 Cost effective and robust solution for deploying and running business
transactions.
򐂰 Ideal solution for customers who do not have CICS or large scale EIS
systems but require the transaction handling qualities of service offered by
CICS.
CUC
DB2
HOD
Oracle
TCP/IP
TXSeries
TN3270
CORBA
Figure 4 Entry-level, stand-alone transaction server
A non-J2EE server in a mixed workload environment
TXSeries provides support for a wide range of industry specific graphical or
screen-based terminal interfaces, allowing users to exploit the exceptional
transaction handling properties. Integrating TXSeries with WebSphere
Application Server using the CICS Transaction Gateway enables composite
applications with sophisticated feature-rich user interfaces to become the front
end of TXSeries applications. The CICS Transaction Gateway even connects
TXSeries to the latest WebSphere based Service Oriented Architecture (SOA)
products, such as WebSphere ESB, enabling TXSeries applications to become
endpoints in a SOA. This enables the TXSeries infrastructure, to be extended to
access new markets and new types of users. See Figure 5 on page 16.
Continuing our previous example of an automobile dealer. The company can
provide a Web interface for its customers to book a slot for servicing their car,
view bills online, or order spare parts. With minimum changes to the existing
applications, the dealer can extend to the Web by writing some presentation logic
running on WebSphere application server and connect to TXSeries via the CICS
Transaction Gateway. All existing employees and users can still continue to
access the system using terminal interfaces.
15
Key features of this deployment
򐂰 Access to TXSeries applications from a Java-based environment.
򐂰 Transactional integrity is propagated automatically by the CICS Transaction
Gateway from WebSphere Application Server to TXSeries. This ensures that
Web-based users receive the same, or better, qualities of service from
TXSeries as conventional terminal-based users.
򐂰 Business applications are written using a combination of J2EE and traditional
CICS programming languages.
Web browsers
WebSphere+CTG
HTTP
TXSeries
CUC
DB2
HOD
TN3270
Figure 5 Non-J2EE server in a mixed workload environment
A distributed server with mainframe connectivity
This scenario covers almost the complete spectrum as it utilizes the integration
of TXSeries with WebSphere Application Server, other members of the CICS
family, and other EIS systems. TXSeries can be used as full transactional system
running applications on behalf of conventional users and internet based users via
WebSphere Application Server. In either an online or batch capacity, TXSeries
can communicate with other CICS or EIS systems to synchronize data or invoke
mission critical functions only available on an EIS. See Figure 6 on page 17.
16
Revealed! The Next Generation of Distributed CICS
An example for this deployment is a very large retail organization that sells a
variety of goods through outlets and shops while also providing Internet-based
shopping. TXSeries can act as a server in each shop or outlet managing all local
transactions such as order processing, inventory management, and shop
specific data. All shop sales representatives use terminal-based interface to
interact with the system.
Each of these shop or outlets is connected to a single mainframe in the
headquarters. The EIS manages the entire business including tasks such as
corporate level data, corporate report generation, invoicing, and salary
processing. Any retail related data such as product pricing and promotional
information is synchronized between the shops and the EIS by overnight batch
updates.
Internet-based users connect via a Web-based interface directly to the main EIS,
but information is distributed to local shops allowing customers the option of
collecting their orders from a shop rather than waiting for delivery.
Branch Office
Headquarters
TXSeries
CICS TS
on zOS
VSAM
DB2
Figure 6 Distributed server with mainframe connectivity
17
Key features of this deployment
򐂰 There is full end-to-end integration between WebSphere Application Server,
CICS Transaction Gateway, CICS, other EIS systems, and TXSeries.
򐂰 Solutions can be simple or complex depending upon the needs of the
organization and the demands of the users.
򐂰 As the organization grows or changes the architecture can remain constant
while utilizing the flexibility of the CICS family to select the most appropriate
combination of products for the users’ needs.
18
Revealed! The Next Generation of Distributed CICS
Deployment, development, and administrative choices
TXSeries, being a true distributed transaction processor, allows both data and
functions to be distributed across heterogeneous systems. This allows you to
use TXSeries in a number of different architectures. To enable this flexibility,
TXSeries provides architects, developers, and administrators with a number of
choices.
This section describes some of the choices available to TXSeries customers in
the areas of deployment, development, and administration.
Deployment choices
This section discusses some of the choices and options available to architects of
a TXSeries based solution.
Choosing a VSAM file system
For VSAM data, Transient Data, and Temporary Storage queues, TXSeries can
either use the integrated CICS Structured File Server (SFS) provided with
TXSeries, or it can use a Relational Database Management System (RDBMS).
Currently DB2 and Oracle are supported databases for VSAM data. TXSeries
does support a wider range of RDBMS for conventional database data.
Once deployed, it is possible to change a TXSeries system from using the CICS
SFS for VSAM data to RDBMS and vice-versa. Clearly, this is not something you
should attempt on a regular basis, so the best option is to make a decision and
stick with it.
The following sections briefly summarize the advantages and disadvantages of
using the SFS for VSAM data compared to RDBMS.
Advantages of SFS
򐂰 Ships with TXSeries and does not require any additional licenses.
򐂰 Very easy to create the initial configuration and deploy VSAM files.
򐂰 Supports all File options (KSDS, ESDS, RRDS), TS and TD queues.
򐂰 Supports both recoverable and unrecoverable files.
Disadvantages of SFS
򐂰 Requires additional skills to manage and tune.
19
򐂰 Options for data backup and restoration to media outside of SFS control are
limited.
Advantages of RDBMS
򐂰 As it is widely used skills are easily available.
򐂰 Easy to backup and restore data.
Disadvantages of RDBMS
򐂰 DB2 or Oracle licenses have to be purchased separately from TXSeries.
򐂰 No concept of unrecoverable files.
Both SFS and RDBMS are capable of storing large volumes of data and both
allow batch programs to access the data.
Both options have their own advantages and disadvantages. Your choice
probably depends on a number of factors such as licences and availability of the
necessary skills within your organization.
Location of file system
Previous versions of TXSeries allowed the SFS server to reside on physically
separate machines to the CICS system. With version 6.0 of TXSeries, this option
of a remote SFS is no longer supported, it has to physically exist on the same
machine as the TXSeries server.
This does leave a number of options for physically locating CICS regions and
RDMS servers. Depending on the capacity of the server and the skill set
available in the organization, RDBMS can either run on the same machine as
TXSeries or remotely.
Choosing the type of Security
TXSeries provides the flexibility of choosing between CICS integrated security
features or user plugable external modules for authentication and authorization.
With TXSeries integrated security, each CICS region authenticates users and
incoming communication and authorizes access to the resources of that system.
All the authentication and authorization depends on the user definition in the
runtime database.
You can enhance or replace authorization services by using an external security
manager (ESM) that is called from CICS. Similarly, you can enhance or replace
authentication services by using an external authentication manager (EAM) that
is called from CICS. With EAM and ESM the possibilities for security
20
Revealed! The Next Generation of Distributed CICS
management and integration are greatly increased. Starting with TXSeries
Version 6, an EAM module is shipped that uses LDAP to integrate with RACF.
With RACF integration all the user authentication and authorization can be
centralized on an EIS.
Your choice of integrated security or external modules depends on a number of
factors including the need to centralize user authentication and authorization.
Choosing the network protocol for intersystem communication (ISC)
TXSeries supports intersystem communication between a local TXSeries region
and the following:
Other TXSeries regions, CICS for MVS/ESA™, CICS/MVS®, CICS/VSE®, CICS
OS/2™, and CICS/400® regions.
TXSeries can communicate with remote systems using either TCP/IP or SNA
protocol. ISC over TCP/IP or SNA can be used between two TXSeries regions.
As ISC over TCP/IP is not supported by Mainframe, ISC over SNA is the only
option when communicating with Mainframe regions. Synchronization levels 1
and 2 are available on both TCP/IP and SNA.
Synchronization level 2 across an SNA connection requires a separately
purchased communications product such as IBM Communications Server to be
installed on the same machine as TXSeries.
Your final choice of protocol for ISC depends on factors such as the need to
access remote systems, existing networks, and required synchronization levels.
Choosing an operating system for deployment
TXSeries is supported on UNIX® style systems (AIX, Solaris and HP-UX) and
Microsoft Windows. As with all production systems, the final choice on which
operating system to run TXSeries depends on a number of factors that include
the following:
򐂰 Number of physical machines required for functions such as production
usage, testing, backup, and development.
򐂰 Number of physical locations, such as separate data centres for locating
machines.
򐂰 Ability to consolidate separate machines into a smaller number of large
machines.
򐂰 Operating system features such as security and backup required by the
administrators and users.
21
򐂰 Availability of third-party software required by the organization.
򐂰 Number and type of systems already deployed within the organization.
Due to the prevalence of existing machines, the choice of an operating system
may be straight forward for some organizations. For others it may be more
difficult.
Development choices
When designing and developing a TXSeries based CICS application, developers
have a large number of choices over how a CICS application behaves. In many
cases, poor performance and behavior in CICS can usually be traced back to an
inappropriate design decision at development time. This section offers some of
the choices and options available to developers of a TXSeries based solution.
In general the choices offered here are not exclusive to TXSeries. They apply to
all CICS based applications regardless of the CICS product at which the
application is targeted.
Separation of logic
An important principle of business application design is to separate the
application logic into components. For example, a broad level of separation could
be presentation logic, business logic, data handling, communications, error
handling, and so forth. with good componentization you can enhance and
change a business application quickly and easily. Componentization also helps
in reuse of business logic. By reusing well designed business logic an application
can be opened up to different client channels with minimum effort and no rework
of the existing server components.
The CICS API provides a number of facilities to simplify the separation of
application logic into components, for example, the COMMAREAS and the LINK
and XCTL commands.
Error handling
Error handling within an application is very important. Categorize errors into the
following, and decide in advance how to handle each type of error:
򐂰 Conditions that are not normal from TXSeries point-of-view but are
anticipated in program.
򐂰 Conditions caused by user and input data errors.
򐂰 Conditions caused by omissions or errors in application code.
22
Revealed! The Next Generation of Distributed CICS
򐂰 Errors caused by mismatches between applications and TXSeries resources,
for example, when a file is not found.
򐂰 Errors relating to hardware or other system conditions beyond application
program control.
Common data structure
It is a good idea to store common structures in a shared library so that multiple
programs can access the structure. It also eases program maintenance and
management.
Testing
Testing is a very important phase of the application development cycle. We
always recommend doing rigorous stress testing with good code coverage
before deploying the applications to production systems.
Data choices
When recoverable resources, such as files and queues, are updated, additional
logging is required, which incurs additional I/O and processor overhead.
Resources defined as unrecoverable incur less logging. Because of this, define
resources as recoverable only if they really need to be.
Short LUW
It is important to keep ACID transactions as small as possible in terms of time.
Longer transactions mean longer Logical Units of Work that increase the
duration of locks on recoverable resources. Locks can be for Storage, Updated
data, and so on. A good example for a long LUW is a conversational program,
where the LUW extends for the duration of the conversation; hence, all data is
locked for the duration of the conversation.
The longer locks are held, the greater the possibility of another transaction
wanting access to the same resource, which leads to a wait situation. Therefore
it is important to keep LUWs as short as possible.
Update close to sync point
A sync point in a CICS transaction is the point at which updated resources are
committed. After this point, the changes to the data cannot be undone or
rolled-back. Once a resource is updated, the data is locked to prevent access by
other transactions. Updating the resource as close as possible to the sync point
23
in terms of time minimizes the possibility of locks affecting other users and
transactions in the system.
Use pseudo-conversation programs
Programs that interact with a terminal based user are known as conversational.
Any resources updated early in the conversation will require locks to be in place
whilst the program solicits input from a user. If a user takes time to respond, or
even fails to respond, data previously updated will remain locked, possibly for
extended periods of time.
To avoid this problem of locking data while waiting for user input, programs
should use a technique called pseudo-conversational programming. At the end
of every conversation with the user, the program terminates, updates any data
and releases data locks. The key here is that the program ends rather than
waiting for user input. Once the user inputs more data, the program restarts and
continues processing.
Data conversion
TXSeries is an ASCII based system, while CICS Transaction Server is an
EBCDIC based system. This means data manipulated by both types of CICS
system could require data conversion as it is moved between systems. Though
not difficult to set up it is an extra overhead and one which must be considered
by application developers.
Choosing an operating system for development
Since TXSeries is supported on UNIX style systems (AIX, Solaris and HP-UX)
and Microsoft Windows, there are two main choices when it comes to deciding
on a development environment. There are a number of factors to consider when
choosing an operating system for development. Following is a list of some of
those considerations:
򐂰 Number of physical machines required.
򐂰 Operating system features such as security and backup required by the
administrators and users.
򐂰 Availability of third-party software required by the organization.
򐂰 Number and type of systems already deployed within the organization.
򐂰 Whether or not developers require access to individual CICS systems for their
own testing, or whether they can share systems?
24
Revealed! The Next Generation of Distributed CICS
Due to the prevalence of existing machines, the choice of operating system may
be straight forward for some organizations. For others it may be more difficult.
Administration choices
TXSeries provides system administrators a number of facilities for controlling and
managing a TXSeries environment. Unlike the previous two sections, where a
decision can have serious effects on the overall behavior and performance of the
system, administration choices describe a number of facilities and functions
available within TXSeries for helping to administer the system. These facilities
can be enabled or disabled as and when they are required, for example to help
diagnose a problem or provide some additional reporting.
User exits
TXSeries provides a very powerful customization option called user exits. A user
exit (also referred to as a user exit point) is the point in a CICS program at which
CICS can transfer control to a program you wrote (a user exit program), and can
then resume control when your program completes its work. There are a number
of points in CICS where a user program can be hooked, for example: Task
termination, Syncpoint, and so on. By effectively using user exits one can extend
the functionality of TXSeries.
Transaction Classes (T-Class)
You can control the number and priority of transactions running in a region at any
one time by using transaction classes. Every transaction is given a T-Class
number in the range of 0 to 10. Administrators can then define the number of
transactions in a particular class allowed to execute concurrently. Using T-Class
is an effective way of making sure high priority transactions take precedence
over lower priority ones.
Number of application servers
TXSeries uses application server processes to execute transactions.
Administrators can control the minimum and maximum number of application
servers available in a CICS region to process transactions and hence control the
number of concurrent transactions CICS is able to run.
The minimum and maximum numbers should be carefully tuned. If too small,
processing time can be wasted because there is not enough work in the system
for disk read/write operations to be overlapped with other transactions. If this is
25
too large, the system can spend more time managing the servers and their
memory than running the transactions.
Monitoring and statistics
CICS provides statistics and monitoring tools that you can use to gain
information about the running of a CICS system. Data provided by these tools
can be used to provide information about any resource contention or other
problems that can affect the performance of your CICS system. You can tailor
these tools to provide information at certain event points or at certain time
intervals in the running of the CICS system. You can also tailor them to specify
the types of data on which CICS is to provide the information.
Dump and trace
TXSeries provides a lot of problem determination tools including dump and trace
utilities. There are the following two kinds of dumps: transaction dump and
system dump. A transaction dump writes specified areas of memory to a file to
assist you in debugging an application program or to identify why an abnormal
termination or storage violation occurred. System dump gives a snapshot of the
entire CICS region with a lot of details at the time of dump. This is very useful is
analyzing a system wide problem.
Tracing can assist both application developers and system administrators, and it
is often crucial when asking for product support. TXSeries divides trace data into
two broad categories, application trace and system trace. Application trace refers
to trace data generated from application-specific code, which programmers use
to debug applications. System trace refers to traces generated from the CICS
product itself, which system administrators and product-support staff use to
analyze and diagnose system-wide problems.
26
Revealed! The Next Generation of Distributed CICS
Mainframe transaction processing monitors versus
distributed transaction processing monitors
It is generally fairly well understood that distributed transaction processing
monitors (TPMs) are usually less expensive for smaller workloads and that
mainframe TPMs provide better price performance as the workload increases.
Also, it is generally accepted that TPMs on the mainframe platform provide
significantly better Qualities-of-Service than do their counterparts on distributed
platforms; however, some application requirements do not require the
best-of-the-best qualities that the mainframe offers, so they can be satisfied by a
distributed TPM. Consider the following example of a company with a
branch/office configuration that does not require a mainframe in each of their 100
branches to do local processing; however, the same company may likely have
one or more mainframes in their head office that connect to these satellite
servers. So, although different business and technical requirements exist, it is
important to have an understanding of what both mainframe and distributed
TPMs can offer.
Due to the nature of hardware and operating systems, there are many
differences between mainframe transaction processing monitors (TPMs), such
as CICS Transaction Server for z/OS, and distributed transaction processing
monitors (DPMs), such as TXSeries. Comparing two transaction processing
products, one from the mainframe and one from a distributed environment, at a
functional level is relatively straightforward. At a high-level, the API for TXSeries
Version 6.0 is somewhere in between CICS MVS/ESA V4.1 and CICS
Transaction Server for OS/390® V1.3—or about the same as CICS Transaction
Server for VSE V1.1. Product documentation is usually available and generally
provides the necessary information and so a feature/function comparison is not
the focus of this section.
The intention of this section of the Redpaper is to give you an impression for
some of the differences in the wider business, technical, application
development, and skills enablement perspectives. This section is not intended to
be an exclusive or exhaustive comparison of the two TPM paradigms; however, it
can serve as a useful starting point for those making comparative assessments
or evaluations.
Business considerations
The following is a number of comparisons between mainframe and distributed
transaction processing systems from an organizations’ business perspective.
27
Enterprise security requirements
Security integrity and integration with the rest of the organization (and beyond) is
critical to most businesses. Mainframe security has a long and well established
track record, often being described as ‘unbreakable’. In the mainframe
environment, security management and integration is engineered into every part
of the hardware architecture, operating system, networking capabilities, data,
and application management software—right through to user identity
management and privacy of information.
Distributed systems have evolved differently with more of a focus on flexibility
and speed to market. The hardware, operating environments, and runtime
software are very often developed and marketed by different vendors. Providing
mainframe level of security management and integration in distributed systems
can be extremely difficult or even impossible.
Engineering security across a highly-distributed, heterogeneous, and loosely
coupled environment can be a high-risk strategy. As the distributed environment
grows, complexity is added, and thus the risk of security breaches and the risk of
duplicating data increases.
Scalability and workload management requirements
As organizations grow, the demands on their transaction processing
environment also increases. Scalability is the ability to scale the system to meet
these increased demands. Mainframe systems can readily scale vertically (within
the machine) and horizontally (across machines). Distributed transaction
processing systems can traditionally scale vertically with few problems; however,
they frequently lack similar horizontal scaling capabilities to dispatch
transactional requests from clients, with affinity between two or more machines.
With increased scalability comes increased workload management
requirements. Mainframe systems are capable of effectively managing complex
and high-volume workloads of hundreds of millions of transactions per day.
While processor speeds of distributed systems can execute instructions very fast
within the same machine, comparable workload management facilities from
distributed solutions are either present, but a lower level of functionality, or not
available at all.
In order to achieve a similar level of functionality to a mainframe system requires
several distributed systems coupled together to give the appearance of a
harmonized environment. This increases not only the complexity but the cost of
people to manage the environment and the likelihood of networking outages.
Distributed environments excel where the requirement for administration and
workload management is lower.
28
Revealed! The Next Generation of Distributed CICS
Core and supplementary functional requirements
Both the mainframe and distributed platforms offer a choice of transaction
processing monitors that all deliver the core managed transactional attributes of
atomicity, consistency, isolation, and durability. More advanced capabilities
depend upon the maturity and quality of the software combined with the
capabilities of the underlying hardware and operating environment.
Technical considerations
The following is a number of comparisons between mainframe and distributed
transaction processing systems from a technical perspective.
Administrative and workload management requirements
Mainframe systems are capable of effectively managing complex and high
volume workloads. Comparable facilities from distributed solutions are now
exhibiting similar behaviors, but often present a lower level of functionality.
Hence, in order to achieve the same functionality of a mainframe system requires
several, if not many, distributed systems coupled together to give the
appearance of a harmonized environment. This increases complexity.
Core and supplementary functional requirements
Both the mainframe and distributed platforms offer a choice of transaction
processing monitors that all deliver the core managed transactional attributes of
atomicity, consistency, isolation, and durability. More advanced capabilities
depend upon the maturity and quality of the software, combined with the
capabilities of the underlying hardware and operating environment.
Due to the differences between hardware and operating environments,
distributed offerings only provide a subset of the Application and System
Programming Interfaces offered by mainframe transaction processing systems.
Unsupported capability can sometimes be written manually in distributed
environments.
The mainframe has consistently innovated for over forty years, and distributed
platforms cannot match the combinations of hardware resilience, functionality,
and near zero downtime. There is also a comprehensive range of supporting
software offerings designed around mainframe based mission critical transaction
processing monitors. This is largely absent from the distributed transaction
processing market.
29
Total cost of ownership
In general, economies of scale in mainframe transaction processing provide that
the price and performance per transaction significantly improves as the quantity
of workload being managed increases. This is especially true of IBM z/OS
systems over 150 MIPS. Distributed transaction processing systems are
generally less expensive in terms of entry costs, but as they grow, expansion and
people management costs grow in parallel.
For new deployments that have entry level transaction processing requirements,
distributed transaction processing monitors provide an ideal option. The IBM
TXSeries is uniquely designed to prove a base CICS API that enables skills and
applications to be reused in a mainframe CICS Transaction Server for z/OS
environment should the business requirement to grow arise.
For existing mainframe customers, a re-platforming exercise to a distributed
transaction processing monitor is not generally a cost effective approach. Unless
the mainframe capacity is very small and the applications were written to use
only the base CICS API, re-platforming exercises are too costly and risky to be of
value. Savings are more likely to be achieved by exploring options such as
server consolidation, Sysplex Aggregation, Sub Capacity Pricing, Speciality
engines, or other such techniques for improving cost. These options enable a
solution that does not significantly increase risk or significantly reduce the
qualities of service.
Technical considerations
The following is a number of comparisons between mainframe and distributed
transaction processing systems from an technical perspective.
Operational requirements
Mainframe hardware sets the reference standard when it comes to tasks such as
administration, systems management, monitoring, security integration, high
availability and supporting software. The hardware and operating system is
designed for high availability, failover, and workload management. With
mainframe transaction processing software, there is a whole industry of available
software to help support, manage, and control the environment.
A distributed transaction processing environment provides a sub-set of the
operational facilities available on a mainframe system. As a general rule, some of
the more fundamental capabilities may be built into the operating system. Others
are procured via additional software. Some can be developed specifically for
particular applications, and others are simply not reproducible on a
30
Revealed! The Next Generation of Distributed CICS
non-mainframe platform. Most operational requirements always struggle to
match the facilities offered by the mainframe in a number of key areas.
Presentation management features
Mainframe transaction processing has defined the reference for Basic Mapping
Support (BMS) including associated presentation APIs. Distributed transaction
processing systems generally only support “minimum” or possibly parts of
“standard” BMS. “Full” BMS is rarely available because of the limitations of 3270
terminal emulators used in a distributed environment.
Many existing terminal and printer devices are mainframe oriented. New devices
use the existing mainframe paradigm. Distributed systems do support printers
and terminals, but their operation, support, and behavior is different. Additional
software is sometimes available to support these devices; however, mapping
between mainframe supported devices and distributed devices can be difficult
due to hardware dependencies.
Data services features
Mainframe Operating Systems provide the real VSAM file system. Distributed
transaction processing systems use various emulation strategies when
compared to real VSAM. This means the basic facilities of Key, Entry, and
Relative Sequenced VSAM files are available through emulation, but the
performance and functionality of these systems is often lacking when compared
to VSAM.
Mainframe transaction processing systems frequently use techniques for splitting
application behavior between different CICS regions. For example, one region
handles only terminals (known as the terminal owning region), while another
handles only application code (known as the application owning region). CICS
intersystem communication is then used between the two regions. Such setups
are more difficult to achieve with distributed environments, where network
communications and affinity between different regions becomes an issue.
Hardware and software infrastructure support
Mainframe product is perceived as late to TCP/IP but makes up for it in other
areas and benefits from cross-IBM SNA simplification efforts. Though other
implementations support TCP/IP they were never used with real volumes until
very recently. SNA remains the best option for server interactions and TCP/IP for
clients.
31
Synchronization Level (SL) is the ability to coordinate the updates to multiple
resources across a network. SNA on the mainframe supports SL0 (lowest), 1,
and 2 (highest). In distributed environments full SL2 support can only be
achieved with additional communications software.
When it comes to JCL scripting and batch processing, Mainframe defines the
standard. Distributed environments either rely on the Operating System or
emulation software to provide similar facilities.
System monitoring and management
This area is one of the key strengths of the mainframe that provides a lot of very
powerful system management utilities. CICSPlex® System Manager is fully
integrated with CICS Transaction Server. Its role is to reduce the complexity of
operating multiple CICS regions by providing access to all major CICS
management functions such as resource definition, operation, monitoring, real
time analysis, workload management, as well as services at the business
application level, through an easy to use Web User Interface (WUI). Access is
provided from a single point of control where resources are manipulated
irrespective of their physical location. A comprehensive API is also provided to
enable automation and scripting of system management tasks. It also
cooperates with the Tivoli® suite of products to meet the needs of end-to-end
application management and automation of the CICS workload on z/OS.
In addition to CICSPlex Manager, which is provided with CICS Transaction
Server for z/OS, there is a wide range of Systems monitoring and management
tooling offered by IBM and by third party vendors for mainframe based
transaction processing monitors. For example, IBM Tivoli OMEGAMON® for
CICS is designed to help you proactively manage your CICS systems. With a
flexible easy-to-use browser interface, IBM Tivoli OMEGAMON XE for CICS
helps you clearly see and understand application and system events. You can
monitor and manage CICS transactions at the big picture and granular levels, as
well as interaction with other applications, within a single interface. IBM Tivoli
OMEGAMON XE for CICS is designed to enable you to detect problems quickly
and take action in real time to speed problem resolution.
Distributed implementations have very basic and minimum tools for system
management of distributed transaction processing systems, which cannot be
compared with Mainframe.
High availability, failover, and disaster recovery
The mainframe architecture, from the hardware, the operating environment and
the software that runs on them, is designed for high availability, failover, and
disaster recovery. Its leadership in delivering world-class application availability
32
Revealed! The Next Generation of Distributed CICS
and overall business resiliency is 40 years in the making. With the IBM Parallel
Sysplex® technology, you can harness the power of up to 32 z/OS systems, yet
make these systems behave like a single, logical computing facility. What's
more, the underlying structure of the Parallel Sysplex remains virtually
transparent to users, networks, applications, and even operations.
An extension to Sysplex is the Geographically Dispersed Parallel Sysplex™
(GDPS®). It is a multi-site or single-site end-to-end application availability
solution that provides the capability to manage remote copy configuration and
storage subsystems (including IBM TotalStorage® Enterprise Storage Server®)
to automate Parallel Sysplex operation tasks and perform failure recovery from a
single point of control. GDPS helps automate recovery procedures for planned
and unplanned outages to provide near-continuous availability and disaster
recovery capability. In addition to Sysplex and GDPS there are other features,
such as dynamic disk-swapping capabilities that keep applications and data
available and makes system failures invisible.
Distributed systems rely on operating systems and other software solutions for
high availability, failover, and disaster recovery. In some of the latest distributed
UNIX systems, some high availability features were introduced in order to
monitor the entire system and to automatically restart an application on
designated backup hardware in the event of failure or service degradation. Some
high availability features must be implemented in every part of the software stack
to work in practice. For smaller application workloads, with more flexible service
level agreements, the availability levels of distributed platforms are acceptable;
however, they cannot match the facilities and services offered by the mainframe.
Workload management
Mainframe product stack is well integrated into system-provided workload
management and has plenty of documentation and tooling. One of the strengths
of mainframe hardware and operating systems is the ability to run multiple
workloads at the same time within one machine or across multiple machines.
The function that makes this possible is dynamic workload management, which
is usually implemented in the Workload Manager component of the operating
system. With Workload Manager, you define performance goals and assign a
business importance to each goal. You define the goals for work in business
terms, and the system decides how much resource, such as CPU and storage,
should be given to it to meet the goal. Workload Manager constantly monitors the
system and adapts processing to meet the goals.
Distributed systems rely on operating system and other software solutions for
workload management. In the UNIX based environment, a number of solutions
can be engineered to enhance the workload management capabilities of small
clusters of similar servers. There are fewer workload management facilities
33
available for Windows-based systems. Generally, any workload management
technology needs to be supported by the core software components that are
driving the workload that need managing, and there is not yet a universally
adopted workload management solution that works across all distributed servers.
In most cases, the workload management capabilities of distributed systems are
sufficient for entry-level workloads, but they cannot match the facilities and
services offered by the mainframe.
Problem determination
Mainframe products generally provide a wide variety of problem determination
tools such as monitoring, journaling, tracing, dumps, and user exits that are
available to administrators when problems occur. To further help the users,
operating system and additional software facilities are also available to help
users pin point the exact cause of a problem.
With distributed transaction processing systems, IBM debuggers enable users to
locate and understand errors in their applications running on various platforms.
Other debugging tools are available from third party application development
vendors, primarily for their own AD implementations. In general, distributed
debugging facilities are available to some extent but can be less sophisticated
then some of the more mature and established mainframe problem
determination tooling that is available from a variety of vendors.
Development requirements
The following is a number of comparisons between mainframe and distributed
transaction processing systems from a development perspective.
Programming features
Mainframe transaction processing defined the reference for the CICS Application
and System Programming Interfaces (API and SPI). Distributed transaction
processing systems only implement a subset of the full CICS interfaces.
Mainframe transaction processing has the broadest range of integration options,
such as greater than 32K inter-program data passing, Web support, and Web
services. Distributed transaction processing monitors like TXSeries provide a
subset of CICS capabilities that are upwardly compatible with CICS Transaction
Server on the mainframe. Other third-party implementations provide a
proprietary solution, with no upgrade path that lacks core facilities or relies on
third-party products for the support.
34
Revealed! The Next Generation of Distributed CICS
CICS Transaction Server for z/OS provides extensive Java support including
Enterprise Java Beans (EJBs) and the CICS API accessible from Java (JCICS).
Distributed transaction processing systems only implement a subset of the full
Java interfaces that CICS offers.
Product connectivity and integration features
Mainframe provides ultimate internal (using cross memory calls) and external
(via External Call Interface) integration scalability with other systems and
environments. Other implementation provide platform specific internal integration
and some basic external integration facilities.
Mainframe transaction processing has a lot of future integration options such as
more than 32kb data passing, web support, and web services. Distributed
systems often lack the facilities or rely on third-party products for the support.
Skills enablement
Mainframe products come with comprehensive product documentation sets. A
great deal of practical assistance is also available through channels such as
Redbooks™, user groups, white papers, and support organizations.
When it comes to education and access to skilled people, there are plenty of
options and alternatives available to an organization.
With distributed transaction proceeding monitors, the support ecosystem and
education infrastructure is less well developed and not as readily available as the
mainframe skills enablement materials
35
Summary
From the comparison we presented it is clear that the mainframe is a superior
product from both a business and a technical perspective. It has a number of
unparalleled features that make it an ideal choice for large scale enterprise
deployment. CICS Transaction Server for z/OS, for example, has evolved over
the last 35 years to become the worlds leading transaction processing monitor–
processing tens of billions of transactions with a value of over a trillion US dollars
every day. For companies that cannot afford to compromise on their
high volume, mission-critical applications, CICS Transaction Server for z/OS is
the only answer.
Although distributed transaction processing solutions are not able to match the
mainframe levels of quality and service for high-volume transaction processing,
they are the perfect solution for smaller scale business critical deployments, or
for applications that can tolerate lower service level agreements. One of the
largest advantages of TXSeries for Multiplatforms is that it can be deployed as
an entry-level CICS system in circumstances where the requirements for growth
may mandate moving an application to a mainframe based system in the future.
In general, distributed transaction processing monitors provide a subset of the
mainframe features and benefits with a subset of their qualities of service but at a
subset of the price. Note that at a certain point, the improved price, performance,
and quality of a mainframe makes it a more cost-effective solution for
high-volume workload requirements than a number of connected distributed
servers.
36
Revealed! The Next Generation of Distributed CICS
Conclusion
TXSeries for Multiplatforms is part of the industry leading CICS family of products
by IBM. It is production proven for over a decade in providing a powerful online
transaction processing environment for the distributed platform. With the release
of TXSeries for Multiplatforms, Version 6, IBM offers the next-generation of
distributed IBM CICS transaction servers. This version delivers the base CICS
functionality of previous versions of distributed CICS transaction servers, but
without the distributed computing environment (DCE) or IBM Encina
prerequisites. This provides a vastly simplified environment where the
installation, configuration, and administration are simplified, enabling increased
system programmer and administrator productivity.
TXSeries software is designed to help you deploy application and integration
programs that are written in enterprise programming languages like COBOL, C,
C++, PL/I, and Java. By providing services that interact with the underlying
hardware and software, TXSeries hides the complexity of your IT systems
without compromising their functionality—enabling enterprise developers to
concentrate on solving tangible business problems with innovative technical
solutions. It delivers a transactional online and batch processing environment
that supports critical applications written in enterprise programming languages.
The online transaction processing (OLTP) environment supports the base-level
CICS application programming interface (API). The integrated CICS structured
file server (SFS) delivers a record-orientation file system.
TXSeries for Multiplatforms is ideally suited to deployment in two common
scenarios. Due to its extensive support for many enterprise information systems
(EIS)—such as CICS Transaction Server, IMS, DB2, WebSphere MQ, and
WebSphere Application Server—TXSeries is very commonly used as a rapid
deployment transactional integration server. Also, due to its wide range of
support for enterprise programming languages and data access services,
combined with TXSeries ability to scale up to CICS Transaction Server on z/OS,
it is commonly used as an entry-level transaction server.
When comparing distributed transaction processing solutions to mainframe
transaction processing solutions, mainframes remain the undisputed leader in
terms of both quality of service and functional capability. Distributed transaction
processors, however, are the perfect solution for smaller scale business-critical
deployments or for highly-distributed applications where the lower service level
agreements that come with the more open, decentralized environment are
acceptable.
One of the largest advantages of TXSeries for Multiplatforms is that customers
have a platform for the future. TXSeries provides interoperation with the latest
IBM WebSphere and mainframe technologies. It also has the ability to scale up
37
to the worlds leading mainframe transaction processing solution, CICS
Transaction Server for z/OS, if required.
38
Revealed! The Next Generation of Distributed CICS
The team that wrote this Redpaper
This Redpaper was produced by a team of specialists from around the world
working at the International Technical Support Organization, Poughkeepsie
Center.
Chris Rayns is the CICS/Security Project Leader at Poughkeepsie and writes
extensively on all areas of z/OS security. He is an IT Specialist at the
International Technical Support Organization, Poughkeepsie Center. Before
joining the ITSO, Chris worked in IBM Global Services in the UK as a CICS IT
Specialist in Poughkeepsie.
Madhu B Ananthapadmanabh is a TXSeries Developer in India. He has over
four years of experience in TXSeries. He holds a degree in Electrical and
Electronics from Bangalore University. His areas of expertise also include
Distributed computing.
Iain Boyle is a Senior IT Specialist working for Software Group Services in IBM
Hursley, UK. He has 17 years of experience in the software industry. For the last
7 years, he worked as a client-focused consultant specializing in WebSphere
Application Server, TXSeries, and CICS Connectors. He holds a degree in
Computer Science from the University of Manchester and an MBA from the
University of Southampton.
Andrew Bates is the Product Line Manager for TXSeries and CICS Transaction
Gateway. He is responsible for delivering on-going versions and releases of
these products that continue to meet the growing needs of IBM clients. He has
worked in the CICS organization since the start of his IBM career in 1999. He
graduated with a Business degree from the University of Plymouth BUsiness
School in the United Kingdom.
Thanks to the following people for their contributions to this project:
Innes Read
International Technical Support Organization, Poughkeepsie Center
Dept. HYJ; HYJ Mail Station P099, 2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A.
39
40
Revealed! The Next Generation of Distributed CICS
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
© Copyright IBM Corp. 2006. All rights reserved.
41
Send us your comments in one of the following ways:
򐂰 Use the online Contact us review redbook form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
redbook@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYJ; HYJ Mail Station P099, 2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A.
®
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX®
CICS OS/2™
CICS/MVS®
CICS/VSE®
CICS/400®
CICS®
CICSPlex®
DB2®
Encina®
Enterprise Storage Server®
Eserver®
Eserver®
GDPS®
Geographically Dispersed
IBM®
Informix®
IMS™
Intel®
MQSeries®
MVS/ESA™
OMEGAMON®
OS/2®
OS/390®
Parallel Sysplex®
Pentium®
Redbooks™
Redbooks (logo)
RACF®
System z9™
Tivoli®
TotalStorage®
TXSeries®
WebSphere®
z/OS®
zSeries®
z9™
™
The following terms are trademarks of other companies:
Java, J2EE, Solaris, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United
States, other countries, or both.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, or service names may be trademarks or service marks of others.
42
Revealed! The Next Generation of Distributed CICS