Concepts and Facilities

WebSphere Application Server Enterprise Edition
TXSeries IBM
Concepts and Facilities
Version 3.0
SC09-4455-00
TXSeries IBM
Concepts and Facilities
Version 3.0
SC09-4455-00
Note
Before using this information and the product it supports, be sure to read the general information under
“Notices” on page 199.
First Edition (June 1999)

This edition applies to:
VisualAge Component Development for WebSphere Application Server Version 3.0, Enterprise Edition for AIX,
program number 5765–E27
VisualAge Component Development for WebSphere Application Server Version 3.0, Enterprise Edition for
Windows NT, program number 5639–I07
WebSphere Application Server Version 3.0, Enterprise Edition for AIX, program number 5765–E28
WebSphere Application Server Version 3.0, Enterprise Edition for Solaris, program number 5765–E29
WebSphere Application Server Version 3.0, Enterprise Edition for Windows NT, program number 5639–I09
WebSphere Application Server Version 3.0, Enterprise Edition Development Runtime for Windows NT, program
number 5639–I11
WebSphere Application Server Version 3.0, Enterprise Edition Development Runtime for AIX, program number
5765–E31
WebSphere Application Server Version 3.0, Enterprise Edition Development Runtime for Solaris, program number
5765–E30
and to all subsequent versions, releases, and modifications until otherwise indicated in new editions. Consult the
latest edition of the applicable system bibliography for current information on these products.
Order publications through your IBM representative or through the IBM branch office serving your locality.
© Copyright International Business Machines Corporation 1999. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Figures . . . . . . . . . . . . . vii Data management . . . . . . . . 45
Communications . . . . . . . . . 46
Tables . . . . . . . . . . . . . ix Security . . . . . . . . . . . . 48
Application development . . . . . . 49
About this book . . . . . . . . . . xi Systems management . . . . . . . 49
Who should read this book . . . . . . xi
Document organization . . . . . . . xi Part 2. More about TXSeries
Conventions used in this book . . . . . xii facilities . . . . . . . . . . . . 51
How to send your comments. . . . . . xiv
Chapter 4. Transaction processing . . . 53
Part 1. Introducing TXSeries . . . 1 What is a CICS region?. . . . . . . . 53
When a CICS region is stopped . . . . 54
Chapter 1. IBM WebSphere . . . . . . 3 When a CICS region is running . . . . 55
WebSphere Application Server family . . . 3 The life cycle of a CICS region . . . . . 59
WebSphere Application Server Enterprise Recovery during restart . . . . . . 60
Edition . . . . . . . . . . . . . 4 General transaction processing services 61
Products for use with Enterprise Task management . . . . . . . . 62
Application Server . . . . . . . . . 5 Performance optimization . . . . . . 62
IBM DB2 Universal Database. . . . . 5 Workload distribution . . . . . . . 63
MQSeries . . . . . . . . . . . 6 Program management . . . . . . . 63
VisualAge . . . . . . . . . . . 6 System resource management . . . . 63
Tivoli management servers . . . . . 7 Controlling access to and updating data 63
Data communication . . . . . . . 64
Chapter 2. Online transaction processing 9 Terminal management . . . . . . . 64
Transactions . . . . . . . . . . . 9 Time management . . . . . . . . 64
Transaction processing monitors. . . . . 11 Security management . . . . . . . 64
The transaction life cycle . . . . . . . 12 Recovery management . . . . . . . 65
Distributed transaction processing . . . . 14
A sample transaction processing Chapter 5. Data management . . . . . 67
environment . . . . . . . . . . . 18 An introduction to data management . . . 67
The sample application. . . . . . . 18 Types of data . . . . . . . . . . . 68
The sample system environment . . . 19 Files . . . . . . . . . . . . . . 69
The transaction processing flow . . . . 20 File organization . . . . . . . . . 70
Primary and alternate indexes . . . . 72
Chapter 3. Overview of IBM TXSeries 23 Adding files to an SFS server. . . . . 72
What is TXSeries? . . . . . . . . . 23 Queues . . . . . . . . . . . . . 73
The TXSeries components and CICS queues . . . . . . . . . . 74
architecture . . . . . . . . . . 23 Encina queues. . . . . . . . . . 80
TXSeries environments . . . . . . . . 40 Relational databases. . . . . . . . . 82
CICS transaction processing environment 40 SQL restrictions for non-XA-enabled
Encina Monitor transaction processing relational databases . . . . . . . . 84
environment . . . . . . . . . . 42 Using DB2 to manage CICS files and
TXSeries facilities . . . . . . . . . 44 queues . . . . . . . . . . . . 84
Transaction processing . . . . . . . 44 Journals . . . . . . . . . . . . . 85
© Copyright IBM Corp. 1999 iii

CICS journal records . . . . . . . 85 Using an External Security Manager for
Synchronizing journal output . . . . 85 CICS security . . . . . . . . . . 127
Considerations for sharing and distributing Authorizing access to resources . . . . . 128
data . . . . . . . . . . . . . . 86 CICS authorization security . . . . . 128
CICS local and remote data . . . . . 86 Security considerations for IBM CICS
Data integrity . . . . . . . . . . 86 Clients . . . . . . . . . . . . . 130
Recovery . . . . . . . . . . . 87 Web security services . . . . . . . 130
Security considerations for CICS Telnet
Chapter 6. Communications . . . . . 89 clients . . . . . . . . . . . . . 131
Communicating with users . . . . . . 91 Security considerations between CICS and
CICS client interfaces . . . . . . . 92 XA-enabled databases . . . . . . . . 132
Client communications with Ensuring secure communications . . . . 132
mainframe-based CICS . . . . . . . 93 Authenticating the remote system that
Communicating with IBM CICS Clients 93 sent the request . . . . . . . . . 132
Accessing CICS from the Internet . . . 95 Authenticating the user that initiated the
Communicating with CICS DCE-enabled request . . . . . . . . . . . . 133
clients . . . . . . . . . . . . 97 Authorizing access to resources . . . . 135
Communicating with CICS Telnet clients 98
Communicating with CICS local Chapter 8. Application development. . . 137
terminals . . . . . . . . . . . 98 Designing transaction processing
Communication using DCE RPCs . . . . 98 applications . . . . . . . . . . . 137
Locating servers for communication . . . 98 CICS application programming . . . . . 139
Using the DCE CDS in a DCE cell . . . 99 IBM CICS Clients programming. . . . 139
Network protocols . . . . . . . . . 101 CICS region application programming 143
SNA synchronization levels . . . . . 102 The CICS IIOP ORB . . . . . . . . 144
Communicating across TCP/IP Encina application programming . . . . 144
connections . . . . . . . . . . 102 The Encina Monitor Application
Communicating across SNA connections 105 Development Environment . . . . . 145
Mixing the communications methods 109 Encina RQS API . . . . . . . . . 146
More about CICS intercommunication. . . 111 Encina SFS API . . . . . . . . . 147
CICS listeners . . . . . . . . . . 112 Encina PPC API . . . . . . . . . 147
CICS intercommunication facilities . . . 112 Encina COM API. . . . . . . . . 148
An introduction to secure communications 114 Encina++ . . . . . . . . . . . 149
Ensuring data integrity with Encina tools available only on Windows
synchronization support . . . . . . . 114 platforms . . . . . . . . . . . 150
CICS use of synchronization levels . . . 114 Application programming for relational
Converting between EBCDIC and ASCII databases . . . . . . . . . . . . 151
data . . . . . . . . . . . . . . 115 Application development tools . . . . . 151
CICS application development
Chapter 7. Security. . . . . . . . . 117 environment . . . . . . . . . . 151
The TXSeries security models . . . . . 117 Third-party application development
The TXSeries security model using DCE 119 tools . . . . . . . . . . . . . 153
Authenticating users and servers with
DCE . . . . . . . . . . . . . 120 Chapter 9. Systems management. . . . 155
Authenticating access from systems Managing a CICS environment . . . . . 155
outside a DCE cell . . . . . . . . 123 Configuration . . . . . . . . . . 156
DCE security information used for CICS 124 Starting and stopping servers . . . . 157
The TXSeries security model using CICS 126 Monitoring systems . . . . . . . . 157
Authenticating CICS users by a CICS The CICS administration tools . . . . 158
userid and password . . . . . . . 126 Managing an Encina environment . . . . 161
iv WebSphere: Concepts and Facilities

The Enconsole Interface . . . . . . 162 Planning how to distribute your system 183
Using the Tivoli Global Enterprise Manager Distributing CICS . . . . . . . . 183
(CICS and Encina) . . . . . . . . . 164 Distributing Encina . . . . . . . . 184
Managing resources with GEM . . . . 165 The CICS client/server distributed
Using the GEM console . . . . . . 165 environment . . . . . . . . . . . 186
Managing Encina with GEM—limitations 166 The relationship between terminal users
Tasks in GEM . . . . . . . . . . 167 and CICS regions . . . . . . . . 187
Controlling access . . . . . . . . 167 The relationship between Encina servers
Managing the Distributed Computing and CICS regions . . . . . . . . 188
Environment (DCE) . . . . . . . . . 168 The relationship between DCE servers
CDS administration . . . . . . . . 168 and CICS regions . . . . . . . . 189
Security administration. . . . . . . 168 The relationship between a CICS region
DTS administration . . . . . . . . 168 and other CICS regions . . . . . . 190
DCE administration tools . . . . . . 169 Example configurations of client/server
relationships . . . . . . . . . . 191
Chapter 10. Component planning. . . . 171 CICS performance considerations . . . . 193
Encina and CICS . . . . . . . . . . 171 Designing a CICS network . . . . . 193
Choosing a DCE configuration . . . . . 172
Deciding how to manage files and queues 174 Part 3. Appendixes . . . . . . . 197
Using an SFS Server to manage CICS
queues and data files . . . . . . . 174
Notices . . . . . . . . . . . . . 199
Using DB2 to manage CICS queues and
Trademarks and service marks . . . . . 201
data files . . . . . . . . . . . 176
Choosing a relational database manager 180
Index . . . . . . . . . . . . . 205
Planning the intercommunication network 181
Chapter 11. Configuration planning . . . 183
Contents v
vi WebSphere: Concepts and Facilities
Figures
1. Integration of WebSphere with other 34. An example Encina queue set 82
products . . . . . . . . . . . 5 35. Relational database services . . . . 83
2. A transaction . . . . . . . . . 10 36. A TXSeries communications network 90
3. Transactions and units of work 11 37. Communication between CICS clients
4. The transaction process for CICS 12 and a CICS region. . . . . . . . 92
5. Distributed transactions . . . . . . 15 38. The CICS Transaction Gateway (from
6. An Example Three-Tiered Distributed standard HTTP browser) . . . . . 96
System . . . . . . . . . . . 17 39. The CICS Transaction Gateway (from
7. Sample Order-Entry Application 18 Java-enabled browser) . . . . . . 97
8. Sample system environment . . . . 19 40. CDS components performing a CDS
9. CICS process flow for the sample lookup . . . . . . . . . . . 100
application . . . . . . . . . . 21 41. Communicating with CICS family
10. General TXSeries architecture 24 TCP/IP support . . . . . . . . 104
11. Client systems and communications 42. Communicating via Encina PPC
gateways . . . . . . . . . . . 26 TCP/IP . . . . . . . . . . . 105
12. Resource managers . . . . . . . 29 43. Using local SNA support to
13. Transaction base services . . . . . 31 communicate across SNA . . . . . 106
14. A DCE cell . . . . . . . . . . 35 44. PPC Gateway connection to an SNA
15. Distributed Computing Environment network . . . . . . . . . . . 107
(DCE) . . . . . . . . . . . . 36 45. Using a PPC Gateway server to
16. A simple distributed configuration communicate across SNA . . . . . 108
using CICS in a non-DCE cell 46. Communications using TCP/IP, a PPC
environment . . . . . . . . . 37 Gateway server, and SNA . . . . . 110
17. A distributed configuration using CICS 47. Communications using a PPC Gateway
in a DCE cell environment . . . . . 38 server and SNA . . . . . . . . 111
18. A simple Encina Monitor configuration 39 48. Security services . . . . . . . . 119
19. The CICS environment . . . . . . 41 49. The general DCE security process 120
20. The Encina Monitor environment 43 50. Authentication of CICS users by a DCE
21. General security concepts . . . . . 48 principal and password . . . . . . 122
22. Machine with a CICS region not 51. Authenticating CICS users by a CICS
running . . . . . . . . . . . 54 userid and password . . . . . . . 126
23. Windows NT machine with a CICS 52. CICS transaction and resource
region running . . . . . . . . . 56 authentication . . . . . . . . . 129
24. Data management services . . . . . 68 53. General 3-tier application
25. General file services . . . . . . . 70 programming . . . . . . . . . 137
26. File organizations . . . . . . . . 71 54. CICS application programming 139
27. General use of queues . . . . . . 73 55. Encina application programming 145
28. An example use of queues . . . . . 74 56. CICS and Encina product architecture 171
29. CICS transient data queues. . . . . 76 57. CICS in a DCE cell environment 173
30. CICS intrapartition transient data 58. CICS in an RPC-only environment 173
queues . . . . . . . . . . . 77 59. A region using an SFS server that is on
31. CICS extrapartition transient data the same machine . . . . . . . . 175
queues . . . . . . . . . . . 78 60. Two regions sharing the same SFS
32. CICS temporary storage queues 79 server . . . . . . . . . . . . 175
33. Encina queues and queue sets 80 61. CICS configuration . . . . . . . 184
© Copyright IBM Corp. 1999 vii

62. An Example Encina Monitor Cell 186 66. The relationship between CICS regions
63. The relationship between terminal and other CICS regions . . . . . . 191
users and CICS regions . . . . . . 188 67. A simple configuration . . . . . . 192
64. The relationship between CICS regions 68. A simple configuration without DCE
and Encina servers . . . . . . . 189 Security Service and CDS . . . . . 192
65. The relationship between CICS regions 69. Two regions sharing an SFS server 193
and DCE servers . . . . . . . . 190
viii WebSphere: Concepts and Facilities

Tables
1. Conventions used in this book xii
© Copyright IBM Corp. 1999 ix

x WebSphere: Concepts and Facilities
About this book
This book provides an overview of IBM TXSeries. It introduces the concepts
and terminology used in transaction processing and describes the services and
components of TXSeries. It also describes the factors involved in choosing
transaction processing components and contains example TXSeries
configurations.
Who should read this book
There is no prerequisite knowledge about transaction processing, CICS,

Encina, or other aspects of TXSeries. General information about TXSeries and
WebSphere Application Server Enterprise Edition can be found on the
following web pages:
http://www.software.ibm.com/ts/txseries
http://www.software.ibm.com/webservers/appserv/enterprise.html
Document organization
Part 1. Introducing TXSeries

v Chapter 1, ″IBM WebSphere,″ introduces the WebSphere family of products.
It also describes complementary IBM software products for use with
WebSphere.
v Chapter 2, ″Online transaction processing,″ describes transaction processing
monitors and distributed transaction processing in general. It also includes
a sample application to illustrate the components and process flow in a
transaction processing system.
v Chapter 3, ″Overview of IBM TXSeries,″ describes the components, services,
and architecture of TXSeries.
Part 2. More about TXSeries facilities

v Chapter 4, ″Transaction processing,″ describes the transaction processing
facilities and resources of a CICS region.
v Chapter 5, ″Data management,″ describes the types of data that can be
managed by CICS and Encina. It introduces Structured File Server (SFS)
files, CICS and Encina Recoverable Queueing Service (RQS) queues, and
CICS journals. It also explains the use of relational databases to manage
files and queues and how data is shared and distributed.
v Chapter 6, ″Communications,″ describes how users communicate with CICS
and Encina clients, how servers are located, and how Distributed
© Copyright IBM Corp. 1999 xi

Computing Environment (DCE) remote procedure calls (RPCs) are used in
both CICS and Encina communication. This chapter also describes
intercommunication, data integrity, and data conversion.
v Chapter 7, ″Security,″ is a detailed explanation of the two TXSeries security
models–using CICS security or DCE. It describes how TXSeries authorizes
access to resources, maintains security for clients, and ensures security via
authentication.
v Chapter 8, ″Application development,″ provides an overview of how to
design transaction processing applications, and then describes the
application development environments for both CICS and Encina.
Application development for relational databases and use of third-party
development tools is also covered.
v Chapter 9, ″Systems management,″ describes the central administrative
tools used to manage a CICS region and an Encina Monitor cell. It lists the
primary administrative tasks that can be done with these tools, including
configuring a cell or region, starting and stopping servers, and monitoring
the system. It also describes the tools used to manage DCE.
v Chapter 10, ″Component planning,″ describes the factors involved in
choosing the components of a transaction processing system.
v Chapter 11, ″Configuration planning,″ outlines the choices available when
installing and planning the distribution of clients and servers in a
distributed environment. It includes sample configurations for both CICS
regions and Encina Monitor cells.
Conventions used in this book
WebSphere Application Server Enterprise Edition documentation uses the

following typographical and keying conventions.
Table 1. Conventions used in this book
Convention Meaning
Bold Indicates values you must use literally, such as commands, functions, and
resource definition attributes and their values. When referring to graphical
user interfaces (GUIs), bold also indicates menus, menu items, labels,
buttons, icons, and folders.
Monospace Indicates text you must enter at a command prompt. Monospace also
indicates screen text and code examples.
Italics Indicates variable values you must provide (for example, you supply the
name of a file for fileName). Italics also indicates emphasis and the titles of
books.
<> Enclose the names of keys on the keyboard.
<Ctrl-x> Where x is the name of a key, indicates a control-character sequence. For
example, <Ctrl-c> means hold down the Ctrl key while you press the c key.
xii WebSphere: Concepts and Facilities

Table 1. Conventions used in this book (continued)
Convention Meaning
<Return> Refers to the key labeled with the word Return, the word Enter, or the left
arrow.
% Represents the UNIX command-shell prompt for a command that does not
require root privileges.
# Represents the UNIX command-shell prompt for a command that requires
root privileges.
®
C:\> Represents the Windows NT command prompt.
> When used to describe a menu, shows a series of menu selections. For
example, ″Select File > New″ means ″From the File menu, select the New
command.″
Entering commands When instructed to “enter” or “issue” a command, type the command and
then press <Return>. For example, the instruction “Enter the ls command”
means type ls at a command prompt and then press <Return>.
[] Enclose optional items in syntax descriptions.
{} Enclose lists from which you must choose an item in syntax descriptions.
| Separates items in a list of choices enclosed in { } (braces) in syntax
descriptions.
... Ellipses in syntax descriptions indicate that you can repeat the preceding
item one or more times. Ellipses in examples indicate that information was
omitted from the example for the sake of brevity.
IN In function descriptions, indicates parameters whose values are used to pass
data to the function. These parameters are not used to return modified data
to the calling routine. (Do not include the IN declaration in your code.)
OUT In function descriptions, indicates parameters whose values are used to
return modified data to the calling routine. These parameters are not used to
pass data to the function. (Do not include the OUT declaration in your code.)
INOUT In function descriptions, indicates parameters whose values are passed to the
function, modified by the function, and returned to the calling routine. These
parameters serve as both IN and OUT parameters. (Do not include the
INOUT declaration in your code.)
$CICS Indicates the full pathname where the CICS product is installed; for example,
C:\opt\cics on Windows NT or /opt/cics on Solaris. If the environment
variable named CICS is set to the product pathname, you can use the
examples exactly as shown; otherwise, you must replace all instances of
$CICS with the CICS product pathname.
CICS on Open Systems Refers collectively to the CICS product for all supported UNIX platforms.
TXSeries CICS Refers collectively to the CICS for AIX, CICS for Solaris, and CICS for
Windows NT products.
About this book xiii

Table 1. Conventions used in this book (continued)
Convention Meaning
CICS Refers generically to the CICS on Open Systems and CICS for Windows NT
products. References to a specific version of a CICS on Open Systems
product are used to highlight differences between CICS on Open Systems
products. Other CICS products in the CICS Family are distinguished by their
operating system (for example, CICS for OS/2 or IBM mainframe-based CICS
for the ESA, MVS, and VSE platforms).
How to send your comments
Your feedback is important in helping to provide the most accurate and

highest quality information. If you have any comments about this book or any
other WebSphere Application Server Enterprise Edition documentation, send
your comments by e-mail to waseedoc@us.ibm.com. Be sure to include the
name of the book, the document number of the book, the version of
WebSphere Application Server Enterprise Edition, and, if applicable, the
specific location of the information you are commenting on (for example, a
page number or table number).
xiv WebSphere: Concepts and Facilities

Part 1. Introducing TXSeries
This part provides an overview of TXSeries and includes the following
chapters:
v “Chapter 1. IBM WebSphere” on page 3
v “Chapter 2. Online transaction processing” on page 9
v “Chapter 3. Overview of IBM TXSeries” on page 23
See “Part 2. More about TXSeries facilities” on page 51 for details.
© Copyright IBM Corp. 1999 1

2 WebSphere: Concepts and Facilities
Chapter 1. IBM WebSphere
IBM TXSeries is part of the WebSphere Application Server family. It is
available as part of IBM’s WebSphere Application Server Enterprise Edition.
This chapter provides an overview of the WebSphere Application Server
family in the following sections:
v “WebSphere Application Server family”
v “WebSphere Application Server Enterprise Edition” on page 4
v “Products for use with Enterprise Application Server” on page 5
For more details about TXSeries and WebSphere, see the following Web page:
http://www.software.ibm.com/webservers/
This chapter also briefly discusses some of the other products that are licensed
for use with Enterprise Application Server.
WebSphere Application Server family
The IBM WebSphere Family was designed to help users realize the promise of
e-business. The WebSphere Family is a set of software products that helps
customers develop and manage high-performance Web sites and integrate
those Web sites with new or existing non-Web business systems. The
WebSphere Family consists of the WebSphere Application Server and other
WebSphere Family software that is tightly integrated with the WebSphere
Application Server and enhances its performance.
To enable customers to achieve their e-business goals, WebSphere is available

in three editions:
v The WebSphere Application Server Standard Edition (also called the
Standard Application Server) combines the portability of server-side
business applications with the performance and manageability of Java™
technologies to offer a comprehensive platform for designing Java-based
Web applications. It enables powerful interactions with enterprise databases
and transaction systems.
v The WebSphere Application Server Advanced Edition (also called the
Advanced Application Server) builds on the Standard Application Server. It
introduces server capabilities for applications built to the Enterprise
JavaBeans™ Specification from Sun Microsystems and provides some
support for integrating the Web applications to other non-Web business
systems.

v The WebSphere Application Server Enterprise Edition (also called the
Enterprise Application Server) builds on the Advanced Application Server
and also offers a robust solution to grow e-business applications into
enterprise environments. It combines TXSeries™, IBM’s world-class
transactional application environment, with the full distributed object and
business-process integration capabilities of Component Broker. The
Enterprise Application Server contains a complete version of the Advanced
Application Server.
These three editions are available on two UNIX® platforms (IBM AIX® and
Sun® Microsystems Solaris™) and Microsoft® Windows NT®. WebSphere
Application Server is also available for the OS/390® and AS/400® platforms;
only one edition of WebSphere Application Server is available on these
platforms.
The WebSphere Application Server Enterprise Edition contains all of the

products found in the Advanced Edition and adds the following major
product components:
v TXSeries, which contains two popular middleware packages (CICS and
Encina) that support and simplify the creation of transactional applications
that can span multiple platforms in diverse and complex networks. In
addition to offering cross-enterprise integration, TXSeries applications
provide high levels of scalability, availability, integrity, longevity, and
security.
v Component Broker, which is an enterprise solution for distributed
computing, providing a scalable, manageable run time for developing and
deploying distributed component-based solutions. It is a complete and
integrated implementation of the open standards contained in the Object
Management Group’s (OMG) Common Object Request Broker Architecture
(CORBA). In addition, Component Broker contains a separate
implementation of the EJB Specification, which can be used with or instead
of the implementation contained in the Advanced Edition.
Enterprise Application Server contains a complete tool set for building Web
applications, for creating distributed, transactional applications that can tie
together disparate non-Web business computing resources, or for integrating
your Web and non-Web systems.

Products for use with Enterprise Application Server
The WebSphere Application Server Enterprise Edition is integrated with other

IBM products as shown in Figure 1.
Figure 1. Integration of WebSphere with other products
The Enterprise Application Server includes the following additional products

that are required by (or recommended for use with) the main tools of the
Enterprise Application Server:
v DB2 Universal Database
v MQSeries
v VisualAge
In addition, the Tivoli products provide integrated system management
solutions for enterprise businesses. Each of these products is described in the
following sections.
IBM DB2 Universal Database
The IBM DB2 Universal Database is designed for businesses that need a
full-powered relational database server that can make use of the power of the
Internet. It combines the customer-proven strengths of IBM’s industry-leading
relational database, DB2, with a robust set of tools for managing
heterogeneous, geographically dispersed databases. It is simple enough for
small Local Area Network (LAN) environments and yet powerful enough for
large-scale distributed customer environments.
Chapter 1. IBM WebSphere 5

TXSeries provides transaction-based access to data stored in DB2 databases.
User applications can make industry-standard Structured Query Language
(SQL) queries for data, with the benefits of transaction processing enhanced
by the data independence and integrity provided by DB2.
DB2 can be used by the EJB administration servers contained in the Advanced
Application Server and must be used by the EJB administration servers
contained in Component Broker. It can also be used to store persistent data
associated with entity beans with Container-Managed Persistence (CMP) in
both EJB implementations.
DB2 Universal Database’s Net.Data enables Internet and intranet access to

relational databases on a variety of platforms. Because of the server’s support
for the Open Database Connectivity (ODBC) and Distributed Relational
Database Architecture (DRDA) standards, customers can use the desktop tools
of their choice, including Web browsers, to access the server and have
transparent access to other data management systems.
MQSeries
The IBM MQSeries range of products enables application programs to

communicate in a nonserial, asynchronous manner by using messages and
queues. At the heart of MQSeries is the Message Queue Interface (MQI), a
high-level programming interface that enables applications to communicate
transparently across various platforms. MQI takes care of network interfaces,
assures delivery of messages, deals with communications protocols, and
handles recovery from system problems.
VisualAge
IBM offers a full range of application development tools for use with
WebSphere. The WebSphere Application Server Enterprise Edition for
Windows NT includes the following VisualAge products:
v IBM VisualAge for Java Enterprise Edition—VisualAge for Java is a
powerful integrated development (IDE) environment that contains many
features for building an e-business solution. This powerful IDE provides
support for developing and testing Java applications and components
written to the Enterprise JavaBeans and JavaBeans Specifications.
v IBM VisualAge C++ Professional Edition—VisualAge C++ provides a rich
environment and toolset for multiplatform object-oriented application
development. The development environment is especially valuable for
high-performance and highly computational applications. Its Open Class
Library provides advanced class libraries and frameworks to build robust
applications on AIX, OS/2, and Windows NT.

Tivoli management servers
The IBM Tivoli management servers provide simplified, enterprise-wide

systems management for multivendor client/server environments. They
deliver an integrated set of applications and services with an easy-to-use
interface.
Systems management includes performance, network management, disaster

recovery, security, and the ability to respond to change. Businesses require a
single, tailorable solution to manage different platforms, operating systems,
networks, and current investments. The IBM Tivoli management servers offer
a complete solution that helps you to make the most of your
information-processing resources and get the greatest return on your systems
management investment.
Chapter 1. IBM WebSphere 7

Chapter 2. Online transaction processing
This chapter provides an overview of transactions and transaction processing
in an online computing environment. It contains the following topics:
v “Transactions”
v “Transaction processing monitors” on page 11
v “Distributed transaction processing” on page 14
v “A sample transaction processing environment” on page 18
If you want more details on transaction processing, see “Chapter 4.

Transaction processing” on page 53.
In online transaction processing (OLTP), many users access large quantities of

information without interfering with each other and without sacrificing the
integrity, speed, and reliability of service provided to each user. Organizations
use transaction processing systems to manage mission-critical information,
where correct and up-to-the-minute information is vital. Transaction
processing systems range from small systems that support a single retailer to
airline systems that serve tens of thousands of users and store hundreds of
gigabytes of data.
Transaction processing enables business applications to concentrate on

business logic and not on data presentation, data retrieval, or resource
management issues. TXSeries provides all the services needed to develop and
run business applications in a transaction processing environment. These
services are outlined in “Chapter 3. Overview of IBM TXSeries” on page 23
and described in “Part 2. More about TXSeries facilities” on page 51.
Transactions
Each user’s interaction with a business information system involves one or

more transactions. (See Figure 2 on page 10.) Each transaction is a set of
operations that must be executed as a unit (though each operation can run in
a different process). Transaction processing is supported by transaction
processing monitors, which provide a way to develop, run, and administer
transaction processing applications. TXSeries provides two transaction
processing monitors, Customer Information Control System (CICS) and the Encina
Monitor.

Figure 2. A transaction
In CICS, a group of related operations is called a logical unit of work (LUW). In

Encina, a group of related operations is called a transaction.
All transactions ensure the integrity and consistency of business information

systems by providing atomicity, consistency, isolation, and durability of work,
known as the ACID properties:
Atomicity
Related operations are grouped into discrete units. All operations in a
unit either complete successfully (they commit their changes) or none
do (they back out their changes).
Consistency
A transaction moves data between consistent states and operates in a
repeatable way. The data used by a transaction is changed in the way
that the user expects and is left in a state that other transactions can
use. If a transaction is repeated, it always performs the same logic.
Isolation
Even though transactions can run concurrently, no transaction can
interfere with another’s work in progress. The transactions appear to
run serially.
Durability
When a unit of work completes successfully, its changes persist even
if a transaction, system, or other failure subsequently occurs.
A transaction can comprise one or more LUWs, as shown in Figure 3 on

page 11. (In Encina, a transaction is a single unit of work.) When an LUW
completes successfully, it issues a synchronization point (also called a syncpoint),

which marks the end of the LUW. This commits any data changes made in
the LUW and releases the data for use by other transactions.
If a task fails, any uncommitted changes are backed out automatically. This
restores recoverable resources to the consistent state they were in at the
beginning of the interrupted LUW (that is, at the most recent syncpoint or the
start of the task). This reversal process, called dynamic transaction backout,
occurs within the same task to safeguard other tasks from any chance of using
corrupted data.
Figure 3. Transactions and units of work
Transaction processing monitors
Transaction processing is controlled by a transaction processing monitor,

which performs all the functions needed to coordinate the online processing
of transactions. In CICS, the transaction processing monitor is implemented by
developing one or more CICS regions, individual administrative units that
support multiple concurrent application programs. In Encina, the transaction
processing monitor is implemented by developing one or more Monitor
application servers running multiple instances (called processing agents) of
the server code. The Monitor application servers run in a single administrative
unit called a Monitor cell.
A CICS region (or Encina Monitor application server) performs work

requested by one or more clients. For example, a user application running on
one machine (the client machine) requests work to be done on another
machine (the server machine). Typically, the region accesses some data,
applies some business logic to it, and then replies to the client. Such service is
provided by running one or more programs on behalf of a transaction.
Chapter 2. Online transaction processing 11

The CICS region maintains and uses a pool of multithreaded processes, each
of which provides a complete environment for running a transaction. In CICS,
such processes are called application servers. In Encina, Monitor application
servers run individual instances of server code called processing agents (PAs).
Each CICS region coordinates all the facilities needed by its application
servers. For example, it coordinates the security of the application servers,
obtains data and storage that they need, and logs their transactions. Among
other advantages, multiple CICS regions can be used to provide a distributed
transaction processing environment for greater throughput and separation of
workload.
A CICS region subcontracts many services to other servers better able to do

the work but provides extra services needed for integrated transaction
processing. For example, a CICS region can use Structured File Server (SFS)
files or DB2 databases to store and manage user data. A region also provides
services to locate and interface with the resource managers, record ongoing
changes to data, and coordinate the update of data across multiple resource
managers.
The transaction life cycle
This section provides an overview of the life cycle of a transaction. The

transaction process for CICS is illustrated in Figure 4 and explained in the text
that follows.
Figure 4. The transaction process for CICS

When a user application requests a transaction in CICS, the request is passed
to a CICS region to be processed. The following numbered steps correspond
to the numbers in Figure 4 on page 12:
1. The CICS region receives a transaction request from a user application.
(The region must first verify that it can communicate with the user’s
device and that the user is authorized to use the system.)
2. The CICS region searches its table of transaction definitions for information
about the transaction. (Before a transaction can be used, it must be defined
with attributes such as the name of the first program to be run when the
transaction is requested.)
3. If a transaction definition exists, the CICS region assigns the request to a
task that it uses to control the processing of the transaction’s programs.
The region schedules the task to be processed with other tasks and
allocates processing time and access to the required data.
4. The task runs the transaction’s first program on a process called an
application server. If the transaction is implemented by several programs,
those programs can run on the same or separate processes, depending on
how the programs are invoked.
5. The CICS region monitors the progress of the task, serving its requests for
data, communications, and other resources. It also performs background
operations needed to ensure that the task continues to run optimally,
without conflict with other tasks and with the data integrity required.
6. When the task completes, the CICS region commits any data changes,
terminates the task, and frees resources for use by other transactions.
Several instances of the same transaction can be running at the same time, as
separate tasks.
The transaction process is similar in Encina:

1. The client, which interacts with the user, makes a remote procedure call
(RPC) to the interface of a Monitor application server (that is, it calls a
function defined at compile time in the interface’s Transactional Interface
Definition Language, or TIDL, file). An interface is a group of remote
procedures that the server makes available to clients. The TIDL file
contains the name and description of return values and argument types
for each procedure in the interface.
2. The application server processes the client request, usually by interacting
with one or more resource managers. The remote procedure call (RPC)
runtime module in the application server receives the communication and
prepares to call the requested server function. During this process, the
protection level and authorization are checked to verify that the client is
allowed to access the requested function.

3. An application server consists of one or more multithreaded processes
(called PAs) that receive and handle client requests for services. The
Monitor automatically parcels out client requests among the various PAs.
4. The server function processes the call. The RPC runtime module returns
the response to the client.
5. When the work is completed, multiple processes coordinate the
committing or aborting of the transaction, using the two-phase commit
protocol. If the transaction is successful, the application server (or other
coordinator) commits any data changes, terminates the transaction, and
frees resources for use by other transactions. If the transaction fails, any
changes are rolled back.
Distributed transaction processing
Modern business information systems are increasingly decentralized and

dynamic. They take advantage of evolving technologies to stay competitive
and to benefit from the smaller, less-expensive, and more powerful computers
and the proliferation of communications services. At the same time, the
information system has to cope with the interaction of different types of
computers, communications networks, and user devices. A transaction can
involve operations on a customer’s notebook computer, a branch desktop
computer, and a central mainframe, yet the system must still provide the
optimum service and integrity. Distributed transaction processing ensures that an
application does not need to be concerned about where operations are
performed as long as the service and integrity are maintained.
In the simplest distributed processing system, a transaction involves several

programs running on different processes of the same machine. In a truly
distributed environment, the processes are on different machines, possibly on
different platforms. This is shown in Figure 5 on page 15, where each oval
indicates work done on a different machine. The arrows between ovals
indicate RPCs.
The most common way for clients to communicate with servers is by using
RPCs. The RPC mechanism hides the details of network communications from
applications; a program always makes the same type of call (an RPC) to
communicate with other programs, regardless of whether the programs are
running on the same or different machines.

Figure 5. Distributed transactions
The business application perceives no functional difference between a

transaction running on one process and a transaction running on several
distributed processes. It still makes the same calls for programs, data, and
other resources and lets the transaction server determine where the resources
are. Users, however, can perceive a better service from the application. For
example, a transaction server can be optimized for user interaction, resulting
in rapid response times, and it can pass on work-intensive operations to
another transaction server for processing.
By distributing transactions, a business can configure its systems flexibly,

placing parts of the logic and the data where they can be used most efficiently.
Services can be tailored to local (geographic or business) needs.
Interconnection enables sharing of logic and data. It also enables greater

availability and reliability by providing duplicate services on separate
computers. Distribution also enables incremental growth of the system by the
addition or replacement of individual computers without affecting the use of
other computers in the system.
A common way of organizing software to run on distributed systems uses the

client/server model. A client, which can be anything from a customer’s
notebook computer to a branch-level computer, contains the display logic. The
business logic and data logic can be distributed among optimal servers across
the network. The client makes a request for a service and a server performs
that service. Server functionality often involves some sort of resource

