Concepts And Facilities

WebSphere Application Server Enterprise Edition TXSeries

IBM

Concepts and Facilities Version 3.0

SC09-4455-00

WebSphere Application Server Enterprise Edition 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

Tables .

.

.

.

.

.

.

.

.

.

.

.

.

ix

. . . . .

. . . . .

. . . . .

. . . . .

. xi . xi . xi . xii . xiv

About this book . . . . . Who should read this book . Document organization . . Conventions used in this book How to send your comments.

Part 1. Introducing TXSeries . . .

1

Chapter 1. IBM WebSphere . . . . . WebSphere Application Server family . . WebSphere Application Server Enterprise Edition . . . . . . . . . . . . Products for use with Enterprise Application Server . . . . . . . . IBM DB2 Universal Database. . . . MQSeries . . . . . . . . . . VisualAge . . . . . . . . . . Tivoli management servers . . . .

. .

3 3

.

4

. . . . .

5 5 6 6 7

Chapter 2. Online transaction processing Transactions . . . . . . . . . . . Transaction processing monitors. . . . . The transaction life cycle . . . . . . . Distributed transaction processing . . . . A sample transaction processing environment . . . . . . . . . . . The sample application. . . . . . . The sample system environment . . . The transaction processing flow . . . .

9 9 11 12 14

Chapter 3. Overview of IBM TXSeries What is TXSeries? . . . . . . . . . The TXSeries components and architecture . . . . . . . . . . TXSeries environments . . . . . . . . CICS transaction processing environment Encina Monitor transaction processing environment . . . . . . . . . . TXSeries facilities . . . . . . . . . Transaction processing . . . . . . . © Copyright IBM Corp. 1999

18 18 19 20 23 23 23 40 40 42 44 44

Data management . . Communications . . . Security . . . . . . Application development Systems management .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

45 46 48 49 49

Part 2. More about TXSeries facilities . . . . . . . . . . . . 51 Chapter 4. Transaction processing . . What is a CICS region?. . . . . . . When a CICS region is stopped . . . When a CICS region is running . . . The life cycle of a CICS region . . . . Recovery during restart . . . . . General transaction processing services Task management . . . . . . . Performance optimization . . . . . Workload distribution . . . . . . Program management . . . . . . System resource management . . . Controlling access to and updating data Data communication . . . . . . Terminal management . . . . . . Time management . . . . . . . Security management . . . . . . Recovery management . . . . . .

. . . . . .

. . . . .

53 53 54 55 59 60 61 62 62 63 63 63 63 64 64 64 64 65

Chapter 5. Data management . . . An introduction to data management . Types of data . . . . . . . . . Files . . . . . . . . . . . . File organization . . . . . . . Primary and alternate indexes . . Adding files to an SFS server. . . Queues . . . . . . . . . . . CICS queues . . . . . . . . Encina queues. . . . . . . . Relational databases. . . . . . . SQL restrictions for non-XA-enabled relational databases . . . . . . Using DB2 to manage CICS files and queues . . . . . . . . . . Journals . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

67 67 68 69 70 72 72 73 74 80 82

.

.

84

. .

. .

84 85

. . . . .

iii

CICS journal records . . . . . . . Synchronizing journal output . . . . Considerations for sharing and distributing data . . . . . . . . . . . . . . CICS local and remote data . . . . . Data integrity . . . . . . . . . . Recovery . . . . . . . . . . . Chapter 6. Communications . . . . . Communicating with users . . . . . . CICS client interfaces . . . . . . . Client communications with mainframe-based CICS . . . . . . . Communicating with IBM CICS Clients Accessing CICS from the Internet . . . Communicating with CICS DCE-enabled clients . . . . . . . . . . . . Communicating with CICS Telnet clients Communicating with CICS local terminals . . . . . . . . . . . Communication using DCE RPCs . . . . Locating servers for communication . . . Using the DCE CDS in a DCE cell . . . Network protocols . . . . . . . . . SNA synchronization levels . . . . . Communicating across TCP/IP connections . . . . . . . . . . Communicating across SNA connections Mixing the communications methods More about CICS intercommunication. . . CICS listeners . . . . . . . . . . CICS intercommunication facilities . . . An introduction to secure communications Ensuring data integrity with synchronization support . . . . . . . CICS use of synchronization levels . . . Converting between EBCDIC and ASCII data . . . . . . . . . . . . . . Chapter 7. Security. . . . . . . . . The TXSeries security models . . . . . The TXSeries security model using DCE Authenticating users and servers with DCE . . . . . . . . . . . . . Authenticating access from systems outside a DCE cell . . . . . . . . DCE security information used for CICS The TXSeries security model using CICS Authenticating CICS users by a CICS userid and password . . . . . . .

iv

WebSphere: Concepts and Facilities

85 85 86 86 86 87 89 91 92 93 93 95 97 98 98 98 98 99 101 102 102 105 109 111 112 112 114 114 114 115 117 117 119 120 123 124 126 126

Using an External Security Manager for CICS security . . . . . . . . . . Authorizing access to resources . . . . . CICS authorization security . . . . . Security considerations for IBM CICS Clients . . . . . . . . . . . . . Web security services . . . . . . . Security considerations for CICS Telnet clients . . . . . . . . . . . . . Security considerations between CICS and XA-enabled databases . . . . . . . . Ensuring secure communications . . . . Authenticating the remote system that sent the request . . . . . . . . . Authenticating the user that initiated the request . . . . . . . . . . . . Authorizing access to resources . . . .

127 128 128 130 130 131 132 132 132 133 135