management, in which a server synchronizes and manages access to the
resource, responding to client requests with either data or status information.
Client programs typically handle user input/output (I/O) and often request
data or initiate some data modification on behalf of a user.
For example, a client can provide a form on which a user (a person working
at a data entry terminal, for instance) can enter orders for a product. The
client sends this order information to the server, which checks the product
database and performs tasks needed for billing and shipping. A single server
is typically used by multiple clients. For example, dozens or hundreds of
clients can interact with a handful of servers that control database access.
Distributed architectures take many forms. One possible architecture is the

three-tiered client/server model. Figure 6 on page 17 shows an example
three-tiered client/server architecture. The first tier contains presentation
software—client applications that interact with users through screens or
command-line interfaces. The client applications send requests to server
applications in the second tier. Second-tier applications contain the business
logic. Servers perform services, such as updating or retrieving data in
response to requests from clients. The third tier contains data and resources,
separating them from the processing logic. Servers communicate with resource
managers. A resource manager is an application that manages shared data,
such as an Oracle database used to hold account information. Servers can
draw on a wide range of resources, including mainframes and relational
database management systems (RDBMSs) to perform their work.

Figure 6. An Example Three-Tiered Distributed System
To maintain the ACID properties, a distributed transaction processing system

uses two features:
Recoverable processes
A recoverable process logs its actions and thus can restore earlier
states if a failure occurs.
Commit protocol
Processes coordinate the committing and aborting of units of work.
The most common protocol is the two-phase commit protocol.
When a unit of work (LUW or transaction) is to be committed, the transaction

processing system ensures that all recoverable servers involved in the work
commit their updates. If one or more cannot do so (for example, if
communication with the resource manager fails), then all servers have to back
out their updates. To achieve this, the commit procedure has two phases (and
is called two-phase commit). In the first phase (the prepare phase), a server
coordinator asks each participant to record sufficient information about the
work to enable the transaction server to commit or back out the updates. In
the second phase (the commit phase), the server coordinator checks that all
participants have completed their updates successfully. If so, it commits the
updates; otherwise, it backs out the changes and aborts the transaction.

Committed changes to data are made permanent. This ensures that a
successful unit of work is reflected as a permanent change to a database and
survives hardware and software errors. If a failure occurs, all processes
involved in the transaction undo any work that has not been committed.
A sample transaction processing environment
This section describes a sample application in a transaction processing

environment.
The sample application
The sample application is a simple order-entry system. The details of its

functions are not important here, but the system generally supports such user
tasks as querying details of items in a catalog, ordering items, and shipping
items to customers. To order an item, the application checks for the item in its
database, changes the inventory, and sends requests to billing and shipping
applications.
Figure 7 shows the basic design of this application.
Figure 7. Sample Order-Entry Application
To place an order, a user interacts with the order-entry program. This program
calls the main order-entry program to do the main application functions. This
program, in turn, does the following:
v Checks for the item in a local RDBMS.
v Adds a shipping request to a central queue that is not part of the
order-entry application. This queue is processed by a central shipping
program that is also not part of the order-entry application.

v Sends a billing request to a central billing program. This central billing
program is not part of the order-entry application.
These operations are all parts of the same logical unit of work. If any
operation fails (for example, if there is insufficient inventory to fill the order),
any changes are backed out and the client is told that the order cannot be
placed.
Other programs cooperate with the order-entry application but are not part of
that application. For example, the queue is processed by a separate central
shipping program and customer bills are processed by a separate central
billing program.
The sample system environment
The order-entry application and associated programs described in “The

sample application” on page 18 are implemented on several client and server
machines. Figure 8 shows the basic design of this system environment.
Figure 8. Sample system environment
To place an order, a user interacts with a client, which requests that a CICS
region do the main application functions. (The CICS region can run on the
same machine or on a different machine.) This CICS region runs the main

order-entry program on one of its application server processes. To implement
the rest of the order-entry system, the CICS region does the following:
v Communicates with an XA-compliant resource manager (inventory)
v Communicates with an XA-compliant resource manager (shipping queue)
v Runs the local billing program on another of its application servers
The local billing program sends billing requests on to a mainframe-based

server. To do this, it routes the requests through a Peer-to-Peer
Communications (PPC) Gateway server and, through that gateway, via a
Systems Network Architecture (SNA) protocol.
In this example, the following are shown:

v The main order-entry program and local billing program run on the same
CICS region. They can run on different regions.
v The queue resource manager and the shipping server run on the same
machine; they can run on separate machines. The PPC Gateway and SNA
must run on the same machine.
In a CICS environment, the order-entry program can run on one of the IBM
CICS Clients provided by TXSeries, and the other programs can run on a
CICS region. The transactions, programs, and other resources used by the
sample application are predefined to the CICS region, as are the identities of
the RDBMS, resource manager, and other network resources.
In an Encina Monitor environment, the order-entry program is a Monitor

client. The main order-entry program is a Monitor application server running
in a Monitor cell. The other programs and resource managers can run in the
same cell. The central shipping program can forward requests to an Encina
Recoverable Queueing Service (RQS) server running in the same Monitor cell
or in a different cell. A PPC Executive application can run the local billing
program and communicate with the mainframe through a PPC Gateway
server.
The transaction processing flow
This section describes the CICS transaction processing flow for the order-entry
application and associated programs described in “The sample application” on
page 18. Figure 9 on page 21 shows the process flow in the sample application.

Figure 9. CICS process flow for the sample application
To place an order, a user interacts with the order-entry graphical user interface
(GUI) on a client machine. This starts the transaction processing flow. The
following numbered steps correspond to the numbers in Figure 9:
1. The GUI program calls the client program with a request to place an
order. The request identifies a transaction to be run and passes
appropriate parameters to qualify the request.
2. The client program calls a CICS region, passing on the request from the
GUI.
3. The CICS region verifies that the user is authorized to make the request
and that the user’s terminal is supported. If not, the user is prevented
from using the transaction processing system.
4. The CICS region assigns a task to process the new instance of the
transaction and schedules the task for processing alongside other current
tasks. The CICS region processes and monitors the order-entry request
throughout the task.
5. The CICS region starts the task, getting storage and other operating
system resources for it. It runs the first program for the transaction, the
main order-entry program. The program runs on an application server
taken from the server’s pool of such processes.
6. The main program checks and decrements the entry in the relational
database. The CICS region and the RDBMS both lock the database entry
to isolate it from update by other transactions. Only this one transaction
can update the account. The CICS region logs the change but does not
commit it until the shipping and billing operations have succeeded.

7. The main program adds a shipping request to the central shipping queue.
The CICS region logs the change but does not commit it until the billing
operation has succeeded.
8. The main program invokes a local billing program to route a request to
the central billing program, which runs as a remote program on a
mainframe host. The local billing program runs on a separate application
server.
9. The local billing program sends the billing request through a PPC
Gateway server (which uses SNA) to the mainframe host. It waits for the
reply (while the main program can be doing other work) and then
returns the reply to the main order-entry program.
10. Having successfully accessed the database, queued the shipping request,
and processed the billing request, the main order-entry program now
issues a syncpoint. The CICS region commits and logs the changes made
to the database, shipping queue, and billing data. This makes the changes
durable.
11. The CICS region releases the resources used for the order-entry request
and makes the application server available for other tasks.
12. The CICS region returns an appropriate success message to the user
through the client program and the order-entry GUI.

Chapter 3. Overview of IBM TXSeries
This chapter introduces TXSeries and describes its components and services. It
includes examples of distributed transaction processing environments that use
CICS and Encina. It contains the following sections:
v “What is TXSeries?”
v “TXSeries environments” on page 40
v “TXSeries facilities” on page 44
For more details, see “Part 2. More about TXSeries facilities” on page 51.
What is TXSeries?
IBM TXSeries is an architecture of integrated software components that you

can use to create a CICS environment, an Encina Monitor environment, or
both. This section outlines the software architecture of TXSeries. For details on
specific software versions and hardware prerequisites, see the Planning and
Installation Guide book.
The TXSeries components and architecture
The general architecture of TXSeries is shown in Figure 10 on page 24.

Figure 10. General TXSeries architecture
TXSeries forms a layer of middleware between your business applications and

the operating system. Business end-users see only the application interfaces
and need not know anything about the underlying architecture. The TXSeries
components are described in the following sections:
v “Transaction processing monitors”
v “Client systems and communications gateways” on page 25
v “Resource managers” on page 29
v “Transaction base services” on page 31
v “DCE services” on page 33
Transaction processing monitors
TXSeries provides a choice of two leading transaction processing monitors:

either CICS or the Encina Monitor. You can create business solutions with
either system, and the different systems can communicate and cooperate with
one another.
CICS CICS is a family of products that provides online transaction
processing and transaction management for applications on both IBM
and non-IBM platforms. CICS builds on the services of the operating
system, the Open Group’s Distributed Computing Environment
(DCE), and Encina. CICS offers many services for application
development, communications, recovery, presentation, data
management, security, and intercommunication.

Encina Monitor
The Encina Monitor provides an infrastructure for developing,
running, and administering transaction processing applications. This
infrastructure includes:
v A full-featured application programming interface (API) that shields
the programmer from the complexities of distributed computing
v A reliable execution environment that delivers load balancing,
scheduling, and fault-tolerance across heterogeneous environments
to provide high performance and transactional integrity
v A comprehensive management environment that enables widely
distributed Monitor-based systems to be administered as a single,
logically defined system
The Monitor provides an open, modular system that is scalable and
that interoperates with existing computing resources such as IBM
mainframes running CICS. It supports interoperation among a
number of components—the operating system, DCE, the Encina
Toolkit, third party relational database management systems such as
Informix and Oracle, third-party front ends (user interfaces), and
networks—for application development.
Client systems and communications gateways
TXSeries provides the following clients and communications gateways, as

shown in Figure 11 on page 26.
Chapter 3. Overview of IBM TXSeries 25

Figure 11. Client systems and communications gateways
IBM CICS Clients: TXSeries includes the following IBM CICS clients:
v CICS Universal Clients (for Windows 95, Windows 98, Windows NT, OS/2,
AIX, and Solaris)
v CICS on Open Systems Clients (for AIX, Solaris, and HP-UX)
CICS Universal Clients communicate with CICS regions on the wide range of
platforms supported by CICS. Communications can be through Transmission
Control Protocol/Internet Protocol (TCP/IP) or Systems Network Architecture
(SNA), available as a range of communications products for the client
workstation platforms or (for TCP/IP) as part of some workstation operating
systems. Clients can also communicate with other systems in an SNA
network—for example, with IBM mainframe-based CICS. To do this, the
clients and servers can use local SNA directly, or indirectly through a
Peer-to-Peer Communications (PPC) Gateway. TXSeries also includes the
Encina PPC Executive component, which provides the APIs for Logical Unit
(LU) 6.2 peer-to-peer communications, and emulation of LU 6.2 over TCP/IP.
CICS Universal Clients provide a standard set of interfaces for client

applications and 3270 terminal emulation. Universal Clients can use TCP/IP
and SNA to communicate with CICS regions on many platforms; for example,
CICS for Windows NT, CICS for AIX, and CICS for MVS/ESA. For example, a
user of a CICS Client for Windows NT can run a client application that
communicates with a CICS for AIX region across TCP/IP while using a 3270
terminal emulator to run transactions on a CICS for MVS/ESA region

connected through an SNA network. DCE-enabled clients use DCE remote
procedure calls (RPCs) over TCP/IP to communicate with CICS regions.
CICS on Open Systems Clients use only DCE remote procedure calls (RPCs)
over TCP/IP to communicate with CICS regions.
Depending on the platform, CICS clients can also be used as an interface

between CICS regions and users connected through the Internet (World Wide
Web).
For more information, see the following Web page:

http://www.software.ibm.com/ts/cics (IBM CICS Clients)
Communications Gateways: TXSeries provides the following

communications gateways:
DE-Light Gateway
The DCE Encina Lightweight Client (DE-Light) is a set of application
programming interfaces (APIs) and a gateway server that you can use
to extend the power of DCE and Encina to personal computers and
other systems not running DCE. You can use DE-Light to build clients
that require less overall effort to create than standard DCE or Encina
clients and still take advantage of the benefits of load balancing,
scalability, and server replication formerly restricted to DCE and
Encina. DE-Light is composed of the following components:
v Java API — Used to develop Java clients for standalone Java
applications. DE-Light Java clients communicate with gateways via
TCP/IP and Hypertext Transfer Protocol (HTTP).
v C API — Used to develop clients for the Microsoft Windows NT
and Windows 95 environments. DE-Light C clients use TCP/IP to
communicate with gateways at known endpoints.
v Gateway server — Enables communications between DE-Light
clients and DCE or Encina.
CICS Transaction Gateway
The CICS Transaction Gateway enables Internet access to the
transactional capabilities of IBM CICS servers, including CICS
Transaction Servers and TXSeries servers, using standard Internet
protocols. The gateway enables any Web browser, Network Computer,
or Internet-enabled consumer device to access business applications
running on CICS servers, using one of three possible methods:
v Standard HTML browsers. The CICS Transaction Gateway renders
existing CICS 3270 applications into HTML automatically, and
transmits to the browser using HTTP. You can also create your own
Java servlets that present information from CICS applications in
HTML forms, customized as required.

v Java-enabled Web browsers. The CICS Transaction Gateway enables
customer applets to access CICS 3270 applications and CICS
programs using supplied Java classes and Java beans.
v ORB-enabled Web browsers. The browsers can run Java beans
which interoperate with server-side Java beans (running on the
CICS Transaction Gateway) via the Common Object Request Broker
Architecture (CORBA) IIOP protocol. The server-side beans can
then invoke CICS 3270 applications and CICS programs using
supplied Java classes.
The CICS Transaction Gateway incorporates the CICS Universal

Clients and a workload balancing facility that allows the transaction
workload from a large number of browers to be distributed across
multiple CICS regions or CICS servers. The gateway is available on
the OS/2, Windows NT, AIX, and Solaris platforms.
Additional Products
TXSeries includes the following additional products:

IBM HTTP Server
The IBM HTTP Server, based on the Apache HTTP Server, features
support for SSL secure connections (both the SSL version 2 and SSL
version 3 protocols). This protocol, implemented using IBM security
libraries, ensures that data transferred between a client and a server
remains private. Once your server has a digital certificate, SSL-enabled
browsers like Netscape Navigator and Microsoft Internet Explorer can
communicate securely with your server using the SSL protocol. The
IBM HTTP Server supports client authentication, configurable cipher
specifications, and session ID caching for improving SSL performance
on the UNIX platforms. The Cache Accelerator (Windows NT systems
only) can dramatically improve the performance of the HTTP Server
when serving static pages, for example, text and image files. Because
the Cache Accelerator cache is automatically loaded during server
operation, you are not required to list the files to be cached in your
server configuration file. In addition, the server will automatically
recache changed pages and remove outdated pages from the cache.
The Cache Accelerator provides support for caching on Web servers
with single and multiple TCP/IP adapters.
MQSeries
The IBM MQSeries range of products enables application programs to
communicate in a nonserial, asynchronous manner by using messages
and queues. At the heart of MQSeries is the Message Queue Interface
(MQI), a high-level programming interface that enables applications to
communicate transparently across various platforms. MQI takes care

of network interfaces, assures delivery of messages, deals with
communications protocols, and handles recovery after system
problems.
Resource managers
Resource managers are servers that manage shared resources, such as

application data in files and databases. TXSeries provides the following
resource managers, as shown in Figure 12:
v Encina Structured File Server (SFS), a record-oriented transactional file
system.
v Encina Recoverable Queueing Service (RQS), a transactional queueing
service.
Figure 12. Resource managers
Structured File Server (SFS)

SFS is a record-oriented file system that offers transaction integrity
and log-based recovery, while supporting large numbers of concurrent
users and very large files that can span multiple disks. SFS runs on
the transaction base services and uses DCE RPCs to communicate
with other servers.

SFS provides both data processing and administrative functions. The
data processing functions provide the standard operations needed to
access and modify data: read, insert, update, delete, lock, unlock, and
so on. The administrative functions enable programs to query and
modify SFS files and volumes, duplicate and delete files, and so on.
Recoverable Queueing Service (RQS)
RQS manages multiple, simultaneous requests for data stored in
queues. RQS runs on the transaction base services and uses DCE
RPCs to communicate with other servers, such as CICS regions.
RQS allows asynchronous connectivity between applications—clients
can offload tasks for later processing. RQS clients can enqueue
requests that do not need to be performed immediately, allowing a
server to eventually dequeue the requests and perform the required
work. Recoverable queues can be used to partition time-consuming
transactions into separate pieces that can be processed as resources
permit, or to accept requests for later, off-peak processing.
Applications can also move work from one queue to another for
additional processing. RQS also provides mechanisms for grouping
queues, setting queue priorities, regulating the distribution of dequeue
requests among queues, and tracking a variety of statistics on queue
activity.
Relational Database Support
Transactions can access relational database management systems
(RDBMSs) by including embedded Structured Query Language (SQL)
calls within their application programs. CICS and the Encina Monitor
provide interfaces for database managers, and provide monitoring and
control services.
With databases that conform to the X/Open Distributed Transaction
Processing (DTP) XA standard, TXSeries coordinates the transactional
update of data, with full two-phase commit of updates. RDBMSs for
use with TXSeries include the following:
v On Windows NT: DB2, DB2 Universal Database, Microsoft SQL
Server, and Oracle.
v On other platforms: the IBM DB2 family and other relational
databases such as Oracle, Sybase, and Informix.
For further information, see the following Web page:

http://www.software.ibm.com/data/db2/ (DB2 Product Family)

Transaction base services
The Encina Toolkit provides the transaction base services required for
distributed transaction processing systems. The Toolkit services implement a
complete transaction paradigm: nested, distributed, concurrent transactions
with recoverable storage. These transactions can be used to maintain the
consistency of data on a network in the face of communications failures,
system failures, and disk failures.
The Toolkit services provide the foundation on top of which Encina’s

extended services are built. These extended services include higher-level
facilities (such as the Encina Monitor) that expand the Toolkit functionality to
provide a comprehensive environment for developing distributed transaction
processing applications.
The transaction base services are grouped into the following two classes:
Toolkit Executive
The Executive provides services that permit a process to initiate,
participate in, and commit distributed transactions. These services
include transactional extensions to DCE remote procedure calls (RPCs)
that ensure transactional integrity over distributed computations
transparently. The Executive also supports nested transactions, a
feature that provides failure containment and simplifies application
development.
Toolkit Server Core
Built upon the Executive, the Server Core provides facilities for
managing recoverable data (data that is accessed and updated
transactionally). These facilities include a locking library to serialize
data access, a recoverable storage system to allow transactions to roll
back after failures, and an X/Open XA interface to permit the use of
XA-compliant resource managers.
Figure 13. Transaction base services
The transaction base services is a suite of services, as shown in Figure 13 . The

unshaded components make up the Toolkit Executive and the shaded
components are part of Toolkit Server Core.

The modules of the Toolkit can be invoked automatically through higher-level
C-language interfaces provided by Encina. Transactional-C (Tran-C) is the
suggested interface for the development of transactional applications based on
the Encina Toolkit. Tran-C adds functions and constructs to the C
programming language that simplify the creation of transactions and correctly
handling whether those transactions abort or commit successfully.
Additional interfaces include Encina++, Tran-C++, and the Object

Management Group Object Transaction Service (OMG OTS).
Toolkit Executive: The following services, which are part of the Toolkit
Executive, provide support for writing client applications:
Distributed Transaction Service (TRAN)
TRAN coordinates multiple transactions, guarantees that transactions
either commit or abort consistently, supports a nested transaction
model, and manages the delivery of information about transaction
outcome to various participants.
Transactional RPC (TRPC)
TRPC provides the underlying communications mechanisms used by
the entire system, enabling transactions to be distributed to other
programs and nodes.
Thread-to-Tid Mapping Service
The Thread-to-Tid Mapping Service (ThreadTid) maintains the
association between a thread and a transaction identifier (TID),
allowing applications to determine which transaction is associated
with a thread.
Toolkit Server Core: The following services, which are part of the Toolkit
Server Core, provide support for writing server applications:
Lock Service (LOCK)
LOCK permits synchronization of accesses to data. Transactions that
run concurrently act as though each ran to completion before the next
was begun.
Log Service (LOG) and Recovery Service (REC)
LOG and REC help guarantee that changes made to data by a
transaction are permanent if the transaction commits, regardless of
system restarts or media failures, and that changes made to data by
that transaction are undone if the transaction aborts.
Volume Service (VOL)
VOL provides a logical interface to underlying physical storage that
enables volumes and files to span physical device boundaries.

Transaction Manager-XA Interface (TM/XA)
TM-XA implements the transaction manager side of the X/Open XA
interface for coordinating distributed transactions with XA-compliant
resource managers.
DCE services
DCE enables distributed transaction processing environments using CICS and

Encina to run seamlessly across machines that differ in terms of hardware,
operating system, network transport, and application software. The DCE layer
extends the basic operating systems of the separate machines to provide a
common infrastructure for distributed computing. By using the standard
interfaces provided by DCE, applications can interoperate with and be ported
to other DCE platforms. The following sections describe the DCE services
used by TXSeries.
Remote Procedure Call: At the core of DCE support is the RPC. RPCs
provide a form of network-transparent communication between processes in a
distributed system. Processes use RPCs to communicate in exactly the same
way regardless of whether they are on the same machine or different
machines in the DCE cell. The DCE security service can be used to
authenticate RPCs. Authenticated RPCs can be checked for tampering and can
be encrypted for privacy. DCE uses multithreading to enable a client to have
multiple concurrent RPC conversations with servers and to enable a server to
handle many concurrent client requests.
Cell Directory Service (CDS): The CDS provides a namespace within which
network resources can be accessed by name only. Applications do not need to
know the addresses of resources. (Typical network resources are servers, users,
files, disks, or print queues.) Further, if a resource is moved, it can still be
located by the same name; application code does not need to be changed.
The CDS Server manages a database, called a clearinghouse, which contains the
names and attributes (including locations) of network resources in the DCE
cell. When a request is made for a network resource, the CDS Server
dynamically locates the resource.
The DCE Directory Service also supports a global name service for identifying
resources outside a cell. For more information, see “Using the CDS to locate
systems outside the DCE cell” on page 101.
Security service: The DCE security service provides secure communications

and controlled access to network resources in a DCE cell. It verifies the
identity of DCE principals (users, servers, and DCE-enabled clients) and allows
them to access only the network resources that they have been authorized to
use. The DCE security service does the following:

v Manages a central source of security information in the cell’s security
database.
v Validates the identity of interactive principals, such as users, by enabling
them to log in to DCE. This is known as establishing a login context.
v Grants tickets to principals and services so their communications are secure.
v Certifies the credentials of principals to control principals’ access rights to
resources.
v Validates the identity of noninteractive principals, such as CICS regions, by
enabling them to perform the equivalent of an interactive user login. In this
way, they can establish their own login context rather than running under
the identity of the principal that started them.
v Controls the authorization that principals have to network resources in the
DCE cell. All objects in the DCE cell can have an associated Access Control
List (ACL) that specifies which operations can be performed by which users.
ACLs can be associated with files, directories, and registry objects, and be
implemented by arbitrary applications to control access to their internal
objects.
The DCE security service is implemented as a Security Server, which

maintains a store of security information about network resources in its
security database (also known as the DCE registry database).
Distributed Time Service (DTS) Server: To compensate for natural drifts in

system clocks, the DCE DTS ensures that all system clocks of the servers in a
DCE cell are synchronized. This is especially important where servers are in
different time zones. A time service is also essential for reliable operation of
authentication and authorization services.
DCE cells: A DCE cell is a group of machines, systems, users, and services
that are administered as a DCE unit. This model simplifies the
implementation and administration of security throughout a network. A DCE
cell requires the following DCE core servers:
v One or more CDS servers
v One or more Security servers
v One or more DTS servers
Figure 14 on page 35 shows an example DCE cell.

Figure 14. A DCE cell
All of the DCE core servers can run on the same machine or on different
machines in the DCE cell. The machines can be any platform that supports
DCE.
The Security Server must run on a secure, highly available computer under
the control of a specially authorized system administrator. The registry
database is only as secure as the security provided by the machine on which
it resides. Access to the CDS is protected by the DCE Security Server so that
only properly authenticated and authorized principals can access the CDS.
The CDS Server and Security Server can be replicated to increase their
availability. Replicating the CDS Server and Security Server provides a master
of each type of server and several read-only replicas. If the database of the
master CDS Server is changed, the databases of the read-only CDS servers are
updated automatically. Likewise, if the database of the master Security Server
is changed, the databases of the read-only Security servers are updated
automatically. Normally, multiple DTS Servers are used to ensure that the
failure of one DTS server does not interfere with the synchronization of clocks
in a DCE cell.

Systems as DCE clients: In addition to the DCE servers, a DCE cell includes
other machines running systems that take part in the DCE cell to benefit from
DCE core services. These machines are configured with the DCE client services,
which enable systems such as CICS regions and Encina servers to run as
clients of the DCE Servers.
All machines in a DCE cell run the DCE client services, which provide the
following DCE clerks. (A clerk is a DCE program that runs unattended to
provide a standard DCE client service.)
An RPC daemon
Enables DCE RPCs to be used for communications between operating
system services on the machine and DCE servers and services on
other machines. The DCE RPC daemon uses the endpoint map
database to identify servers on its machine.
A CDS clerk
Accepts requests from systems on the machine to store or retrieve
CDS information and sends requests to the CDS Server for processing.
The clerk caches the results of retrieved requests to avoid repeat
requests to the CDS Server.
A Security clerk
Verifies that the Security Server is authentic, manages the machine
principal, and certifies login contexts.
A DTS clerk
Keeps the machine’s local time synchronized with other machines in
the DCE cell by regularly asking one or more DTS Servers for the
correct time. If necessary, the DTS clerk adjusts the local time to the
correct time returned by the DTS Servers.
Figure 15. Distributed Computing Environment (DCE)
Each system is predefined with the minimum protection level of authenticated

RPCs for any principal communicating with it. For example, if a CICS region

uses an authenticated RPC created with a protection level below the minimum
defined for an SFS server, it cannot access that server.
Example configurations
The following sections illustrate some example configurations for CICS and
Encina.
A simple CICS configuration: A simple distributed CICS environment has a

CICS client on one machine and a CICS region on another machine, as shown
in Figure 16. This configuration is recommended for first-time CICS
installations because it is the easiest to install, test, and maintain.
Figure 16. A simple distributed configuration using CICS in a non-DCE cell environment
The example configuration shows CICS in an RPC-only environment. In an

RPC-only environment, internal CICS security and directory services are used.
The DCE RPC for endpoint mapping and transmitting transactional data is
the only DCE service used. DCE security services can be used if provided, as
described in “A simple CICS configuration within a DCE cell”.
The example configuration shows the following:

v The SFS server is used for CICS region files and queues, and can be used to
store user data.
v Communications between the CICS region and the SFS server use DCE
RPCs provided by the DCE RPC daemon. Other DCE client services are not
used.
v The CICS client provides immediate 3270 and program access to the CICS
region.
A simple CICS configuration within a DCE cell: A simple distributed CICS

environment within a DCE cell consists of a client on one machine and a CICS
region running on another machine, as shown in Figure 17 on page 38. This
configuration

requires the DCE CDS and DCE Security Services to be installed on machines
in the DCE cell.
Figure 17. A distributed configuration using CICS in a DCE cell environment
The example configuration shows the following:

v Server location and security services are provided by DCE.
v The SFS server is used for CICS region files and queues, and can be used to
store user data.
v The DCE RPCs used to communicate between the CICS region and the SFS
server can be authenticated by the DCE Security Server.
v The CICS client provides immediate 3270 and program access to the CICS
region.
Note: The CICS client machine does not have to be part of the DCE cell,
unless it also runs a CICS region that uses the DCE cell services.
A simple Encina Monitor configuration: A simple Encina Monitor

configuration, shown in Figure 18 on page 39, has a Monitor cell containing
the following:
v A cell manager, which coordinates the activity of node managers in the cell
v A node manager, which controls the activity of all servers running on the
node (machine)

v A Monitor application server, which provides the business logic of an
Encina application and acts on data stored in an SFS server
v A Monitor client, which provides the presentation logic of an Encina
application
The Monitor cell is part of a DCE cell, which contains another machine on
which the DCE CDS and DCE Security Services are installed.
Figure 18. A simple Encina Monitor configuration
Server location and security services are provided by DCE. The DCE RPCs
used to communicate between the Encina servers and client can be
authenticated by the DCE Security Server.

TXSeries environments
TXSeries is based on the transaction processing environments of CICS and

Encina. Both CICS and Encina can be used in the same network, and both
share components and underlying architecture. In particular, both use DCE to
support the distribution of function and resources across multiple machines.
This section provides an overview of a CICS and Encina processing
environment.
CICS transaction processing environment
The CICS transaction processing environment, shown in Figure 19 on page 41,

is based on one or more CICS regions. A CICS region provides the transaction
processing services that are convenient to manage as a single administrative
unit. These services typically support the business logic of user applications,
running as transactions requested by CICS client applications and 3270
terminal users. A CICS region contains a pool of application servers, which are
multithreaded processes that can handle either single or multiple client
requests for services. Application servers allow parallel processing without the
administrative overhead of running several identical CICS regions. The CICS
region automatically allocates client requests to the application servers.

Figure 19. The CICS environment
In addition to CICS regions, a CICS environment contains the following:

CICS clients
A client can use parallel sessions with multiple CICS regions. Each
CICS region automatically determines the type of device being used,
creates (autoinstalls) an appropriate session, and dynamically
monitors the state of connections. If a session fails, the server can
automatically reconnect the client.
Client machines can be workstations that present a graphical user
interface to CICS or simply devices, such as automated teller
machines (ATMs) and bar-code readers, that use 3270 data streams to
communicate with CICS regions.
Resource Managers
A CICS region can store its system and user files and queues in an
SFS server or in a DB2 database. If an SFS server is local (on the same
machine as a CICS region), the administration of both can be
coordinated by using CICS facilities; for example, the SFS server can
be started and stopped automatically when required. An SFS server
can also be remote. Application programs running on a CICS region

can use embedded SQL calls to access data in SQL databases, such as
IBM DB2, Microsoft SQL Server, Oracle, Sybase, and Informix.
Each machine on which a CICS region can be started has a CICS permanent
database, which stores configuration details for the CICS regions. This
information includes resource definitions that define the initial characteristics of
the CICS regions and any resources, such as transactions, programs, and files,
that they use. When a CICS region is started, it loads the resource definitions
it needs into its runtime database. While a CICS region is running, it uses its
runtime database to control its processing, to track changes to its resources,
and to add new resources dynamically.
User applications can be distributed across multiple CICS regions without

users and application programs being aware of the distribution. A user can
request a transaction from a CICS region and leave it up to CICS to determine
which program to run and on which CICS region to run it. The resource
definitions identify the location and other parameters needed. An application
program can be moved from one CICS region to another (for example, to
other CICS platforms) without user applications needing to be changed.
The only DCE service required by CICS is DCE RPCs, which CICS regions use
to communicate with SFS servers, other CICS regions, other servers, and CICS
on Open Systems clients. Outside a DCE cell, the security and name services
are provided by the CICS regions. To take advantage of the centralized DCE
security service and name service, it is recommended that CICS production
environments be run in a DCE cell.
Communications within a CICS environment can use TCP/IP and SNA.

TCP/IP is provided by the operating system or communications products on
the machines on which CICS runs. TCP/IP communications within a DCE cell
use PPC TCP/IP, but CICS can also use CICS family TCP/IP to communicate
with clients and other systems outside a DCE cell. A CICS region can use local
SNA directly (on the same machine) or indirectly through a PPC Gateway.
Encina Monitor transaction processing environment
As shown in Figure 20 on page 43, the Encina Monitor transaction processing

environment is based on the Monitor cell. A monitor cell is a collection of
nodes (machines) running Encina servers that are managed by one
coordinating server called a cell manager. The nodes are connected by one or
more local area networks, with potentially one or more wide area network
connections to other Monitor cells. A cell consists of a collection of nodes that
is convenient to manage as a single administrative unit.

Figure 20. The Encina Monitor environment
Each Monitor cell has one cell manager, which coordinates the activity of
servers in the cell by communicating with node managers. Each node manager
controls server activity on a managed node.
In addition to cell and node managers, a Monitor cell contains the following:
Monitor clients
A Monitor client is the portion of an Encina application through
which users interact with the Monitor cell. Monitor clients make
requests for services provided by Monitor application servers. Monitor
clients can run on any node, including nodes that are not managed by
the cell manager.
Monitor application servers
A Monitor application server is the server portion of an Encina
application. Monitor application servers provide the services
requested by Monitor clients. A Monitor application server contains
one or more processing agents (PAs), which are multithreaded processes
that can handle either single or multiple client requests for services.
Monitor application servers must run on managed nodes.
Processing agents allow parallel processing without the administrative
overhead of running several identical Monitor application servers. A

single Monitor application server with several processing agents need
only be configured and started once, and its processing agents can be
administered as a unit. The Monitor automatically allocates client
requests to the processing agents.
Resource Managers
A resource manager is a server that manages a shared resource, such
as application data. A Monitor application server can store files in one
or more SFS servers and store queues in one or more RQS servers.
Application programs running on a Monitor application server can
use embedded SQL calls to access data in SQL databases, such as IBM
DB2, Microsoft SQL Server, Oracle, Sybase, and Informix.
A cell manager tracks cell contents and activities by storing and continually
updating information about servers running in the cell. It maintains this
information in its cell repository, which can be administered from any machine
in the Monitor cell.
A Monitor cell is a subset of a DCE cell, which can contain multiple Monitor
cells. Servers and clients in a Monitor cell make use of the DCE RPC, security
service, and name service.
Communications within an Encina environment can use TCP/IP and SNA.

PPC TCP/IP is provided by the Encina PPC Executive and builds on the
TCP/IP provided by the operating system or communications products on the
machines on which Encina runs. An Encina server can use local SNA directly
(on the same machine) or indirectly through a PPC Gateway.
TXSeries facilities
The following sections discuss the general services provided by TXSeries.

Each is summarized here and detailed in the remaining chapters of this book.
Transaction processing
TXSeries provides the transaction processing facilities that enable application

programs to be implemented as transactions. The work of many users can be
processed at the same time, by a single server or by multiple servers in a
distributed computing environment. To users, TXSeries provides seemingly
dedicated processing of their work, with the security of access, reliability of
data update, and other benefits that transactions provide. It hides the
complexity of the facilities from user applications by providing standard APIs.
These facilities include the following:
Scheduling tasks
Controlling the rate and order in which tasks are processed to give

higher-priority tasks the best response times and to adapt to the
availability of application servers and other system resources
Managing system resources
Maintaining a pool of operating system resources to be used for
transaction processing, loading application programs, and acquiring
and releasing storage
Monitoring tasks
Monitoring the progress of tasks, suspending those waiting for input,
adjusting task priorities, and resolving problems
Managing task data
Getting data needed by tasks, coordinating resource managers (such
as file servers and database managers), locking data for update, and
logging changes
Managing communications
Monitoring communications with users and between servers and
other systems, starting communications sessions as needed, managing
data handling and conversion, and routing data to the right
destination
Time management
Managing transaction processing in relation to the passage of time,
starting tasks at predefined times, logging the date and time of events
onto disk, and regularly controlling part of the business system to
provide degrees of automation
Data management
Business applications must not lose or corrupt their data. TXSeries preserves
data integrity by keeping track of updates and ensuring that they are
committed in a consistent way across the entire network.
TXSeries provides extensive data-management services that enable reliable

processing of data in a global dynamic business environment. It helps keep
shared disks up-to-date, backed up in case of damage, and fully accessible at
all times. It performs careful logging and tracking to ensure that many users
can access and change the same data apparently at the same time.
Applications do not need to know where data is located; they make simple
calls for data, and servers determine where to find the data. This provides
flexibility in the distribution of data.
TXSeries manages data being passed around the business information system,
finding storage for the data while it exists and then relinquishing that storage
for reuse when the data has been processed.