Chapter 8. Application development. . Designing transaction processing applications . . . . . . . . . . CICS application programming . . . . IBM CICS Clients programming. . . CICS region application programming The CICS IIOP ORB . . . . . . . Encina application programming . . . The Encina Monitor Application Development Environment . . . . Encina RQS API . . . . . . . . Encina SFS API . . . . . . . . Encina PPC API . . . . . . . . Encina COM API. . . . . . . . Encina++ . . . . . . . . . . Encina tools available only on Windows platforms . . . . . . . . . . Application programming for relational databases . . . . . . . . . . . Application development tools . . . . CICS application development environment . . . . . . . . . Third-party application development tools . . . . . . . . . . . .

. 137

Chapter 9. Systems management. Managing a CICS environment . . Configuration . . . . . . . Starting and stopping servers . Monitoring systems . . . . . The CICS administration tools . Managing an Encina environment .

. . . . . . .

. . . . . . .

. . . . . . .

. 137 . 139 . 139 143 . 144 . 144 . . . . . .

145 146 147 147 148 149

. 150 . 151 . 151 . 151 . 153 155 155 156 157 157 158 161

The Enconsole Interface . . . . . . Using the Tivoli Global Enterprise Manager (CICS and Encina) . . . . . . . . . Managing resources with GEM . . . . Using the GEM console . . . . . . Managing Encina with GEM—limitations Tasks in GEM . . . . . . . . . . Controlling access . . . . . . . . Managing the Distributed Computing Environment (DCE) . . . . . . . . . CDS administration . . . . . . . . Security administration. . . . . . . DTS administration . . . . . . . . DCE administration tools . . . . . .

162 164 165 165 166 167 167 168 168 168 168 169

Chapter 10. Component planning. . . Encina and CICS . . . . . . . . . Choosing a DCE configuration . . . . Deciding how to manage files and queues Using an SFS Server to manage CICS queues and data files . . . . . . Using DB2 to manage CICS queues and data files . . . . . . . . . . Choosing a relational database manager Planning the intercommunication network

. 171 . 171 . 172 174

Chapter 11. Configuration planning .

. 183

.

. 174 . 176 180 181

Planning how to distribute your system Distributing CICS . . . . . . . Distributing Encina . . . . . . . The CICS client/server distributed environment . . . . . . . . . . The relationship between terminal users and CICS regions . . . . . . . The relationship between Encina servers and CICS regions . . . . . . . The relationship between DCE servers and CICS regions . . . . . . . The relationship between a CICS region and other CICS regions . . . . . Example configurations of client/server relationships . . . . . . . . . CICS performance considerations . . . Designing a CICS network . . . .

183 . 183 . 184 . 186 . 187 . 188 . 189 . 190 . 191 . 193 . 193

Part 3. Appendixes . . . . . . . 197 Notices . . . . . . . . . Trademarks and service marks .

. .

. .

. .

. 199 . 201

Index

.

.

.

. 205

.

.

.

.

.

.

.

.

.

Contents

v

vi

WebSphere: Concepts and Facilities

Figures 1. Integration of WebSphere with other products . . . . . . . . . . . 2. A transaction . . . . . . . . . 3. Transactions and units of work 4. The transaction process for CICS 5. Distributed transactions . . . . . . 6. An Example Three-Tiered Distributed System . . . . . . . . . . . 7. Sample Order-Entry Application 8. Sample system environment . . . . 9. CICS process flow for the sample application . . . . . . . . . . 10. General TXSeries architecture 11. Client systems and communications gateways . . . . . . . . . . . 12. Resource managers . . . . . . . 13. Transaction base services . . . . . 14. A DCE cell . . . . . . . . . . 15. Distributed Computing Environment (DCE) . . . . . . . . . . . . 16. A simple distributed configuration using CICS in a non-DCE cell environment . . . . . . . . . 17. A distributed configuration using CICS in a DCE cell environment . . . . . 18. A simple Encina Monitor configuration 19. The CICS environment . . . . . . 20. The Encina Monitor environment 21. General security concepts . . . . . 22. Machine with a CICS region not running . . . . . . . . . . . 23. Windows NT machine with a CICS region running . . . . . . . . . 24. Data management services . . . . . 25. General file services . . . . . . . 26. File organizations . . . . . . . . 27. General use of queues . . . . . . 28. An example use of queues . . . . . 29. CICS transient data queues. . . . . 30. CICS intrapartition transient data queues . . . . . . . . . . . 31. CICS extrapartition transient data queues . . . . . . . . . . . 32. CICS temporary storage queues 33. Encina queues and queue sets © Copyright IBM Corp. 1999

5 10 11 12 15

34. 35. 36. 37. 38.

17 18 19

39.

21 24

41.

40.

42. 26 29 31 35 36

43. 44. 45. 46.

37 47. 38 39 41 43 48

48. 49. 50. 51.

54 52. 56 68 70 71 73 74 76 77 78 79 80

53. 54. 55. 56. 57. 58. 59. 60. 61.

An example Encina queue set Relational database services . . . . A TXSeries communications network Communication between CICS clients and a CICS region. . . . . . . . The CICS Transaction Gateway (from standard HTTP browser) . . . . . The CICS Transaction Gateway (from Java-enabled browser) . . . . . . CDS components performing a CDS lookup . . . . . . . . . . . Communicating with CICS family TCP/IP support . . . . . . . . Communicating via Encina PPC TCP/IP . . . . . . . . . . . Using local SNA support to communicate across SNA . . . . . PPC Gateway connection to an SNA network . . . . . . . . . . . Using a PPC Gateway server to communicate across SNA . . . . . Communications using TCP/IP, a PPC Gateway server, and SNA . . . . . Communications using a PPC Gateway server and SNA . . . . . . . . Security services . . . . . . . . The general DCE security process Authentication of CICS users by a DCE principal and password . . . . . . Authenticating CICS users by a CICS userid and password . . . . . . . CICS transaction and resource authentication . . . . . . . . . General 3-tier application programming . . . . . . . . . CICS application programming Encina application programming CICS and Encina product architecture CICS in a DCE cell environment CICS in an RPC-only environment A region using an SFS server that is on the same machine . . . . . . . . Two regions sharing the same SFS server . . . . . . . . . . . . CICS configuration . . . . . . .