TXSeries provides extensive support for files, queues, and databases, as
follows:
v Files can be fixed- or variable-length. They can be entry-sequenced
(sequential), relative (organized by their relative slot number), or clustered
(organized in a hierarchical tree and indexed with multiple indexes).
Clustered (indexed) and sequential files offer a limited form of database
functionality. These file types are processed by servers, which read from
and write to user-defined files, gather statistics, acquire dynamic storage for
I/O operations, and manage the buffers and blocks used. The main access
method is an emulation of the standard Virtual Storage Access Method
(VSAM), which is used widely by transaction processing systems.
v Queues support the dynamic nature of transaction processing and offer
flexibility in application construction. In CICS, queues provide scratchpad
support, asynchronous communications between applications, transaction
batching, general data storage, and many other capabilities.
v Databases offer the greatest degree of data independence. You can share
them between TXSeries applications and other programs with equal
freedom for both access and update and with full database integrity.
Applications can access databases either directly, by embedding SQL calls
within the application code, or indirectly through interfaces to database
managers.
CICS also supports journals, which are special files used to record data needed
to reconstruct events or changes to data; for example, as an audit trail or aid
to transaction recovery. Automatic journaling can be used for files to write
records to a specified journal if a record is read for update, a new record is
added, or an existing record is deleted.
Communications
Users interact with TXSeries through clients, which communicate with servers
(CICS regions and Encina servers) for transaction processing services. The
servers, in turn, can communicate with each other and with resource
managers (such as SFS servers and RDBMSs) and other systems to provide a
full range of services.
TXSeries manages all aspects of communications for users and applications in

a distributed system. It enables:
v Multiple users to access TXSeries without interfering with each other.
TXSeries ensures that data is routed to the intended user in a form that can
be displayed by the user’s device or handled by the user’s application
program.
v The functions of TXSeries to be distributed across a number of servers,
while providing optimum service for business applications.

v Communications among servers to share data, resources, and work, thereby
providing a more flexible business service and better use of resources.
v Clients (user workstations and other devices) to communicate with servers
from anywhere, from numerous types of devices, and from the Internet.
v Other systems (transaction processing and non-transaction processing) to
make use of the TXSeries and, in turn, to be used by the TXSeries.
Communications in a TXSeries environment can use TCP/IP and SNA. To

provide network-transparent system-to-system communication, RPCs can be
used; for example, for communications between CICS regions and an SFS
server, and between servers in an Encina Monitor cell.
Each server can use multiple, parallel communications sessions with other
systems (clients and servers). The server monitors all sessions for activity so
that no user is left waiting for access.
In a CICS region, servers can use a variety of methods to communicate with

other servers, as follows:
v They can route transactions to other servers, either predefined or
dynamically determined.
v They can ship functions requested by transactions to other servers.
v The can link application programs to programs on other servers.
v They can start transactions on remote servers, for asynchronous processing,
at the request of local transactions.
Servers can also communicate by using the following:

v High-level Advanced Program-to-Program Communication (APPC),
enabling programs to interoperate with other APPC programs
v Message queueing, as provided by IBM MQSeries products
Before a system can communicate, it must identify the remote system and
then make a connection to that system. The remote system must advertise
itself, making available binding information needed to make the connection.
This is provided by a name service, either by the CDS of a DCE cell or, in a
CICS environment, by each CICS region. Communications between systems
can be made secure, again centrally by DCE or by using services provided by
individual CICS regions.
Any network can be subject to network or system failures. To overcome this,

TXSeries uses a form of acknowledgment processing that uses the three
synchronization levels defined by SNA.
Systems that store data in Extended Binary Coded Decimal Interchange Code
(EBCDIC) can transfer data with other systems that store data in American
Standard Code for Information Interchange (ASCII). For example, data can be

transferred between a CICS for Open Systems (ASCII) region and an IBM
mainframe-based CICS (EBCDIC) region. To enable this, data conversion is
used.
Security
Protecting a business information system is a vital requirement, both to

prevent unauthorized people from using the system and to ensure that users
access only the resources that they are permitted to use. TXSeries protects the
systems, transactions, data, and other resources used by applications. The
general TXSeries security concepts are shown in Figure 21.
Figure 21. General security concepts
To start using a system, a user provides a user identifier (userid) and password
to prove the user’s identity to the system. This process, which can be
automatic (and hidden from the user), is known as authentication.
After authenticating, users still need permission to access system resources. To

access a resource, a user must have permissions on the ACL of the resource.
The process of checking for permissions to access a resource is known as
authorization.
Another way to protect a distributed system is to enforce secure

communications between systems. Systems can verify the identity of the remote
systems, set protection levels required for communications, and assign special
userids and passwords for communication across connections. Communication
using authenticated RPCs can be checked for tampering and encrypted for
privacy. CICS regions can send userids on communications with other CICS
regions and can make use of encrypted bind flows for SNA communications.

DCE can be used to provide security based on DCE cells. A DCE cell is a
group of machines that work together, are administered as a unit, and share
the same DCE services. Within a DCE cell, a Security Server provides a
centralized security service and use of authenticated RPCs.
CICS also provides its own security services to provide authentication of users
and authorization for their access to transactions and other resources. CICS
internal security services provide a basic alternative to DCE security. These
services can make use of user-written or vendor-supplied external security
managers to enhance or replace the basic CICS internal security.
In addition, client workstations can provide extra security by using standard

security facilities like Web security services.
Application development
TXSeries simplifies or hides many aspects of program design; for example, by

removing the need for programs to obtain system resources for themselves.
This helps keep transaction processing programs similar to traditional
programs and minimizes the impact of special-design challenges on the
application programmer. Special system configuration options push the
complexity down to a lower level, where it is handled by special-purpose
systems management tools and packages.
The TXSeries APIs enable application development in a consistent style that is

independent of the programming language used and the underlying
functionality of the operating system. TXSeries functions are used to extend
the functions of the operating system.
A wide range of development tools for both client and server application
segments is available for use with TXSeries, from IBM and other vendors. In
addition, TXSeries supports the development of object-oriented applications
that are based on DCE, CORBA, or a mixture of both.
TXSeries has evolved out of the well-proven CICS and Encina products and
their associated technologies. Application programs can use the standard CICS
and Encina application programming interfaces to run on hardware ranging
from personal computers to mainframes without needing major change. This
means that existing applications and programming skills can be used,
protecting and building on your investment.
Systems management
Any computing environment, whether it is one machine or several distributed

machines, needs to be managed. The general systems management tasks
involved are common to all environments. In a distributed environment,
especially one containing different types of systems, the systems management
challenge is greater. The ideal is to provide a single point of control from which
all the systems can be managed. This requires a common systems
management tool, or some means by which different systems can be managed
remotely by using their own management tools.
TXSeries provides an evolving set of tools for general management of its

component systems. These tools can be used remotely for centralized systems
management.
TXSeries also provides a range of services to help automate systems

management, including the following:
Abnormal and exception handling
Handling of abnormal conditions at an application level and system
level. At an application level, this handling includes rerouting
applications and their work, application recovery and restart, and
orderly termination with diagnostics. At a system level, these services
prevent serious system problems from developing, enable you to
handle problems that develop, and help to provide a high level of
system availability and reliability.
Event monitoring
Automatic notification of events affecting systems and resources.
Recoverability
Automatic recovery of work in progress and recovery of systems after
machine or system failure.

Part 2. More about TXSeries facilities
This part contains details on the facilities provided by TXSeries. It contains the
following chapters:
v “Chapter 4. Transaction processing” on page 53
v “Chapter 5. Data management” on page 67
v “Chapter 6. Communications” on page 89
v “Chapter 7. Security” on page 117
v “Chapter 8. Application development” on page 137
v “Chapter 9. Systems management” on page 155
v “Chapter 10. Component planning” on page 171
v “Chapter 11. Configuration planning” on page 183

Chapter 4. Transaction processing
This chapter describes the transaction processing facilities and resources used
by TXSeries. It contains the following topics:
v “What is a CICS region?” describes what makes up a CICS region when it
is stopped and when it is running.
v “General transaction processing services” on page 61 describes the services
provided by a CICS region.
TXSeries controls the processing of transactions in a business system, even

when the transactions are working concurrently on different computers and
accessing the same data. User application programs do not need to perform
the specialized task scheduling and control, and data routing and locking
required by transaction processing.
Transaction processing services enable application programs to concentrate on

business logic and not on how the logic is implemented. These services are
implemented by CICS regions to provide each user with a single-user view of
the transaction processing system while maintaining data integrity and
optimum performance for many concurrent users.
The services used to run CICS regions are in many cases the same services as
those used to process user transactions.
What is a CICS region?
This section describes a CICS region in two stages:

1. “When a CICS region is stopped” on page 54
2. “When a CICS region is running” on page 55
Note: Although this section describes a CICS region running on Windows NT,
the descriptions of resources and startup and shutdown procedures are
similar for CICS regions running on other platforms. Where
appropriate, NT-specific descriptions are noted.
In this chapter, figures are simplified to show only facilities related to the
CICS region; typically there are other facilities related to other active
applications.

When a CICS region is stopped
Figure 22 shows a stopped CICS region.
Figure 22. Machine with a CICS region not running
CICS permanent database

Each machine on which a CICS region can be started has a permanent
database of CICS resource definitions. You create these resource
definitions to define the attributes of CICS regions that can be started,
the regions’ resources, and other functions that the regions use. For
example, you create a region definition to define the name and
attributes of a CICS region. This defines, among other things, the
number of application servers that the CICS region is to be started
with. Each user program that the CICS region can run is identified by
a program definition related to the region definition.
Note: The CICS permanent resource definitions are so called to

distinguish them from resource definitions used when a CICS
region is running. The permanent resource definitions must be
created before a CICS region can be started. When a CICS
region is started, it typically loads a subset of the permanent
resource definitions to use while it is running. Those resource
definitions are referred to as runtime resource definitions.
Libraries
The CICS region is implemented as a number of system programs and
runs user application programs, all of which exist in libraries on the
machine. On Windows NT, these are dynamic link libraries. On AIX

and Solaris, these are loadable files. The CICS programs are installed
as part of the TXSeries installation procedure.
Services and subsystems
On Open Systems and Windows NT, CICS regions and SFS servers are
run as a special category of program. On AIX, this category is known
as a subsystem. Subsystems are managed by the System Resource
Controller. On Windows NT, the category is known as a service.
Services are managed by the Windows NT Service Control Manager.
On other Open Systems platforms, the concept of a subsystem does
not exist as part of the operating system and the System Resource
Controller function is emulated by CICS.
On both Open Systems and Windows NT, programs running as
services or subsystems can run concurrently.
On Windows NT, the Control Panel Services applet displays a list of
services. (Note that CICS regions and SFS servers cannot be started
and stopped from the Services applet.)
Event log (Windows NT only)
On Windows NT, CICS records the starting, stopping, and other
significant events for its services in the Windows NT event log.
Consequently, the event log is a good starting point for identifying a
problem. Other applications (for example communications products,
relational databases, and the NT operating system itself), also record
information in the event log. As other applications may be influencing
the behavior of CICS, the event log is particularly useful. The event
log on one machine can also be used to view events on another
machine and can therefore assist in remote identification of problems.
When a CICS region is started, it begins an initialization process; when the

process completes, the region is in a running state. The running state of a
CICS region is outlined in “When a CICS region is running”, and the
initialization process is outlined in “The life cycle of a CICS region” on
page 59.
When a CICS region is running
Figure 23 on page 56 shows a CICS region that is running on a Windows NT

machine.
Chapter 4. Transaction processing 55

Figure 23. Windows NT machine with a CICS region running
Runtime resource definitions

Each CICS region is defined (by a permanent region definition) with a
list of resource groups that it can be started with. When the CICS
region starts, resource definitions in the groups are loaded into the
CICS region as runtime resource definitions. Runtime definitions exist
between CICS region instances and are reloaded when a region is
auto-started. They are maintained on disk in the same way as the
permanent resource definitions. Runtime definitions can be operated
on independently from their related permanent resource definitions.
For example, you can alter the runtime attributes of a transaction
without affecting its permanent resource definition.
Windows NT services
A CICS region runs as one Windows NT service for its own

processing functions. It also uses other Windows NT services for its
application servers. The CICS region consists of several internal
processes supervised by a monitor process. The monitor process
handles all the Windows NT service requests to start and shut down
the CICS region. The actual function of a CICS region is controlled by
a main process. The main process coordinates the parallel running of
the following:
v Application Server Manager. This controls the creation, running, and
termination of application servers. It has a pool of application
servers, with a predefined maximum possible number and a
minimum number to be kept available. It monitors a shared
memory queue for transactions to be started and for new
transactions waiting for an available application server. If an
application server is available, it runs the transaction on the
application server. If there is no available application server, and the
maximum number possible has not been reached, it creates a new
application server to run the transaction. If the maximum number
of possible application servers is active, the transaction is queued
and retrieved automatically by the next application server to
become free.
v Listeners. A remote procedure call (RPC) Listener is used to monitor
incoming Distributed Computing Environment (DCE) RPC requests.
If the listener detects an incoming transaction request, it places the
request in a shared memory queue monitored by the Application
Server Manager. A CICS region can also be configured to run other
listeners—for example, those listening for local Systems Network
Architecture (SNA) requests, over Transmission Control
Protocol/Internet Protocol (TCP/IP) or a named pipe.
v A Log Manager. This writes checkpoint data to the CICS region log.
The data is used to minimize restart time and to help diagnose
problems.
v A Recovery Manager. During system startup, this reads the CICS
region log and creates a Recovery Server for each in-doubt
transaction that it finds. For more information, see “Recovery
during restart” on page 60.
v Interval Control Manager. This controls the starting of user and
system transactions at user-specified times. When a time-triggered
request occurs, the Interval Control Manager adds it to the shared
memory queue monitored by the Application Server Manager.
If the main process terminates abnormally, the monitor process cleans

up by ending any remaining CICS region processes and removing any
lock files and shared memory segments.

Operating system memory
A running CICS region is an area of operating system memory into
which CICS system programs have been loaded (and run), with other
memory allocated for the CICS region to use.
System shared segment
This is used to store runtime resource definitions and
information needed to manage the CICS region. This data is
used by many of the CICS region processes, so CICS
synchronizes access to the data.
Shared text segment
This contains the shared system libraries used by the running
CICS region. User application code, if link-edited
appropriately, can be located here; otherwise, it is located in
the process data segment.
Process data segment
This contains data local to an application server—for example,
input and output parameters for all CICS commands issued
by an application program running on the application server.
The application data is private (isolated from other application
programs). This makes the system more robust because an
application program in error cannot accidentally damage
memory belonging to another program. Application programs
that use this memory must be written so that they do not
stray beyond the bounds of their own data, and changes to
shared fields must be synchronized.
Task shared segment
This contains data to be shared among several application
servers.
Processor text segment
This contains the application server startup code.
System log
The CICS region records in its system log all events that occur while it
is running. For example, it records when a CICS client connects to the
CICS region and when a user logs on. The system log (in addition to
the Windows NT event log) can provide more clues about a problem
with CICS. For example, the system log can show that a specific
transaction was running and abended for some reason. Also, each
application server has its own log of events. The Recovery Manager
uses these logs to recover the work of an application server after a
failure.

The life cycle of a CICS region
This section contains an overview of what happens during the startup and
shutdown of a CICS region. It is based on a region that is predefined in the
CICS permanent database.
When a CICS region is started, the following takes place:

1. The startup request is passed to the Windows NT Services Manager, which
creates the CICS region monitor and main processes.
The initialization actions of the main process depend on whether you
requested a cold or automatic (auto) startup.
In a cold start, the startup of the region occurs without regard to any
previous region activity. CICS installs the permanent resource definitions
into the runtime database. For an automatic startup, CICS starts the region
according to its state at the last shutdown. This results in either of the
following:
v A cold start, if you have not started the region before. When a region is
cold started, CICS installs (copies) the permanent definitions into the
runtime database. While running, a CICS region can use the resources
defined in the runtime database.
v A warm start, if the region terminated with a normal shutdown. When a
region is warm started, the permanent database is not copied into the
runtime database. Instead, CICS uses the definitions from the previous
CICS instance (already in the runtime database).
v An emergency restart, if the region terminated with an immediate
shutdown or abnormally. When a CICS region performs an emergency
restart, the permanent database is not copied into the runtime database.
Instead, CICS uses the definitions in the runtime database and performs
recovery processing as outlined in “Recovery during restart” on page 60.
The main process also obtains the operating system memory that it needs.
2. The main process starts the RPC listener and, if the system was predefined
appropriately, one or more Transmission Control Protocol/Internet
Protocol (TCP/IP) listeners, the SNA listener, the named-pipe listener
(used for local 3270 terminals), and the LU0 listener. (The LU0 listener is
supported on Windows NT only.)
3. The main process establishes connections to the relational databases that it
is to use.
4. The main process creates the following management processes:
v The Log Manager, which opens the system log and waits for a request
to write the first checkpoint.

v The Recovery Manager, which reads the system log and any application
server logs from a previous run of this system, and creates a Recovery
Server for each in-doubt transaction that it finds.
v The Application Manager, which creates the minimum number of
application servers predefined in the region definition. It maintains this
minimum number while the CICS region is running.
v The Time Service starts itself and waits for the first timed request.
5. The CICS region runs some internal CICS transactions and writes a
checkpoint to the system log. Then it registers a profile entry with the
DCE Cell Directory Service (CDS) Server. This enables CICS clients to see
the system in a list of available systems and to send transaction requests to
it.
The CICS region is now started and is able to run user transactions. If any
errors occur during startup, the system generates an error message so that
appropriate action can be taken.
Recovery during restart
When a CICS region starts up after a previous shutdown, the CICS region
performs recovery processing to return the region to the same state that it was
in when it was last shut down. The CICS region automatically decides
whether to perform a warm start (following a normal shutdown) or an
emergency restart (following a system failure). You can force a cold start (in
which the system log is reset during initialization), but data integrity
problems can occur—for example, from in-doubt transactions not being
recovered.
During a restart, the system data loaded into operating system memory
during the previous run is used. For example, the resources in the runtime
database are used (and not reloaded from the permanent database).
Recovering the state of recoverable resources after a system failure requires an

external record of all the work that needs to be redone. For this purpose, CICS
is configured to periodically take checkpoints of the states of all recoverable
resources. On restart, CICS reads the checkpoint to reestablish the states of the
recoverable resources at the time the checkpoint was written, and then
processes all relevant information held for the region. You can control the
frequency with which checkpoints are taken.
The emergency restart procedure is as follows:

1. The Recovery Manager opens the system log.
2. The latest checkpoint is read.
3. A list of global transaction identifiers is built from checkpoint data.

4. The Recovery Manager opens each log owned by the application servers
and determines what recovery is needed, as follows:
v It does not recover transactions that were active but not in doubt.
v It creates a Recovery Server for each transaction that was in doubt.
5. Each Recovery Server opens its own log and, depending on the
transaction’s state, does one of the following:
v If the transaction is prepared and committed, the Recovery Server
awaits ″finished″ responses from its subordinate transactions. When
these responses are received and logged, the Recovery Server
terminates.
v If the transaction is prepared, the Recovery Server awaits an outcome
from the coordinator of the transaction. When the outcome arrives, the
outcome action is taken and the Recovery Server is terminated. When
X/Open XA-compliant databases are in use, the outcome is also passed
to the database by using the XA protocol.
The Recovery Manager terminates Recovery Servers that have completed

their work. When all Recovery Servers are terminated, the Recovery
Manager also terminates.
General transaction processing services
The processes in the CICS region cooperate with other servers, such as
resource managers and security managers, to provide a complete transaction
processing environment. The region forwards to other servers the work that
they are best able to do, but provides other services to coordinate the function
of the multiple servers. For example, it passes requests to update data to SFS
servers and relational databases, but provides extra data management services
to ensure that updates are synchronized.
This section provides more information about the following general

transaction processing services:
v “Task management” on page 62
v “Performance optimization” on page 62
v “Workload distribution” on page 63
v “Program management” on page 63
v “System resource management” on page 63
v “Controlling access to and updating data” on page 63
v “Data communication” on page 64
v “Terminal management” on page 64

v “Time management” on page 64
v “Security management” on page 64
v “Recovery management” on page 65
Task management
Task management services control the creation, processing, and termination of

tasks. Whenever possible, the CICS region provides the best response times to
the most important or urgent work. Usually, several tasks are competing for
processing time, so the CICS region determines the priority. At any time there
are likely to be many tasks to be performed concurrently, all requiring use of
the same resources. The region schedules and dispatches tasks according to
their relative priority and the availability of application servers and other
system resources. This controls the rate and order in which tasks are
processed, thereby minimizing the chances of conflict or system overload.
Because transactions are not normally processed through to completion in one

uninterrupted operation, the CICS region calculates the priority several times
during the lifetime of a task. For example, a task can be processed until it
needs input from a file or a user. The CICS region suspends the task, awaiting
its input, and starts a new waiting task or resumes work for another
suspended task.
You can control the number of tasks running concurrently in a CICS region by
using transaction classes. You can assign certain types of transactions to a given
transaction class and limit the number of tasks that can run for transactions in
that class.
Performance optimization
User tasks (for example, adding a new employee to a payroll file) are usually
simple and do not take very long. However, the tasks are often interrelated
and share the same programs and data. Furthermore, users want short
response times. CICS regions enable the users’ work to be done most
efficiently by managing the use of operating system processing time,
resources, and access to data. A CICS region continually monitors the work to
be done and the state and performance of the operating system. It forwards
the optimum selection of work to the operating system and ensures that work
throughput is maximized. The workload can be balanced across multiple
regions to further enhance the performance of the entire system. Besides the
automatic monitoring and adjustment of work and resources, CICS regions
collect data about system performance and provide functions and interfaces
for tuning them.

Workload distribution
You can distribute transactions across multiple CICS regions to spread the
workload across those regions. You can predefine whether a transaction
request is to be served locally (on the CICS region that received the request),
routed to a specified remote region to be run there, or routed dynamically to
any region that can run the transaction.
Program management
Program management services are used to associate a task with the application
program that is to do its work. Although many tasks can need to use the
same application program, program control loads only one copy of the code
into memory. Each task threads its way through this code independently, so
many users can run tasks concurrently using the same physical copy of an
application program.
If a task involves many interactions with the user (for example, for data to be
input), it is usually implemented as a number of programs that run in
sequence and end before the next program starts. This technique is called
pseudoconversational programming. When each program ends, it displays a
screen for the user to input data. The CICS region remembers which program
to run next to process the input, but releases the memory used by the task
and the program that ended. If that program was not being used by other
tasks, the region also reuses the memory used to hold the program. So, while
the CICS region is waiting for a user to input data, the system resources are
freed to be used by other tasks. However, the user is unaware of the program
ending and can continue to communicate with the system, almost like a
conversation.
System resource management
A CICS region frees application programs from having to negotiate with the
operating system to acquire and release resources. Each task being processed
uses processor cycles, processor memory for the programs doing the work,
and memory for the task and user data. It needs small areas of memory for
scratchpad-type calculations and, sometimes, it needs data-communications
channels, data files, and databases. For all these, the region gets the resources
needed from the operating system. It then allocates the resources to the tasks
that need them. It reacquires the resources when the tasks complete their
processing or specifically release a resource.
Controlling access to and updating data
A CICS region enables many users to share the same data. It controls the
simultaneous access to resource managers, even across multiple machines and
platforms, and preserves the integrity of data updates. For example, it

synchronizes updates, logs changes, and recovers in-doubt updates. It can also
use security services to ensure that only authorized users can access and
update data.
Control of data access and updates by a CICS region enables application

programs to implement the business logic without needing code to interact
with the data managers. When a task’s program requests data, the CICS
region determines the appropriate data manager and retrieves the data for the
program. When a task finishes, the region releases the resources given to the
task for use by other transaction processing tasks or other programs.
Data communication
To enable many users to work at the same time, a CICS region must minimize
the users’ wait time. It uses data communication services to recognize which
user has sent a particular message and to send data to the correct user. The
region also ensures that display data is sent in a way that is compatible with
the user’s device. The CICS region does this by monitoring all communication
sessions with users, managing all the data handling and transmission, and
finding and releasing memory for the data to be worked on.
Terminal management
Terminal management provides device-independence that enables applications

to communicate with any type of terminal in one standard way. The CICS
region queries the users’ devices and determines the optimum characteristics
to use for application output. The region can use models to influence its
choice of characteristics and can use terminal definitions to apply specific
characteristics to devices.
Time management
Time management services enable programs to start and control a range of

time-dependent operations—for example, starting a transaction (task) at a
certain time of day and signalling when a specified time period has elapsed.
These services also enable date- and time-stamped events to be logged to disk
for accounting purposes or to ensure data integrity, and they enable a degree
of automation for the CICS region.
Security management
A CICS region provides security against unauthorized logon, and protects

individual resources (programs, files, and so on) from use by all but certain
users. The security management services provide the data needed for the
checks, which are performed by CICS internal security, an external security
manager, DCE security services, or by some combination of these.

CICS regions can use DCE security services for centralized authentication and
authorization of users who want to use transaction processing services. CICS
provides its own internal security services that are a more basic alternative to
DCE security. It also provides interfaces to special-purpose external security
packages to manage all aspects of system security. Encina uses DCE security
services or (if running without security) the base security services of the
operating system. TXSeries security services are described in “Chapter 7.
Security” on page 117.
Recovery management
A CICS region ensures that the business system and its data are always in a
consistent state. In the event of an application or system failure (for example,
if there is a power loss and the computer system shuts down), the region can
automatically restart itself (if needed) and recover any uncompleted work that
was in progress at the time of failure, including any changes to data. If it
cannot commit data changes for a task, a region dynamically backs out the
changes to a point when the system was last in a consistent state.
Transaction processing recovery services are based on the following:

Logical units of work (LUWs) and synchronization points
These provide records of the last committed changes made by a
transaction.
Transaction logging
While a task is in progress, the CICS region logs information about
changes that it makes to recoverable data. The logged information
indicates uncommitted changes to data made since the last syncpoint.
Dynamic transaction backout
If a task fails to complete, the CICS region uses its logged
information, and information recorded by resource managers, to
reverse uncommitted data changes. This restores recoverable data to
its previous committed state.
User journals
User journals record information for recovery functions not provided
by the CICS region, such as an audit trail. You can write applications
to use any of the user journals.

Chapter 5. Data management
This chapter describes the facilities of TXSeries for managing data. It covers
the following topics:
v “An introduction to data management”
v “Types of data” on page 68
v “Files” on page 69
v “Queues” on page 73
v “Relational databases” on page 82
v “Journals” on page 85
v “Considerations for sharing and distributing data” on page 86
An introduction to data management
Transaction processing systems provide users with timely, accurate, and

reliable access to data; for example, customer accounts. Such user data can be
in the form of files, queues, and database entries. (A transaction processing
system also uses data, called system data, to control its operation.)
The data can be provided by one or more resource managers: for example, a
Structured File Server (SFS) server; a Relational Database Manager (RDBM) such
as IBM’s Database 2 (DB2) or Microsoft SQL Server; or a queue manager, such
as the Encina Recoverable Queueing Service (RQS) or MQSeries.
This is illustrated in Figure 24 on page 68.

Figure 24. Data management services
Types of data
Data can be stored as the following:

v Files—data that is permanently stored until explicitly deleted.
v Queues—temporary data to process requests or to pass data from one task
or one program to another. Queues can persist over multiple executions of a
Customer Information Control System (CICS) region and can represent
permanent data.
v Relational databases—data stored in a special structure, dictated by the
RDBM, and accessed by structured query language (SQL) commands.
v Journals—sets of special-purpose files needed to recover data changes after
failures.
Data is a global resource available to one or more servers. Any task can read,
write, or delete data, and can share data with other tasks.
For data access, the most important difference between data stored in a
database and data stored in files or queues is the structure that the RDBM
imposes on the data. This structure dictates the application programming
interface to the data and determines how easy or hard it is to store and
retrieve the data for a particular processing requirement. If the data is
complex, the structure can be the overriding consideration.
A related difference is where knowledge of the data structure is stored. In a

database management system (DBMS), the logical structure of the data resides
in the DBMS. The physical structure is also there, but it is not tied directly to

the logical structure. Therefore, the physical structure can be changed
considerably without changing application code. In flat files, the logical
structure of the data is embedded in the programs using it, and logical and
physical structures coincide.
The differences in function between DBMSs and traditional file access

methods outside the application programming interface can be equally
important to your choice. DBMSs provide services and utilities for managing
recovery, sharing, and distribution that can be essential to your application. If
your data is voluminous, recovery and other management functions can
determine your choice. If you need to distribute your data, facilities for
managing the distributed data become crucial.
Files
Data in files is organized as a collection of records. (See Figure 25 on page 70.)

A record is a grouping of related information with a predefined size and a
predefined number and layout of fields. Each record in a file has the same
number and layout of fields, which hold specific parts of the record’s
information. For example, each record can contain information about a bank
account, with fields for the account number, a name, the balance, and other
information. The way the records in a file are arranged is called the file
organization.
A file has one primary index, which defines the physical order of records in the
file. A file can also have any number of secondary indexes that provide
alternative sequences in which the file’s records can be accessed. An index can
be seen as a list of pointers to records in a file, where the primary index lists
the actual order of the records, and each secondary index lists the pointers in
a different order. Application programs can read, update, add, delete, and
browse data in local or remote files.
TXSeries file services (provided by SFS) are like those provided by the Virtual
Storage Access Method (VSAM) data sets. If you are moving to CICS on Open
Systems from an IBM mainframe-based CICS platform, your application
programs can use the same file access commands as used for VSAM data sets.
Chapter 5. Data management 69

Figure 25. General file services
File organization
TXSeries file services support the following:

v Fixed-length and variable-length records
v Multiple access paths to the same file
v Large records that can span system boundaries (control intervals, disk
blocks)
v Record-level locking (or in the case of VSAM, control-interval locking)
Before a file can be used, you must define it. For example, a file definition is
used by CICS to identify the name and location of a file, and to automatically
define the file to the appropriate file manager. The file definition also defines
the file organization (its records and indexes defined in terms of their
constituent fields).
Each field can be fixed or variable length. A record can have only one
variable-length field, which must be the last field in the record.
The three file organizations and their equivalent VSAM terms are as follows:

Entry-sequenced
Entry-sequenced data set (ESDS)
Relative
Relative record data set (RRDS)
Clustered
Key-sequenced data set (KSDS)
Figure 26. File organizations
Entry-sequenced file (ESDS)
Records in an entry-sequenced file are stored in the order in which they are
written into the file. New records are always appended to the end of the file.
When records are deleted, the disk space they used is not automatically
reclaimed or reused; it can be reclaimed by reorganizing the file.
Entry-sequenced files are often used when the records are accessed in the
chronological order in which they were written; for example, for log files and
audit trail files. The primary index, which is stored separate from the file, lists
records in the order in which they were added to the file.
Records can be fixed or variable length. When an existing record is updated,

the updated record cannot be longer than its original length.

Relative file (RRDS)
A relative file is an array of fixed-length slots in which records can be stored. A

record can be added into the first free slot from the beginning of the file, at
the end of the file, or in a specified slot in the file. Records can be fixed or
variable length up to the slot size predefined to the file manager. You can
update or delete any record. Any slot freed when a record is deleted can be
reused by the insertion of another record in the free slot. The primary index is
physically part of the data in the record.
Clustered (KSDS)
A clustered file has each of its records identified by a key field in a predefined
position within the record. The keys need not be unique. The records in a file
are sorted automatically according to the value of their keys, to cluster records
with the same and adjacent keys. This reduces the cost of searching for ranges
of records.
Records in a clustered file do not have a numerical index as do

entry-sequenced and relative files. You can base the primary index on any
field or combination of fields. The records in a clustered file are ordered
according to the primary index. When you add or delete records, the file
manager automatically updates the primary index and, if needed, moves
records to maintain clustering. Disk space freed by deleting records is
automatically reused.
Primary and alternate indexes
A file’s primary index is used to access each record in the file by a unique
primary key. You can also define one or more alternate indexes, which enable
you to access the same set of records in different ways. For example, a
personnel file can have a primary index using the unique employee numbers
and an alternate index using employee names. You can then retrieve a record
by using either the employee number or name.
Adding files to an SFS server
To add files to an SFS server, you can either add each file interactively or use
schema file definitions, as follows:
v The interactive method (cicssdt) prompts you for the required attributes of
the file; for example, the file organization and the names and types of
fields. However, the file definitions are not stored, and so must be entered
again each time you want to add them. For example, if an SFS server is
cold started, all its files are discarded and must be added again.
v A schema file definition is a set of file and index specifications that can be
reused as required to add files to any SFS server.

Queues
Queues are sequential storage facilities, generally transitory in nature because

of the dynamic nature of transaction processing. They are typically used to
process requests or to pass data from one transaction to another as shown in
Figure 27. For example, data produced as part of a transaction is usually not
printed until well after its task has been completed; the data waits in a queue
for the print program to process it when there is no more urgent work to be
done.
Figure 27. General use of queues
A queue is a sequence of data elements identified by a symbolic name. Each

element contains record-oriented data of a type specific to the application that
is to process it. Elements of different types can be placed in the same queue.
For the general type of queue, transactions add (enqueue) elements to the tail
of the queue and remove (dequeue) elements from the head of the queue in a
first-in first-out (FIFO) manner. Each element must be read sequentially and
when read is removed from the queue. Queues support multiple simultaneous
requests to enqueue and dequeue elements, growing and shrinking in size
according to the volume of requests. A transaction can requeue elements to
another queue for alternative processing.
You can use some queues differently; for example, as a common scratchpad of
elements to be written, updated, read, and deleted by any transactions. You
can also dequeue elements in a different order from the order in which they
were enqueued.

CICS and the Encina Monitor implement queue services in different ways.
Each provides different functions that extend the general queueing concept,
and different methods of storing queues.
Before a queue can be used, you must define it. For example, a queue definition
is used by CICS to identify the symbolic name and type of a queue, and to
define the queue to the appropriate queue manager.
Figure 28 shows queues being used to support a telephone sales business

application. Each sales agent runs an application (on transaction server A) and
confirms sales to customers in real time to preserve critical response times.
Each transaction adds the data associated with the sale orders to queues for
later processing. The larger task of processing the order is split into billing,
shipping, and updating inventory applications. These applications run
separately from the initial order-taking application, as transactions on
transaction server B. These transactions dequeue the data that they are to
process.
Figure 28. An example use of queues
CICS queues
CICS supports the following types of queues:

v “Transient data queues” on page 75
v “Temporary storage queues” on page 78
Transient data queues provide the general queue functions. Temporary storage
queues are typically used for shared reading, writing, and updating by
multiple transactions; for example, as a scratchpad for shared data.

Some of the main differences between the types of queue are as follows:
v Transient data queues must be defined to a CICS region before it starts up.
In contrast, temporary storage queues can be created any time that an
application needs to write to a queue.
v Transient data queues must be read sequentially, and each element can be
read only once. (After a transaction reads an element, that element is
removed from the queue and is not available to any other transaction.) In
contrast, elements in temporary storage queues can be read either
sequentially or directly. They can be read any number of times and are
never removed from the queue until the entire queue is purged.
These two characteristics make transient data queues inappropriate for

scratchpad data but suitable for queued data such as audit trails and output
to be printed. In fact, for data that is read sequentially once, transient data
queueing is preferable to temporary storage.
Transient data queues
CICS provides the following types of transient data queues, illustrated in

Figure 29 on page 76.
v Intrapartition transient data destinations
v Extrapartition transient data destinations
v Indirect destinations
v Temporary storage queues
Application programs can write, read, and delete data in a transient data
queues, but cannot update such data.

Figure 29. CICS transient data queues
Intrapartition transient data destinations
Application programs use intrapartition destinations to queue data on

direct-access storage devices to be processed by other programs running as
separate tasks within the same CICS region, as shown in Figure 30 on page 77.
Data directed to or from these internal destinations is called intrapartition data.
Typical uses for intrapartition destinations include message switching,
distribution of output to several terminals, and enqueueing data to assign
priority by arrival.

Figure 30. CICS intrapartition transient data queues
Automatic transaction initiation (ATI): Intrapartition destinations can be

predefined with a trigger level and triggered transaction. When the number of
entries in the destination reaches that level, the triggered transaction is
automatically initiated (started).
Typically, the triggered transaction processes the records on the queue. The
transaction uses a principal facility to determine how it runs, as follows:
v File—the transaction runs as a background task on the same CICS region as
the queue
v Terminal—the transaction writes to a local or remote terminal
v System—the transaction takes part in a Distributed Transaction Processing
(DTP) conversation with a back-end transaction on another CICS region
Once the queue has been emptied, a new ATI cycle begins. That is, a new task
is scheduled for initiation when the specified trigger level is again reached,
whether or not execution of the earlier task has ended.
Extrapartition transient data destinations
Extrapartition destinations are queues residing on any file system file (disk,
tape, and so on) that are accessible by programs on any CICS region. Data can
also be routed to output devices, such as printers. Examples of such
extrapartition data are logging data, statistics, and transaction error messages.
In general, extrapartition destinations are used for storing and retrieving data
outside the CICS region and for storing data for input to non-CICS programs.