82 83 90 92 96 97 100 104 105 106 107 108 110 111 119 120 122 126 129 137 139 145 171 173 173 175 175 184

vii

62. An Example Encina Monitor Cell 63. The relationship between terminal users and CICS regions . . . . . . 64. The relationship between CICS regions and Encina servers . . . . . . . 65. The relationship between CICS regions and DCE servers . . . . . . . .

viii

WebSphere: Concepts and Facilities

186 188 189 190

66. The relationship between CICS regions and other CICS regions . . . . . . 67. A simple configuration . . . . . . 68. A simple configuration without DCE Security Service and CDS . . . . . 69. Two regions sharing an SFS server

191 192 192 193

Tables 1.

Conventions used in this book

© Copyright IBM Corp. 1999

xii

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.



Where x is the name of a key, indicates a control-character sequence. For example, 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



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 . For example, the instruction “Enter the ls command” means type ls at a command prompt and then press .

[]

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 [email protected]. 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. © Copyright IBM Corp. 1999

3

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.

WebSphere Application Server Enterprise Edition 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.

4

WebSphere: Concepts and Facilities

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.

6

WebSphere: Concepts and Facilities

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

8

WebSphere: Concepts and Facilities

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.

© Copyright IBM Corp. 1999

9

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),

10

WebSphere: Concepts and Facilities

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

12

WebSphere: Concepts and Facilities

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.

Chapter 2. Online transaction processing

13

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.

14

WebSphere: Concepts and Facilities

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 Chapter 2. Online transaction processing

15

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.

16

WebSphere: Concepts and Facilities

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.

Chapter 2. Online transaction processing

17

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.

18

WebSphere: Concepts and Facilities

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

Chapter 2. Online transaction processing

19

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.

20

WebSphere: Concepts and Facilities

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. Chapter 2. Online transaction processing

21

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.

22

WebSphere: Concepts and Facilities

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.

© Copyright IBM Corp. 1999

23

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

24

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.

WebSphere: Concepts and Facilities

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

26

WebSphere: Concepts and Facilities

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. Chapter 3. Overview of IBM TXSeries

27

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

28

WebSphere: Concepts and Facilities

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.

Chapter 3. Overview of IBM TXSeries

29

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)

.

30

WebSphere: Concepts and Facilities

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.

Chapter 3. Overview of IBM TXSeries

31

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.

32

WebSphere: Concepts and Facilities

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: Chapter 3. Overview of IBM TXSeries

33

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.

34

WebSphere: Concepts and Facilities

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.

Chapter 3. Overview of IBM TXSeries

35

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

36

WebSphere: Concepts and Facilities

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

Chapter 3. Overview of IBM TXSeries

37

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)

38

WebSphere: Concepts and Facilities

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.

Chapter 3. Overview of IBM TXSeries

39

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.

40

WebSphere: Concepts and Facilities

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

Chapter 3. Overview of IBM TXSeries

41

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.

42

WebSphere: Concepts and Facilities

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 Chapter 3. Overview of IBM TXSeries

43

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

44

WebSphere: Concepts and Facilities

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.

Chapter 3. Overview of IBM TXSeries

45

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.

46

WebSphere: Concepts and Facilities

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

Chapter 3. Overview of IBM TXSeries

47

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.

48

WebSphere: Concepts and Facilities

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 Chapter 3. Overview of IBM TXSeries

49

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.

50

WebSphere: Concepts and Facilities

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

© Copyright IBM Corp. 1999

51

52

WebSphere: Concepts and Facilities

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.

© Copyright IBM Corp. 1999

53

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

54

WebSphere: Concepts and Facilities

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

56

WebSphere: Concepts and Facilities

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.

Chapter 4. Transaction processing

57

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.

58

WebSphere: Concepts and Facilities

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.

Chapter 4. Transaction processing

59

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.

60

WebSphere: Concepts and Facilities

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

Chapter 4. Transaction processing

61

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.

62

WebSphere: Concepts and Facilities

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 Chapter 4. Transaction processing

63

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.

64

WebSphere: Concepts and Facilities

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 4. Transaction processing

65

66

WebSphere: Concepts and Facilities

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.

© Copyright IBM Corp. 1999

67

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

68

WebSphere: Concepts and Facilities

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:

70

WebSphere: Concepts and Facilities

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.

Chapter 5. Data management

71

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.

72

WebSphere: Concepts and Facilities

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. Chapter 5. Data management

73

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.

74

WebSphere: Concepts and Facilities

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 v v v

Intrapartition transient data destinations Extrapartition transient data destinations Indirect destinations Temporary storage queues

Application programs can write, read, and delete data in a transient data queues, but cannot update such data.

Chapter 5. Data management

75

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.

76

WebSphere: Concepts and Facilities

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.

Chapter 5. Data management

77

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.

78

WebSphere: Concepts and Facilities

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 Chapter 5. Data management

79

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

80

WebSphere: Concepts and Facilities

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).

Chapter 5. Data management

81

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.)

82

WebSphere: Concepts and Facilities

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.

Chapter 5. Data management

83

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:

84

WebSphere: Concepts and Facilities

– 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

Chapter 5. Data management

85

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

86

WebSphere: Concepts and Facilities

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 5. Data management

87

88

WebSphere: Concepts and Facilities

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.

© Copyright IBM Corp. 1999

89

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.

90

WebSphere: Concepts and Facilities

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

92

WebSphere: Concepts and Facilities

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

Chapter 6. Communications

93

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

94

WebSphere: Concepts and Facilities

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 Chapter 6. Communications

95

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.

96

WebSphere: Concepts and Facilities

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.

Chapter 6. Communications

97

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

98

WebSphere: Concepts and Facilities

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.

Chapter 6. Communications

99

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.

100

WebSphere: Concepts and Facilities

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 Chapter 6. Communications

101

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:

102

WebSphere: Concepts and Facilities

v v v v

Function Shipping Transaction Routing Distributed Program Link (DPL) 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.

Chapter 6. Communications

103

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

104

WebSphere: Concepts and Facilities

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.) Chapter 6. Communications

105

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

106

WebSphere: Concepts and Facilities

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.

Chapter 6. Communications

107

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

108

WebSphere: Concepts and Facilities

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.

Chapter 6. Communications

109

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

110

WebSphere: Concepts and Facilities

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.

Chapter 6. Communications

111

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

112

WebSphere: Concepts and Facilities

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. Chapter 6. Communications

113

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

114

WebSphere: Concepts and Facilities

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

Chapter 6. Communications

115

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

116

WebSphere: Concepts and Facilities

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.

© Copyright IBM Corp. 1999

117

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.

118

WebSphere: Concepts and Facilities

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.

120

WebSphere: Concepts and Facilities

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:

Chapter 7. Security

121

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.

122

WebSphere: Concepts and Facilities

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.

Chapter 7. Security

123

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.

124

WebSphere: Concepts and Facilities

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.

Chapter 7. Security

125

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.

126

WebSphere: Concepts and Facilities

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.

Chapter 7. Security

127

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.

128

WebSphere: Concepts and Facilities

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.

Chapter 7. Security

129

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

130

WebSphere: Concepts and Facilities

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 Chapter 7. Security

131

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

132

WebSphere: Concepts and Facilities

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.

Chapter 7. Security

133

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.

134

WebSphere: Concepts and Facilities

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 7. Security

135

136

WebSphere: Concepts and Facilities

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

© Copyright IBM Corp. 1999

137

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,

138

WebSphere: Concepts and Facilities

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.

140

WebSphere: Concepts and Facilities

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

Chapter 8. Application development

141

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:

142

WebSphere: Concepts and Facilities

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.

Chapter 8. Application development

143

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).

144

WebSphere: Concepts and Facilities

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.

Chapter 8. Application development

145

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 v v v v

Tran-C TX (the X/Open standard transactional interface) The Distributed Transaction Service (TRAN) Tran-C++ 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

146

WebSphere: Concepts and Facilities

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 Chapter 8. Application development

147

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.

148

WebSphere: Concepts and Facilities

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.

Chapter 8. Application development

149

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.

150

WebSphere: Concepts and Facilities

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

Chapter 8. Application development

151

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

152

WebSphere: Concepts and Facilities

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 8. Application development

153

154

WebSphere: Concepts and Facilities

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

© Copyright IBM Corp. 1999

155

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.

156

WebSphere: Concepts and Facilities

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

158

WebSphere: Concepts and Facilities

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,

Chapter 9. Systems management

159

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.

160

WebSphere: Concepts and Facilities

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.

Chapter 9. Systems management

161

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.

162

WebSphere: Concepts and Facilities

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

Chapter 9. Systems management

163

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

164

WebSphere: Concepts and Facilities

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 v v v v v

CICS regions Encina cell managers (ecm) Encina node managers (enm) Recoverable Queueing Service (RQS) servers Peer-to-Peer Communications (PPC) Gateway servers 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.

Chapter 9. Systems management

165

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

166

WebSphere: Concepts and Facilities

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.

Chapter 9. Systems management

167

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.

168

WebSphere: Concepts and Facilities

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.

Chapter 9. Systems management

169

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.

170

WebSphere: Concepts and Facilities

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 © Copyright IBM Corp. 1999

171

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.

172

WebSphere: Concepts and Facilities

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:

174

WebSphere: Concepts and Facilities

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.

Chapter 10. Component planning

175

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.

176

WebSphere: Concepts and Facilities

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.

Chapter 10. Component planning

177

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.

178

WebSphere: Concepts and Facilities

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.

Chapter 10. Component planning

179

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.

180

WebSphere: Concepts and Facilities

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.

Chapter 10. Component planning

181

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.

182

WebSphere: Concepts and Facilities

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 shown in Figure 61 on page 184.

© Copyright IBM Corp. 1999

183

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 RPC-only setup or in a DCE cell) v A CICS region that uses a DB2 database for file management (in an RPC-only setup or in a DCE cell) 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.

184

WebSphere: Concepts and Facilities

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.

186

WebSphere: Concepts and Facilities

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 .

Chapter 11. Configuration planning

187

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.

188

WebSphere: Concepts and Facilities

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.

Chapter 11. Configuration planning

189

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 shown in Figure 66 on page 191.

190

WebSphere: Concepts and Facilities

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.

Chapter 11. Configuration planning

191

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

192

WebSphere: Concepts and Facilities

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

Chapter 11. Configuration planning

193

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).

194

WebSphere: Concepts and Facilities

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.

Chapter 11. Configuration planning

195

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.

196

WebSphere: Concepts and Facilities

Part 3. Appendixes

© Copyright IBM Corp. 1999

197

198

WebSphere: Concepts and Facilities

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 © Copyright IBM Corp. 1999

199

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

200