Figure 31. CICS extrapartition transient data queues
Extrapartition data consists of sequential records that are fixed length or

variable length, as predefined for the destination. The queue definition also
defines the logical organization (length and termination character) of records
in the queue, as shown in Figure 31. Variable-length records terminating with
the ASCII newline character are particularly useful for queues containing
readable text, because they enable the file to be viewed or written with
conventional text editors.
Indirect destinations
Intrapartition and extrapartition destinations can be used as indirect

destinations to route data to any other destination. Application programs send
data to the indirect destination by using its original symbolic name. The
resolution of the symbolic name can be changed simply by changing the
queue definition for the destination; applications do not need to be changed.
Temporary storage queues
Temporary storage queues are typically used for shared reading, writing, and
updating of data by multiple transactions; for example, as a scratchpad for
shared data.

Figure 32. CICS temporary storage queues
As shown in Figure 32, temporary storage queues can be used to store data
either in main storage of the operating system, or in auxiliary storage on a
direct-access storage device. Generally, main storage is used if small amounts
of data are needed for short periods of time; auxiliary storage is used if data
is to be kept for long periods of time. Transactions can write, update, read,
and delete data in a temporary storage queue any number of times until the
queue is deleted.
Temporary storage queues are not predefined to a region, but created the first
time you write to a queue by using a new symbolic name. Any transaction
can retrieve temporary data by using the symbolic name assigned to the
queue. Specific elements (logical records) within a queue are referred to by
relative position numbers.
A temporary storage queue having only one record can be treated as a single
unit of data that can be accessed by using its symbolic name, for example, as
a scratchpad for multiple transactions. In general, use temporary storage
queues of more than one record only when direct access or repeated access to
records is necessary; transient data control provides facilities for efficient
handling of sequential files.
Recoverable temporary storage: Data stored in recoverable auxiliary storage is

retained after a CICS region terminates and can be recovered in a subsequent
restart. Data stored in nonrecoverable auxiliary storage is retained only across a
normal shutdown, but not across an immediate shutdown or system failure

unless a database is being used as the file manager. Data stored in main
storage is not retained across any type of shutdown and so cannot be
recovered.
A CICS region can automatically delete temporary storage queues that have
not been accessed for a specified number of days. The storage occupied by
these queues is freed and becomes available again.
Encina queues
Figure 33. Encina queues and queue sets
The Encina Recoverable Queueing Service (RQS) manages concurrent requests

for data stored in queues. In Encina, applications enqueue (add elements to
the tail of a queue) and dequeue (read the first available element from the
head of the queue) in a generally first-in first-out (FIFO) manner. Figure 33
illustrates enqueueing and dequeueing in Encina RQS queues.
The layout of an element is predefined by its element type, which is a named

specification that defines the data type and size for each field of an element,
and the element’s key or keys. An element key is a sequence of one or more
element fields to be used as a basis for retrieving the element.
Element types are independent of queues; a single queue can contain elements
of several different element types. For example, a financial application can
have several element types defined: one each for debit, credit, and cancellation
data. Element type specifications are designed to be compatible with SFS
record specifications.
To manage queue system traffic—maximize throughput, perform load

balancing, and ensure that the highest priority tasks are given the most
attention—Encina enables you to group queues into queue sets. Queue sets are
collections of queues ranked by their priority class. You can add elements to

the queue that has the appropriate priority class. You can dequeue an element
from the queue set as a whole; the element returned is the next one from the
highest priority queue that contains elements.
Dequeueing from queue sets
The selection of queues in a queue set can be based strictly on each queue’s
priority class (called strict prioritization) or on the weights defined by their
service levels (called weighted prioritization).
In a queue set with strict prioritization, dequeueing takes place strictly in the
order of the priority classes. Queues at the highest priority class are
considered for dequeueing first, until empty. Queues at the next highest
priority class are considered next until empty; and so on.
In a queue set with weighted prioritization, the frequency of dequeueing from

one queue relative to lower-priority queues is changed by the weight factors
defined by the service levels of the priority classes.
In Figure 34 on page 82, with weighted prioritization, the queues (A and B)

with priority class 1 are considered for dequeueing four times as often as
priority class 2 (queues C and D). The queues at priority 1 are considered
together, and approximately equal numbers of elements are dequeued from
each queue. With strict prioritization, elements are removed from queues A
and B until the queues are empty, then from queues C and D (while queues A
and B are empty).

Figure 34. An example Encina queue set
The priority classes and service levels collectively determine the flow of traffic
through a queue set. By altering priority classes and service levels, the
selection behavior can be adjusted in response to demands on the server or to
the requirements of client applications.
Relational databases
User application programs can access RDBMs by using embedded Structured

Query Language (SQL) commands. They can also use CICS API commands to
access files and queues stored in DB2. (See Figure 35 on page 83.)

Figure 35. Relational database services
If you use the X/Open XA interface to XA-enabled relational databases, the

CICS region, rather than the RDBMS, coordinates the transactional updating
of data. For example, a CICS region issues syncpoints to ensure that the
relational database and the CICS region are updated by using the two-phase
commit protocol. The benefits are that the CICS region can do the following:
v Implement a two-phase commit process
v Restore shared resources to a consistent state after a failure
v Roll back transactions in the event of a failure in the first phase of a
two-phase commit
CICS also provides optimized single-phase commit support that improves

performance for updates to DB2, Oracle, Sybase, and Informix.
XA-enabled databases support the X/Open XA interface, as defined by the

X/Open Distributed Transaction Processing standard (X/Open DTP). That
standard defines the concept of a functional model that consists of an
application program, resource managers, and transaction managers. For
information about the X/Open DTP standard, see X/Open Distributed
Transaction Processing Reference Model ISBN 1 872630 16 2.

If the RDBMS you are using is not compliant with the X/Open XA interface,
or you are not accessing that RDBMS with the XA interface, then you cannot
use two-phase commit between the resources coordinated by CICS.
DB2 supports XA dynamic registration, which means that the CICS region can
drive a syncpoint in the database when the database is updated for a given
transaction. Dynamic registration can reduce the time it takes to syncpoint
when you are running in an environment with multiple XA databases and file
managers. It is particularly useful if the majority of your transactions do not
need to access a database.
SQL restrictions for non-XA-enabled relational databases
If you use non-XA-enabled relational databases, your application programs

must issue specific commands to do the following:
v Connect to the RDBMS before making any SQL calls and close the
connection to the RDBMS after all SQL calls have been made. An exception
is DB2, where the first SQL statement triggers a connection to a database
defined by the environment variable DB2DBDFT. This is known as an
implicit connection.
v Commit updates to SQL resources in the database and CICS resources (or
let CICS commit its resources implicitly at the end of the transaction). If one
of these updates succeeds while the other does not, you must manually
correct the two systems to make them consistent.
Using DB2 to manage CICS files and queues
CICS can store files and queues (used by application programs or by the
system) in a DB2 database instead of an SFS server. However, consider the
following when using DB2:
v A CICS region can use only one DB2 database for its files, but can use one
or more SFS servers for user files. (The CICS region can also access remote
files through other CICS regions.)
v Some COBOL External File Handler facilities are not supported; for
example, you cannot mix transactional and nontransactional access to files
within a single application.
v Nonrecoverable files, nonrecoverable auxiliary temporary storage queues,
and transient data queues are supported as recoverable files on DB2. This
means that data is not written to a file or queue until a syncpoint is taken,
but data can be recovered after failures.
v The set of DB2 data types that can be accessed by CICS is limited. For CICS
family portable applications, use DB2 data types that are not associated
with a coded character set.
v DB2 can use either of the following table spaces:

– Database Managed Space (DMS) Table Space, where the database
manager controls the storage space
– System Managed (SMS) Table Space, where operating system file
manager calls are used to control the storage space
Use DMS Table Space with CICS because, in general, it provides better
performance than SMS Table Space.
Application programs can use SQL access to a DB2 database that is also used
for CICS file and queue management.
Journals
A journal is a set of special-purpose sequential files. Journals can contain any

or all data that the user needs to reconstruct events or data changes. For
example, a journal can act as an audit trail, a change-file of database updates
and additions, or a record of transactions passing through the system (often
called a log). Any task can write to the same journal.
Journals are fundamental to the recoverability of transactions. In particular,

CICS uses the system journal to log transaction commit processing and
syncpoint data so that CICS can recover all necessary recoverable resources in
the event of a CICS or transaction failure.
CICS journal records
CICS can write data to either its system journal or any of its user journals.
When a journal record is built, the data is moved to the journal buffer area.
All buffer space and other work areas needed for journal operations are
acquired and managed by CICS. An application program does not need to
know anything about the journal; it knows only which journal to use, and
what user data to supply to be written to the journal. Journal records are
written to extrapartition queues in variable-length record format.
Synchronizing journal output
When a task creates a journal record, the task can wait until the output has
been completed. The application program can then be sure that the journal
record is written to the journal’s external storage device before processing
continues; the task is said to be synchronized with the output operation.
The application program can also request asynchronous journal output. This
causes a journal record to be created in an operating system file buffer and,
optionally, initiates the data output operation from the buffer to the external

device. This enables the requesting task to retain control and thus continue
with other processing. The task can check and wait for output completion
(that is, synchronize) later.
Considerations for sharing and distributing data
Current hardware and software make it practical to distribute data among

several remote locations. Distribution allows you to keep data local to the
application programs that most often use it without restricting access by other
users. However, it also introduces new and more complex issues of sharing,
integrity, and recovery. If your application requires distributed data, it affects
your initial decisions.
CICS local and remote data
Files and queues that are accessed directly by a CICS region are defined as
local to that region. If the data is accessed by way of another CICS region, it is
defined as remote. A CICS region sends requests for a remote resource to the
remote region by means of CICS function shipping.
Generally, applications are designed to access a resource without being aware

of the resource’s location. Each resource definition indicates whether the
resource is local or remote and, for remote resources, indicates the CICS
region to which function shipping requests should be sent.
Note: A resource definition is also used on the remote CICS region to identify
the remote resource, and can also specify that it is on another CICS
region. In this way, function shipping requests can be passed from one
CICS region to another several times. The requesting application
remains unaware of any remote routing.
If needed, CICS application programs can name a remote CICS region

explicitly when requesting a resource.
Data integrity
Data integrity is an issue with all shared data. When even one user updates
data, there is a risk to read integrity, in that data can become obsolete while
other users are reading it. Read integrity becomes critical, for example, when
a user is reading the data on a customer’s charge card balance to authorize a
large purchase.
If more than one user can update the files, there is greater risk to data
integrity. If two tasks try to update the same data item, they can interfere with
each other or override the change made by one task with data that does not

reflect that change. TXSeries protects you against such update conflicts and
lost updates by enforcing write integrity.
Write integrity can be maintained by serializing all updates. Serializing is

done by locking data as soon as a task expresses intent to update and
delaying any other task that wants to update the same data until the holder of
the lock updates and releases the lock. Read integrity can be accomplished the
same way if reads, as well as updates, lock the data. Locks imply delays,
however, and therefore full read integrity is usually optional.
To work, locks must be imposed by a program that has control over all the
potential users of the data. Database managers, the access methods, the
transaction processing monitor, and the operating system all use locking to
prevent conflicts among the users they control. For example, among the tasks
in a single region, CICS enforces write integrity and, optionally, partial read
integrity.
In CICS, logical units of work (LUWs) provide the internal data consistency
required when there are processing relationships between two or more items
of data. For example, a single LUW can be used to transfer money between
two bank accounts and to record the transfer. The LUW ensures that the three
operations are all completed together so that both accounts contain consistent
data that also matches the transfer record.
Recovery
In a distributed transaction processing environment, resources updated by a

task can belong to more than one resource manager. In this situation the
recovery actions necessary when a task fails during an LUW are controlled by
the CICS region, but are the joint responsibility of all the resource managers
involved. One example of this is when you are using an XA-compliant
database, in which case the CICS region controls the backout actions both of
itself (as a resource manager) and of the RDBMS. Also, data can be stored on
several SFS servers, and although the CICS region keeps track of changes to
recoverable data, it is each SFS server that performs the major backout and
recovery of failed changes.

Chapter 6. Communications
This chapter describes the communications facilities used by TXSeries, as
shown in Figure 36 on page 90. It covers the following topics:
v “Communicating with users” on page 91
v “Communication using DCE RPCs” on page 98
v “Locating servers for communication” on page 98
v “Network protocols” on page 101
v “More about CICS intercommunication” on page 111
v “An introduction to secure communications” on page 114
v “Ensuring data integrity with synchronization support” on page 114
v “Converting between EBCDIC and ASCII data” on page 115
Figure 36 on page 90 shows a variety of TXSeries systems intercommunicating
by using a mixture of communication services.

Figure 36. A TXSeries communications network
The central Customer Information Control System (CICS) for Windows NT

region is communicating with the following:
v Another CICS for Windows NT region, a CICS on Open Systems region,
and an Encina Peer-to-Peer Communications (PPC) based application in the
same DCE cell. PPC Transmission Control Protocol/Internet Protocol (PPC
TCP/IP) is used because the systems are in the same DCE cell. The Encina
PPC-based application can be an Encina Monitor application server running
in a Monitor cell.

v CICS Clients and another CICS region on the TCP/IP network outside the
DCE cell. CICS family TCP/IP is used for TCP/IP communication outside
the DCE cell.
v CICS Clients, some Advanced Program-to-Program Communication (APPC)
workstations, and a CICS for OS/2 region across a Systems Network
Architecture (SNA) network. Local SNA support is used because these do not
support synchronization level 2.
v A CICS for MVS/ESA region across the SNA network. A PPC Gateway server
is used to provide SNA synchronization level 2 support. Communication to
and from the PPC Gateway server uses PPC TCP/IP.
Communicating with users
Users communicate with servers through clients. Clients are typically products
dedicated to communicating with servers and providing interfaces to users
and their application programs. Clients run on a range of platforms, for
example, laptop computers and Open Systems workstations.
Users can communicate with CICS through the following:

v IBM CICS Clients, which also enable you to access CICS regions from the
Internet. (See “Communicating with IBM CICS Clients” on page 93 and
“Accessing CICS from the Internet” on page 95 .)
v Telnet clients with 3270 emulation capability (See “Communicating with
CICS Telnet clients” on page 98.)
v Local 3270 terminals attached directly to CICS regions (See
“Communicating with CICS local terminals” on page 98.)
If you have other devices for communicating with users, these are connected
to IBM CICS Clients. For example, an automatic teller machine (ATM) can be
connected to a client to provide its user interface to CICS. Similarly, a printer
attached to a client can be used for output from CICS.
Encina Monitor clients are applications that communicate with Monitor

application servers.
Figure 37 on page 92 illustrates the various communications methods used by

CICS clients.
Chapter 6. Communications 91
Figure 37. Communication between CICS clients and a CICS region
CICS client interfaces
CICS Clients and CICS DCE-enabled clients provide the following user
interfaces:
The External Call Interface (ECI)
This enables a non-CICS application program running on the client
machine to call a CICS program synchronously or asynchronously, as
a subroutine. Client-based applications use simple ECI calls to pass
blocks of data to CICS regions, without needing any special
communication code.
The External Presentation Interface (EPI)
This enables an application program running in the client to invoke a
CICS transaction on the server. The transaction is executed as though
it is started from a 3270 terminal. The transaction returns a 3270 data
stream to the client, which can present it in a graphical user interface
(GUI). This enables technologies such as graphical or multimedia
interfaces to be used with traditional 3270 CICS applications without
changing the CICS applications.
3270 terminal and printer emulation
This enables the client workstation to function as a 3270 terminal or
printer. Existing CICS applications can be ported to the TXSeries
environment (for example, from mainframe CICS regions) without
change, as long as users have client machines that run the 3270
emulator. The user of a CICS client can enter cicsterm commands to

establish 3270 terminal-emulation sessions. Those 3270 terminal
sessions can be used to request the start of CICS transactions and to
receive 3270 data-stream output from applications running on CICS
regions.
You can define a client-attached printer so that CICS applications
running on servers can send output to it. You can direct the output to
a physical printer attached, for example, to the LPT1 port, or you can
specify a command to process the data into a format more suitable for
special-purpose printers.
Client communications with mainframe-based CICS
IBM CICS Clients can communicate directly with IBM mainframe-based CICS
via APPC, usually through a local area network (LAN) and an SNA gateway.
In an IBM LAN, gateway communication facilities are provided by SNA
running on the gateway machine.
You can also communicate between a CICS client and IBM mainframe-based
CICS through an intermediate CICS region to which the client is connected.
This makes use of CICS intercommunication facilities, described in “CICS
intercommunication facilities” on page 112.
Communicating with IBM CICS Clients
CICS regions can provide transaction processing facilities for multiple

workstations that are running IBM CICS Client products. Users can
communicate with IBM CICS Clients using the interfaces described in “CICS
client interfaces” on page 92. They can also make use of the CICS Transaction
Gateway for access to the Internet. This section describes the process used to
connect and authenticate IBM CICS Clients to CICS regions, and provides an
overview of the CICS Transaction Gateway.
A CICS client can communicate with multiple CICS regions. A client

initialization file determines the parameters for client operation and identifies
the associated regions and protocols used for communication.
Connecting and authenticating IBM CICS Clients
CICS regions support requests from IBM CICS Clients by means of TCP/IP
and SNA listener processes running on the CICS regions. (See Figure 37 on
page 92.) The listener process communicates with a corresponding process on
the client machine and imitates the flows between CICS regions. (For more
information about listeners, see “CICS listeners” on page 112.) When a CICS
Client connects to a CICS region, the server automatically installs a
communications definition that identifies the CICS Client and other
communication attributes for it. For an EPI or cicsterm request, the server also
installs a terminal definition that it uses to identify the 3270 characteristics of
the CICS Client.
To communicate with a server, a client first connects to the server either

explicitly by a connect (command) request, or implicitly when an ECI, EPI, or
cicsterm request is sent to an unconnected server. The client identifies the
server either by parameters passed on the request or from its file of servers
that it can connect to. When a connection has been made to a server, it is used
for all subsequent communication with the server, until the connection is
terminated.
The server can require that the client provide a userid and password for the
connection to be made. If so, the client can get the userid and password from
either of the following:
v Its file of servers that it can connect to. In this file, the client administrator
can define the default userids and passwords to be used for connections to
the servers.
v A user entry, prompted by a pop-up box displayed by the client if there are
no defaults defined for the connection. The values entered are used for the
connection, and stored as the default for connections to the server.
For additional security, a server can require that clients provide a userid and
password on any ECI, EPI, or cicsterm request made for an existing
connection, as follows:
v An ECI application can have a userid and password coded in it. On an ECI
request, the client can automatically pass those values to the server. If the
values are invalid, a security error is returned to the ECI application.
v For EPI and cicsterm requests, there is no facility to automatically provide a
userid and password.
v For EPI and cicsterm requests, and ECI requests without a valid userid and
password, the client displays a pop-up box prompting the user to enter
new values. Those values are sent to the server and stored by the client as
the default for connections to the server.
If a valid userid and password are not provided, the request is refused but the
connection remains in place.
CICS Client communication protocols
The CICS clients can communicate with CICS regions by using the following
protocols:
v TCP/IP
v APPC

Depending on the client platform, the CICS clients can also use other
protocols to communicate with other systems.
Accessing CICS from the Internet
You can provide access to CICS from the Internet by using the CICS
Transaction Gateway. This gateway enables Internet access to existing CICS
2370 applications and allows a Java-enabled Web browser or network
computer to download a Java applet and transparently access CICS data and
applications.
More information is available on the following Web page:

http://www.software.ibm.com/ts/cics/platforms/desktop
(CICS Desktop and Internet Integration)
The CICS Transaction Gateway
The CICS Transaction Gateway enables Internet access to the transactional

capabilities of IBM CICS servers, including CICS Transaction Servers and
TXSeries servers, using standard Internet protocols. The gateway enables any
Web browser, Network Computer, or Internet-enabled consumer device to
access business applications running on CICS servers, using one of three
possible methods:
v Standard HTML browsers. The CICS Transaction Gateway renders existing
CICS 3270 applications into HTML automatically, and transmits to the
browser using HTTP. You can also create your own Java servlets that
present information from CICS applications in HTML forms, customized as
required.
v Java-enabled Web browsers. The CICS Transaction Gateway enables
customer applets to access CICS 3270 applications and CICS programs
using supplied Java classes and Java beans.
v ORB-enabled Web browsers. The browsers can run Java beans which
interoperate with server-side Java beans (running on the CICS Transaction
Gateway) via the CORBA IIOP protocol. The server-side beans can then
invoke CICS 3270 applications and CICS programs using supplied Java
classes.
The CICS Transaction Gateway incorporates the CICS Universal Clients and is
available on OS/2, Windows NT, AIX, and Solaris platforms.
Access to 3270 applications
As shown in Figure 38 on page 96, the CICS Transaction Gateway provides an

interface between a Web server and CICS applications and data, allowing
conversion of 3270 data streams into Hypertext Markup Language (HTML)
format used by the World Wide Web. The CICS application can then be
accessed by Web browsers on diverse platforms with no change to either the
browser or the CICS application.
Figure 38. The CICS Transaction Gateway (from standard HTTP browser)
The CICS Transaction Gateway resides on the Web server machine and
dynamically builds Web pages containing the CICS data and transmits them
to the Web browser.
The CICS Transaction Gateway provides automatic translation between CICS

3270 data streams and HTML using the CICS EPI, which is part of a CICS
Client. IBM CICS Clients provide links to CICS regions.
For more information, see “Web security services” on page 130.
Access to CICS Java applications
The CICS Transaction Gateway enables CICS client applications written in

Java to communicate with CICS regions. It provides an application
programming interface (API) that enables conversation between an application
or applet in Java and a transactional application running in a CICS region.
The CICS Transaction Gateway is a Java application that runs on the same
Web server machine as the CICS Client. Access to the Web server and so to
the CICS applications is from any Java-enabled browser such as Netscape
Navigator, or a network computer (NC). A typical configuration using the
CICS Transaction Gateway is shown in Figure 39 on page 97.

Figure 39. The CICS Transaction Gateway (from Java-enabled browser)
The CICS Transaction Gateway consists of the following two components:

v The supplied Java application.
v A CICS Java class library, which includes two classes that provide an API
and are used to communicate between the Java gateway application and a
Java application or applet.
The multithreaded architecture of the CICS Transaction Gateway enables it to

manage many communication links to connected Web browsers at the same
time, and to control asynchronous conversations to multiple CICS region
systems.
Communicating with CICS DCE-enabled clients
CICS DCE-enabled clients (both RPC-only clients and clients that use the full
services of DCE) use DCE remote procedure calls (RPCs) to communicate with
CICS regions and provide the same EPI, ECI, and 3270 interfaces as other IBM
CICS Clients.
When a CICS DCE-enabled client connects to a CICS region, it can pass its
DCE principal to the CICS region. If that principal is not associated with a
user definition for that CICS region, or if a principal is not passed, the user is
signed on to CICS with the region’s default userid. If the principal is
associated with a user definition, the user is signed on with that userid.
If you are using DCE security, CICS DCE-enabled clients are authenticated
when they start up and use authenticated RPCs for communication with CICS
regions.
Communicating with CICS Telnet clients
A CICS Telnet server enables Telnet clients to connect to CICS regions running
on the same machine as the server. Telnet clients are available on a number of
operating systems, including Windows NT, OS/2, MVS, AIX, and other Open
Systems platforms.
An instance of the Telnet server is started for every connection needed

between a Telnet client and a CICS region. When a CICS Telnet server is
available, a user needs only to run a Telnet client to access CICS. This can
present a choice of available CICS regions. When the user selects a region, the
Telnet server connects to it and requests a terminal autoinstall. The user can
then run CICS transactions subject to any security for the Telnet connection.
(For more information, see “Security considerations for CICS Telnet clients” on
page 131.) When in use, a CICS Telnet connection is represented in the CICS
region by a terminal definition, which is automatically installed when the
connection is established.
Communicating with CICS local terminals
A CICS local terminal is an administrative 3270 terminal running on a

machine. It can be used to enter requests to start CICS transactions and to
receive 3270 data-stream output from CICS transactions and user application
programs. More powerful user interface facilities can be provided by a CICS
Client.
Communication using DCE RPCs
CICS regions use DCE RPCs to communicate with other CICS regions, SFS
servers, PPC Gateway servers, DCE-enabled CICS clients, PPC applications,
and other CICS regions that use DCE RPCs. The Encina Monitor uses DCE
RPCs for all its communications. In a DCE cell, authenticated RPCs can be
used for greater communications security.
Locating servers for communication
For two servers to communicate, each server needs information to locate the
other server. Servers use a name service to provide this information, called
binding information. Binding information consists of the following:
v A protocol sequence, which indicates the network protocol to be used
v A server host, which indicates the machine the server is running on
v The endpoint, which indicates how to contact the server

The protocol sequence and server host information can be stored by either
v Using the DCE Cell Directory Service (CDS) (transparent binding).
v Using an environment variable and a binding file.
On each machine in the network, an endpoint map database stores the endpoint
information (the process address for contacting a system) for all systems on
that machine.
If the communicating systems are using the DCE CDS, then all of the binding
information is created and maintained automatically. If you move a system
from one machine to another within that DCE cell, you do not have to change
any of the binding information. In addition, the DCE CDS is required by DCE
security services.
If your CICS regions and associated servers run on a small number of

machines and you do not wish to use DCE servers, you can set up the
binding information manually. To do this, you use a binding file and an
environment variable that must be accessible to all of your CICS regions. The
environment variable lists all the machines where the CICS regions and other
servers are located. If the location of one of the regions changes, you must
manually update the binding information.
Using the DCE CDS in a DCE cell
The DCE CDS Server provides a central naming service for a DCE cell,
enabling principals in that cell to be located by simple names regardless of
where they are located. The CDS lookup process used to determine the names
within a DCE cell is shown in Figure 40 on page 100.
Figure 40. CDS components performing a CDS lookup
The following numbered steps correspond to the numbers in the figure:

1. The DCE client, CICS region A, wants to access a DCE resource, CICS
region B, for which it knows only the name. To determine the address of
CICS region B, CICS region A sends a lookup request to the local CDS
clerk.
The CDS clerk checks its local cache. If the name is not in the cache, it
forwards the request to the CDS Server. If the cache is empty, the CDS
clerk performs additional lookups to resolve a long pathname.
2. Before a CDS clerk is able to request a lookup to the CDS Server, the CDS
clerk must be able to locate the CDS Server in the DCE environment. The
clerk can locate the CDS Server in one of the following ways:
v By using a solicitation and advertisement protocol
v By performing a lookup
v By using a management command
The advertisement protocol is used by the CDS Server to broadcast

messages at regular intervals to advertise its existence to clerks in a Local
Area Network (LAN). The advertisement message contains information
such as the cell that the server belongs to, the server’s network address,
and the clearinghouses it manages. At startup, the clerks send out
solicitation messages (broadcasts) to request for advertisement.
3. The CDS Server checks to see if the name of CICS region B is in its
clearinghouse. If the name is not in the clearinghouse, the CDS Server
gives the clerk as much data as it can about where else to search for the
name.

4. If the name is in the clearinghouse, the CDS Server gets the requested
information.
5. The CDS Server returns the information to the CDS clerk.
6. The CDS clerk caches the information and passes the requested data to the
client application. The clerk caches the results of lookups so that it need
not repeatedly contact the server for the same information. The cache is
written to disk periodically so that the information can survive a CICS,
Encina, or DCE restart. The cache is deleted when the host is rebooted.
Using the CDS to locate systems outside the DCE cell
If a CDS Server receives a lookup request with a global name for a system in
another (remote) DCE cell, it sends the request to the DCE Global Directory
Agent (GDA). The GDA sends the request to a DCE global name service,
which returns the address (binding information) to the CDS Server in the
remote DCE cell. The local CDS clerk that made the lookup request then
connects to the remote CDS server to obtain the information as if that remote
CDS server was in the local DCE cell. The server in the local DCE cell can
then use DCE RPCs to communicate with the system in the remote DCE cell.
Network protocols
When two systems communicate, they need to agree on the set of rules to use
to interpret the data they exchange. These rules are known as network
protocols, and they are defined in a network architecture. The network protocol
also defines the form of acknowledgment processing that transactions on two
communicating systems use to ensure that their data updates are
synchronized. The form of this acknowledgment depends on the
synchronization levels defined by the IBM Systems Network Architecture (SNA).
TXSeries intercommunication is based on the SNA LU 6.2 protocol, often

referred to as APPC. CICS on Open Systems supports intercommunication
across an SNA network between a local region and the following:
v Other CICS on Open Systems regions
v Other CICS products such as CICS/ESA and CICS for OS/2
v IBM CICS Clients
v Applications on systems that support the SNA LU 6.2 protocol
In addition, CICS on Open Systems can emulate SNA LU 6.2 across TCP/IP
networks. This allows connectivity across TCP/IP between a local region and
the following:
v Other CICS on Open Systems regions
v CICS for OS/2 and CICS for AIX regions
v IBM CICS Clients
v Encina PPC-based applications

Similarly, an Encina Monitor application server can use TCP/IP to
communicate with other Encina servers, and with CICS regions that support
PPC TCP/IP. An Encina Monitor application server can also use a PPC
Gateway and SNA to communicate with systems on an SNA network, for
example, with IBM mainframe-based CICS regions.
For more information about the effect of network protocols, see the following
sections:
v “SNA synchronization levels”
v “Communicating across TCP/IP connections”
v “Communicating across SNA connections” on page 105
v “Mixing the communications methods” on page 109
SNA synchronization levels
CICS and the Encina Monitor support all three synchronization levels defined
by SNA, across both SNA and TCP/IP networks. The SNA synchronization
levels are as follows:
Synchronization level 0 (NONE)
SNA provides no synchronization support. The application must code
its own.
Synchronization level 1 (CONFIRM)
SNA provides the ability to send simple acknowledgment requests.
Synchronization level 2 (SYNCPOINT)
SNA provides the ability for two or more systems to treat the updates
made by an application on these systems as one logical unit of work
(LUW).
Communicating across TCP/IP connections
TCP/IP is a communication protocol that is part of the underlying structure of

the operating system on machines that run TXSeries. It is a simple protocol
that requires each system to provide most of the support for
intercommunication, such as the data formats used to send intersystem
requests and the security needed to protect system resources. TXSeries
supports two types of TCP/IP connections:
v CICS family TCP/IP
v PPC TCP/IP
CICS family TCP/IP
CICS family TCP/IP supports the following types of intersystem requests

between CICS on Windows NT, CICS for OS/2, and CICS on Open Systems
regions:

v Function Shipping
v Transaction Routing
v Distributed Program Link (DPL)
v Asynchronous Processing
Distributed Transaction Processing (DTP) is not supported.
IBM CICS Clients can also use CICS family TCP/IP to connect to a CICS
region. When the first request is made, a TCP/IP connection is acquired
between the two systems. This connection remains acquired while both
systems are active, and it can carry many concurrent intersystem requests
flowing in either direction.
A CICS region can accept TCP/IP connections on one or more TCP/IP ports
in the local machine and on one or more TCP/IP network adapters. This
flexibility enables your region to connect to a large number of remote regions
and clients.
Note: CICS family TCP/IP support does not provide the same level of
security as PPC TCP/IP. This is discussed in “An introduction to secure
communications” on page 114.
Figure 41 on page 104 illustrates a CICS on Open Systems region using CICS
family TCP/IP to communicate with a CICS for OS/2 system and an IBM
CICS Client.

Figure 41. Communicating with CICS family TCP/IP support
Synchronization levels: All intersystem requests on a CICS family TCP/IP

connection use synchronization level 1 (synclevel 1). Synchronization levels are
described in “SNA synchronization levels” on page 102.
PPC TCP/IP
CICS can use PPC TCP/IP for all types of intercommunication with CICS
regions. It also allows DTP with Encina applications and communication with
SFS servers and PPC Gateway servers.
The Encina Monitor uses TCP/IP for all communication between Encina
Monitor clients, servers, and resource managers.
Systems communicating with PPC TCP/IP must be in the same DCE cell if
they use the CDS. If the system you wish to communicate with is running on
a machine in a different DCE cell, then you must make use of DCE’s global
naming services. If the system you wish to communicate with is not running
on a machine in a DCE cell, then consider using CICS family TCP/IP support
or SNA support.
When an intersystem request is made, CICS uses the name service to locate
the remote region. Then a TCP/IP connection is set up between the two

systems. This connection is used exclusively by the intersystem request and is
closed down when the request has completed.
Figure 42 illustrates a PPC Executive being used to interconnect CICS on

Open Systems regions, and an application that is using the PPC Executive.
Figure 42. Communicating via Encina PPC TCP/IP
Synchronization levels: Encina PPC TCP/IP supports synchronization levels

0, 1, and 2. For more information about the different synchronization levels,
see “SNA synchronization levels” on page 102.
Communicating across SNA connections
CICS regions and Encina PPC-based applications can communicate across

SNA with any system that supports APPC; for example, IBM
mainframe-based CICS and APPC workstations.
TXSeries can use the following two methods of SNA communication:

v CICS local SNA support, which supports synchronization levels 0 and 1
(See “Using CICS local SNA support to communicate across SNA” on
page 106.)
v An Encina PPC Gateway server, which supports synchronization levels 0, 1,
and 2 (See “Using a PPC Gateway server to communicate across SNA” on
page 107.)

Both methods support all the CICS intercommunication facilities to other
CICS regions, and DTP is supported to non-CICS regions (such as Encina).
Also, CICS can use local SNA support to communicate with IBM CICS
Clients.
Using CICS local SNA support to communicate across SNA
Local SNA support provides the fastest SNA connectivity offered by CICS. It
enables CICS applications to communicate with every other member of the
CICS family, and IBM CICS Clients to use SNA to communicate with CICS.
Local SNA support requires SNA to be installed and configured on the same
machine as the CICS region.
Figure 43 illustrates CICS on Open Systems using local SNA support to

communicate with other CICS regions and with other APPC applications. The
term APPC workstations refers to any small computer running APPC
applications.
Figure 43. Using local SNA support to communicate across SNA

Synchronization levels: Local SNA support gives your CICS regions support
for synchronization levels 0 and 1. If you require synchronization level 2
support then you must use a PPC Gateway server. This is described in “Using
a PPC Gateway server to communicate across SNA”. For information about
the different synchronization levels, see “SNA synchronization levels” on
page 102.
Using a PPC Gateway server to communicate across SNA
Figure 44. PPC Gateway connection to an SNA network
As shown in Figure 44, CICS and Encina can communicate with an SNA
network by using a PPC Gateway server. Communication with the PPC
Gateway server uses PPC TCP/IP, and the PPC Gateway server provides
synclevel 2 communication across the SNA network. This allows applications
to ship or accept transactions from other systems that use LU 6.2, such as IBM
mainframe-based CICS, CICS for OS/2, and CICS/400. The PPC Gateway
uses a mechanism (called the PPC Executive) to ensure that transaction
semantics are preserved across distributed processes and can emulate APPC
protocol. If you are using the DCE CDS as a name service, the PPC Gateway
server must be in the same DCE cell as the CICS or Encina servers that use
the gateway. The PPC Gateway server uses SNA to connect to the remote SNA
systems. SNA must be on the same machine as the gateway.
CICS and the Encina Monitor are the only transaction processing monitors
that can do this at synclevel 2, and CICS is the only one to integrate seamlessly
the mainframe-based transaction processing environment with the distributed,
workstation-based environment.
Figure 45 on page 108 illustrates a CICS on Open Systems region using the
PPC Executive to connect to a PPC Gateway server machine, which in turn
connects to a SNA network.

Figure 45. Using a PPC Gateway server to communicate across SNA
A CICS region can use more than one PPC Gateway server. Using multiple
gateway servers enables you to do the following:
v Spread the network links from a large number of remote machines across
more than one gateway machine, and thus across multiple SNAs
v Introduce redundancy, so that if one PPC Gateway server fails, there is
another available as a backup

v Spread the processing load across more than one PPC Gateway server
Synchronization levels: A PPC Gateway server gives your CICS region