WebSphere: Concepts and Facilities

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 AIX AS/400 CICS CICS OS/2 CICS/400 CICS/6000 CICS/ESA CICS/MVS CICS/VSE CICSPlex DB2 DCE Encina Lightweight Client DFS Encina IBM

IMS MQSeries MVS/ESA OS/2 OS/390 OS/400 PowerPC RISC System/6000 RS/6000 S/390 Transarc TXSeries VSE/ESA VTAM VisualAge 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 Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright

202

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

WebSphere: Concepts and Facilities

Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright Copyright

1995, 1996 Servio, Corp. 1996 Siemens Nixdorf Informationssysteme AG 1991, 1992, 1995, 1996 by Sun Microsystems, Inc. 1995, 1996 SunSoft, Inc. 1996 Sybase, Inc. 1996 Taligent, Inc. 1995, 1996 Tandem Computers, Inc. 1995, 1996 Teknekron Software Systems, Inc. 1995, 1996 Tivoli Systems, Inc. 1995, 1996 Transarc Corporation 1995, 1996 Versant Object Technology Corporation 1997 Visigenic Software, Inc. 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

204

WebSphere: Concepts and Facilities

Index Numerics 3270 terminal emulation

92

A ACID properties 10 atomicity 10 consistency 10 durability 10 isolation 10 ACLs for SFS files 125 adding files to SFS 72 Advanced Application Server 3 advanced program-to-program communications (APPC) DTP applications 113 advertisement protocol (CDS) 100 already verified 134 alternate indexes of files 72 API Toolkit Executive 32 Toolkit Server Core 32 application development 137 associating a program with a transaction 152 business logic 138 CICS application development environment 151 CICS application program debugging 152 CICS application program translation 152 CICS presentation interface development 151 CICS region application programming 143 CICS servers 139 data services 138 designing TP applications 137 detail 137 Encina application programming 144 external call interface (ECI) 140, 142 external presentation interface (EPI) 141, 142 IBM CICS Clients 139 Internet applications for CICS 142 © Copyright IBM Corp. 1999

application development 137 (continued) overview 49 presentation services 137 relational databases 151 tools 153 tools for program development 151 application development tools CICS application development environment 151 CICS application program debugging 152 CICS application program translation 152 CICS presentation interface development 151 other tools 153 application program calling 152 transactions 152 Application Server Manager 57 application servers 11 architecture CICS Transaction Gateway 27 client systems 25 communications servers 25 databases 30 DE-Light Gateway 27 Distributed Computing Environment (DCE) 33 recoverable queueing service (RQS) 30 relational databases 30 resource managers 29 structured file server (SFS) 29 Toolkit Executive 32 Toolkit Server Core 32 transaction base services 31 transaction processing monitor 24 TXSeries 23 ASCII to EBCDIC data conversion 115 associating a program with a transaction 152 asynchronous processing (CICS) 113 atomicity 10

attach security (SNA) 134 authenticated RPC 123 authenticating IBM CICS Clients 93 authentication using a CICS userid and password 126 using a DCE principal and password 120 authentication (DCE) in RPC 123 authorization by CICS 128 of user access to resources 128 automatic transaction initiation (ATI) 77

B backout 114 base services 32 Basic Mapping Support (BMS) application development tool 152 physical map 152 symbolic map 152 bind-time security description of 114 binding COM 149 binding information 98

C C BMS source files 152 translation of source 152 CDS, using to locate a server 99 CDS administration 168 CDS clerk 36, 100 CDS Server 33 CECI, CICS transaction 160 CEDF application development tool 152 CEDF, CICS transaction 160 Cell Directory Services (CDS) Server 33 CEMT, CICS transaction 160 checkout, program 152 CICS application development environment 151

205

CICS (continued) application program debugging 152 application program translation 152 application programming 139 client/server relationships 186 configuration planning 183 ECI and EPI programs 142 example configurations 191 network design 193 presentation interface development 151 transaction processing environment 40 CICS 3270 terminal emulation (client) 92 CICS 3270 terminal emulation (region) 98 cics_admin group 124 CICS clients 91 communication interfaces 92, 93 3270 terminal emulation 92 external call interface (ECI) 92 external presentation interface (EPI) 92 printer emulation 93 connecting and authenticating 93 DCE-enabled clients 97 Internet access 95 protocols 94 Telnet clients 98 CICS Control Program, cicscp 159 CICS DB2 Diagnostic Tool, cicsddt 160 CICS family TCP/IP 102 security considerations 132 CICS for OS/2 to CICS on Open Systems data conversion 115 CICS listeners 112 CICS local terminal 98 CICS on Open Systems to CICS for OS/2 data conversion 115 CICS permanent database 54 CICS permanent resource definitions 54 CICS queues 74 extrapartition destinations 77 indirect destinations 78 intrapartition destinations 76 temporary storage queues 78 transient data queues 75 cics_regions group 124

206

cics_regions group 124 (continued) SFS as member 125 CICS security services 126 authenticating users 126 authorizing access to resources 128 resource security 128 transaction security 128 using an External Security Manager 127 XA-enabled databases 132 cics_sfs group 124 CICS SFS Import Tool, cicssfsimport 160 CICS Transaction Gateway 27 CICS transactions 160 cics_users group 124 cicscheckup 160 cicscp, the CICS Control Program 159 cicsddt, the CICS DB2 Diagnostic Tool 160 cicsterm 92 clerk, defined 36 client/server computing COM 148 client/server model 16 client systems 25 Internet security services 130 security considerations 130 Web security services 130 clustered (KSDS) 72 COBOL BMS source files 152 External File Handler, restrictions 176 translation of source 152 COM 148 binding 149 commit 114 commit protocol 17 Common Object Request Broker (CORBA) 144 communications 89 ASCII to EBCDIC data conversion 115 authenticating a remote system (security) 132 authenticating a remote user (security) 133 authorizing access to resources 135 CICS client interfaces 92 CICS communication functions 111, 112

WebSphere: Concepts and Facilities

communications 89 (continued) CICS DCE-enabled clients 97 CICS family TCP/IP 102 CICS local terminal 98 client interfaces 92 client-server 91 connecting and authenticating IBM CICS Clients 93 data conversion 115 data integrity (synchronization) 114 DCE cells, locating systems outside 101 DCE RPCs 98 detail 89 EBCDIC to ASCII data conversion 115 example 90 indoubt resolution (CICS) 115 Internet access to CICS 95 link security (CICS communications) 135 listeners (CICS) 112 local SNA support (CICS) 106 mixing SNA and TCP/IP 109 overview 46 PPC Gateway server 107 PPC TCP/IP 104 protocols 101 protocols (IBM CICS Clients) 94 security 114 SNA 105 SNA flowed userids (security) 134 synchronization for data integrity 114 synchronization levels 102 synchronization levels (CICS use of) 114 TCP/IP 102 Telnet clients 98 two-phase commit process 115 user security (CICS communications) 135 with CICS Clients 93 with users 91 communications gateways comtidl compiler

25

148

configuring a CICS environment 156 confirm

114

connecting and authenticating IBM CICS Clients 93 consistency

10

conversation-level security (SNA) 134 conversion of data between systems 115

D data consistency, preserving 87 data conversion 115 ASCII to EBCDIC 115 between systems 115 CICS for OS/2 to CICS on Open Systems 115 CICS on Open Systems to CICS for OS/2 115 EBCDIC to ASCII 115 data management 67 considerations for sharing data 86 databases 82 DB2 82 DB2 for CICS files and queues 84 detail 67 files 69 introduction 67 journals 85 overview 45 queues 73 relational databases 82 SQL servers 82 types of data 68 Database Managed Space (DMS) Table Space 85 database manager, relational 180 databases 30, 82 DB2 82 Database Managed Space (DMS) Table Space 85 field name restrictions 179 System Managed (SMS) Table Space 85 DB2 for CICS files and queues 84 DB2 Universal Database 5 DCE authenticating access from outside a DCE cell 123 authentication with the CICS default userid 122 CDS clerk 36 CDS Server 33 cell 33 Cell Directory Services (CDS) Server 33 client systems 36 Distributed Time Service (DTS) Server 34

DCE (continued) DTS clerk 36 general DCE security process 120 region principal 125 replica CDS servers 35 replica Security Servers 35 RPC daemon 36 security 119 security clerk 36 security groups 124 security service 33 SFS security 125 what makes up a DCE cell? 33 DCE CDS, using to locate a server 99 DCE cell 33 DCE Cell Directory Service (CDS) 98 name lookup 100 DCE clients 36 DCE Distributed Time Service (DTS) Server 34 DCE-enabled CICS clients 97 DCE security authentication 120 DCE security service CDS Server 33 cell 33 DCE clients 36 DTS clerk 36 general DCE security process 120 security clerk 36 Security Server 33 DCE Security Service 119 authenticated RPC 123 authenticating access from outside a DCE cell 123 DE-Light Gateway 27 debugging CEDF 152 debugging CICS application programs 152 Distributed Computing Environment (DCE) configurations 172 distributed program link (DPL) 113 Distributed Time Service (DTS) Server 34 distributed transaction processing 14 distributed transaction processing (DTP) 113 distributed transaction service 32

distributed unit of work 114 DTS administration 168 DTS clerk 36 dumps in a CICS environment 158 durability 10 dynamic link libraries 54 dynamic transaction backout 65

E EBCDIC to ASCII data conversion 115 ECI (external call interface) developing 142 emergency restart 60 Encina configuration planning 184 Encina++/CORBA 149 Encina++/CORBA-DCE 149 Encina++/DCE 149 Encina Monitor application programming 144 systems management 161 transaction processing environment 42 Encina queues 80 dequeueing from queue sets 81 Enconsole, tool for managing Encina 162 access to Encina settings 162 monitoring transactions 163 starting Encina servers 163 stopping Encina servers 163 Enterprise Application Server 3 entry-sequenced file (ESDS) 71 EPI (external presentation interface) developing 142 ESM (External Security Manager) overview 127 event log 55 Execution Diagnostic Facility (CEDF) application development tool 152 external call interface (ECI) 140 developing 142 External File Handler, restrictions 176 external presentation interface (EPI) 141 developing 142 External Security Manager using ACLs 130 External Security Manager (ESM) overview 127 extrapartition destinations (queues) 77 Index

207

F facilities provided by TXSeries 23 application development, overview 49 communications, overview 46 data management, overview 45 security, overview 48 systems management, overview 49 transaction processing, overview 44 field name restrictions DB2 179 file management 174 file organization 70 clustered (KSDS) 72 entry-sequenced (ESDS) 71 relative (RRDS) 72 files 69 adding to SFS 72 alternate indexes 72 indexes 72 organization 70 primary indexes 72 function shipping (CICS) 112

G gateways DE-Light 27 Internet 27 Java 27 Gateways Internet 95 Java 95

I IBM CICS Clients developing ECI and EPI programs 142 external call interface (ECI) 140 external presentation interface (EPI) 141 Internet applications for CICS 142 programming 139 IBM HTTP Server 28 IBM Tivoli management servers 7 IBM TXSeries Administration Tool 158 IDL (DCE) compiler 148 indexes of files 72 indirect destinations (queues) 78 indoubt condition 115