support for synchronization levels 0, 1, and 2. If you require only
synchronization level 0 or 1, and you plan to put SNA on the machine where
the CICS region is running, then consider using local SNA support. This is
described in section “Synchronization levels” on page 107. For information
about the different synchronization levels, see “SNA synchronization levels”
on page 102.
Mixing the communications methods
You can mix the communication methods used to connect your CICS regions.
For example, a CICS region can communicate with another CICS region over
TCP/IP, while also communicating over SNA using both local SNA support
and a PPC Gateway server. Figure 46 on page 110 shows a CICS on Open
Systems region that is communicating with another CICS on Open Systems
region using TCP/IP. PPC TCP/IP is used because both regions are in the
same DCE cell. The CICS on Open Systems region is also communicating
across an SNA network to another CICS system, some APPC workstations and
a CICS for MVS/ESA system. The communications with the CICS system and
the workstations is using local SNA support. Local SNA support was chosen
because CICS and the APPC workstations do not support synchronization
level 2. The communications with CICS for MVS/ESA is using a PPC
Gateway server because synchronization level 2 support is required. The PPC
Gateway server is running on the same machine as the CICS region and is
using the same SNA.

Figure 46. Communications using TCP/IP, a PPC Gateway server, and SNA
Another example of mixing the communication methods is shown in Figure 47

on page 111. Here a CICS on Open Systems region is communicating across
an SNA network to a CICS system, some workstations, and a CICS for
MVS/ESA system. The communications with the CICS system and the
workstations is using local SNA support. However the communications with
CICS for MVS/ESA is using both local SNA support and a PPC Gateway

server (which is running on a different machine than the CICS on Open
Systems region). This setup allows CICS transactions that communicate with
the CICS for MVS/ESA system to use the faster local SNA support for
synchronization level 0 and 1 requests, and the PPC Gateway server for
synchronization level 2 requests.
Figure 47. Communications using a PPC Gateway server and SNA
More about CICS intercommunication
CICS provides a range of intercommunication facilities to simplify distributed

operations across multiple CICS regions. CICS intercommunication between
one CICS region and another and between a CICS region and a client is
implemented through listeners.

CICS listeners
Listeners are used to monitor incoming communication and to facilitate

outgoing communication. A CICS region can use the following types of
listeners:
1. An RPC listener is used for communication with other CICS regions and
other systems that use DCE RPC; for example, with a PPC Gateway server
on AIX. If the RPC listener detects an incoming transaction request, it
places the request in a shared memory queue monitored by the
Application Server Manager.
2. A TCP/IP listener is used for communication across a TCP/IP network.
3. A local SNA listener is used for communication with local SNA.
4. A named pipe listener is used for communication across 3270 named pipes,
typically with CICS local terminals.
Communication between a CICS region and IBM CICS Clients uses either the
TCP/IP listener or the local SNA listener, depending on whether the clients
are connected via TCP/IP or SNA.
Each listener is a multithreaded process started when CICS is started. The

number of threads can be predefined or determined automatically by the
CICS region when it starts. The listener communicates with a corresponding
listener on the other system. For a CICS client, the communication with a
CICS region imitates the listener-listener flows between CICS regions. For
example, the flows generated by an EPI call are the same as those passed
between CICS regions involved in a transaction routing operation. The flows
generated by an ECI request are the same as those for a CICS-to-CICS DPL
request.
A CICS region needs a communications definition in its runtime resource

database for each remote system with which it can communicate. If a CICS
client connects to a CICS region, the CICS region automatically installs a
communications definition.
CICS intercommunication facilities
CICS provides the following intercommunication facilities to simplify

distributed operations across multiple CICS regions:
Function shipping
This enables an application program to access the files, transient data
queues, and temporary storage queues of another CICS region. Each
request is sent separately to the remote CICS region. If an application
needs a large number of accesses to remote data, it can be better to
use DPL or DTP. Function shipping is also available only for accessing

CICS resources, such as files and queues. If you wish to access
non-CICS data on a remote system, you need to use another method.
Transaction routing
This enables you to run a transaction on another region and display
its information on your terminal as if it is running on your local
region. Transaction routing is therefore useful if all of the processing
for a transaction is to take place on a single remote system.
You can configure a CICS region to use dynamic transaction routing,
where transactions are routed to any CICS region according to criteria
such as input to the transaction, available CICS regions, and relative
loading of available systems.
Asynchronous processing
This enables an application to start a transaction to run independently
on another CICS region. The success or failure of this remotely started
transaction does not affect the application that started it. Therefore
asynchronous processing is useful when it is not necessary, or
desirable, to keep a local transaction waiting while the remote
transaction is running.
Distributed program link (DPL)
This enables a CICS application program to link to a program that
resides on a different CICS region. DPL is very useful if an application
needs to make a large number of accesses to a remote resource, for
example, to search through a file on a remote CICS region. The local
application can use DPL to connect to a program on the region that
owns the data, passing details of the record that is required. The
linked-to program can search through the file and return the required
record to the local application. Using DPL in this case is significantly
more efficient than using function shipping to read each record
remotely. However, if your transactions need to transfer large amounts
of data between two CICS regions, consider using DTP.
Distributed transaction processing (DTP)
This is the most flexible of all the intercommunication facilities. It
enables two applications running on different systems to pass
information between each other. The commands used map to the LU
6.2 mapped conversation verbs defined in the SNA. The applications
can send as much data as they need at any point in their processing.
However, this means it is the most complex to use because the
application is responsible for setting up the communication with the
remote system, sending and receiving the data, and finally closing the
communication down when it is finished.
DTP is the only CICS intercommunication facility that can be used to
communicate with non-CICS applications. The non-CICS applications
must use the APPC protocol.

An introduction to secure communications
When two systems communicate, it is important to ensure that the systems’

identities can be verified and that resources are being shared only with users
who are authorized to access them. In a DCE cell, authenticated RPCs can be
used to protect communication between systems. The authentication checks
are made by the DCE Security Service.
CICS intercommunication provides extensions to CICS security for a single

standalone region to allow security checks for intersystem requests. CICS
intercommunication security checks are made by the system receiving the
request.
TXSeries functions for making communication secure are an extension of the

general security functions used by each separate system. For more information
about the general security functions used by TXSeries, see “Chapter 7.
Security” on page 117. For more information about the security functions used
for communications security, see “Ensuring secure communications” on
page 132.
Ensuring data integrity with synchronization support
TXSeries uses a form of acknowledgment processing to overcome any network or

system failures that can affect data updates in a distributed environment. For
a request to update remote data, a transaction runs on each system involved.
An appropriate form of acknowledgment is used so that the systems are sure
that the two transactions completed their tasks successfully. The form of this
acknowledgment depends on the requirements of the application, and uses
the three synchronization levels defined by SNA. (These synchronization levels
are summarized in “SNA synchronization levels” on page 102.)
When two SNA systems first establish contact, they agree on the maximum
synchronization that they will use. The synchronization level for each
individual task is then determined either by the system or by the application
program.
CICS use of synchronization levels
If the remote system and the communication network are able, CICS uses the
following synchronization levels across both SNA and TCP/IP:
v Synchronization level 2 for function shipping, asynchronous processing, and
DPL requests to a remote system

v Synchronization level 1 for transaction routing requests to a remote system
(because they do not update recoverable data on the local region)
v Synchronization level 2 for transaction routing requests received from CICS
for MVS/ESA, CICS/ESA, CICS/MVS, and CICS/VSE
DTP uses the synchronization level requested on the command used to
connect the two systems
CICS synchronization and the indoubt condition
Intercommunication using synchronization level 2 makes use of a two-phase

commit. A two-phase commit is a process for coordinating changes to
recoverable resources when more than one resource manager is used by a
single transaction. In the first phase, all resource managers are asked to
prepare their work; in the second phase, they are all requested to either
commit or back out (rollback).
During the processing of a two-phase commit for a transaction, a connection

or system error can occur. Some errors cause the transaction to wait until
either you correct the error or it is corrected by the transaction. These waiting
transactions are said to be in an indoubt condition. With CICS, if you do not
want the transaction to wait for the error to be corrected, you can purge the
transaction and have CICS commit or back out changes made by the
transaction before the wait occurred.
Converting between EBCDIC and ASCII data
Some of the systems that your CICS region can connect to store data in
different character encodings. For example, data is held in the Extended
Binary-Coded Decimal Interchange Code (EBCDIC) format on a IBM
mainframe-based CICS system, and in the American Standard Code for
Information Interchange (ASCII) format on CICS for OS/2. There are also
differences between CICS on Open Systems data and CICS for OS/2 data,
where the codes used for some characters vary and the method used for
representing numbers is different.
If data is transferred between two systems, it can require conversion from the
format used on the sending system to that used by the receiving system. CICS
converts some data, such as the filenames in function shipping requests,
without user setup. For other data, such as file records, you can define the
types of conversion to be applied to specified fields in data records. Exits and
user-replaceable conversion programs are available.
Note: Microsoft SNA Server does not provide mechanisms needed by CICS
for Windows NT to receive data conversion information from other

CICS regions. This affects data conversion on inbound function
shipping, DPL, and asynchronous processing requests.

Chapter 7. Security
This chapter describes the security facilities used by TXSeries. It contains the
following topics:
v “The TXSeries security models”
v “The TXSeries security model using DCE” on page 119
v “The TXSeries security model using CICS” on page 126
v “Authorizing access to resources” on page 128
v “Security considerations for IBM CICS Clients” on page 130
v “Security considerations for CICS Telnet clients” on page 131
v “Security considerations between CICS and XA-enabled databases” on
page 132
v “Ensuring secure communications” on page 132
The TXSeries security models
TXSeries can use either or both of the following security models:

v DCE security. A Distributed Computing Environment (DCE) Security Server
provides comprehensive, centralized security services for authenticating and
authorizing all systems in a DCE cell. This includes functions for making
communication secure through authenticated remote procedure calls (RPCs).
(See “The TXSeries security model using DCE” on page 119.)
v CICS security. Each CICS region does all the authentication and
authorization checking required for its own security, and can use an external
security manager as part of the security service. CICS security includes
functions for making communication secure, such as flowing userids and
passwords. (See “The TXSeries security model using CICS” on page 126.)
The most secure model uses DCE cell security. It is required for use with the
Encina Monitor but is optional for Customer Information Control System
(CICS).
Note: For CICS regions, you can start with the CICS security services, which
can be sufficient for a basic CICS environment. You can then migrate to
a DCE security model at a later date. For comprehensive security, such
as required by production CICS regions, the security services of DCE
are recommended.

Both security models provide facilities tailored to transaction processing that
enhance the security functions provided by the operating system and the
administrative model that it uses for network security.
More detail about the security services used by TXSeries is shown in Figure 48
on page 119. The authentication and authorization services shown are
described in this chapter. Other communication security services, such as
flowed userids and encrypted bind flows are described in “Ensuring secure
communications” on page 132.

Figure 48. Security services
The TXSeries security model using DCE
Within a DCE cell, the DCE Security Server provides a centralized security
service, based on its database of security information about network resources.
A CICS region that does not participate in a DCE cell has its own database of
users and processes logon requests by itself. (See “The TXSeries security
model using CICS” on page 126.) Users and systems that do not participate in
a cell but access the cell are treated as unauthenticated principals, for which
you assign special security privileges.
Chapter 7. Security 119

DCE security is not provided with TXSeries, but is available as a number of
products and IBM Software Servers for different platforms; for example, as
part of the IBM Software Server Directory and Security Server.
For more information, see:

v “Authenticating users and servers with DCE”
v “Authenticating access from systems outside a DCE cell” on page 123
v “DCE security information used for CICS” on page 124
Authenticating users and servers with DCE
This section describes the general DCE security process.
The general DCE security process
The general DCE security process, shown in Figure 49, depends on

information in the DCE security database, which is managed by the registry
service of the DCE Security Server.
Figure 49. The general DCE security process
To take part in a DCE cell, a principal (user or system) proves its identity by
authenticating to DCE. A user typically logs into DCE and specifies a
principal and password. A system authenticates automatically when it starts
up by getting its private key (encrypted password) from its DCE keytab file,
which is located on the machine on which it runs. In both cases the DCE clerk
on the principal’s machine sends the principal’s identifier and password to the
DCE Security Server to be checked by its authentication service.

DCE provides an integrated login facility that logs users into DCE whenever
they log into the operating system. It also synchronizes changes to the
passwords for operating system userids and their DCE principals. All
communications between a principal and the DCE Security Server are
encrypted with session keys that can be resolved only by those two
participants.
The DCE Security Server authenticates the principal and gives it an encrypted
time-stamped ticket that is passed to any process that the principal starts.
Tickets are used to indicate that the principal has been authenticated and
enable the principal to communicate in a secure way with the DCE Security
Server and with other principals in the DCE cell.
A principal’s authentication information eventually expires and must be

periodically refreshed. Servers automatically reauthenticate by using the
keytab file. Servers can also automatically reauthenticate their users, or users
can log in again to DCE when required.
When a principal requests access to a resource, the privilege service of the DCE
Security Server adds the principal’s authorization credentials to the ticket that
the principal passes to the resource manager. The resource manager
communicates with the DCE Security Server to decrypt the ticket and verify
that the principal is authorized to access the resource. The DCE Security
Server compares authorization credentials with the access control list (ACL) for
the resource. The ACL, stored in the DCE security database, identifies the
principals that are authorized to access the resource, and the type of access
that they can use. For example, the ACL for a Structured File Server (SFS) file
indicates whether a principal can read, write, create, or delete records.
DCE authentication of CICS users
The DCE process for authenticating users of a CICS region is based on the
authentication outlined in “The general DCE security process” on page 120.
The extra steps, shown in Figure 50 on page 122, are as follows:

Figure 50. Authentication of CICS users by a DCE principal and password
1. The user requests to log into the CICS region.

The CICS region looks in its runtime table of user definitions for an entry
for the user. If there is an entry, it retrieves the principal for the user. Both
the userid and password can be provided automatically by the client or
can be requested from the user. If a user accesses CICS without providing
a userid, a default userid is used.
The same userid can be used concurrently by more than one session with
a CICS region. Neither DCE nor CICS checks to see if a particular userid is
already in use.
2. The CICS region passes the request (principal and password) on to the
DCE Security Server for authentication. If the principal’s identity is
verified, the Security Server returns the user’s DCE security credentials to
the CICS region.
3. The CICS region logs in the user with the specified (or default) userid.
Only after the login is complete can the user invoke CICS functions.
The authorization for a user to access CICS resources is not determined by

DCE but by CICS authorization security. (See “Authorizing access to
resources” on page 128.)
Using the CICS default userid for DCE authentication
Each CICS region has a special userid called the default userid. This userid is
for users who access the CICS region but do not have a userid predefined in
that region’s runtime database. To maintain the security of the CICS region,
predefine the default userid with limited access to public resources only.

Authenticating communication between servers
If a server, such as a CICS region, wants to communicate with another server

in the DCE cell, it uses DCE RPCs. To make the communication secure, it
sends a request for a service ticket to the DCE Security Server. The
authentication service of the DCE Security Server prepares a ticket by
reencrypting the requesting server’s authorization credentials with the
destination server’s private key. This ticket is sent to the other server with the
first RPC, as an authenticated RPC.
Authenticated RPCs can be created with a range of protection levels, from

checking authentication only at the beginning of an RPC session to encryption
of all data sent on the session. Each server has an attribute that predefines the
level of RPC protection used on outgoing intersystem requests and the
minimum level expected on incoming requests. For CICS, these levels are the
same. Therefore, all servers that use authenticated RPCs to communicate with
CICS regions must have the same level of RPC protection predefined.
Authenticating access from systems outside a DCE cell
Systems outside a DCE cell can communicate with servers within it. (See
“Using the CDS to locate systems outside the DCE cell” on page 101.)
Preventing unauthorized access from those systems depends on whether or
not they are running in another DCE cell. If the remote system is running in
another DCE cell, you can configure both DCE cells for secure
communication. To do this, you create a principal representing the remote cell
in both DCE cells. Both principals share the same private key. The two
security databases (one in each DCE cell) are known as mutual authentication
surrogates, and the two DCE cells that maintain those surrogates are known as
trust peers. It is through those surrogates that the DCE Security Servers in each
DCE cell can convey to each other the information about their respective
principals. This enables a principal in one DCE cell to acquire a ticket to a
principal in the other cell.
If a CICS region in another DCE cell needs to communicate with servers in a

local DCE cell, the ACLs used for the servers in the local DCE cell need to
include a user entry for the CICS region in the other DCE cell. If that remote
CICS region needs to access SFS files, the ACLs for those files must also
contain a user entry for the remote CICS region.
If the remote system is not part of any DCE cell, then special precautions need
to be taken to validate and secure communication from that system. For
example, communication from a CICS region outside a DCE cell can be
treated as secure (if it is across a trusted connection) or as insecure. For
insecure communication, the receiving CICS region can assign a userid with
limited authorization specifically for that connection.

DCE security information used for CICS
This section outlines the DCE security information used to provide security in
a CICS environment. For more information, see the following sections:
v “Using CICS user definitions with DCE security”
v “DCE groups used by CICS”
v “Principals for CICS regions” on page 125
v “ACLs for SFS files” on page 125
v “DCE ACLs used in CICS” on page 125
Using CICS user definitions with DCE security
Each CICS region has a table of predefined user definitions that are loaded into
its runtime database when the region starts up. These user definitions define
the userids, CICS passwords, and DCE principals for people who can access
the CICS region.
With DCE security, the user definitions determine the DCE principal to be
authenticated for a user. When you define a CICS userid, it automatically
creates the associated DCE principal.
Users who have been authenticated by DCE are signed in to a CICS region
with either their predefined CICS userid, or a special default userid for the
CICS region. This userid is then used to control access to CICS transactions
and resources, as described in “CICS authorization security” on page 128.
DCE groups used by CICS
When the DCE Security server is configured for CICS, it defines the following
DCE Security groups for that DCE cell:
v cics_admin. Contains principals, such as the DCE principal cell_admin, for
user accounts that are permitted to administer CICS regions and the servers
that it uses. For example, to administer an SFS server, you must be
authenticated as a member of the cics_admin group.
v cics_regions. Contains principals for CICS regions.
v cics_user. Contains principals for users.
v cics_sfs. Contains principals for SFS servers.
v cics_ppcgwy. Contains principals for Peer-to-Peer Communications (PPC)
Gateway servers.
The DCE Security Server uses the principals for CICS regions, SFS servers,
and PPC Gateway servers to authenticate those servers.

Principals for CICS regions
Each CICS region establishes a DCE principal in the DCE security database
with a name derived from the region name and the prefix cics/. This principal
is known as the region principal. For example, the principal for region SALES
can be cics/SALES. The account for that region principal is made a member of
the DCE groups cics_users and cics_regions. The password for the account is
randomly generated and stored in encrypted form in the keytab file when the
region is started and is regenerated periodically as required. Only the CICS
region and a properly authorized CICS systems administrator can access the
keytab file to obtain the password of the region principal.
ACLs for SFS files
To provide security for SFS files, the SFS server can be configured to permit
access by authenticated RPCs only. When such an SFS server is started in a
CICS environment, ACLs for the SFS files are set so that only CICS region
principals are permitted access. This means that CICS users cannot access the
files directly. They must use CICS because only a CICS region can access the
files.
If you want to implement authorization security for SFS files based on

individual users, you can use authorization provided by a CICS transaction
and resource security, by a CICS external security manager, or by DCE ACLs.
(See “Using DCE ACLs with an ESM” on page 130.)
If the SFS server is run unauthenticated, ACLs are set to permit access to the
server by any principal and unauthenticated user. SFS files then permit access
by any principal.
DCE ACLs used in CICS
CICS uses the following types of DCE ACLs to define the privileges of the
DCE groups used by CICS:
v Parent container objects. These ACLs control access to the types of servers
and services used by CICS.
v Server container objects. These ACLs control access to individual CICS
regions, SFS servers, and PPC Gateway servers in the DCE cell.
v Leaf (file) objects in SFS container objects. These ACLs control access to
individual files and queues in an SFS.
The ACLs for parent container objects are created automatically when DCE is
configured for CICS. When a CICS region, SFS server, or PPC Gateway server
is created, its ACL is created automatically.

The TXSeries security model using CICS
In the CICS security model, each CICS region authenticates users and
incoming communication and authorizes access to the resources of that
system. The security service provided by a CICS region can be enhanced or
replaced by using an external security manager (ESM) called from CICS.
CICS authentication depends on user definitions in its runtime database. You

define the userids and passwords for the users permitted to use the CICS
region, and associate those user definitions with the CICS region definition.
You specify whether authentication checks are to be performed by CICS or an
ESM. CICS authorization depends on the user definitions and attributes of
other resource definitions in its runtime database.
For more information, see the following sections:

v “Authenticating CICS users by a CICS userid and password”
v “Using an External Security Manager for CICS security” on page 127
Authenticating CICS users by a CICS userid and password
For incoming work requests, a CICS region can check userids and passwords
to provide basic authentication of users. This sign-on process, shown in
Figure 51, can be enhanced by using an ESM called from the CICS region. The
server logs all unsuccessful sign-on attempts.
Note: A CICS region does not have to authenticate users. It can rely on
authorization checking and secure communications, or run without
security (for example, in a standalone development CICS region).
Figure 51. Authenticating CICS users by a CICS userid and password
CICS authentication, shown in Figure 51, works as follows:

1. To sign on to a CICS region with a specific userid, the user must provide a
valid userid and password.

2. When the CICS region receives a login request, it checks that the user’s
userid is defined in its runtime database and that the user’s password
matches the stored value. The same userid can be used concurrently by
more than one session with a server. CICS does not check to see if a
particular userid is already in use.
3. If a user accesses CICS without signing on, a default userid is used to give
minimal authority to run transactions.
4. For local 3270 terminal emulators (connected directly to a CICS region),
users are logged into CICS with the default userid.
5. When logged in to a CICS region, a user can use the CESN transaction to
change the userid and password. The new userid and its related authority
remain associated with that session until the user signs off or changes to
another userid.
6. Users accessing a CICS region from an IBM CICS Client can provide a
userid and password automatically, and therefore sign on to CICS without
the user needing to do anything. This process is described in “Connecting
and authenticating IBM CICS Clients” on page 93.
Using an External Security Manager for CICS security
You can use an ESM instead of, or with, CICS internal security to authenticate
CICS users and authorize access to CICS transactions and other resources. The
ESM is a user-supplied program that allows you to define your system’s own
security mechanism for preventing unauthorized access to resources from
application programs and the unauthorized initiation of CICS transactions.
(CICS provides a sample ESM module to demonstrate the interface that you
need to conform to if you choose to write your own ESM.) You must identify
the ESM to the CICS region at startup; you possibly need to identify the CICS
region to the ESM.
CICS passes information about the user, transaction, and resource to the ESM.
The ESM uses this, and possibly other information such as DCE ACL entries,
to determine whether authorization is allowed. The CICS region must then be
informed, through the interface, of the ESM’s authorization decision.
If you change the ESM during the life of a region, you must perform a warm
start to make the ESM valid for all application servers. Otherwise, the
changed ESM applies only to tasks running under application servers started
after the ESM was changed, which can lead to inconsistencies in security
within the region.
It is best to design your ESM so that it stores its data separately from the
program itself. You can then access security data at all times, without needing
to restart CICS.

Authorizing access to resources
Authorization ensures that users have the credentials (also known as

permissions) needed to access resources. You can make your servers more
secure by restricting user access to specific transactions and other resources.
This authorization security is based on ACLs. Each entry in the ACL identifies
which transactions and other resources a user can use.
In a DCE cell, RPCs can be used to restrict access to resource managers from
only properly authenticated servers. To restrict access for specific users, you
can use CICS authorization security or an ACL manager for DCE ACLs.
CICS provides authorization security by its transaction and resource security,

which can be used even if you are using DCE security. This provides
authorization for CICS’s own resources and any resources accessed through
CICS. CICS authorization security is based on keys predefined for CICS user
definitions, terminal definitions, and other resource definitions in its runtime
database. You can use an external security manager to provide extra or
different authorization security; for example, for network resources based on
DCE ACLs. For more information, see “CICS authorization security”.
Access to the resources in an Encina Monitor cell is controlled by the DCE

security service. When a transaction requests access to a resource, the Monitor
application server and resource manager negotiate with the DCE Security
Server to verify authorization, as outlined in “The general DCE security
process” on page 120.
CICS authorization security
CICS implements authorization checking in the following two ways:

v Transaction security
v Resource security
Both techniques are based on the use of security keys. Each transaction and
other resource in the CICS region has a predefined key. Several resources can
have the same key, forming a group of resources with the same
authorizations. Resources can also be defined as public (if available to all
users) and private (if available to only specially trusted transactions). Each
user has a predefined set of keys that must match the keys of transactions and
other resources that the user needs. Keys used to authenticate user
transactions are called transaction level security (TSL) keys, and keys used for
other resources are called resource level security (RSL) keys.

Figure 52. CICS transaction and resource authentication
Consider the example shown in Figure 52 where a user attempts to run two
transactions and use them to access two files. The following actions take
place:
v The user is predefined to run transactions with TSL keys 1, 2, 4, and 7, and
to use those transactions to access resources with RSL keys 1, 5, 8, and 11.
v A request for TRN1 (predefined with TSL key 7) succeeds, because the user
has a matching TSL key. However, a request for TRN2 (predefined with TSL
key 6) fails, because the user does not have that TSL key.
v The user runs TRN1, which tries to read several files. The request for FILE1
(predefined with RSL key 1) succeeds, because the user has a matching RSL
key. The request for FILE2 (predefined with RSL key 3) fails, because the
user does not have that RSL key.
v Any attempt to access an unauthorized transaction or resource returns an
error to the application program and adds an entry in the system log.
The same authorization checking can be used for terminal devices

communicating with CICS without an associated user. The terminal definition
predefines the TSL and RSL keys that it can use.

Using DCE ACLs with an ESM
CICS internal security cannot use DCE ACLs and authenticated RPCs to
restrict access to specific users. Instead, it uses RSL and TSL keys to determine
which users can run which transactions and access which resources. You can,
however, write an ESM that uses ACLs to authorize specific users to run
transactions and access resources. For example, an ESM can enable you to
restrict some users of a CICS region to read-only access for a file while other
users of that CICS region have write access for that file.
Security considerations for IBM CICS Clients
When a CICS Client connects to a CICS region, the region can require that the
client provide a default userid and password to be used for all requests from
the client. The client can automatically provide the default userid and
password (by using a file); otherwise, the client user is prompted to enter
appropriate values. The server then uses its standard user authentication to
determine the identity and authorization of the userid. (See “The TXSeries
security models” on page 117.)
If this userid has insufficient authority to process a request, the client can
automatically send a new userid and password for External Call Interface
(ECI) requests or, for External Presentation Interface (EPI) and 3270 terminal
emulation requests, prompt the client user to enter a new userid and
password. For 3270 terminal emulation requests, you can also specify that the
first transaction used (on the server) is the CICS sign-on transaction, CESN.
This forces the user to enter a valid userid and password.
For more information, see “Connecting and authenticating IBM CICS Clients”
on page 93.
Notes:
1. You can restrict the ability of client users to connect to servers by
protecting the command used to connect clients.
2. You can use normal workstation security facilities to restrict use of a client
workstation.
3. If a client uses the CICS Transaction Gateway, you can also use Web
security to secure user access to CICS from web browsers.
Web security services
You can make your own network secure by using authentication and
authorization. If your network is connected to the Internet, you can create a
security barrier, called a firewall, between your network and the Internet, and
you can make your communications across the Internet more secure. A
firewall forms a barrier between a secure, internal, private network and

another, nonsecure, network like the Internet. Internet users can be given
permission to connect from the Internet through the firewall to gain access to
data on the company’s legacy systems, available through the internal network.
The IBM SecureWay Software products provide integrated directory,

connectivity, and security between users and application for e-business. For
example, IBM SecureWay FirstSecure provides a comprehensive framework to
help companies secure all aspects of networking via the Web and other
networks. FirstSecure provides virus protection, access control, traffic content
control, intrusion detection, encryption, digital certificates, firewall, tool kits
and implementation services.
The security from a web browser to the CICS Transaction Gateway (via the
web server) is provided by the following Internet communication standards:
v Secured Hypertext Transport Protocol (S-HTTP)
v Secured Sockets Layer (SSL)
These ensure that information is encrypted and arrives safely at its intended
destination. In addition, the CICS Transaction Gateway offers the following:
v Authentication, via built-in support for userids and passwords that are
authenticated by CICS applications servers. The gateway also provides an
External Security Interface (ESI) that enables customer applications to verify
userids and passwords and to change expired passwords.
v Authorization, which is provided as a standard function of each CICS
server, enabling customers to control what transactions a given end user
can run and what data that user can access.
Security considerations for CICS Telnet clients
Any Telnet client that knows the port that a CICS Telnet server is listening on
can use that server to access CICS. Therefore, to create a secure CICS Telnet
environment, the following actions are recommended:
v Require Telnet clients to sign on to CICS by ensuring that the Telnet Server
always invokes the CESN transaction as the first transaction. (You do this
by starting the Telnet Server with a special option.) If CESN fails, the user
is signed on as the default userid. Therefore, define the default userid with
restricted access.
v Restrict execution access to the Telnet server program to a small and
controlled set of operating system userids. You can do this by altering the
permissions on the program executable.
v If you are using DCE security, set up the Telnet server program to run with
the DCE principal that you have defined for the region’s default userid.
This means that Telnet client users are given the same access as you have
set up for unauthenticated users. Alternatively, you can create a principal

and matching CICS userid specifically for the Telnet server. When a Telnet
client requests connection to a region, the Telnet server reads the keytab file
where the principal and password are stored and passes the principal as a
userid to CICS. The region then searches for a user definition that matches
the principal and, if found, uses that as a userid to log into the region. The
user is then given access to those transactions and resources predefined for
that userid.
Security considerations between CICS and XA-enabled databases
All transactions that run on a CICS region access XA-enabled databases by

using the same database userid and therefore have the same authorization for
resources in the databases. (This userid is predefined as an attribute of the
CICS region.) To provide more security for database access, you can use CICS
security to control access to the CICS region and to specific resources, such as
the transactions that can access databases and files that are stored on the
databases.
Ensuring secure communications
A system receiving communication from another system is concerned with the

following:
v Authenticating the remote system that sent the request
v Authenticating the user that initiated the request
v Authorizing access to its resources
In a DCE cell, both CICS and Encina can use authenticated RPCs to protect
communication between systems. The authentication checks are made by the
DCE Security Service.
CICS intercommunication provides extensions to CICS security for a single,

standalone region to allow security checks for intersystem requests. CICS
intercommunication security checks are made by the CICS region receiving
the request.
Authenticating the remote system that sent the request
When systems connect, they pass identification information across the

network. This identification information can be trusted only if the
communication method provides the facilities to verify it. How a system can
authenticate the system that sends an intersystem request depends on the
communication method, as follows:
CICS family TCP/IP
These connections, which can be used by CICS regions, provide no

mechanisms for authenticating remote systems. CICS can extract the
Internet Protocol (IP) address and listening port of the remote system,
but this is easy for an unauthorized system to imitate. If your network
is private and secure, this is not a problem for you. If you wish to
avoid this potential security risk, configure your CICS region to
provide more restrictive security appropriate to the connection or
consider using one of the other communication methods, such as PPC
TCP/IP.
PPC TCP/IP
PPC TCP/IP uses a DCE RPC request to acquire a connection. CICS
and Encina systems in a DCE cell can send security information with
DCE RPCs. The DCE Security Server verifies this security information
so that the system receiving the communication can be sure of the
identity (DCE principal) of the system that is acquiring the
connection.
These authenticated RPCs enable communication to be checked for
tampering or encrypted for privacy. The level of secure
communication is controlled through protection levels. Both systems
involved in a communication must be at sufficiently high protection
levels or the communication cannot proceed.
Local Systems Network Architecture (SNA)
When an SNA connection is acquired, sessions are activated in both
systems by exchanging encrypted bind flows. You can use SNA to
automatically verify the identity of each system by defining a bind
password for the connection. Sessions are then activated only if both
systems have the same bind password. This process is known as
bind-time security or Logical Unit-Logical Unit (LU-LU) verification. It
enables each system to verify the identity of the other system.
PPC Gateway/SNA
The SNA connection from the PPC Gateway server to the remote
(SNA) system can be protected by using bind passwords, and the
connection between the local (TCP/IP) system and the PPC Gateway
server can be protected by using DCE security (authenticated RPCs).
Therefore, the local system can verify that an incoming request comes
from a trusted PPC Gateway server, and the PPC Gateway server can
verify that the outbound SNA requests are coming from an authorized
local system.
Authenticating the user that initiated the request
A CICS Client or CICS region can send a userid (and optionally a password)
on a CICS intersystem request. The receiving CICS region can then use that
flowed userid or a userid that is defined locally to control access to its
resources.

You can specify that userids must be sent with a password for CICS family
TCP/IP connections to CICS for OS/2, or when the local SNA product you
are using is one that passes the password to CICS. Otherwise, you can specify
that incoming requests must be from a trusted system as follows:
v When the remote system does not send passwords with userids. This
applies to other CICS regions and CICS for MVS/ESA systems.
v When the SNA-connected system does send passwords, but the SNA
product you are using verifies the password and does not pass it to CICS.
Receiving userids from SNA-connected systems
The SNA LU 6.2 architecture has optional support for flowing userids and
passwords between SNA connected systems. This is called conversation-level
security (or sometimes attach security or conversation security). As this security is
optional, each system needs a definition of the level of security it is able (or
wishes) to accept from a particular remote system. You can set up a different
conversation security acceptance level on each end of a connection between two
systems. The possible levels of security acceptance are as follows:
Conversation-level security not supported or required
Userids and passwords cannot be sent to this system. Sending them is
considered an SNA protocol violation.
Conversation-level security supported
Userids can be sent to this system but must be accompanied by a
valid password. This level is used to receive userids from a system
that does not have its own security manager and so cannot verify its
own users (as with CICS for OS/2).
Already verified supported
Userids can be sent to this system without a password because the
remote system is trusted to have verified the userid against a
password before the intersystem request was sent. CICS for
MVS/ESA, CICS/ESA, CICS/MVS, CICS/VSE, and CICS on Open
Systems always send verified userids. A SNA-connected system that
wishes to receive userids from those CICS regions must accept
already-verified userids.
Persistent verification supported
The verification for a userid and password pair persists over a
number of intersystem requests. Both the userid and password are
sent on the first request. Then, if they are valid, only the userid is
required on subsequent requests. The userid can be sent without a
password for a user-defined period of time, or until the initiating
system sends a sign-off request.

Both Already verified and Persistent verification supported
Allows both already verified requests and requests that use persistent
verification.
The security acceptance levels available to you depend on the support

provided by your local SNA product.
Note: Microsoft SNA Server does not allow CICS regions to flow
already-verified userids with intersystem communication outbound
requests.
Authorizing access to resources
For requests received from another system, access to CICS resources is

authorized by using an extension to the resource security used for a single,
standalone CICS region. (See “CICS authorization security” on page 128.) The
transactions and other resources that a request can access are controlled by the
security keys assigned to the request. These keys can be from TSL and RSL
key masks defined for the connection, from key lists of a link userid defined for
the connection, and from key lists defined for a userid associated with the
request. The key lists and key masks can be combined to restrict the security
keys further so that an intersystem request has less access to the region’s
resources than a local user with the same userid. There are two methods of
determining the keys to be used:
Link security
The security keys defined in the key mask or link userid’s key list for
a connection must include all the keys needed by every user who can
make a request to a remote system. If a link userid is defined for the
connection, the user is logged in to the remote region as that userid,
and the user’s security keys are restricted to those for the link userid.
If no link userid is defined, the user is logged in to the remote region
as that region’s default userid and the user’s security keys are all
those in the connection’s key masks. Use of a link userid is the
preferred method.
User security
The user is logged into the remote region as either a flowed userid (sent
with the connection request) or the remote region’s default userid. The
user’s security keys are restricted either to those for the assigned
userid that match the key masks for the connection or further
restricted to keys that match those for a link userid defined for the
connection. Use of a link userid is the preferred method.

Chapter 8. Application development
This chapter describes the application development environment provided by
TXSeries. It contains the following topics:
v “Designing transaction processing applications”
v “CICS application programming” on page 139
v “Encina application programming” on page 144
v “Application programming for relational databases” on page 151
v “Application development tools” on page 151
Designing transaction processing applications
A common design of a transaction processing application is a three-tiered

client/server design as shown in Figure 53. The tiers are as follows:
v Presentation logic (client)
v Business logic (server)
v Data services (resource manager)
Figure 53. General 3-tier application programming
Presentation logic
Presentation logic is used for communications between the end user
and the transaction processing system. Presentation logic in an