208

intercommunication network choosing 181 intercommunication security authenticating a remote system 132 internal data consistency, preserving 87 Internet developing applications for CICS 142 Internet access to CICS 95 developing applications 142 Internet gateway 27 Internet Inter-ORB Protocol (IIOP) 144 Internet security services 130 Interval Control Manager 57 intrapartition destinations (queues) 76 isolation 10

J Java gateway 27 Java OTS client 150 journal records 85 journals 85 CICS records 85 synchronizing output

85

K key-sequenced data set (KSDS) 72 keytab file contains region principal 125

L life cycle of a region 59 life cycle of a transaction, basic overview 12 link security description of 114 listeners 57 listeners (CICS) 112 local 3270 terminal (CICS) 98 local SNA security considerations 133 local SNA listener 112 local SNA support 102 local SNA support (CICS) 106 synchronization levels 107 lock service 32 log service 32 logical unit of work (LUW) 114 LU 6.2 181 LUTYPE6.2 101, 105

WebSphere: Concepts and Facilities

M managing a CICS environment managing an Encina environment 161 MIDL compiler 148 Monitor 149 Monitor Cell Manager 184 Monitor Node Manager 184 monitoring a CICS environment 157 MQSeries 6, 28

155

N name lookup (CDS) 100 name service options 98 named pipe listener 112

O Object Management Group (OMG) 144 Object Request Broker (ORB) 144 OCCS 150 online transaction processing ACID properties 10 atomicity 10 consistency 10 durability 10 isolation 10 transactions 9 what is a region? 53 Application Server Manager 57 CICS permanent resource definitions 54 dynamic link libraries 54 emergency restart 60 event log 55 Interval Control Manager 57 life cycle of a region 59 listeners 57 log manager 57 operating system memory 58 recovery during restart 60 Recovery Manager 57 runtime resource definitions 56 system log 58 when a region is stopped 54 when the region is running 55 Windows NT services 55, 56 operating system memory 58 process data segment 58 processor text segment 58 shared text segment 58

operating system memory 58 (continued) system shared segment 58 task shared segment 58

P password verification (SNA) 134 performance CICS network design 193 permanent database, CICS 54 persistent verification 134 platforms WebSphere Application Server 4 PPC Gateway server 107 security considerations 133 PPC TCP/IP 104 security considerations 133 primary indexes of files 72 principal region 125 printer emulation 93 priority 62 priority of tasks 62 process data segment 58 processor text segment 58 program testing 152 programming associating a program with a transaction 152 business logic 138 CICS application development environment 151 CICS application program debugging 152 CICS application program translation 152 CICS presentation interface development 151 CICS region application programming 143 CICS servers 139 data services 138 designing TP applications 137 Encina application programming 144 external call interface (ECI) 140, 142 external presentation interface (EPI) 141, 142 IBM CICS Clients 139 Internet applications for CICS 142 presentation services 137 relational databases 151 tools 153

programming (continued) tools for program development 151 protocols (communications) 101 CICS family TCP/IP 102 PPC TCP/IP 104 SNA 105 TCP/IP 102

Q queue and file control SFS 174 queue and file management choosing 174 Queue sets 80 queues 73 CICS queues 74 dequeueing from queue sets 81 Encina queues 80 extrapartition destinations 77 indirect destinations 78 intrapartition destinations 76 temporary storage queues 78 transient data queues 75

R RDO commands 160 recoverable processes 17 recovery user journals 65 recovery and restart startup 65 recovery during restart 60 Recovery Manager 57 recovery service 32 region principal 125 relational database managers choosing 180 relational databases 30, 82 DB2 for CICS files and queues 84 programming 151 SQL restrictions for non-XA-enabled databases 84 relative record file (RRDS) 72 Remote Procedure Call (RPC) 172 Remote Procedure Calls (RPCs) authenticated RPC 123 resource managers 29 databases 30 recoverable queueing service (RQS) 30 relational databases 30 structured file server (SFS) 29 resource security 128

restrictions COBOL External File Handler 176 External File Handler 176 field names (DB2) 179 SFS for queue and file control 174 rollback 114 RPC (Remote Procedure Call) 172 RPC daemon 36 RPC listener 112 RPCs 149 RQS++ 150 runtime resource definitions 56

S sample application overview 18 sample transaction processing environment 18 sample application 18 sample system environment 19 transaction processing flow 20 scheduling 62 scheduling of tasks 62 Secured Hypertext Transport Protocol (S-HTTP) 131 Secured Sockets Layer (SSL) 131 security 117 ACLs for CICS 125 ACLs for SFS files 125 ACLs with an ESM 130 authenticating a remote system 132 authenticating a remote user 133 authenticating access from outside a DCE cell 123 authentication for transaction services using a CICS userid and password 126 using a DCE principal and password 120 authorizing access to resources 128, 135 by CICS 128 CICS 126 CICS security services 126 client systems 130 communications security 132 DCE 119, 172 DCE Security Server 33 detail 117 External Security Manager (CICS) 127 Index

209

security 117 (continued) intercommunication 114 Internet security services 130 link security (CICS communications) 135 overview 48 security models 117 SNA flowed userids 134 Telnet clients 131 user security (CICS communications) 135 Web security services 130 XA-enabled databases and CICS 132 security administration (DCE) 168 security clerk 36 SFS queue and file control 174 SFS++ 150 SFS (structured file server) 29 sfsimport, the CICS SFS Import Tool 160 shared text segment 58 sharing and distributing data 86 SNA BIND request 114 conversation-level security 134 password verification 134 synchronization level 114 use of 101 SNA (System Network Architecture) 181 solicitation protocol (CDS) 100 source code translation 152 SQL restrictions for non-XA-enabled databases 84 SQL servers 82 Standard Application Server 3 starting servers in a CICS environment 157 startup recovery and restart 65 statistics in a CICS environment 158 stopping servers in a CICS environment 157 strict prioritization of queue sets 81 structured file server (SFS) 29 sync point 114 synchronization level 114 synchronization levels 102 CICS family TCP/IP support for 104 CICS use of 114 indoubt resolution (CICS) 115