application program uses these services to interact with the
presentation management facilities of the server. The services are
typically provided by a client.
Business logic
Business logic forms the bulk of an application program and performs
the data manipulation and computation required by transactions.
Business logic is typically subdivided into several modules, each
providing a separate service. For example, you can divide an
application into modules for the following:
v Checking the validity of input data
v Handling communications
v Performing data access
v Accessing system information
v Setting up the processing environment
v Requesting system services
This technique of dividing up business logic is known as isolation.

Designing applications in this way has the following benefits:
v Enhanced portability for distribution of applications across multiple
servers and different platforms
v Enhanced programmer productivity because code can be reused in
other applications
v Reduced maintenance costs because similar functions are grouped
together, making it easier to locate and modify code
v Well-defined interfaces, making it easier to add new modules or to
replace outdated ones
Data services
Data services, provided by resource managers, are used to retrieve
and update data.
There are several advantages to the three-tiered client/server approach shown

in Figure 54 on page 139:
v It simplifies writing the client program. The client needs only to know that
it has requested an operation; it does not need to know how to perform the
operation.
v It makes it easier to change implementation details. If you decide to add to
the business logic, only the server needs to be changed. For example, a
Microsoft SQL Server can be replaced by a DB2 database without modifying
the clients.
v It minimizes the number of calls that the client needs to make to a server.
For example, a client can request that an item be ordered (one call to the
server); the operations for checking the item, changing the inventory,

sending a bill, and queueing the item for shipping can all be done by the
server (eliminating several calls to the server, one for each of the
operations).
v It provides better application security because only the server needs to
access the database.
For information about application programming for distributed transaction

processes, see the CICS Intercommunication Guide.
CICS application programming
Customer Information Control System (CICS) provides standard application

programming interfaces (APIs) for both IBM CICS Clients and CICS regions.
Figure 54. CICS application programming
These APIs are described in:

v “IBM CICS Clients programming”
v “CICS region application programming” on page 143
IBM CICS Clients programming
CICS provides the following two APIs that enable non-CICS applications on a
client machine to use the facilities of connected CICS regions. These APIs,
common to all IBM CICS Clients, are as follows:
v “The External Call Interface” on page 140
v “The External Presentation Interface” on page 141
IBM CICS Clients also provide you with access to CICS regions from the
Internet.
Chapter 8. Application development 139

For more information about developing client applications to use CICS, see:
v “Developing ECI and EPI application programs” on page 142
v “Developing Internet applications that use CICS” on page 142
Some Graphical User Interface (GUI) builders, such as IBM’s VisualAge,

integrate the CICS client program into the tools.
The External Call Interface
The external call interface (ECI) enables a non-CICS application running on

the client machine to call a CICS server program running on a CICS region.
The client program can call the server program synchronously or
asynchronously as a subroutine. The client application communicates with the
CICS server program by using a data area called a COMMAREA, which is
passed to the CICS region on the call. The CICS server program typically
populates the COMMAREA with data accessed from files or databases, then
returns data to the client for manipulation or display. The CICS server
program cannot perform terminal I/O, but can access and update all other
CICS resources.
The ECI enables the design of new applications to be optimized for

client/server operation (the ECI is the recommended interface for developing
new client/server applications). Its call structure easily divides the
presentation logic (usually in the client) from the business logic in the CICS
server application, offering application designers maximum flexibility. As an
example, the ECI can be used with mainframe CICS applications that are
already divided into business logic (in the application-owning region) and
presentation logic (in the terminal-owning region). The business logic can
remain unaltered when the presentation logic is developed to use the ECI.
With the ECI, you can write applications that do the following:
v Call a CICS program in a CICS region from a non-CICS program
v Connect to several servers at the same time
v Have several outstanding program calls at the same time
v Access CICS programs, files, transient data queues, temporary storage, and
transactions
v Exchange data between the client and the server
Synchronous calls made by an ECI application return control when the called
server program completes; the information returned is immediately available.
Asynchronous calls return control without waiting for the called server
program to complete, and the ECI application is notified when the
information becomes available.

Calls can be extended; that is, a single logical unit of work can cover more
than one successive call, though only one call can be active for each logical
unit of work at a time. The application can manage multiple logical units of
work concurrently if it uses asynchronous calls.
The called server program can do the following:

v Update resources on its own CICS region
v Use distributed program link (DPL) to call programs on other CICS regions
v Access resources on other CICS regions by using function shipping or
distributed transaction processing (DTP)
The ECI provides the following three types of calls:

v Program link calls that cause a CICS program to be executed on a CICS
region
v Status information calls that retrieve status information about the
application and its connection to the CICS region
v Reply solicitation calls that retrieve information after asynchronous program
link or asynchronous status information calls
With the ECI, you can also retrieve information about available servers to
which the calls are directed.
The External Presentation Interface
The External Presentation Interface (EPI) enables client applications to start

and converse with legacy 3270 CICS applications running on CICS regions.
The CICS application sends and receives 3270 data streams to and from the
client application as though it is conversing with a 3270 terminal. The client
application captures these data streams and, typically, displays them with a
non-3270 presentation product, such as a GUI. The EPI is therefore a method
of enhancing an existing CICS application by adding a graphical or other
modern interface. The CICS application itself does not need to be altered.
With the EPI, you can write applications that do the following:
v Allow a non-CICS application program to be viewed as a 3270 terminal by
a CICS region to which it is connected
v Connect to several servers at the same time
v Have several outstanding program calls at the same time
v Schedule transactions that send output to client applications
When a transaction is initiated, 3270 data streams and events are passed
between the CICS region and the EPI-connected application. The application
can present the contents of the terminal I/O to its user in any appropriate

way. Transactions can be routed to other CICS regions by standard transaction
routing. Resources on other CICS regions can be accessed by function
shipping.
The EPI consists of functions, data structures, and events. The EPI functions
define application programming calls, such as installing new terminals to be
controlled by a process, sending data from a terminal, and terminating the
process. The EPI data structures define EPI data, such as reason codes, details
of events, terminal details, and sense codes. The EPI events are used to
respond to events, for example, when a transaction sends data and expects a
reply.
Developing ECI and EPI application programs
ECI and EPI application programs that run on CICS clients can be written in
COBOL, C, or C++. Programs that do not make operating-system-specific calls
are portable between the CICS client products. Client application programs
can use both the ECI and the EPI. To use the ECI and EPI, programs must be
linked to the appropriate ECI and EPI libraries.
For more information about client programming, see the CICS Family:
Client/Server Programming book.
Developing Internet applications that use CICS
Developing Internet applications that use CICS is an extension to normal

programming for the Internet, and uses the standard interfaces of Web
servers. By using programs invoked by a Web server, you can run CICS
transactions from a Web browser, dynamically create Hypertext Markup
Language (HTML) pages in response to user input, and issue Structured
Query Language (SQL) queries to relational database managers.
An Internet application using the CICS Transaction Gateway generally

contains the following:
v An HTML form, which presents a user with a Web page for entering data
and sends user input to the CICS Transaction Gateway whose name is
encoded in the form. This form can be developed by using standard Web
development tools and processes.
v The CICS Transaction Gateway, which is a Java application called to convert
between HTML and 3270 data streams.
v A program to be invoked on a CICS region. The program can be developed
by using the standard CICS application development facilities.
The CICS Transaction Gateway provides the following:

v All functionality of the CICS Universal Clients Version 3.0, for
communication with CICS servers.
v A set of Java EPI beans for creating Java front ends for existing CICS 3270
applications, without any programming. This enables Java applications or
applets to be created by using a tool such as VisualAge for Java.
v Implementations of the ECI and EPI programming interfaces in C, C++, and
COBOL, and as COM objects.
CICS region application programming
CICS offers a standard set of commands used by application programs to

request services from CICS regions. This set of commands is called the CICS
application programming interface (API). Because the API is common to all CICS
family members, CICS applications can be moved from one platform to
another.
The commands are abstracted statements that you include at appropriate

points in your application program to perform a variety of programming
functions. (This abstraction hides the complexity of the underlying services
needed for distributed, recoverable transaction processing applications.) The
following example shows how to read a record identified by its name (the
RIDFLD parameter) from a file named MASTER into a specified data area:
EXEC CICS READ FILE('MASTER') RIDFLD(ACCTNO) INTO(RECORD)
Notes:
1. CICS on Open Systems supports approximately 95 percent of the CICS
API commands provided by CICS for MVS/ESA. The main differences are
in Basic Mapping Support (BMS) and Systems Programming Interface
(SPI) commands.
2. When migrating applications, note that some commands are not available
with all CICS products. For details about the commands available, see the
application programming information for each CICS product, and the
CICS Family: API Structure book.
3. CICS on Open Systems supports command-level, but not macro-level,
application programs.
4. Application programs are not limited to using only the CICS API; they can
use operating system calls, other product calls, and imbedded SQL calls.
Reference information about the CICS commands available (on all CICS
platforms) is in the CICS Application Programming Reference. For information
about preparing applications developed on other platforms to run with CICS
on Open Systems, see the CICS Application Programming Guide.

The CICS IIOP ORB
The CICS Internet Inter-ORB Protocol (IIOP) Object Request Broker (ORB)
enables CICS applications to communicate with applications that use the IIOP
protocol that was defined as part of the Common Object Request Broker
Architecture (CORBA). CORBA clients can use communicate with CICS
applications, and CICS applications can send requests to CORBA servers.
The CICS IIOP ORB supports the following functionality:

v Inbound IIOP from any CORBA-compliant client
v Outbound IIOP to any CORBA-compliant server
v Object interfaces defined in the CORBA Interface Definition Language (IDL)
v Object implementations written in Java
v The use of server groups for load balancing
v The Secure Socket Layer (SSL) protocol
Java can be used as a programming language for traditional CICS programs

as well as for CICS IIOP object implementations. In either case, access to CICS
facilities from Java is gained by using a set of Java classes. There is no CICS
translator for Java; a CICS Java application is compiled.
Encina application programming
An Encina application, as shown in Figure 55 on page 145, is a client/server

application that typically runs in the Encina environment. Writing Encina
applications is described in detail in Writing Encina Applications.
Encina applications use one of the Encina transactional interfaces such as

Transactional-C (Tran-C) to manage transactions. They can also use other
Encina interfaces such as the Recoverable Queueing Service (RQS), Structured
File Server (SFS), and Peer-to-Peer Communications (PPC) interfaces. Encina
applications can be written in C, C++ (using the Encina++ interface), or
COBOL (using the Monitor COBOL interface).

Figure 55. Encina application programming
The remainder of this section contains information about programming in the

Encina Monitor environment.
The Encina Monitor Application Development Environment
The Monitor provides a number of features that simplify the writing of

application programs:
v Transparent binding. The client simply makes a remote procedure call
(RPC), and the Monitor chooses an appropriate server.
v Simplified initialization. The Monitor performs most of the initialization
needed by both client and server; the application does not need to initialize
each of the underlying components individually.
v Ease of scheduling and load balancing. A Monitor application server can
consist of multiple processing agents, each of which executes the server
code. The Monitor also enables administrators to assign priorities to servers.
For example, an administrator can assign priorities so that servers on more
powerful machines service more RPCs.
v Automated recoverability. The server needs to call only a single function
during initialization. The Monitor handles all other aspects of making the
server recoverable, including initializing and using the Encina Log and
Recovery Services.
v Simplified access to Distributed Computing Environment (DCE) services.
The Monitor simplifies the use of many of the other underlying DCE
features in addition to RPCs and the Cell Directory Service (CDS). For
example, many aspects of security are handled automatically by the
Monitor.

The Monitor development environment consists of application development
tools, languages, and libraries for developing Monitor applications. Monitor
applications are developed by using the Monitor API in conjunction with
other interfaces.
Interface Definition
An interface is a group of RPCs that a server makes available to clients. All

functions that make up the interface must be defined in a transactional interface
definition file (IDL file) using the Transactional Interface Definition Language
(TIDL), Encina’s extension to the DCE interface definition language (IDL). The
TIDL compiler is then used to generate the code that turns local procedure
calls into RPCs.
Each interface is made up of one or more related functions. Servers can offer
one or more interfaces to clients. The clients then invoke the functions in that
interface by using RPCs.
Transactional Interfaces
The Encina Toolkit provides several interfaces for managing transactions. Each
of these interfaces includes methods for starting and ending (committing or
aborting) transactions, retrieving information about transactions, and
performing other transactional work. The interfaces are as follows:
v Tran-C
v TX (the X/Open standard transactional interface)
v The Distributed Transaction Service (TRAN)
v Tran-C++
v The Object Management Group Object Transaction Service (OMG OTS)
Tran-C and Tran-C++ provide a number of features used by transactional

applications. They provide several constructs for delimiting transactions. They
also automatically associate a transaction with a thread of execution and
handle the flow of control, automatically transferring execution to the
appropriate location if a transaction aborts.
To delimit a transaction in Tran-C or Tran-C++, the application program

simply groups those actions inside of the transaction construct. Encina
handles all the details of coordinating the transaction and backing out changes
if the transaction aborts.
Encina RQS API
RQS enables applications to queue transactional work to be completed at a

later time. Applications can then commit any existing transactions with the

assurance that the queued work is not lost. RQS guarantees that once an
element is added to a queue and the transaction commits, the element
remains in the queue until dequeued by another transaction.
RQS applications queue and dequeue elements to queues that are maintained
by an RQS server. Applications queue elements to specific queues.
Applications can dequeue from specific queues or from a queue set (a group
of queues that implements prioritized dequeueing). Applications can also
access elements by element IDs, by key, or by using cursors to scan elements
in a queue.
RQS provides interfaces in both C and C++.

Encina SFS API
The SFS is a record-oriented file system that provides transactional integrity,

log-based recovery, and broad scalability. SFS supports record-oriented file
types. SFS organizes the records into fields and provides both record-level and
field-level access to data. Access to the records is through indices, enabling an
application to easily and quickly access records based on one or more fields in
the record.
Applications can access SFS files sequentially and randomly. For random
access, an index is used to locate a single record that matches an index key
value. Sequential access involves using key values to select multiple records
and then sequentially stepping through those records (either forward or
backward).
SFS provides interfaces in both C and C++.

Encina PPC API
The PPC Services enable Encina applications to interact with applications

running in Systems Network Architecture (SNA) networks, typically on
mainframes. Encina PPC provides two interfaces that can be used by
applications:
v The Common Programming Interface-Communications (CPI-C), as specified
by the IBM and X/Open standards.
v CICS Distributed Program Link (DPL).
The CPI-C interface provides a number of services, including the following:

v Allocating, accepting, and deallocating conversations
v Sending and receiving data
v Synchronizing processing between programs
v Notifying peers of errors

The Common Programming Interface-Resource Recovery (CPI-RR) is used
with CPI-C to manage synclevel syncpoint (transactional) conversations.
Encina DPL provides a way for Encina applications to communicate with

CICS applications by using a mechanism that is conceptually similar to an
Encina transactional remote procedure call (TRPC). DPL allows Encina
applications to interact with CICS DPL applications (that is, CICS applications
that use the EXEC CICS LINK command) and other Encina DPL applications.
Encina COM API
The Encina Component Object Model (COM) API is available on Windows NT

systems. The Encina COM API enables clients to interact with Encina and
Encina++ servers, manage transactions, and manage DCE login contexts.
Microsoft COM is a model for developing applications composed of

individual components that can be transparently and separately upgraded.
When using COM, Windows applications can be developed as multiple
components rather than as a single entity; this enables the application to be
distributed more easily. For more information on COM, consult the
appropriate Microsoft documentation.
One of the most important aspects of COM is that a COM component can be
used to create an application in any language. Once instantiated in a client, a
COM object acts as a proxy for the client, marshaling and unmarshaling data
to contact a server and returning data and status information back to the
client.
From an Encina point of view, COM enables you to develop clients that use
Encina COM components to contact Encina servers, manage transactions, and
manage DCE login contexts simply by instantiating Encina COM objects and
calling standard members functions on those objects. The Encina COM
components transparently handle many of the tasks normally required of an
Encina client.
comtidl and midl
To create a COM component that acts as an interface between a client and an

Encina server, you define an interface in a standard Encina TIDL file. The
TIDL file is then compiled by using the Encina comtidl compiler. In addition
to some source and header files, this compiler creates a DCE IDL file and a
Microsoft Interface Definition Language (MIDL) file. The DCE IDL file must
be compiled by using the DCE idl compiler and the MIDL file must be
compiled by using the Microsoft midl compiler. The resulting object files from
these three compilations are then linked with Encina and DCE library files to
create the Encina COM component in the form of a DLL file. This type of
COM component is known as an in-process COM component.

The majority of the tasks associated with creating an Encina COM component
can be hidden from the user by using the Encina COM Wizard. In fact, all you
need to do is create the TIDL file, process it by using the Encina COM Wizard,
and build the resulting project. The Encina COM DLL file that is created can
then be used with the prepackaged Encina COM DLLs (and non-Encina COM
DLLs) to develop Encina clients.
Remote Procedure Calls
Within the Microsoft Transaction Server, client/server communications by way

of COM is handled by using a Microsoft RPC. However, client/server
communications between an Encina COM-based client and an Encina
application server is done by using a DCE RPC. This provides the added
advantage of DCE naming and security.
Because Encina COM-based clients use DCE, the machine on which such a
client is developed or run must be configured as a DCE client.
The Encina COM component completely wraps the Encina interface and stub
functionality. To the client programmer using an Encina COM component,
nearly all of the underlying client/server interactions are transparent.
Naming and binding
When a COM-based Encina client needs to access an Encina server, naming

and binding are handled by the corresponding DCE and Encina services,
rather than the Microsoft equivalents.
Encina++
Encina++ is an object-oriented API for Encina. It is composed of classes that

access many Encina components. Encina++ supports the development of
object-oriented applications that are based on DCE (Encina++/DCE), CORBA
(Encina++/CORBA), and a mixture of both DCE and CORBA
(Encina++/CORBA-DCE). The latter type of application is often referred to as
a mixed application.
Of the components that make up Encina++, some can be used only with
Encina++/DCE or only with Encina++/CORBA, while some can be used by
either or both.
The following Encina++ components can be used in any type of Encina++

application:
v The Encina++ interface defines C++ classes and member functions that
enable the creation and management of client/server applications and
provide support for the underlying environment.

v The Transactional-C++ (Tran-C++) interface defines C++ constructs and
macros as well as classes and member functions for distributed transaction
processing. This interface provides an object-oriented alternative to the
Encina Transactional-C interface.
v The Object Management Group Object Transaction Service (OMG OTS) interface
also defines C++ classes and member functions for distributed transactional
processing. This interface implements the OMG Object Transaction Service
specification as documented in OMG document 94.8.4.
The Encina++ programming interfaces that are supported only for DCE
(including mixed applications) provide object-oriented access to two types of
Encina servers offering specialized services:
v The Recoverable Queueing Service C++ interface (RQS++) defines C++
classes and functions for enqueueing and dequeueing data transactionally
at an RQS server.
v The Structured File Server C++ interface (SFS++) defines C++ classes and
functions for manipulating data stored in record-oriented files at an SFS
server while maintaining transactional integrity.
The Encina Data Definition Language (DDL) compiler is used to generate the
classes used by RQS++ and SFS++ applications.
Encina++ provides two programming interfaces that are supported only for
CORBA (including mixed applications): one defines a locking mechanism for
CORBA-based servers, and the other enables you to develop Java
transactional clients that can communicate with Encina++ servers.
Encina tools available only on Windows platforms
On both Windows NT and Windows 95 systems, Encina provides the

following programming and diagnostic tools:
v Encina Server Wizard—This wizard, which can be used to create Encina
and Encina++ servers, generates much of the standard initialization code
for the server, organizes the code into a project, and associates the
appropriate Encina and system libraries required to build a server.
Depending on the type of server being created, this wizard invokes the
DCE and CORBA idl and the Encina tidl compilers to create the required
source and header files.
v Encina COM Wizard—This wizard is used to create an Encina COM
component (in the form of a DLL file) from an Encina TIDL interface. It
invokes the Encina comtidl compiler, the Microsoft midl compiler and the
DCE idl compiler to produce a COM project. After the COM project is used
to compile the Encina COM DLL file, the file can then be incorporated into
a client written in any language to enable that client’s access to any Encina
server that exports the interface defined in the DLL.

v The WinTrace tool—This tool aids developers in debugging distributed
client/server applications. This Encina-specific tool is used to format and
view application output and Encina trace files and to translate error codes
and trace identifiers. It can also be used to start Encina Trace Listener
servers for use in viewing output while a process is running.
For more information on developing applications that use the Encina COM
API, see “Encina COM API” on page 148.
Application programming for relational databases
Application programs running under CICS or Encina can access data held in
relational databases. To access such data, the application programs issue SQL
calls to the database. An application program must be precompiled with the
appropriate Relational Database Management System (RDBMS) precompiler,
linked to appropriate RDBMS libraries, and generally needs some way of
defining which database the program’s SQL calls are to be used on.
Both CICS and Encina use the underlying Transaction Manager Service
(TM-XA) to map transaction events to XA calls. TM-XA translates all
information about transaction context and scope into appropriate XA calls that
it sends to the XA resource manager (database). It uses the XA protocol to
communicate transaction prepare, commit, and abort states to resource
managers involved in those transactions.
Application development tools
TXSeries provides a range of tools for developing user application programs.

Application development tools are also available from third-party vendors.
CICS application development environment
This section provides an overview of the development and debugging tools

provided by and for CICS.
Presentation interface development
You can develop presentation interfaces that make use of client ECI and EPI
interfaces and the local 3270 terminal interface. With ECI calls, the
presentation interface on the client makes no use of CICS presentation
functions and communicates directly with a user application program on the
CICS region. With client EPI calls and calls to local 3270 terminals, the
presentation interface makes use of CICS 3270 terminal support on the CICS

region. The application program on the CICS region uses CICS Basic Mapping
Support (BMS) to construct 3270 data streams to be interpreted by the
presentation interface.
You use the CICS BMS processor to translate BMS source files, which contain
the definitions of map sets, into a symbolic map and a physical map. The
symbolic map is a programming source language data structure (a C or C++
structure) used by the compiler to resolve source language references to fields
in the map. The physical map contains the information necessary to display
the map on a physical terminal and instructions for embedding control
characters within a data stream to achieve this display. You can create
different national language versions of the same physical map, and leave it to
the CICS region to determine automatically the appropriate map to display
for the language defined for a client user.
Application program translation
Application programs that include CICS API commands are processed by the
command language translator that translates the CICS API commands into
statements in the language used. This translator accepts as input a source
program written in COBOL, C, C++, or PL/1 where CICS API commands are
coded, and produces as output an equivalent source program where each
command is translated into statements in the language of the source program.
You can then compile and link-edit your programs by using the COBOL, C,
C++, or PL/1 compilers.
Alternatively, you can request that your source program be translated,

compiled, and link-edited in one step. This has the advantage that CICS uses
the correct compilers and sets up the options required by CICS for translation.
Application program debugging
CICS provides the Execution Diagnostic Facility (EDF) for debugging an

application program. In an EDF session, the CEDF transaction displays the
state of the application program at the CICS interception points and allows
you to interact with the debugging tool before returning control to the
application code. To obtain additional debugging information, you can also
add user-defined interception points to your application programs.
You can also use the CICS-provided CECS transaction to interactively check
the syntax of commands used in your application programs.
Using transactions to call your program
When you develop your application program, you associate it with a

transaction that is used to request the program. To do this, you define both

the transaction and program to CICS (see the CICS Administration Reference ).
You can then use the CICS Clients or a cicsteld command to run the
transaction and, therefore, run your application program. The transaction is
executed under the control of CICS, which provides the services requested by
each API command.
Third-party application development tools
There is a wide range of tools for developing applications to run on

workstation clients and servers in a TXSeries environment. For example, you
can use the following products:
v IBM VisualAge for Java
v IBM VisualAge for C++
v Microsoft Visual C++
v IBM VisualAge Cobol
v Micro Focus Object COBOL

Chapter 9. Systems management
This chapter describes the systems management facilities of TXSeries. It
contains the following topics:
v “Managing a CICS environment”
v “Managing an Encina environment” on page 161
v “Using the Tivoli Global Enterprise Manager (CICS and Encina)” on
page 164
v “Managing the Distributed Computing Environment (DCE)” on page 168
The tasks involved are described in other TXSeries books, primarily Planning
and Installation Guide, CICS Administration Guide, and Encina Administration
Guide Volume 1: Basic Administration.
Managing a CICS environment
Systems administration for Customer Information Control System (CICS)

consists of configuring the CICS environment so that CICS regions can be
started, monitoring running CICS regions, shutting regions down, and
recovering from problems. Administering CICS involves procedures that affect
other TXSeries components such as the Structured File Server (SFS), DB2, and
the Distributed Computing Environment (DCE).
The administrative tool used to configure and manage CICS depends on the
operating system you are using. For example, you can use the IBM TXSeries
Administration Tool for CICS on Windows NT or the System Management
Interface Tool (SMIT) for CICS on AIX. The tools simplify and automate the
administrative procedures. The IBM TXSeries Administration Tool is described
in “The IBM TXSeries Administration Tool (Windows NT only)” on page 158.
You can also use other tools, such as CICS commands and transactions.
The CICS administration tools are designed to manage the CICS environment
on one machine. To use them, you log into the machine as a systems
administrator, then invoke the tool that you want to use. To manage the CICS
environment on several machines, you can use standard techniques to log into
each machine remotely and use the tools on those machines. For example, you
can use one machine as a single point of control (SPOC), with sessions set up
to run tools on other machines. You can control access to the administration
tools by controlling access to the SPOC machine. You can use CICS-supplied

transactions at a CICS region on an SPOC machine to manage the runtime
environment of CICS regions on other machines.
Configuration
Configuration is the stage during which you specify or modify the settings that
define the properties of the CICS environment. You can use the administrative
tools to create CICS regions and SFS servers, and to set up the related settings
in DCE and your operating system.
Configuring CICS
To define the properties of a CICS region to be started, you first create the
CICS region. This adds a region definition to the CICS permanent database on
the machine. In a DCE cell, the administrative tool automatically creates the
DCE principal and account, the access control lists (ACLs), and the keytab file
for the CICS region (using DCE facilities).
As part of configuration, you also create a resource definition for each resource
used by a CICS region, or by user applications that run on the CICS region. A
resource definition describes the properties of the resource and how it is to be
treated by CICS. For example, you create a transaction definition for each
transaction that can be processed by a CICS region.
Configuring DCE
CICS can use a number of DCE services, from DCE remote procedure calls
(RPCs) for communications to the core services of a DCE cell. Configuring
DCE client services for CICS is described in the Planning and Installation Guide
and the CICS Administration Guide. The DCE tools provided with TXSeries (or
DCE) are described in “DCE administration tools” on page 169.
Configuring CICS clients
To enable CICS clients to access a CICS region, you do the following:

v Configure each client machine for communications with CICS, for example,
by adding Transmission Control Protocol/Internet Protocol (TCP/IP)
attributes to the client initialization file.
v Configure the CICS region for listener processes for the clients and define
userids and terminals to be used for the client connections.
Configuring file managers
For file management, CICS can use either an SFS server or an IBM DB2
database. The region can be configured to access the file manager either
locally or remotely.

Before your application programs can use data in an SFS server, you must set
up the files on the SFS. You can do this either interactively or by adding files
that have been predefined in schema file definitions. The interactive method is
best used for one-time creation of SFS files, and the schema file definitions
method (using the CICS SFS Import tool) is best for repeated use of files with
the same characteristics.
Before your application programs can use data in DB2, you must configure
DB2 for use with CICS.
Starting and stopping servers
You can use your administrative tool to start and stop CICS regions and SFS
servers.
Monitoring systems
While your CICS regions are running, you can monitor their operation and
change runtime settings of the regions and the resources that they use. You
can also use monitoring facilities to resolve any problems that occur.
General monitoring capabilities for CICS are as follows:

v You can display a CICS-oriented view of all operating system services that
make up a CICS region and can act on the runtime settings of CICS regions.
v Messages about the condition and events for a CICS region are written to
its console log. Such messages include startup messages, transaction-related
messages, and error messages for the region. You can view the log file
directly or can use the remote log viewer transaction CMLV (Console Message
Log Viewer) to view the log file of any connected CICS region.
v Application servers write messages about transactions to the CICS region’s
CSMT transient data queue. You can view this queue for information about
the processing of transactions by the CICS region.
v CICS writes messages about the autoinstall and deinstall of terminals
related to CICS Clients to a CCIN transient data queue. You can view this
queue directly for information about the clients that have been accessing
the CICS region.
v On Windows NT only, CICS writes messages to the event log, similar to
messages written to the console log. You can view the event log for such
messages, and for messages relating to the operation of CICS as operating
system services.
Besides the routine monitoring of CICS, you can analyze the performance of
CICS in more detail. To do this, you can use CICS tools to create and view the
following information:
Chapter 9. Systems management 157

v Dumps, which show a detailed snapshot of what is happening in CICS at
the moment that you captured the dump
v Trace, which shows the flow of control through an application program or
through CICS
v Statistics, which show details of how your applications handle resources
and how individual resources, such as terminals, are being used
v Monitoring, which provides information for debugging applications by
using system-defined event monitoring points that exist within CICS code
The CICS administration tools
TXSeries provides a range of tools for managing a CICS environment,

including graphical user interfaces (GUIs), CICS commands, and online CICS
transactions.
v “The IBM TXSeries Administration Tool (Windows NT only)”
v “CICS commands” on page 159
v “Online CICS-supplied transactions” on page 160
The IBM TXSeries Administration Tool (Windows NT only)
The IBM TXSeries Administration Tool for Windows NT provides a graphical

interface to many of the CICS configuration and management tasks. In
particular, it provides a simple interface for creating, modifying, starting,
stopping, and destroying CICS regions, SFS servers, PPC Gateway servers,
and the resources used by CICS regions. Where needed, the IBM TXSeries
Administration Tool makes changes to DCE and the underlying operating
system automatically. For example, if you use the IBM TXSeries
Administration Tool to start a CICS region that uses an SFS server for file and
queue management, it performs as many of the following tasks as needed:
v Starts DCE
v Creates a userid for the SFS server
v Creates logical volumes for the SFS server
v Creates the SFS server
v Starts the SFS server
v Configures the SFS server for the CICS region
v Creates the CICS region
v Starts the CICS region
Generally, when managing the CICS environment, you use the IBM TXSeries
Administration Tool. If you need to do more specialized tasks you can use
other tools; for example, the CICS SFS Diagnostic Tool and the DCE Director.
The IBM TXSeries Administration Tool uses a number of CICS commands and
offline utilities that can also be entered directly from the command line. The

main command used is cicscp, which automatically invokes other CICS
commands. A description of the CICS commands is provided in the CICS
Administration Reference.
The IBM TXSeries Administration Tool presents an object-oriented window of

systems that you can manage. For each system, you can display a pop-up
menu of actions that, where necessary, display other dialog boxes, such as the
properties notebook. The properties notebook provides you with several
different mechanisms for setting the value of object attributes. Among these
are:
v Check boxes for binary choices
v Drop-down lists or cascade lists for multiple defined values
v Dialog boxes for user-defined values
The IBM TXSeries Administration Tool provides several sources of

information for help on using it, on choosing appropriate actions, and on
getting descriptions of object attributes. For example:
v You can access online help for each object attribute. Help lists the possible
values for the attribute and explains the effect of using them. It also
provides the actual variable name of the attribute as used by the system.
v If you are more familiar with an attribute’s actual variable name than with
the prompt on a panel, you can display the variable name, in the form of
context-sensitive help, by moving your cursor over the relevant prompt.
CICS commands
TXSeries provides a set of powerful CICS commands that can be used to

simplify system management of CICS, SFS, DCE, and Systems Network
Architecture (SNA). Most of the functions provided by the commands can be
accessed through the CICS graphical administrative tools. However, it can
sometimes be helpful to use a specific command rather than the graphical
interface, especially when you are familiar with using both.
For a detailed description of the CICS commands, see the CICS Administration
Reference.
The CICS Control Program, cicscp: The main CICS command is the CICS
control program, cicscp. This provides a standard command interface for
configuring, starting, and stopping the components that make up a CICS
environment. This command is designed for users new to the CICS
environment, and makes it easy to configure, start, and stop the environment.
Underlying commands used by cicscp: The cicscp command automatically

invokes other CICS commands. For example, it uses the cicssetupdce
command to add to DCE the CICS-related DCE groups and objects. However,

when you are working with a complex configuration, it is sometimes helpful
to configure individual components separately, using the commands normally
invoked by cicscp.
Resource management (RDO) commands: To define or amend the resources

in a region, you can use commands instead of the graphical administrative
tool. For example, you can use the cicsupdate command to change a resource
definition. You can indicate that a command is to be applied to the CICS
permanent database only, to the CICS runtime database only, or to both.
The CICS SFS Diagnostic Tool, cicssdt: This tool provides a powerful,
interactive interface to SFS. You can use it to manage user files on SFS servers.
For example, you can create new files, list all files on the SFS server, read and
write file records, and transfer and convert a Virtual Storage Access Method
(VSAM) file to SFS.
The CICS SFS Import Tool, cicssfsimport: This tool adds files to SFS based
on predefined schema file definitions.
The CICS DB2 Diagnostic Tool, cicsddt: This tool is used to manage user
files on DB2 databases. For example, you can create new files, list all files on
the database, and transfer and convert a VSAM file to DB2.
The CICS Service Utility, cicscheckup (Windows NT only): This service

utility enables a user to check various aspects of TXSeries for Windows NT
installation and configuration. It reports the current configuration of a
particular machine, the software installed on it, and any CICS regions or SFS
servers that have been defined. For further details on cicscheckup, see the
README file in \opt\cics\utils\cicscheckup on the drive on which CICS is
installed.
Online CICS-supplied transactions
You can use several CICS transactions to operate running CICS regions,
including the following:
CEMT
This command is used to dynamically manage a running CICS region
and its resources.
CECI This command is used to run CICS commands.
CEDF
This command is used to debug CICS application programming
interface (API) program statements.
These transactions can be entered at a CICS local 3270 terminal, a cicsterm

session of a CICS Client, or a Telnet client.

Managing an Encina environment
Encina administrators can use a wide range of interfaces for configuring,

starting, and monitoring resources in a Monitor cell. These interfaces include
the following:
v GUIs. Enconsole is the primary interface for Encina administration. It is an
excellent choice for first-time users and for administrators who must
oversee a large networked Encina system. This approach is recommended
for prototyping systems and for one-time and periodic administrative tasks.
Enconsole’s forms-based interface simplifies many time-consuming tasks.
v Command-line interfaces. These interfaces are required for the following
tasks:
– Certain volume management tasks, such as creating backups and
restoring volumes
– Server-specific tasks, such as setting up queues in Recoverable Queueing
Service (RQS) servers and indicating priorities for queues and queue sets
Command-line interfaces are also useful for the following tasks:

– Building custom scripts
– Automating repetitive tasks
– Processing information that is not available from GUI screens
– Integrating Encina administrative commands with proprietary
administrative tools
Enconsole is a graphical user interface that provides a cohesive view of a

distributed client/server environment within an Encina Monitor cell. It also
provides remote administration capabilities for the servers in a distributed
environment.
You can monitor a wide variety of Encina client/server applications with

Enconsole, including RQS applications which manage simultaneous requests
for queued data, SFS applications which support concurrent users accessing
large files across multiple disks, and Peer-to-Peer Communications (PPC)
applications which provide communications and distributed transaction
processing capabilities between Encina and other systems.
Enconsole can also administer servers that do not use the Encina API. These
generic servers are built with shell programs or the C programming language.
Generic servers do not rely on Encina or DCE capabilities. You can build your
own communications systems, ordering and purchasing systems, financial
systems, and other transaction processing systems that interact with the
Encina Monitor and with other Encina applications.

Using Enconsole, you can view information about the Encina cell and can
perform tasks such as defining, reviewing, modifying, and deleting server
configurations. Enconsole simplifies server creation by displaying the forms
necessary for creating a server and its associated components, such as log
volumes and data volumes.
Enconsole uses default values to ensure consistency throughout the network