210

synchronization levels 102 (continued) local SNA (CICS) 107 PPC Gateway server 109 PPC TCP/IP support for 105 two-phase commit 115 synchronization point 11 synchronizing journal output 85 system log 58 System Managed (SMS) Table Space 85 System Network Architecture (SNA) 181 system shared segment 58 systems management 155

WebSphere: Concepts and Facilities

CDS administration 168 commands for CICS 159 commands for CICS, cicscheckup 160 commands for CICS, cicscp 159 commands for CICS, cicsddt 160 commands for CICS, cicssfsimport 160 commands for CICS, RDO 160 configuring a CICS environment 156 DCE tools 169 DCEsetup 169 DTS administration 168 dumps in a CICS environment 158 Encina command-line interfaces 163 Enconsole 162 IBM TXSeries Administration Tool for CICS 158 managing a CICS environment 155 managing an Encina environment 161 managing DCE 168 messages in a CICS environment 157 monitoring a CICS environment 157 overview 49 security administration 168 starting servers in a CICS environment 157 statistics in a CICS environment 158 stopping servers in a CICS environment 157 systems management 155

systems management 155 (continued) tools for a CICS environment 158 trace in a CICS environment 158 transactions for CICS 160 transactions for CICS, CECI 160 transactions for CICS, CEDF 160 transactions for CICS, CEMT 160 Systems Network Architecture (SNA) communicating across 105 local SNA support (CICS) 106 PPC Gateway server 107 synchronization levels 102

T table space Database Managed Space (DMS) 85 System Managed (SMS) 85 task shared segment 58 tasks 62 TCP/IP 102 CICS family TCP/IP 102 use of 101 TCP/IP listener 112 Telnet clients (CICS) 98 security considerations 131 temporary storage queues 78 Thread-to-Tid Mapping Service 32 ThreadTid 32 Tivoli management servers 7 TM/XA interface 33 Toolkit Executive 31 Toolkit Server Core 31 tools for program development 151 CICS application development environment 151 CICS application program debugging 152 CICS application program translation 152 CICS presentation interface development 151 other tools 153 tools for systems management CICS commands 159 CICS commands, cicscheckup 160 CICS commands, cicscp 159 CICS commands, cicsddt 160 CICS commands, cicssfsmimport 160

tools for systems management (continued) CICS commands, RDO 160 CICS environment 158 CICS transactions 160 CICS transactions, CECI 160 CICS transactions, CEDF 160 CICS transactions, CEMT 160 DCE tools 169 DCEsetup 169 Enconsole 162 IBM TXSeries Administration Tool for CICS 158 trace in a CICS environment 158 TRAN 32 transaction base services 31 transaction classes 62 transaction identifier (CEDF) 152 transaction life cycle, basic overview 12 transaction processing 9, 53 ACID properties 10 atomicity 10 consistency 10 durability 10 isolation 10 detail 53 overview 44 transactions 9 what is a region? 53 Application Server Manager 57 CICS permanent resource definitions 54 dynamic link libraries 54 emergency restart 60 event log 55 Interval Control Manager 57 life cycle of a region 59 listeners 57 log manager 57 operating system memory 58 recovery during restart 60 Recovery Manager 57 runtime resource definitions 56 system log 58 when a region is stopped 54 when the region is running 55 Windows NT services 55, 56 transaction processing environments CICS 40 Encina Monitor 42 transaction processing monitor 24

transaction routing (CICS) 113 transaction security 128 transactional RPC 32 transactions 9 CEDF 152 transient data queues 75 translating CICS application programs 152 TRPC 32 two-phase commit 17, 115 TXSeries example configurations 37 TXSeries architecture 23 client systems 25 communications gateways 25 databases 30 DE-Light Gateway 27 Distributed Computing Environment (DCE) 33 Internet gateway 27 Java gateway 27 recoverable queueing service (RQS) 30 relational databases 30 resource managers 29 structured file server (SFS) 29 Toolkit Executive 32 Toolkit Server Core 32 transaction base services 31 transaction processing monitor 24

U user journals, as used in recovery 65 user security description of 114 using an External Security Manager overview 127

WebSphere Application Server 3 (continued) supported platforms 4 weighted prioritization of queue sets 81 what is a region? 53 Application Server Manager 57 CICS permanent resource definitions 54 dynamic link libraries 54 emergency restart 60 event log 55 Interval Control Manager 57 life cycle of a region 59 listeners 57 log manager 57 operating system memory 58 process data segment 58 recovery during restart 60 Recovery Manager 57 runtime resource definitions 56 shared text segment 58 system log 58 system shared segment 58 task shared segment 58 when a region is stopped 54 when the region is running 55 Windows NT services 55, 56 Windows NT services 55, 56 World-Wide Web (WWW) access to CICS developing applications 142

X X/Open XA

32

V verifying passwords (SNA) 134 Virtual Storage Access Method (VSAM) entry-sequenced (ESDS) 71 key-sequenced data set (KSDS) 72 relative record data set (RRDS) 72 VisualAge C++ 6 VisualAge for Java 6 volume service 32

W Web security services 130 WebSphere Application Server

3 Index

211

212

WebSphere: Concepts and Facilities

© Copyright IBM Corp. 1999

213

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