and to minimize the number of configuration choices that you must make.
The Enconsole Interface
The Enconsole interface displays three windows into the Encina cell: one that
shows all servers, one that shows all nodes, and one that shows all system
messages. You can use this cohesive view of the Encina cell to monitor the
system and to troubleshoot problems from any network location.
The Enconsole interface includes menus, with which you direct Enconsole to
perform operations; forms, with which you specify the information necessary
for Enconsole to perform operations; and display screens, which provide status
information about servers and the operations being performed on them. Most
aspects of the interface are similar to other graphic interfaces.
Online help is available for Enconsole display screens, forms, and fields. The
help displays information about how to use the online help, how to do
administrative tasks using Enconsole, and about the components of the
current window, for example, the screens, forms, fields, menu options, and
common buttons.
Access to DCE Settings
Enconsole provides access to the DCE settings for each Monitor application
server. The settings for principals and keytab files control user access to
critical information and resources, and provide protection from misuse, theft,
and tampering. Additionally, Enconsole uses the DCE Cell Directory Service
(CDS) to manage information about the resources necessary for open,
distributed client/server applications.
Access to Encina settings
Enconsole provides access to the Encina settings for each Monitor application
server. The Encina settings ensure availability and recovery for each server.
The Encina Toolkit components provide fatal and warning messages through
Enconsole. This communication helps you reduce downtime by making it
easier to recognize and respond to errors.

Starting and stopping servers
Enconsole provides ways to start and stop Monitor application servers, and
other servers that they use, individually from any network location. You can
also monitor the startup and shutdown messages for all servers.
Enconsole also provides ways to automate server administration. You can use
Enconsole to create a server set that starts or stops a collection of servers, or
you can create schedules–procedural plans that specify times at which to start
or stop servers.
Monitoring and administering transactions
Enconsole displays information about the transactions for a Monitor

application server from any network location. For any transaction, you can
use Enconsole to review the identifier of the transaction, the number of data
locks it holds, the number of data locks it is waiting for, and its state. You can
also review information about the parent transaction and the RPCs associated
with the transaction.
Enconsole also provides ways to correct transaction failures. You can abort
unresolved transactions, and you can release all locks held by a prepared
transaction and force the transaction to abort, commit, or finish.
The Encina command-line interfaces
The Encina Control Program (enccp) is a command-line and scripting interface

for administering Encina Monitor cells. It provides all the functionality of
Enconsole. The enccp interface is modeled after dcecp, the DCE
administration tool based on Tcl (tool command language). Tcl is a portable
command language that provides programming facilities, such as variables,
procedures, conditionals, list-processing functions, and looping constructs. The
enccp interface extends Tcl by providing a set of commands for manipulating
Encina Monitor objects. Furthermore, enccp incorporates dcecp so that all
dcecp functionality is available from within enccp.
The tkadmin command-line interface is used for configuring and maintaining

the components common to all Toolkit servers. For example, the interface can
be used for a wide range of volume management, transaction administration,
and application tracing tasks. It can be used for basic tasks such as creating
and mirroring volumes, performing daily backups, and querying server
attributes. It can also be used for less-frequent tasks, such as renaming
volumes and restoring data.
Many initial tasks required for defining servers (such as creating, allocating,
and mirroring volumes) are performed when you complete the fields on

server definition forms in Enconsole. Other tasks must be done exclusively
with the tkadmin interface (or with a combination of Enconsole and the
tkadmin interface).
The tkadmin commands are always available whether or not you choose to
use Enconsole. The two interfaces are compatible; tkadmin commands (as
well as other Encina command suites) can be used to administer a server
started with Enconsole.
Once an Encina server is started, you administer it by using server-specific

command-line interfaces. The following interfaces enable you to manipulate
server objects after a server is started:
v The rqsadmin interface for administering RQS servers. This interface is
used to create queues, organize them into queue sets, and specify their
priorities and service levels. This interface is also used for defining element
types for queues, specifying how and when to perform maintenance tasks
in the queue storage area, and adjusting other storage factors that affect
performance in an RQS server.
v The sfsadmin interface for administering SFS servers. This interface is used
to create and manage SFS files and indices.
v The ppcadmin interface for administering Peer-to-Peer Communications
(PPC) Gateway servers.
Using the Tivoli Global Enterprise Manager (CICS and Encina)
Tivoli provides a set of software tools for managing heterogeneous hardware

and software resources within a network. The Tivoli Global Enterprise
Manager (GEM) adds to the Tivoli environment the ability to identify and
organize resources according to their business application and function. GEM
provides graphical views that administrators can use to inspect the overall
status of distributed applications, to monitor individual resources within the
application, and to perform administrative operations on resources.
GEM can be used in a network or a mainframe environment. In a distributed

network environment, the Tivoli Management Framework must be configured.
In a mainframe or OS/390 environment, NetView™ must be configured.
GEM provides the following functionality:

v Provides tools for modeling, monitoring, and administering cross-platform,
distributed applications using graphical views
v Organizes multiple views into a hierarchical structure
v Reports status information about individual software components within a
business system

v Provides controls for performing operations on individual resources
v Simplifies setting alerts and configuring event triggers on heterogeneous
network resources through a uniform interface
For complete information about Tivoli, refer to Tivoli documentation. For

more information about GEM, see the Tivoli Global Enterprise Manager
Installation and User’s Guide.
GEM comprises the following components:

v A GUI, or console, built using the Sun Microsystem Java™ programming
platform—Administrators use GEM to plan, build, verify, and control
distributed applications with graphical views.
v A server component—The GEM server, also called the Tivoli Topology
Server, models and stores the topologies of distributed applications.
v An event-enabling component—Administrators use this component to
implement automated warnings and actions based on changing conditions
within a distributed application.
v Instrumentation for each type of resource that is managed by
GEM—Administrators use GEM to monitor and control each resource in a
distributed application.
Managing resources with GEM
The following CICS and Encina resources can be monitored and managed by
GEM:
v CICS regions
v Encina cell managers (ecm)
v Encina node managers (enm)
v Recoverable Queueing Service (RQS) servers
v Peer-to-Peer Communications (PPC) Gateway servers
v Structured File Server (SFS) servers
v Monitor Application servers (MAS)
v Generic servers (GS)
Using the GEM console
The GEM console provides administrators with a way to plan, build, verify,
and control business systems. A business system is a group of network
resources that work together to perform a specific business function. An
Encina Monitor cell or a CICS system can constitute a complete business
system or be part of a larger one.

The left pane of the GEM console displays business systems organized in a
logical hierarchical tree. The top of the tree represents the overall enterprise.
Subentries represent complete business systems.
The right pane of the console displays a graphical representation of each

business system, such as the Encina business system model. The icon at the
apex of the topology represents the Encina business system. Selecting the icon
displays properties about the business system, its configuration, and the
resources that it comprises. The icons connected to this icon represent each
resource within the business system. Selecting a resource icon displays
summary information, a list of tasks available on the resource, and the GEM
monitors for the resource.
Control views
Business systems can be administered by using GEM from any workstation

that supports Java. GEM control views display topologies of business systems,
visual indications of the health of the business system, and the means to
inspect individual resources within a business system.
Each CICS or Encina resource instance, such as an Encina node manager or

Structured File Server, is displayed as an icon within a GEM view. Resources
are polled periodically to determine their status, and resource icons are
updated with color cues.
Alerts and events
Information gathered by GEM instrumentation is also used by the GEM event

component for triggering alerts or processes. Status data is compared with
configurable thresholds when a resource is polled. If a utilization or
availability threshold has been crossed, GEM updates the view and performs
any additional operations that have been specified by the administrator for
the threshold. Operations can include running scripts, sending e-mail, or
performing other custom functions. Administrators can establish multiple
trigger thresholds for each type of resource by using the Set Threshold task in
the GEM console for any resource.
Managing Encina with GEM—limitations
Administrative tasks that can be performed in GEM are a small subset of the
overall functionality available through the standard CICS and Encina
administrative interfaces. GEM is not a replacement for the standard CICS and
Encina administrative interfaces. For example, you cannot use GEM to install,
fully configure, or fine tune Encina Monitor cell or CICS system resources.
In general, any complex administrative task, such as performing server

recovery or executing manual transaction tasks, must be done by using the

appropriate CICS or Encina interface. For example, for Encina, you must use
enccp or tkadmin command-line administrative tools, or the Enconsole
graphical user interface. For CICS, you must use cicsp or SMIT administrative
tools, or the IBM TXSeries Administration Tool for Windows NT.
GEM instrumentation does not provide a real-time picture of the health of a

business system. GEM instrumentation periodically gathers information from
resources, so there is lag time between what is seen in a GEM view and the
actual state of a resource instance. The interval at which GEM monitors gather
information is configurable, but setting interval periods well below default
settings can negatively affect performance.
GEM can be used to manage only one TXSeries transaction-management

environment on a Tivoli managed node. Encina and CICS cannot be managed
by GEM simultaneously on the same Tivoli managed node. However, multiple
Encina resources, or multiple CICS resources (but not both) can reside on the
same host machine and be managed by GEM.
Tasks in GEM
Two categories of tasks can be performed on each managed resource in GEM:

v Tasks that are common to all managed resources in GEM. Examples include
querying the threshold settings of a resource monitor and specifying the
interval that a resource monitor uses to check the utilization level of a
resource.
v Tasks that are specific to the type of resource being managed in GEM.
These resource-specific tasks include starting and stopping a resource,
listing the percentage of free space on a data volume (Encina only), and
setting the minimum and maximum number of checkpoint records (Encina
only). Resource-specific tasks can also be performed by using a standard
CICS or Encina administrative interface.
Controlling access
Tivoli protects access to managed network resources by using security roles.

Users can gain access only to the resources and administrative operations
permitted by the security roles associated with their login identity. Security
roles for users and groups and security role requirements for resources are
assigned by Tivoli administrators. Tivoli administrators typically possess the
senior or super security role, which grants them access to these Tivoli
administrative operations.

Managing the Distributed Computing Environment (DCE)
Management of DCE (though not part of TXSeries administration) is an

important part of systems management if you are running CICS or Encina in
a DCE cell. DCE clerks, servers, and databases are initially created and started
as part of DCE clerk and server configuration. They are largely self-regulating
and, apart from monitoring, require minimal intervention.
The procedures used to configure CICS or Encina automatically configure

DCE with the required settings. This section contains an overview of the
general tasks and tools involved in managing DCE:
v “CDS administration”
v “Security administration”
v “DTS administration”
v “DCE administration tools” on page 169
CDS administration
CDS administration generally involves the following:

v Configuring, starting, and stopping CDS clerks and server
v Managing the CDS namespace, clearinghouse, and directories
Security administration
Security administration generally involves the following:

v Establishing security policies
v Setting up and managing the security database
v Configuring, starting, and stopping Security clerks and server
v Managing use of accounts and ACLs
v Managing use of principals, passwords, security keys
v Auditing the DCE cell and monitoring invalid logins
DTS administration
DTS administration generally involves the following:

v Configuring, starting, and stopping DTS clerks and servers
v Setting the time on DTS servers
v Changing the role on DTS servers
The DTS clients and servers do not have a configuration file or database, but
are controlled by parameters specified for the commands used to manage
them.

DCE administration tools
The main administrative tool for DCE is dcecp.

The DCE control program (dcecp) (All platforms)
The dcecp control program provides consistent, portable, extensible,
and secure access to nearly all DCE administration functions from any
point in a DCE cell. It streamlines administration by providing a
number of task objects for performing DCE operations. For example,
adding a host to a cell requires adding a host principal to the registry,
adding the principal to various security groups and organizations,
creating an account, placing host information in CDS and if necessary
setting ACLs on CDS directories. All of these operations can be
accomplished by using a single task object. The dcecp program is built
on a portable command language called Tcl (tool command language).
Tcl provides programming facilities, such as variables, procedures,
list-processing functions, and looping constructs. The dcecp program
extends Tcl by providing a set of commands for manipulating DCE
objects.
The DCE setup tool (Windows NT systems)
For DCE on Windows NT, the main DCE tool is DCE setup, which
provides a graphical user interface for configuring DCE client services.
It is typically used before configuring CICS and other TXSeries
facilities on a machine. Using DCE setup, you can choose a standard
client configuration, which minimizes the amount of information you
need to specify. This standard configuration sets up the DCE client
services and enables the integrated login and automatic startup
facilities.
The DCE Director (available on IBM DCE only) is the main graphical
tool for managing DCE cells. The DCE Director makes it easy for you
to perform DCE management tasks, for example, creating, deleting,
and modifying user accounts, security groups, and CDS directories. It
presents an object-oriented view of the DCE environment, with the
DCE cell as the top-level object. Objects within the DCE cell include
users, groups, host machines, CDS directories, and DCE servers. You
can use the DCE Director to manage several DCE cells from your
desktop: the DCE cell to which your local machine belongs and other
DCE cells with which your cell can communicate.
The DCE Director enables access to other standard DCE control
programs and provides other functions, such as allowing authorized
users to preconfigure host machines in a cell and manage user
accounts. The DCE Director includes an enhanced ACL editor, the
Visual ACL Editor, which you can use to manage ACLs graphically.

Both the Visual ACL Editor and other DCE control programs can be
used as standalone tools to manage your DCE environment outside
the DCE Director.

Chapter 10. Component planning
This chapter describes the choices involved in deciding which TXSeries
components to install and configure. It contains the following topics:
v “Encina and CICS”
v “Choosing a DCE configuration” on page 172
v “Deciding how to manage files and queues” on page 174
v “Using an SFS Server to manage CICS queues and data files” on page 174
v “Using DB2 to manage CICS queues and data files” on page 176
v “Choosing a relational database manager” on page 180
v “Planning the intercommunication network” on page 181
Encina and CICS
You can use Customer Information Control System (CICS) or Encina as a

transaction processing monitor. Encina offers distributed transactional services
by integrating and building on the services provided by the Distributed
Computing Environment (DCE), while CICS, in turn, uses the services of
Encina. See Figure 56 for an illustration of how CICS and Encina relate to each
other and how they build on DCE.
Figure 56. CICS and Encina product architecture
Encina extends DCE services to provide log-based recovery, locking,

transactional extensions to DCE remote procedure call (RPC), two-phase
commit protocol, and interfaces that permit interoperability with X/Open

XA-compliant resource managers. The Toolkit Executive and Server Core,
together with DCE, contain the building blocks necessary to implement
distributed transactional systems. On top of this important infrastructure,
Encina provides a transaction processing monitor, ready-built recoverable
server applications, services for allowing mainframe applications to become
part of a distributed system, and a graphical interface for central
administration.
See Planning and Installation Guide for information on which Encina

components are used by CICS and by the Encina Monitor. For an explanation
of the various Encina services, refer to the Encina documentation.
Choosing a DCE configuration
Both CICS and the Encina Monitor are based on standard DCE services that
provide secure, authenticated, client/server interoperability across diverse
platforms. At the heart of DCE is the Remote Procedure Call (RPC), used by
both CICS and the Encina Monitor to open connections, to organize data into
a stream suitable for transmission, and to transmit the data.
For a CICS system you can choose between two types of DCE configurations:
v DCE cell, as shown in Figure 57 on page 173.
The CICS region participates in a DCE cell. A DCE cell is a group of
machines (hosts) or a single machine administered as a unit. Each cell
provides the services needed for a distributed computing environment and
groups the users, systems, and resources that share those services.
The DCE server software—the Cell Directory Service (CDS), Security
Service, and Distributed Time Service (DTS)—is installed on one or more
hosts within the DCE cell. (A host running DCE server software can also
contain a CICS region.)
The DCE client software—the RPC daemon, CDS, Security Service, and DTS
clients (also known as clerks)—is installed on each host within the cell.
You can create a new DCE cell or you can add CICS to an existing DCE
cell.
v RPC only, as shown in Figure 58 on page 173.
The CICS region is not part of a DCE cell but uses only the RPC daemon.
In this case, CICS rather than DCE provides a means of locating server host
names and of performing endpoint mapping. The security facilities of CICS,
the operating system, or an external security manager are used rather than
those of DCE.

Although CICS can run with just RPC only, it is strongly recommended that
you run a CICS production environment in a DCE cell to take advantage of
the greater security.
Figure 57. CICS in a DCE cell environment
Figure 58. CICS in an RPC-only environment
In an Encina Monitor system, you must operate in a DCE cell environment.

Again, you can create a new DCE cell or add the Encina Monitor to an
existing DCE cell.
TXSeries can use either or both of the following security models:

v DCE security. A DCE Security Server provides comprehensive, centralized
security services for authenticating and authorizing all principals in a DCE
Chapter 10. Component planning 173

cell. The services include making communication secure through
authenticated RPCs. (See “The TXSeries security model using DCE” on
page 119.)
v CICS security. Each CICS region does all the authentication and
authorization checking required for its own security, and can use an external
security manager as part of the security service. This includes functions for
making communication secure, such as flowing userids and passwords. (See
“The TXSeries security model using CICS” on page 126.)
The most secure model uses DCE cell security.
Note: For CICS regions, you can start with the CICS security services, which
can be all you need for a basic CICS environment. You can migrate to a
DCE security model later. For comprehensive security, such as required
by production CICS regions, the security services of DCE are strongly
recommended.
Both TXSeries security models provide services tailored to transaction

processing that enhance the security functions provided by the operating
system and the administrative model that it uses for network security.
Deciding how to manage files and queues
CICS queue and file management includes managing data files, auxiliary
temporary storage queues, intrapartition transient data queues, and locally
queued automatic transaction initiation (ATI) requests. In CICS, you can use
one of the following to manage this data:
v A local Encina Structured File Server (SFS) server, that is, one on the same
host as the CICS region.
v A remote SFS server, that is, one shared with another CICS region. The
remote SFS server and CICS must be installed and set up on the same
machine before you set up the local CICS region.
v A DB2 database, which must be installed and set up before you set up the
CICS region.
The Encina Monitor can use the Encina SFS for file management, the
Recoverable Queueing Service (RQS) for queue management, or another
resource manager. The Encina SFS server can be local or remote.
Using an SFS Server to manage CICS queues and data files
The method used to configure an SFS server depends on the following

options:

Option 1. Local SFS Server
With this option, the region uses an SFS server located on the same
machine as the region. See Figure 59.
Figure 59. A region using an SFS server that is on the same machine
Also with this option, you can use the Encina Fast Local Transport
(FLT) mechanism that significantly improves performance. See the
CICS Administration Guide for more information.
Option 2. Remote SFS server on a machine with CICS
With this option, a region on one machine shares an SFS server with a
region on another machine. See Figure 60.
Figure 60. Two regions sharing the same SFS server
There are three ways to use DCE with option 2:

v DCE can be used for user and RPC authentication if both the region and
the SFS server are in the same DCE cell.
v A region that does not use DCE CDS and the DCE Security Service can use
an SFS server that does, as long as the SFS server and the region are in the
same Transmission Control Protocol/Internet Protocol (TCP/IP) network
and as long as the region includes the SFS host name in the CICS_HOSTS
environment variable in /var/cics_regions/regionName/environment.

However, both the region and the SFS server must be defined with
protection levels set to none. In this scenario, RPCs cannot be authenticated.
v Neither the region nor the SFS server is in a DCE cell (but they are in the
same TCP/IP network), and the following are true:
– The region lists the SFS server’s host name in the CICS_HOSTS
environment variable.
– The server binding information has been made available for clients.
Both the region and the SFS server must be defined with protection levels
set to none. RPCs cannot be authenticated.
Using DB2 to manage CICS queues and data files
This section compares using DB2 to using SFS for managing CICS files and
queues. It contains some special topics to consider when deciding between the
two.
Comparing DB2 to SFS for queue and file management
While DB2 provides a rich set of services, there are limitations and restrictions
when compared to the services provided by SFS. The limitations are as
follows:
The region’s use of a single DB2 database for the data files
A region can only use one DB2 database for data files. This is the
database specified with the Region Definitions (RD) DefaultFileServer
attribute. The File Definitions (FD) FileServer attribute is ignored.
COBOL External File Handler restrictions
Due to limitations imposed by holding files in a relational database,
some facilities of the COBOL External File Handler are not supported.
The following restrictions apply:
v Mixing of transactional access and nontransactional access to files
within a single application is not permitted.
v When access to a file is nontransactional, only single record locking
is enabled.
v The facility to add indexes dynamically to a file at runtime is not
supported.
See the CICS Application Programming Guide for more information.

Nonrecoverable files
The semantics of nonrecoverable file behavior cannot readily be
implemented by relational database managers (RDBMs).
Nonrecoverable files are supported as recoverable files on DB2.

The change in semantics means that data is not written to a file until a
syncpoint is taken. The main consequences of this are as follows:
v Data is recovered after both system and transaction failure.
v Locks are retained until the next syncpoint.
v New data cannot be read until it has been committed.
v Long-running transactions will hold additional locks and consume
resources for nonrecoverable files.
v Transactions architected for nonrecoverable resources may deadlock
each other unexpectedly.
If you are dependent on nonrecoverable file semantics, it is

recommended that you do one of the following:
v Use SFS for CICS queue and file management.
v Set up a region that uses SFS for those files and queues that require
nonrecoverable file semantics and use function shipping between
SFS and the DB2 region.
Note: Function shipping is a programming construct used in CICS

application programs to do the following:
– Access CICS files owned by other CICS systems.
– Transfer data to or from transient data and temporary
storage queues in other CICS systems.
– Initiate transactions in other CICS systems. This form of
communication is described in the CICS Intercommunication
Guide.
– Initiate transactions in other CICS systems.
For more information, see the CICS Intercommunication Guide.

Nonrecoverable auxiliary temporary storage queues
Nonrecoverable auxiliary temporary storage queues and transient data
queues are not supported. These are implemented by using
recoverable files on DB2. All temporary storage queues behave as
recoverable temporary storage queues and all transient data queues
behave as logically recoverable transient data queues. The change in
semantics means that data is not written to a queue until a syncpoint
is taken. The main consequences of this are as follows:
v Data is recovered after both system and transaction failure.
v Locks are retained until the next syncpoint.
v New data cannot be read until it has been committed.
v Triggering of transactions by writing to transient data queues is
delayed until the writing transaction performs a successful
syncpoint.

If you are dependent on nonrecoverable queue semantics, it is
recommended that you use SFS for CICS queue and file management.
Locally queued unprotected starts
Locally queued unprotected starts are not supported. They are
implemented by using recoverable files on DB2. The change in
semantics means that starts are not written to the file until a syncpoint
is taken. The main consequences of this are that the request to the
remote system is not retried until the requesting transaction has
performed a successful syncpoint and, if the requesting transaction
abends, the START request is discarded if it was queued.
If you are dependent on locally queued START semantics, it is
recommended that you use SFS for CICS queue and file management.
Physically recoverable transient data queues
Physically recoverable transient data queues are not supported. They
are supported by using recoverable files on DB2. They behave as
logically recoverable transient data queues.
If you are dependent on physically recoverable transient data queues,
it is recommended that you use SFS for CICS queue and file
management.
DB2 data types
The set of DB2 data types that can be accessed by CICS is limited. For
CICS family portable applications, use DB2 data types that are not
associated with a coded character set. This can be achieved by
defining columns as CHAR or VARCHAR ″FOR BIT DATA″ or by
using Binary Large Objects (BLOBs). While binary data types are
recommended, CICS is able to support DB2 character data types that
are associated with a coded character set. However, CICS does not
support DATETIME or NUMERIC DB2 data types.
Segmented keys
Segmented keys are not supported.
Single database
All files and queues for a specific region must be held in a single
database.
Index names
In DB2, the index name for a particular table must be unique within
the database. In SFS, multiple files can support indexes with the same
name.
Field names
DB2 does not allow certain special characters in the field names.

Before migrating SFS files to DB2, refer to the information in the DB2
Structured Query Language (SQL) reference that describes field name
restrictions.
Additional considerations
When using DB2 to manage queues and files, consider the following points:
v DB2 must be integrated with CICS through the XA interface or the
CICS-DB2 single-phase commit optimization. Implications of this choice are
described in the CICS Administration Guide.
v The queues and files cannot be stored in host database management
systems such as DB2 for MVS.
v Where only one DB2 database is defined to the region, CICS establishes
implicit connections to it and all file control, queue, and SQL operations are
directed to that database. SQL-based transactions that access DB2 databases
other than those supported in the file system must be coded to ensure that
the connection to the file system database is maintained across CICS file
control, queue, and transaction control commands. For example, it can be
necessary to code an explicit EXEC SQL CONNECT prior to some CICS file
control, queue, and transaction control commands.
v DB2 tables must not be redefined while the corresponding file is opened to
CICS. Use CEMT SET FILE to close and disable the file before redefining
the underlying table. See the CICS Administration Guide .
v File locking and concurrency on DB2 differs from file locking and
concurrency in SFS. See the CICS Application Programming Guide.
v Because the DB2 fixed record size limit is 4005 bytes, records larger than
this are treated as if they were variable-length records.
v A CICS application cannot have more than 25 concurrent browse and
read-for-update operations open against a DB2 database at any given time.
Applications must be designed so that this limit is not exceeded.
v Unlike SFS, DB2 does not allow alternate record specification when creating
a secondary index. This does not functionally affect CICS applications, but
should be considered when creating DB2 resources for CICS.
v DB2 tables and their associated indexes that map to CICS files should be
owned by the DB2 user cics.
See the CICS Administration Guide for additional information.
Using a dual purpose DB2 database
You can access data in a DB2 database from CICS application programs by
using embedded SQL statements. The CICS Administration Guide describes
how to configure CICS and the database for this type of access.

A region configured to use DB2 for queue and file management is already
configured for SQL access from application programs using XA support as
long as the CICS data and application data are on the same database. The
only additional configuration required is to set up the COBOL runtime
environment if the applications are written in Micro Focus COBOL.
If the application data is on a different DB2 database from the CICS queue
and file management data, then the region and the database should be
configured for CICS queue and file management before following the
procedures described in the CICS Administration Guide. Certain programming
restrictions apply if you use a separate database for native SQL. See the CICS
Application Programming Guide for details.
To add support for a database that is already used by another CICS region, do
the following:
v Follow the procedures that describe how to configure the region and DB2
for queue and file management.
v If you require access to data in the same database from application
programs written in Micro Focus COBOL, then set up the COBOL runtime
environment as described in the CICS Administration Guide.
Choosing a relational database manager
TXSeries transactions can access RDBMs by including embedded SQL calls

within the body of a CICS application program. Coordinated commitment and
recovery of transactions that include CICS and SQL calls are possible only
with databases that support the X/Open XA Interface, as defined by the
X/Open Distributed Transaction Processing standard (X/Open DTP). You can
use one of the following RDBMs, which provide the X/Open XA Interface
required by TXSeries:
v IBM DB2
v IBM Database Server (which includes DB2)
v Informix
v Microsoft SQL Server
v Oracle
v Sybase
The Encina Monitor supports two types of interaction with resource

managers. A native resource manager, such as the Encina RQS or SFS, is one
that interacts with the Monitor by using components of the Encina
Toolkit—for example, TRAN or Transactional Remote Procedure Call (TRPC).
Such resource managers provide transactional consistency transparently to the
Monitor. An XA-compliant resource manager such as Oracle or Informix, on
the other hand, interacts with the Monitor by using the X/Open XA interface.

This type of resource manager is ″registered″ with the Monitor and
interoperates with the Monitor via the Toolkit’s TM-XA component.
Planning the intercommunication network
This section provides an overview of the options available for

intercommunication networks. For detailed information about choosing which
of these products to use, refer to the CICS Intercommunication Guide, which
describes the following:
v How to design an intercommunication environment
v How to configure CICS and SNA for intercommunication
v How to operate a CICS intercommunication environment
v How to write application programs for intercommunication
When two systems communicate, they need to agree on the set of rules they
will use to interpret the data that is sent between them. These rules are
known as network protocols and they are defined in a network architecture. CICS
intercommunication is based on the IBM Systems Network Architecture (SNA)
LU 6.2 protocol. This protocol, which is often referred to as advanced
program-to-program communications (APPC), was developed to accommodate
the needs of two systems that wish to share data and applications. Therefore,
it is ideally suited to the CICS intercommunication environment.
CICS on Open Systems supports intersystem communication between a local

region and the following:
v CICS on Open Systems regions
v CICS for MVS/ESA, CICS/MVS, CICS/VSE, CICS for OS/2, and CICS/400
regions
v Encina PPC-based applications
v Applications on systems that support the SNA LU6.2 protocol
CICS can communicate with remote systems across either of the following:
v A TCP/IP network
v An SNA network
A CICS on Open Systems region can communicate across TCP/IP with other
CICS on Open Systems regions, with CICS for OS/2 regions, or with any
application using Encina because it emulates the APPC protocol.
The TCP/IP support provided by CICS on Open Systems supports

synchronization levels 0, 1, and 2.

CICS on Open Systems regions can communicate across SNA with any system
that supports APPC. This includes CICS for MVS/ESA, CICS/MVS,
CICS/400, CICS/VSE, CICS for OS/2, and CICS on Open Systems.
There are two methods of SNA communication available in CICS:

v Local SNA support. Local SNA support allows CICS to communicate across
an SNA network if an appropriate SNA product is installed and configured
on the same machine as the region. Using local SNA support provides the
fastest SNA connectivity offered by CICS and enables your CICS
applications to communicate, using synchronization levels 0 and 1, with
any CICS product and any non-CICS APPC workstation. If you require
synchronization level 2 support across SNA, you need a PPC Gateway
server.
v SNA support using a remote or local Peer-to-Peer Communications (PPC)
Gateway server. CICS can communicate across an SNA network by using a
PPC Gateway server. CICS communicates with the PPC Gateway server by
using TCP/IP, which means the PPC Gateway server does not have to be
on the same machine as your CICS region. The PPC Gateway server uses
an appropriate SNA product to connect to the remote SNA systems. This
SNA product must be installed and configured on the machine where the
PPC Gateway server is running.
Encina Monitor application servers use TCP/IP to communicate with other

Encina servers and with CICS regions that support PPC TCP/IP. An Encina
Monitor application server can also use a PPC Gateway server and SNA
product to communicate with systems on an SNA network—for example,
IBM-mainframe-based CICS regions.

Chapter 11. Configuration planning
This chapter describes some possible configurations for TXSeries. It contains
the following topics:
v “Planning how to distribute your system”
v “The CICS client/server distributed environment” on page 186
v “CICS performance considerations” on page 193
Planning how to distribute your system
There are many ways to distribute the clients and servers in your distributed
system. The final decision depends on how the system will be used (now and
in the future) and involves many trade-offs. The following sections discuss
possible ways to distribute the resources in Customer Information Control
System (CICS) and Encina systems, and describe performance options to
consider when designing a system.
Distributing CICS
The recommended option for first-time CICS installations is to install a CICS

region and Structured File Server (SFS) server on the same host, with a CICS
client on the same host or another host. This configuration is the easiest to
install, test, and maintain. However, within a Transmission Control
Protocol/Internet Protocol (TCP/IP)-connected network, you can have
multiple CICS regions, and file managers can be shared by CICS regions, as

Figure 61. CICS configuration
Other possible configurations include the following:

v A CICS client in a remote procedure call (RPC)-only setup
v A CICS client in a Distributed Computing Environment (DCE) cell
v A CICS region that uses a local SFS server for file management (in an
RPC-only setup or in a DCE cell)
v A CICS region that uses a remote SFS server for file management (in an
v A CICS region that uses a DB2 database for file management (in an
CICS clients can communicate with CICS regions by using either TCP/IP or
Systems Network Architecture (SNA). Both of these can be used for clients on
the same machine as a CICS region, as well as for clients on remote machines.
For more information, refer to the CICS Intercommunication Guide.
If you use a remote SFS server (one already set up for use by CICS) or a DB2
database for file management, these must be in the same TCP/IP network.
In a DCE cell, the CICS region must be in the same cell as any SFS server that
is used.
Distributing Encina
An Encina distributed transaction processing system typically consists of a

network of machines, each running client or server software, or both. The
parts of an Encina application can be grouped into a single administrative
unit called a Monitor cell. A Monitor cell is a collection of nodes (machines)
whose server processes are managed by one coordinating server called a cell
manager. A cell manager stores and continually updates information about
server processes running in a cell.

Each Monitor cell has one cell manager. The cell manager coordinates cell
activity by communicating with individual node managers, each of which
controls server activity on a single node. A node that is managed by a node
manager is called a managed node.
The machines making up a Monitor cell must all be contained within a single
DCE cell. More than one Monitor cell can exist in a single DCE cell, although
each managed node can be part of only one Monitor cell.
In addition to cell and node managers, a Monitor cell contains the following:
v Monitor clients, through which a user interacts with the Monitor, making
requests for services exported by application servers. Clients can run on any
node.
v Monitor applications servers, which export services requested by client
applications. Monitor application servers contain one or more processing
agents (PAs). Processing agents are instances of server code that can handle
either single or multiple client requests for services. Monitor application
servers must run on managed nodes.
v Resource managers.
Figure 62 on page 186 shows an example Monitor cell. This Monitor cell
contains several nodes—Windows NT machines and UNIX workstations.
Nodes A, B, C, and E are managed nodes; each runs a node manager, and
Node C also runs a cell manager process. Node D is not managed by the cell
manager; this node runs a Monitor client. Monitor clients contact the cell
manager to request services from available application servers or from
resource managers.
Chapter 11. Configuration planning 185

Figure 62. An Example Encina Monitor Cell
You can choose to distribute the Encina servers—SFS servers, Monitor

application servers, or Recoverable Queueing Service (RQS) servers—and
clients that are members of the same Monitor cell in whatever configuration
best suits your application and machine requirements. For example, you can
run the Encina client applications on a separate machine from the Monitor
application servers, and you can run the cell manager on a separate machine
from the Monitor application servers. For more information, refer to the
Encina documentation.
The CICS client/server distributed environment
There are several client/server relationships in CICS. The relationships are

between the following:
v Terminal users and CICS regions
v Encina servers and CICS regions
v DCE servers and CICS regions
v CICS regions and other CICS regions
“Example configurations of client/server relationships” on page 191 shows

some examples of how clients and servers can be distributed.

Note: The terms client and server refer to software rather than hardware. This
is an important distinction, especially when considering the
relationships between clients and servers in a CICS environment. For
example, a host can have both clients and servers, and a region acts as
a client with some processes and as a server with others.
The relationship between terminal users and CICS regions
Terminal users request services from CICS regions as clients. A terminal user
can be:
v A Telnet client with 3270 emulation capability
v A CICS on Open Systems client
v A CICS Universal Client
Telnet clients with 3270 emulation capabilities can connect to a CICS region
through the cicsteld Telnet server. This is described in the CICS Administration
Guide.
The CICS on Open Systems clients can connect to a CICS region by using, for
example, the cicsterm command. These connections use DCE RPCs. Any CICS
on Open Systems client can connect to any CICS on Open Systems region.
Two application programming interfaces, the external presentation interface

(EPI) and the external call interface (ECI), are available with the CICS on
Open Systems clients and the CICS Universal Clients. The CICS Universal
Clients are:
v The CICS Client for Windows NT
v The CICS Client for Windows 95 and Windows 98
v The CICS Client for OS/2
v The CICS Client for AIX
v The CICS Client for Solaris
The CICS Universal Clients provide their own LU6.2 emulation to connect to
any CICS on Open Systems region over TCP/IP and SNA.
The relationship between clients and CICS regions is shown in Figure 63 on

page 188 .

Figure 63. The relationship between terminal users and CICS regions
The EPI and the ECI are described in CICS Family: Client/Server Programming
and in the CICS Administration Guide.
The relationship between Encina servers and CICS regions
CICS uses the Encina PPC Gateway server for intercommunication across an
SNA network and the Encina SFS for CICS queue and file management. When
requesting a service from one of these servers, the region is acting as a client.
This relationship is shown in Figure 64 on page 189.

Figure 64. The relationship between CICS regions and Encina servers
For more information about using a PPC Gateway server, see the CICS
Intercommunication Guide.
The relationship between DCE servers and CICS regions
CICS uses the DCE DCE Security Service to authenticate users and the DCE
Cell Directory Service (CDS) to help clients find servers. The components
within the CICS environment that use these services are:
v CICS on Open Systems clients
v CICS on Open Systems regions
v Encina SFS servers
v Encina PPC Gateway servers
Although the CICS client and region software initially request the services,
these requests are made through the DCE CDS clerk and DCE Security clerk
processes. The relationship between DCE servers and CICS regions is shown
in Figure 65 on page 190.

Figure 65. The relationship between CICS regions and DCE servers
Note: You will also see other DCE processes running on your system, such as
the DCE CDS Advertiser server and the DCE RPC daemon. CICS
administration does not normally require involvement in these
processes. If you require more information about them, see the DCE
documentation.
The relationship between a CICS region and other CICS regions
CICS regions communicate with other CICS regions by using peer-to-peer

communications. CICS uses the Encina PPC Executive to implement these
communications. However, communications between CICS on Open Systems
regions are established in the same way as other client/server relationships, in
that the region initiating the request acts as a client, and the region
responding to the request acts as a server. This client/server relationship is

Figure 66. The relationship between CICS regions and other CICS regions
The Encina PPC Executive is required for region-to-region communications

across TCP/IP because the PPC Executive emulates LU6.2 protocol and offers
two-phase commit processing. The Encina PPC Executive is also used when a
region (client) requests the PPC Gateway server to communicate with another
region across an SNA network.
For information about CICS intercommunication across TCP/IP and SNA

networks, see the CICS Intercommunication Guide.
Example configurations of client/server relationships
This section shows several example configurations.
A simple configuration
Figure 67 on page 192 shows a simple configuration of a DCE cell that

contains one CICS on Open Systems client, one CICS region, an Encina SFS
server, a DCE CDS Server, and a DCE Security Server. DCE RPCs are used to
establish connections and transmit data between clients and servers. Because
the SFS server is on the same host as the region, the Encina Fast Local
Transport (FLT) mechanism is also used to transmit data between the SFS
server and the region. This represents significant performance improvement
over the use of RPCs.

Figure 67. A simple configuration
A simple RPC-only setup
Figure 68 shows a variation of a simple configuration that does not use the
DCE Security Service or the CDS. Notice that there are no DCE servers in this
configuration. However, the DCE RPC daemon is still required for data
transmission between clients and servers.
Figure 68. A simple configuration without DCE Security Service and CDS

Two regions sharing an SFS server
Figure 69 shows a configuration in which two regions share an SFS server.
Figure 69. Two regions sharing an SFS server
CICS performance considerations
When you distribute your CICS system across a number of processors, you
need to ensure that the distribution does not adversely affect performance.
What goes where and how it performs depends on many factors: the design
of your data, the number of users, how much the users depend on the system,
your budget, and projected growth requirements.
The following section takes a performance-oriented look at how to design a

CICS network. It cannot tell you specifically how to distribute your system,
but it helps you to consider the performance costs of various aspects of a
design.
Designing a CICS network
CICS is designed to effectively exploit multiple processors on a fast network,

such as a Local Area Network (LAN). For simplicity, this section assumes you

are using CICS file control to manage your data. If you are using XA resource
managers to manage some or all of your data, the same information applies,
but the details differ.
Step 1. Design your data
Consider the following questions when deciding how to design your data:
v What files are needed?
v Is each file entry sequenced, relative-record, or key sequenced?
v What indexes are needed on each file?
v Approximately how many records are in each file?
v Approximately how many bytes are in each file?
v How many reads and writes per second will there be on each file?
v How many transactions per second will update each file (how many
syncpoints will there be when the file is updated)?
Notes:
1. Unique indexes are generally handled more efficiently than indexes that
allow duplicates. Each active index represents an overhead when inserting
records into the file.
2. The smaller the record, the larger the number of records that fit into a
given amount of physical memory and the faster the records are retrieved.
The benefits of a faster record retrieval normally outweigh the increased
cost of formatting more records for display.
3. Consider using binary integer fields rather than packed decimal or
character fields for storing sequence numbers. Use variable-length records
where appropriate.
Step 2. Understand how your users access CICS
The many ways of accessing CICS are listed below. Each requires a certain
amount of processing power in a certain place.
v Running cicsterm as an operating system process on a server machine or on
a desktop machine. The cicsterm process, when running on the CICS
region, uses up to 40 percent of the machine’s processing. Running cicsterm
on the CICS region machine greatly undermines performance and is
advisable only for an entry-level system. For short transactions, as much as
40 percent of the path length can be in cicsterm, so the first priority in
scaling up from a single machine configuration is to move the cicsterm
processes off the region machine.
v Running a 3270-capable Telnet client program or a concentrator box such as
a 3174, and running cicsteld as an operating system process.
v Running an application that uses the EPI as well as other UNIX facilities
(typically X Windows or drivers for special hardware).

v Using transaction routing from CICS for OS/2, using the interfaces and
tools that are available under OS/2.
Step 3. Set up a virtual network
Set up a virtual network where each machine runs only one of the following:
v A region
v An SFS server managing one file
For simplicity, this section assumes that all machines have the same size
processor.
If you think that the CICS region machine represents a bottleneck, you can
add additional CICS regions on additional machines at this stage. Bear in
mind the following:
v CICS regions do not share queues with each other. This can place
restrictions on the way applications use queues.
v Users have to be told which CICS regions to select.
Step 4. Identify processor workload
Identify how much of the processor is used for each machine on the virtual
network. An SFS file that needs to be accessed often uses more of a processor
than an SFS file that is accessed only occasionally. Examine your data design
and try to estimate the potential number of accesses for each file.
The processing for file control and syncpoint operations is approximately

evenly split between the region and the file system. Consider this information
when calculating what fraction of each virtual processor will be used when
the system is running at its designed throughput.
Step 5. Identify the operational effort
Identify the operational effort needed in the virtual network. This does not
affect the performance, but it can affect your decision about whether to select
either a small number of large processors, or a large number of small
processors.
For example, placing all of the SFS files on one machine simplifies backup,
but is not necessarily the most efficient use of the machine’s processor. You
can perform backup tasks remotely, that is, across the network, rather than by
using tape drives on the machine itself. Consider the need for these tasks
when you design your system.

Step 5. Map the virtual network
Map the virtual network to the real network, or to a proposed real network. It
is possible to configure the virtual network as a real network, using a large
number of processors and an appropriate LAN. This delivers maximum
performance, but can be costly in terms of initial expense and operational
effort.
When mapping the real network, consider the following:

v The model of hardware. Models differ in clock speed, number of processors,
expandability, processor architecture, memory architecture, and mounting
style.
v Putting several files on one host. If you do this, you should have the files
managed by one SFS server on that host.
v Running a CICS region with a local SFS server. If an SFS server is on the
same host as a CICS region using that SFS, then requests flow across a path
about 10 percent faster than the network path. See the CICS Administration
Guide for more information.
v If a transaction uses or updates no more than one SFS server, then
syncpoint can be run more quickly.
v Machines running only CICS regions and CICS clients do not require
frequent intervention, since they do not manage data that is updated in the
course of transactions.
Taken to the extreme, you would end up with all processes on one processor.
If this configuration meets your performance requirements, this is what you
should do; but it is important to explore the options for expansion as your
needs grow.
Step 6. Iterate a few times
The design process can reveal bottlenecks, or potential bottlenecks, in the

overall system. It is worth revisiting each point in this section to consider
whether to take a different design approach.
Step 7. Implement and test
If appropriate, implement and test the system or arrange for a prototype or

demonstration of some aspects of the system to get early feedback on whether
the designed system meets requirements.

Part 3. Appendixes

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.
For license inquiries regarding double-byte (DBCS) information, contact the

IBM Intellectual Property Department in your country or send inquiries, in
writing, to:
IBM World Trade Asia Corporation Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
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

DOCUMENT “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OR CONDITIONS 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 document. 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.
Licensees of this program who wish to have information about it for the
purpose of enabling: (i) the exchange of information between independently
created programs and other programs (including this one) and (ii) the mutual
use of the information which has been exchanged, should contact:
For Component Broker:
IBM Corporation
Department LZKS
11400 Burnet Road
Austin, TX 78758
U.S.A.
For TXSeries:
IBM Corporation
ATTN: Software Licensing
11 Stanwix Street
Pittsburgh, PA 15222
U.S.A.
Such information may be available, subject to appropriate terms and

conditions, including in some cases, payment of a fee.
The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM International
Program License Agreement or any equivalent agreement between us.
Any performance data contained herein was determined in a controlled

environment. Therefore, the results obtained in other operating environments
may vary significantly. Some measurements may have been made on
development-level systems and there is no guarantee that these measurements
will be the same on generally available systems. Furthermore, some
measurements may have been estimated through extrapolation. Actual results
may vary. Users of this document should verify the applicable data for their
specific environment.
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.
All statements regarding IBM’s future direction or intent are subject to change
or withdrawal without notice, and represent goals and objectives only.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples may
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.
If you are viewing this information softcopy, the photographs and color
illustrations may not appear.
Trademarks and service marks
The following terms are trademarks or registered trademarks of the IBM

Corporation in the United States, other countries, or both:
AFS IMS
AIX MQSeries
AS/400 MVS/ESA
CICS OS/2
CICS OS/2 OS/390
CICS/400 OS/400
CICS/6000 PowerPC
CICS/ESA RISC System/6000
CICS/MVS RS/6000
CICS/VSE S/390
CICSPlex Transarc
DB2 TXSeries
DCE Encina Lightweight Client VSE/ESA
DFS VTAM
Encina VisualAge
IBM WebSphere
Microsoft, Windows, Windows NT, and the Windows 95 logo are trademarks
of Microsoft Corporation in the United States and/or other countries.
Oracle and Oracle8 are registered trademarks of the Oracle Corporation in the
United States and/or other countries.
Notices 201
UNIX is a registered trademark of The Open Group in the United States
and/or other countries licensed exclusively through X/Open Company
Limited.
OSF and Open Software Foundation are registered trademarks of the Open
Software Foundation, Inc.
* HP-UX is a Hewlett-Packard branded product. HP, Hewlett-Packard, and

HP-UX are registered trademarks of Hewlett-Packard Company.
Orbix is a registered trademark and OrbixWeb is a trademark of IONA

Technologies Ltd.
Sun, SunLink, Solaris, SunOS, Java, all Java-based trademarks and logos, NFS,
and Sun Microsystems are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States and/or other countries.
Some of this documentation is based on material from Object Management

Group bearing the following copyright notices:
Copyright 1995, 1996 AT&T/NCR

Copyright 1995, 1996 BNR Europe Ltd.
Copyright 1991, 1992, 1995, 1996 by Digital Equipment Corporation
Copyright 1996 Gradient Technologies, Inc.
Copyright 1995, 1996 Groupe Bull
Copyright 1995, 1996 Expersoft Corporation
Copyright 1996 FUJITSU LIMITED
Copyright 1996 Genesis Development Corporation
Copyright 1989, 1990, 1991, 1992, 1995, 1996 by Hewlett-Packard Company
Copyright 1991, 1992, 1995, 1996 by HyperDesk Corporation
Copyright 1995, 1996 IBM Corporation
Copyright 1995, 1996 ICL, plc
Copyright 1995, 1996 Ing. C. Olivetti &C.Sp
Copyright 1997 International Computers Limited
Copyright 1995, 1996 IONA Technologies, Ltd.
Copyright 1995, 1996 Itasca Systems, Inc.
Copyright 1991, 1992, 1995, 1996 by NCR Corporation
Copyright 1997 Netscape Communications Corporation
Copyright 1997 Northern Telecom Limited
Copyright 1995, 1996 Novell USG
Copyright 1995, 1996 02 Technolgies
Copyright 1991, 1992, 1995, 1996 by Object Design, Inc.
Copyright 1991, 1992, 1995, 1996 Object Management Group, Inc.
Copyright 1995, 1996 Objectivity, Inc.
Copyright 1995, 1996 Oracle Corporation
Copyright 1995, 1996 Persistence Software

Copyright 1995, 1996 Servio, Corp.
Copyright 1996 Siemens Nixdorf Informationssysteme AG
Copyright 1991, 1992, 1995, 1996 by Sun Microsystems, Inc.
Copyright 1995, 1996 SunSoft, Inc.
Copyright 1996 Sybase, Inc.
Copyright 1996 Taligent, Inc.
Copyright 1995, 1996 Tandem Computers, Inc.
Copyright 1995, 1996 Teknekron Software Systems, Inc.
Copyright 1995, 1996 Tivoli Systems, Inc.
Copyright 1995, 1996 Transarc Corporation
Copyright 1995, 1996 Versant Object Technology Corporation
Copyright 1997 Visigenic Software, Inc.
Copyright 1996 Visual Edge Software, Ltd.
Each of the copyright holders listed above has agreed that no person shall be
deemed to have infringed the copyright in the included material of any such
copyright holder by reason of having used the specification set forth herein or
having conformed any computer software to the specification.
WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE

ACCURATE, THE OBJECT MANAGEMENT GROUP, AND THE
COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND WITH
REGARDS TO THIS MATERIAL INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE. The Object Management Group and the companies
listed above shall not be liable for errors contained herein or for incidental or
consequential damages in connection with the furnishing, performance, or use
of this material.
This software contains RSA encryption code.
Other company, product, and service names may be trademarks or service

marks of others.
Notices 203
Index
application development 137 attach security (SNA) 134
Numerics (continued) authenticated RPC 123
3270 terminal emulation 92
overview 49 authenticating IBM CICS Clients 93
A presentation services 137
relational databases 151
authentication
using a CICS userid and
ACID properties 10
tools 153 password 126
atomicity 10
tools for program using a DCE principal and
consistency 10
development 151 password 120
durability 10
application development tools authentication (DCE)
isolation 10
CICS application development in RPC 123
ACLs
environment 151 authorization
for SFS files 125
CICS application program by CICS 128
adding files to SFS 72
debugging 152 of user access to resources 128
Advanced Application Server 3
CICS application program automatic transaction initiation
advanced program-to-program
translation 152 (ATI) 77
communications (APPC)
CICS presentation interface
DTP applications 113
development 151 B
advertisement protocol (CDS) 100 backout 114
other tools 153
already verified 134 base services 32
application program
alternate indexes of files 72 Basic Mapping Support (BMS)
calling 152
API application development
transactions 152
Toolkit Executive 32 tool 152
Application Server Manager 57
Toolkit Server Core 32 physical map 152
application servers 11
application development 137 symbolic map 152
architecture
associating a program with a bind-time security
CICS Transaction Gateway 27
transaction 152 description of 114
client systems 25
business logic 138 binding
CICS application development communications servers 25
COM 149
environment 151 databases 30
binding information 98
DE-Light Gateway 27
CICS application program
debugging 152
Distributed Computing C
Environment (DCE) 33 C
CICS application program
recoverable queueing service BMS source files 152
translation 152
CICS presentation interface (RQS) 30 translation of source 152
development 151 relational databases 30 CDS, using to locate a server 99
resource managers 29 CDS administration 168
CICS region application
structured file server (SFS) 29 CDS clerk 36, 100
programming 143
Toolkit Executive 32 CDS Server 33
CICS servers 139
Toolkit Server Core 32 CECI, CICS transaction 160
data services 138
designing TP applications 137 transaction base services 31 CEDF
detail 137 transaction processing application development
Encina application monitor 24 tool 152
TXSeries 23 CEDF, CICS transaction 160
programming 144
external call interface (ECI) 140, ASCII to EBCDIC data Cell Directory Services (CDS)
142 conversion 115 Server 33
external presentation interface associating a program with a CEMT, CICS transaction 160
(EPI) 141, 142 transaction 152 checkout, program 152
IBM CICS Clients 139 asynchronous processing CICS
Internet applications for (CICS) 113 application development
CICS 142 atomicity 10 environment 151

CICS (continued) cics_regions group 124 (continued) communications 89 (continued)
application program SFS as member 125 CICS DCE-enabled clients 97
debugging 152 CICS security services 126 CICS family TCP/IP 102
application program authenticating users 126 CICS local terminal 98
translation 152 authorizing access to client interfaces 92
application programming 139 resources 128 client-server 91
client/server relationships 186 resource security 128 connecting and authenticating
configuration planning 183 transaction security 128 IBM CICS Clients 93
ECI and EPI programs 142 using an External Security data conversion 115
example configurations 191 Manager 127 data integrity
network design 193 XA-enabled databases 132 (synchronization) 114
presentation interface cics_sfs group 124 DCE cells, locating systems
development 151 CICS SFS Import Tool, outside 101
transaction processing cicssfsimport 160 DCE RPCs 98
environment 40 CICS Transaction Gateway 27 detail 89
CICS 3270 terminal emulation CICS transactions 160 EBCDIC to ASCII data
(client) 92 cics_users group 124 conversion 115
CICS 3270 terminal emulation cicscheckup 160 example 90
(region) 98 cicscp, the CICS Control indoubt resolution (CICS) 115
cics_admin group 124 Program 159 Internet access to CICS 95
CICS clients 91 cicsddt, the CICS DB2 Diagnostic link security (CICS
communication interfaces 92, 93 Tool 160 communications) 135
3270 terminal emulation 92 cicsterm 92 listeners (CICS) 112
external call interface clerk, defined 36 local SNA support (CICS) 106
(ECI) 92 client/server computing mixing SNA and TCP/IP 109
external presentation interface COM 148 overview 46
(EPI) 92 client/server model 16 PPC Gateway server 107
printer emulation 93 client systems 25 PPC TCP/IP 104
connecting and Internet security services 130 protocols 101
authenticating 93 security considerations 130 protocols (IBM CICS Clients) 94
DCE-enabled clients 97 Web security services 130 security 114
Internet access 95 clustered (KSDS) 72 SNA 105
protocols 94 COBOL SNA flowed userids
Telnet clients 98 BMS source files 152 (security) 134
CICS Control Program, cicscp 159 External File Handler, synchronization for data
CICS DB2 Diagnostic Tool, restrictions 176 integrity 114
cicsddt 160 translation of source 152 synchronization levels 102
CICS family TCP/IP 102 COM 148 synchronization levels (CICS use
security considerations 132 of) 114
binding 149
CICS for OS/2 to CICS on Open TCP/IP 102
commit 114
Systems data conversion 115 Telnet clients 98
commit protocol 17
CICS listeners 112 two-phase commit process 115
Common Object Request Broker
CICS local terminal 98 user security (CICS
(CORBA) 144
CICS on Open Systems to CICS for communications) 135
communications 89 with CICS Clients 93
OS/2 data conversion 115 ASCII to EBCDIC data with users 91
CICS permanent database 54 conversion 115
CICS permanent resource authenticating a remote system communications gateways 25
definitions 54 (security) 132 comtidl compiler 148
CICS queues 74 authenticating a remote user configuring a CICS
extrapartition destinations 77 (security) 133 environment 156
indirect destinations 78 authorizing access to confirm 114
intrapartition destinations 76 resources 135
temporary storage queues 78 CICS client interfaces 92 connecting and authenticating IBM
transient data queues 75 CICS communication CICS Clients 93
cics_regions group 124 functions 111, 112 consistency 10

conversation-level security DCE (continued) distributed unit of work 114
(SNA) 134 DTS clerk 36 DTS administration 168
conversion of data between general DCE security DTS clerk 36
systems 115 process 120 dumps in a CICS environment 158
region principal 125 durability 10
D replica CDS servers 35 dynamic link libraries 54
data consistency, preserving 87 replica Security Servers 35 dynamic transaction backout 65
data conversion 115 RPC daemon 36
ASCII to EBCDIC 115 security 119 E
between systems 115 security clerk 36 EBCDIC to ASCII data
CICS for OS/2 to CICS on Open security groups 124 conversion 115
Systems 115 security service 33 ECI (external call interface)
CICS on Open Systems to CICS SFS security 125 developing 142
for OS/2 115 what makes up a DCE cell? 33 emergency restart 60
EBCDIC to ASCII 115 DCE CDS, using to locate a Encina
data management 67 server 99 configuration planning 184
considerations for sharing DCE cell 33 Encina++/CORBA 149
data 86 DCE Cell Directory Service Encina++/CORBA-DCE 149
databases 82 (CDS) 98 Encina++/DCE 149
DB2 82 name lookup 100 Encina Monitor
DB2 for CICS files and DCE clients 36 application programming 144
queues 84 DCE Distributed Time Service (DTS) systems management 161
detail 67 Server 34 transaction processing
files 69 DCE-enabled CICS clients 97 environment 42
introduction 67 DCE security Encina queues 80
journals 85 authentication 120 dequeueing from queue sets 81
overview 45 DCE security service Enconsole, tool for managing
queues 73 CDS Server 33 Encina 162
relational databases 82 cell 33 access to Encina settings 162
SQL servers 82 DCE clients 36 monitoring transactions 163
types of data 68 DTS clerk 36 starting Encina servers 163
Database Managed Space (DMS) general DCE security stopping Encina servers 163
Table Space 85 process 120 Enterprise Application Server 3
database manager, relational 180 security clerk 36 entry-sequenced file (ESDS) 71
databases 30, 82 Security Server 33 EPI (external presentation interface)
DB2 82 DCE Security Service 119 developing 142
Database Managed Space (DMS) ESM (External Security Manager)
authenticated RPC 123
Table Space 85 overview 127
authenticating access from
field name restrictions 179 outside a DCE cell 123 event log 55
System Managed (SMS) Table
DE-Light Gateway 27 Execution Diagnostic Facility (CEDF)
Space 85
debugging application development
DB2 for CICS files and queues 84
CEDF 152 tool 152
DB2 Universal Database 5
debugging CICS application external call interface (ECI) 140
DCE
programs 152 developing 142
authenticating access from
outside a DCE cell 123 Distributed Computing Environment External File Handler,
authentication with the CICS (DCE) restrictions 176
default userid 122 configurations 172 external presentation interface
CDS clerk 36 distributed program link (DPL) 113 (EPI) 141
CDS Server 33 Distributed Time Service (DTS) developing 142
cell 33 Server 34 External Security Manager
Cell Directory Services (CDS) distributed transaction using ACLs 130
Server 33 processing 14 External Security Manager (ESM)
client systems 36 distributed transaction processing overview 127
Distributed Time Service (DTS) (DTP) 113 extrapartition destinations
Server 34 distributed transaction service 32 (queues) 77
Index 207
intercommunication network
F choosing 181
M
facilities provided by TXSeries 23 managing a CICS environment 155
intercommunication security
application development, managing an Encina
authenticating a remote
overview 49 environment 161
system 132
communications, overview 46 MIDL
internal data consistency, compiler 148
data management, overview 45
preserving 87 Monitor 149
security, overview 48
Internet Monitor Cell Manager 184
systems management,
overview 49 developing applications for Monitor Node Manager 184
transaction processing, CICS 142 monitoring a CICS
overview 44 Internet access to CICS 95 environment 157
field name restrictions developing applications 142 MQSeries 6, 28
Internet gateway 27
DB2 179
Internet Inter-ORB Protocol N
file management 174 name lookup (CDS) 100
file organization 70 (IIOP) 144
Internet security services 130 name service options 98
clustered (KSDS) 72 named pipe listener 112
entry-sequenced (ESDS) 71 Interval Control Manager 57
relative (RRDS) 72 intrapartition destinations O
files 69 (queues) 76 Object Management Group
adding to SFS 72 isolation 10 (OMG) 144
alternate indexes 72 Object Request Broker (ORB) 144
indexes 72
J OCCS 150
organization 70 Java gateway 27 online transaction processing
primary indexes 72 Java OTS client 150 ACID properties 10
function shipping (CICS) 112 journal records 85 atomicity 10
journals 85 consistency 10
G CICS records 85 durability 10
gateways synchronizing output 85 isolation 10
DE-Light 27 transactions 9
Internet 27
K what is a region? 53
Java 27 key-sequenced data set (KSDS) 72 Application Server
keytab file Manager 57
Gateways
contains region principal 125 CICS permanent resource
Internet 95
definitions 54
Java 95
L dynamic link libraries 54
I life cycle of a region 59 emergency restart 60
life cycle of a transaction, basic event log 55
IBM CICS Clients
overview 12 Interval Control Manager 57
developing ECI and EPI
link security life cycle of a region 59
programs 142
description of 114 listeners 57
external call interface (ECI) 140
listeners 57 log manager 57
external presentation interface
listeners (CICS) 112 operating system memory 58
(EPI) 141
recovery during restart 60
Internet applications for local 3270 terminal (CICS) 98
Recovery Manager 57
CICS 142 local SNA
runtime resource
programming 139 security considerations 133
definitions 56
IBM HTTP Server 28 local SNA listener 112
system log 58
IBM Tivoli management servers 7 local SNA support 102 when a region is stopped 54
IBM TXSeries Administration local SNA support (CICS) 106 when the region is
Tool 158 synchronization levels 107 running 55
IDL (DCE) lock service 32 Windows NT services 55, 56
compiler 148 log service 32 operating system memory 58
indexes of files 72 logical unit of work (LUW) 114 process data segment 58
indirect destinations (queues) 78 LU 6.2 181 processor text segment 58
indoubt condition 115 LUTYPE6.2 101, 105 shared text segment 58

operating system memory 58 programming (continued) restrictions
(continued) tools for program COBOL External File
system shared segment 58 development 151 Handler 176
task shared segment 58 protocols (communications) 101 External File Handler 176
CICS family TCP/IP 102 field names (DB2) 179
P PPC TCP/IP 104 SFS for queue and file
password verification (SNA) 134 SNA 105 control 174
performance TCP/IP 102 rollback 114
CICS network design 193 RPC (Remote Procedure Call) 172
permanent database, CICS 54 Q RPC daemon 36
persistent verification 134 queue and file control RPC listener 112
platforms SFS 174 RPCs 149
WebSphere Application Server 4 queue and file management RQS++ 150
PPC Gateway server 107 choosing 174 runtime resource definitions 56
security considerations 133 Queue sets 80
PPC TCP/IP 104 queues 73 S
security considerations 133 CICS queues 74 sample application
dequeueing from queue sets 81 overview 18
primary indexes of files 72
Encina queues 80 sample transaction processing
principal
extrapartition destinations 77 environment 18
region 125
indirect destinations 78 sample application 18
printer emulation 93
intrapartition destinations 76 sample system environment 19
priority 62 transaction processing flow 20
temporary storage queues 78
priority of tasks 62 scheduling 62
transient data queues 75
process data segment 58 scheduling of tasks 62
processor text segment 58 R Secured Hypertext Transport
program testing 152 RDO commands 160 Protocol (S-HTTP) 131
programming recoverable processes 17 Secured Sockets Layer (SSL) 131
associating a program with a recovery security 117
transaction 152 user journals 65 ACLs for CICS 125
business logic 138 recovery and restart ACLs for SFS files 125
CICS application development startup 65 ACLs with an ESM 130
environment 151 recovery during restart 60 authenticating a remote
CICS application program Recovery Manager 57 system 132
debugging 152 authenticating a remote
recovery service 32
CICS application program user 133
region principal 125
translation 152 authenticating access from
relational database managers
CICS presentation interface outside a DCE cell 123
choosing 180
development 151 authentication for transaction
CICS region application relational databases 30, 82
services
programming 143 DB2 for CICS files and using a CICS userid and
CICS servers 139 queues 84 password 126
data services 138 programming 151 using a DCE principal and
designing TP applications 137 SQL restrictions for password 120
Encina application non-XA-enabled databases 84 authorizing access to
programming 144 relative record file (RRDS) 72 resources 128, 135
external call interface (ECI) 140, Remote Procedure Call (RPC) 172 by CICS 128
142 Remote Procedure Calls (RPCs) CICS 126
external presentation interface authenticated RPC 123 CICS security services 126
(EPI) 141, 142 resource managers 29 client systems 130
IBM CICS Clients 139 databases 30 communications security 132
Internet applications for recoverable queueing service DCE 119, 172
CICS 142 (RQS) 30 DCE Security Server 33
presentation services 137 relational databases 30 detail 117
relational databases 151 structured file server (SFS) 29 External Security Manager
tools 153 resource security 128 (CICS) 127
Index 209
security 117 (continued) synchronization levels 102 systems management 155
intercommunication 114 (continued) (continued)
Internet security services 130 local SNA (CICS) 107 tools for a CICS
link security (CICS PPC Gateway server 109 environment 158
communications) 135 PPC TCP/IP support for 105 trace in a CICS environment 158
overview 48 two-phase commit 115 transactions for CICS 160
security models 117 synchronization point 11 transactions for CICS, CECI 160
SNA flowed userids 134 synchronizing journal output 85 transactions for CICS, CEDF 160
Telnet clients 131 transactions for CICS,
user security (CICS system log 58 CEMT 160
communications) 135 System Managed (SMS) Table Systems Network Architecture
Web security services 130 Space 85 (SNA)
XA-enabled databases and System Network Architecture communicating across 105
CICS 132 (SNA) 181 local SNA support (CICS) 106
security administration (DCE) 168 system shared segment 58 PPC Gateway server 107
security clerk 36 systems management 155 synchronization levels 102
SFS
queue and file control 174 CDS administration 168 T
SFS++ 150 commands for CICS 159 table space
SFS (structured file server) 29 commands for CICS, Database Managed Space
sfsimport, the CICS SFS Import cicscheckup 160 (DMS) 85
Tool 160 commands for CICS, cicscp 159 System Managed (SMS) 85
shared text segment 58 commands for CICS, cicsddt 160 task shared segment 58
sharing and distributing data 86 commands for CICS, tasks 62
SNA cicssfsimport 160 TCP/IP 102
BIND request 114 commands for CICS, RDO 160 CICS family TCP/IP 102
conversation-level security 134 configuring a CICS use of 101
password verification 134 environment 156 TCP/IP listener 112
synchronization level 114 DCE tools 169
Telnet clients (CICS) 98
use of 101 DCEsetup 169
security considerations 131
SNA (System Network DTS administration 168
temporary storage queues 78
Architecture) 181 dumps in a CICS
Thread-to-Tid Mapping Service 32
solicitation protocol (CDS) 100 environment 158
Encina command-line ThreadTid 32
source code translation 152 Tivoli management servers 7
SQL restrictions for non-XA-enabled interfaces 163
Enconsole 162 TM/XA interface 33
databases 84
IBM TXSeries Administration Toolkit Executive 31
SQL servers 82
Tool for CICS 158 Toolkit Server Core 31
Standard Application Server 3
managing a CICS tools for program development 151
starting servers in a CICS
environment 155 CICS application development
environment 157
managing an Encina environment 151
startup CICS application program
environment 161
recovery and restart 65 managing DCE 168 debugging 152
statistics in a CICS messages in a CICS CICS application program
environment 158 environment 157 translation 152
stopping servers in a CICS monitoring a CICS CICS presentation interface
environment 157 environment 157 development 151
strict prioritization of queue sets 81 overview 49 other tools 153
structured file server (SFS) 29 security administration 168 tools for systems management
sync point 114 starting servers in a CICS CICS commands 159
synchronization level 114 environment 157 CICS commands,
synchronization levels 102 statistics in a CICS cicscheckup 160
CICS family TCP/IP support environment 158 CICS commands, cicscp 159
for 104 stopping servers in a CICS CICS commands, cicsddt 160
CICS use of 114 environment 157 CICS commands,
indoubt resolution (CICS) 115 systems management 155 cicssfsmimport 160

tools for systems management transaction routing (CICS) 113 WebSphere Application Server 3
(continued) transaction security 128 (continued)
CICS commands, RDO 160 transactional RPC 32 supported platforms 4
CICS environment 158 transactions 9 weighted prioritization of queue
CICS transactions 160 CEDF 152 sets 81
CICS transactions, CECI 160 transient data queues 75 what is a region? 53
CICS transactions, CEDF 160 translating CICS application Application Server Manager 57
CICS transactions, CEMT 160 programs 152 CICS permanent resource
DCE tools 169 TRPC 32 definitions 54
DCEsetup 169 two-phase commit 17, 115 dynamic link libraries 54
Enconsole 162 TXSeries emergency restart 60
IBM TXSeries Administration example configurations 37 event log 55
Tool for CICS 158 TXSeries architecture 23 Interval Control Manager 57
trace in a CICS environment 158 client systems 25 life cycle of a region 59
TRAN 32 communications gateways 25 listeners 57
transaction base services 31 databases 30 log manager 57
transaction classes 62 DE-Light Gateway 27 operating system memory 58
transaction identifier (CEDF) 152 Distributed Computing process data segment 58
transaction life cycle, basic Environment (DCE) 33 recovery during restart 60
overview 12 Internet gateway 27 Recovery Manager 57
transaction processing 9, 53 Java gateway 27 runtime resource definitions 56
ACID properties 10 recoverable queueing service shared text segment 58
atomicity 10 (RQS) 30 system log 58
consistency 10 relational databases 30 system shared segment 58
durability 10 resource managers 29 task shared segment 58
isolation 10 structured file server (SFS) 29 when a region is stopped 54
detail 53 Toolkit Executive 32 when the region is running 55
Toolkit Server Core 32 Windows NT services 55, 56
overview 44
transactions 9 transaction base services 31 Windows NT services 55, 56
what is a region? 53 transaction processing World-Wide Web (WWW) access to
monitor 24 CICS
Application Server
Manager 57 developing applications 142
CICS permanent resource
U
definitions 54
user journals, as used in X
recovery 65 X/Open XA 32
dynamic link libraries 54
user security
emergency restart 60
description of 114
event log 55
using an External Security Manager
Interval Control Manager 57
overview 127
life cycle of a region 59
listeners 57
log manager 57
V
verifying passwords (SNA) 134
operating system memory 58
Virtual Storage Access Method
recovery during restart 60
(VSAM)
Recovery Manager 57
entry-sequenced (ESDS) 71
runtime resource
key-sequenced data set
definitions 56
(KSDS) 72
system log 58
relative record data set
when a region is stopped 54
(RRDS) 72
when the region is
VisualAge C++ 6
running 55
VisualAge for Java 6
Windows NT services 55, 56
volume service 32
transaction processing environments
CICS 40 W
Encina Monitor 42 Web security services 130
transaction processing monitor 24 WebSphere Application Server 3
Index 211
IBMR
Program Number: 5765-E27

5639-I07
5765-E28
5765-E29
5639-I09
5639-I11
5765-E31
5765-E30
Printed in the United States of America

on recycled paper containing 10%
recovered post-consumer fiber.
SC09-4455-00
Spine information:
IBM WebSphere Concepts and Facilities Version 3.0 SC09-4455-00

Concepts and Facilities

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Concepts and Facilities

Загружено:

Авторское право:

Доступные форматы

WebSphere Application Server Enterprise Edition

First Edition (June 1999)

© Copyright IBM Corp. 1999 iii

iv WebSphere: Concepts and Facilities

Chapter 11. Configuration planning . . . 183

© Copyright IBM Corp. 1999 vii

viii WebSphere: Concepts and Facilities

© Copyright IBM Corp. 1999 ix

Who should read this book

There is no prerequisite knowledge about transaction processing, CICS,

Part 1. Introducing TXSeries

Part 2. More about TXSeries facilities

© Copyright IBM Corp. 1999 xi

Conventions used in this book

WebSphere Application Server Enterprise Edition documentation uses the

xii WebSphere: Concepts and Facilities

About this book xiii

How to send your comments

Your feedback is important in helping to provide the most accurate and

xiv WebSphere: Concepts and Facilities

See “Part 2. More about TXSeries facilities” on page 51 for details.

© Copyright IBM Corp. 1999 1

WebSphere Application Server family

To enable customers to achieve their e-business goals, WebSphere is available

© Copyright IBM Corp. 1999 3

WebSphere Application Server Enterprise Edition

The WebSphere Application Server Enterprise Edition contains all of the

4 WebSphere: Concepts and Facilities

The WebSphere Application Server Enterprise Edition is integrated with other

Figure 1. Integration of WebSphere with other products

The Enterprise Application Server includes the following additional products

Chapter 1. IBM WebSphere 5

DB2 Universal Database’s Net.Data enables Internet and intranet access to

The IBM MQSeries range of products enables application programs to

6 WebSphere: Concepts and Facilities

The IBM Tivoli management servers provide simplified, enterprise-wide

Systems management includes performance, network management, disaster

Chapter 1. IBM WebSphere 7

If you want more details on transaction processing, see “Chapter 4.

In online transaction processing (OLTP), many users access large quantities of

Transaction processing enables business applications to concentrate on

Each user’s interaction with a business information system involves one or

© Copyright IBM Corp. 1999 9

In CICS, a group of related operations is called a logical unit of work (LUW). In

All transactions ensure the integrity and consistency of business information

A transaction can comprise one or more LUWs, as shown in Figure 3 on

10 WebSphere: Concepts and Facilities

Figure 3. Transactions and units of work

Transaction processing monitors

Transaction processing is controlled by a transaction processing monitor,

A CICS region (or Encina Monitor application server) performs work

Chapter 2. Online transaction processing 11

A CICS region subcontracts many services to other servers better able to do

The transaction life cycle

This section provides an overview of the life cycle of a transaction. The

Figure 4. The transaction process for CICS

12 WebSphere: Concepts and Facilities

The transaction process is similar in Encina:

Chapter 2. Online transaction processing 13

Distributed transaction processing

Modern business information systems are increasingly decentralized and

In the simplest distributed processing system, a transaction involves several

14 WebSphere: Concepts and Facilities