WOW! DRDA Supports TCP/IP: DB2 Server for OS/390 and DB2

SG24-2212-00

WOW! DRDA Supports TCP/IP:DB2 Server for OS/390 and DB2 Universal Database

July 1997

SG24-2212-00

International Technical Support Organization

WOW! DRDA Supports TCP/IP:DB2 Server for OS/390 and DB2 Universal Database

July 1997

IBML

Take Note!

Before using this information and the product it supports, be sure to read the general informationin Appendix E, “Special Notices” on page 199.

First Edition (July 1997)

This edition applies to Version 5 of IBM DATABASE 2 Server for OS/390 (DB2 for OS/390), ProgramNumber 5665-DB2, and Version 5 of IBM DATABASE 2 Universal Database.

Warning

This book is based on a pre-GA version of a product and may not apply when the productbecomes generally available. It is recommended that, when the product becomes generallyavailable, you destroy all copies of this version of the book that you have in your possession.

Comments may be addressed to:IBM Corporation, International Technical Support OrganizationDept. QXXE Building 80-E2650 Harry RoadSan Jose, California 95120-6099

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute theinformation in any way it believes appropriate without incurring any obligation to you.

Copyright International Business Machines Corporation 1997. All rights reserved.Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication ordisclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii i

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvThe Team That Wrote This Redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvComments Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Chapter 1. Product Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 DB2 Universal Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 DB2 Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 Net.Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.3 DB2 UDB Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.4 DB2 UDB Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 DB2 for OS/390 Version 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.1 Native TCP/IP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.2 Positioning TCP/IP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.3 Reasons for TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.4 Reasons for APPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.5 World Wide Web and ODBC-CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.6 Support for High-Volume Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . 111.2.7 Better Performance for DRDA Applications . . . . . . . . . . . . . . . . . . . . . . 111.2.8 Enhanced Stored Procedures Environment . . . . . . . . . . . . . . . . . . . . . . 111.2.9 Improved Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.10 DB2 Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.11 Additional Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.3 Software Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.1 DB2 for OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.2 DB2 Universal Database Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 14

Chapter 2. The Project Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1 Workstations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 Mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 3. TCP/IP Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1 Architectural Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Internetworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.1 Host Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.1 Network Adapters and Host Names . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Copyright IBM Corp. 1997 iii

3.3.2 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.3 Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 4. TCP/IP for MVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1 System Address Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.1 TCPIP.DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2.2 tcpip.ETC.SERVICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.3 tcpip.HOSTS.LOCAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.4 PROFILE.TCPIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Chapter 5. DB2 for OS/390 and TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1 DB2 for OS/390 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.1 Defining TCP/IP to DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1.2 Migration and Update Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 395.1.3 BSDS Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 DDF Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.1 DDF and OpenEdition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.3 Defining DB2 to TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3.1 Registering DB2 Port Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3.2 Defining TCP/IP Host Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3.3 Defining TCP/IP Service Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.3.4 Additional Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Chapter 6. DB2 for OS/390 As an AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2 Virtual IP Address Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.3 Client Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Chapter 7. DB2 for OS/390 As an AR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.1 CDB Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.1.1 SYSIBM.LOCATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.1.2 SYSIBM.IPNAMES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.1.3 SYSIBM.LUNAMES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.1.4 SYSIBM.USERNAMES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.2 DB2 for OS/390 Bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.2.1 Binding to the DB2 UDB AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.2.2 Binding to DB2 for OS/390 Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.3 BIND Options Available in DB2 UDB Servers . . . . . . . . . . . . . . . . . . . . . . . 657.3.1 Bind Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.3.2 DB2 for OS/390 Connection Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.3.3 Improving Performance for Distributed Applications . . . . . . . . . . . . . . . . 70

Chapter 8. DB2 UDB Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

iv DB2 for OS/390 and DB2 UDB DRDA TCP/IP Support

8.1 Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718.1.1 Standards for Port Numbers and Service Names . . . . . . . . . . . . . . . . . . 718.1.2 Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738.1.3 Windows 95 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798.1.4 AIX Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818.1.5 OS/2 Warp Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8.2 UDB Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858.2.1 Database Manager Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . 868.2.2 DB2COMM Environment Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . 868.2.3 Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapter 9. Universal Database As an Application Requester . . . . . . . . . . . . . . . . 899.1 Configuring the Hosts File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899.2 Configuring the Services File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909.3 Catalog Process in the UDB Directories . . . . . . . . . . . . . . . . . . . . . . . . . . 91

9.3.1 Cataloging the Database for OS/2, Windows NT, and Windows 95 . . . . . . . . 919.3.2 Cataloging the TCP/IP Node for UDB, Using CLP . . . . . . . . . . . . . . . . . . 1009.3.3 Cataloging a Database in the System Database Directory, Using CLP . . . . . 1019.3.4 Cataloging the DCS Database for UDB . . . . . . . . . . . . . . . . . . . . . . . . 1029.3.5 Testing the TCP/IP Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

9.4 Binding Packages to DB2 for OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Chapter 10. Data Sharing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10710.1 DB2 for OS/390 Data Sharing As an Application Requester . . . . . . . . . . . . . . 10710.2 DB2 for OS/390 Data Sharing As an Application Server . . . . . . . . . . . . . . . . 10710.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10810.4 Each Member on a Different MVS: Common Host Name . . . . . . . . . . . . . . . . 108

10.4.1 How Connection Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10810.4.2 One DB2 Member Quiesced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

10.5 Each Member on a Different MVS: DNS Not Configured . . . . . . . . . . . . . . . . 10810.5.1 How Connection Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10910.5.2 One DB2 Member Quiesced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

10.6 Resynchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11010.7 Workload Balancing for the Data Sharing AS . . . . . . . . . . . . . . . . . . . . . . 111

10.7.1 DB2 for OS/390 Data Sharing Limits . . . . . . . . . . . . . . . . . . . . . . . . . 11210.7.2 MAXDBAT Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Chapter 11. Mixed Mode Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11511.1 DB2 for OS/390 As a Requester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

11.1.1 Customizing the CDB for Mixed Mode Connections . . . . . . . . . . . . . . . . 11511.1.2 Enabling Mixed Mode for DB2 UDB Servers . . . . . . . . . . . . . . . . . . . . 116

11.2 DB2 UDB As a Requester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11811.3 Data Sharing Considerations for Mixed Mode . . . . . . . . . . . . . . . . . . . . . . 119

Contents v

Chapter 12. Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12112.1 Security Changes for Distributed Processing . . . . . . . . . . . . . . . . . . . . . . . 12112.2 DRDA Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12112.3 DB2 for OS/390 AS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12212.4 DB2 for OS/390 AR Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

12.4.1 CDB Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12412.4.2 Outbound Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12712.4.3 RACF PassTickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12812.4.4 DCE Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13012.4.5 Changing Remote Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

12.5 DB2 UDB AS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13012.5.1 DB2 UDB Server Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13112.5.2 Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13112.5.3 PassTickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

12.6 DB2 UDB AR Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13212.6.1 DB2 Connect Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13212.6.2 Sending PassTickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13312.6.3 Accessing Servers through a Firewall . . . . . . . . . . . . . . . . . . . . . . . . 13412.6.4 Changing the Password at the Remote Server . . . . . . . . . . . . . . . . . . . 135

Chapter 13. Distributed Unit of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13713.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

13.1.1 Multisite Reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13713.1.2 Multisite Reads and Single-Site Update . . . . . . . . . . . . . . . . . . . . . . . 13813.1.3 Multisite Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

13.2 Two-phase Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14013.3 DB2 UDB As an Application Requester . . . . . . . . . . . . . . . . . . . . . . . . . . 142

13.3.1 Using DUW with SYNCPOINT NONE . . . . . . . . . . . . . . . . . . . . . . . . . 14213.3.2 Using DB2 for OS/390 As a Transaction Manager . . . . . . . . . . . . . . . . . 143

13.4 DB2 UDB As an Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14413.5 DB2 for OS/390 As an Application Requester . . . . . . . . . . . . . . . . . . . . . . 14513.6 DB2 for OS/390 As an Application Server . . . . . . . . . . . . . . . . . . . . . . . . . 14513.7 DataJoiner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

13.7.1 Supported Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14613.7.2 The Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14813.7.3 Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14913.7.4 Application Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14913.7.5 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15013.7.6 Resynchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Appendix A. Monitoring Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151A.1 DB2 for OS/390 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151A.2 DB2 for OS/390 Command Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152A.3 DB2 UDB Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

vi DB2 for OS/390 and DB2 UDB DRDA TCP/IP Support

Appendix B. Problem Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163B.1 UDB Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

B.1.1 DB2DIAG.LOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163B.1.2 DB2 Trace Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164B.1.3 DRDA Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165B.1.4 Possible Causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167B.1.5 DB2 Connect Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167B.1.6 Bind Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

B.2 System-Based Troubleshooting Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 170B.2.1 UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170B.2.2 OS/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171B.2.3 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

B.3 TCP/IP Commands - Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172B.3.1 Network Management Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 173B.3.2 Simple Network Management Protocol Support . . . . . . . . . . . . . . . . . . . 176B.3.3 NETSTAT Command - Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Appendix C. TCP/IP Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181C.1 TCP/IP Architecture - Layered Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 181

C.1.1 Bridges, Routers, and Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183C.1.2 IP Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

C.2 Main Protocol Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187C.2.1 Address Resolution Protocol (ARP) . . . . . . . . . . . . . . . . . . . . . . . . . . 187C.2.2 Reverse Address Resolution Protocol (RARP) . . . . . . . . . . . . . . . . . . . . 188C.2.3 User Datagram Protocol (UDP) Basics . . . . . . . . . . . . . . . . . . . . . . . . 188C.2.4 Transmission Control Protocol (TCP) . . . . . . . . . . . . . . . . . . . . . . . . . 189C.2.5 Internet Control Message Protocol (ICMP) . . . . . . . . . . . . . . . . . . . . . . 191

Appendix D. TCP/IP for MVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193D.1 TCP/IP and OpenEdition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

D.1.1 OpenEdition Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193D.1.2 TCP/IP Version 3 for OpenEdition . . . . . . . . . . . . . . . . . . . . . . . . . . . 193D.1.3 TCP/IP Data Set Names with OpenEdition Services . . . . . . . . . . . . . . . . 194

D.2 Other Address Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194D.3 Multiple Copies of TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195D.4 TCP/IP for MVS Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Appendix E. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Appendix F. Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203F.1 International Technical Support Organization Publications . . . . . . . . . . . . . . . 203F.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203F.3 Other Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Contents vii

How to Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205How IBM Employees Can Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . 205How Customers Can Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206IBM Redbook Order Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

ITSO Redbook Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

viii DB2 for OS/390 and DB2 UDB DRDA TCP/IP Support

Figures

1. Sample Scenario with DB2 Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Sample Scenario with Net.Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. DB2 UDB Control Center Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. The Project Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Directions for Services and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Two Interconnected Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Assigned Classes of Internet Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Host Network Adapter Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Relationship among Network Adapter, IP Address, and TCP Host . . . . . . . . . . 2710. Demultiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2811. Structure of IBM TCP/IP Version 3 Release 2 for MVS . . . . . . . . . . . . . . . . . 3212. The DSNTIPR Installation Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3613. The DSNTIP5 Installation Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3814. The Change Log Inventory Step of DSNTIJUZ . . . . . . . . . . . . . . . . . . . . . . 4015. The DDF Address Space Startup Procedure . . . . . . . . . . . . . . . . . . . . . . . 4116. RACF Panel to Change the UID Parameter . . . . . . . . . . . . . . . . . . . . . . . . 4217. PORT Statement in TCP/IP PROFILE Data Set . . . . . . . . . . . . . . . . . . . . . . 4418. TCP/IP Network Message Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4819. Port Numbers for Two DB2 Subsystems on the Same MVS . . . . . . . . . . . . . . 5220. PROFILE.TCPIP Data Set Definition for Port Numbers . . . . . . . . . . . . . . . . . 5221. DDF Statement to Define PORT and RESPORT . . . . . . . . . . . . . . . . . . . . . 5322. DDF Communication Record in the BSDS . . . . . . . . . . . . . . . . . . . . . . . . 5323. DB2 Messages during DDF Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5324. Sample HOSTS File for an AR Workstation . . . . . . . . . . . . . . . . . . . . . . . . 5525. Sample HOSTS.LOCAL Data Set Statement for an AR MVS . . . . . . . . . . . . . . 5526. Sample Service Statement: MVS and Workstation Platforms . . . . . . . . . . . . . 5527. Relationship among SYSIBM.LOCATIONS, SYSIBM.IPNAMES, and

SYSIBM.LUNAMES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6128. Message from SPUFI Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6329. Sample JCL to Bind the Package for the SPUFI Application . . . . . . . . . . . . . 6430. BIND PACKAGE DSNEBP07 Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6831. Catalog Changes Resulting from New OPTIONS Keyword . . . . . . . . . . . . . . . 6932. Service Files for OS/2 Application Server . . . . . . . . . . . . . . . . . . . . . . . . 7233. Service Files for AIX Application Server . . . . . . . . . . . . . . . . . . . . . . . . . 7234. Service Files for Windows NT Application Server . . . . . . . . . . . . . . . . . . . . 7335. Identification Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7336. Adapter Configuration Initial Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7437. Adapter List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7538. TCP/IP Configuration Initial Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7639. TCP/IP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7740. Advanced IP Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Copyright IBM Corp. 1997 ix

41. Domain Name System Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7942. Windows 95 Network Configuration for TCP/IP . . . . . . . . . . . . . . . . . . . . . . 8043. SMIT Change / Show Characteristics of a Token Ring Adapter Screen . . . . . . . 8144. SMIT TCP/IP Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8245. SMIT Minimum Configuration and Startup Screen . . . . . . . . . . . . . . . . . . . 8346. SMIT Add a Service Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8447. TCP/IP Configuration in OS/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8548. Sample Hosts File Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8949. Sample Client Services File Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9050. Client Configuration Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9251. Add Database SmartGuide: Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9352. Add Database SmartGuide: Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9453. Add Database SmartGuide: Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9554. Add Database SmartGuide: Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9655. Add Database SmartGuide: Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9756. Add Database SmartGuide: Step 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9857. Window for Testing the Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9858. User ID and Password Confirmation Window . . . . . . . . . . . . . . . . . . . . . . 9959. Client Configuration Assistant: End of Configuration . . . . . . . . . . . . . . . . . . 10060. Output of the LIST NODE DIRECTORY Command . . . . . . . . . . . . . . . . . . . . 10161. Output of the LIST DATABASE DIRECTORY Command . . . . . . . . . . . . . . . . . 10262. Output of the LIST DCS DIRECTORY Command . . . . . . . . . . . . . . . . . . . . . 10363. Connection Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10964. MAX REMOTE CONNECTED Limit Reached . . . . . . . . . . . . . . . . . . . . . . . 11365. TCP/IP Requests: Server Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12366. TCP/IP Requests: Client Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12767. Multisite Reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13868. Multisite Reads and Single-site Update . . . . . . . . . . . . . . . . . . . . . . . . . . 13969. Multisite Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14070. Two-phase Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14171. DB2 for OS/390 As a Transaction Manager Database . . . . . . . . . . . . . . . . . 14472. DataJoiner Two-phase Commit Environment . . . . . . . . . . . . . . . . . . . . . . . 14873. DISPLAY THREAD Command Issued from the AR . . . . . . . . . . . . . . . . . . . . 15374. DISPLAY THREAD Command Issued from the AS . . . . . . . . . . . . . . . . . . . . 15475. DISPLAY LOCATION Command Issued from DB2 for OS/390 AR . . . . . . . . . . . 15476. DISPLAY LOCATION Command Issued from DB2 Data Sharing Member AS . . . . 15577. NETSTAT Command Issued on the MVS Platform . . . . . . . . . . . . . . . . . . . . 15678. PING Command Output from a TSO Session . . . . . . . . . . . . . . . . . . . . . . . 15679. GET CONNECTION STATE Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15880. LIST APPLICATIONS Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15981. GET AUTHORIZATIONS Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16082. LIST COMMAND OPTIONS Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16183. Displaying the SCA with CLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16284. Example of Trace Entries in an Output File . . . . . . . . . . . . . . . . . . . . . . . . 165

x DB2 for OS/390 and DB2 UDB DRDA TCP/IP Support

85. BIND JCL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16986. TCP/IP Utilities - Icon View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17587. Simple Network Management Protocol and CMOT . . . . . . . . . . . . . . . . . . . 17688. Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17689. DB2 Subagent Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17790. TSO NETSTAT Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17991. Architectural Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18192. Detailed Architectural Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18293. Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18394. Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18495. Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18596. Datagram Packed in a Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18597. IP Routing Mechanism Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18698. Address Resolution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18799. Reverse Address Resolution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 188100. User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189101. Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190102. TCP Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191103. Internet Control Message Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192104. Example of Network connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Figures xi

xii DB2 for OS/390 and DB2 UDB DRDA TCP/IP Support

Tables

1. Workstation Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2. Mainframe Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Differences between SYSIBM.SYSLOCATIONS and SYSIBM.LOCATIONS Columns 58 4. Differences between SYSIBM.SYSLUNAMES and SYSIBM.LUNAMES Columns . . 58 5. Differences between SYSIBM.SYSLUMODES and SYSIBM.LUMODES Columns . . 58 6. SYSIBM.LOCATIONS Definitions: Port Number and Service Name . . . . . . . . . . 60 7. SYSIBM.IPNAMES Definitions Using IP Address and Host Name . . . . . . . . . . . 61 8. SYSIBM.USERNAMES Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 9. DRDA BIND PACKAGE Options to DB2 for OS/390 . . . . . . . . . . . . . . . . . . . 6510. Bind List Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10411. DataJoiner Version 2 Data Sources and Two-Phase Commit Support . . . . . . . . 147

Copyright IBM Corp. 1997 xiii

xiv DB2 for OS/390 and DB2 UDB DRDA TCP/IP Support

Preface

This redbook positions the new support available in DB2 for OS/390 Server Version 5 andUniversal Database Version 5 related to Distributed Relational Database Architecture(DRDA) connections using the TCP/IP protocol. This redbook will help you install, tailor,and configure application requesters (ARs) and application servers (ASs) to interchangerelational data based on DRDA and using TCP/IP. We also cover enhancements introducedin DB2 for OS/390 related to DRDA using the Application Program-to-Program (APPC)protocol.

We present basic concepts of TCP/IP that will help DB2 for OS/390 systems programmersand database administrators implement DRDA using TCP/IP. Installation and customizationtasks are also described.

We describe how TCP/IP works in a DB2 data sharing environment, and how to configurethe installation with several security options.

This redbook is essential for a successful implementation of DRDA using TCP/IP.

The Team That Wrote This Redbook

This redbook was produced by a team of specialists from around the world working at theInternational Technical Support Organization, San Jose Center.

Ricardo Darriba Macedo is a Senior DB2 Product Specialist, working at the IBM SoftwareBusiness Unit, in Rio de Janeiro, Brazil. He joined IBM in 1987 and since then has beenresponsible for supporting customers in the database and application development areas.Ricardo has implemented DB2 for many large customers in Brazil. He is also the co-authorof the redbooks, Getting Started with Stored Procedures and DRDA Security Considerations.

Silvia Savino is a Technical Service Support member of the S/390 SW Support departmentin Rome, Italy. She has about 10 years of experience in VSE and VM and, more recently,MVS Service Center and customer field support. Her areas of expertise include SQL/DS forVSE and VM and DB2 for MVS.

Jose Eduardo Pol is a Systems and Product Specialist at IBM Brazil. He has worked forfour years in the IBM Support Center as a DB2 specialist, helping customers solveproblems in the DB2 area, including DRDA connection and others products in MVSplataform.

Silvio Podcameni is a Data Management Specialist for DB2 and DRDA, on assignment atthe ITSO - San Jose Center since August 1994. During his assignment he led projects toproduce redbooks on DRDA and DB2 for MVS/ESA on such topics as security, storedprocedures, connectivity, and data sharing. Silvio has also conducted workshops worldwide

Copyright IBM Corp. 1997 xv

on DB2 for MVS/ESA data sharing recovery, client/server features of DB2 for OS/390 ServerVersion 5, and connectivity. Before his assignment he worked for the Open Systems Centerin Brazil as a DB2 and DRDA specialist.

Thanks to the following people for their invaluable contributions to this project:

Curt L. CotnerIBM Santa Teresa Laboratory

James PickelIBM Santa Teresa Laboratory

Maureen McDevittIBM Santa Teresa Laboratory

Tony K. LeeIBM Santa Teresa Laboratory

David J. MarvinIBM Toronto Laboratory

Al SabawiIBM Toronto Laboratory

Frankie SunIBM Toronto Laboratory

Peter ShumIBM Toronto Laboratory

Mike CookIBM Toronto Laboratory

Leon D. KatsnelsonIBM Toronto Laboratory

Mark LeungIBM Toronto Laboratory

Martin W. MurhammerIBM International Technical Support Organization - Raleigh Center

Alfred ChristensenIBM International Technical Support Organization - Raleigh Center

xvi DB2 for OS/390 and DB2 UDB DRDA TCP/IP Support

Robert HaimowitzIBM International Technical Support Organization - Poughkeepsie Center

Michael ParbsHealth Insurance Commision - Australia

Thanks also to Maggie Cutler for her editorial assistance.

Comments Welcome

Your comments are important to us!

We want our redbooks to be as helpful as possible. Please send us your comments aboutthis or other redbooks in one of the following ways:

• Fax the evaluation form found in “ITSO Redbook Evaluation” on page 211 to the faxnumber shown on the form.

• Use the electronic evaluation form found on the Redbooks Home Pages at the followingURLs:

For Internet users http://www.redbooks.ibm.comFor IBM Intranet users http://w3.itso.ibm.com/redbooks

• Send us a note at the following address:

[email protected]

Preface xvii

xviii DB2 for OS/390 and DB2 UDB DRDA TCP/IP Support

Chapter 1. Product Overview

In this chapter we describe the DB2 products used in this project, with emphasis on newfunctions and new DRDA capabilities. We also provide a list of prerequisite software foreach of the platforms used.

1.1 DB2 Universal Database

The DB2 Universal Database Version 5 (DB2 UDB), announced in December 1996, is thefollow-on product to DB2 common servers. DB2 UDB combines the online transactionprocessing (OLTP) performance, advanced functions, and relational features of DB2common servers with the parallel processing and clustering, query performance, and verylarge database support of DB2 Parallel Edition.

DB2 UDB enhances the integration of an enterprise′s total data resources by various formsof support for the DB2 family (DB2 for OS/390, DB2 for OS/400, and DB2 for VM and VSE).This support ranges from new Transmission Control Protocol/Internet Protocol (TCP/IP)support, new Distributed Relational Database Architecture (DRDA) application server (AS)support, and direct desktop client access with DB2 Connect for Web enablement andmiddleware (data replication support and centralized database systems management).With the use of DataJoiner it is possible to access nonrelational data, such as IMS andVSAM, and non-IBM databases, such as Oracle, Informix, and Sybase.

DB2 UDB provides:

• Web-enablement: DB2 UDB data can be accessed from Web clients through its built-inJava Database Connectivity (JDBC) support or Net.Data. It is also possible to invokestored procedures from a Java application.

• Multimedia: DB2 UDB can manage both traditional and multimedia data.Object-relational extenders support data types such as image, video, audio, and text aspart of the database.

• Scalability: DB2 UDB scales from Intel to UNIX platforms, from notebooks touniprocessors to symmetric multiprocessing (SMP) to massively parallel processing(MPP) environments.

• Integration: Replication support, distributed data warehousing, complex querying power,Internet connectivity, optimized high-performance transaction processing, and databasetools are delivered in one integrated product.

• Openness: DB2 UDB supports leading industry standards and runs on both IBM andnon-IBM platforms, including OS/2, AIX, Windows NT, Windows 95, HP, Sun, SINIX, andSCO.

Copyright IBM Corp. 1997 1

1.1.1 DB2 Connect

DB2 Connect is the follow-on product to Distributed Database Connection Services (DDCS).DB2 Connect allows stand-alone users or local area network (LAN) clients to access datastored in any DRDA server such as DB2 for OS/390, DB2 for OS/400, and DB2 for VM andVSE. Applications running on the client machines work with the host data transparently, asif a local database server managed the data.

DB2 Connect supports the Advanced Program-to-Program Communication (APPC) andTCP/IP protocols for connections with all DRDA servers. For the current releases, however,only DB2 for OS/390 and UDB products support the TCP/IP protocol.

Regardless of the protocol used, DB2 Connect provides DRDA support for distributed unit ofwork (DUW) with two-phase commit processing.

DB2 Connect runs on different platforms including Windows 3.11, Windows 95, Windows NT,OS/2, AIX, HP, Sun, SINIX, and SCO. The Windows 3.11 and Windows 95 products areavailable only in single-user versions and do not support APPC.

Figure 1 on page 3 shows a sample scenario with DB2 Connect.

2 DB2 for OS/390 and DB2 UDB DRDA TCP/IP Support

Figure 1. Sample Scenario with DB2 Connect

1.1.2 Net.Data

Net.Data is an application that runs on a Web server and enables you to create Web pageswith access to DB2 data. Net.Data offers tools for building two-tier and three-tierapplications that can access DB2 data by using standard HTML and SQL. A commongateway interface (CGI) processes input from the HTML pages and sends SQL commandsto a DB2 database specified in the application you create with Net.Data.

Applications can access DB2 data on the Internet server or on other servers, using DB2Client Application Enablers (CAEs) and DB2 Connect. With the use of DataJoiner, theapplication can also access non-DB2 servers.

Net.Data builds on the database access and reporting capabilities of the previous DB2WWW Connection product. However, its function has been enhanced to become acomprehensive Web development tool for the creation of either simple dynamic Web pages

Chapter 1. Product Overview 3

or complex Web-based applications. In addition, it also supports Internet server applicationprogram interfaces (APIs) on the following servers:

• Netscape Server (NSAPI)

• Microsoft Internet Server (ISAPI)

• IBM Internet Connection Server (ICAPI)

Figure 2 shows a sample scenario using Net.Data.

Figure 2. Sample Scenario with Net.Data

1.1.3 DB2 UDB Tools

DB2 UDB includes tools to perform administrative functions and application development.These tools enable performance tuning, access to remote DB2 UDBs, management ofdifferent servers from a single workstation, application development, and process SQLqueries.


The Control Center is a graphical tool that enables you to manage the local server orremote servers from a single point of control. With the Control Center you can:

• Create, alter, and drop DB2 objects

• Backup and recover databases and table spaces

• Define replication policies

• Configure databases and communication protocols

The Control Center provides SmartGuide to help you perform complex tasks. As anexample, when you are tuning the performance of your system, SmartGuide can guide youthrough the process.

The Control Center also has additional facilities to:

• Create mini-applications called scripts. These scripts may contain DB2 commands, SQLstatements, and operating system commands.

• Schedule jobs to run unattended. This facility is useful for tasks such as backups thathave to be executed frequently.

• Monitor the system for potential problems or automate actions to correct problemswithout operator intervention

• Manage your server, performing tasks such as creating an access profile that can beused at the client workstations to uniformly set up each client on the network

• Monitor the performance of your DB2 system and analyze and tune SQL statements

Figure 3 on page 6 shows a typical Control Center window.


Figure 3. DB2 UDB Control Center Window

1.1.4 DB2 UDB Packaging

DB2 UDB has three packaging options, each with a set of components:

• DB2 Personal Edition

− DB2 UDB for use in a single machine. It contains the functions for the databasesystem and DB2 UDB tools but cannot act as a server for clients in the LAN.

• DB2 Workgroup Edition

− DB2 UDB for use as a server in a LAN environment. All functions and tools of thePersonal Edition are also available in the Workgroup Edition.

− DB2 Net.Data for Internet access

− DB2 CAEs for all supported platforms

The DB2 Workgroup Edition requires a valid license for each user connected to theserver.

• DB2 Enterprise Edition

− All components of the Workgroup Edition

− The DB2 Connect product for accessing host databases


The DB2 Enterprise Edition has unlimited usage and does not require additionallicenses for users connected to the server.

The DB2 Software Developer′s Kit (SDK) contains clients, application development tools,and samples for all supported platforms and is available separately. The DB2 SDK enablesyou to develop applications using embedded SQL, call level interface (CLI), open databaseconnectivity (ODBC), and Java through JDBC.

In addition to being part of the DB2 Enterprise Edition, DB2 Connect is also availableseparately in two versions:

• DB2 Connect Personal Edition

For stand-alone workstations, as the previous DDCS Single-User.

• DB2 Connect Enterprise Edition

For connections between LAN clients and the host system. DB2 Connect EnterpriseEdition performs the function of a gateway, as its predecessor DDCS Multi-UserGateway.

1.2 DB2 for OS/390 Version 5

DB2 for OS/390 Version 5 has enhancements in the areas of performance, capacity,availability, client/server, and user productivity. It is the first release to support nativeTCP/IP for DRDA connections. Migration to DB2 for OS/390 Version 5 is possible only froma DB2 for MVS/ESA Version 4 subsystem.

DB2 for OS/390 Version 5 provides:

• Flexible client/server solutions: DB2 for OS/390 delivers TCP/IP connectivity andDistributed Computing Environment (DCE) authentication for DRDA clients, such as DB2Connect. Stored procedures support is also enhanced with query result sets andmultiple address spaces.

• Availability for data warehouse and operational applications: DB2 for OS/390 providesSysplex query parallelism for complex queries and support for very large tables (up to 1TB). With online REORG availability is improved.

• Increased user productivity: DB2 for OS/390 is fully compliant with the SQL92 EntryLevel Standard and provides full year 2000 support. DB2 for OS/390 also delivers a CLIbased on ODBC and X/Open′s CLI and enables the use of object-oriented programminglanguages. Installation, performance tuning, and explain of SQL statements andpackages can now be performed from a workstation.

• Complete database server solution: The DB2 Performance Monitor (DB2 PM), DB2Estimator for Windows, and DB2 WWW Connection are now features of DB2 for OS/390.These new features enable you to monitor and optimize DB2′s performance, assistapplication design and capacity planning, and provide Internet access.


1.2.1 Native TCP/IP Support

TCP/IP is a standard communication protocol. Previous versions of DB2 supported TCP/IPnetworks for DRDA connections only if products such as AnyNet were installed on both theclient and the server. DB2 for OS/390 Version 5 native TCP/IP support eliminates thisrequirement. DRDA clients on many platforms, including OS/2, Windows 3.11, Windows 95,Windows NT, AIX, Solaris, and HP, can connect directly to DB2 for OS/390 without using anSNA gateway machine. These workstation clients require the DB2 Connect product toaccess DB2 for OS/390 using TCP/IP.

There are no SQL changes associated with TCP/IP. Your choice of communication protocol(APPC or TCP/IP) is completely transparent to SQL application programmers and endusers.

The DB2 distributed data facility (DDF) does not support TCP/IP for DB2 private protocolconnections. TCP/IP is supported only for DRDA connections.

Existing SNA connections to Windows NT, OS/2, AIX, and other UNIX systems aresupported, so DB2 can work in an SNA network, a TCP/IP network, or a mixed network.

TCP/IP offers the following advantages:

• Less administrative overhead than SNA

• Inexpensive software costs—it is preinstalled on many systems

• Available on all platforms—more open than SNA.

Native TCP/IP support relies on functions available in OS/390 Release 3 and MVSOpenEdition.

1.2.2 Positioning TCP/IP SupportIn this section we describe some general considerations regarding the support provided byDB2 for OS/390 and TCP/IP.

Unquestionably TCP/IP support for DRDA is a feature that the DB2 community on the MVSplatform has demanded for quite a while. This is the first version of the DB2 product on theMVS platform that delivers TCP/IP support for DRDA, which is expected to enhance not onlyDB2 and TCP/IP on the MVS platform but also the interface between these products. Beaware that for this version the interface is designed to work with TCP/IP 3.2, which mightnot provide excellent performance for heavy processing. New releases of TCP/IP are ontheir way, and they should reduce considerably CPU usage and bring new enhancements.None of these TCP/IP improvements will require changes to DB2. Thus, the TCP/IP supportbuilt into DB2 will get better over time, as the TCP/IP product evolves.

For the subsequent discussion, whenever we refer to SNA, we are referring to the APPCimplementation of it.


1.2.3 Reasons for TCP/IP

There are several reasons why you should choose TCP/IP instead of APPC. Here is just asubset of those reasons:

• Support for Windows 95

You must use TCP/IP if your application requesters (ARs) are on Windows 95. You mustuse TCP/IP if you require gatewayless, direct access, from Windows 95 to DB2 forOS/390. The previous DDCS product was not supported on the Windows 95 platform.DB2 Connect supports only TCP/IP on the Windows 95 platform; it does not supportAPPC on the Windows 95 platform.

Before the TCP/IP support, you could access DB2 data on the MVS platform, but youneeded a gateway machine where DDCS was installed. Typically, you would haveDDCS installed on an AIX or OS/2 workstation, and Windows 95 could request datathrough the DDCS machine in a client/server environment. The gateway servermachine would access DB2 on the MVS platform through DRDA, using APPC. This isstill supported for the new DB2 Connect product.

• No knowledge of SNA

The definitions of and setup for SNA connections are much more complex than those forTCP/IP. If you are starting with distributed databases and your shop has no SNA skills,probably you will choose to use TCP/IP.

• Costs

TCP/IP is generally delivered together with the base operating system for workstations.SNA products for the workstation generally have a cost. For one workstation, the costmay not represent a huge amount of money, but, as the number of your gatewaymachines increases, the cost can be considerable.

• TCP/IP on LAN

Many enterprises as a rule use TCP/IP on their LANs. It thus makes sense to migrateto TCP/IP for a more homogeneous portrait of protocols.

1.2.4 Reasons for APPC

Before moving everything to TCP/IP, you have to consider the following factors, for thecurrent versions and releases of the products:

• Performance

In a huge network, TCP/IP on the MVS platform does not perform as well as APPC. Weforesee that, in the future, there will not be a great difference between APPC andTCP/IP.

• Functions


Although from an application point of view there is no difference between TCP/IP andAPPC, some functions are available only if you use APPC. Most of those functions arerelated to security. DCE security is the most secure method; RACF PassTickets is thenext most secure method. Both methods are supported for SNA and TCP/IPconnections. If you combine SNA logical unit-logical unit (LU-LU) security with RACFPassTickets, you would be close to providing the same security level as DCE since bothprovide mutual authorization. The DCE overhead might be too large for manycustomers to support. TCP/IP does not support inbound translation. For TCP/IP, theacceptance of a userid or a userid and password (or PassTicket, or DCE ticket) issystemwide. With APPC this option can be more granular, at the LU level.

You have different flavors for the two-phase commit processing. For example, TCP/IPprovides two-phase commit for unsecure workstations without requiring them to have arecovery log to minimize possible data outages. SNA does not support this option.However, SNA supports presume abort and presume nothing.

• APPC already been used

If APPC is already in use for DRDA connections, there are no big advantages to movingto TCP/IP unless for one of the reasons mentioned in 1.2.3, “Reasons for TCP/IP” onpage 9. This is particularly true if your DRDA connection is among DB2′s on the MVSplatform.

1.2.5 World Wide Web and ODBC-CLI

The DB2 for OS/390 Version 5 TCP/IP support does not include any direct support for theWWW products.

The WWW products that support DB2 on the MVS platform, such as DB2 WWW for MVSVersion 1 or its follow-on product, Net.Data for MVS, do not require DB2 for OS/390 Version5 and do not use DRDA to access DB2 data. The WWW workstation products use DRDA toaccess DB2 on the MVS platform. They require an AR code such as DDCS or DB2 Connectand can access any DB2 on the MVS platform that supports DRDA. If you use DB2 Connectand DB2 for OS/390 Version 5, the DRDA connection can use TCP/IP as the underlyingcommunication protocol.

The DB2 for OS/390 Version 5 ODBC-CLI support enables you to execute a program in anMVS address space that accesses DB2, using the ODBC-CLI interface. It does not providedirect access from an ODBC-CLI application running in a workstation. ODBC-CLIapplications running in a workstation can access DB2 on the MVS platform, using DDCS orDB2 Connect through DRDA.

DB2 for OS/390 Version 5 is expected to support the JDBC SDK toolkit on MVS, using theDB2 for MVS ODBC-CLI support.


1.2.6 Support for High-Volume Data Transfer

Asynchronous transfer mode (ATM) is a rapidly emerging industry standard for networkingtechnology. With DB2 for OS/390 Version 5 you can use ATM technology as the underlyingtransport for either SNA or TCP/IP, with the following benefits:

• ATM is an open solution with broad vendor support.

• ATM operates at 155 MB/sec, a rate that is projected to be more than 1 GB/sec in thenear future.

• ATM lets network applications reserve network bandwidth, which is beneficial forclient/server database applications. Large, reserved bandwidth is also essential forapplications such as video on demand.

1.2.7 Better Performance for DRDA Applications

DB2 for OS/390 Version 5 new functions improve the performance of high-volumetransaction processing for DRDA client/server applications. DB2 for OS/390 also introduceschanges to help reduce network traffic.

DRDA clients can now use the OPTIMIZE FOR n ROWS clause of the SELECT statement.Users of some client/server applications only need to browse a limited amount of data, forexample, only enough to fill one screen. This clause can be used to influence the DRDAnetwork blocking that DB2 uses to return result sets. Thus clients can limit the number ofdata rows that the server returns during each DRDA network transmission.

DB2 for OS/390 introduces some changes to dynamic SQL query processing that alsoinfluences the performance of DRDA connections. The DDF now optimizes the processingof PREPARE statements for DRDA connections. The SQL statement being prepared must bea SELECT statement with no parameter markers. In that case, DB2 automatically adds anOPEN request to the PREPARE and DESCRIBE flow. In previous releases of DB2, thedynamic SQL SELECT statement required two network message exchanges. In DB2 forOS/390 Version 5, this traffic is reduced for a single network message exchange.

DB2 for OS/390 implements an improved block-fetch processing that benefits queriesreturning a large number of columns and rows. DB2 also exploits enhancements ofACF/VTAM Version 4 Release 4 to reduce the cost of VTAM operations.

1.2.8 Enhanced Stored Procedures Environment

With DB2 for OS/390 Version 5 and enhancements to the MVS Workload Manager (WLM)that are available in OS/390 Release 3, the DB2 stored procedures environment supports ahigher volume of transaction processing than in previous releases. Enhancements includethe following:


• Multiple DB2 address spaces for stored procedures that allow clients to run moreconcurrent transactions. The MVS WLM optimizes performance on the basis of systemworkload. The WLM environment offers efficient program management and allowsWLM-managed stored procedures to run as subprograms and use RACF security.

• Return of multiple SQL result sets to local and remote clients in a single networkoperation

• Use of individual MVS dispatching priorities to improve stored procedure scheduling

• Access of data sources outside DB2 with two-phase commit coordination. This ispossible with the new Recoverable Resource Manager Services attachment facility(RRSAF). The RRSAF can use OS/390 Transaction Management and RecoverableResource Manager Services (OS/390 RRS) to synchronize the two-phase commitprocessing.

1.2.9 Improved Security

DB2 for OS/390 Version 5 supports DCE for authenticating remote DRDA clients. With DCE,you do not have to maintain a password on each MVS system when accessing different DB2servers. You need maintain only one password, the DCE password, to access any DB2 thatsupports DCE security. Using DCE, remote clients do not have to send an MVS password inreadable text; instead they can use an encrypted DCE ticket for authentication.

Previous releases of DB2 supported the use of RACF PassTickets with DB2 as a serveronly. DB2 for OS/390 Version 5 enables you to use RACF PassTickets, also as a client,without having to hardcode your password in the CDB and without transmitting yourpassword across the network.

Another improvement in DB2 for OS/390 security is the possibility of changing expiredpasswords through DRDA. Whenever a DRDA requester is notified that a RACF passwordhas expired, using the new DRDA function to change passwords, you are prompted for thenew password. DB2 for OS/390 supports the new DRDA change password function as aserver but cannot send requests to change passwords in other servers.

1.2.10 DB2 Installer

DB2 for OS/390 installation can now be performed from an OS/2 workstation using a newtool called the DB2 Installer. The DB2 Installer provides a graphical interface that facilitatesthe installation process and provides a graphical record of how each subsystem is defined.The DB2 Installer lets you run SMP/E, installation, and sample jobs. It also indicates jobstatus dynamically and lets you edit JCL, perform job cleanup, and examine job output fromyour OS/2 workstation.

To simplify the installation, the DB2 Installer arranges the install options into main windowsand advanced windows. The install options that must be specified are placed in the main


windows, and the other options can be accessed through the advanced windows. Usingthis approach, you can get a basic subsystem up and running quickly without having tospecify every install option.

1.2.11 Additional Features

DB2 for OS/390 Version 5 simplifies planning, installation, and maintenance of serversoftware by offering the following additional features at the time the product is delivered:

The DB2 PM feature enables you to monitor, analyze, and optimize the performance of DB2and its applications. It includes an online monitor, for both the host and the workstationenvironments, which provides an immediate snapshot view of DB2 for OS/390 activities andallows for exception processing while the system is operational. In addition, it offers ahistory facility to view recent events, a wide variety of customizable reports for in-depthperformance analysis, and an EXPLAIN function to analyze and optimize SQL statements.The workstation-based Online Monitor can connect directly to the Visual Explain function ofthe DB2 base product.

The DB2 WWW Connection feature provides support for Internet access. An applicationbuilt with and managed by DB2 WWW Connection on OS/390 uses the industry-standardHTML and SQL languages and can access DB2 data on local or remote servers. End usersaccess DB2 data from their Web browsers by means of familiar Web page forms. NativeTCP/IP support for DRDA is not a prerequisite for DB2 WWW Connection.

The DB2 Estimator for Windows feature delivers application performance evaluation. DB2Estimator for Windows Version 5 provides an easy-to-use capacity planning tool that helpsdatabase administrators, capacity planners, and application programmers test the feasibilityof system and design changes before investing additional time and money. Withperformance estimates for DB2 Version 5 SQL statements and utilities, you can perform“what if” scenarios for feasibility studies and determine whether utility processing will fitthe available batch window. This no charge feature can be ordered with DB2; it also can bedownloaded from the Internet.

1.3 Software Prerequisites

In this section, we describe the basic software prerequisites for DB2 for OS/390 Version 5and DB2 UDB Version 5.

1.3.1 DB2 for OS/390

DB2 for OS/390 requires the following products:

• MVS/SP Version 4 Release 3 or MVS/ESA Version 5 Release 1 or OS/390 Release 1


Native TCP/IP support for DRDA requires OS/390 Release 3, LE/370 Version 1 Release 5,and OpenEdition.

• DFSMS Version 1 Release 1 or MVS/DFP Version 3 Release 3

• TSO/E Version 2 Release 5

• DFSORT Version 1 Release 13

• SMP/E Version 1 Release 8.1

• ISPF Version 3 Release 5 and ISPF/PDF Version 3 Release 5, or ISPF for MVS Version 4Release 2

• IBM High Level Assembler for MVS Version 1 Release 2

The DDF requires:

• ACF/VTAM Version 3 Release 4.2 or ACF/VTAM Version 4 Release 2

DDF enhancements, such as the EXTENDED SECURITY install option that can be used tocontrol how DB2 reports security errors to DDF clients and the reduction of VTAM sendand receive operations, require ACF/VTAM Version 4 Release 4.

Note: Extended security is also used to enable the change password support andprovide extended DRDA security failures for TCP/IP connections.

1.3.2 DB2 Universal Database Prerequisites

DB2 UDB running on AIX requires the following products:

• AIX Version 3 Release 2.5 or AIX Version 4 Release 1

For APPC connectivity

• IBM Communication Server Version 4.1 for AIX for two-phase commit support, or IBMCommunication Server Version 1 if you do not need two-phase commit.

DB2 UDB running on OS/2 requires the following products:

• OS/2 Warp Version 3 or Version 4, OS/2 Warp Connect Version 3, or OS/2 Warp ServerVersion 4


• For APPC connectivity with two-phase commit with DB2 UDB and DRDA host systemssuch as DB2 for OS/390, you require IBM Communication Server Version 4.1 for OS/2 orlater. If you do not need to use two-phase commit, IBM Communication Server Version1.x or later is sufficient.

For TCP/IP connectivity


• IBM TCP/IP Version 3.0 or later for Warp Versions 3 and 4 and for OS/2 Warp ConnectVersion 3. The OS/2 Warp Server Version 4 base operating system provides TCP/IPconnectivity.

DB2 UDB running on Windows NT requires the following products:

• Windows NT Version 3.51, Version 4.0, or later


• Microsoft SNA Server Version 2.11 or later

For TCP/IP connectivity

• The Windows NT base operating system includes support for the TCP/IP protocol.



Chapter 2. The Project Environment

During the project, we tested many different connections between workstations at theInternational Technical Support Organization (ITSO) in San Jose, California, and amainframe in Poughkeepsie, New York.

Figure 4 shows our project environment.

Figure 4. The Project Environment

Many of the examples in this book refer to the machines shown in Figure 4. In the sectionsthat follow we describe in more detail the configurations we used so that you can easilyunderstand our examples.


2.1 Workstations

We used three IBM Personal Computer 750s and one RS/6000, all running the DB2 UDBBeta 3. Table 1 on page 18 shows the configurations for these workstations.

Table 1. Workstation Configurations

OperatingSystem

Host Name IP AddressPort

NumberResync

Port

OS/2 wewak 129.33.160.112 30000 30001

AIX cayman 129.33.160.198 31000 31001

WindowsNT

yap 129.33.160.161 32000 32001

Windows95

nile 129.33.160.22

The TCP/IP domain name is almaden.ibm.com for the workstations listed in Table 1. TheWindows 95 workstation does not have port numbers because it cannot act as a server.

All workstations had the SAMPLE database installed. To allow connections from ARs to allserver workstations that had the same SAMPLE database name, different alias werecreated for the different servers. Clients accessing the SAMPLE database on differentservers used the following aliases:

SAMP2 Access to the SAMPLE database on the OS/2 server

SAMPX Access to the SAMPLE database on the AIX server

SAMPN Access to the SAMPLE database on the NT server

2.2 Mainframe

During the project, we used a 9672 mainframe located in Poughkeepsie. The mainframe isa Sysplex running the OS/390 Release 3 operating system. We used two members of theSysplex, systems SC48 and SC55.

We installed one non-data-sharing DB2 for OS/390 Version 5 subsystem and a DB2 forOS/390 Version 5 data sharing group. Table 2 on page 19 shows the mainframeconfigurations.


Table 2. Mainframe Configurations

SubsystemID

Location System Host Name IP AddressPort

NumberResync

Port

DB51 DB51 WTSC48 9.12.14.207 446 33000

DBC1 DSGC WTSC48 9.12.14.207 34000 34001

DBC2 DSGC WTSC55 9.12.14.203 34000 34002

The TCP/IP domain name for the mainframe system is itso.ibm.com. Subsystem DB51 is astand-alone DB2; subsystems DBC1 and DBC2 are members of data sharing group DSGC.Host name DB2PLEX.ITSO.IBM.COM is also defined in the domain name server (DNS)pointing to both IP addresses. This common host name was used to allow (in somescenarios) workload balancing between the data sharing members when the ARs connectthrough TCP/IP.

Chapter 2. The Project Environment 19


Chapter 3. TCP/IP Introduction

In this chapter we introduce the concepts of TCP/IP, describing its basic properties, namely,internetworking, protocol layering, and routing.

3.1 Architectural Model

TCP/IP consists of a set of communication protocols; the TCP/IP protocol suite. It is namedfor two of its most important protocols: Transmission Control Protocol (TCP) and InternetProtocol (IP). Another name for it is the Internet Protocol Suite, which is used in officialInternet standard documents. In this redbook we use the term TCP/IP to refer to the entireprotocol suite.

3.1.1 Internetworking

The first design goal of TCP/IP was to build an interconnection of networks that provideduniversal communication services. A set of interconnected networks is called aninternetwork or an Internet. Each physical network has its own technology-dependentcommunication interface in the form of a programming interface that offers basiccommunication functions.

Software running between the physical network and the user applications uses the basiccommunication functions to invoke communications services, as shown in Figure 5 onpage 22. The communication services provide a common interface for these applications,independent of the underlying physical network.


Figure 5. Directions for Services and Functions

The second design goal of TCP/IP was to interconnect different physical networks in a formthat appears to the user as a large network.

To interconnect two networks, you need one machine attached to both networks thatforwards packets (messages) from one network to the other. This machine is called arouter. (Figure 6 shows an example using two interconnected networks, both of which areseen as one logical network.) The term IP router is also used because the routing functionis part of the IP layer of the TCP/IP protocol suite (see C.1, “TCP/IP Architecture - LayeredProtocols” on page 181).

Figure 6. Two Interconnected Networks


From a network standpoint, a router is a normal host. A host identifies an addressablepoint in the network. From a user standpoint, routers do not exist. The user sees only onelarge network.

3.2 Addressing

To uniquely identify a host on the internetwork, each host is assigned an address, known asthe IP address or Internet address.

The IP address consists of a pair of numbers:

IP address = <network number><host number>

The network number is assigned by a central authority and is unique throughout theInternet. The host number can be assigned by a local administrator. An IP address is a4-byte number represented in a dotted decimal format; that is, each byte of the IP addressis displayed in decimal format with a period delimiting each number. For example, 128.2.7.9is the dotted decimal format for the following bit configuration:

BINARY 10000000 00000010 00000111 00001001 DECIMAL 128 2 7 9

Also, depending on the class of the IP address, 128.2 could be the network number, and 7.9the host number.

The first bits of the IP address specify how the address should be divided into the networknumber and the host number. We can distinguish five classes of IP addresses, as shown inFigure 7.

Figure 7. Assigned Classes of Internet Addresses

Chapter 3. TCP/IP Introduction 23

From Figure 7, it is clear that class A addresses are assigned to networks with a largenumber of hosts, and class C addresses are suitable for networks with fewer hostaddresses. Class D addresses are reserved for multicasting, a type of limited broadcastingbetween hosts that have class D addresses.

When a host has multiple network adapters, each adapter has a separate IP address. Ifone host is attached to more than one network, it is called multihomed, and it has one IPaddress for each network interface. Figure 8 shows one host with two network adaptersand a multihomed host connected to different networks using different IP addresses.

Figure 8. Host Network Adapter Connections

The standards for IP addresses are described in RFC 1166 - Internet Number.

3.2.1 Host NamesInternet addresses can also be referenced with a symbolic name, called the host name.Thus, you are not forced to use a dotted decimal format for the IP address.

In a small, isolated TCP/IP network, it is easy to identify all hosts with unique host names.The mapping between host name and IP address is done in a local TCP/IP directory file. Ifyou have a mapping between the IP address 128.2.7.9 and the host name lcs, you canspecify in commands lcs instead of the IP address. For example, to check whether there isconnectivity from your host to IP address 128.2.7.9, issue the PING command:

ping lcs

As a network expands and, especially, when it is connected to other, existing networks,identifying all hosts becomes complicated. So the host names must be qualified by what iscalled the domain name. You acquire a domain name that is unique to your organizationfrom the Network Information Center. The uniqueness of the domain name facilitatesrouting of messages between major enterprises. For example, IBM as an enterprise has adomain name of ibm.com. The IBM domain is part of the domain directory called com,which contains all commercial users. Two other examples of other domain directories areedu (for educational institutions) and gov (for government institutions). Within IBM, there is


a directory entry at ibm.com, for example, to austin.ibm.com. Within either the ibm.comdirectory or a separate directory at austin.ibm.com, there are entries for the host at eachlocation. These directories are generally called hosts files.

If you do not use a host file, the mapping between the host name and the IP address isdone by the domain name system, which uses a standard protocol. The domain namesystem uses a DNS host machine (explained in 3.3, “Name Resolution”). The domain namesystem is supported in most IBM implementations of TCP/IP. It can search directories tofind an IP address for a given host name.

To use host names at least one host in the network must perform the DNS function. ThisDNS has the translation information between host names and the numeric addresses. Thefully qualified host name consists of a hierarchical order that reflects the real authoritydelegation used to assign the domain name. For example:

edu!____________

lcs.mit.edu = ! ! !mit xxx yyy!lcs

In this example, lcs.mit.edu is the fully qualified name. It has a subdomain of mit.edu,which is a subdomain of edu (education). Here edu is the top-level domain name. We canimagine this naming convention as a hierarchical tree representation.

The lowest-level domain name corresponds to the host IP address number. Certainproducts that interface with TCP/IP services, such as DB2 for OS/390, sometimes refer tothe host name as the domain name.

3.3 Name Resolution

Whenever a TCP/IP host needs to access another host, it must have the IP address of thathost. If you or the application specifies a host name, the host name must be resolved intoan IP address. The process of obtaining an IP address from a host name is called nameresolution. Name resolution can be performed by using a file located on the local host forthis purpose (hosts file) or using another host called the DNS. A DNS is a host thatperforms name resolution. When you configure TCP/IP, you can configure one or morehosts to be your DNS.

DNSs are supported on several platforms, such as AIX, OS/2, and MVS. The level ofsupport that a DNS provides depends on the platform on which it resides.

The order of search between the local host file and among the DNSs depends on theplatform of the originating host. For example, if the TCP/IP message originates from an


OS/2 host, the default order of search is first the DNSs in the order in which they areconfigured on the OS/2 host, and then the host file. You can configure another order ofsearch.

DNSs may have entries to other DNSs called foreign DNS. The foreign DNS is used if amatch is not found for the host name in the DNS configured in the local host. If a match fora host name is not found in the host file, DNSs, or foreign DNSs, the requesting host gets anunknown host message.

An application uses the GETHOSTBYNAME() system call to invoke name resolution.

If the IP address indicates a different physical network, the request can be sent acrossmany gateway machines until the request can be delivered or no route is found.

In some situations an IP address must be translated (resolved) into a host name. Thisprocess is called reverse name resolution. DNSs are also capable of performing reversename resolution. An application uses the GETHOSTBYADDR() system call to perform nameresolution.

3.3.1 Network Adapters and Host NamesThere is a relationship among network adapters, host names, and TCP/IP stacks. Toexplain the relationship, we use TCP/IP on the MVS platform.

TCP/IP runs in its own address space. In this context, the address space where TCP/IPexecutes is called a TCP/IP stack or engine.

When the TCP/IP address space comes up, it reserves for its own use a certain number ofnetwork adapters as specified in one of TCP/IP′s data sets. Each network adapter has itsown IP address, but the TCP/IP address space is associated with only one host name. TheDNS maps the unique host name to any of the IP addresses. This relationship is illustratedin Figure 9 on page 27.


Figure 9. Relationship among Network Adapter, IP Address, and TCP Host

If there is a request to connect to the TCP/IP address space, and the request specifies an IPaddress, the network adapter associated with that IP address is used. If the requestspecifies a host name, the DNS returns to the requester the list of IP addresses associatedwith the host name. The requester decides which IP address, and consequently, whichnetwork adapter will be used for establishing the communication. The default is the first onthe list. Instead of returning the list of IP addresses to the requester, some DNSs canchoose which network adapter to use on the basis of an algorithm. For example, a DNSresiding on an AIX SP2 machine can distribute the request among the network adapters ina round-robin fashion. In any case, once the connection is established by using onenetwork adapter, all communication between the requester and the TCP/IP address spaceuses that adapter.

If communication is lost, the resynchronization process must use the same networkadapter. If the communication is lost because of network adapter failure, you can use thevirtual IP address (VIPA) implementation, which provides a degree of flexibility. Toimplement the VIPA, you specify a nonexisting (virtual) IP address as the first IP addressassociated with that TCP/IP stack and specify that the interface type used by this IP addressis VIPA. When you implement VIPA, TCP/IP can automatically route the requests to anotheravailable network adapter.


3.3.2 Ports

In this explanation of ports, a process is any application that requests services from TCP/IP.Each process that must communicate with another process in the network must identifyitself to the TCP/IP protocol suite, using one or more ports. A port can be seen as an opendoor that a process uses when requesting services to TCP/IP. Each port is a 16-bit number.For TCP/IP incoming requests, a port is also used to identify to which application program(process) TCP/IP must deliver incoming messages. The process of delivering incomingmessages to the correct port is called demultiplexing. Figure 10 shows demultiplexingbased on ports.

Figure 10. Demultiplexing

There are three basic types of TCP/IP ports:

• A well-known port is a port number between 1 and 1023 that is reserved in the TCP/IParchitecture for a specific TCP/IP application. Here are some of the well-known portassignments:

− Port number 21 is assigned to File Transfer Protocol (FTP)− Port number 23 is assigned to Telnet− Port number 446 is assigned to DRDA relational database

Port numbers 21, 23, and 446 are preassigned and controlled by the Internet AssignedNumbers Authority (IANA). The rest of the ports, from 1024 to 65535, are not controlledby IANA.

• Ephemeral ports are port numbers that are dynamically assigned to a client process bythe client′s TCP/IP instance. The client may be an MVS application program or anapplication on another platform (Windows NT, Windows 95, Windows 3.11, OS/2, or AIX).


An ephemeral port is associated with the client process as long as the client′s TCP/IPcommunication connection is active. Once the communication connection ends, theephemeral port is available for use by another TCP/IP client process.

• Server port numbers are used when a TCP/IP server program does not have awell-known port number, or another instance of the server program is already installedusing the well-known port number. Server port numbers can be assigned by the TCP/IPnetwork administrator.

In many cases, users find that port numbers are not easy to remember. It is possible toassociate port numbers with service names and let TCP/IP perform the translation fromservice name to port number. For example, port number 446, which is usually used by DB2,can be named DB2xxx, or MYDB2, or something else, depending on user needs.

The TCP/IP ETC services file contains the association between a port number and a servicename.

3.3.3 Sockets

TCP/IP supports an API called sockets. Each socket is a callable programming interfacethat provides a particular function to the calling program. In most TCP/IP systems, thesocket API is designed for application programs written in the C programming language.

DB2 for OS/390 uses the OpenEdition MVS sockets interface to TCP/IP with new extensionsfor assembler language service request block (SRB) mode applications. This new supportis part of the MVS OpenEdition component of OS/390 Release 3.

When a DB2 application issues an SQL CONNECT statement, the DB2 AR code provides toTCP/IP information to reach the AS in a form similar to the following:

{protocol,local-address,local-process,foreign-address,foreign-process}

where:

• protocol is TCP

• local-address is the IP address of the AR

• local-process is the port number used for the AR

• foreign-address is the IP address of the AS

• foreign-process is the port number on which the AS is listening

For example:

{tcp,193.44.234.3,12345,193.44.234.5,2244}

In TCP/IP terms, the above is called an association. An association is represented by a5-tuple that completely specifies the two processes in a connection.


For more information about TCP/IP, refer to Appendix C, “TCP/IP Protocols” on page 181.


Chapter 4. TCP/IP for MVS

In this chapter we present an overview of the TCP/IP for MVS TCP/IP system addressspaces and data sets.

4.1 System Address Space

TCP/IP for MVS runs as a started task in its own address space, known as the TCP/IPsystem address space. This address space is also referred to as the stack, the engine, or aTCP/IP instance. Applications that require to use TCP/IP such as DB2 for OS/390, run inanother address space.

An application′s address spaces can communicate with the TCP/IP system address spacein three ways, using:

• The OpenEdition MVS kernel address space• A virtual machine communication facility/inter-user communication vehicle (VMCF/IUCV)

address space• The high performance native socket (HPNS) path

DB2 for OS/390 communicates with the TCP/IP system address space by using theOpenEdition MVS kernel address space. DDF is the DB2 address space that communicateswith the OpenEdition MVS kernel address space. Refer to D.1, “TCP/IP and OpenEdition”on page 193 for an introduction to MVS OpenEdition and its interface with TCP/IP.

In MVS, you can have several TCP/IP system address spaces. Future releases of TCP/IPwill eliminate a lot of these cross address space moves, and TCP/IP should haveconsiderable performance gains.

As far as DB2 for OS/390 is concerned, only one TCP/IP system address space is used byall DB2 subsystems, as explained in D.3, “Multiple Copies of TCP/IP” on page 195.

Figure 11 on page 32 shows the structure of TCP/IP Version 3 Release 2 for MVS.


Figure 11. Structure of IBM TCP/IP Version 3 Release 2 for MVS

4.2 Data Sets

You define TCP/IP objects through parameters, using TCP/IP statements contained in datasets.

These data sets can have different high-level qualifiers, depending on your environment.Please refer to the TCP/IP for MVS: Customization and Administration Guide and theTCP/IP for MVS: Planning and Migration Guide for TCP/IP configuration data set names.

Refer to Chapter 3, “TCP/IP Introduction” on page 21 for an explanation of such TCP/IPobjects as IP address, host name, DNS (DNS), and ports. Below we describe some TCP/IPdata sets and some statements relevant to DB2.

4.2.1 TCPIP.DATA

The TCPIP.DATA configuration data set contains the TCP/IP parameters that must beavailable to all address spaces that use TCP/IP functions. Some of the parameters are:

DOMAINORIGIN Specifies the domain origin that is appended to the host name to formthe fully qualified domain name for a host. For example:

DOMAINORIGIN ITSO.IBM.COM

HOSTNAME Specifies the TCP/IP host name of the MVS host. For example:


WTSC48: HOSTNAME WTSC48

NSINTERADDR Defines the IP address of a DNS in dotted decimal format. forexample:

NSINTERADDR 9.12.14.7

NSPORTADDR Specifies the DNS port number. For example:

NSPORTADDR 53

TCPIPJOBNAME Specifies the member name of the cataloged procedure used to startthe TCP/IP address space. For example:

TCPIPJOBNAME TCPIP

Depending on how you have costumized your environment, these statements may be inmember TCPDATA of the TCPIP.TCPPARM data set.

4.2.2 tcpip.ETC.SERVICES

The ETC.SERVICES data set contains the TCP/IP service names, the correlated port number,and the Internet style (TCP or UDP). DB2 always uses TCP; for example:

drda 446/tcp #DRDA default service

4.2.3 tcpip.HOSTS.LOCAL

The HOSTS.LOCAL data set contains the host names and the Internet addresses of thehosts. It corresponds to what is typically known as the /etc/hosts file on other TCP/IPplatforms. It must have one line for each distinct host if you are not using a DNS. Forexample:

HOST : 121.65.183.98 : S2.VNET.IBM.COM

4.2.4 PROFILE.TCPIP

Each TCP/IP system address space has a specific PROFILE configuration. You specify thedata set that must be used for the profile configuration in the PROFILE DD statement of theJCL procedure to start up TCP/IP:

PORT Specifies which ports should be reserved to use by this TCP/IPsystem address space and the name of the address space that isallowed to use it. For DB2 definitions the address space nameshould be the OpenEdition procedure name. For example:

PORT 446 TCP OMVS ; DRDA SQL port

GATEWAY Contains the static routes definitions. There are three kinds ofroutes:

Chapter 4. TCP/IP for MVS 33

Direct routes Routes that are directly connected to this hostinterface

Indirect routes Routes that are reachable through routers onthis network

Default route All packets to an unknown destination arerouted through this route.

BSDROUTINGPARMS Defines the characteristics of each physical link for dynamic routing.

DEVICE and LINK TCP/IP for MVS allows a single TCP/IP address space to drivemultiple instances of any supported device. To configure yourdevices, add the appropriate DEVICE and LINK statements to thePROFILE data set. The LINK statements show how to define anetwork interface link associated with the device and are includedwith the DEVICE statement for that device type.

HOME Defines the IP addresses of each link (network adapter) on this host.For example:

HOME 9.12.14.207 TR1

Depending on how you have customized your environment, these statements may be inmember TCPDATA of the TCPIP.TCPPARM data set.


Chapter 5. DB2 for OS/390 and TCP/IP

In this chapter we describe the installation of DRDA TCP/IP support in DB2 for OS/390Version 5. We explain the installation steps, changes required on data sets andprocedures, some common errors, and the customization of the TCP/IP data sets neededfor DB2.

5.1 DB2 for OS/390 Installation

The installation of DB2 for OS/390 Version 5 requires a few changes to prepare yoursubsystem for DRDA TCP/IP connections. In this section we describe these changes,review the parameters required, and explain how to specify the parameters.

5.1.1 Defining TCP/IP to DB2

To enable your DB2 for OS/390 subsystem to use DRDA TCP/IP native support, you mustspecify some parameters during a new installation or migration process.

The DSNTINST CLIST provides two panels for DDF customization: DSNTIPR and DSNTIP5.Panel DSNTIP5 is specific for TCP/IP; however, you must also specify the parameters inDSNTIPR, even those that relate only to APPC support. To use native TCP/IP support, youmust also have APPC support customized and active.

Figure 12 on page 36 and Figure 13 on page 38 show the two DSNTINST panels for DDF.


� � DSNTIPR INSTALL DB2 - DISTRIBUTED DATA FACILITY ===>

Enter data below:

1 DDF STARTUP OPTION ===> AUTO NO, AUTO, or COMMAND2 DB2 LOCATION NAME ===> DB51 The name other DB2s use to

refer to this DB23 DB2 NETWORK LUNAME ===> SCPDBA1 The name VTAM uses to refer to this DB24 DB2 NETWORK PASSWORD ===> Password for DB2′ s VTAM application5 RLST ACCESS ERROR ===> NOLIMIT NOLIMIT, NORUN, or 1-50000006 RESYNC INTERVAL ===> 2 Minutes between resynchronization period7 DDF THREADS ===> ACTIVE (ACTIVE or INACTIVE) Status of a

database access thread that commits orrolls back and holds no database locksor cursors

8 DB2 GENERIC LUNAME ===> Generic VTAM LU name for this DB2subsystem or data sharing group

9 IDLE THREAD TIMEOUT ===> 180 0 or seconds until dormant server ACTIVEthread will be terminated (0-9999)

10 EXTENDED SECURITY ===> YES Allow change password and descriptivesecurity error codes. YES or NO.

PRESS: ENTER to continue RETURN to exit HELP for more information

� �Figure 12. The DSNTIPR Installation Panel

Most of the parameters in the DSNTIPR panel are the same as in DB2 for MVS/ESA Version4. In this panel, you must specify the DB2 LOCATION NAME and the DB2 NETWORKLUNAME parameters. The LU name is used to identify the DB2 subsystem to VTAM and touniquely identify logical units of work. Even if you are planning to use only TCP/IP tocommunicate with remote sites, you still have to configure the LU name parameter andVTAM, because DB2 uses the network ID and the LU name to identify units of work.

You should also consider specifying a nonzero value for the IDLE THREAD TIMEOUT(IDTHTOIN) parameter to prevent TCP/IP network outages from affecting DB2 dataavailability. This parameter defines the number of seconds that an active server thread isallowed to remain idle and hold locks before it is canceled. Inactive and indoubt threadsare not subject to timeout.

The IDLE THREAD TIMEOUT parameter is not specific to TCP/IP. When you specify a valuefor it, any DDF thread using APPC or TCP/IP is subject to cancellation. Active, idle DDFthreads are, for example, threads originating from a remote application program that didsome SQL processing, did not issue an SQL COMMIT or ROLLBACK statement, and is


waiting for user input. Also, if a network problem occurs after a successful execution of anSQL statement, the DDF thread remains active, holding DB2 resources. For that reason,you can use the IDLE THREAD TIMEOUT parameter to automatically cancel the thread, rollback its updates, and release the resources.

If you specify a timeout value of less than 3 min, it may not be honored for up to 3 min.This may happen because the threads are checked every 3 min to see whether they haveexceeded the timeout value. The default value for this parameter is zero, which disablesthe timeout processing.

The EXTENDED SECURITY (EXTSEC) parameter is new in DB2 for OS/390. It is used tocontrol new security options, regardless of the communication protocol being used (TCP/IPor APPC). If you specify YES, it enables the DRDA change RACF password function. It alsoprovides detailed error messages for requests that failed because of security errors. If youspecify NO, RACF users cannot change their passwords through DRDA, and generic errorcodes are sent to DDF clients when security errors occur. The EXTENDED SECURITYparameter requires the use of either TCP/IP or VTAM Version 4 Release 4. The EXTENDEDSECURITY facility is available for ARs running on any platform. For OS/390 clients theEXTENDED SECURITY parameter does not provide support for password changing.

Chapter 5. DB2 for OS/390 and TCP/IP 37

� � DSNTIP5 INSTALL DB2 - DISTRIBUTED DATA FACILITY PANEL 2 ===>

Enter data below:

1 DRDA PORT ===> 446 TCP/IP port number for DRDA clients.1-65534. 446 is reserved for DRDA.

2 RESYNC PORT ===> 33000 TCP/IP port for 2-phase commit. 1-655343 TCP/IP ALREADY VERIFIED ===> YES Accept requests containing only a userid

(no password)? YES or NO

PRESS: ENTER to continue RETURN to exit HELP for more information� �Figure 13. The DSNTIP5 Installation Panel

This DSNTIP5 panel relates only to the TCP/IP protocol. The first parameter, DRDA PORT,specifies the TCP/IP port number used for accepting TCP/IP requests from remote DRDAARs. To use TCP/IP as an AS or AR, you can specify the DRDA well-known port number446 or a server port number assigned to DB2. For more information on TCP/IP ports, referto 3.3.2, “Ports” on page 28. In a non-data-sharing environment, each DB2 subsystem inthe same MVS system must have a unique DRDA port number, regardless of the MVSwhere the subsystem is running. In a data sharing environment, all members of the datasharing group share the same DRDA port number.

The RESYNC PORT parameter is used to specify the TCP/IP port number used to processrequests for two-phase-commit resynchronization. You must specify a server port numberdifferent from the number used for the DRDA PORT parameter. Each DB2 subsystem in thesame MVS system must have a unique resynchronization port. In a data sharingenvironment, each member of the data sharing group must also have a uniqueresynchronization port.


Both the DRDA PORT and the RESYNC PORT parameters should specify values that arereserved in the TCP/IP subsystem, although DB2 works if they are not defined to TCP/IPand not being used by other applications.

The values specified on these parameters are used to generate the JCL that stores them inthe DB2 bootstrap data set (BSDS). For more information about how to customize theTCP/IP subsystem for DB2, refer to 5.3, “Defining DB2 to TCP/IP” on page 43.

The TCP/IP ALREADY VERIFIED parameter specifies whether a TCP/IP connection isaccepted with only the user ID, or whether a password is required with the connectionrequest. If you specify YES, requests with only a user ID are accepted. If you specify NO,the request must also contain a password, or a RACF PassTicket, or a DCE ticket. In a datasharing group, all members must specify the same value for the TCP/IP ALREADY VERIFIEDparameter.

The TCP/IP protocol does not provide the same level of security checking as the APPCprotocol for client authentication. The TCP/IP ALREADY VERIFIED parameter simulates thesame support provided by the VTAM SECACPT=ALREADYV specification. However, whenyou use APPC, VTAM decides whether a connection without a password will be accepted.When you use TCP/IP, the level of authentication accepted by the AS is done by the DB2DRDA protocol during the conversation.

Notice that you do not specify an IP address (or host name) during DB2 installation. DB2obtains this information dynamically from TCP/IP, so you cannot enter this value duringinstallation.

After you have selected your options for the DDF parameters, the installation processgenerates the JCL to update the BSDS and the procedure to start the DDF address space.

5.1.2 Migration and Update Considerations

During the migration to DB2 for OS/390 Version 5, or when updating installation options, youcan change all DDF parameters by using the DSNTINST CLIST.

Most of DDF parameters are stored in the DSNZPARM module. You can use the DSNTIJUZmember of the installation library to update the DSNZPARM module. The TCP/IP portnumbers and the APPC LU name information are not part of the DSNZPARM module; theyare stored in the BSDS and can be updated with the change log inventory utility, which isalso in the DSNTIJUZ member.

5.1.3 BSDS Changes

The TCP/IP port and resynchronization port numbers used by DB2 are stored in the BSDScommunication record. After you execute the installation DSNTINST CLIST, the DSNTIJUZmember of the SDSNSAMP data set is generated. One of the steps of the DSNTIJUZ JCL is


an invocation of the change log inventory utility to update the BSDS information. Figure 14on page 40 shows the DSNTIJUZ job step to update the BSDS.

� �//*//* CHANGE LOG INVENTORY://* UPDATE BSDS WITH PASSWORDS,//* UPDATE BSDS WITH DISTRIBUTED VALUES//*//DSNTLOG EXEC PGM=DSNJU003,COND=(4,LT)//STEPLIB DD DISP=SHR,DSN=DSN510.SDSNLOAD//SYSUT1 DD DISP=OLD,DSN=DSN510.BSDS01//SYSUT2 DD DISP=OLD,DSN=DSN510.BSDS02//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSIN DD *DDF LOCATION=DB51,LUNAME=SCPDBA1,

NOPASSWD,RESPORT=33000,PORT=446 <-- (1)� �Figure 14. The Change Log Inventory Step of DSNTIJUZ

The DDF statement of the change log inventory utility has been enhanced with the PORTand RESPORT parameters (1). These parameters are used to add or update the TCP/IPport numbers in the BSDS.

If PORT and RESPORT are defined, DDF accepts TCP/IP connections from any client thatprovides valid security information. DB2 also allows outbound connections to other DRDAservers using TCP/IP.

To enable native TCP/IP support, you must also have DB2 defined to VTAM. So theLUNAME keyword must be defined in the BSDS, the APPL must be defined in VTAM, andthe LU must be active.

To disable native TCP/IP support, you must update the PORT and RESPORT values to zero:

DDF PORT=0,RESPORT=0

To execute the change log inventory utility, you must stop the DB2 subsystem.

5.2 DDF Considerations

The installation process generates the JCL needed to start the DDF address space. TheDSNTIJMV member of the SDSNSAMP data set contains the steps to define the DB2subsystem to OS/390. One of these steps updates the OS/390 PROCLIB with the DB2


procedures. Figure 15 on page 41 shows an example of the procedure used to start thessnmDIST DDF address space.

� �//*************************************************//* JCL PROCEDURE FOR THE STARTUP OF THE//* DISTRIBUTED DATA FACILITY ADDRESS SPACE//*//*************************************************//DB51DIST PROC RGN=0K,// LIB=′ DSN510.SDSNEXIT′//IEFPROC EXEC PGM=DSNYASCP,REGION=&RGN//STEPLIB DD DISP=SHR,DSN=&LIB// DD DISP=SHR,DSN=DSN510.SDSNLOAD// DD DISP=SHR,DSN=CEE.SCEERUN <-- (1)� �

Figure 15. The DDF Address Space Startup Procedure

To use native TCP/IP support, DDF uses some functions provided by the LanguageEnvironment/370 (LE/370) product. You must ensure that DDF has access to the LE/370runtime library. The installation procedure automatically adds the LE/370 runtime libraryname (specified in panel DSNTIPG) to the STEPLIB concatenation of the DDF JCL procedure(1). In this case, you must ensure that the LE/370 runtime library is APF authorized.

Another way of providing DDF with access to the LE/370 runtime library is to concatenatethe library to the OS/390 link list. If you choose this option, the LE/370 runtime library doesnot have to be APF authorized, and it should be removed from the DDF JCL procedure.

5.2.1 DDF and OpenEdition

DDF uses the OpenEdition assembler callable interface to perform TCP/IP services. Someof these services are only available in OS/390 Release 3. Because of these requirements,to use native TCP/IP support, you must ensure that you have OS/390 Release 3 andOpenEdition MVS installed in your system.

Some of the OpenEdition functions that DDF executes require an authorized user withcertain privileges. To execute the authorized functions, the user ID associated with the DDFstarted task must be defined for OpenEdition as a superuser. To define a user ID as asuperuser for OpenEdition, you must set the User Identifier (UID) parameter of the RACFuser profile to zero. To set the UID parameter for your DDF user, you can issue one of thefollowing RACF commands:

ADDUSER userid OMVS(UID(0))...ALTUSER userid OMVS(UID(0))...


In the above commands, userid should be replaced with the user ID associated with theDDF address space. The ADDUSER RACF command adds a new user profile and should beused if you are creating a new user for DDF. The ALTUSER RACF command changes theRACF profile for the existing DDF user. You can also use the RACF panels to change theUID parameter. Figure 16 shows the RACF panel used to define the UID parameter.

� �RACF - CHANGE USER DDFUSER 1 of 3OMVS PARAMETERS

COMMAND ===>

Delete ALL OMVS information (NOOMVS) ===> Enter YES to DELETE

-- OR --

Select only ONE option from each group to CHANGE or DELETE, then press ENTER.

Specify new User Identifier (UID) ===> 0 0 - 2147483647Delete User Identifier (NOUID) ===> Enter YES to DELETE

Change Initial Path Name (HOME) ===> Enter YES to CHANGEDelete Initial Path Name (NOHOME) ===> Enter YES to DELETE

Change Program Path Name (PROGRAM) ===> Enter YES to CHANGEDelete Program Path Name (NOPROGRAM) ===> Enter YES to DELETE

� �Figure 16. RACF Panel to Change the UID Parameter

If your DDF user ID is not defined as a superuser, during the startup of DDF the followingmessage is displayed at the MVS system log:

DSNL512I =DB51- DSNLILNR TCP/IP SETRLIMIT FAILED WITHRETURN CODE=139 AND REASON CODE=1148033C

To check whether your DDF user ID is already defined to OpenEdition as a superuser, issuethe following RACF command:

LISTUSER userid OMVS

The output of this command includes an OpenEdition section (OMVS Information) thatshows the UID value:


OMVS INFORMATION ---------------- UID= 0000000000 HOME= / PROGRAM= /bin/sh

If you specify both a user ID and a group in the RACF Started Procedures Table, ICHRIN03,for the DDF address space, the group must also have a valid OpenEdition group ID (GID)setting. To define RACF groups to be OpenEdition groups, use the RACF panels or one ofthe following commands:

ADDGROUP groupid OMVS(GID(n))...ALTGROUP groupid OMVS(GID(n))...

where groupid is the name of the RACF group associated with the DDF address space, andn can be any valid, unique identifier. There is no requirement to set GID to zero; you canuse any value you want.

For more information about how to define DB2 resources to RACF, please refer to DB2 forOS/390 Administration Guide Volume 1.

5.3 Defining DB2 to TCP/IP

In this section, we describe the steps to customize TCP/IP for DB2.

5.3.1 Registering DB2 Port Numbers

During DB2 for OS/390 installation, you must select TCP/IP port numbers for DB2′s serverprocessing. You must plan carefully this assignment of TCP/IP port numbers to DB2,because TCP/IP uses the port numbers to pass network requests to the correct MVSapplication. In a non-data-sharing environment, each DB2 subsystem in the same MVSsystem must have unique port numbers.

To define the port numbers in TCP/IP you must update the TCP/IP PROFILE data set. Tofind out the name of the PROFILE data set your TCP/IP system is using, look at the TCP/IPaddress space startup JCL procedure and check the name of the data set being allocatedwith DDNAME PROFILE. If there is no DDNAME PROFILE in your TCP/IP JCL procedure,your TCP/IP is using dynamic allocation for the PROFILE data set. In that case, refer to“Understanding TCP/IP Data Set Names” in the TCP/IP for MVS Customization andAdministration Guide, for a complete explanation of how TCP/IP dynamically allocates itsdata sets.

Once you know the name of your PROFILE data set, you can update it with your DB2subsystem information. You must register the TCP/IP port numbers you have specified


during DB2 installation or using the change log inventory utility. Use the PORT statement toregister port numbers in the PROFILE data set, as shown in Figure 17 on page 44.

� �PORT

7 UDP MISCSERV ; Miscellaneous Server7 TCP MISCSERV9 UDP MISCSERV

:::

446 TCP OMVS ; DRDA SQL port for DB51 33000 TCP OMVS ; DRDA SQL resync port for DB51

::� �

Figure 17. PORT Statement in TCP/IP PROFILE Data Set

In Figure 17, we have defined the two port numbers required by our DB2 subsystem, DB51.In the PORT statements you must use TCP as the protocol, and the name of theOpenEdition started procedure, in our case, OMVS. Because DB2 uses OpenEditionservices to connect to TCP/IP, the DB2 ports are reserved to the OpenEdition address spaceand not to the DDF address space, xxxxDIST. In future releases of OS/390, it will bepossible to reserve DB2 port numbers to the DDF address space.

If you define a wrong name for the OpenEdition started procedure, the following message isdisplayed at the MVS system log during DDF startup:

DSNL515I =DB51 DSNLILNR TCP/IP BIND FAILED FOR PORT446 WITH RETURN CODE=1115 AND REASON CODE=12E80291

DB2 native TCP/IP support works even if you do not register the port numbers in the TCP/IPPROFILE data set. However, we strongly recommend that you register the DB2 portnumbers. Registering the DB2 port numbers to OpenEdition prevents othernon-OpenEdition applications from using the DB2 port numbers by mistake.

5.3.2 Defining TCP/IP Host Names

DB2 for OS/390 uses TCP/IP host names as both an AS and an AR. DB2 needs the localhost name to be defined before DDF is started. As an AR, if you use host names in theIPADDR column of the SYSIBM.IPNAMES CDB table, all AS host names must also bedefined.

For DB2 to obtain its local host name it performs the following tasks:


1. DB2 issues the GETHOSTID() command to obtain the IP address of the host. TCP/IPreturns the local IP address to DB2 on the basis of the HOME statement in thePROFILE.TCPIP data set. The HOME statement specifies the IP address assigned to thehost.

2. On the basis of the IP address obtained, DB2 issues a GETHOSTBYADDR() command.This command goes to the DNS and returns the host name for the specified address.

3. If there is no DNS, or if a matching IP address is not found in the DNS, theHOSTS.LOCAL data set is searched.

If your TCP/IP is configured to use a DNS, it is likely that all of the host names that DB2needs are already defined in the DNS. In that case, you do not have to worry about hostname definitions for DB2. For more information about DNS and host names, refer to 3.3,“Name Resolution” on page 25.

If your TCP/IP does not use a DNS or if the DNS does not contain all required entries, youhave to define the local host name used by this host and the host names required forremote connections in the TCPIP.HOSTS.LOCAL data set. Note that TCPIP is the defaulthigh level qualifier for TCP/IP data sets, and it may be different in your installation. Thehigh-level qualifier used in your TCP/IP subsystem is specified in the DATASETPREFIXstatement of the PROFILE data set or in the TCPIP.DATA data set.

To customize your HOSTS.LOCAL data set, you must edit it and add an entry for every hostname you need. Here is an example of HOSTS.LOCAL data set entries:

::

HOST : 9.12.14.207 : WTSC48 ::::HOST : 129.33.160.120 : FABIANA :::HOST : 129.33.143.34 : ALINE :::

::

Note that WTSC48 is the host name for the local host.

After the HOSTS.LOCAL data set is configured, you have to execute the MAKESITE utility.On the basis of the information in the HOSTS.LOCAL data set, the MAKESITE utilitygenerates the HOSTS.ADDRINFO and the HOSTS.SITEINFO data sets that are used totranslate host names into IP addresses. By default, the user ID executing the MAKESITEutility is used as the high-level qualifier for these two data sets. To make those two datasets available to all of your users, they must have the TCP/IP high-level qualifier. Invokethe MAKESITE utility with the HLQ parameter:

MAKESITE HLQ=TCPIP

If, during DDF startup, DB2 fails to obtain the local host name, the following message isdisplayed in the MVS system log:


DSNL512I =DB51 DSNLILNR TCP/IP GETHOSTBYADDR FAILEDWITH RETURN CODE=16 AND REASON CODE=00000001

If TCP/IP is not active during DDF startup, the following message is displayed in the MVSsystem log:

DSNL512I =DB51 DSNLILNR TCP/IP GETHOSTID FAILED WITHRETURN CODE=112 AND REASON CODE=12E60296

To support a Sysplex environment or multiple network interfaces on a single host, werecommend that you use the DNS or the HOSTS.LOCAL data set to associate the multiple IPaddresses with a single host name. In future versions of OS/390, the DNS will interface withthe WLM to translate the host name to the most suitable IP address according to eachsystem load.

When new releases of OS/390 are available, changes in the Sysplex environment willenable WLM to support automatic workload balancing by using the DNS. To enable thisfuture support, DB2 will generate two host names:

location.sysplexname.domainname- used by clients to access a location

luname.location.sysplexname.domainname - used by ARs to perform resynchronization with a specific subsystem

When the new release of OS/390 is available, populating the DNS with these names will beautomatic and managed by WLM. Until then, the DNS must be set up with these names.For now, DB2 generates these names by issuing GETHOSTID() to get the host IP addressand GETHOSTBYADDR() to get the host name. An OS/390 IXCQUERY call is made to getthe Sysplex name. DB2 strips off the high-level qualifier in the host name and prefixes itwith location.sysplexname to the remaining portion of the host name. Theluname.location.sysplexname.domainname is used transparently to the application; theserver provides this name to the client to be used if resynchronization is required after afailure in two-phase-commit processing.

5.3.3 Defining TCP/IP Service Names

DB2 for OS/390 uses TCP/IP service names only as an AR if you use a service name,instead of a port number, in the PORT column of the SYSIBM.LOCATIONS CDB table. Inthis case, you must define all service names used in the TCPIP.ETC.SERVICES data set.Here is an example of entries in the TCPIP.ETC.SERVICES data set:

drda 446/tcp # DRDA default servicedb2os2 30000/tcp # Service name for DB2 UDB ASdb2aix 31000/tcp #

For more information about port numbers and service names, refer to 3.3.2, “Ports” onpage 28.


5.3.4 Additional Considerations

TCP/IP communication failures can cause DDF threads to hang for a long time. Configuringthe IDLE THREAD TIMEOUT DDF parameter and the TCP/IP keep-alive timer, you canprotect the DB2 subsystem from TCP/IP outages. Refer to 5.1.1, “Defining TCP/IP to DB2”on page 35 for information about how to specify the IDLE THREAD TIMEOUT parameter.

The keep-alive timer can be used to notify DB2 when a network failure occurs. Thekeep-alive timer mechanism periodically sends a packet on a possible idle connection.After TCP/IP receives a message and the keep-alive timer is active, TCP/IP startsaccumulating the time. If the timer reaches a specified value, TCP/IP sends a packet to theremote TCP/IP. If the remote TCP/IP does not respond to the packet, the connection isended and DB2 is notified. If any message arrives before the timer reaches the specifiedvalue, the timer is reset.

You can specify the interval TCP/IP waits to transmit the keep-alive timer packet. Thedefault interval is 2 hours. This default implies that a DDF thread can hang for up to 2hours until DB2 is notified of a failure. The hung thread can cause many operationalproblems for the DB2 server, especially if the thread holds locks on critical DB2 resources.

To change the keep-alive timer interval, you have to edit the TCP/IP PROFILE data set andinclude the KEEPALIVEOPTIONS parameter. The INTERVAL keyword of theKEEPALIVEOPTIONS parameter specifies the number of minutes TCP/IP waits afterreceiving a packet for a connection before it sends a keep-alive packet for that connection.Here is an example of the KEEPALIVEOPTIONS parameter:

::

KEEPALIVEOPTIONS INTERVAL 5ENDKEEPALIVEOPTIONS

::

In this example, we set the keep-alive timer interval to 5 min. We strongly recommend thatyou specify a value of 5 min or less for the TCP/IP keep-alive timer. Note that the activationof the keep-alive timer is valid for all TCP/IP connections, not only for DB2 connections.

If a network outage occurs during the exchange of messages between the client and theserver, TCP/IP eventually notifies both the client and the server. However, the timeliness ofthe notification depends on where the outage occurs in the exchange of messages. Tobetter understand the use of the TCP/IP keep-alive timer and the IDLE THREAD TIMEOUTparameter, consider the message exchanges between a DRDA client and a DB2 server, asshown in Figure 18 on page 48.


Figure 18. TCP/IP Network Message Exchange

In Figure 18, for each message that a TCP/IP host sends, an acknowledgment message issent back. Also, TCP/IP does not have the concept of a conversation as in SNA. Forexample, as far as TCP/IP is concerned, there is no relationship among REQ1, REPLY1, andREQ2.

In Figure 18, the keep-alive timer is triggered whenever a TCP/IP host receives a message.For the DRDA client this occurs in T2, T3, and T6. For the DB2 server this happens in T1,T3, and T5.

Here is what happens, from the client perspective, for the intervals shown in Figure 18:

• If a network outage occurs between T1 and T2, TCP/IP reports the failure to the DRDAclient in a relatively short time. The keep-alive timer is not used in this case. TCP/IP atthe client tries to retransmit REQ1 over a different route. It keeps retransmitting until itgets an acknowledgment or all routes time out.

• If a network outage occurs between T2 and T3, the keep-alive timer triggered at T2causes TCP/IP to send a packet to the server. If the server is no longer accessible,TCP/IP reports the failure to the DRDA client. Note that TCP/IP does not know whetherREPLY1 will come or not because TCP/IP is a full-duplex communication protocol. TheDRDA client hangs until TCP/IP notifies it that a network outage has occurred.

If there is no network outage, but execution of REQ1 is taking a long time, thekeep-alive timer will periodically send a packet and reset the timer every time aresponse is received.


• In T3 the keep-alive timer is triggered again. If there is a network outage between T3and T4 the DRDA client is notified because there is no acknowledgment for the ACKREPLY1 message that the client sent.

• If a network outage occurs in the interval between T4 and T5, it is also covered by thekeep-alive timer, because it was triggered in T3. Note that because T4 is sent amessage, it does not reset the timer.

• If a network outage does not occur between T4 and T5, the keep-alive timer will onlysend packets and get a response back. The keep-alive timer flags an error only ifTCP/IP on the server side cannot be reached.

For this interval, from a DB2 server perspective, the thread is idle. If the clientapplication does not issue a COMMIT statement during this interval, it remains holdinglocks in DB2 resources. If you use only the keep-alive timer, the locks would be helduntil a network failure, or until a COMMIT statement is issued. In this time interval, it isimportant to have the IDLE THREAD TIMEOUT parameter defined to cancel theapplications that did not issue the COMMIT statement often enough.

• The interval between T5 and T6 is similar to the interval between T1 and T2, and thekeep-alive timer is not used.

Similar processing occurs on the server side:

• If a network outage occurs between T1 and T2, the keep-alive timer triggered at T1reports the failure to the DB2 server.

• If a network outage occurs between T2 and T3, the keep-alive timer triggered at T1reports the failure to the DB2 server.

• If a network outage occurs between T3 and T4, TCP/IP reports the failure to the DB2server in a relatively short time. The keep-alive timer is not used in this case. TCP/IPat the server tries to retransmit REPLY1 over a different route. It will keepretransmitting until it gets an acknowledgment or all routes time out.

• If a network outage occurs after T4, the keep-alive timer triggered at T4 or T5 reportsthe failure to the DB2 server.

When the keep-alive timer detects a network failure and notifies DB2, the followingmessage is displayed on the MVS system log and the DB2 master address space:

DSNL511I =DB51 DSNLIENO TCP/IP CONVERSATION FAILEDTO LOCATION 129.33.160.112IPADDR=129.33.160.112 PORT=1267SOCKET=READ RETURN CODE=1127 REASON CODE=12EE0291

If the thread is canceled, because of the IDLE THREAD TIMEOUT parameter, the followingmessages are displayed:


DSNL027I =DB51 SERVER DISTRIBUTED AGENT WITH 118LUWID=090C0ECF.9703.711140315388=16RECEIVED ABEND=04EFOR REASON=00D3003B

DSNL028I =DB51 090C0ECF.9703.711140315388=16 119ACCESSING DATA FORLOCATION 129.33.160.112IPADDR 129.33.160.112

For both cases, the thread is canceled, and the updates are rolled back.

Be sure that the keep-alive timer is set not only for MVS but also at each client′sworkstations.


Chapter 6. DB2 for OS/390 As an AS

In this chapter we describe consideration for DB2 for OS/390 as an AS using TCP/IP. Wealso describe some considerations about a data sharing environment.

In this book we choose to use the term host name instead of domain name, the term used inthe current DB2 literature.

6.1 Definitions

You must define a server port number and a resynchronization port number to supportTCP/IP connection requests from remote DRDA clients. TCP/IP uses the server′s portnumber to pass network requests to the correct DB2 subsystem.

The TCP/IP port number definitions required are:

• For DRDA SQL requests, you can use the well-known port number 446 reserved forDRDA, or you can choose an available port number assigned by the TCP/IPadministrator.

• For the resynchronization port number, you must choose another available port numberassigned by the TCP/IP administrator. The resynchronization port is used forresynchronization of two-phase-commit processing.

These port numbers should also be defined in the PROFILE.TCPIP data set.

If you plan to use DB2 only as a TCP/IP AS, you do not have to populate the CDB. ForTCP/IP, no rows are needed in the CDB tables because DB2 for OS/390 does not searchany CDB table to determine which clients in the network are allowed to connect to the DB2subsystem.

TCP/IP on the MVS AS does not support inbound name translation. Inbound security is notestablished on individual clients, so you cannot use the CDB for “come from” checking ofTCP/IP clients. Security requirements for TCP/IP clients is systemwide. The TCPALVERparameter value specified in the DSN6FAC macro of DSNZPARM defines the minimumsecurity requirements for all TCP/IP clients. You can specify whether DB2 for OS/390accepts TCP/IP connection requests containing only the user ID or a user ID with apassword (or RACF PassTicket) or a DCE ticket.

If you are using a data sharing group, the value of the TCPALVER parameter must be thesame for all members of the data sharing group. You can use RACF to limit the user IDsauthorized to access DB2 for OS/390 using TCP/IP. Refer to Chapter 12, “SecurityConsiderations” on page 121 for more details on security.

The server port number and the resynchronization port number can be specified during theinstallation process in the DSNTIP5 panel. This specification generates the appropriate


control statements used by the change log inventory utility to update the DDF record in theBSDS.

If you have more than one DB2 subsystem on the same MVS system, you must have aunique server port number and resynchronization port number for each DB2 subsystem. Forexample, if there are two DB2 subsystems (DB51 and DB2B) on the same MVS system(MVS1), you cannot assign port number 446 for the SQL request and 33000 forresynchronization processing to both DB2 subsystem, because TCP/IP supports only oneserver at each pair of port numbers. You can assign port numbers 446 and 33000 to DB51and port numbers 33001 and 33002 to DB2B as shown in Figure 19.

Figure 19. Port Numbers for Two DB2 Subsystems on the Same MVS

Figure 20 is an example of the corresponding definition required in the PROFILE.TCPIP dataset for system DB2B.

33001 TCP OMVS ;DRDA SQL server port for DB2B33002 TCP OMVS ;Resync port for DB2B

Figure 20. PROFILE.TCPIP Data Set Definit ion for Port Numbers

For this example OMVS is the OpenEdition MVS started procedure name.

The PORT and RESPORT parameters can be changed on any DB2 subsystem by runningthe change log inventory utility. If you change the port number or resynchronization portnumber, you should update the PROFILE.TCPIP data set with the same value.

Figure 21 on page 53 is an example of the DDF control statement for the change loginventory utility.


� �DDF LOCATION=DB2B,LUNAME=SCPDBA1,

NOPASSWD,RESPORT=33002,PORT=33001� �Figure 21. DDF Statement to Define PORT and RESPORT

Figure 22 is an extract of the output of the print log map utility showing the DDF record inthe BSDS.

� �**** DISTRIBUTED DATA FACILITY ****

COMMUNICATION RECORD00:39:52 MARCH 01, 1997

LOCATION=DB2B LUNAME=SCPDBA1 PASSWORD=(NULL) GENERICLU=(NULL)PORT=33001 RPORT=33002� �

Figure 22. DDF Communication Record in the BSDS

In a data sharing environment, all members of the DB2 data sharing group must have thesame value for server port number, and each member must have a uniqueresynchronization port. Because the server port number is the same for all members of thedata sharing group, if you change the number on one member, you must change it on allother members of the group.

During DDF startup you see new messages related to TCP/IP support, as shown inFigure 23.

� �=DB51 START DDFDSNL021I =DB51 START DDF COMMAND ACCEPTEDDSNL003I =DB51 DDF IS STARTINGDSNL519I =DB51 DSNLILNR TCP/IP SERVICES AVAILABLE

FOR DOMAIN wtsc48.itso.ibm.com AND PORT 446 <-- (1)DSNL004I =DB51 DDF START COMPLETE 746

LOCATION DB51LU USIBMSC.SCPDBA1GENERICLU -NONEDOMAIN wtsc48.itso.ibm.com <-- (2)TCPPORT 446 <-- (3)RESPORT 33000 <-- (4)� �

Figure 23. DB2 Messages during DDF Startup

Chapter 6. DB2 for OS/390 As an AS 53

(1) - This message is issued when TCP/IP support is available.

If during the startup process, or at a later point in time, DB2 encounters a problem withTCP/IP, it issues message DSNL515I, identifying the cause of the error. In this case, DDFperiodically tries to reinitialize TCP/IP. When the reinitialization is successful, DDF issuesDSNL519I again.

(2) - DOMAIN of message DSNL004I indicates the host name (wtsc48) and the domain name(itso.ibm.com).

DB2 obtains the IP address by issuing the GETHOSTID() command. It then issues aGETHOSTBYADDR() to obtain the corresponding host name for this IP address. The hostname is obtained from the DNS, the TCPIP.DATA data set, or the TCP/IP site tables, in thatorder. It must be a fully qualified name for a successful two-phase-commitresynchronization process. If the IP address is not found, message DSNL512I GETHOSTIDFAILURE is issued.

(3) - TCPPORT indicates the port that DB2 is using. It is defined in the BSDS.

(4) - RESPORT indicates the resynchronization port that DB2 is using. It is defined in theBSDS.

DB2 for OS/390 V5 implements two-phase commit for TCP/IP protocols. It supports twotypes of two-phase commit for TCP/IP clients:

• The DRDA client coordinates the two-phase commit.

• The DRDA client gives responsibility for the resynchronization to an AS.

CDB definition is not required for resynchronization.

Refer to Chapter 13, “Distributed Unit of Work” on page 137 for details about the two-phasecommit process.

6.2 Virtual IP Address Considerations

If you have more than one network controller on a single central processing complex (CPC),we recommend using a VIPA because, if the network controller fails, TCP/IP canautomatically route the data to another network controller in the CPC. Please refer to DB2Data Sharing: Planning and Administration for details.

6.3 Client Considerations

Remote DRDA clients need to know the following information to connect to the DB2 forOS/390 subsystem server:


• The host name or the IP address of the TCP/IP instance used by DB2 for OS/390

• The TCP/IP port number used by DB2 for OS/390 to accept incoming DRDA SQLconnection requests. If service names are used in the AR, they must be resolved byTCP/IP on the AR platform before reaching DB2 for OS/390.

If this DB2 for OS/390 is an AS only, you do not have to specify any information on theHOSTS.LOCAL data set for remote ASs. However, if an AR connects to the AS, using a hostname, the AR must define the host name in its HOSTS.LOCAL data set (MVS platform) orthe \etc\hosts file (workstation platform), unless there is a definition for the host AS on theDNS of the AR. Figure 24 shows an example of the HOSTS file for an AR workstation.

9.12.14.207 WTSC48.ITSO.IBM.COM

Figure 24. Sample HOSTS File for an AR Workstation

Figure 25 shows an example of the HOSTS.LOCAL data set statement for an AR MVS.

HOST : 129.33.160.112 : CAYMAN.ITSO.IBM.COM

Figure 25. Sample HOSTS.LOCAL Data Set Statement for an AR MVS

If DB2 for OS/390 is only an AR, and you defined a service name in the CDB, the servicename must be defined in the ETC.SERVICES data set, with the corresponding port andInternet style. If a UDB AR connects to a DB2 for OS/390 AS, using a service name insteadof the port number, the service name must be defined in the DB2 AR \etc\services\ file withthe same port number value that is defined in the BSDS. Figure 26 is an example of aservice statement. It has the same format for the MVS and the workstation platforms.

db251 446/tcp

Figure 26. Sample Service Statement: MVS and Workstation Platforms

Please refer to Chapter 5, “DB2 for OS/390 and TCP/IP” on page 35 for more details aboutcustomizing DB2 to use TCP/IP.

Chapter 6. DB2 for OS/390 As an AS 55


Chapter 7. DB2 for OS/390 As an AR

For DB2 for OS/390 to support TCP/IP, you have to enable the DDF for OpenEdition andupdate the BSDS with the SQL port number and a resynchronization port number used byDB2 as an AS. When DB2 acts as an AR, it uses an ephemeral port number provided byTCP/IP. You do not specify to TCP/IP or in the BSDS the port number used by the DB2 forOS/390 AR. However, you must configure TCP/IP to know all of the host names or IPaddresses of the AS to which DB2 for OS/390 is allowed to connect. For the TCP/IP datasets, files, and configuration, refer to 5.3, “Defining DB2 to TCP/IP” on page 43.

7.1 CDB Tables

With DB2 for OS/390 Version 5, the CDB has been changed to support TCP/IP protocoldefinitions, and it is part of the DB2 catalog. The CDB tables have been restructured andrenamed. Thus in a data sharing environment, a down-level member can still access theold format of the CDB tables, and DB2 for OS/390 Version 5 can work with the new format.During the migration process, DB2 creates and updates the new CDB according to theinformation stored in the old CDB. The job that performs this task is in the DSNTIJSGmember of the SDSNSAMP library.

As with previous versions of DB2 you can issue SELECT, INSERT, or UPDATE statementsspecifying the CDB tables. If you update one version of the CDB (new or old), the otherversion (old or new) is not updated. If you plan to fall back, you have to update bothversions of the CDB. Maintaining the old and the new CDB structure on the same DB2eases the fallback process.

The old DSNDDF database does not exist if you install a brand new DB2 for OS/390subsystem. The objects of the DSNDDF database are now in the DSNDB06 database.

The renamed CDB tables are now located in the new SYSDDF table space:

• SYSIBM.LOCATIONS (replaces SYSIBM.SYSLOCATIONS)

• SYSIBM.LULIST (replaces SYSIBM.SYSLULIST)

• SYSIBM.LUMODES (replaces SYSIBM.SYSLUMODES)

• SYSIBM.LUNAMES (replaces SYSIBM.SYSLUNAMES)

• SYSIBM.MODESELECT (replaces SYSIBM.SYSMODESELECT)

• SYSIBM.USERNAMES (replaces SYSIBM.SYSUSERNAMES)

Table 3 on page 58 summarizes the differences between the SYSIBM.SYSLOCATIONS(Version 4) and SYSIBM.LOCATIONS (Version 5) columns.


Table 3. Differences between SYSIBM.SYSLOCATIONS and SYSIBM.LOCATIONS Columns

SYSIBM.SYSLOCATIONS SYSIBM.LOCATIONS Observation

LOCATION LOCATION Same

LOCTYPE Suppressed in V5

LINKNAME LINKNAME Same

LINKATTR TPN Renamed in V5

IBMREQD Added in V5

PORT Added in V5

Table 4 summarizes the differences between the SYSIBM.SYSLUNAMES (Version 4) andSYSIBM.LUNAMES (Version 5) columns.

Table 4. Differences between SYSIBM.SYSLUNAMES and SYSIBM.LUNAMES Columns

SYSIBM.SYSLUNAMES SYSIBM.LUNAMES Observation

LUNAME LUNAME Same

SYSMODENAME SYSMODENAME Same

USERSECURITY Suppressed in V5

SECURITY_IN Added in V5

SECURITY_OUT Added in V5

ENCRYPTPSWDS ENCRYPTPSWDS Same

MODESELECT MODESELECT Same

USERNAMES USERNAMES Same

GENERIC GENERIC Same

IBMREQD Added in V5

Although not relevant to TCP/IP, Table 5 summarizes the differences betweenSYSIBM.SYSLUMODES (Version 4) and SYSIBM.LUMODES (Version 5) columns.

Table 5 (Page 1 of 2). Differences between SYSIBM.SYSLUMODES and SYSIBM.LUMODESColumns

SYSIBM.SYSLUMODES SYSIBM.LUMODES Observation

LUNAME LUNAME Same


Table 5 (Page 2 of 2). Differences between SYSIBM.SYSLUMODES and SYSIBM.LUMODESColumns

SYSIBM.SYSLUMODES SYSIBM.LUMODES Observation

MODENAME MODENAME Same

CONVLIMIT Suppressed in V5

AUTO Suppressed in V5

IBMREQD Added in V5

The following tables are new:

• SYSIBM.IPNAMES

• SYSIBM.SYSDUMMY1 (resides in the table space of the SYSSTR catalog)

Most all of the referential constraints among the CDB tables in Version 4 no longer exist.The only referential constraint that still exists is that SYSIBM.LULIST, SYSIBM.LUMODES,and SYSIBM.MODESELECT are dependent on the SYSIBM.LUNAMES table.

To use a TCP/IP connection, you have to populate at least the SYSIBM.LOCATIONS andSYSIBM.IPNAMES tables. In addition, if you are using outbound translation, you have topopulate the SYSIBM.USERNAMES table.

7.1.1 SYSIBM.LOCATIONS

SYSIBM.LOCATIONS defines the remote DRDA AS that the DB2 where this CDB is locatedcan access, using TCP/IP or APPC:

• The LOCATION column of this table specifies the location name of another DB2 in theMVS platform or an alias name of a UDB. The value specified in this column is used inthe CONNECT statement or for remote binds. There is a unique type 2 index on theLOCATION column.

• For APPC-only connections, the LINKNAME column specifies the LU name of the partnerLU. For TCP/IP-only connections, the value specified is only a pointer to theSYSIBM.IPNAMES table. If you are enabling TCP/IP and APPC connections with thispartner, you must specify in the LINKNAME column the LUNAME of the partner. If youenable both connections (TCP/IP and APPC), for DRDA connections TCP/IP is used.

• The PORT column contains the 1—5 digit TCP/IP port number or the service nameassociated with the remote AS. For TCP/IP connection to an AS, the DB2 AR checks fora value in the PORT column. If blank, the default is the DRDA 446 port number. ForAPPC connections this column is ignored.

• The TPN column is not used for TCP/IP connections. It is used only for APPCconnections, and it specifies the transaction program name that must be invoked on the

Chapter 7. DB2 for OS/390 As an AR 59

AR. The default is X′07′6DB. This column is equivalent to the LINKATTR column of theold SYSIBM.SYSLOCATIONS table.

Table 6 shows sample definitions required for SYSIBM.LOCATION to access a UDB server.The first row shows the PORT column using the port number and the second shows thePORT column using the service name.

Table 6. SYSIBM.LOCATIONS Definitions: Port Number and Service Name

Location Linkname Port

SAMP2 SC02089I 30000

SAMPN SC02009I db2cn

Note that these rows must be for different location names.

Enabling DB2 for mixed network mode connections, that is, configuring the CDB for bothSNA and TCP/IP, is discussed in Chapter 11, “Mixed Mode Connections” on page 115.

7.1.2 SYSIBM.IPNAMES

SYSIBM.IPNAMES contains information related to the remote DRDA AS accessed by usingTCP/IP.

• The LINKNAME column must match the value specified in the LINKNAME column of theassociated row in the SYSIBM.LOCATIONS table. There is a unique type 2 index on theLINKNAME column.

• The IPADDR column contains the IP address or host name of the remote TCP/IP host. Ifa host name is specified in this column, it must also be defined in the HOSTS.LOCALdata set, the hierarchical file system (HFS), or the DNS.

• The SECURITY_OUT column specifies the DRDA security option to use when connectingto the AS. A connection request can contain only the authorization ID (value A), a RACFPassTicket (value R), or authorization ID and a password (value P).

• In the USERNAMES column you specify whether you want outbound translation (valueO) when connecting to the AS. If you specify the value P for the SECURITY-OUTcolumn, you must specify the value O for the USERNAMES column in this table. If youspecify the value O for the USERNAMES column, you must populate theSYSIBM.USERNAMES table with appropriate values.

Note that, in contrast to APPC, you can have only outbound translation; inbound translationfor TCP/IP is not supported.


Table 7 on page 61 shows sample definitions for the SYSIBM.IPNAMES table to access aUDB server. The first row shows the IPADDR column using an IP address, and the secondrow shows a host name instead of an IP address.

Table 7. SYSIBM.IPNAMES Definitions Using IP Address and Host Name

Linkname SECURITY_OUT USERNAMES IPADDR

SC02089I A O 129.33.160.112

SC02009I A O YAP.ITSO.IBM.COM

Note that these rows must refer to different location names.

7.1.3 SYSIBM.LUNAMES

SYSIBM.LUNAMES is used for APPC connections only. This table must contain a row foreach SNA client or server that communicates with DB2.

For DB2 for OS/390 Version 5, the following columns are new:

• SECURITY_IN, which specifies security requirements for incoming requests. Aspecification of A indicates that a user ID, a user ID and a password (or RACFPassTicket), or a DCE ticket is accepted. A specification of V indicates that a user IDand a password (or PassTicket) or a DCE ticket is accepted.

• SECURITY_OUT, which specifies security requirements for outgoing requests. Aconnection request can contain only the authorization ID (value A), a RACF PassTicket(value R), or authorization ID and a password (value P).

Figure 27 shows the relationship among the SYSIBM.LOCATIONS, SYSIBM.IPNAMES, andSYSIBM.LUNAMES tables.

Figure 27. Relationship among SYSIBM.LOCATIONS, SYSIBM.IPNAMES, and SYSIBM.LUNAMES


7.1.4 SYSIBM.USERNAMES

For TCP/IP connections, the SYSIBM.USERNAMES table is used only if you specifiedoutbound translation.

• The TYPE column specifies which type of translation is to be performed. Valid valuesfor this column are: I for inbound translation or O for outbound translation. Each row inthis table indicates one type of translation. TCP/IP uses only rows with the specificationof O.

• The AUTHID column is the local authorization ID. If this column is left blank, thetranslation applies to every authorization ID.

• The LINKNAME column must match the LINKNAME column of SYSIBM.LOCATIONS.

• The NEWAUTHID and the PASSWORD columns are, respectively, the authorization IDand the password to be sent during the connection process. If you are using RACFPassTickets to connect to the AS, you do not have to specify the password in thePASSWORD column; DB2 for OS/390 obtains a PassTicket from RACF.

Table 8 shows sample definitions for the SYSIBM.USERNAMES to access a UDB server.The first row refers to a specific authorization ID, and the second row refers to allauthorization IDs.

Table 8. SYSIBM.USERNAMES Definitions

Type AUTHID LINKNAME NEWAUTHID

O DIANA SC02089I POL

O SC02089I DB2

Changes to the SYSIBM.USERNAMES table take effect at the next thread access. Changesto the SYSIBM.LOCATIONS and SYSIBM.IPNAMES tables can take effect at the next threadaccess, as long as an AR or AS has not tried to communicate to or from the LOCATION thatyou are adding.

7.2 DB2 for OS/390 Bind

For a DB2 for OS/390 AR to be able to access data from the remote location, you mustcreate the proper package at the remote location, using the BIND command. In contrast toDB2 Connect, DB2 for OS/390 does not automatically bind sample applications, such asSPUFI, when you execute them for the first time. You must manually bind all applicationsthat access data in a remote location.

If you try to access data at a remote AS without an existing package, you get a messagesimilar to that shown in Figure 28 on page 63.


� �DSNT408I SQLCODE = -805, SQLSTATE = 51002,INVALID APPLICATION STATE FROM

OS/2 TOKENS DSNESPCS.DSNESM68� �Figure 28. Message from SPUFI Application

DB2 for OS/390 provides the following sample application programs that you can use toaccess remote sites:

• SPUFI, which enables you to execute SQL statements contained in a file

• DSNTIAUL, which enables you to unload tables from an AS into a sequential data setthat can be loaded locally or on another DB2 for OS/390

• DSNTIAD, which enables you to execute dynamic SQL statements

• DSNTEP2, which is a sample PL/I program that enables you to execute SQL statementsusing distributed unit of work (DUW).

For each sample application program you must bind the corresponding packages to the ASthat you intend to access and include the package in the local plan for that application.Sample JCL can be used to bind the programs to the AS:

• DSNTIJSG installation job member in the SDSNSAMP library is used to bind SPUFI.

• DSNTEJ2A installation job member in the SDSNSAMP library is used to bind DSNTIAUL.

• DSNTIJTM installation job member in the SDSNSAMP library is used to bind DSNTIAD.

• DSNTEJ1P sample job member in the SDSNSAMP library is used to bind DSNTEP2.

Below we present examples of binding the SPUFI application. The steps you follow differaccording to whether the AS is a DB2 for OS/390 or UDB. Refer to the samples in DB2 forMVS Connections with AIX and OS/2 for examples of binding the other DB2 for OS/390sample application programs. For more details on BIND options, refer to 7.3, “BIND OptionsAvailable in DB2 UDB Servers” on page 65.

7.2.1 Binding to the DB2 UDB AS

The BIND command is issued locally, but you must specify in the PACKAGE keyword theremote location where the package is to be created.

Figure 29 on page 64 shows the sample JCL for the SPUFI application, where SAMP2 in thePACKAGE keyword is the remote database destination of the package.


� �//******************************************************************//BIND JOB (ACCOUT#),′ DB2 V5′ , NOTIFY=DB2,// CLASS=A,MSGCLASS=T,REGION=5000K,// MSGLEVEL=(1,1)//******************************************************************//JOBLIB DD DISP=SHR,DSN=DSN510.SDSNLOAD//DSNTIAS EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(4,LT)//DBRMLIB DD DSN=DSN510.SDSNDBRM,DISP=SHR//SYSTSPRT DD SYSOUT=*//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSTSIN DD * DSN SYSTEM(DB51)BIND PACKAGE (SAMP2.DSNESPCS) MEMBER(DSNESM68) -ACT(REP) ISO(CS) SQLERROR(NOPACKAGE) VALIDATE(BIND)END� �

Figure 29. Sample JCL to Bind the Package for the SPUFI Application

A BIND PLAN command is required for the local DB2 to execute SPUFI remotely. You canuse the JCL provided in Figure 29 to bind the plan.

An alternative is to issue the BIND PLAN command before executing the BIND PACKAGE,specifying a single remote location or all locations that DB2 will access. Here is anexample of BIND PLAN to all locations:

BIND PLAN(DSNESPCS) PKLIST(*.DSNESPCS.DSNESM68) -ISOLATION(CS) ACTION(REPLACE)

The same procedure must be followed for all applications that you want to use to accessthe remote locations.

7.2.2 Binding to DB2 for OS/390 Servers

When the AS is a DB2 for OS/390, typically the packages for SPUFI and for the other sampleapplications have already been created during DB2 installation, so they are available for theAR connection. You must bind a new package for SPUFI or for other DB2 sampleapplications only if the local AR DB2 for OS/390 has a product release level different fromthe AS. In this case you must use different collection names.

Once you have bound the package on the server, you must include the package in the localAR plan.

For a sample of the BIND PACKAGE and BIND PLAN commands refer to 7.2.1, “Binding tothe DB2 UDB AS” on page 63.


7.3 BIND Options Available in DB2 UDB Servers

In this section we cover the BIND options available when binding from a DB2 for OS/390 ARto a UDB AS.

If an invalid option value is used in the BIND parameter, you receive an SQLCODE -4930from the UDB server. If an unrecognized option is used in the BIND parameter, you receivean SQLCODE -30072 from the UDB server.

Table 9 lists the available and unavailable DRDA BIND PACKAGE options, with theirrespective error codes, for binding from a DB2 for OS/390 AR to a DB2 UDB AS. The ErrorCode column lists the SQLCODES issued when the UDB server receives an invalidspecification.

Table 9 (Page 1 of 2). DRDA BIND PACKAGE Options to DB2 for OS/390

Valid Value Description Error Code

CURRENTDATA YES/NO CURRENTDATA is supportedby UDB AS.

DEGREE 1/ANY Specifies whether or not thequery is executed using I/Oparallel processing. We usedDEGREE(1) andDEGREE(ANY), and the bindof the package ended withouterrors. This option is ignoredby DB2 UDB.

EXPLAIN YES/NO EXPLAIN is ignored by UDBAS.

FLAG I/W/E/C FLAG is supported by UDBAS.

ISOLATION RS/UR/CS/RR

ISOLATION(RS) is nowsupported by UDB AS.ISOLATION(NC) is notsupported; it uses UR.

SQLCODE+ 5 9 5 forISO(NC)

ENABLE/ DISABLE ENABLE and DISABLE are notsupported for remoteprocessing.

DSNT244I byDB2 forOS/390

VALIDATE BIND VALIDATE(RUN) is notsupported by UDB AS.

SQLCODE-4930 byUDB AS

ACTION REPLACE ACTION(ADD) is notsupported by UDB AS.



7.3.1 Bind Enhancements

DB2 in the MVS platform enables you to copy local packages to remote ASs. DB2 forOS/390 Version 5 implements new bind options such as (REOPT(VARS)) and(KEEPDYNAMIC). If these options are sent to servers that do not recognize them, the bindfails. If using BIND PACKAGE COPY, any bind options not explicitly specified on thecommand (or DB2I panel) are obtained from the DB2 catalog, and all options are flowed ona remote BIND PACKAGE COPY.

If you want to flow to the server only the options explicitly specified on the BIND command(or DB2I panel), use the new OPTIONS(COMMAND) keyword.

This enhancement allows the BIND PACKAGE COPY subcommand to be extended toinclude the optional keyword:

OPTIONS(COMPOSITE|COMMAND)

Table 9 (Page 2 of 2). DRDA BIND PACKAGE Options to DB2 for OS/390

Valid Value Description Error Code

RELEASE COMMIT RELEASE(DEALLOCATE) isnot supported by UDB AS.


DYNAMICRULES RUN DYNAMICRULES(BIND) is notsupported by UDB AS.


SQLERROR NOPACKAGE SQLERROR(CONTINUE) is notsupported by UDB AS.


DEFER DEFER(PREPARE) is notsupported by UDB AS.


NODEFER NODEFER(PREPARE) is notsupported by UDB AS.


REOPT REOPT(VARS) is notsupported by UDB AS.


NOREOPT NOREOPT(VARS) is notsupported by UDB AS.


KEEPDYNAMIC KEEPDYNAMIC is notsupported by UDB AS.



The format for the new BIND PACKAGE COPY command is:

+--- BIND PACKAGE COPY OPTIONS -------------------------------------------+| || >>--BIND PACKAGE--(-.----------------.-collection-id)-----------------> || ′ -location-name.-′ || || >--.--------------------------------------------------------------.-->< || ′ -COPY(collection-id.package-id)-.--------------------------.--′ || | .-COMPOSITE-. | || ′ -OPTIONS(-′ -COMMAND---′ -)-′ || |+-------------------------------------------------------------------------+

The default for BIND PACKAGE COPY without the OPTIONS keyword is to use the bindoption values from the catalog for the copied package and those from the BIND PACKAGECOPY command (or DB2I panel) as overrides.

If you specify OPTIONS(COMPOSITE), the options of the new package are taken from theBIND PACKAGE COPY command (or DB2I panel), and those not specified are taken fromthe catalog. This is the same as the default action without the OPTIONS keyword specified.

If you specify OPTIONS(COMMAND), the options of the new package are the optionsexplicitly specified on the BIND PACKAGE COPY command (or DB2I panel). For the optionsnot specified:

• For a local copy, the DB2-defined BIND PACKAGE option defaults are used.

• For a remote copy, the server-defined BIND PACKAGE option defaults are defaulted atthe server.

The use of the OPTIONS keyword is not stored in the catalog.

The OPTIONS keyword does not flow on a remote bind, and it is valid for BIND PACKAGECOPY only. It does not affect commands for plans, REBIND, FREE, or automatic bind.

The OPTIONS keyword is included on the main BIND PACKAGE panel (DSNEBP07) of DB2I(see Figure 30 on page 68). Because it is only applicable when the COPY keyword isspecified, OPTIONS is defined below the COPY heading (see option 7). The default ofCOMPOSITE is shown here for documentation purposes only; it appears as blank when theDSNEBP07 panel is first initialized and remains blank unless you specify a value.


DSNEBP07 BIND PACKAGE SSID: DSN

COMMAND ===>

Specify output location and collection names:1 LOCATION NAME ............. ===> (Defaults to lo2 COLLECTION-ID ............. ===> LOC (Required)

Specify package source (DBRM or COPY):3 DBRM: COPY: ===> DBRM (Specify DBRM or COPY)4 MEMBER or COLLECTION-ID ===> MEM5 PASSWORD or PACKAGE-ID .. ===>6 LIBRARY or VERSION ..... ===>7 ........ -- OPTIONS ..... ===> COMPOSITE (COMPOSITE or COMMAND)Enter options as desired:8 CHANGE CURRENT DEFAULTS? .. ===> YES (NO or YES)9 ENABLE/DISABLE CONNECTIONS? ===> NO (NO or YES)10 OWNER OF PACKAGE (AUTHID).. ===> (Leave blank for primary ID)11 QUALIFIER ................. ===> (Leave blank for OWNER)12 ACTION ON PACKAGE .... .... ===> REPLACE (ADD or REPLACE)13 REPLACE VERSION ........... ===>

(Replacement version-iPRESS: ENTER to process END to save and exit HELP for more informati

Figure 30. BIND PACKAGE DSNEBP07 Panel

The DSNH COPYOPTS keyword has the following syntax:

>>--COPYOPTS--(--.-NONE------.--)--------------------------------------|-COMPOSITE-|′ -COMMAND---′

where NONE indicates that the OPTIONS keyword is not specified on BIND PACKAGEinvocation. COMPOSITE or COMMAND indicates that either COMPOSITE or COMMAND ispassed as the BIND PACKAGE OPTIONS keyword parameter.

New values are added for the existing SYSIBM.SYSPACKAGE REMOTE column, as shown inFigure 31 on page 69.


Column Name______________________________________________________________________REMOTE CHAR(1) Source of the package:

NOT NULLC package was created by BIND COPY.D package was created by BIND COPYwith the OPTIONS(COMMAND) option.

K The package was copied from a packagethat was originally bound on behalfof a remote requester.

L The package was copied with theOPTIONS(COMMAND) option from a packagethat was originally bound on behalfof a remote requester.

N package was locally bound from a DBRM.Y Package was bound on behalf of a remoterequester.

Figure 31. Catalog Changes Resulting from New OPTIONS Keyword

7.3.2 DB2 for OS/390 Connection Test

After you have populated the CDB table and bound the application packages, the DB2 forOS/390 AR can connect to the AS. Remember you must configure the AS site before doingthe connection.

In this CONNECT statement from DB2 for OS/390 to a DB2 UDB server:

EXEC SQL CONNECT TO SAMP2

SAMP2 is the server database alias defined in the UDB server and specified in the CDBtables in the DB2 for OS/390 requester.

If you are using SPUFI, the server location must be specified in the SPUFI main painel(DSNESP01), in the CONNECT LOCATION parameter. Note that if you try to use theCONNECT SQL statement in the SPUFI input data set, you get SQLCODE -084, ERROR:UNACCEPTABLE SQL STATEMENT.

The user ID and password are sent according to the CDB table definitions. Please refer toChapter 12, “Security Considerations” on page 121 for details.

If you try a connection to a remote AS at this time, without configuring the AS, you get amessage similar to this:


� � DSNL511I =DB51 DSNLIENO TCP/IP CONVERSATION FAILED

TO LOCATION SAMP2IPADDR=129.33.160.112 PORT=-30536SOCKET=CONNECT RETURN CODE=1128 REASON CODE=12F80291� �

The remote AS UDB must have the local database configured, with the right protocolsupport, before any remote connection can be successful.

7.3.3 Improving Performance for Distributed Applications

SQL statements sent to a remote server take longer to execute than they do on the localsystem because of the network traffic and the overhead of processing at the server. Toobtain better performance when accessing remote ASs, you have several options:

• Code more efficient queries. Using clauses like WHERE, GROUP BY, and HAVING, youcan reduce the number of rows in the result table that is sent back to the application.

• Bind with a different level of isolation than ISOLATION(RR) to reduce lock contention.

• Minimize the use of parameter markers. DB2 can streamline the processing of dynamicrequests that do not have parameter markers.

• Use block fetch, which optimizes data transfer because DRDA access can use limitedblock fetch. To use BLOCK FETCH, specify FOR FETCH ONLY or FOR READ ONLY inyour SQL statement.

Refer to the DB2 for OS/390 Version 5 Application Programming and SQL Guide for a moredetailed discussion on optimizing the DRDA BIND process.


Chapter 8. DB2 UDB Servers

In this chapter we describe how to configure AIX, Windows NT, and OS/2 workstations to actas DRDA ASs.

Although Windows 95 does not support server functions in either a DRDA or non-DRDAenvironment, it can act as an AR or a client, using TCP/IP, so we describe its TCP/IPconfiguration.

8.1 Network Configuration

Configuring TCP/IP is quite simple. First you have to obtain the IP address and host nameof your workstation.

For the UDB AS platforms that we are describing, the TCP/IP configuration files are usuallystored in ETC subdirectories. The services file contains all ports assigned to applicationsfor the TCP/IP connection process. DB2 UDB requires two ports: one for SQL requests andone for interrupts.

The port numbers can be any server port number assigned by the TCP/IP administrator,and the service name can be any name you choose. The service name assigned to SQLrequests must be used to update SVCENAME, the database manager configuration fileparameter for this instance. During the installation process of a DB2 UDB server, DB2prompts you to enter the port number and service name. You can accept the default portnumbers, 30000 and 30001, or use a port number of your choice. If port number 30000 orthe default service name is already defined in the etc.services file, DB2 UDB issues awarning message for you to accept them or not.

DB2 automatically adds the required entries in the services file, for both the connection andthe interrupt port.

The default service names assigned by DB2 are the concatenation of the instance namewith the string CDB2 for SQL requests or the string IDB2 for interrupts. The defaultinstance name is db2 .

8.1.1 Standards for Port Numbers and Service NamesIf you have more than one workstation acting as a server, you should establish somestandards for the port numbers and service names for your ASs. One approach is to use acommon port number and service name for all workstation servers. Here are some of theadvantages and disadvantages of this approach:

• If a new server workstation is added to the network, you only have to obtain its IPaddress and host name.


• If you require connection to a new AS workstation, all you have to know is the new hostname (or IP address).

• Administration and control of port numbers and service names are trivial tasks.

• You do not have much flexibility in terms of service names. For example, if thecommon service name is db2CDB2, you cannot differentiate an AIX platform from anOS/2 platform just by examining the service name in the SERVICES file of the AR.

• You might have just a common port number with different service names. This can beproblematic when tracking connections in a Windows NT requester, because the TCP/IPNETSTATS command always displays the first defined service name, even thoughWindows NT might be connected to an AS which the CATALOG TCPIP NODE specifiedusing a different service name.

In our environment, we chose as a standard port numbers and service names based on theworkstation platform. Figure 32, Figure 33, and Figure 34 on page 73 show the entries weplaced in the services file for the OS/2, AIX, and Windows NT AS platforms.

SERVICES FILE - OS/2

<service name> <port number>/<protocol> {comment}

db2c2 30000/tcp #UDB port for OS/2db2i2 30001/tcp #UDB resync port for OS/2

Figure 32. Service Files for OS/2 Application Server

SERVICES FILE - OS/2


db2cx 31000/tcp #UDB port for AIXdb2ix 31001/tcp #UDB resync port for AIX

Figure 33. Service Files for AIX Application Server


SERVICES FILE - Windows NT


db2cn 32000/tcp #UDB port for WIN NTdb2in 32001/tcp #UDB resync port for WIN NT

Figure 34. Service Files for Windows NT Application Server

8.1.2 Windows NTTo start configuring TCP/IP and display the Network dialog shown in Figure 35, follow thesesteps:

1. Double-click on the My Computer icon on the desktop

2. Double-click on the Control Panel icon

3. Double-click on the Network icon

Figure 35. Identification Dialog

Chapter 8. DB2 UDB Servers 73

In the Identification dialog box, specify:

• In the Computer Name field, a name of up 15 characters for this workstation and thatWindows uses to go through the network.

• In the Domain field, the name of the Windows Workgroup, which consists of thoseworkstations that must communicate with each other.

DB2 does not use the information provided in the Identification dialog box, but the value youenter in the Computer Name field is the default for TCP/IP host name.

Click on the Adapters dialog box and select the network adapters installed on thisworkstation and that will be used in the protocol configuration. In our workstation, wedefined the IBM Auto 16/4 Token-Ring ISA Adapter (see Figure 36).

Figure 36. Adapter Configuration Init ial Box


To add the adapter, click on the add push bottom and select the adapter from the NetworkAdapter list as shown in Figure 37 on page 75.

Figure 37. Adapter List

To configure the TCP/IP protocol, click on Protocols in the Identification dialog box(Figure 35 on page 73), and the Network window shown in Figure 38 on page 76 isdisplayed.


Figure 38. TCP/IP Configuration Init ial Box

Select TCP/IP Protocol from the Network Protocols dialog box and click on the Propertiesbutton, to display the Microsoft TCP/IP Properties dialog box shown in Figure 39 onpage 77.


Figure 39. TCP/IP Properties

In the Microsoft TCP/IP Properties dialog box:

1. Select the Adapter that TCP/IP wil l use from the push-down menu.

2. Click on the Specify an IP address radio button.

3. Enter the IP address assigned to this workstation network adapter in the IP Addressfield.

4. Enter the Subnet Mask and the Default Gateway IP address, if you have one.

Your network administrator can provide the information required for the IP address, subnetmask, and default gateway.

Click on the Advanced push button to display the Advanced IP Addressing window shown inFigure 40 on page 78. On the Advanced IP Addressing window you can provide more


detail on the configuration: you can add other IP addresses for the local workstation if youhave more than one adapter and provide IP addresses for gateways.

Figure 40. Advanced IP Addressing

Check the Enable Security box and click on the Configure push button to display the TCP/IPSecurity window shown in Figure 40. Through the TCP/IP Security window you controlaccess through the TCP and UDP ports of this server and enable the IP protocolconnections. Usually, you click on Permit All for all of the selections.


In the Microsoft TCP/IP Properties window (Figure 39 on page 77) click on DNS to get to theDomain Name System (DNS) dialog box shown in Figure 41 on page 79, where youconfigure the DNS for this workstation.

Figure 41. Domain Name System Dialog Box

Usually you use DNS capability if you connect to the Internet. In a complex network, DNSfunctions are delivered by a given IP router that may not be your workstation.

Other IP routing information can be provided in other dialog boxes (DHCP Relay , WINSAddress , Bindings , and Routing ), but they are not required for our basic connection.

8.1.3 Windows 95The configuration for Windows 95 is similar to that for Windows NT. To start configuringTCP/IP for Windows 95 and display the Network dialog shown in Figure 42 on page 80,follow these steps:


1. Double-click on the My Computer icon on the desktop

2. Double-click on the Control Panel icon

3. Double-click on the Network icon

Figure 42. Windows 95 Network Configuration for TCP/IP

The customization is similar to that for Windows NT. You do not specify different securitylevels for TCP, UDP, and IP addresses; you just configure the Bindings (that is, thesupported connections) as coming from Microsoft clients.

For both Windows NT and Windows 95, you cannot define the TCP/IP services graphically.You have to find the respective services files in the subdirectories. We had services fileslocated in this directory for Windows NT:

:C\WINNT\SYSTEM32

and in this directory for Windows 95:

C:\WINDOWS

After you have customized the network, Windows NT and Windows 95 prompt you to rebootthe workstation.


8.1.4 AIX Workstation

Before starting the TCP/IP configuration for AIX, you must verify that the adapter, in ourcase a token-ring adapter, is correctly configured. You must invoke the SystemManagement Interface Tool (SMIT) and select the following items:

• Devices

• Communication

• Token-Ring Adapter

• Adapter

You get a screen similar to that shown in Figure 43.

Change / Show Characteristics of a Token Ring Adapter

Type or select values in entry fields.Press Enter AFTER making all desired changes.

(Entry Fields)Token Ring Adapter tok0Description Token-Ring High-Perfor>Status AvailableLocation 00-02TRANSMIT queue size (60)RING speed 16Receive ATTENTION MAC frame noReceive BEACON MAC frame noEnable ALTERNATE TOKEN RING address yesALTERNATE TOKEN RING address (0x4000520471C5)Apply change to DATABASE only no

Figure 43. SMIT Change / Show Characteristics of a Token Ring Adapter Screen

The status of the adapter must be available. If you get a message stating that you cannotchange the adapter configuration because it is busy for other processes, issue thiscommand:

rmdev -l tok0

or:

mkdev -l tok0

If the adapter is not yet available, verify that it is listed, using the following command:


lsdev -Ccadapter

After configuring the adapter, you can now configure the TCP/IP protocol that will use it.Invoke SMIT and select the following:

1. Communications Applications and Services

2. TCP/IP

3. Minimum Configuration and Startup

When you select Minimum Configuration and Startup , you get a screen containing theavailable interfaces, similar to that shown in Figure 44.

TCP/IPMove cursor to desired item and press Enter

Minimum Configuration & StartupFurther Configuration

Available Network Interfaces

Move cursor to desired item and press Enter.

en0 Standard Ethernet Network Interfaceet0 IEEE 802.3 Ethernet Network Interfacetr0 Token Ring Network Interface

F1=Help F2=Refresh F3=CancelF8=Image F10=Exit Enter=Do/=Find n=Find Next

Figure 44. SMIT TCP/IP Screen

In our environment, we selected the Token Ring Network Interface and customized theTCP/IP protocol as shown in Figure 45 on page 83.


Minimum Configuration & Startup

To Delete existing configuration data, use Further Configuration Menu

Type or select values in entry fields.Press Enter AFTER making all desired changes.

{Entry Fields}* HOSTNAME {cayman}* Internet ADDRESS (dotted decimal) {129.33.160.198}Network MASK (dotted decimal) {255.255.255.0}

* Network INTERFACE tr0NAMESERVER

Internet ADDRESS (dotted decimal) {129.33.72.254}DOMAIN Name {almaden.ibm.com}

Default GATEWAY Address {129.33.160.254}(dotted decimal or symbolic name)RING Speed {16}START Now no

F1=Help F2=Refresh F3=Cancel F4=ListEsc+5=Reset F6=Command F7=Edit F8=ImageF9=Shell F10=Exit Enter=Do

Figure 45. SMIT Min imum Configuration and Startup Screen

You must define the TCP/IP services ports in use by the applications and subsystems (asthe UDB database manager) on your AIX workstation. Go back to the TCP/IP screen andselect the following:

1. Further Configuration

2. Client Network Services

3. Services (/etc/services)

4. Add a Service

A screen similar to that shown in Figure 46 on page 84 is displayed.


Add a Service

Type or select values in entry fields.Enter.Press Enter AFTER making all desired changes.List All Services

{Entry Fields}* Official Internet SERVICE Name {db2cx}* Transport PROTOCOL tcp* Socket PORT number {31000}Unofficial Internet SERVICE NAMES {}(separate names with blanks)

F1=Help F2=Refresh F3=Cancel F4=ListEsc+5=Reset F6=Command F7=Edit F8=ImageF9=Shell F10=Exit Enter=Do

Figure 46. SMIT Add a Service Screen

In our environment, the Official Internet SERVICE Name is db2cx, the Transport PROTOCOLis tcp, and the Socket PORT number is 31000.

You do not have to restart TCP/IP or reboot the AIX workstation after you finish theconfiguration. In this environment, updates are dynamically configured.

8.1.5 OS/2 Warp Workstation

For the OS/2 Warp workstation, the SERVICES and HOSTS files are in the C:\MPTN\ETCpath. TCP/IP for OS/2 is not shipped as part of the product, it is ordered and installedseparately. To display the TCP/IP Configuration window shown in Figure 47 on page 85click on the:

1. OS/2 System icon

2. TCP/IP icon

3. TCP/IP Configuration icon


Figure 47. TCP/IP Configuration in OS/2

In the Network dialog box, you configure the interfaces owned by the local machine and theassociated IP addresses. You must specify the subnet mask.

Clicking the right arrow, you get the Routing dialog box where you can provide routinginformation.

The other dialog boxes are not related to DRDA implementations. They must be configuredwhen users request other types of TCP/IP support.

When you finish configuring TCP/IP, you are prompted to make the changes effective on thehard disk. You do not have to start TCP/IP again. Whenever you start TCP/IP on OS/2, usethe TCPSTART command. Note that there is not a TCPSTOP command. A TCPSTARTcommand stops and restarts TCP automatically. For product information, refer to the“Introduction to TCP/IP” online manual provided with the product.

8.2 UDB Configuration

Once you have completed the network configuration you must update the databasemanager configuration file and assign values to the DB2COMM environment variable.


8.2.1 Database Manager Configuration File

If during installation you did not specify information about the service name used by theDB2 UDB AS, issue the following command:

UPDATE DATABASE MANAGER CFG USING SVCENAME svcename

where svcename is the service name or the port number specified in the ETC/SERVICES filefor SQL requests. In our environment we specified service name db2c2 on the OS/2platform. Instead of the service name, you can specify the port number (30000).

Note that you do not specify in the database manager configuration file the service name orthe port number for interrupts.

DB2 UDB sets the authentication requirements at the instance level for local databases. Toupdate the authentication in the database manager configuration file, use the followingcommand:

UPDATE DATABASE MANAGER CFG USING AUTHENTICATION authentication

where authentication can be CLIENT or SERVER. Specify CLIENT if all the requesters aretrusted. Specify SERVER to accept only requests with a valid user ID and password.

To check the information in the database manager configuration file, use the followingcommand:

GET DATABASE MANAGER CONFIGURATION

Refer to 12.5.1, “DB2 UDB Server Authentication” on page 131 for details about theauthentication process.

8.2.2 DB2COMM Environment Variable

For UDB servers you must set the DB2COMM environment variable with appropriate values.During startup, UDB obtains the values of DB2COMM to determine which protocols areenabled. To enable TCP/IP in a UDB server, you must specify TCPIP in the DB2COMMstatement:

DB2SET DB2COMM=TCPIP

This command enables TCP/IP until you issue another DB2SET or SET DB2COMMcommand. SET DB2COMM has the same function as DB2SET, but it is reset at the nextoperating system reboot.

You can define several communication protocols when you issue the DB2SET or SETDB2COMM commands. For example, to enable APPC, IPX, NetBIOS, and TCP/IP issue thefollowing command:

DB2SET DB2COMM=APPC,IPX,NETBIOS,TCPIP.


You can also specify the values for the DB2COMM environment variable in the CONFIG.SYSfile for OS/2, Windows NT, and Windows 95. For AIX, you specify the value of theDB2COMM environment variable in the PROFILE file. The DB2SET and SET DB2COMMcommands override the value specified in these files.

The DB2COMM statement is not part of the database manager or database configurationfiles.

8.2.3 Aliases

When a DRDA AR connects to a UDB AS, it passes the alias name of the database to whichit wants to connect. This database alias name should exist in the UDB server. If you haveseveral workstations that have the same alias name for different databases and you usethat name in your DB2 for OS/390 AR, you will be able to connect to only one of thedatabases in one workstation because the LOCATION column of the SYSIBM.LOCATIONtable is unique in a DB2 for OS/390 and the alias name is unique in the system databasedirectory of the workstation. If you plan to access all databases from a DB2 for OS/390 AR,you have to define different aliases for the same database name. On OS/2, Windows NT,Windows 95, and AIX UDB platforms, you define aliases by issuing the following command:

CATALOG DATABASE database-name AS alias-name

You can also use the Command Center to define aliases.

The UDB provides the SAMPLE database. In our environment we created the followingaliases for the SAMPLE database:

CATALOG DATABASE SAMPLE AS SAMP2 (OS/2 server)CATALOG DATABASE SAMPLE AS SAMPN (Windows NT server)CATALOG DATABASE SAMPLE AS SAMPX (AIX server)



Chapter 9. Universal Database As an Application Requester

In this chapter we describe how to configure the UDB as an AR that uses TCP/IP protocols.We assume that TCP/IP support has already been configured.

DB2 Connect is the UDB product that enables DRDA AR functions. The configuration issimilar to all platforms supported by DB2 Connect. In this chapter we describe therequirements for an OS/2 AR to connect to a DB2 for OS/390 AS. The requirements for theAIX, Windows NT, and Windows 95 platforms are similar.

9.1 Configuring the Hosts File

If the UDB AR connects to the AS by using a host name, the AR must define the host namein the hosts file, unless there is a definition for the host AS on DNS. In the hosts file youassociate a server IP address with a host name so that you can reference the server by ahost name instead of an IP address.

Figure 48 is an example of an entry in the hosts file for our MVS system.

9.12.14.207 WTSC48.ITSO.IBM.COM

Figure 48. Sample Hosts File Entry

The format shown in Figure 48 is valid for OS/2, AIX, Windows NT, and Windows 95platforms.

You can define different host names with the same IP address in the same clientworkstation so that you can connect to the same server with different host names. Eachconnection might have different characteristics. If you catalog the same server withdifferent host names, you might have some problem when monitoring the connectionsbecause some statistic command, such as the HOST command, shows the first host namewith the common IP address defined in the \etc\hosts file.

The hosts file is typically located in the \etc subdirectory on the drive where TCP/IP isinstalled. For the OS/2 platform, this file is usually in the \mptn\etc directory; for theWindows NT platform, in the \winnt\system32\drivers\etc subdirectory; for the Windows 95platform, in the \windows directory; and for the AIX platform, in the \etc directory.

UDB Version 5 also provides support to specify directly the IP address of the server whencataloging the TCPIP node.

Note that the host name is resolved into an IP address using the hosts file on thisworkstation or by a DNS before reaching the final host.


9.2 Configuring the Services File

In this version of UDB, for TCP/IP DRDA connections to DB2 for OS/390 the service nameand port number work as follows:

• If you specify a port number when using the CATALOG TCPIP NODE command, you donot have to define the port number in the services file.

• If you specify a service name when using the CATALOG TCPIP command and there isno corresponding definition in the services file, UDB assumes the 446 port number. Ifthe DB2 for OS/390 subsystem that you want to connect is not defined with this portnumber in its BSDS, but another DB2 subsystem is using the 446 port number, theresults are unpredictable.

• If you specify a service name when using the CATALOG TCPIP command and there is acorresponding definition in the services file, UDB uses the definition as specified in theservices file.

• If you are using the DB2 Client Configuration Assistant tool, you must specify a portnumber and optionally a service name.

− If you specify a service name that is not defined in the services file, DB2 UDBcreates two entries in the services file: one entry for the specified service name andport number, and one entry for the interrupt. The port number for the interrupt isequal to the specified port number plus 1.

− If you specify a service name that is defined in the services file, DB2 UDB checkswhether the port number specified on the DB2 Client Configuration Assistant toolmatches the number in the services file. If it does not match, an error message isdisplayed.

In the services file you associate a service name with a port number and Internet style. Inprevious releases of UDB, for non-DRDA TCP/IP connections you had to add two entries inthe services file of the client for TCP/IP as shown in Figure 49.

db2cm 33000/tcp # Connect port for DB2

db2im 33001/tcp # Interrupt port for DB2

Figure 49. Sample Client Services File Entry

The services file is typically located in the \etc subdirectory on the drive where TCP/IP isinstalled. For the OS/2 platform, it is usually in the \mptn\etc directory; for the Windows NTplatform, in the \winnt\system32\drivers\etc subdirectory; for the Windows 95 platform, inthe \windows directory; and for the AIX platform, in the \etc directory. The entries inFigure 49 are valid for the OS/2, AIX, Windows NT, and Windows 95 platforms.


You can define different service names with the same server port number on the sameclient workstation. You might take this approach if you have different servers but yourorganization′s standard is that all servers on different machines must use the same portnumber. This approach enables you to use the same port number but to specify the type ofserver in the service name. If you catalog the different service names with the same portnumber, you might have a problem when monitoring the connections because somecommands, such as the NETSTAT command, show the first service name with the commonport number defined in the \etc\services file.

Note that the service name is resolved into a port number before the request leaves theworkstation. For this reason, the service name specified in the services file does not haveto match the service name specified on the DRDA AS.

9.3 Catalog Process in the UDB Directories

To catalog the AS in the UDB directories, you can use the DB2 Client ConfigurationAssistant tool for OS/2, Windows NT, and Windows 95 or the command line processor (CLP)command.

The syntax of the commands is the same for the OS/2, AIX, Windows NT, and Windows 95platforms.

9.3.1 Cataloging the Database for OS/2, Windows NT, and Windows 95

In this section we use the OS/2 Client Configuration Assistant tool to illustrate the nextsteps, but there are similar windows in the Client Configuration Assistant for Windows NTand Windows 95.

In our environment the AIX platform does not have tool similar to the Client ConfigurationAssistant tool, so we had to use CLP.

To catalog the information about the DB2 for OS/390 AS, perform the following steps:

1. Click on the DB2 program icon.

2. Click on the Client Configuration Assistant tool icon to get to the main window of theclient Configuration Assistant tool, where you can update, configure, add, and deleteyour servers (Figure 50 on page 92).

Chapter 9. Universal Database As an Application Requester 91

Figure 50. Client Configuration Assistant

3. Click on the Add push button to add a new database server configuration. The AddDatabase SmartGuide window shown in Figure 51 on page 93 is displayed.

On this window you select how you want to configure the connections to the serverdatabase. You can configure manually or use a previously cataloged configuration.


Figure 51. Add Database SmartGuide: Step 1

4. Check the Manually configure a DRDA connection to a database radio button of theSource dialog box.

5. Click on the Next push button to display the Protocol dialog box shown in Figure 52 onpage 94.

On this window you can select the type of operating system of the database server andchoose the communication protocol to be used.



6. Select MVS/ESA for the Operation system field and check the TCP/IP radio button to usethe TCP/IP communication protocol.

7. Click on the Next push button to display the TCP/IP dialog box shown in Figure 53 onpage 95.

Use the information provided on this window to catalog the node directory.



8. Enter the host name or IP address of the server database in the Hostname field.

You can enter the service name in the the Service Name field, which is an optional fieldthat we did not use. Refer to 9.2, “Configuring the Services File” on page 90 for anexplanation of this field.

9. Enter the server ′s port number in the Port number field.

The default node name is TCPnnnnn, where nnnnn is a sequential number. If you donot want to use this name, you have to catalog the node, using the CLP commands.

10. Click on the Next push button to display the Target Database dialog box shown inFigure 54 on page 96.

On this window you specify the DB2 for OS/390 location as stored in the BSDS of theAS.



11. Enter the location name in the Target Database field.

12. Click on the Next push button to display the Alias dialog box shown in Figure 55 onpage 97.

13. On this window you specify the alias name for the database. This name is used in theconnect statement.



14. In the Alias field, enter the alias name by which the database is known in this ARworkstation.

15. Optionally enter a description in the Description field.

16. If you click on the Next push button, you have the option of using ODBC to process thisAS, as shown in Figure 56 on page 98.



17. Click on the Done push button to display the Confirmation window shown in Figure 57.

On this window you can test the connection to the AS you have just configured.

Figure 57. Window for Testing the Connection

18. Click on the Test push button, and the Client Application Enabler/2 window shown inFigure 58 on page 99 is displayed. On this window you specify authenticationinformation.


Figure 58. User ID and Password Confirmation Window

19. In the Database field, select the alias for the database you have just configured.

20. Enter a user ID known to the OS/390 AS, in the User ID field.

21. Enter the corresponding password for the user ID, in the Password field.

22. Click on the Share radio button.

23. Click on the OK push button to check for connectivity. You get a message indicatingthat the connection was successful.

24. After testing, click on the OK push button, and the Client Configuration Assistantwindow shown in Figure 59 on page 100 is displayed.

Note on this window that the newly configured database is also displayed in theAvailable DB2 Databases list.


Figure 59. Client Configuration Assistant: End of Configuration

25. Click on the Close push button to exit the Client Configuration Assistant tool.

When you use the Manually configure a DRDA connection to a database option, the defaultvalue for the AUTHENTICATION parameter is DCS. If you need to change this value, youhave to manually uncatalog and recatalog the node.

9.3.2 Cataloging the TCP/IP Node for UDB, Using CLP

You can catalog the TCP/IP node in the node directory, using the following command:

catalog tcpip node tcpm remote 9.12.14.207 server 446

where:

tcpm is the node name identifying the AS. You cannot have the same node name fordifferent server sites.

9.12.14.207 is the IP address of the server

446 is the port number of the server


The IP address and port number must be defined in TCP/IP for MVS data sets at the serversite.

You can also use the host name instead of the IP address and use a service name insteadof a port number. For example:

catalog tcpip node tcpm remote wtsc48 server db2cm

To verify that the node entry was correctly cataloged, use the following command:

LIST NODE DIRECTORY

Figure 60 shows the output of this command.

� � Node Directory

Number of entries in the directory = 1

Node 1 entry:

Node name = TCPMComment =Protocol = TCPIPHostname = 9.12.14.207Service name = 446� �

Figure 60. Output of the LIST NODE DIRECTORY Command

To uncatalog a node, use the UNCATALOG NODE command.

9.3.3 Cataloging a Database in the System Database Directory, Using CLP

The system database directory contains an entry for every database that you can accessfrom this workstation. It stores information such as the node on which the databaseresides, the name by which the database is known on this workstation, and where securityauthentication takes place. You can use the following command to catalog a database inthe system database directory:

catalog database db51t as db51t at node tcpm authentication dcs

where:

The first db51t is the database name. For a DRDA connection, it is a pointer to the DCSdatabase directory entry. The DCS database entry describes the name by which thedatabase is known on the MVS system (the location name).

The second db51t is the alias name by which this database is known in this workstation.It is the name that you use in the CONNECT statement.


In our case, we used the same name for the database and alias names, but you canuse different names.

tcpm must match the node name you specified when you cataloged the TCP/IP node.

dcs is the authentication type. Other options are covered in Chapter 12, “SecurityConsiderations” on page 121.

The authentication type for each remote database determines how and where a user isauthenticated.

DCS specifies that the userid and password are sent to the DRDA AS to be authenticatedthere. To verify that the database entry was correctly cataloged, use the followingcommand:

LIST DATABASE DIRECTORY


� � System Database Directory


Database 1 entry:

Database alias = DB51TDatabase name = DB51TNode name = TCPMDatabase release level = 8.00Comment =Directory entry type = RemoteAuthentication = DCSCatalog node number = -1� �

Figure 61. Output of the LIST DATABASE DIRECTORY Command

To uncatalog a database, use the UNCATALOG DATABASE command.

9.3.4 Cataloging the DCS Database for UDB

The DCS directory stores information about the DRDA AS. For every remote databaseaccessed through DRDA, a DCS database must be cataloged. You can use the followingcommand to catalog a DCS database:

catalog dcs database db51t as db51

where:


db51t is the database name by which the DB2 subsystem is known to this workstation.It must match the database name used in the CATALOG DATABASE command.

db51 is the target database name by which the DB2 subsystem is known to the OS/390system. It must match the location name stored in the BSDS of the DB2 for OS/390subsystem.

To verify that the DCS database entry was correctly cataloged, use the following command:

LIST DCS DIRECTORY


� � Database Connection Services (DCS) Directory


DCS 1 entry:

Local database name = DB51TTarget database name = DB51Application requestor name =DCS parameters =Comment =DCS directory release level = 0x0100� �

Figure 62. Output of the LIST DCS DIRECTORY Command

To uncatalog a DCS database, use the UNCATALOG DCS DATABASE command.

9.3.5 Testing the TCP/IP Connection

After you have configured both the workstation and the AS, you can test the TCP/IPconnection. Use the following command, in the CLP, to connect to the remote AS:

connect to database user userid using pssword

where:

• database is the alias database that you cataloged. Refer to Chapter 9.3, “CatalogProcess in the UDB Directories” on page 91 for details.

• userid and password should be a valid userid and password defined in the MVS systemto which you are connecting. Refer to Chapter 12, “Security Considerations” onpage 121 for details.

Here is an example of the CONNECT statement to connect an OS/2 workstation to DB2 forOS/390:


connect to db51t user db2 using db2

To reset a connection, use the CONNECT RESET statement.

9.4 Binding Packages to DB2 for OS/390

After a successful connection, you must bind some packages into the server DB2 for OS/390database. The DB2 UDB is shipped with various utilities, such as import, export, and DB2CLI, that have bind files that must be bound to each DRDA AS in which they are used. Thebind files are grouped together in different files with an extension of .lst that are specific toeach DRDA AS platform.

Table 10 shows the DRDA AS platforms and their associated .lst files. The list files are inthe \SQLLIB\BND subdirectory.

Table 10. Bind List Files

DRDA AS Name

OS/390 ddcsmvs.lst

VSE ddcsvse.lst

VM ddcsvm.lst

OS/400 ddcs400.lst

common server db2ubind.lst bs2cli.lst db2cliv1.lst

Here is an example of binding the utilities packages by using the list file for the OS/390DRDA AS:

connect to db51t user db2 using db2

bind @ddcsmvs.lst blocking all grant public

Before you execute the BIND command, you must connect to the AS to which you intend tobind the files. If you do not bind the DB2 UDB server utilities packages into DB2 for OS/390,the first time you use them, the DB2 UDB server automatically binds all of the utilitiespackages by using a specific bind list file according to the platform of the DRDA AS.Because the underlying bind process is executed before the SQL statement, the reply forthe SQL statement may take a long time.

Note: The automatic bind process is valid for SELECT SQL statements only. It is not validfor other DML or DDL statements.


Here is an example of the message you get when you try to access remote data before youhave bound the DB2 UDB server utilities package:

SQL0805N Package ″NULLID.SQLC2BA3″ was not found. SQLSTATE=51002



Chapter 10. Data Sharing Considerations

In this chapter we describe how to customize DB2 for OS/390 and explain how it works in adata sharing environment. We present scenarios where the DB2 data sharing member is anAR and where the DB2 data sharing group is an AS having as an AR a workstation or aDB2 non-data sharing subsystem.

10.1 DB2 for OS/390 Data Sharing As an Application Requester

When any DB2 member acts as a DRDA AR, it uses an ephemeral TCP/IP port number.Because ephemeral ports are uniquely assigned to processes within a TCP/IP instance,each DB2 member can successfully connect to the DRDA AR. There are no furtherconsiderations when a member of a data sharing group is an AR, because the transactionexecutes in only one member.

10.2 DB2 for OS/390 Data Sharing As an Application Server

Depending on how you configure the data sharing group AS and the ARs you can connectto any member of the group.

DB2 ARs require a single-system image of the DB2 data sharing group, where the AR doesnot need to be aware that multiple data sharing members exist. To accommodate thisneed, all members have a common location name. All members also must have the sameTCP/IP port number for incoming DRDA SQL requests, so that TCP/IP socket calls cantransparently connect DB2 ARs to any member of the DB2 data sharing group. However,for resynchronization, each member has its own unique resync port number, which allows itto handle outstanding resync requests, even if it is started on another MVS system.

You can have a DB2 data sharing group with one or more members acting as an AS. If aDB2 data sharing group has only one member, it works as a non-data-sharing DB2subsystem. If you have a non-data-sharing DB2 subsystem in a Sysplex environment, or adata sharing group with only one member, you can set up your DNS with multiple entriesfor the same host name. Each entry points to an MVS-specific IP address. If the AR usesthe common host name, it can connect to the DB2 susbsystem or the member of the datasharing AS group regardless of the MVS where the AS is running.

When defining the DB2 for OS/390 data sharing AS in the AR, you must use the commonlocation name for the group, which is defined in the BSDS of each DB2 member.


10.3 Scenarios

In this section we describe some scenarios that we tested during our project. For thesescenarios we assume that there are two DB2 members in the data sharing group (DBC1and DBC2). You may have more than one IP address for a given host name if you havemore than one network adapter on the same MVS, but for our scenarios we assume thatthere is just one IP address for each host name.

10.4 Each Member on a Different MVS: Common Host Name

If each member is running on a different MVS, each MVS system has a different host nameand a different IP address. In this case, you should configure the DNS server with multipleentries with a new host name, each entry pointing to the MVS-specific IP address. If the ARuses the common host name, the AR can connect to any member of the data sharing group.Specify this host name to populate the SYSIBM.IPNAMES table of the DB2 for OS/390 AR orspecify it when cataloging the node directory of the UDB AR. We strongly recommend thatyou set up your SYSIBM.IPNAMES such that you use a common host name that applies toall members of the Sysplex. This naming convention is consistent with the WLM Sysplexbalancing support that will be shipped with TCP/IP, DNS, and WLM in next releases. We donot recommend that you hard code the IP addresses of the Sysplex on the AR or use asingle host name of one of the systems.

10.4.1 How Connection WorksIf the AR is DB2 for OS/390, all connections are directed to just one member of the datasharing group. If the AR is running on the same MVS as one of the members, it connects tothat member. If the AR is running on a different MVS, it connects to the first memberconfigured in the DNS.

If the AR is a DB2 UDB, the connections are distributed among the AS.

10.4.2 One DB2 Member QuiescedIf you quiesce one of the members, all new connections are directed to the active members,regardless of the AR.

10.5 Each Member on a Different MVS: DNS Not Configured

If each member is running on a different MVS, each MVS system has a different host nameand a different IP address. If you do not configure the DNS as explained in 10.4, “EachMember on a Different MVS: Common Host Name,” you have the following configurationoptions for the AR:

For a DB2 Connect AR, you have to specify the host name or IP address of one of themembers when cataloging the node directory. If you specify the host name, it must beresolved into the IP address before reaching the host DRDA AS. Specify an entry in the


hosts file. If in the host file you specify two entries for the same host name, each pointingto the IP address of a different member, and you use this host name when cataloging theTCP/IP node directory, DB2 Connect can only connect to the first IP address specification.As a consequence, in contrast to using a DNS, this technique does not give youtransparency of the member that DB2 Connect uses as an AS.

For a DB2 for OS/390 AR, you can define in the HOSTS.LOCAL data set both IP addresseswith the same host name. If your TCPIP.DATA data set has the same high level qualifier asdefined in the DATASETPREFIX statement in the TCPIP.PROFILE data set, you must add inthe DDF startup procedure the DD JCL statement for //SYSTCPD pointing to yourTCPIP.DATA data set.

If you do not have the correct TCPIP.DATA data set specified in the DDF startup procedure,you get the message shown in Figure 63 during connection execution.

� �DSNE625I CONNECT TO LOCATION DSGC PERFORMED, SQLCODE IS 904DSNT408I SQLCODE = -904, ERROR: UNSUCCESSFUL EXECUTION CAUSED BY AN

UNAVAILABLE RESOURCE. REASON 00D31058, TYPE OF RESOURCE00001007, AND RESOURCE NAME SCPDSGC.′ DB2PLEX.ITSO.IBM.COM′ . 1

DSNT418I SQLSTATE = 57011 SQLSTATE RETURN CODEDSNT415I SQLERRP = DSNLIDNS SQL PROCEDURE DETECTING ERRORDSNT416I SQLERRD = 0 0 0 -1 0 0 SQL DIAGNOSTIC INFORMATIONDSNT416I SQLERRD = X′00000000′ X′00000000′ X′00000000′ X′ FFFFFFFF′

X′00000000′ X′00000000′ SQL DIAGNOSTIC INFORMATION� �Figure 63. Connection Error

where:

REASON CODE 00D31058 indicates that the host name has not been found.

DB2PLEX.ITSO.IBM.COM is the fully qualified name, defined in the HOSTS.LOCAL data setpointing to both IP addresses, that could not be translated (not found).

For details of the HOSTS.LOCAL data set and DB2DIST startup procedure, refer toChapter 6, “DB2 for OS/390 As an AS” on page 51.

10.5.1 How Connection WorksFor a DB2 Connect AR, you can connect to only one of the members. The member that youcan connect to is the member cataloged with the IP address or, if you are using a hostname, the first host name specified in the hosts file.

If the AR is DB2 for OS/390, all connections are directed to just one of the members of thedata sharing group.

Chapter 10. Data Sharing Considerations 109

10.5.2 One DB2 Member QuiescedIf you quiesce one of the members, no new connections are allowed for the DB2 ConnectAR. For a DB2 for OS/390 AR, connections are directed to the other member if you havespecified a host name in the SYSIBM.IPNAMES table of the AR, and in the HOSTS.LOCALdata set the host name has entries for both IP addresses.

10.6 Resynchronization

If one of the members fails while a transaction is in-flight, any new connections are directedto the active members for all described implementations if the AR is DB2 for OS/390. If theAR is a DB2 Connect, new connections are directed to active members as long as you haveconfigured the implementation as described in 10.4, “Each Member on a Different MVS:Common Host Name” on page 108.

When the failing member is restarted, the updates for the in-flight transaction are rolledback.

In contrast to APPC, new connections for the active members are accepted regardless ofwhether you are using CONNECT TYPE 1 or CONNECT TYPE 2, as long as there are noin-doubt units of work. APPC only has a restriction when you use VTAM generic resources.If you use the APPC member-routing approach, APPC member-routing works just likeTCP/IP. DB2 Connect will support this approach later.

Each MVS in a data sharing Sysplex has its own TCP/IP instance and IP address. If a DB2member is moved from one MVS to another, the IP address used by the DB2 memberchanges, because DB2 ends up connected to a different TCP/IP instance. This can easilyoccur when the automatic restart manager (ARM) restarts DB2 following the failure of aMVS.

If DB2 is restarted on another MVS, the TCP/IP instance is different. If the failure occurredduring two-phase commit processing, the AR has to resynchronize with the original DB2. Inthis case the DRDA AR can communicate with one of the other DB2 servers in the Sysplexto request routing information for the AS in question. During the connection to a datasharing group, the AR is informed that it is connecting to a data sharing group and ispassed a list of the IP addresses of all the members. This list is constantly updated byWLM, which adds active members and drops failed or quiesced members.

If the AR has specified the IP address of the AS in the SYSIBM.IPNAMES table or whencataloging the node directory, it can no longer connect to the DB2 member because theDB2 member could now be at another IP address.

If the AR has specified the common host name in the SYSIBM.IPNAMES table or whencataloging the node directory, the AR reconnects to the data sharing group, but there is noguarantee that the connection is to the original member because there can be more thanone member on this MVS. The AR and AS exchange log information during commit


processing, which includes the resync port number. If commit fails and resynchronization isrequired, the IP address and resync port number are tried. If this try fails, the host name isused to get the lastest list of IP addresses for the resynchronized host. The list passed bythe AS contains the IP address and the resync port of each active member.

10.7 Workload Balancing for the Data Sharing AS

You have the following options related to workload balancing:

• You can specify the IP address or the host name of a particular AS data sharingmember. Compared to APPC, this implementation is similar to specifying the real LUname of the AS data sharing member on the AR. If you choose this implementation,you can connect only to members of a data sharing group that reside on this MVSsystem. If members are moved to some other MVS system in the Sysplex environment,the AR cannot connect to the moved members.

Workload balancing is static, and it is implemented manually if you have more than oneAR.

• As explained in 10.4, “Each Member on a Different MVS: Common Host Name” onpage 108, you can configure the DNS with a new common host name related to all IPaddresses of MVSs where there are members running. This implementation can becompared to APPC when specifying the generic LU name of the AS data sharing groupon the AR. Generic resource forces all connections for a given client to be directed toonly one AS member of the data sharing group. An AR could enforce this restriction byusing the common host name approach, or the AR could use the entire list of IPaddresses returned by the DNS, and then round-robin within that list. It is an ARimplementation choice.

• A variation of the previous implementation will be available in future releases ofOS/390, where WLM will provide to the DNS a list of IP addresses ordered by thecurrent capacity. When the AR TCP/IP code requests information from the DNS, theDNS will return the IP address of the MVS with the most capacity at the top of the list.TCP/IP tends to choose the first IP address on the list. In the current release of OS/390,WLM does not provide information to the DNS that describes which IP addresses havethe most capacity (DRDA workload). This new enhancement is valid only for the DNS,not for the HOSTS.LOCAL data set. If you use the HOSTS.LOCAL data set, you do notuse workload balancing. Refer to DB2 Data Sharing: Planning and Administration.

Note that this implementation is not directly related to the DRDA code.

• The DRDA architecture can take advantage of the Sysplex workload balancing providedby WLM. This support is already available if the AR is a DB2 for OS/390 Version 5 orlater. The AS data sharing group specifies through DRDA message exchange how theworkload is distributed among the members of the data sharing group. When a TCP/IPDRDA AR connects to a DB2 server, the DB2 server returns a list of IP addresses andrelative priorities that the AR can use for routing subsequent DRDA connectionrequests. On the basis of this information, the AR decides which is the more suitable


member to use for the connection. If the AR issues frequent connection requests toDB2, it has an accurate picture of the available capacity within the Sysplex, whichenables the AR to route the connection request to the member of the Sysplex that isleast used. This support is designed for ARs that manage a large number of concurrentthreads, such as DB2 for MVS or multiuser DB2 Connect gateways.

The DRDA AR is not required to use the Sysplex workload balancing information thatthe DDF supplies, so some DRDA ARs may choose to ignore Sysplex workloadbalancing. This evaluation takes place at the execution of each SQL CONNECTstatement.

Compared to APPC, this configuration is similar to the member-specific implementation,where the AR receives a list of LUs with the corresponding workload.

For APPC workload balancing, each DB2 member calls WLM during START DDF to reportits LU name to WLM. Thus WLM knows which DDFs are up and the LU namess they areusing. When DB2 wants workload balancing information, it asks WLM to return the currentlist. WLM returns the list of LU names (based on the DDFs that are currently active from aWLM ′s point of view). WLM also includes a weight.

There will be some changes in this area due to customer requests. An APAR not availableat the time of writing this redbook will contain the following changes:

• On V4 or later, a DB2 requester will skip entries returned by the server if the entries arenot in LULIST. Thus a requester can restrict access to a subset of the total list of LUs inthe Sysplex.

• In V5, you can specify that a member is only an AR, by setting MAXDBAT=0. WLM andVTAM generic resources will not include the member with MAXDBAT=0 as acandidate.

This is further explained in 10.7.2, “MAXDBAT Changes” on page 113.

10.7.1 DB2 for OS/390 Data Sharing LimitsFor implementations where there is some kind of workload balancing, if the MAX REMOTECONNECTED limit is reached for a particular member, a new connection is not directed toother members, and the connection request is rejected or queued, depending on how youset up the installation parameters.

If you set up your environment such that the connection is immediately rejected when theMAX REMOTE CONNECTED limit is reached, the next connection receives the messageshown in Figure 64 on page 113 on the MVS console.


� �DSNL030I =DBC1 DSNLILNR DDF PROCESSING FAILURE FORLUWID=8121A0A1.0890.000000000000AUTHID=-N/A-, REASON=00D31034� �

Figure 64. MAX REMOTE CONNECTED Limit Reached

where:

REASON CODE 00D31034 indicates that the MAX REMOTE CONNECTED limit is reached.For new connections to be accepted, you have to end previous connections.

10.7.2 MAXDBAT Changes

As more customers move DB2 data sharing into production, there are additionalrequirements concerning how to control intersystem lock contention. DDF access is one ofthe key areas where this is an issue, because most other forms of DB2 access can becontrolled on a member-by-member basis. For example, you can choose to run CICS, IMS,or batch on a member-by-member basis. With an APAR that was not available at the timeof writing, you will be able to control DDF access in a similar way, so that a given DB2member can be configured to accept or reject DDF server activity (transparently to the enduser).

You can use the MAXDBAT system parameter (also known as the MAX REMOTE ACTIVEinstall option) to control the number of DDF server threads that run on each member of theSysplex. Currently, you can use MAXDBAT=0 to turn off DDF server thread activity on aDB2 member, but there are drawbacks to this solution:

• If you start DDF on a member with MAXDBAT=0, connections from remote LUs usingVTAM generic resources or member-specific routing will be rejected with SQL -904 andDB2 reason code 00D300F9.

• If you choose not to run DDF on a DB2 member, the member cannot act as a DDFrequester, so local applications that require access to remote data will not run properly.

The APAR makes the following changes to DDF so that MAXDBAT=0 can be used torestrict DDF server activity on a member of a data sharing group without introducingnegative side effects:

1. DDF will no longer register the member ′s LU name with the VTAM generic LU nameduring DDF startup. This will cause VTAM generic resource connections to be directedto DB2 members that specify MAXDBAT greater than zero.

2. DDF will no longer register the member with WLM for member-specific Sysplex routing.This will not prevent the member from using WLM for enclave prioritization, but it will


prevent WLM from including this member in the Sysplex routing data sent to remotesites.

3. DDF wil l not listen on the DRDA SQL port, so TCP/IP SQL connections wil l be acceptedonly by members that specify MAXDBAT greater than zero.

4. DDF wil l now accept two-phase commit resynchronization requests, even whenMAXDBAT=0. Thus the DB2 member can resolve indoubt threads, even when it is notconfigured to support other kinds of DB2 server activity.

MAXDBAT=0 can also be specified for a non-data sharing system. In this case, DB2 willreject server connection requests (as in previous releases), unless the connection requestis for two-phase commit resynchronization.


Chapter 11. Mixed Mode Connections

In this chapter we describe how to set up connections to DRDA servers using both APPCand TCP/IP protocols and explain some of the implications associated with these mixedmode connections.

11.1 DB2 for OS/390 As a Requester

When you write your application in a DB2 for OS/390 environment, there are two possiblemethods of requesting data from a remote server:

• The application directs the query to another DB2 subsystem by using an alias or athree-part name. The DB2 private protocol is used in this case.

• The application connects to the server location using the SQL CONNECT statement.The DRDA protocol is used in this case.

With the three-part name method, only the APPC protocol is supported. In the CDB, youmust have all of the definitions required for an APPC connection with the remote server,otherwise the request fails.

With the SQL CONNECT statement method, either the APPC or the TCP/IP protocol can beused. DB2 chooses the protocol to be used according to your definitions on the CDB. Ifyou have definitions for both protocols, DB2 uses TCP/IP.

11.1.1 Customizing the CDB for Mixed Mode Connections

In the CDB, the LINKNAME column of SYSIBM.LOCATIONS is used to link this table with theother CDB tables that provide information specific to the communication protocol beingused. For APPC connections, the LINKNAME column must contain the LU name of theremote server. For TCP/IP connections, the LINKNAME column can contain any value thatmatches an entry in the LINKNAME column of the SYSIBM.IPNAMES table.

To enable both APPC and TCP/IP connections to a remote location, you must have a row inSYSIBM.LOCATIONS that links to rows in both SYSIBM.IPNAMES and SYSIBM.LUNAMES.Because the APPC connection requires the LINKNAME to be the LU name of the server, youmust use the LU name as the LINKNAME in the IPNAMES table. Here is an example of theCDB definitions that enable both protocols to a remote server:

SYSIBM.LOCATIONSLOCATION LINKNAME PORT TPNDSGC SCPDSGC 34000


SYSIBM.IPNAMESLINKNAME SECURITY_OUT IPADDR USERNAMESSCPDSGC P DB2PLEX.ITSO.IBM.COM O

SYSIBM.LUNAMESLUNAME SECURITY_OUT USERNAMESSCPDSGC P O

SYSIBM.USERNAMESTYPE AUTHID LINKNAME NEWAUTHID PASSWORDO SCPDSGC SILVIO C1PRNH

Note how the LU name (SCPDSGC) is used in the CDB tables to link the information for bothprotocols. Also, because outbound translation was specified in the IPNAMES and theLUNAMES tables, the row in SYSIBM.USERNAMES applies to both APPC and TCP/IPconnections.

If a request is issued to remote location DSGC, DB2 chooses the protocol to be usedaccording to the following rules:

• For requests issuing the SQL CONNECT statement (DRDA), DB2 checks for a matchingrow in the SYSIBM.IPNAMES table first. If it finds a matching row, it uses the TCP/IPprotocol, regardless of whether there is a matching row in SYSIBM.LUNAMES.

If, for any reason, a TCP/IP connection cannot be established, DB2 does not try to usethe APPC protocol, and the request fails.

• For requests using three-part names, DB2 uses the APPC protocol.

If you want to use the APPC protocol for connections using the SQL CONNECT statement,you must remove the matching row from the SYSIBM.IPNAMES table.

Although you can write programs that access different servers using TCP/IP and APPCprotocols, you cannot use both three-part name and TCP/IP connections in the same thread,accessing the same remote location. If you try do so, the second access fails withSQLCODE -842, even if you issue an SQL COMMIT before the access.

11.1.2 Enabling Mixed Mode for DB2 UDB Servers

If the AS is a DB2 UDB server, the TCP/IP protocol is always used, because three-partnames require the DB2 for OS/390 private protocol, which DB2 UDB does not support. Ifyou want to use both APPC and TCP/IP protocols to access the same DB2 UDB database,you must configure the CDB to have two different locations defined in SYSIBM.LOCATIONSassociated with two database aliases in the DB2 UDB server. For example, if you wantAPPC and TCP/IP connections to DB2 UDB database SAMPLE, the following definitions arerequired in the CDB:


SYSIBM.LOCATIONSLOCATION LINKNAME PORT TPNSAMPLE TCPUDB 30000SAMP2 SC02089I DB22TPN

SYSIBM.IPNAMESLINKNAME SECURITY_OUT IPADDR USERNAMESTCPUDB P 129.33.160.112 O

SYSIBM.LUNAMESLUNAME SECURITY_OUT USERNAMESSC02089I A O

In our example, SAMP2 is an alias for the SAMPLE database defined in the DB2 UDBserver. From the DB2 for OS/390′s point of view, the SAMP2 and SAMPLE entries are twodifferent locations, even though they are just aliases for the same database (SAMPLE). Ifyou issue a CONNECT to SAMP2, the APPC protocol is used. If you issue a CONNECT toSAMPLE, the TCP/IP protocol is used.

It is possible to write a program that issues connects to both the SAMP2 and SAMPLElocations in the same unit of work. In this case, two threads are created, as shown in thefollowing example:

=DB51 DIS THD(*) DETAILDSNV401I =DB51 DISPLAY THREAD REPORT FOLLOWS -DSNV402I =DB51 ACTIVE THREADS - 519NAME ST A REQ ID AUTHID PLAN ASID TOKENTSO TR * 6 DB2RES1 DB2RES1 COBPROG3 0061 109 V444-USIBMSC.SCPDBA1.AE6C8BAF0BD1=109 ACCESSING DATA AT V446-SAMPLE:129.33.160.112:30000 SAMP2:SC02089I V447--LOCATION SESSID A ST TIME V448--SAMP2 ED038CEAEA8464A0 S2 9708619593168 V448--SAMPLE 1056:30000 V R2 9708619593182DISPLAY ACTIVE REPORT COMPLETE

You can also verify the two different connections in the DB2 UDB server:

db2 list applicationsAuth Id Application Appl. Application Id DB # of

Name Handle Name Agent-------- -------------- ---------- ------------------------------ -------- ----DB2 DB2RES1 .B 458752 USIBMSC.SCPDBA1.AE6C8BAF0BD1 SAMPLE 1DB2 DB2RES1 .B 524288 090C0E36.9703.272153512004 SAMPLE 1

Note that both connections use the same database. You must be very careful whenconnecting to the same database using different protocols in the same unit of work.Because you are using different threads, you may create a situation where one of the

Chapter 11. Mixed Mode Connections 117

connections holds locks in tables that you are trying to access with your second connection.In this case, you may create deadlock situations within your own program. You must alsoremember that DB2 UDB as an application server using TCP/IP does not support two-phasecommit processing.

11.2 DB2 UDB As a Requester

When you write your application in a DB2 UDB environment, the only way to request datafrom a remote server is to use the SQL CONNECT statement.

To connect to the remote location specified in the CONNECT statement, DB2 UDB relies onthe information stored in its directories. When you catalog a remote database, you informthe node where it resides. DB2 UDB uses the protocol specified in the node directory toaccess that database.

Only one protocol can be associated with a node, so if you want DRDA connections to thesame remote server using both the APPC and the TCP/IP protocol, you must define twonodes and two database aliases associated with the nodes.

Here is an example of how to catalog location DSGC, in a DB2 UDB requester, using boththe TCP/IP and the APPC protocols:

Catalog the nodes:CATALOG TCPIP NODE TCPN REMOTE DB2PLEX.ITSO.IBM.COM SERVER 34000CATALOG APPC NODE APPCN REMOTE CPICGC SECURITY PROGRAM

Catalog the database aliases:CATALOG DATABASE DSGC AS DSGCT AT NODE TCPN AUTHENTICATION DCSCATALOG DATABASE DSGC AS DSGCA AT NODE APPCN AUTHENTICATION DCS

Catalog the DCS database aliases:CATALOG DCS DATABASE DSGC

DB2 UDB does not support three-part names; the protocol to be used is based only on thedatabase alias you code in your CONNECT statement. If you issue a CONNECT to DSGCA,the APPC protocol is used. If you issue a CONNECT to DSGCT, the TCP/IP protocol is used.

The DB2 Connect product is used when you are requesting a connection to a DRDA server.DB2 Connect supports distributed unit of work and two-phase commit processing. It ispossible to write an application that accesses remote DRDA servers and uses APPC andTCP/IP protocols in the same unit of work.


11.3 Data Sharing Considerations for Mixed Mode

With mixed mode connections, in a data sharing environment nothing really differs from thenon-data-sharing customization. The data sharing group can receive requests and accessremote servers, using both network protocols.

Chapter 11. Mixed Mode Connections 119


Chapter 12. Security Considerations

In this chapter, we discuss security considerations for connections between the DB2 UDBand DB2 for OS/390. Although we focus on the changes introduced with the new nativeTCP/IP support in DB2 for OS/390, much of the information provided here applies toconnections using both APPC and TCP/IP protocols.

12.1 Security Changes for Distributed Processing

DB2 for OS/390 Version 5 introduces many changes in the security and auditing area. Hereis a summary of the changes related to distributed processing for DB2 for OS/390:

• Support for RACF PassTickets, allowing a DB2 for OS/390 AR to connect without flowingthe password on the network. A RACF PassTicket can be used for user authentication.This support also removes the need to store passwords in the AR CDB, makingpassword maintenance simpler and more secure. Previous versions of DB2 for OS/390as an AS support the use of PassTickets.

• Support for Distributed Computing Environment (DCE) security as an AS allowing DRDAARs to connect to DB2 using a unique global identity. DB2 for OS/390 as an AR doesnot support DCE security.

• Ability to use RACF checks for stored procedures that access non-DB2 resources.

• Detailed error codes identifying the cause of a security failure, and remote change ofexpired RACF password from DRDA clients. These functions are enabled by the newinstallation option, EXTENDED SECURITY. As an AR, DB2 for OS/390 does not supportremote password change.

12.2 DRDA Security

DRDA allows a user to be authenticated using SNA security mechanisms or DRDAmechanisms. DRDA mechanisms are independent of the network protocol being used. ForTCP/IP connections, DB2 uses only the DRDA security mechanisms.

Although not recommended, you can use the DRDA security mechanism for APPCconnections. If DB2 for OS/390 is an AS, you specify the value NONE for the SECACPTparameter when defining the APPL for DB2 application in VTAM. You must ensure that allDRDA ARs accept this level of DRDA message exchange. If the AR is DB2 Connect, youcatalog the APPC node on the workstation, using the value NONE for the SECURITYparameter.

The DRDA security mechanisms are also used with DCE authentication, regardless of thenetwork protocol.


12.3 DB2 for OS/390 AS Security

DB2 for OS/390 as an AS using TCP/IP has fewer security options than it has when usingthe APPC protocol. Here are the differences you should consider if you plan to use DB2 forOS/390 as an AS with TCP/IP:

• The CDB is not used to control inbound TCP/IP requests. If DB2 is configured to useTCP/IP, any client machine can connect to DB2. The CDB has no information regardingwhich client machines are authorized to connect to the DB2 AS.

• It is not possible to handle incoming user IDs through DB2. All user IDs must bedefined to RACF or use DCE for authentication. You can prohibit specific users fromconnecting to DB2.

• There is no inbound translation of user IDs.

• There is no concept similar to SNA′s partner LU verification with TCP/IP.

• You cannot encrypt passwords. If you do not want passwords to flow on the network,you must use RACF PassTickets or DCE tickets.

• The sign-on exit (DSN3@SGN) is not used for TCP/IP requests unless the clientapplication is executing in an IMS or CICS for MVS environment and the thread is beingreused. If you need to associate an inbound ID with secondary IDs, modify theconnection exit (DSN3@ATH).

Inbound security for TCP/IP requests is not controlled because the TCP/IP client′s domainnames and IP addresses can change dynamically and hackers can send messagessimulating any IP addresses they want.

When using the APPC protocol, you can define whether a request must contain a user IDand a password or only a user ID by specifying the VTAM parameter SECACPT. To providesimilar support with TCP/IP, DB2 for OS/390 includes a new installation parameter, theTCP/IP ALREADY VERIFIED (TCPALVER) parameter.

If you specify NO for the TCPALVER parameter, all incoming requests must include one ofthe following authentication options:

• A user ID and a password

• A user ID and a RACF PassTicket

• A DCE security ticket

If you specify YES for the TCPALVER parameter, in addition to the above options, requestswith only a user ID are also accepted.

Figure 65 on page 123 shows an overview of DB2 server processing for TCP/IP connectionrequests.


Figure 65. TCP/IP Requests: Server Flow

12.4 DB2 for OS/390 AR Security

DB2 for OS/390 as an AR chooses SNA or DRDA security mechanisms on the basis of thenetwork protocol you are using. If you are using APPC, you get the SNA securitymechanisms, and the authentication information is sent in an FMH-5 header.

If you are using TCP/IP, DB2 uses the security commands included in the DRDA messageexchange, and the user ID, user ID and password, or user ID and RACF PassTicket are sentas part of a DRDA command.

Chapter 12. Security Considerations 123

12.4.1 CDB Tables

If you are using TCP/IP, the CDB is not used to control incoming requests to a DB2 server.However, when DB2 for OS/390 is a requester, some CDB tables are used to controlaspects of what is sent in the remote requests. In this section, we focus on the CDB tablesthat relate to security in TCP/IP requests.

12.4.1.1 SYSIBM.IPNAMES: SYSIBM.IPNAMES is used to control requests that use theTCP/IP protocol. Here is a brief description of the columns that relate to security:

• LINKNAME

The LINKNAME column in SYSIBM.IPNAMES must match the LINKNAME column of theSYSIBM.LOCATIONS table. The LINKNAME column is used to link the row inSYSIBM.IPNAMES with the remote location defined in SYSIBM.LOCATIONS and mustcontain a unique value.

• SECURITY_OUT

The SECURITY_OUT column specifies which authentication information is sent with therequests to the remote server. The valid values for this column are:

A Already verified. This is the default option. It specifies that theoutbound requests contain only the user ID. Passwords orPassTickets are not sent to the server. If the remote server is aDB2 for OS/390 system, the TCPALVER parameter of the remotesystem must be set to YES; otherwise the connect request isrejected. If the remote server is a DB2 UDB system, theAUTHENTICATION parameter of the database managerconfiguration file must be set to CLIENT; otherwise the connectrequest is rejected.

R RACF PassTicket. This option specifies that the outboundrequests contain the user ID and a RACF PassTicket. To generatethe PassTicket, RACF uses the user ID, the application name, thecurrent time, and a predefined key. The application name usedfor DB2 is the LU name of the AS. Because the remote server LUname is used when generating the PassTicket, the LINKNAMEcolumn must specify the remote server LU name.

This option cannot be used if the remote server is a DB2 UDBsystem. However, if the remote server is a DB2 for OS/390system, we recommend that you use RACF PassTickets whenusing TCP/IP, to avoid passwords being sent in clear text on thenetwork

If you use outbound translation, the translated user ID is used togenerate the RACF PassTicket. For more information about RACFPassTickets, refer to 12.4.3, “RACF PassTickets” on page 128.


P Password. This option specifies that the outbound requestscontain the user ID and a password. The password is obtainedfrom the SYSIBM.USERNAMES table. Note that the password isnot obtained from RACF. When using TCP/IP, you cannot specifypassword encryption, so the password specified inSYSIBM.USERNAMES is sent in clear text over the network.

If you specify P for the SECURITY_OUT column, you must specifyO in the USERNAMES column.

As a requester, DB2 for OS/390 cannot send DCE tickets to be validated at the remoteserver.

• USERNAMES

For TCP/IP connections there is no inbound translation. The USERNAMES column isused only to specify whether or not an outbound request is subject to translation. Thevalid values for the USERNAMES column are:

O Outbound translation. The user ID, sent to the correspondingLINKNAME, is subject to translation. When you specify O in theUSERNAMES column, DB2 searches for a row in theSYSIBM.USERNAMES table to perform the outbound translation.

blank No outbound translation is performed for the correspondingLINKNAME.

12.4.1.2 SYSIBM.USERNAMES: The SYSIBM.USERNAMES table is used by both SNAand TCP/IP connections. Here is a brief description of the columns of theSYSIBM.USERNAMES table.

• TYPE

The TYPE column specifies whether the row is used for inbound or outbound translation:

I The row is used for inbound translation.

O The row is used for outbound translation.

Because DB2, when using TCP/IP, does not perform checks for inbound requests usingthe CDB, for TCP/IP connections the value of the TYPE column must be O.

• AUTHID

For TCP/IP connections, this column is used only to specify the user ID to be translated.If blank, all user IDs are translated in the same way for the specified LINKNAME.

• LINKNAME

The LINKNAME column identifies the location associated with the row. If blank, the rowapplies to any TCP/IP or SNA connections. If you want the SYSIBM.USERNAMES row toapply to a specific server using TCP/IP, the value of the LINKNAME column in


SYSIBM.USERNAMES must match the value in the LINKNAME column ofSYSIBM.IPNAMES.

• NEWAUTHID

The NEWAUTHID column specifies the translated user ID. If blank, no translationoccurs.

• PASSWORD

The PASSWORD column specifies the password to be sent with outbound requests.This password is not provided by RACF and cannot be encrypted. If in theSECURITY_OUT column of SYSIBM.IPNAMES you specify P, the PASSWORD columnprovides the password to be sent to the remote server.

12.4.1.3 CDB Processing for Outbound Requests: Figure 66 on page 127 shows anoverview of the flow when sending a request from a DB2 client using TCP/IP.


Figure 66. TCP/IP Requests: Client Flow

12.4.2 Outbound Translation

When sending requests to remote servers, you may want to translate the local user ID to adifferent valid remote user ID or send a password associated with the user ID to beauthenticated at the remote server. These functions are implemented by adding rows tothe SYSIBM.USERNAMES CDB table.

Note: If you do not use outbound translation, the primary authorization ID is always sent tothe server.

Below we present a few examples of SYSIBM.USERNAMES table customization.


To translate user ID SILVIO to RICARDO, on outbound requests to server IPSVR1, sendingpassword RICPASSW, you need the following row in SYSIBM.USERNAMES:

TYPE AUTHID LINKNAME NEWAUTHID PASSWORDO SILVIO IPSVR1 RICARDO RICPASSW

If you do not want to translate user ID FELIPE on outbound requests to server IPSVR1 butwant to send password FELPASSW, you need the following row in SYSIBM.USERNAMES:

TYPE AUTHID LINKNAME NEWAUTHID PASSWORDO FELIPE IPSVR1 blank FELPASSW

To translate user ID ALINE to FABIANA, on outbound requests to any remote server,sending password FABPASSW, you need the following row in SYSIBM.USERNAMES:

TYPE AUTHID LINKNAME NEWAUTHID PASSWORDO ALINE blank FABIANA FABPASSW

To translate any user ID to SJUSER, on outbound requests to server IPSVR1, sendingpassword SJPASSW, you need the following row in SYSIBM.USERNAMES:

TYPE AUTHID LINKNAME NEWAUTHID PASSWORDO blank IPSVR1 SJUSER SJPASSW

If you specify outbound translation on the SYSIBM.IPNAMES table, and there is not a row inSYSIBM.USERNAMES for the user ID, or a row with blanks on AUTHID for the remotelocation, the request is rejected.

12.4.3 RACF PassTickets

RACF PassTickets can be used for both TCP/IP and APPC connections. However, whenusing TCP/IP, you can neither encrypt passwords nor get the password directly from RACFwhen connecting to remote servers. You should consider using RACF PassTickets forTCP/IP requests, to avoid the password flowing on the network and to reduce the need forcustomization of the SYSIBM.USERNAMES table.

Previous releases of DB2 could receive requests with PassTickets but not send PassTicketsto remote servers. The use of PassTickets as a requester is new in DB2 for OS/390 Version5. For more information about PassTickets support in previous versions of DB2, refer to theredbook, DB2 for MVS DRDA Server: Security Considerations.

DB2 UDB servers cannot receive PassTickets for authentication. If your remote server is aDB2 UDB system, you must provide a valid password or specify the already verified optionin the CDB.

Whenever the authentication process takes place on the remote server, a valid user ID anda password are sent to the host. An alternative way of authenticating the user ID is to use


a RACF PassTicket instead of a password. PassTickets are passwords generateddynamically; they are valid only once within a certain period of time after their generation.

To use RACF PassTickets, you must have one of the following versions of RACF:

• RACF Version 1.9.2 with the secured signon SPE APAR(OY65281)

• RACF Version 2

With the appropriate RACF level and definitions, you can use PassTickets instead ofpasswords for user authentication on the remote server.

The generation process of a PassTicket uses the following information:

• User ID

The user ID in the client request is one of the parameters used to generate aPassTicket. If you specify outbound translation, the translated user ID is used forPassTicket generation.

• Secured signon application key

The secured signon application key is a secret key related to the application beingaccessed. The secured signon application key is a 16 hexadecimal character keystored in the RACF PassTicket generic profile associated with the application. RACFPassTicket profiles must be created on both client and server systems, and the securedsignon application key must be the same on both systems. Refer to 12.4.3.1,“Configuring RACF for PassTickets” on page 130 for more information about how todefine the secured signon application key.

• Application ID

The application ID is the identification of the DB2 server being accessed. Theapplication ID of a DB2 for OS/390 server is its LU name. If you are accessing a datasharing group, the application ID is the generic LU name.

During PassTicket generation on the requester DB2, the value for the application ID isobtained from the LINKNAME column of the SYSIBM.LOCATIONS table. Because theapplication ID must be the remote server′s LU name, you must ensure that, even if youare using TCP/IP, the LINKNAME value for the remote location is set to the remote LUname.

• Timestamp

This is the current time and date information relative to the Greenwich mean time(GMT). The timestamp is used to limit the usability of a PassTicket to a certain amountof time. After this time, the PassTicket is no longer valid.


12.4.3.1 Configuring RACF for PassTickets: To use PassTickets for userauthentication, some RACF profiles must be defined in both client and server systems.

First, you must define and activate the RACF PassTicket data class (PTKTDATA). This classcontains the RACF profile for the server DB2 subsystem. To activate the PTKTDATA class,you must issue the following RACF commands:

SETROPTS CLASSACT(PTKTDATA)SETROPTS RACLIST(PTKTDATA)

After activating PTKTDATA, you must define a profile for the DB2 server. This profilecontains the secured signon application key used for generating and validating thePassTicket. The name of the profile must be the LU name of the server DB2. If yourrequester accesses more than one DB2 server, you must define one profile for each server.You must also ensure that the DB2 server LU name is used as the LINKNAME value in theSYSIBM.LOCATIONS table of the requester CDB.

To define a RACF profile for a DB2 server that has LU name SCPDBA1, use the followingRACF command:

RDEFINE PTKTDATA SCPDBA1 SSIGNON(KEYMASKED(C1D3C9D5C5D9C9C3))

In the above command, the SSIGNON parameter is used to define the secured signonapplication key. The value for this parameter can be any 16 hexadecimal characters, butyou must ensure that the value you specify is the same for the client and server systems.

The final step to enable the use of RACF PassTickets is to refresh the RACF profilesdefinition by issuing the following command:

SETROPTS RACLIST(PTKTDATA) REFRESH

12.4.4 DCE Tickets

Although DB2 for OS/390 can accept requests with DCE tickets in the authenticationinformation, it cannot send DCE tickets for authentication in the remote server.

12.4.5 Changing Remote Passwords

As a requester, DB2 for OS/390 does not provide support to change passwords on theremote server.

12.5 DB2 UDB AS Security

DB2 UDB can perform the role of a DRDA AS, using both APPC and TCP/IP protocols.However, depending on the network protocol and server platform you are using, there are afew differences regarding the authentication of the remote user.


12.5.1 DB2 UDB Server Authentication

DB2 UDB sets the authentication requirements at the instance level for local databases.You can catalog a local database with a different authentication level, but the authenticationspecified in the database manager configuration file overrides the authentication youspecify in the CATALOG DATABSEe command for the local database.

If you specify AUTHENTICATION=CLIENT, any remote request containing only the user ID isaccepted, as well as requests with user ID and password. If all of the requesters aretrusted systems, you can choose to use the AUTHENTICATION=CLIENT option. If youspecify AUTHENTICATION=SERVER, only requests with a valid user ID and password areaccepted.

If you are using DB2 UDB running on AIX, you can use AUTHENTICATION=CLIENT orSERVER, regardless of the protocol being used.

DB2 UDB running on OS/2 or Windows NT using the APPC protocol can only useAUTHENTICATION=CLIENT because the user ID and password are sent inside the SNAFMH-5 header and both CM/2 and the SNA Server for Windows NT do not pass to the DB2UDB server the password received in FMH-5. If, however, you configure the LU 6.2Syncpoint Manager (SPM), which is a privileged user, CM/2 can provide the password tothe DB2 UDB server. If you do not configure SPM, you cannot useAUTHENTICATION=SERVER. If you have requesters that cannot be trusted, such asWindows 3.11 clients, this may be a problem because authentication is set at the instancelevel for all clients.

If you use TCP/IP as the network protocol, there are no restrictions for the authentication inDB2 UDB for OS/2 and Windows NT. Using TCP/IP, you can specify eitherAUTHENTICATION=CLIENT or AUTHENTICATION=SERVER, because the user ID andpassword are received inside DRDA commands. You can choose to use the TCP/IPprotocol, to provide a more secure environment for your DB2 UDB servers running on OS/2and Windows NT.

12.5.2 Case Sensitivity

The DB2 UDB server platforms we tested during our residency, AIX, OS/2, and Windows NT,handle case sensitivity for user IDs and passwords in different ways. If your request iscoming from a DB2 for OS/390 system, you must be aware of some restrictions regardingcase sensitivity.

12.5.2.1 AIX: In the AIX environment, user IDs and passwords are usually in lowercase.If the user ID and password received are in uppercase, DB2 UDB checks for an exactmatch. If it does not find a match, it folds the user ID and password to lowercase andperforms another validation check.


If your requester is DB2 for OS/390 and your server is DB2 UDB for AIX, you can specify theuser ID and password in the SYSIBM.USERNAMES table, in lowercase or uppercase, aslong as you have defined the password in AIX in lowercase.

12.5.2.2 OS/2: DB2 UDB running on OS/2 uses UPM services for validating user IDs andpasswords. UPM always stores user IDs and passwords in uppercase. If the incomingrequest contains a lowercase user ID and password, UPM automatically folds them touppercase for validation.

If your requester is DB2 for OS/390 and your server is DB2 UDB for OS/2, you can specifythe user ID and password in the SYSIBM.USERNAMES table, in lowercase or uppercase.

12.5.2.3 Windows NT: User IDs and passwords on Windows NT are case sensitive. Thefinal version of DB2 UDB for Windows NT works in the same way as in the AIX environment,folding the user ID and password if necessary. However, the beta version we used duringour tests requires the Windows NT password to be defined in uppercase when therequester is a DB2 for OS/390 system. If the password in Windows NT is defined inuppercase, you can define the password either in uppercase or lowercase in theSYSIBM.USERNAMES table. If the Windows NT password is in lowercase, the request failsregardless of how you specify it in the SYSIBM.USERNAMES table.

12.5.3 PassTickets

DB2 UDB as a server does not accept PassTickets instead of passwords for userauthentication. If the DB2 UDB server is defined with AUTHENTICATION=SERVER, yourDB2 for OS/390 requester must specify P in the SECURITY_OUT column of theSYSIBM.IPNAMES table, and a valid user ID and password must be provided in theSYSIBM.USERNAMES table.

12.6 DB2 UDB AR Security

DB2 Connect implements the DRDA requester function. DB2 Connect can perform the roleof a DRDA AR using both APPC and TCP/IP protocols. However, depending on the networkprotocol, there are a few differences regarding user authentication.

12.6.1 DB2 Connect Authentication

When cataloging the remote database on the client workstation, you can specify theauthentication level you want for that specific remote database. The authenticationspecified in the CATALOG command for remote databases overrides the authenticationspecified at the instance level. In this section, we briefly describe how the differentauthentication levels work in DRDA connections using TCP/IP.


12.6.1.1 Authentication CLIENT: If you specify authentication CLIENT in your CATALOGDATABASE command, user validation takes place at the client workstation. In this case,only the user ID is sent to the DRDA server. If the DRDA server is a DB2 for OS/390system, the authentication CLIENT option only works if you specify YES for the TCP/IPALREADY VERIFIED (TCPALVER) parameter in the DB2 for OS/390 server. Even though thepassword is not validated at the DB2 for OS/390 system, you must be aware that a RACFprofile for the user ID must exist, or the request is rejected.

12.6.1.2 Authentication SERVER: If you specify authentication SERVER in yourCATALOG DATABASE command, user validation takes place at the DB2 Connectworkstation. Whit TCP/IP, the authentication SERVER works differently than it does withAPPC connections. With TCP/IP, the user is validated only at the DB2 Connect workstation.The DRDA server does not validate the user ID. With TCP/IP, the authentication SERVERoption works in a similar way as the authentication CLIENT option and requires theTCPALVER parameter to be set to YES in DB2 for OS/390 servers.

12.6.1.3 Authentication DCS: If you specify authentication DCS in your CATALOGDATABASE command, user validation takes place at the DRDA server. The user is notvalidated at the DB2 Connect workstation. If the TCPALVER parameter is set to YES in theDB2 for OS/390 server, requests with only the user ID, without a password, are alsoaccepted, when you specify authentication DCS with TCP/IP. If the TCPALVER is set to NO,the request must contain the user ID and a valid password when you specify authenticationDCS with TCP/IP.

12.6.1.4 Authentication DCE: Authentication using DCE security works differently. Theuser is authenticated at a DCE security server. The DCE client software running in thesame machine as the DB2 client is responsible for the communication with the DCE server.The communication is such that the password cannot flow over the network. At present,this implementation is supported only on DB2 clients running on AIX systems.

When accessing a DB2 for OS/390 server, if you specify authentication DCE, a DCE ticket isgenerated at the local DCE server and sent to the mainframe for validation.

12.6.2 Sending PassTickets

DB2 UDB servers cannot accept PassTickets for user authentication, but if you areaccessing DB2 for OS/390 servers you can send a user ID and a PassTicket to be validatedat the host. The main difference between DB2 for OS/390 as a requester and a DB2Connect request is that DB2 for OS/390 generates the RACF PassTicket automaticallyduring the connect, and DB2 Connect does not generate the PassTicket automatically.

If you plan to send PassTickets to the DRDA server, before the CONNECT statement, youmust invoke a program that will generate the PassTicket for your user ID. When you issuethe CONNECT statement, you must then specify the previously generated PassTicket,


instead of your password. The PassTicket generation program uses the services of anexternal security manager and can generate a valid PassTicket only if you provide thecorrect application ID and key in your server system. For more information aboutPassTicket generation for workstation clients and examples of programs to generatePassTickets, see the redbook, DB2 for MVS DRDA Server: Security Considerations.

12.6.3 Accessing Servers through a Firewall

In essence, a firewall is a system that works as a barrier between a secure, internal privatenetwork and another (nonsecure) network or the Internet. The purpose of a firewall is toprevent unauthorized communication into or out of the secure network. The firewall hastwo jobs:

• Prevent users outside your network from coming in to compromise or attack it

• Prevent users inside your network from freely exchanging information with systemsoutside your network

The firewall provides security against unauthorized users, but it does not allow access toexternal servers. One way of accessing external servers through a firewall is to use asocks server.

Socks is software that allows computers in network protected by firewall to access externalnetworks or the Internet. The socks software is usually installed on a machine inside yournetwork or on the firewall. Users of the network protected by the firewall access the socksserver as clients to reach the external network or the Internet.

A different DNS is usually associated with the socks server. This DNS is needed to resolvehost names of the external network or the Internet. Generally, your usual DNS can onlyresolve host names of your internal network.

If you want to access a DRDA server that resides in an external network, you may have touse a socks server. DB2 UDB and DB2 Connect now implement a new option in theCATALOG TCPIP NODE command to specify that you need to use a socks server to reachthe remote host. This new option is SECURITY SOCKS and is specified as follows:

CATALOG TCPIP NODE EXTSVR REMOTE db2svr.other.com SERVER 446 SECURITY SOCKS

The SECURITY SOCKS option also requires that you set two environment variables:

• SOCKS_NS

• SOCKS_SERVER

The SOCKS_NS variable must be set to the IP address of the DNS associated with yoursocks server. You can set the SOCKS_NS variable, using the DB2SET command as follows:

DB2SET SOCKS_NS=9.14.1.30


The SOCKS_SERVER variable can be set to the IP address or the host name of your socksserver. You can set the SOCKS_SERVER variable, using the DB2SET command as follows:

DB2SET SOCKS_SERVER=socks1.server.ibm.com

Note that using the SECURITY SOCKS option is different from using DB2 Net.Data or DB2WWW Connection. With Net.Data or DB2 WWW, the client machine always runs a Webbrowser, such as Netscape, and access to DB2 data is always through HTML forms. Whenyou catalog a database using SECURITY SOCKS, the client is a regular DB2 client, runningthe CAE or the SDK products, and has the same accessing possibilities as a client that runsin the internal network.

12.6.4 Changing the Password at the Remote Server

DB2 for OS/390 as an AS enables clients to remotely change the password in the serversystem. From a DB2 Connect client you can request the password change, using theDB2PEM utility. The CONNECT statement does not provide support for remote passwordchange.



Chapter 13. Distributed Unit of Work

In this chapter, we discuss the use of DUW and the two-phase commit protocol in DRDAconnections. Note that for TCP/IP connections, DRDA is XA compliant.

13.1 Concepts

A unit of work is a DUW when the application sends requests to multiple remote applicationservers. DUW allows an application to access more than one relational databasemanagement system (RDBMS) within a unit of work, that is, the application can switchbetween RDBMSs before committing the data. Thus you can do work involving multipleRDBMSs, local and remote, in the same unit of work. Without DUW, an application canhave only one connection to an application server within one commit scope.

Although you can work with many servers with DUW, all tables referenced by each SQLstatement must reside in a single application server. That is, you cannot perform suchoperations as joins of tables residing in different servers.

SQL requests that reference multiple tables on different servers are called distributedrequests and require the use of the DataJoiner product. For more information aboutDataJoiner, refer to 13.7, “DataJoiner” on page 146.

With DUW you can perform:

• Multisite reads

• Multisite reads and single-site updates

• Multisite reads and multisite updates

Both DB2 UDB and DB2 for OS/390 provide support for DUW using the DRDA protocol witheither TCP/IP or APPC.

All IBM products that support DRDA can act as ASs for a client running a DUW application,although there are some restrictions related to updating these ASs.

13.1.1 Multisite Reads

A DUW with multisite read can be connected to different application servers, but allrequests to the application servers are read-only. You can read several tables fromdifferent databases without closing and reopening cursors, but you cannot update any ofthose tables. Because there is no update in any server, there is no need for coordination atcommit. The level of commit used in this case is called one-phase commit. Figure 67 onpage 138 illustrates multisite reads to different application servers.


Figure 67. Multisite Reads

All IBM products that support DRDA can act as ASs for a client running a DUW application,although there are some restrictions related to updating these ASs.

13.1.2 Multisite Reads and Single-Site Update

A DUW with multisite reads and single-site update is connected to different applicationservers, reading information from several servers and updating information in only one ofthe servers, within the unit of work. Because the update occurs in only one server, there isno need for coordination at commit. The level of commit used in this case is alsoone-phase commit. Figure 68 on page 139 illustrates multisite read to different applicationservers with single-site update.


Figure 68. Multisite Reads and Single-site Update

All IBM products that support DRDA can act as an AS for a client running a DUWapplication for this type of DUW.

13.1.3 Multisite Updates

A DUW with multisite updates is connected to different application servers, reading andupdating information in any of the servers. Because you are updating many servers withinthe unit of work, there must be coordination at the commit. If one server fails to commit, allof the other servers must roll back. The commit is successful only if all servers cancommit. The level of commit used in this case is called two-phase commit. Figure 69 onpage 140 illustrates multisite update to different application servers.

Chapter 13. Distributed Unit of Work 139

Figure 69. Multisite Updates

Some of the IBM products that support DRDA provide support for two-phase commitprocessing. The support is dependent on the protocol used, the IBM product, the productversion, and the release level.

13.2 Two-phase Commit

When data in more than one server must be consistent, all update operations at all serverswithin a unit of work must be either committed or rolled back. Two-phase commit providesa mechanism that ensures this consistency (see Figure 70 on page 141).

Two-phase commit is under the control of the client application, called the coordinator. Theservers involved are called the participants. In interactions with other servers, your localsystem can be either the coordinator or a participant.


DB2 can work with other database managers, such as IMS and CICS. The two-phasecommit protocol is also supported in this case. If you are using IMS or CICS, DB2 is theparticipant for the IMS or CICS subsystem coordinator.

Figure 70. Two-phase Commit

In Figure 70, during phase 1, the coordinator informs all participants that they are toprepare for commit. The participants successfully complete phase 1 and notify thecoordinator. If any participant indicates that it cannot commit, the coordinator sends out therequest to roll back the unit of work at all systems.

The coordinator completes its phase 1 processing and begins phase 2, when the actualcommit occurs. The participants successfully complete phase 2 and notify the coordinator.The coordinator finishes its phase 2 processing. The data controlled by all servers is nowconsistent and available to other applications.

If an AS system fails after completing phase 1 but before starting phase 2, when the AS isrestarted it has a unit of work that is indoubt. The failed AS system must communicate withthe coordinator to find out the final outcome of the unit of work and commit or roll back itsupdates according to this information.

If the protocol being used is presume nothing, and for some reason the coordinator wascold started and lost this information, the user has to manually decide to roll back orcommit the unit of work. If the protocol being used is presume abort and for some reasonthe coordinator was cold started or lost this information, the AS rolls back the unit of work.


Both DB2 for OS/390 and DB2 UDB provide support for the two-phase commit protocol.However, DB2 UDB support for two-phase commit varies according to the platform and thecommunication protocol being used.

13.3 DB2 UDB As an Application Requester

DB2 UDB provides full support for DUW with two-phase commit when using its privateprotocol; that is, for a DUW involving only DB2 UDB servers, two-phase commit is supportedregardless of the protocol being used.

When the DUW also updates non-UDB servers, such as DB2 for OS/390, the DRDA protocolis used. The DB2 Connect product allows you to update multiple DRDA servers within aDUW. However, depending on the communications protocol you are using, there are someprerequisites that must be satisfied.

If you are using APPC, you must have LU 6.2 SPM installed and enabled. To have thissupport, for OS/2 and AIX requesters, you need the Communication Server Version 4product. Microsoft SNA Server V3 has syncpoint support, but DB2 Connect on the NTplatform does not.

The DB2 Connect LU6.2 SPM is supported only on OS/2 and AIX.

Also, you can use two-phase commit through APPC only when accessing DB2 for MVSVersion 3.1 or later or DB2 for OS/400 Version 3.1 or later. The current release of DB2 forVM and VSE does not support two-phase commit processing as an application server.

If you are using TCP/IP, you can access DB2 for OS/390 Version 5 and DB2 UDB databasesin the same DUW. DB2 Connect supports two-phase commit when accessing applicationservers through TCP/IP.

Regardless of the protocol being used, to enable DUW with two-phase commit processing,you must ensure that your client program is precompiled with the CONNECT 2 andSYNCPOINT TWOPHASE options.

13.3.1 Using DUW with SYNCPOINT NONE

When you are using DUW, you can choose to precompile your application program with theSYNCPOINT NONE option. This option disables the two-phase commit protocol, but yourapplication program can update multiple servers.

When you issue a commit, there is no coordination between the different servers. Thecommit is sent to all servers, and, if there is a failure in one of them, the other servers willcommit the updates, regardless of the failure.


You can choose to use this option if your remote servers do not support the two-phasecommit protocol, and the consistency of the data among the servers is not critical to yourapplication.

If you use SYNCPOINT NONE, and a failure occurs in one of the remote servers, a messagesimilar to the following is returned to your application:

SQL0979N COMMIT has failed against ″ 1″ databases for an application processrunning with SYNCPOINT of NONE. The failures include the following databasealias and SQLSTATE pairs (a maximum of four can be returned): ″SAMPLE55032″ , ″″ , ″″ , ″″ . SQLSTATE=40003

The AS can be DB2 UDB, or any other IBM product that supports a DRDA AS. Thecommunication protocol can be TCP/IP or APPC.

13.3.2 Using DB2 for OS/390 As a Transaction Manager

One of the advantages of using the TCP/IP protocol is that you can access DB2 for OS/390databases from Windows 95 or 3.11 directly, without a gateway machine. However, whenyou have applications that use DUW updating databases on different remote servers, theclient application is responsible for coordinating the two-phase commit processing. Theclient application is also responsible for resynchronizing the ASs in case of a failure.

As explained in 13.2, “Two-phase Commit” on page 140, in case of failures duringtwo-phase commit, the resynchronization process takes place after the failing system isrestarted. Assume for the following scenario that:

• The client application runs on a workstation used during week days and is turned off onweekends.

• The client application does multisite updates on several DB2 for OS/390 ASs.

• A communication failure between the AR and one or more of the ASs occurs by the endof Friday during the two-phase commit processing.

The result is that the ASs have indoubt units of work. If the workstation is powered offbefore these indoubts are resolved, all locks acquired by the client application are held untilthe workstation is powered on and communication is reestablished.

To avoid this problem, when you configure DB2 UDB, the transaction manager databaseparameter, TM_DATABASE, can be configured to specify the database used to log thetwo-phase commit process and to perform resynchronization in case of a failure. If therequester you are using is a workstation, you can configure the TM_DATABASE parameterto point to a remote database located in a more reliable system.

DB2 Connect Version 5 allows you to set the TM_DATABASE parameter to a DB2 for OS/390AS system accessed by the application. The DB2 for OS/390 AS will be responsible for theresynchronization process if there is a communication failure.


Figure 71 on page 144 illustrates DB2 for OS/390 as a transaction manager database.

Figure 71. DB2 for OS/390 As a Transaction Manager Database

To implement this option you must configure the database that has two-phase commitresynchronization responsibilities such that it can communicate with the other ASs.

13.4 DB2 UDB As an Application Server

DB2 UDB provides support for DUW with two-phase commit when accessed as a DRDA AS.However, this support is dependent on the communication protocol being used and theplatform where the DB2 UDB server is running. It is a new function implemented in DB2UDB Version 5.


When DB2 UDB uses the APPC protocol as an application server, it supports two-phasecommit only on the OS/2 and AIX platforms, if you have the Communications Server Version4 installed. DB2 UDB running on the Windows NT platform does not support the two-phasecommit protocol as an AS.

When using the TCP/IP protocol, DB2 UDB as an application server does not support thetwo-phase commit protocol.

Note that if you are not using the DRDA protocol to access the DB2 UDB server, DB2 UDBsupports two-phase commit, regardless of the protocol being used.

13.5 DB2 for OS/390 As an Application Requester

DB2 for OS/390 as an AR provides support for DUW with two-phase commit processingregardless of the protocol being used.

Your DUW can include connections using TCP/IP and APPC. Two-phase commit issupported even if you use TCP/IP to access some servers and APPC to access otherservers in the same DUW.

The two-phase commit processing with TCP/IP connections supports presume abort only.However, a TCP/IP connection can be part of a DUW that includes both presume abort andpresume nothing APPC connections.

If you try to update an application server that does not support two-phase commit, within aDUW, you receive an SQLCODE -919. Your DUW is placed in a must rollback state, and allservers involved must roll back the previous updates.

13.6 DB2 for OS/390 As an Application Server

DB2 for OS/390 as an AS provides support for DUW with two-phase commit processingregardless of the protocol being used.

If you are using a data sharing group as your server, you must be aware that if aresynchronization is required, your requester must reconnect to the same AS member usedduring the execution that failed. DB2 for OS/390 ensures that your requester reconnects tothe same member, regardless of the protocol being used. For more information about theresynchronization process in a data sharing environment, refer to 10.6, “Resynchronization”on page 110.


13.7 DataJoiner

To help you understand how DataJoiner supports two-phase-commit processing, wedescribe some of the features of the DataJoiner product.

DataJoiner Version 2 can execute on the following platforms:

• AIX• HP-UX• Solaris• Windows NT

DataJoiner Version 2 is based on DB2 common server Version 2.1.2. Each DataJoinerinstance is a DB2 common server instance with catalog extensions that allow theDataJoiner administrator to specify nicknames. A nickname is an alias for a remote datasource table or view. The actual data source can be on either a non-IBM product such asOracle, Sybase, Microsoft SQL Server, and Informix or on another IBM relational productsuch as DB2 UDB, DB2 common server, DB2 for OS/390, DB2 for VM and VSE, DB2 forOS/400.

The key feature of DataJoiner is transparency, where you can use a nickname the sameway that you use local names for tables or views. You do not have to code the SQLCONNECT statement to access a remote table or view. DataJoiner allows you to issue SQLstatements, including update statements, referring to remote tables or views. It alsoprovides support for distributed requests, allowing the specification of tables or views fromdifferent data sources in the same SQL statement.

There is a layer between DataJoiner and the various data sources. The appropriateprotocol is dynamically loaded on the basis of the type of data source that is beingaccessed, as registered in the DB2 catalog extension.

DataJoiner uses the DB2 private protocol to access DB2 common server or UDB, DRDA toaccess a host DB2 database (MVS, VM, VSE, or OS/400 platforms), and specific protocols toaccess non-IBM data sources (Oracle, Sybase, Microsoft SQL Server, Informix). BecauseDataJoiner is based on DB2 common server Version 2.1.1, it uses only APPC to access aDRDA remote database. TCP/IP for DRDA connections is not available in DataJoinerVersion 2.

13.7.1 Supported ProductsDataJoiner Version 2 supports multisite update within a unit of work using the two-phasecommit protocol if all participants support two-phase commit. Table 11 on page 147 showsthe data sources supported by DataJoiner Version 2 and indicates whether the data sourcesupports two-phase commit processing.


Table 11. DataJoiner Version 2 Data Sources and Two-Phase Commit Support

Two-PhaseCommitSupport

DB2 for MVS/ESA (before Version 3) No

DB2 for MVS/ESA (Version 3 or after) Yes

DB2 for OS/400 (before Version 3) No

DB2 for OS/400 (Version 3 or after) Yes

DB2 for VM and VSE (before Version 4.1) No

DB2 for VM and VSE (Version 4.1 or later) Yes

DB2 common server (before Version 2.1) No

DB2 common server (Version 2.1 or after) Yes

Oracle without XA library/distributed database option No

Oracle V7 with XA library/distributed database option all UNIXplatforms

Yes

Oracle V7.2 or V7.3.2.1.1 with XA library/distributed database optionon NT 3.5.1

Yes

Oracle V7.3.2.2.1 with XA library/distributed database option on NT 4.0 Yes

Sybase (DBLIB) No

Sybase (CTLIB) Yes

MS SQL Server 4.2 and 6.5 No

MS SQL Server 4.2 (CTLIB) Yes

MS SQL Server 6.5 (ODBC) using DataJoiner on NT Yes

MS SQL Server 6.5 (ODBC) using DataJoiner on non-NT No

Informix 7.1 and 7.2 with Informix SQL API products Yes

Data sources accessed using generic access API No

EDA/SQL No

DataJoiner nonrelational component No

Cross Access No


13.7.2 The ArchitectureThe basic architecture for DataJoiner two-phase commit processing is based on the X/OpenDistributed Transaction Process (XA) two-phase commit model. In this model there is acoordinator, also known as the transaction manager (TM), and zero or more participants,also known as resources managers (RMs). DataJoiner can assume both roles. It assumesthe role of an RM because it owns resources participating in the unit of work, such as localtables. It assumes the role of a subordinate TM because of the other data sourcesaccessed through DataJoiner. Figure 72 illustrates this environment.

Figure 72. DataJoiner Two-phase Commit Environment

In Figure 72 the TM (TM1) has an RM (RM1) and two subordinate TMs (DataJoiner 1 andTM2), one of which is DataJoiner. The DataJoiner subordinate TM (DataJoiner 1) has twoRMs (RM2 and RM3) and a subordinate TM (DataJoiner 2), which happens to be aDataJoiner. (DataJoiner 2 could have a number of subordinate RMs, illustrating thepossibility of an arbitrarily deeper hierarchy.) The non-DataJoiner TM (TM2) has two RMs(RM4 and RM5).


13.7.3 ModesAs indicated in Table 11 on page 147, not every RM in a Datajointer configuration supportstwo-phase commit processing. The lack of support for two-phase commit processing doesnot exclude a particular data source from participating in a transaction. A transaction canaccess concurrently DataJoiner data sources that support two-phase commit processingand data sources that do not support two-phase commit processing, with some restrictions.

DataJoiner defines a transaction as being in one of three modes:

read only The transaction has not yet performed updates.

one phase The transaction can perform only single-site updates.

two phase The transaction can participate in two-phase commit processing.

All transactions start in read-only mode. If a transaction is in read-only mode and anattempt is made to update a data source that does not support two-phase commit, thetransaction is placed into a one-phase mode, and only updates to this data source arepermitted; other data sources can be accessed in read-only mode. If a transaction is inread-only mode and an attempt is made to update a data source that supports two-phasecommit, the transaction is placed into a two-phase mode, and updates can be performed toall data sources that are two-phase capable; data sources that are one-phase capable canbe accessed in read-only mode.

A new two-phase commit keyword with options Y (yes) or N (no) has been added to theOPTION column of the SYSCAT.SERVER_OPTIONS table. If the specification for thetwo-phase commit keyword is N, DataJoiner enforces single-site update regardless ofwhether or not the data source supports two-phase commit processing. If the transactionupdates this data source, no other data source can be updated, that is, the transaction isplaced in one-phase mode. This can improve performance because if two-phase commitprocessing is used, more XA calls and extra log records are written. If you know that theparticular data source is the only data source used or the only data source updated, youcan avoid this additional processing by enforcing a one-phase commit to this data source.

After a commit or roll back, the transaction is placed in read-only mode.

13.7.4 Application ImplicationsWhen you code a DB2 common server application you must know whether the two-phasecommit processing is enabled or not because the semantics of the SQL CONNECTstatement differ if you are using your application in a two-phase or one-phase commitprocessing environment. During precompilation of the DB2 common server application, youspecify whether the application will use one-phase or two-phase commit processing,through the SYNCPOINT precompiler option. The DB2 common server SET CLIENTcommand can override the precompiler option.

Regardless of what you specify during precompilation, Datajointer always tries to enforcetwo-phase commit processing when accessing DataJoiner data sources, unless the data


source does not support two-phase commit or because you have specified N in theSYSCAT.SERVER_OPTIONS table. You can override SYSCAT.SERVER_OPTIONS duringexecution, using the new Datajoiner SQL SET SERVER OPTION command before theconnection to the data source is established.

13.7.5 ProtocolsDifferent data sources use different two-phase commit protocols. DB2 common serverimplements presume abort, using flows that are equivalent to the X/Open XA standard.DataJoiner can use different protocols depending on the data source, for example, for datasources such as the DB2 for OS/390 server, it uses DRDA, and for Oracle and Informix datasources, it uses the XA protocol.

13.7.6 ResynchronizationIn case of a failure between DataJoiner and a data source, at startup, Datajoiner attemptsto resynchronize with the various RMs and subordinate TMs. If the resynchronization fails,DataJoiner during its normal processing periodically attempts to resynchronize to the RM orsubordinate TM on the basis of the database manager configuration parameter,RESYNC_INTERVAL.


Appendix A. Monitoring Commands

DB2 for OS/390 and DB2 UDB provide commands that you can use to monitor theconnection status. In this appendix we briefly describe these commands and show howthey are used.

A.1 DB2 for OS/390 Commands

The commands listed below can be used for TCP/IP and SNA connections. There are nospecial commands to monitor TCP/IP connections only.

• DISPLAY THREAD command

Use the DISPLAY THREAD command to display the current status of threads. Thethread status changes dynamically, and the information displayed by the DISPLAYTHREAD command changes according to the status.

You can display information about:

− Active threads− Distributed threads− Indoubt threads− Remote connections

Here is an example of the DISPLAY THREAD command:

DISPLAY THREAD(*) DETAIL LOCATION(*)

where:

The asterisk (*) value in the THREAD keyword represents all connection names. Aunique connection name can be specified.

The asterisk (*) value in the LOCATION keyword represents all locations. You canspecify an IP address, a location name, a partial location name, or a LU name. Youcannot specify a host name.

Specify the DETAIL option to get detailed information about the threads.

• DISPLAY LOCATION command

Use the DISPLAY LOCATION command to display information about threads andconversations with remote locations. You can specify a particular location or alllocations.

Here is an example of the DISPLAY LOCATION command:

DISPLAY LOCATION(129.33.160.112) DETAIL

where:


129.33.160.112 is the IP address of the remote location about which you want to getinformation. Instead of the IP address you can specify the location name or partiallocation name for TCP/IP connections. You cannot specify a host name value. The LUname value is valid only for SNA connections.

Specify the DETAIL option to get detailed information about the connection.

• CANCEL THREAD command

Use the CANCEL THREAD command to cancel the processing for specific local ordistributed threads. To cancel distributed threads, use the following command:

CANCEL DDF THREAD(token)

where:

token is a unique identifier for a specific thread. Instead of a token you can use theluwid. Use the DISPLAY THREAD DETAIL command to find the values of the token andthe luwid.

• RESET INDOUBT command

The RESET INDOUBT command purges information displayed in the indoubt threadreport generated by the DISPLAY THREAD command, but it does not resolve the indoubtthread, so be cautious when using this command.

Here is an example of the RESET INDOUBT command:

RESET INDOUBT IPADDR(9.12.14.207:34001)

where:

9.12.14.207:34001 are the IP address and resync port number related to the indoubtinformation to be purged.

Instead of the IPADDR keyword, you can use the LOCATION or LUWID keyword. Usethe LU name to purge indoubt information about SNA connections only.

• RECOVER INDOUBT command

The RECOVER INDOUBT command recovers indoubt threads. For indoubt threads thatuse TCP/IP connections, you can specify the IP address instead of the LU name.

For more information about DB2 for OS/390 commands, refer to the DB2 for OS/390 Version5 Command Reference.

A.2 DB2 for OS/390 Command Examples

In this section we present examples of commands to monitor connections where a DB2 forOS/390 (DB51) is an AR accessing a DB2 data sharing group (DSGC) AS using both TCP/IPand APPC protocols. It is possible to use both TCP/IP and APPC because the APPCconnection uses a three-part name.


Figure 73 on page 153 shows an example of the DISPLAY THREAD command issued at theDB51 AR.

� �=DB51 DIS THD(*) DETAIL LOCATION(DSGC)DSNV401I =DB51 DISPLAY THREAD REPORT FOLLOWS -DSNV402I =DB51 ACTIVE THREADS -NAME ST A REQ ID AUTHID PLAN ASID TOKENTSO TR 16 DB2RES3 DB2RES3 DSNESPCS 0100 299�1�V444-USIBMSC.SCPDBA1.AE7CB130DF5D=299 ACCESSING DATA AT V446-DSGC:9.12.14.207:34000 V447--LOCATION SESSID A ST TIME V448--DSGC �2�1125:34000 S2 9709917190872TSO TR 13 DB2RES3 DB2RES3 DSNESPCS 0100 300 V444-USIBMSC.SCPDBA1.AE7CB2D5ECB4=300 ACCESSING DATA AT�3�V446-DSGC:SCPDSGC V447--LOCATION SESSID A ST TIME V448--DSGC �4�ED13006A34C0A426 S3 9709917195480DISPLAY ACTIVE REPORT COMPLETEDSN9022I =DB51 DSNVDT ′ -DIS THD′ NORMAL COMPLETION� �

Figure 73. DISPLAY THREAD Command Issued from the AR

Message DSNV444 �1� shows that the SCPDBA1 (DB51) AR is accessing data at the DSGCdata sharing group AS. Message DSNV446 indicates that this connection is using theTCP/IP protocol with the following information about the AS:

• The location is DSGC.• The IP address is 9.12.14.207.• The AS port number is 34000.

Message DSNV448 �2� shows in the SESSID local port number 1125 and remote portnumber 34000. Note that the local port number is ephemeral.

For the APPC connection message DSNV446 �3� shows location DSGC and LU nameSCPDSGC instead of the IP address. Message DSNV448 �4� shows the VTAM session IDinstead of the port numbers.

Figure 74 on page 154 shows the result of a similar command issued at the data sharingmember AS DBC1.

Appendix A. Monitor ing Commands 153

� �=DBC1 DIS THD(*) DETAILDSNV401I =DBC1 DISPLAY THREAD REPORT FOLLOWS -DSNV402I =DBC1 ACTIVE THREADS -NAME ST A REQ ID AUTHID PLAN ASID TOKENTSO RA * 12 DB2RES3 DB2RES3 DSNESPCS 010D 2�1�V445-USIBMSC.SCPDBA1.AE7CB2D5ECB4=2 ACCESSING DATA FOR DB51:SCPDBA1 V447--LOCATION SESSID A ST TIME V448--DB51 �2�ED13006A34C0A426 W R3 9709917195481TSO RA * 11 DB2RES3 SILVIO DSNESPCS 010D 1�3�V445-USIBMSC.SCPDBA1.AE7CB130DF5D=1 ACCESSING DATA FOR 9.12.14.207 V447--LOCATION SESSID A ST TIME�4�V448--9.12.14.207 34000:1125 W R2 9709917190872DISPLAY ACTIVE REPORT COMPLETEDSN9022I =DBC1 DSNVDT ′ -DIS THD′ NORMAL COMPLETION� �

Figure 74. DISPLAY THREAD Command Issued from the AS

Message DSNV445 �1� shows that DSGC is accessing data on behalf of DB51 using theAPPC protocol. The AR LU name is SCPDBA1. Message DSNV448 shows that the VTAMsession ID �2� is the same as that displayed in Figure 73 on page 153.

Message DSNV445 �3� shows the TCP/IP connection indicating that the �4� IP address ofthe AR is 9.12.14.207. Message DSNV448 shows in the SESSID �4� the local AS portnumber (34000) and the remote AR ephemeral port number (1125).

Figure 75 shows the DISPLAY LOCATION command output issued from DB51 AR.

� � =DB51 DIS LOCATION(DSGC) DETAIL DSNL200I =DB51 DISPLAY LOCATION REPORT FOLLOWS- LOCATION PRDID LINKNAME REQUESTERS SERVERS CONVS�1�DSGC DSN05010 SCPDSGC 1 0 3�2�L203-SYSTASK SESSID A ST TIME

L204-SYSCON-O ED13006A34C0A427 S 9709917195377 L204-SYSCON-I ED13006A34C0A414 W R 9709917254341�3�DSGC DSN05010 9.12.14.207 1 0 1 DISPLAY LOCATION REPORT COMPLETE� �

Figure 75. DISPLAY LOCATION Command Issued from DB2 for OS/390 AR

The DISPLAY LOCATION command indicates the role of this DB2 subsystem as an AR or anAS and the number of conversations.

�1� shows location DB51 with one active thread as an AR (REQUESTERS column) and threeconversations (CONVS column) with location DSGC. Because this information is for the


APPC protocol, the LINKNAME shows the LU name (SCPDSGC) of the AS. There are threeconversations because DB2 is using system-directed access (three-part name) for thisrequest. When using system-directed access, DB2 creates conversations used for systemcommunication, as shown in �2�. A conversation is created to manage ″outbound″communication, and another conversation is created to manage ″inbound″ communication.That is why there are three conversations: two conversations used for systemcommunication and one conversation used for SQL processing.

Instead of a remote LU name, the remote IP address 9.12.14.207 is shown �3�, whichindicates the use of the TCP/IP protocol. Location DB51 has one active thread(REQUESTERS column) and one conversation (CONVS column) with the DSGC locationusing TCP/IP protocol.

Figure 76 shows the DISPLAY LOCATION command output issued from the DBC1 AS.

� � =DBC1 DIS LOCATION DETAIL DSNL200I =DBC1 DISPLAY LOCATION REPORT FOLLOWS- 519 LOCATION PRDID LINKNAME REQUESTERS SERVERS CONVS�1�DB51 DSN05010 SCPDBA1 0 1 3�2�L203-SYSTASK SESSID A ST TIME

L204-SYSCON-O ED13006A34C0A414 S 9709917195378 L204-SYSCON-I ED13006A34C0A427 W R 9709917195377�3�9.12.14.207 9.12.14.207 0 1 1 DISPLAY LOCATION REPORT COMPLETE� �

Figure 76. DISPLAY LOCATION Command Issued from DB2 Data Sharing Member AS

Location DBC1 has one active thread as an AS (SERVERS column) and three conversations(CONVS column) with the DB51 location �1�. Because this information is for the APPCprotocol, the LINKNAME shows the LU name (SCPDBA1) of the AR. There are threeconversations because the DB2 AR is using system-directed access for this request. Whenusing system-directed access, DB2 creates conversations used for system communication,as shown in �2�. So, there are three conversations—two for system communication and onefor SQL processing.

�3� shows the connection using TCP/IP protocol, where DBC1 has one active thread(SERVERS column) and one conversation (CONVS column) with IP address 9.12.14.207,which is the AR IP address. Note that the IP address of the AR is displayed instead of alocation name.

Figure 77 on page 156 shows the NETSTAT command. For these examples both DB2 forOS/390s were on the same MVS system.


� �User Id Conn Local Socket Foreign Socket State---- -- ---- ----- ------ ------- ------ -----�1�OMVS 1008 9.12.14.207..446 *..* Listen�2�OMVS 1007 9.12.14.207..1125 9.12.14.207..34000 Established�3�OMVS 1012 9.12.14.207..34000 *..* Listen�4�OMVS 1011 9.12.14.207..34000 9.12.14.207..1125 Established� �

Figure 77. NETSTAT Command Issued on the MVS Platform

�1� shows that DB51, which has IP address 9.12.14.207 and port number 446, is waiting for aconnection request from any remote TCP/IP address using any port number. This isindicated in the State column by the Listen value.

�2� indicates an open connection for DB51 using ephemeral port number 1125. As far asTCP/IP is concerned, this is an active connection, as indicated in the State column by theEstablished value. From DB2 for OS/390 commands we know that DB51 is the AR.

�3� shows that DBC1, which has IP address 9.12.14.207 and port number 34000, is waitingfor a connection request from any remote TCP/IP address using any port number. This isindicated in the State column by the Listen value.

�4� indicates an open connection for DBC1, using SQL port number 34000. As far as TCP/IPis concerned, this is an active connection, as indicated in the State column by theEstablished value. From DB2 for OS/390 commands we know that DBC1 is the AS.

Figure 78 shows the output for the following PING command issued in a TSO session:

TSO PING WTSC48.ITSO.IBM.COM

Although not related to the connection between the AR and AS, the PING command enablesyou to check whether a particular host has TCP/IP access to some other host in thenetwork.

Note that the host name, WTSC48.ITSO.IBM.COM, was translated into the 9.12.14.207 IPaddress.

� �Ping V3R2: Pinging host WTSC48.ITSO.IBM.COM (9.12.14.207). Use ATTN tointerrupt.PING: Ping #1 response took 0.015 seconds. Successes so far 1.� �

Figure 78. PING Command Output from a TSO Session


A.3 DB2 UDB Commands

In this section we list some common UDB commands used to monitor local and remoteconnection states. We provide the format and some examples when the commands wereissued using CLP.

• GET CONNECTION STATE

The GET CONNECTION STATE command is valid for the Windows NT, AIX, and OS/2platforms. It displays the connection state for local and remote connections. It requiresSYSADM or SYSCTRL authority. The status of a connection can be:

• Connectable and connected

• Connectable and unconnected

• Unconnectable and connected

• Implicitly connectable (if implicit connect is available)

Connectable and connected status indicates that an application process is connected to aserver and a CONNECT TO statement can be executed.

Connectable and unconnected status indicates that an application process is not connectedto a server, but a CONNECT TO statement can be executed.

Unconnectable and connected status indicates that an application process is connected to aserver, but no other CONNECT TO statements can be executed to change the server.

Implicitly connectable status is the initial state of an application process. This statusindicates that CONNECT RESET has been issued, or a DISCONNECT statement has beenissued after a COMMIT or ROLLBACK.

The format of this command is:

GET CONNECTION STATE

Figure 79 on page 158 shows sample output from GET CONNECTION STATE, after asuccessful connection from Windows NT to a remote DB2 for OS/390 AS (DB51T).


� �db2 => get connection state

Database Connection State

Connection state = Connectable and Connected Connection mode = SHARE Local database alias = DB51T Database name = DB51T� �

Figure 79. GET CONNECTION STATE Output

• LIST APPLICATIONS

The LIST APPLICATIONS is command is valid for the AIX, Windows NT, and OS/2 platforms.It displays the:

• Authorization ID• Application name• Application handle• Application ID• Database name

It requires SYSADM, SYSCTRL, or SYSMAINT authority.

The command syntax is:

LIST APPLICATIONS

or

LIST APPLICATIONS SHOW DETAIL

or

LIST APPLICATIONS FOR DATABASE database-alias SHOW DETAIL

Figure 80 on page 159 shows sample output obtained on Windows NT after two connectionswere established: a remote connection coming from DB51T (DB2 for OS/390 database) toSAMPN local database using a TCP/IP connection and a local connection to SAMPLE. Bothconnections are shown for database SAMPLE because SAMPN is an alias for the localdatabase, SAMPLE.


� � db2 => list applications

Auth Application Appl. Application Id DBId Name Handle Name ------ -------------- -------- -------------------------- ------- DB2 DB2RES2 .B 2162688 090C0ECF.9704.092058246204 SAMPLE DB2 db2bp.exe 2228224 *LOCAL.DB2.970409211350 SAMPLE� �

Figure 80. LIST APPLICATIONS Output

The Application Id for the connection coming from DB51T provides a local ID for the thread.It is not the same as the LUWID that is shown on DB2 for OS/390 when the DISPLAYTHREAD command is issued.

• LIST DRDA INDOUBT TRANSACTIONS

The LIST DRDA INDOUBT TRANSACTIONS command is valid for AIX, Windows NT, andOS/2 platforms. It provides a list of indoubt transactions. It is similar to the DB2 for OS/390DISPLAY THREAD TYPE(INDOUBT) command. You must have SYSADM authority to issuethis command. This command requires a connection to an instance. The WITHPROMPTING parameter starts an interactive dialog mode. The interactive dialog modeallows you to list all indoubt transactions and the handle number, commit or roll back thetransactions, and quit the command.

The format of this command is:

LIST DRDA INDOUBT TRANSACTIONSorLIST DRDA INDOUBT TRANSACTIONS WITH PROMPTING

To gather information about INDOUBT transactions with this command, you must beconnected to the SPM instance. You must set the spm_name database managerconfiguration file parameter and connect to it.

• GET AUTHORIZATIONS

The GET AUTHORIZATIONS command is valid for the AIX, OS/2, and Windows NT platforms.It reports the authority of the current user as registered in the database managerconfiguration file and SYSCAT.DBAUTH catalog table. It does not require any specialauthorization to be executed. It requires a connection to a database, local or remote. If noconnection exists, this command implicitly connects to the default database. This commandcan be executed when connected to remote databases only if the remote database supportsthis function. For example, if you issue the GET AUTHORIZATIONS command whenconnected to a DB2 for OS/390 AS, you receive message SQL1325N stating that the remotedatabase environment does not support the command.


The syntax of this command is:

GET AUTHORIZATIONS

Figure 81 shows sample output obtained for a user connected from DB2 on the AIX platformto the Windows NT SAMPLE database.

� �$ db2 get authorizations

Administrative Authorizations for Current User

Direct SYSADM authority = NO Direct SYSCTRL authority = NO Direct SYSMAINT authority = NO Direct DBADM authority = YES Direct CREATETAB authority = YES Direct BINDADD authority = YES Direct CONNECT authority = YES Direct CREATE_NOT_FENC authority = YES Direct IMPLICIT_SCHEMA authority = YES

Indirect SYSADM authority = YES Indirect SYSCTRL authority = NO Indirect SYSMAINT authority = NO Indirect DBADM authority = NO Indirect CREATETAB authority = YES Indirect BINDADD authority = YES Indirect CONNECT authority = YES Indirect CREATE_NOT_FENC authority = NO Indirect IMPLICIT_SCHEMA authority = YES� �

Figure 81. GET AUTHORIZATIONS Output

• LIST COMMAND OPTIONS

The LIST COMMAND OPTIONS command is valid for the AIX, OS/2, and Windows NTplatforms. It does not require any special authorization level. It lists the current settingsfor the following environment variables:

• DB2BQTIME

• DB2BQTRY

• DB2RQTIME

• DB2IQTIME

• DB2OPTIONS


The DB2OPTIONS environment variable is usually customized to facilitate problemdetermination. For example, option -a set to ON displays the SQLCA, the option -e set toON displays the SQLCODE/SQLSTATE, and option -r saves the output in a history file.

The format of the command is:

LIST COMMAND OPTIONS


� �$ db2 list command options

Command Line Processor Option Settings

Backend process wait time (seconds) (DB2BQTIME) = 1 No. of retries to connect to backend (DB2BQTRY) = 60 Request queue wait time (seconds) (DB2RQTIME) = 5 Input queue wait time (seconds) (DB2IQTIME) = 5 Command options (DB2OPTIONS) =

Option Description Current Setting------ ---------------------------------------- ----------------a Display SQLCA OFF-c Auto-Commit ON-e Display SQLCODE/SQLSTATE OFF-f Read from input file OFF-l Log commands in history file OFF-o Display output ON-p Display interactive input prompt ON-r Save output to report file OFF-s Stop execution on command error OFF-t Set statement termination character OFF-v Echo current command OFF-w Display FETCH/SELECT warning messages ON-z Save all output to output file OFF� �

Figure 82. LIST COMMAND OPTIONS Output

You can customize the DB2OPTIONS variable, using the UPDATE COMMAND OPTIONScommand available in UDB. Figure 83 on page 162 shows the output when you issue aCLP command and set the -a option to ON to display the SQLCA.


� �db2=> connect to sample

Database Connection Information

Database product = DB2/NT 5.0.0 SQL authorization ID = DB2 Local database alias = SAMPLE

SQLCA Information

sqlcaid : SQLCA sqlcabc: 136 sqlcode: 0 sqlerrml: 51 sqlerrmc: 11252DB2 SAMPLE QDB2/NT27525124201252 sqlerrp : SQL03010 sqlerrd : (1) 1 (2) 1 (3) 1

(4) 1 (5) 0 (6) 0 sqlwarn : (1) (2) (3) (4) (5) (6)

(7) (8) (9) (10) (11) sqlstate: 00000� �

Figure 83. Displaying the SCA with CLP


Appendix B. Problem Determination

In this appendix we list some methods to track and solve communication problems. Formore information, refer to the DB2 for OS/390 and DB2 UDB manuals.

B.1 UDB Troubleshooting

In this section we describe the most common methods for UDB problem determination.

B.1.1 DB2DIAG.LOG

Various logging facilities are available on all platforms supported by DB2. First Failure DataCapture (FFDC) is diagnostic information captured by DB2 about an error condition whenthe error occurs. FFDC does not report all details, but it ensures that some records aboutfailure are dumped into files.

DB2DIAG.LOG is one of the files updated with information about the error. The amount ofinformation recorded on the DB2DIAG.LOG depends on what you specify for DIAGLEVEL, adatabase manager configuration parameter that specifies the level of FFDC-collectedinformation. Possible values are:

• DIAGLEVEL (0) - no diagnostic data

• DIAGLEVEL (1) - severe errors only

• DIAGLEVEL (2) - all errors, severe and not severe

• DIAGLEVEL (3) - all errors and warnings (default)

• DIAGLEVEL (4) - all errors, warnings, and informational messages

DIAGPATH is a database manager configuration parameter that contains the value of thesubdirectory where dumps, error logs, and alert log files are written. The subdirectory canbe automatically created by DB2 UDB. If this parameter is not specified, it defaults to:

• db2path\instance where DB2PATH and DB2INSTANCE are two environment variables, ifthe DB2INSTPROF environment variable is not set.

• x:\db2instprof\db2instance, where DB2INSTPROF is the environment variable containingthe ID of the instance owner.

The DB2DIAG.LOG file can be accessed with a local editor. As an example, we simulated acommunication error during a DRDA TCP/IP connection from Windows NT to the host DB2for OS/390 location DB51T AS, where DDF was not started. On the DB2 UDB CLP, wereceived the following error message:


db2 => connect to db51t user silvioEnter password for silvio:SQL30081N A communication error has been detected. Communicationprotocol being used: ″TCP/IP″ . Communication API being used: ″SOCKETS″ .Location where the error was detected: ″″ . Communication functiondetecting the error:″recv″ . Protocol specific error code(s): ″10061″,″*″, ″0″. SQLSTATE=08001.

Here is the FFDC entry collected in the DB2DIAG.LOG file:

1997*02*14*11.44.04.461000DB2 pid(189) tid(193) process (db2bp.exe)common_communication sqlcctcpconnr Probe:101DIA3202C The TCP/IP call ″connect″ returned an errno=″10061″.

where sqlcctcpconnr is the function name, and DIA3202C is the diagnostic message with anexplanation of the error.

The er rno=″10061″ is a protocol-specific error code on Intel-based machines. According tothe DB2 Messages Reference manual, this TCP/IP error code corresponds to anECONNREFUSED condition, that is, the connection has been refused. If you are trying toconnect to a database, you must check that the TCP/IP protocol support at both the AS andAR are successfully started.

B.1.2 DB2 Trace Facility

You may want to gather more information for a failure if the message on the DB2 UDBcommand line or the DB2DIAG.LOG file information is not enough. You can trace events onall DB2 UDB platforms, using the DB2 trace facility (db2trc ). This facility traces events,dumps trace data to a file, and formats trace data into a readable form. It starts in memory,but you can place trace data in a file when you invoke the trace or after collecting traceddata. Use this facility only when the error conditions are predictable and repeatablebecause it affects DB2 performance. You need SYSADM, SYSCTRL, or SYSMAINT authorityto invoke the DB2 trace facility.

The syntax for invoking the trace is:

db2trc (chg|clr|dmp|flw|fmt|inf|off|on) options

chg|change change the trace mask, maxSysErrors or maxRecordSizeclr|clear clear the tracedmp|dump dump the trace to a binary trace fileflw|flow show control flow of the tracefmt|format format the traceinf|info|information get information on the traceoff turn the trace offon turn the trace on


Here is an example of db2trc invoked for the same communication problem on the WindowsNT platform:

db2trc on <<<< activate the traceconnect to db51t <<<< failure during connectiondb2trc dump db2trc.dmp <<<< trace from memory to a filedb2trc flw db2trc.dmp > db2trc.fmt <<<< trace formattinge db2trc.fmt <<<< check the contents

Editing the db2trc.fmt file, we found the trace entries shown in Figure 84. If required, tracedata can be requested as documentation from IBM product support people.

1054 | | | | | | | | | | | | |sqlcctcpconnr fnc_data ...1055 | | | | | | | | | | | | |sqlcctcpconnr fnc_data ...1056 | | | | | | | | | | | | |sqlcctcpconnr fnc_retcode 0x0036 = 541057 | | | | | | | | | | | |sqlccconnr cei_data ...1058 | | | | | | | | | | | |sqlccconnr cei_retcode 0x0036 = 541059 | | | | | | | | | | | |sqljmctk fnc_entry ...1060 | | | | | | | | | | | |sqljmctk fnc_data ...1061 | | | | | | | | | | | | |sqlofica cei_entry ...1062 | | | | | | | | | | | | |sqlofica cei_retcode 01063 | | | | | | | | | | | |sqljmctk fnc_retcode 01064 | | | | | | | | | | |sqljicrd non-fatal_err...1065 | | | | | | | | | | | |connect error fnc_entry ...1066 | | | | | | | | | | | |connect error fnc_data ...1067 | | | | | | | | | | | |connect error fnc_retcode 0x0036 = 54

Figure 84. Example of Trace Entries in an Output File

The sqlcctcpconnr function is the same found in the DB2DIAG.LOG file. According to theTCP/IP Messages and Codes manual, fnc_retcode represents a TCP/IP system error code 54corresponding to ECONNRESET. This condition indicates that the connection to the host isnot available, confirming the refusal of the connection.

You can also start the db2trc trace facility from the Problem Determination folder ofWindows NT and OS/2.

B.1.3 DRDA Trace

You can use the DRDA trace (db2drdat ) to capture DRDA data streaming between the ARand the AS. This trace is used to determine how many sends and receives are required toexecute an application and can be useful as a tool for performance tuning. The syntax ofthe command is:

Appendix B. Problem Determination 165

SYNTAX:db2drdat on (-i) (-c) (-r) (-s) (-l=LENGTH)db2drdat off (-t=TRACEFILE) (-p=PROCESSID)

WHERE:on - Turns the DRDA trace onoff - Turns the DRDA trace off-i - Include timestamps-c - Trace SQLCAs-r - Trace DRDA receive buffers-s - Trace DRDA send buffers-l=LENGTH - LENGTH is the size of the trace buffer. The default

value is one megabyte.-t=TRACEFILE - TRACEFILE is the file name where the captured trace

will be stored. The default file name isdb2drdat.dmp.

-p=PROCESSID - PROCESSID is the ID of a process to be traced.If PROCESSID is not specified, all process IDsfor the DB2 instance are traced.

We issued the following commands to get the db2drdat trace entries:

db2drdat on -r -s <<<< both sends and receives are tracedconnect to db51t user silvio <<<< failing connectiondb2drdat off -t=db2drdat.trc <<<< stop & dump trace to a filee db2drdat.trc <<<< to verify the contents

We got the following information in our db2drdat.trc file:

DB2 fnc_data gateway_drda_ar connect error (1.35.10.127)pid 198; tid 191; cpid 0; time 69094622; trace_point 182COMMUNICATIONS ERROR

INIT FUNCTION RC = 54SEVERITY = 8PROTOCOL USED = TCP/IPAPI USED = SOCKETSNETID.LOCALLUNAME =FAILED CPIC FUNCTION = connectCPIC RETURN CODE = 10061ERROR NUMBER ON AIX = *INTERNAL CCI RET CODE = *

For our sample connection failure, the DRDA trace provides in the FAILED CPIC FUNCTIONthe SQL CONNECT statement and in the CPIC RETURN CODE the same return codecontained in the DB2DIAG.LOG file.


B.1.4 Possible Causes

SQL30081N is a common message when there is a DRDA communication problem. ForTCP/IP, this error code indicates that the client cannot find the server, or the connectionhas been refused. From SQL30081N message, DB2DIAG.LOG file, and DB2TRC file that theconnection was refused because either the AS or the TCP/IP protocol support was notsuccessfully started.

The first action is to check the network connectivity between the requester and target host.You can use the PING command to check for TCP/IP connectivity. Here is the output of asuccessful PING command issued on a workstation:

C:\>ping 9.12.14.54

Pinging 9.12.14.54 with 32 bytes of data:

Reply from 9.12.14.54: bytes=32 time=160ms TTL=51Reply from 9.12.14.54: bytes=32 time=200ms TTL=51Reply from 9.12.14.54: bytes=32 time=170ms TTL=51

If the target host responds to the PING command, you should verify that the TCP/IP port iscorrectly defined on the requester services file. If the ping is successful, you can direct thediagnosis to the target relational database.

As a general rule, for an SQL30081N communication error message, check that TCP/IP isstarted on both the client and server and that the server DBMS is up and ready for theconnection. Ensure that TCP/IP is included on the server configuration.

• If UDB is the AS, check the value of database manager configuration file parameterSVCENAME and the setting of the DB2COMM environment variable.

− For OS/2, Windows 95, and Windows NT, use the DB2SET command to verify thatTCP/IP is set in the DB2COMM variable.

− On AIX, ensure that the “profile” file includes the line with DB2COMM=TCPIP.

• If UDB is the AR check that the:

− Local node directory contains the connect host name or IP address for the AS

− Local TCP/IP services file does not contain any end-of-file marker after your portsetting.

B.1.5 DB2 Connect Trace

The ddcstrc trace provides a record of the data interchanged between the DB2 Connectworkstation and the DRDA AS.


You may find it is useful to understand how this flow of data works because such knowledgecan help you determine the origin of a particular problem. In our example, we issued aCONNECT TO database statement for a DRDA server database, but the command failed andwe received an unsuccessful return code. If you can understand exactly what informationwas conveyed to the DRDA server DBMS, you may be able to determine the cause of thefailure even if the return code information is general. Many failures are caused by simpleuser errors.

The output from the ddcstrc trace lists the data streams exchanged between the ARworkstation and the DRDA AS. Data sent to the DRDA AS is labeled SEND BUFFER anddata received from the DRDA server is labeled RECEIVE BUFFER. Here is the syntax toinvoke the ddcstrc trace:

SYNTAX:ddcstrc on (-i) (-c) (-r) (-s) (-l=LENGTH)ddcstrc off (-t=TRACEFILE) (-p=PROCESSID)

WHERE:on - Turns the DRDA trace onoff - Turns the DRDA trace off-i - Include timestamps-c - Trace SQLCAs-r - Trace DRDA receive buffers-s - Trace DRDA send buffers-l=LENGTH - LENGTH is the size of the trace buffer. The default

value is one megabyte.-t=TRACEFILE - TRACEFILE is the file name where the captured trace

will be stored. The default file name is ddcstrc.dmp.-p=PROCESSID - PROCESSID is the ID of a process to be traced. If

PROCESSID is not specified, all process IDs for theDB2 instance are traced.

In a successful connection, you can find the following information:

• The process ID (PID) of the client application

• The RDBNAME cataloged in the database connection services (DCS) directory

• The AR coded character set identifiers (CCSIDs)

• The DRDA server CCSIDs

• The DRDA AS system with which the DB2 Connect AR is communicating.


B.1.6 Bind Errors

In this section we describe some bind errors that can occur when binding from DB2 forOS/390 to a remote UDB server (refer to Table 9 on page 65 to see the bind optionsavailable when binding from DB2 for OS/390 to a UDB AS). Figure 85 on page 169 is theJCL that we used to bind from DB2 to the UDB AIX server.

//JOBLIB DD DISP=SHR,// DSN=DSN510.SDSNLOAD//DSNTIAS EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(4,LT)//DBRMLIB DD DSN=DSN510.SDSNDBRM,DISP=SHR//SYSTSPRT DD SYSOUT=*//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSTSIN DD * DSN SYSTEM(DB51)BIND PACKAGE (SAMPX.DSNESPCS) MEMBER(DSNESM68) ACT(ADD) ISO(CS) -VALIDATE (BIND)

Figure 85. BIND JCL Example

We used the ACT(ADD) option, which is not supported on the UDB for AIX platform. Our jobended with these messages:

DSNT270I =DB51 THE FOLLOWING SQLCA INFORMATION WAS RETURNED FROMSQLJPSEM

SQLCODE = -4930SQLSTATE =SQLERRMT = ACTION ADD (DRDA Bind Option

PKGRPLOPT(PKGRPLNA))SQLWARN 0= ,1= ,2= ,3= ,4= ,5= ,6= ,7= ,8= ,9= ,A=

DSNT233I =DB51 UNSUCCESSFUL BIND FORPACKAGE = SAMPX.DSNESPCS.DSNESM68.()

From the output of the job, in message DSNT270I, the SQLCODE -4930 was not directlyreturned by DB2 for OS/390. This SQLCODE was returned by DB2 UDB.

You can issue the ? sql4930 on CLP to get a more complete text for the -4930 SQLCODE:

SQL4930N Bind or precompile option or option value″<option-name>″ is invalid.

Cause: Either ″<option-name>″ is an invalid bind orprecompile option or the value specified for this option isinvalid. The bind or precompile cannot continue.


Action: Correct the bind or precompile option or optionvalue and retry the bind or precompile command.

Using the ddcstrc or db2drdat commands, you can collect more information from the SQLCA(you must start the ddcstrc trace with -c option):

DB2 fnc_data drda_as sqljg_sqlcagrp_len (1.35.75.108)pid 18754; tid 1; node 0; cpid 0; sec 860093067;nsec 507631232; tpoint 179SQLCASQLCAID: SQLCASQLCABC: 136SQLCODE: -4930SQLERRML: 50SQLERRMC: ACTION ADD (DRDA Bind Option PKGRPLOPT(PKGRPLNA))SQLERRP: SQLJPSEMSQLERRD(0->5): FFFFFFF4, 00000000, 00000000,

00000000, 00000000, 00000000SQLWARN(0->A): , , , , , , , , , ,SQLSTATE:

For further information and an example of the ddcstrc trace utility, see the DB2 ConnectUser′s Guide. For further information on connectivity problems, refer to the IBM DB2 UDBTroubleshooting Guide and IBM DB2 Connect Troubleshooting Guide.

B.2 System-Based Troubleshooting Actions

Each UDB platform, AIX, OS/2, and Windows, provides system tools to help in problemdetermination and performance analysis. Here is a brief description of these tools,arranged by platform.

B.2.1 UNIX

Diagnostic tools available include:

• System error log (SYSLOG)

DB2 UDB logs error and warning conditions to the SYSLOG. The generated messagesappear in the file specified in the /etc/syslog.conf file. Each DB2 entry consists offollowing information:

− Date− Time− Host name− “DB2” identif ier− Process ID of reporting process− Instance name


− Node number− Reporting component− Reporting function− Probeid− Error_num− Alert_num

• Core File

A core file is created when a severe error occurs. A memory image of the currentterminating process is saved. This core dump is usually caused by memory addressviolations, illegal instructions, bus errors, and user generated signals. The dbx function(or xdb for HP-UX operating systems) is used to access the core file information.

• Process start utility (ps)

The ps utility returns process status information for active processes. Without flags, theps utility displays all information about the current shell. The ps utility may degradeperformance. Use the map ps command to verify all flags available.

B.2.2 OS/2

The more commonly used tools are:

• first failure support technology (FFST)

FFST for OS/2 captures error data as it occurs. It also routes SNA generic alerts to aspecific dump file, over an SNA session to a host, or to a LAN alert connection facility.DB2 UDB accesses the FFST for OS/2, so the OS/2 logging facility provides records oferror information for problem determination. The syslog command allows you tosuspend or resume logging.

• pstat command

The pstat command returns process status information on the threads running on thesystem, with their status and priorities. The main processes of database components ofUDB are:

− db2pfchr , servers for input/output

− db2pcinr , buffer pool page cleaner

− db2loggr , logger for DB2 logging facilities

− db2dlock , deadlock detector

− db2sysc , DB2 system controller

− db2resyn , resync agent that scans the global resync list

− db2gds , global daemon spawner on UNIX system, starts new processes

− db2wdog , handles abnormal terminations


− db2fcmdm , handles internode communication, used only in UDB ExtendedEnterprise Edition

− db2pdbc , handles parallel requests from remote nodes

− db2panic , for “unexpected” occurrences, used only in DB2 UDB Extended Edition

B.2.3 Windows

The following tools are available for Windows 3.1 and Windows 95 operating systems.

• Dr. Watson

You start this utility by typing drwatson on the command line. The utility is invoked inthe event of a general protection fault (GPF). It logs data for problem diagnosis in a file.

• DB2 - supplied tools

For Windows 95, DB2 provides administrative and development tools to identify DB2problems. These tools are accessed from the Server Administration folder. For systemerrors, the Event Analyzer allows you to get and filter registered events.

• ODBC/CLI traces

These traces are helpful for identifying problems with CLI and ODBC applications thatconnect to DB2 using the CLI driver. To activate this trace facility, add the followinglines in the common section of the DB2CLI.INI initialization file:

{COMMON}TRACE=1TRACEFILENAME=C:\TRACES\CLI\APPLE.CLITRACEFLUSH=1

For the above example, TRACE=1 turns on the trace facility; APPLE.CLI will be the filecontaining the trace data; TRACEFLUSH=1 writes files to disk each time they areupdated.

• Windows NT Administrative tools

From the Windows NT Administrative tools menu, you can obtain:

− System errors, by selecting Event Viewer

− Performance statistics, by selecting Performance Monitor

− User accounts, by selecting User Manager

− Problem diagnosis, by selecting Windows NT Diagnostics

B.3 TCP/IP Commands - Workstation

TCP/IP provides tools and commands to monitor the network and obtain services statistics.In this section, we consider the available TCP/IP commands for the workstation platform.


We distinguish these commands in three categories: network management commands, hostname resolution commands, and routing commands.

B.3.1 Network Management Commands

We describe here only those commands that are meaningful for DRDA networking problemdetermination.

• IPTRACE command

The IPTRACE command is available only on the OS/2 platform. It is used to trace thepackets received from and sent to an interface. Use the command only when a problemcan be easily re-created. Stop the trace as soon as the problem reoccurs. Thecommand writes to an iptrace.dmp file, which is created in the subdirectory where thecommand is issued, and continues writing without checking for sufficient disk space.This command can have an adverse impact on performance. The format of theIPTRACE command is:

iptrace -i interface1 interface2 interfacen

The -i flag specifies that only IP packets must be traced, not every hardware interfaceframe. You can provide the adapter interface name for which the trace must be started;otherwise all interfaces are traced.

The following trace is started from the OS/2 command line and stopped by pressingEnter on the same session:

C:\′ iptracelan0: tracing enabled lan0:( 0.000): process_pkt: len=521, type=9 lan0:( 0.093): process_pkt: len=521, type=9 lan0:( 0.094): process_pkt: len=521, type=9 lan0:( 0.125): process_pkt: len=506, type=9

lan0: tracing disabledthe ip trace taken

• IPFORMAT command

The IPFORMAT command is available only on the OS/2 platform and is used to formatthe iptrace data into a readable form. The syntax of the IPFORMAT command is:


IPFORMAT (-a)(-d)(-f<file>)(-h)(-n)(-s<hwaddress>)(-x)(data can be piped to a file (>filename) for browsing using an editor)-a Don′ t format ARP/RARP packets-d Don′ t display data portion of packet-f<input file> (default IPTRACE.DMP)-h display raw data packet after formatted info-n Don′ t display hex data for unknown data type-s ONLY format data for <hwaddress> (Source or Destination)

where hwaddress is the 12 digit hex addressie: 123456789ABC

-x Convert datafile to ″Sniffer″ format file

The formatted iptrace contains the source and destination port number, the source andtarget IP addresses, ARP protocol information, and the data portion of the IP datagrams.

• NETSTAT command

The NETSTAT command is available on the OS/2, Windows, and AIX platforms. Itdisplays the network status of the local workstation. It provides information aboutTCP/IP connections, memory, buffers, and sockets usage and statistics about UDP andIP. The syntax is:

Usage: netstat ( -? ) / ( -mtuisprcna )

Where:m - mbufst - tcpu - udpi - ips - socketsr - routesc - icmpn - interfacesa - addressp - arp? - help

We used this command to verify the status of connections from a DB2 Connect AR to aDB2 for OS/390 AS or to a data sharing group acting as an AS to check how theconnections are distributed through the DB2 members. Here is the result of theNETSTAT command from the Windows NT platform after a successful connection toremote location DB51T, using the TCP/IP protocol:

Active Connections

Proto Local Address Foreign Address StateTCP 127.0.0.1:1026 127.0.0.1:1027 ESTABLISHEDTCP 127.0.0.1:1027 127.0.0.1:1026 ESTABLISHEDTCP 129.33.160.161:1059 9.12.14.207:446 ESTABLISHED


Our connection is represented on the third line. The local address consists of the localworkstation IP address and local TCP ephemeral port number (1059). The foreignaddress consists of the remote DB2 IP address and the DB2 for OS/390 port number(446), both defined in the local UDB node directory.

• PING

The PING command sends echo requests to a remote host to determine whether thehost is accessible with the current TCP/IP definitions. It is commonly used when an IPaddress in the local or remote network changes and new definitions should be checked.The format of the PING command is:

Usage: ping (-?drv) <host> (size (packets))

Where:d - Turn debug on.r - Bypass the normal routing tables.v - Verbose output. Include all ICMP packets received.host - Destination.size - The size of data portion of the packet.packets - The number of Echo Request packets to send.

The PING command is available on all workstation platforms. It is issued on theoperating system command line, and its activity stops when the process is canceled byan interrupt (CTRL+C). The TCP/IP for OS/2 platform provides a GUI to invoke thePING command:

1. Double-click on the OS/2 System icon on the desktop

2. Double-click on the TCP/IP icon on OS/2 System folder

3. Double-click on the TCP/IP Utilities icon.

The window shown in Figure 86 is displayed.

Figure 86. TCP/IP Utilit ies - Icon View


B.3.2 Simple Network Management Protocol Support

Before describing the DB2 SNMP subagent, let us first discuss the basic concepts of theSNMP protocol.

The TCP/IP suite does not have a standard protocol for communicating networkmanagement information. Two standard drafts are recommended: Simple NetworkManagement Protocol (SNMP) and CMIP Over TCP (CMOT).

Figure 87 shows the positioning of the recommended drafts.

Figure 87. Simple Network Management Protocol and CMOT

UDB and DB2 for OS/390 do not provide support for CMOT. DB2 for AIX and DB2 for OS/2Version 2 support SNMP management processes.

SNMP is a protocol used by network elements such as hosts and bridges to exchangeinformation about network management. The resources that are supervised and controlledby network management are called managed objects. Software, as buffer managementroutines or an organized pool of data, can be treated as managed objects.

Managed objects are managed by a management process, which is an application process.The management process is logically divided into a managing process and an agentprocess. The managing process requests functions to be performed on the managedobjects, and the second agent process performs these functions on the managed objects.The communication among the managing process, agent process, and managed objects isthrough management operations and notifications, as shown in Figure 88.

Figure 88. Management Process


We can position the UDB components in Figure 88 and see how they are related:

• The managing process is SNMP itself.

• The agent process protocol function is provided by the DB2 SNMP subagent component(see B.3.2.1, “DB2 SNMP Subagent” on page 178).

• The managed objects are databases, database servers, DBMS configurationparameters, and other pools of data.

The management information base (MIB) is the structure where descriptions of managedobjects are passed between UDB and the SNMP.

MIB is defined by the RFC_1697 Internet standard protocol, for use with the networkmanagement protocols in the Internet community. RFC_1697 provides the MIB standardstructure containing the descriptions of objects to manage relational databases.

Figure 89 is a logical view of DB2 subagent processing.

Figure 89. DB2 Subagent Processing

UDB support for the SNMP protocol allows a single view of database and systemmanagement for complex systems of distributed database servers.


B.3.2.1 DB2 SNMP Subagent: The DB2 SNMP subagent component of UDB sendsSNMP traps to notify the management console when a condition that requires operatorattention and DBMS instance recovery function, that detects all databases and DBMSinstances at a given server.

With SNMP subagent support for DB2, an SNMP subsystem management product can beused to monitor database status, configuration, and some performances attributes. SNMPsystems management products are implemented in many network products, such as IBMNetView for OS/2, IBM NetView/6000, and the SNMPTRAP utility provided by TCP/IP forOS/2, as well as SNMP support provided by TCP/IP for MVS in the OS/390 environment.

SNMP managers have facilities that periodically sample some attributes, check their valuesagainst predefined thresholds, and issue alerts or take actions if exceptions exist. Anexample of this use is the control of current connections to a DBMS.

These attributes are listed in the MIB structure and can contain the following attributes:

• Database product name, version, and release

• Date and time of last backup

• Database manager and database configuration parameter values

• Database and database manager limits

• Number of database reads and writes

• Number of pages read/write

• Number of SQL statements processed

• Number of SQL statements received and sent

• High-water mark for registered agents in the database

• Maximum number of registered agents

• Current state of database

The DB2 SNMP subagent can also send alerts for critical database conditions.

The standard for all object identifiers in the MIB structure is a subset of Abstract SyntaxNotation One (ASN.1) defined in RFC_1442. Windows, AIX, and OS/2 SNMP managersystems provide commands to personalize the MIB structure, activate SNMP traps, andquery SNMP agents in the network. Here is a list of SNMP network managementcommands as listed in the TCP/IP for OS/2 Command Reference Manual:

• SNMPD, starts the SNMP agent

• SNMPGRP, provides SNMP manager function to query SNMP agents for data fromtables and other variables in the MIB structure


• SNMPIPW and SNMPPRF, set configuration data for the SNMP agent

• SNMPTRAP , receives and displays unsolicited notification of network events from SNMPagents.

B.3.3 NETSTAT Command - Example

The TCP/IP NETSTAT command is used in every supporting platform to query the TCP/IPstatus of the local host. Here is the information provided by the NETSTAT command:

• Active TCP connections at this local host

• State of all TCP/IP servers on this local host and the sockets used by them

If a DRDA connection cannot be started by DB2 because the CONDBAT limit has beenreached, NETSTAT provides the information shown in Figure 90 on the DB2 server side.

User Id Conn Local Socket Foreign Socket State---- -- ---- ----- ------ ------- ------ -----OMVS 1007 9.12.14.207..34000 *..* ListenOMVS 1009 9.12.14.207..34000 9.12.14.203..1043 EstablishedOMVS 1008 9.12.14.207..34000 9.12.14.203..1044 EstablishedOMVS 1006 9.12.14.207..34000 9.12.14.203..1045 FIN-wait-2

Figure 90. TSO NETSTAT Output

In Figure 90, the fourth row represents our failed DRDA connection. Here is an explanationof the columns provided by the NETSTAT command:

• Local Socket is the local half-association, which consists of the local host IP addressand local process number (service port).

• Foreign Socket is the foreign half-association, which consists of the remote requester IPaddress and TCP/IP process number (service port).

• State

− Listen —the local host is waiting for a connection request from the address and portlisted in the Foreign Socket column of NETSTAT. ″*..*″ in the Foreign Socket columnindicates waiting for a connection request from any port on any host.

− Established —the connection is completely established. Both sides can send andreceive data. This is the normal state for the data transfer phase of a connection.

− FIN-wait-2 —the state a connection enters when the local host application closes butthe application on the other end does not close. There is no time-out in this state.

In this state, data can be received but not sent. Some applications mightintentionally put the connection into this state because they plan to send data in one


direction. However, in most cases, this is not a long-term state. Usually,persistence of this state indicates an error condition.

Refer to the TCP/IP V3R2 for MVS: Diagnosis Guide for a more detailed explanation ofTCP/IP association states.


Appendix C. TCP/IP Protocols

In this appendix we present details about the TCP/IP architecture and protocols.

C.1 TCP/IP Architecture - Layered Protocols

The internet protocols are modeled in four layers as shown in Figure 91.

Figure 91. Architectural Model. Each layer represents a ″package″ of functions.

Application

The application layer is a user process communicating with another process on the sameor a different host. Telnet, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol(SMTP) are examples of application protocols.

Transport

The transport layer provides the end-to-end data transfer. It can use a connection-orientedprotocol or a connectionless protocol. A connection-oriented protocol requires that bothpartners have connection capability, that is, they start a connection before starting aconversation process. In the connectionless protocol, if one of the partners has noconnection capability, there is no control over the partner ′s status or message or datatransfer errors. TCP is an example of a connection-oriented protocol and user datagramprotocol (UDP) is an example of a connectionless protocol.


Internetwork

The internetwork layer, also called the network layer, provides the “virtual network” imageof the Internet. It shields higher level layers from the network architecture used below it.

IP, the most important protocol used in this layer, does not provide reliability, flow control,or error recovery. It does not assume reliability from the lower layers. IP is aconnectionless protocol.

Network interface

The network interface layer, also called the link layer or the data-link layer (in OSI, SNA, orIEEE), is the interface to the actual network hardware. This interface may or may notprovide reliable delivery. It can be either packet or stream oriented. The network interfacelayer can use almost any network interface available, because TCP/IP does not specify anyprotocol for it. This approach provides the IP protocol with a high degree of flexibility.Examples of protocols used in this layer are IEEE 802.2, X.25, ATM, FDDI, Packed RadioNetworks, and SNA.

Figure 92 shows the layering model in more detail.

Figure 92. Detailed Architectural Model


C.1.1 Bridges, Routers, and Gateways

IBM and TCP/IP documentation use different terminology for bridges, routers, andgateways.

Here are the IBM definitions of bridges, routers, and gateways:

Bridge Interconnects LAN segments at the network interface layer and forwards framesbetween them (see Figure 93). A bridge performs the function of a mediumaccess control (MAC) relay. It is independent of any higher layer protocol(including the logical link protocol). If required, it provides MAC layer protocolconversion. Examples are a PS/2 running the IBM Token-Ring Network Bridgeprogram and the IBM 8229 LAN bridge.

Figure 93. Bridge

Router Sometimes performs the function of a bridge, usually interconnects networks atthe network layer level, and routes packets between them (see Figure 94 onpage 184). The router understands the addressing structure associated with thenetworking protocols. It supports and makes decisions on whether, and how, toforward packets. Routers can also select the best transmission paths andoptimal packet size. Any IBM host or workstation running TCP/IP can be usedas a router.

Appendix C. TCP/IP Protocols 183

Figure 94. Router

Gateway Interconnects networks at higher levels than bridges or routers (see Figure 95on page 185). A gateway can operate in any of the four TCP/IP layers, from thenetwork interface to the application layer. A gateway usually supports addressmapping from one network to another and can provide transformation of databetween the environments to support end-to-end application connectivity. Anexample of a gateway is an MVS host running SMTP/JES mail gateway usingTCP/IP.


Figure 95. Gateway

C.1.2 IP Routing

The Internet datagram (IP datagram) is the base transfer packet in the Internet protocolsuite. It is composed of a header with information for IP and data that is used only byhigher level protocols.

Datagram is encapsulated in the physical network′s frame. The frame′s size depends onthe hardware used. Figure 96 shows how the datagram flows through the network.

Figure 96. Datagram Packed in a Frame

Because frames have a limited or maximum size, a datagram can span more than oneframe. Datagrams that span more than one frame are called fragmented datagrams.

The basic routing function of IP allows the acceptance of datagrams in the local IP stack,the passing of them to higher level protocols, or the rerouting of them to other IPaddresses. Figure 97 on page 186 shows the four layers of each host and the IP routing


mechanism. IP datagrams flow through the network going from one IP address to another.If the IP destination address in the datagram header matches the local host IP address, theIP protocol passes the datagram to higher levels. If the IP destination address in thedatagram header does not match the local host IP address, then the IP protocol reroutesthe datagram or discards it. The IP protocol discards the datagram if the ipforwarding flagis set to off.

Figure 97. IP Routing Mechanism Layers

The IP routing table on each host contains the set of mappings between IP addresses andthe IP addresses of next hop routers for these destinations. There are three kinds ofmapping:

• Direct routes, for locally attached networks

• Indirect routes, for networks reachable with one or more routers (′hopping ′mechanism).

• Default route, containing an IP address of a router that is used for all IP addresses notcovered by direct and indirect routes or locally attached networks.

If the datagram is to be rerouted to some other network, the IP routing algorithm checks forthe following:

• If the host has an entry in the local IP routing table matching the destination IP addressin the datagram, the datagram is sent to this new destination.

• If the network number of the destination IP address is the same as the network numberof one of this host′s network adapters, the datagram is sent to the physical address ofthis host matching the destination IP address.


The TCP/IP host has basic router functions. This can be sufficient for simple routing, but forcomplex networks, other specialized protocols are needed.

C.2 Main Protocol Concepts

In this section we describe basic concepts for the rest of the main protocols.

C.2.1 Address Resolution Protocol (ARP)

IP datagrams are transmitted through networks. They contain a source IP address and adestination IP address. The destination IP address must be translated or mapped to aphysical address. To find the destination ′s physical network address, network-specificstandard protocols, such as the Address Resolution Protocol (ARP) for LAN are used.

The ARP is responsible for converting the high-level protocol addresses (IP addresses) tophysical network addresses. Figure 98 shows the positioning of ARP in the TCP/IP protocolsuite.

Figure 98. Address Resolution Protocol

Because ARP is a network-specific standard protocol, there are different standards indifferent networks (Ethernet, Token-Ring, SNA). In a single network, each host knows theothers by their physical hardware address. Higher level of protocols, such as IP, addresshosts in the form of IP address. When a higher level protocol sends a datagram using thedestination IP address, the device driver cannot understand it, so the ARP moduletranslates the IP address to the physical address of the destination host. ARP does thistranslation using a lookup table, known as the ARP cache.


ARP works in a single network. When the address it receives does not match its local IPaddress, ARP requests to all hosts in this network. If one host in the network recognizesthe IP address in the ARP request as its own, it sends back to the original ARP an ARPreply. This reply contains the physical hardware address of the host and path information.ARP caches both the physical hardware address and the path information and uses themthe next time the same IP destination address is used for datagram transmission.

C.2.2 Reverse Address Resolution Protocol (RARP)

Some hosts in the network, such as diskless workstations, do not know their own IPaddress, only their physical address. To determine their IP address, they must use amechanism similar to ARP. The Reverse Address Resolution Protocol (RARP) maps aphysical address into an IP address. Figure 99 shows the positioning of this protocol in theTCP/IP protocol suite.

Figure 99. Reverse Address Resolution Protocol

A RARP server must exist on the network to maintain a database of mappings fromhardware physical addresses to IP addresses. RARP is a network-specific standardprotocol. Reverse address resolution works in a similar way as in ARP. While ARPassumes that each host knows the mapping of its own physical and symbolic addresses, weneed one or more RARP servers in a network to maintain mappings of physical and IPaddresses.

C.2.3 User Datagram Protocol (UDP) Basics

Figure 100 on page 189 shows how UDP is positioned in the TCP/IP protocol suite.


Figure 100. User Datagram Protocol

UDP is basically an application interface to IP. It adds no reliability, flow control, or errorrecovery to IP. It works as a ″multiplexer-demultiplexer″ for datagram processing, as shownin Figure 10 on page 28. UDP is a connectionless protocol. It only provides the mechanismto send datagrams between processes. Every error recovery that could be needed,requires the application responsibility. The application interface offered by UDP isdescribed in RFC-768. It provides for:

• The creation of new receive ports, at process request

• Receive operation that returns data and an indication of source port and source IPaddress

• Send operation with data, source, and destination ports, and addresses like parameters.

C.2.4 Transmission Control Protocol (TCP)

Figure 101 on page 190 shows the positioning of TCP in the TCP/IP protocol suite.


Figure 101. Transmission Control Protocol

TCP provides more facilities for applications than UDP, such as error recovery, flow control,and reliability. TCP is a connection-oriented protocol.

If two processes are communicating over TCP, they use TCP sockets. The socket modelprovides a process with a full-duplex byte stream connection to another process. Facilitiesto manage this stream are provided by TCP. These facilities are transparent to applications.

TCP, like UDP, uses the port principle to provide multiplexing. Each side of the connectionhas a socket identified by the triple <TCP, IP address, port number>, also called ahalf-association. If two processes communicate using TCP, they have a logical connection,identifiable by the association representation: <TCP, local IP address, local port, remote IPaddress, remote port>. Figure 102 on page 191 shows an example of the connection pathbetween PROCESS X and PROCESS Y.


Figure 102. TCP Connection

Each connection uses the segment as the entity for data transmission. The segment formatcontains the data bytes, the source and destination port number, information related to thecontiguous byte stream fragmentation (one contiguous byte stream can span more than onesegment), and other transmission protocol information. Refer to TCP/IP V3R2 for MVSApplication Programing Interface, RFC 793.

C.2.5 Internet Control Message Protocol (ICMP)

Internet Control Message Protocol (ICMP) is a standard protocol with STD 5, which alsoincludes IP. It is an integral part of IP. Figure 103 on page 192 shows the positioning ofICMP in the TCP/IP protocol suite.


Figure 103. Internet Control Message Protocol

When errors in datagram processing occur, a destination host or a gateway mustcommunicate them to the source host. ICMP is used to report these errors. ICMP has thefollowing characteristics:

• ICMP uses IP as if ICMP were a higher level protocol. ICMP is part of IP and must beimplemented in every IP module.

• Although ICMP can report some errors, this does not make IP a reliable protocol.Datagrams might be undelivered, without any report that they are lost. Only a protocolrunning on a higher level can provide reliability.

• ICMP can produce reports on IP datagrams but not for ICMP error datagrams, thiswould bring to infinite repetitions. ICMP can, however, send messages in response toICMP query messages.

• For fragmented datagrams, ICMP error messages are sent only for fragment zero,which contains the information for fragments reassembly.

• ICMP messages are never sent in response to datagrams with a destination IP addressthat is a multicast address.

• ICMP can send messages only if the source address is not zero and is not a loopbackaddress, a broadcast, or a multicast address.

• RFC 792 states that ICMP messages ″may″ be generated to report IP datagramprocessing errors, not ″must.″ Thus an ICMP router almost always produces messages,but, depending on the router implementation, the destination hosts might not see all ofthem.


Appendix D. TCP/IP for MVS

In this appendix we present further details on TCP/IP for MVS.

D.1 TCP/IP and OpenEdition

TCP/IP and OpenEdition applications are a feature of TCP/IP for MVS, so you need the basefeature of TCP/IP for MVS to use TCP/IP and OpenEdition applications. However, onceinstalled, the OpenEdition applications can be used with either AnyNet MVS or TCP/IP forMVS as the TCP/IP transport provider.

Before you can use TCP/IP OpenEdition, the OpenMVS component must be installed andstarted.

D.1.1 OpenEdition Overview

OS/390 services support an environment within which operating systems, servers,distributed systems, and workstations share common interfaces. OpenEdition supportsstandard application development across multivendor systems. It is required if you want tocreate and use applications that conform to the POSIX or XPG4 standard. OpenEditioncombines the personal power of the workstation, the flexibility of open systems, and thestrength of OS/390. It supports and fosters a superenvironment of larger operating systemsor servers and of distributed systems and workstations that share common interfaces.Users can switch back and forth between the traditional TSO/E interface and theOpenEdition shell interface. UNIX-skilled users can interact with the system, using afamiliar set of standard commands and utilities. OS/390-skilled users can interact with thesystem, using familiar TSO/E commands and interactive menus to create and managehierarchical file system files and to copy data back and forth between OS/390 data sets andfiles. Application programmers and users can choose from both sets of interfaces and, bymaking appropriate tradeoffs, choose to mix these interfaces.

D.1.2 TCP/IP Version 3 for OpenEditionThe current releases of IBM MVS, TCP/IP, and the TCP/IP Version 3 for OpenEdition MVSApplications Feature work together to provide a set of OpenEdition (OE) socket applicationsand programming interfaces. The applications and programming interfaces enhanceinteroperability between the OE MVS environment and various client or server hosts.

With the feature, all TCP/IP users can access files in the hierarchical file system (HFS) ofOpenEdition MVS. Users familiar with HFS can use it without converting file names totraditional MVS data set names. They can use the OpenEdition FTP server to access files inthe HFS. Whether users have an MVS background or an AIX or UNIX background, they canuse the commands that they are familiar with to access OpenEdition MVS. They can usethe vi editor. Application programmers have access to the RPC, X Window System, and


OSF/Motif programming runtime libraries that provide the interfaces to write standard,portable applications.

Before you can use OpenEdition MVS services, the OpenMVS component must be installedand started. The OpenEdition MVS Shell and Utilities and the OpenEdition MVS Debuggerare optional features.

D.1.3 TCP/IP Data Set Names with OpenEdition Services

The OpenEdition socket runtime library functions use the following TCP/IP data sets:

• tcpip.TCPIP.DATA

• tcpip.STANDARD.TCPXLBIN

• tcpip.HOSTS.SITEINFO

• tcpip.HOSTS.ADDRINFO

• tcpip.ETC.PROTO

• tcpip.ETC.SERVICES

D.2 Other Address Spaces

The original version of TCP/IP for MVS was ported from a VM implementation. Theimplementation for MVS was designed to emulate some basic VM functions for transfer ofdata and control information between the socket application address spaces and the TCP/IPsystem address space. These functions in a VM environment are the VMCF and interusercommunication vehicle (IUCV). The TCP/IP MVS platform emulates the following VM systemfunctions:

The TNF function, which is an authorized user facility that allows a service address space torequest notification when a client′s address space or a task within the client′s addressspace terminates. TNF executes on its own address space.

The VMCF function, which performs the functions of VM VMCF and IUCV in the TCP/IP V3for MVS environment. This address space provides the communication between the socketapplication address space and TCP/IP system address space.

The TCP/IP SNALINK and X.25 device drivers address space provide communicationbetween TCP/IP and an SNA backbone network. The interface is through VTAM based onLU0 and LU6.

The TCP/IP device driver function executing in the TCP/IP system address space providesthe usage of IEEE802.5 to access TCP/IP hosts using a token-ring network.


The TSO address space communicates with TCP/IP through the VMCF/IUCV address space.It allows a TSO user to issue TCP/IP commands. For example, you can issue the PINGcommand to check for connections to some host or the NETSTAT command to obtain thestatus of connections. The server address space, which is usually implemented as one ormore started tasks, delivers certain services to a client, such as a file transfer function.

D.3 Multiple Copies of TCP/IP

You can run one or more TCP/IP address space copies on a single MVS system. Toconcurrently connect more than one TCP/IP instance to OpenEdition MVS, you need toconfigure the OpenEdition MVS, to use Common I-Net (C-INET) AF_INET PFS instead ofIntegrated sockets AF_INET PFS, which does not support multiple TCP/IP instancesconnected to OpenEdition MVS. When you have DB2 using TCP/IP, however, you can haveonly one TCP/IP instance connect to OpenEdition MVS on the same MVS system, becauseDB2 uses asynchronous I/O services, and C-INET AF_INET PFS does not supportasynchronous I/O, the integrated sockets AF_INET PFS must be used. In other words, youmust configure OpenEditon MVS to use the integrated sockets AF_INET PFS when usingDB2 with TCP/IP. Refer to the TCP/IP for MVS: Customization and Administration Guide forfurther consideration of multiple copies of TCP/IP.

D.4 TCP/IP for MVS Connectivity

There are many ways in which you can connect your TCP/IP for MVS host to an IP network.

The network connectivity options of TCP/IP for MVS can be grouped into two separatecategories as shown in Figure 104 on page 196:

• Networks that are directly attached to your TCP/IP for MVS stack

These are hosts that are in the same network as your hosts.• Networks that are attached through a router

Appendix D. TCP/IP for MVS 195

Figure 104. Example of Network connectivity

Figure 104 shows a host, MVS1, directly connected to network 193.0.2 using LINK1 and tonetwork 193.9.200 using LINK2. MVS1 is indirectly connected to network 128.84.1, which isaccessible through router 193.9.200.2. All packets destined for a network that has no in therouting table should be routed through router 193.0.2.2, the default route, which is alsodefined in the GATEWAY statement.

D.4.1.1 TCP/IP for MVS Functions TCP/IP functions can be categorized as belonging toone of five categories:

• Connectivity and gateway functions , which handle the physical interfaces and therouting of IP datagrams. For example:

SNALINK Access TCP/IP hosts using an SNA backbone network (LU0 andLU6.2 based

IEEE802.5 Access TCP/IP hosts using a token-ring network

RS/6000 Access TCP/IP hosts using an S/370 parallel channel-attached oran S/390 ESCON channel-attached RS/6000

• Server functions , which are usually implemented as one or more started tasks runningin individual address spaces. As the name implies, these functions deliver a certainservice to a client, for example, a file transfer function.

• Client functions , which are implemented as user commands requesting a certainservice from a server anywhere in the network

• Network status and management functions , which are used to detect and solve networkproblems, for example, PING command


• Application programming interfaces (APIs) , which allow you to write your ownclient/server applications

Appendix D. TCP/IP for MVS 197


Appendix E. Special Notices

This publication is intended to help database administrators to implement DRDA usingTCP/IP as the communication protocol. The information in this publication is not intendedas the specification of any programming interfaces that are provided by DB2 for OS/390Server Version 5, DB2 Universal Database Version 5, DB2 Connect Version 5. See thePUBLICATIONS section of the IBM Programming Announcement for DB2 for OS/390 ServerVersion 5, DB2 Universal Database Version 5, DB2 Connect Version 5 for more informationabout what publications are considered to be product documentation.

References in this publication to IBM products, programs or services do not imply that IBMintends to make these available in all countries in which IBM operates. Any reference to anIBM product, program, or service is not intended to state or imply that only IBM′s product,program, or service may be used. Any functionally equivalent program that does notinfringe any of IBM′s intellectual property rights may be used instead of the IBM product,program or service.

Information in this book was developed in conjunction with use of the equipment specified,and is limited in application to those specific hardware and software products and levels.

IBM may have patents or pending patent applications covering subject matter in thisdocument. The furnishing of this document does not give you any license to these patents.You can send license inquiries, in writing, to the IBM Director of Licensing, IBMCorporation, 500 Columbus Avenue, Thornwood, NY 10594 USA.

Licensees of this program who wish to have information about it for the purpose ofenabling: (i) the exchange of information between independently created programs andother programs (including this one) and (ii) the mutual use of the information which hasbeen exchanged, should contact IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY10589 USA.

Such information may be available, subject to appropriate terms and conditions, includingin some cases, payment of a fee.

The information contained in this document has not been submitted to any formal IBM testand is distributed AS IS. The information about non-IBM (″vendor″) products in this manualhas been supplied by the vendor and IBM assumes no responsibility for its accuracy orcompleteness. The use of this information or the implementation of any of these techniquesis a customer responsibility and depends on the customer ′s ability to evaluate and integratethem into the customer′s operational environment. While each item may have beenreviewed by IBM for accuracy in a specific situation, there is no guarantee that the same orsimilar results will be obtained elsewhere. Customers attempting to adapt these techniquesto their own environments do so at their own risk.


Any performance data contained in this document was determined in a controlledenvironment, and therefore, the results that may be obtained in other operatingenvironments may vary significantly. Users of this document should verify the applicabledata for their specific environment.

Reference to PTF numbers that have not been released through the normal distributionprocess does not imply general availability. The purpose of including these referencenumbers is to alert IBM customers to specific information relative to the implementation ofthe PTF when it becomes available to each customer according to the normal IBM PTFdistribution process.

The following terms are trademarks of the International Business Machines Corporation inthe United States and/or other countries:

The following terms are trademarks of other companies:

C-bus is a trademark of Corollary, Inc.

PC Direct is a trademark of Ziff Communications Company and isused by IBM Corporation under license.

UNIX is a registered trademark in the United States and othercountries licensed exclusively through X/Open Company Limited.

Microsoft, Windows, Wndows NT and the Windows 95 logoare trademarks or registered trademarks of Microsoft Corporation.

IBM DATABASE 2OS/390 DB2Distributed Relational Database Architecture DRDAMVS AIXOS/2 S/390SQL/DS MVS/ESAOS/400 DataJoinerIMS Net.DataAnyNet OpenEditionRACF ACF/VTAMVTAM MVS/SPDFSMS MVS/DFPDFSORT RS/6000SP2 Language EnvironmentCICS ATCurrent FFSTNetView PS/2S/370 ESCONSystem/390 AS/400BookManager PROFS


Java and HotJava are trademarks of Sun Microsystems, Inc.

Other trademarks are trademarks of their respective companies.

Appendix E. Special Notices 201


Appendix F. Related Publications

The publications listed in this section are considered particularly suitable for a moredetailed discussion of the topics covered in this redbook.

F.1 International Technical Support Organization Publications

For information on ordering these ITSO publications see “How to Get ITSO Redbooks” onpage 205.

• DB2 for MVS Connections with AIX and OS/2, SG24-4558

• DB2 for MVS DRDA Server: Security Considerations, GG24-2500

• TCP/IP Tutorial and Technical Overview, GG24-3376-04

• TCP/IP V3R2 for MVS: Implementation Guide, SG24-3687-03

F.2 Redbooks on CD-ROMs

Redbooks are also available on CD-ROMs. Order a subscription and receive updates 2-4times a year at significant savings.

CD-ROM Title SubscriptionNumber

Collection KitNumber

System/390 Redbooks Collection SBOF-7201 SK2T-2177Networking and Systems Management Redbooks Collection SBOF-7370 SK2T-6022Transaction Processing and Data Management Redbook SBOF-7240 SK2T-8038AS/400 Redbooks Collection SBOF-7270 SK2T-2849RS/6000 Redbooks Collection (HTML, BkMgr) SBOF-7230 SK2T-8040RS/6000 Redbooks Collection (PostScript) SBOF-7205 SK2T-8041Application Development Redbooks Collection SBOF-7290 SK2T-8037Personal Systems Redbooks Collection SBOF-7250 SK2T-8042

F.3 Other Publications

These publications are also relevant as further information sources:

• DB2 for OS/390 Version 5 What is New?, GC26-8971

• DB2 for OS/390 Version 5 Release Guide, SC26-8965

• DB2 for OS/390 Version 5 Data Sharing: Planning and Administration, SC26-8961

• DB2 for OS/390 Version 5 Installation Guide, GC26-8970

• DB2 for OS/390 Version 5 Administration Guide, SC26-8957

• DB2 for OS/390 Version 5 Command Reference, SC26-8960


• DB2 for OS/390 Version 5 Utility Guide and Reference, SC26-8967

• DB2 for OS/390 Version 5 Application Programming and SQL Guide, SC26-8958

• DB2 for OS/390 Version 5 SQL Reference, SC26-8966

• DB2 for OS/390 Version 5 Call Level Interface Guide and Reference, SC26-8959

• TCP/IP for OS/2 Command Reference Manual, SX75-0070-02

• TCP/IP for MVS: Customization and Administration Guide, SC31-7134-04

• TCP/IP for MVS: Planning and Migration Guide, SC31-7189-02

• TCP/IP V3R2 for MVS Messages and Codes, SC31-7132-04

• TCP/IP V3R2 for MVS: Diagnosis Guide, LY43-0105-02

These publications are also relevant as further information sources, but their numbers arenot listed because at the time of writing these publications were not orderable:

• IBM DB2 Connect Troubleshooting Guide

• IBM DB2 UDB Troubleshooting Guide

• IBM DB2 UDB Administration Getting Started

• IBM DB2 UDB Administration Guide

• IBM DB2 UDB Command Reference

• DB2 Connect Enterprise Edition Quick Beginnings

• DB2 Connect Personal Edition Quick Beginnings

• DB2 Connect User′s Guide

• IBM DB2 UDB Message Reference

• Road Map to DB2 Programming

• SQL Getting Started

• SQL Reference

• System Monitor Guide and Reference

• DB2 Extended Enterprise Edition Quick Beginnings

• DB2 Personal Edition Quick Beginnings

• Quick Beginnings for OS/2

• Quick Beginnings for UNIX

• Quick Beginnings for Windows NT


How to Get ITSO Redbooks

This section explains how both customers and IBM employees can find out about ITSO redbooks,CD-ROMs, workshops, and residencies. A form for ordering books and CD-ROMs is also provided.

This information was current at the time of publication, but is continually subject to change. Thelatest information may be found at URL http://www.redbooks.ibm.com.

How IBM Employees Can Get ITSO Redbooks

Employees may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) andinformation about redbooks, workshops, and residencies in the following ways:

• PUBORDER — to order hardcopies in United States

• GOPHER link to the Internet - type GOPHER.WTSCPOK.ITSO.IBM.COM

• Tools disks

To get LIST3820s of redbooks, type one of the following commands:

TOOLS SENDTO EHONE4 TOOLS2 REDPRINT GET SG24xxxx PACKAGETOOLS SENDTO CANVM2 TOOLS REDPRINT GET SG24xxxx PACKAGE (Canadian users only)

To get BookManager BOOKs of redbooks, type the following command:

TOOLCAT REDBOOKS

To get lists of redbooks:

TOOLS SENDTO USDIST MKTTOOLS MKTTOOLS GET ITSOCAT TXTTOOLS SENDTO USDIST MKTTOOLS MKTTOOLS GET LISTSERV PACKAGE

To register for information on workshops, residencies, and redbooks:

TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ITSOREGI 1996

For a list of product area specialists in the ITSO:

TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ORGCARD PACKAGE

• Redbooks Home Page on the World Wide Web

http://w3.itso.ibm.com/redbooks

• IBM Direct Publications Catalog on the World Wide Web

http://www.elink.ibmlink.ibm.com/pbl/pbl

IBM employees may obtain LIST3820s of redbooks from this page.

• REDBOOKS category on INEWS

• Online — send orders to: USIB6FPL at IBMMAIL or DKIBMBSH at IBMMAIL

• Internet Listserver

With an Internet e-mail address, anyone can subscribe to an IBM Announcement Listserver. Toinitiate the service, send an e-mail note to [email protected] with the keywordsubscribe in the body of the note (leave the subject line blank). A category form and detailedinstructions will be sent to you.


How Customers Can Get ITSO Redbooks

Customers may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) andinformation about redbooks, workshops, and residencies in the following ways:

• Online Orders (Do not send credit card information over the Internet) — send orders to:

• Telephone orders

• Mail Orders — send orders to:

• Fax — send orders to:

• 1-800-IBM-4FAX (United States) or (+1)001-408-256-5422 (Outside USA) — ask for:

Index # 4421 Abstracts of new redbooksIndex # 4422 IBM redbooksIndex # 4420 Redbooks for last six months

• Direct Services - send note to [email protected]

• On the World Wide Web

Redbooks Home Page http://www.redbooks.ibm.comIBM Direct Publications Catalog http://www.elink.ibmlink.ibm.com/pbl/pbl

• Internet Listserver

With an Internet e-mail address, anyone can subscribe to an IBM Announcement Listserver. Toinitiate the service, send an e-mail note to [email protected] with the keywordsubscribe in the body of the note (leave the subject line blank).

IBMMAIL InternetIn United States: usib6fpl at ibmmail [email protected] Canada: caibmbkz at ibmmail [email protected] North America: dkibmbsh at ibmmail [email protected]

United States (toll free) 1-800-879-2755Canada (toll free) 1-800-IBM-4YOU

Outside North America (long distance charges apply)(+45) 4810-1320 - Danish(+45) 4810-1420 - Dutch(+45) 4810-1540 - English(+45) 4810-1670 - Finnish(+45) 4810-1220 - French

(+45) 4810-1020 - German(+45) 4810-1620 - Italian(+45) 4810-1270 - Norwegian(+45) 4810-1120 - Spanish(+45) 4810-1170 - Swedish

IBM PublicationsPublications Customer SupportP.O. Box 29570Raleigh, NC 27626-0570USA

IBM Publications144-4th Avenue, S.W.Calgary, Alberta T2P 3N5Canada

IBM Direct ServicesSortemosevej 21DK-3450 AllerødDenmark

United States (toll free) 1-800-445-9269Canada 1-403-267-4455(+45) 48 14 2207 (long distance charge)Outside North America


IBM Redbook Order Form

Please send me the following:

Title Order Number Quantity

First name Last name

Company

Address

City Postal code Country

Telephone number Telefax number VAT number

• Invoice to customer number

• Credit card number

Credit card expiration date Card issued to Signature

We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card notavailable in all countries. Signature mandatory for credit card payment.

DO NOT SEND CREDIT CARD INFORMATION OVER THE INTERNET.

How to Get ITSO Redbooks 207


Index

Special Characters/etc/hosts fi le 33/etc/syslog.conf file 170\etc directory 89\etc\hosts fi le 55, 89\mptn\etc directory 89, 90\SQLLIB\BND subdirectory 104\windows directory 89, 90\winnt\system32\drivers\etc subdirectory 89,

90

Aaccess profile 5ACF/VTAM 11, 14acknowledgment message 48ADDGROUP command 43Address Resolution Protocol

See ARPaddress space

DDF 40engine 31kernel 31ODBC-CLI 10port number 44PROFILE.TCPIP data set 33stack 26, 31stored procedure 7, 12system 31TCP/IP 43TCPIP.DATA data set 32

addressing 23ADDUSER command 42Advanced Program-to-Program Communication

See APPCagent process 176AIX

alias 87case sensitivity 131cataloging the database 91Client Configuration Assistant tool 91configuring TCP/IP 81

AIX (continued)DataJoiner 146DB2 Connect 2DB2 UDB 131DB2COMM environment variable 87DNS 25ephemeral port 28GET AUTHORIZATIONS command 159GET CONNECTION STATE command 157hosts file 89LIST APPLICATIONS command 158LIST COMMAND OPTIONS command 160LIST DRDA INDOUBT TRANSACTIONS

command 159native TCP/IP support 8prerequisites 14product overview 1project environment 18services fi le 90standards 72TCP/IP positioning 9two-phase commit 142

alert 163, 178alias 87, 96, 115, 118, 146ALTGROUP command 43ALTUSER command 42AnyNet 8, 193APAR OY65281 129APF authorized library 41APPC

AUTHENTICATION parameter 131command examples 152DataJoiner 146DB2 Connect 2DISPLAY LOCATION command 155DSNZPARM module 39DUW 137generic resources 110IDLE THREAD TIMEOUT parameter 36inbound translation 60installation 35mixed mode 115, 116, 118outbound translation 60


APPC (continued)PassTicket 128prerequisites 14resynchronization 110security 121, 122SQL changes 8SYSIBM.LOCATIONS table 59SYSIBM.LUNAMES table 61TCP/IP ALREADY VERIFIED parameter 39TCP/IP positioning 8two-phase commit 142, 145workload balancing 111, 112

APPL 40, 121application ID 129application key 129, 130application requester

See AR 9application server

See ASAR

association 29bind 62BIND PACKAGE options 65client considerations 55data sharing 107, 108, 109DB2 Connect 89DB2 for OS/390 44, 57, 143DISPLAY LOCATION command 154, 155DISPLAY THREAD command 154DRDA PORT parameter 38EXTENDED SECURITY 37HOSTS.LOCAL data set 55OS/2 89resynchronization 46, 110SAMPLE database 18security 123TCP/IP positioning 9trace 165transaction program name 60Windows 95 71workload balancing 111WWW products 10

ARM 110ARP 187AS

association 29bind 62, 64, 104

AS (continued)BIND PACKAGE options 65changing password 135connection test 69data sharing 107, 108database manager configuration 86DB2 for OS/390 44, 51, 64, 89DB2 UDB 65DISPLAY LOCATION command 154DISPLAY THREAD command 154DRDA PORT parameter 38DUW 141hosts file 89mixed mode 116node name 100package 63PassTicket 121performance 70resynchronization 54, 110security 60, 122SYNCPOINT NONE 143SYSIBM.IPNAMES table 60SYSIBM.LOCATIONS table 59TCP/IP ALREADY VERIFIED parameter 39test the connection 98, 103trace 165two-phase commit 144, 145USERNAMES column 60workload balancing 111

assembler callable interface 41association 29, 179asynchronous transfer mode

See ATMATM 11auditing 121authentication

cataloging the database 102DB2 Connect 132DB2 UDB 131instance level 86PassTicket 121, 128, 130RACF 130

AUTHENTICATION parameter 100, 124, 131AUTHID column 62, 125authorization ID 60


authorized functions 41automatic restart manager

See ARMavailabi l i ty 7, 36, 200

Bbackup 5bind

AS 65DB2 for OS/390 104DSNTEP2 program 63DSNTIAD program 63DSNTIAUL program 63enhancements 66errors 169file 104performance 70SPUFI 63

BIND command 62, 63, 64, 104blocking 11, 70, 104bootstrap data set

See BSDSbridge 183bs2cli.lst bind file 104BSDROUTINGPARMS parameter 34BSDS

\etc\services fi le 55changes 39data sharing 107DDF record 52, 53installation 39LU name 39port number 39, 57

CCAE 3, 6, 135call level interface

See CLIcallable interface 41CANCEL command 152capacity planning 13case sensitivity 131, 132catalog 66, 146CATALOG APPC NODE command 118

CATALOG DATABASE command 103, 131, 133CATALOG TCPIP NODE command

DB2 UDB 100example 118host name 101IP address 101NETSTAT command 72SECURITY SOCKS specification 134services fi le 90

CCSID 168CDB

AS 51data sharing 57mixed mode 60, 115, 116PassTicket 121password 12referential constraints 59resynchronization 54security 122, 124service name 55

CGI 3change log inventory uti l i ty 39, 40, 44, 52CICS 113, 122, 141CLI 7, 10, 104, 172Client Configuration Assistant tool 90, 91, 100CLP

cataloging 91, 100, 101command examples 157default node name 95getting text for SQLCODEs 169testing the connection 103

CM/2 131coded character set identifier

See CCSIDcold start 141come from checking 51Command Center 87command line processor

See CLPcommit

CLP 161data sharing 111DataJoiner 149DB2 for OS/390 as a transaction

manager 143DUW 137failed AS 141

Index 211

commit (continued)LIST DRDA INDOUBT TRANSACTIONS

command 159multisite updates 139participants 141protocol 141SYNCPOINT NONE 142

COMMIT statement 37, 49, 116, 157common gateway interface

See CGIcommunication record 39, 53Communication Server Version 4 14, 142, 145CONFIG.SYS file 87CONNECT 2 142CONNECT RESET statement 104, 157CONNECT statement

association 29cataloging the database 101changing password 135connection test 69DataJoiner 146, 149LOCATION column 59mixed mode 115, 118PassTicket 133testing the connection 103trace 166workload balancing 112

CONNECT TYPE 1 110CONNECT TYPE 2 110connection exit 122Control Center 5conversation 39, 48, 151, 154, 155coordinator 140, 141, 148COPYOPTS keyword 68core file 171CPU 8cursor 137

Ddata class 130data replication 1data sharing

CDB 57command examples 153mixed mode 119PassTicket 129

data sharing (continued)port number 38, 53project environment 18RESYNC PORT parameter 38resynchronization 110TCP/IP ALREADY VERIFIED parameter 39TCPALVER parameter 51two-phase commit 145workload balancing 111

data sourceDataJoiner roles 148distributed request 146failure 150generic API 147nickname 146precompile 150protocol 150stored procedure 12SYSCAT.SERVER_OPTIONS table 149transaction mode 149two-phase commit 146, 149

data types 1data warehouse 1, 7database manager configuration

authentication 131DataJoiner 150GET AUTHORIZATIONS command 159network configuration 71SECURITY_OUT column 124specifying values 85updating 86

datagramerrors 192fragmented 186IP address 187IP routing 185IP routing table 186MVS 196NETSTAT command 174protocol 188transport layer 181

DataJoineraccess to nonrelational data 1Net.Data 3resynchronization 150supported products 146


DATASETPREFIX statement 45, 109DB2 Client Application Enabler

See CAEDB2 common server 1, 146, 147, 149, 150DB2 Connect

AR 89authentication 132bind 62changing password 135data sharing 108, 109DB2 for OS/390 as a transaction

manager 143DB2 UDB packaging 6DCE 7member-routing method 110native TCP/IP support 8OS/2 89product overview 1, 2resynchronization 110security 121, 132trace 167two-phase commit 142workload balancing 112WWW products 10

DB2 Connect Enterprise Edition 7DB2 Connect Personal Edition 7DB2 Enterprise Edition 6, 7DB2 Estimator for Windows 7, 13DB2 for OS/390

address space 31AR 57, 65AS 51, 64, 89ATM 11bind 62, 64, 104BIND PACKAGE options 65case sensitivity 132changing password 135client considerations 55commands 151connection test 69data sharing 107, 108, 109DataJoiner 146DB2 Connect 2DB2 Installer 12domain name 25DUW 137, 145GET CONNECTION STATE command 157

DB2 for OS/390 (continued)host name 25installation 35migrat ion 39mixed mode 115NETSTAT command 155package 104PassTicket 121, 128, 133prerequisites 13security 122, 123sockets 29stored procedures 11TCP/IP positioning 8test the connection 99transaction manager 143two-phase commit 142, 145Version 5 enhancements 7workload balancing 111WWW products 10

DB2 for OS/400 1, 2, 142, 146DB2 for VM and VSE 1, 2, 142, 146DB2 Parallel Edition 1DB2 Performance Monitor

See DB2 PMDB2 Personal Edition 6DB2 PM 7, 13DB2 UDB

AS 65authentication 131Beta 3 18bind 63case sensitivity 132commands 157connection test 69data sharing 108database manager configuration 86DataJoiner 146DUW 137mixed mode 116packaging 6PassTicket 128, 132, 133prerequisites 14product overview 1security 130SECURITY_OUT column 124SYNCPOINT NONE 143three-part name 118

Index 213

DB2 UDB (continued)tools 4two-phase commit 142, 144, 145

DB2 Workgroup Edition 6DB2 WWW Connection 3, 7, 13, 135DB2 WWW for MVS 10DB2BQTIME environment variable 160DB2BQTRY environment variable 160DB2CLI.INI file 172db2cliv1.lst bind file 104DB2COMM environment variable 85, 86, 167DB2DIAG.LOG file 163, 165db2drdat command 166, 170DB2INSTANCE environment variable 163DB2INSTPROF environment variable 163DB2IQTIME environment variable 160DB2OPTIONS environment variable 160DB2PATH environment variable 163DB2PEM utility 135DB2RQTIME environment variable 160DB2SET command 86, 167db2trc trace facility 164, 165db2ubind.lst bind file 104dbx function 171DCE

authentication 130DB2 Connect 133DB2 for OS/390 7, 12, 51, 121SYSIBM.LUNAMES table 61TCP/IP ALREADY VERIFIED parameter 39TCP/IP positioning 10

DCS directory 101, 102DDCS 2, 7, 9, 10ddcsmvs.lst bind file 104ddcstrc trace 167, 168, 170ddcsvm.lst bind file 104ddcsvse.lst bind file 104DDF

address space 40communication with OpenEdition 31data sharing 109host name 44IDLE THREAD TIMEOUT parameter 36installation 35keep-alive t imer 47MAXDBAT parameter 113migrat ion 39

DDF (continued)OpenEdition 41, 57performance 11prerequisites 14private protocol 8procedure 39reinit ial ization 54started procedures table 43startup 42, 45statement 40, 53superuser 41workload balancing 112

DDL statements 104deadlock 118default route 34demultiplexing 28DESCRIBE statement 11DEVICE parameter 34DFSMS 14DFSORT 14DIAGLEVEL parameter 163DIAGPATH parameter 163direct routes 34DISCONNECT statement 157dispatching priorit ies 12DISPLAY LOCATION command 151, 154DISPLAY THREAD command 151, 152, 153Distributed Computing Environment

See DCEdistributed data facil ity

See DDFDistributed Database Connection Services

See DDCSdistributed request 137, 146distributed unit of work

see DUWDML statements 104DNS

configuring TCP/IP 79data sharing 107, 108domain name system 25DSNL004I message 54firewall 134foreign 26hosts file 89HOSTS.LOCAL data set 33IP address 33


DNS (continued)network adapter 26project environment 19SYSIBM.IPNAMES table 60workload balancing 111

domain directory 24domain name

addressing 24DSNL004I message 54project environment 18, 19security 122TCPIP.DATA data set 32

domain name serverSee DNS

domain name system 25DOMAINORIGIN parameter 32dotted decimal 23, 24, 33Dr. Watson utility 172DRDA

alias 87authentication 133bind files 104BIND PACKAGE options 65block fetch 70client considerations 54data sharing 107, 108DataJoiner 146, 150DB2 Connect 2DB2 WWW Connection 13DCS directory 102DUW 137EXTENDED SECURITY 14, 37keep-alive t imer 47manual configuration 100mixed mode 115multisite update 140password changing 12performance 11, 70port number 28, 51prerequisites 14resynchronization 110security 102, 121, 123SYNCPOINT NONE 143SYSIBM.IPNAMES table 60SYSIBM.LOCATIONS table 59TCP/IP ALREADY VERIFIED parameter 39TCP/IP positioning 8

DRDA (continued)trace 165two-phase commit 54, 142, 144workload balancing 111WWW products 10

DRDA PORT parameter 38drwatson 172DSN3@ATH exit 122DSN3@SGN exit 122DSN6FAC macro 51DSNDB06 database 57DSNDDF database 57DSNEBP07 panel 67DSNESP01 panel 69DSNL004I message 53DSNL027I message 50DSNL028I message 50DSNL030I message 113DSNL511I message 49, 70DSNL512I message 46, 54DSNL515I message 44, 54DSNL519I message 53DSNT244I message 65DSNT270I message 169DSNT408I message 63, 109DSNTEJ1P member 63DSNTEJ2A member 63DSNTEP2 program 63DSNTIAD program 63DSNTIAUL program 63DSNTIJMV member 40DSNTIJSG member 57, 63DSNTIJTM member 63DSNTIJUZ member 39, 40DSNTINST CLIST 35, 39DSNTIP5 panel 35, 38, 51DSNTIPG panel 41DSNTIPR panel 35DSNV444 message 153DSNV445 meessage 154DSNV446 message 153DSNV448 message 153, 154DSNZPARM module 39, 51DUW

concepts 137DB2 Connect 2DB2 for OS/390 as a transaction

manager 143

Index 215

DUW (continued)DSNTEP2 program 63

dynamic allocation 43dynamic routing 34dynamic SQL 11, 63

Eembedded SQL 7enclave 113encrypt 12, 122, 125, 126, 128ephemeral port

AR 57data sharing 107definit ion 28DISPLAY THREAD command 153, 154NETSTAT command 156, 175

error codes 65ETC subdirectories 71ETC/SERVICES file 86ETC.SERVICES data set 33, 46, 55, 194etc.services file 71explain 7, 13export uti l i ty 104EXTENDED SECURITY 14, 37, 121EXTSEC parameter 37

Ffai lure

DataJoiner 150DB2 for OS/390 as a transaction

manager 143IDLE THREAD TIMEOUT parameter 47keep-alive t imer 47MVS 110security 121SYNCPOINT NONE 142VIPA 27

FFDC 163, 164FFST 171File Transfer Program

See FTPfirewall 134First Failure Data Capture

See FFDC

first failure support technologySee FFST

FMH-5 header 123, 131FOR FETCH ONLY specification 70FOR READ ONLY specification 70foreign DNS 26foreign process 29fragmented datagrams 185FTP 28full-duplex communication 48

Ggateway 9, 77, 184GATEWAY parameter 33generic LU name 36, 111, 129generic resources 110, 112, 113GET AUTHORIZATIONS command 159GET CONNECTION STATE command 157GETHOSTBYADDR() 26, 45, 46, 54GETHOSTBYNAME() 26GETHOSTID() 45, 46, 54GID parameter 43global identity 121GROUP BY clause 70group ID 43

HHAVING clause 70HFS 60hierarchical fi le system

See HFShigh performance native socket

See HPNShistory facil ity 13history fi le 161HLQ parameter 45HOME statement 34, 45HOST command 89host name

addressing 24cataloging the database 95cataloging the node directory 101client considerations 55data sharing 107, 108, 109DB2 for OS/390 44


host name (continued)DISPLAY THREAD command 151DNS 25DSNL004I message 54hosts file 89HOSTS.LOCAL data set 33installation 39IPADDR column 60MAKESITE utility 45name resolution 25network adapter 26network configuration 71PING command 156project environment 19standards 71TCPIP.DATA data set 32workload balancing 111

host number 23HOSTNAME parameter 32hosts file

configuring 89data sharing 109domain name system 25foreign DNS 26location 84name resolution 25

HOSTS.ADDRINFO data set 45HOSTS.LOCAL data set

data sharing 109, 110DB2 for OS/390 55IPADDR column 60parameters 33searching 45workload balancing 111

HOSTS.SITEINFO data set 45HP 1, 2, 8, 146HPNS 31HTML 3, 13, 135

IIBM Communication Server Version 4.1 for

AIX 14IBM High Level Assembler for MVS Version 1

Release 2 14IBM Internet Connection Server 4

ICHRIN03 procedure table 43idle connection 47IDLE THREAD TIMEOUT parameter 36, 47, 49import uti l i ty 104IMS 1, 113, 122, 141in-fl ight transaction 110inbound translation 51, 122, 125indirect routes 34indoubt

detection 141LIST DRDA INDOUBT TRANSACTIONS

command 159locks 143MAXDBAT parameter 114RESET INDOUBT command 152timeout 36

Informix 1, 146INSERT statement 57instance

authentication 86, 131DataJoiner 146DB2 UDB 71default name 71LIST DRDA INDOUBT TRANSACTIONS

command 159owner 163server program 29TCP/IP 28, 31, 55, 110, 195

Intel 1inter-user communication vehicle

See IUCVInternet

configuring TCP/IP 79DB2 Estimator for Windows 13DB2 UDB 1, 6ETC.SERVICES data set 33firewall 134IP address 23Net.Data 3protocol 21style 55, 90

Internet Protocol Suite 21interrupt 71, 86, 90INTERVAL keyword 47IP address

ARP 187association 29

Index 217

IP address (continued)cataloging the database 95cataloging the node directory 101class 23client considerations 55components 23configuring TCP/IP 77, 85data sharing 107, 108, 109datagram 187DB2 for OS/390 AR 57DISPLAY LOCATION command 152, 155DISPLAY THREAD command 151, 154DNS 25domain name system 25DSNL004I message 54firewall 135HOME statement 45hosts file 25, 89installation 39IPADDR column 60iptrace command 174MAKESITE utility 45mult ihome 24name resolution 25NETSTAT command 156, 179network adapter 26network configuration 71PROFILE.TCPIP data set 34project environment 19RARP 188RECOVER INDOUBT command 152RESET INDOUBT command 152resynchronization 110security 122standards 71TCPIP.DATA data set 33VIPA 27workload balancing 111

IPADDR column 44, 60IPFORMAT command 173IPTRACE command 173iptrace.dmp file 173ISOLATION 70ISPF 14IUCV 31

IXCQUERY call 46

JJava 1, 7Java Database Connectivity

See JDBCJDBC 1, 7, 10join 137

Kkeep-alive t imer 47, 48, 49, 50KEEPALIVEOPTIONS parameter 47KEEPDYNAMIC option 66

LLAN 2, 6, 7, 9, 171, 183LE/370 14, 41license 6, 7limited block fetch 70link list 41LINK parameter 34LINKATTR column 60LINKNAME column

APPC 59mixed mode 115PassTicket 129, 130RACF 130security 124SECURITY_OUT column 124TCP/IP 60, 62

LIST APPLICATIONS command 158LIST COMMAND OPTIONS command 160LIST DATABASE DIRECTORY command 102LIST DCS DIRECTORY command 103LIST DRDA INDOUBT TRANSACTIONS

command 159list files 104LIST NODE DIRECTORY command 101LISTUSER command 42LOCATION column 59, 87location name

AR 59, 60BSDS 103cataloging the database 101


location name (continued)data sharing 107DISPLAY LOCATION command 152DISPLAY THREAD command 151SmartGuide 96

LOCATION NAME parameter 36lock

IDLE THREAD TIMEOUT parameter 36, 49ISOLATION 70keep-alive t imer 47MAXDBAT parameter 113mixed mode 118

LOG file 166logical unit name

See LU namelowercase 131, 132LU 6.2 Syncpoint Manager

See SPMLU name

command examples 154DISPLAY LOCATION command 152, 155DISPLAY THREAD command 151DSNZPARM module 39generic 36, 111, 113, 129installation 36MAXDBAT parameter 113mixed mode 115PassTicket 129, 130RACF 130RECOVER INDOUBT command 152RESET INDOUBT command 152SECURITY_OUT column 124SYSIBM.LOCATIONS table 59workload balancing 111, 112

LULIST 112LUNAME keyword 40luwid 152, 159

MMAKESITE utility 45map ps command 171massively parallel processing

See MPPMAX REMOTE CONNECTED 112MAXDBAT parameter 112, 113, 114

member-rout ing method 110member-specif ic method 112, 113message exchange 47, 111, 121, 123Microsoft Internet Server 4Microsoft SNA Server 15, 142Microsoft SQL Server 146, 147migrat ion 35, 39, 57mixed mode 60, 115, 116, 119monitor 5MPP 1multicasting 24multihomed host 24mult imedia 1multiple network interfaces 46multisite read 137multisite update 139, 143, 146must rollback state 145MVS

DNS 25ephemeral port 28TCP/IP 9, 10, 31

MVS/DFP 14MVS/SP 13

Nname resolution 25naming convention 108Net.Data 1, 3, 6, 10, 135Netscape 4, 135NETSTAT command 72, 91, 155, 174, 179network

addressing 24configuration 71DNS 25failure 47interface 24IP address 77keep-alive t imer 48management commands 173message exchange 48mixed connections 60password 12performance 11PING command 156protocol 21security 121

Index 219

network (continued)standards 71stored procedure 12TCP/IP positioning 9traffic 70

network adapteradding to the list 75configuring TCP/IP 74data sharing 108datagram 186DNS 27host name 26IP address 26mult ihomed 24

network controller 54network interface 34, 46NETWORK LUNAME parameter 36NEWAUTHID column 62, 126nicknames 146node directory

cataloging 94, 100data sharing 108mixed mode 118resynchronization 110

node name 100NSINTERADDR parameter 33NSPORTADDR parameter 33

Oobject-oriented programming languages 7object-relational extenders 1ODBC 7, 10, 97, 172OLTP 1OMVS 42one-phase commit 137, 138, 149online monitor 13online REORG 7open database connectivity

See ODBC 7OPEN request 11OpenEdition

address space 31DDF 41, 57groups 43native TCP/IP support 8port number 44

OpenEdition (continued)prerequisites 14PROFILE.TCPIP data set 33sockets 29superuser 41, 42

OPTIMIZE FOR clause 11OPTION column 149OPTIONS keyword 66Oracle 1, 146OS/2

alias 87AR 89AUTHENTICATION parameter 131case sensitivity 132cataloging the database 91configuring TCP/IP 84DB2 Connect 2, 89DB2COMM environment variable 87DNS 25ephemeral port 28GET AUTHORIZATIONS command 159GET CONNECTION STATE command 157hosts file 89LIST APPLICATIONS command 158LIST COMMAND OPTIONS command 160LIST DRDA INDOUBT TRANSACTIONS

command 159native TCP/IP support 8prerequisites 14product overview 1project environment 18services fi le 90standards 72TCP/IP positioning 9two-phase commit 142

OS/390 Release 1 13OS/390 Release 3

callable interface 41native TCP/IP support 8, 14project environment 18sockets 29WLM 11

OS/400 104outages 36outbound translation 60, 62, 116, 125, 127


overhead 8, 10, 70

Ppackage

bind 62bind files 104COPY options 67DB2 for OS/390 104new options 66plan 63

PACKAGE keyword 63parallel processing 1parameter marker 70participant 140partner LU verif ication 122PassTicket

DB2 for OS/390 12, 51DB2 UDB 132LU name 130RACF 121, 128SECURITY_OUT column 124sending 133SYSIBM.LUNAMES table 61SYSIBM.USERNAMES table 62TCP/IP ALREADY VERIFIED parameter 39TCP/IP positioning 10

passwordcase sensitivity 131, 132cataloging the database 102changing 12, 14, 37, 121, 130, 135database manager configuration 86DB2 for OS/390 AS 51DB2 UDB 131DCE 12encrypt 122, 128outbound translation 127PassTicket 121SECURITY_OUT column 60, 124SYSIBM.LUNAMES table 61SYSIBM.USERNAMES table 62TCP/IP ALREADY VERIFIED parameter 39TCP/IP positioning 10test the connection 99

PASSWORD column 62, 126performance

Control Center 5

performance (continued)DB2 Estimator for Windows 13DB2 for OS/390 7DB2 PM 13DRDA 11future releases 31improving 70query 1TCP/IP positioning 9trace 164, 165

physical link 34PING command 24, 156, 167, 175plan 63, 64, 67PORT column 46, 59PORT keyword 40port number

\etc\services fi le 55AS 51association 29BSDS 57cataloging the node directory 101data sharing 107DISPLAY THREAD command 154DSNZPARM module 39ephemeral 28, 57identif ication 28installation 43iptrace command 174NETSTAT command 156network configuration 71OpenEdition 44PROFILE data set 43RESET INDOUBT command 152resynchronization 39, 107server 29, 38service name 46services fi le 90standards 71SYSIBM.LOCATIONS table 59well-known 38, 51

PORT parameter 52PORT statement 33, 44precompile 142, 149, 169PREPARE statement 11presume abort 10, 141, 145

Index 221

presume nothing 10, 141primary authorization ID 127priorit ies 111private protocol 8, 115, 116, 142, 146PROFILE configuration 33PROFILE data set 43, 45, 47PROFILE file 87PROFILE.TCPIP data set 33, 45, 51protocol suite 21ps util ity 171pstat command 171PTKTDATA class 130

Qquiesce 108, 110

RRACF

configuring 130DB2 Connect 133DB2 for OS/390 12, 51EXTENDED SECURITY 37LU name 130PassTicket 121, 128, 130profi le 42SECURITY_OUT column 60, 124started procedures table 43stored procedure 12, 121superuser 41SYSIBM.USERNAMES table 62TCP/IP ALREADY VERIFIED parameter 39TCP/IP positioning 10user ID 122

RARP 188RDEFINE command 130recover 5, 178, 182, 189RECOVER INDOUBT command 152Recoverable Resource Manager Services

See RRSAFreferential constraint 59REMOTE column 68REOPT(VARS) option 66replication 5RESET INDOUBT command 152

resource managerSee RM

RESPORT parameter 40, 52result sets 7, 12RESYNC PORT parameter 38RESYNC_INTERVAL parameter 150resynchronization

AR 46AS 51BSDS 39data sharing 110, 145DataJoiner 150MAXDBAT parameter 114network adapter 27RESYNC PORT parameter 38transaction manager 143

Reverse Address Resolution ProtocolSee RARP

RM 148, 149, 150roll back 139, 141, 145, 149, 159ROLLBACK statement 37, 157router 22, 79, 183RRSAF 12runtime l ibrary 41

Ssample applications 62SCO 1, 2scripts 5SDK 7, 10, 135SDSNSAMP library 39, 40, 57, 63SECACPT parameter 39, 121, 122secondary ID 122secured signon 129security

case sensitivity 131cataloging the database 101DB2 Connect 132DB2 for OS/390 12, 123DB2 UDB 130DRDA 121EXTENDED SECURITY 37firewall 134inbound translation 51SECURITY_OUT column 60SNA 121


security (continued)stored procedure 12TCP/IP ALREADY VERIFIED parameter 39TCP/IP positioning 10

SECURITY parameter 121SECURITY SOCKS specification 134SECURITY_IN column 61SECURITY_OUT column 60, 124, 125, 126, 132SELECT statement 11, 57server port

assignment 29data sharing 53DB2 for OS/390 51DB2 UDB 71, 91DRDA 38more than one subsystem 52

service nameCATALOG TCPIP NODE command 72cataloging the database 95cataloging the node directory 101CDB 55client considerations 55database manager configuration 86DB2 for OS/390 46port number 29services fi le 90standards 71SYSIBM.LOCATIONS table 59

service request blockSee SRB

SERVICES data set 33services fi le

configuring 71, 90location 80, 84trace 167

session ID 153, 154SET CLIENT command 149SET DB2COMM command 86SET SERVER OPTION command 150SETROPTS command 130sign-on exit 122Simple Network Management Protocol

See SNMPsingle-site update 139SINIX 1, 2

site tables 54SmartGuide 5, 92SMP/E 12, 14SNA

ATM 11commands 151conversation 48DISPLAY LOCATION command 152FFST 171gateway machine 8mixed connections 60partner LU verif ication 122security 121, 123TCP/IP positioning 8, 10

SNA Server for Windows NT 131snapshot 13SNMP 176, 177, 178sockets 29SOCKS_NS environment variable 134SOCKS_SERVER environment variable 134Software Developer ′s Kit

See SDKSolaris 8, 146SPM 131, 142SPUFI 62, 64, 69SQL statement

automatic bind 104bind files 104Control Center 5DataJoiner 146DB2 Estimator for Windows 13DB2 PM 13DSNTEP2 program 63DSNTIAD program 63IDLE THREAD TIMEOUT parameter 37overhead 70

SQL0805N message 105SQL0979N message 143SQL1325N message 159SQL92 Entry Level Standard 7SQLCA 161, 170SQLCODE -084 69SQLCODE -30072 65SQLCODE -4930 65, 169SQLCODE -919 145

Index 223

SQLCODE + 5 9 5 65SRB 29SSIGNON parameter 130started procedures table 43stored procedures 7, 11, 121subdomain 25subnet mask 77, 85Sun 1, 2superuser 41SVCENAME parameter 71, 167Sybase 1, 146SYNCPOINT option 142, 149syncpoint support 142SYSADM 157, 158, 159, 164SYSCAT.DBAUTH table 159SYSCAT.SERVER_OPTIONS table 149, 150SYSCTRL 157, 158, 164SYSDDF table space 57SYSIBM.IPNAMES table

columns 60data sharing 108, 110host name 44mixed mode 115new table 59resynchronization 110security 124SYSIBM.LOCATIONS table 59

SYSIBM.LOCATIONS tablealias 87columns 59mixed mode 115PassTicket 129replacement of SYSIBM.SYSLOCATIONS 57service name 46SYSIBM.IPNAMES table 60

SYSIBM.LULIST table 57SYSIBM.LUMODES table 57SYSIBM.LUNAMES table

columns 61DCE 61differences 58PassTicket 61password 61replacement of SYSIBM.SYSLUNAMES 57

SYSIBM.MODESELECT table 57

SYSIBM.SYSLOCATIONS table 57, 60SYSIBM.SYSLULIST table 57SYSIBM.SYSLUMODES table 57SYSIBM.SYSLUNAMES table 58SYSIBM.SYSMODESELECT table 57SYSIBM.SYSPACKAGE table 68SYSIBM.SYSUSERNAMES table 57SYSIBM.USERNAMES table

case sensit ivity 132columns 62, 125mixed mode 116outbound translation 127PassTicket 128replacemnet of SYSIBM.SYSUSERNAMES 57security 125SYSIBM.IPNAMES table 60

SYSLOG 170SYSMAINT 158, 164Sysplex

data sharing 108DNS 46project environment 18query parallel ism 7resynchronization 110workload balancing 111

system communication 155system database directory 101system-directed access 155

Ttable space 5, 57, 59TCP 21TCP/IP ALREADY VERIFIED parameter 39TCPALVER parameter 51, 122, 124, 133TCPDATA member 33, 34TCPIP.DATA data set

data sharing 109high level qualifier 45host name 54parameters 32runtime l ibrary 194

TCPIP.PROFILE data set 109TCPIP.TCPPARM data set 33, 34TCPIPJOBNAME parameter 33TCPSTART command 85


TCPSTOP command 85Telnet 28test the connection 98, 103thread

DISPLAY LOCATION command 151, 152,154, 155

DISPLAY THREAD command 151IDLE THREAD TIMEOUT parameter 36indoubt 114keep-alive t imer 47message exchange 49mixed mode 117reuse 122workload balancing 112

three-part name 115, 116, 118, 152, 155ticket 12t imeout 36t imestamp 129TM 148, 150TM_DATABASE parameter 143token 152TPN column 59trace facil ity 164transaction manager 143

See TMtransaction manager database parameter 143transaction program name 59translation 25, 29, 51Transmission Control Protocol

See TCPtwo-phase commit

concepts 140data sharing 110DataJoiner 146, 149DB2 for OS/390 as a transaction

manager 143disabling 142DUW 139failure 143MAXDBAT parameter 114mixed mode 118phase 1 141phase 2 141prerequisites 14RESYNC PORT parameter 38resynchronization 46, 51stored procedure 12

two-phase commit (continued)successful 54TCP/IP positioning 10

type 2 index 59, 60TYPE column 62, 125

UUID parameter 41UNCATALOG DATABASE command 102UNCATALOG DCS DATABASE command 103UNCATALOG NODE command 101unit of work

connecting to the same database usingdifferent protocols 117

DataJoiner 146, 148DUW 137mixed mode 118multisite update 139, 143VTAM 36

UNIX 8, 147, 170, 171, 193UPDATE COMMAND OPTIONS command 161UPDATE statement 57UPM 132uppercase 131, 132user ID

case sensitivity 131, 132cataloging the database 102database manager configuration 86DB2 for OS/390 AS 51DB2 UDB 131handling incoming 122MAKESITE utility 45outbound translation 127PassTicket 129SECURITY_OUT column 124superuser 41SYSIBM.LUNAMES table 61test the connection 99

USERNAMES column 60, 125

VVIPA 27, 54virtual IP address

See VIPA

Index 225

virtual machine communication facil i tySee VMCF

Visual Explain 13VM 104VMCF 31VSAM 1VSE 104VTAM

APPL 40enabling TCP/IP support 40EXTENDED SECURITY 14, 37generic resources 110, 113installation 36performance 11SECACPT parameter 122security 39, 121session ID 153, 154workload balancing 112

WWeb

browser 135DB2 for OS/390 13enablement 1Net.Data 3

well-known port 28, 38, 51WHERE clause 70Windows 3.11

authentication 131DB2 Connect 2DB2 for OS/390 as a transaction

manager 143ephemeral port 28native TCP/IP support 8

Windows 95alias 87cataloging the database 91configuring TCP/IP 79DB2 Connect 2DB2 for OS/390 as a transaction

manager 143DB2COMM environment variable 87ephemeral port 28hosts file 89native TCP/IP support 8network configuration 71

Windows 95 (continued)product overview 1project environment 18services fi le 90TCP/IP positioning 9

Windows NTalias 87AUTHENTICATION parameter 131case sensitivity 132cataloging the database 91configuring TCP/IP 73DataJoiner 146DB2 Connect 2DB2COMM environment variable 87ephemeral port 28GET AUTHORIZATIONS command 159GET CONNECTION STATE command 157hosts file 89LIST APPLICATIONS command 158LIST COMMAND OPTIONS command 160LIST DRDA INDOUBT TRANSACTIONS

command 159native TCP/IP support 8prerequisites 15product overview 1project environment 18services fi le 90standards 72two-phase commit 142, 145

WLMDNS 111future changes 46naming convention 108prior i ty 113resynchronization 110stored procedures 11

workload balancing 19, 46, 111Workload Manager

See WLM 11

XX/Open 7, 148, 150


Yyear 2000 7

Index 227


ITSO Redbook Evaluation

WOW! DRDA Supports TCP/IP: DB2 Server for OS/390 and DB2 Universal DatabaseSG24-2212-00

Your feedback is very important to help us maintain the quality of ITSO redbooks. Please completethis questionnaire and return it using one of the following methods:

• Use the online evaluation form found at http://www.redbooks.com• Fax this form to: USA International Access Code + 1 914 432 8264• Send your comments in an Internet note to [email protected]

Please rate your overall satisfaction with this book using the scale:(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)

Overall Satisfaction ____________

Please answer the following questions:

Was this redbook published in time for your needs? Yes____ No____

If no, please explain:_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

What other redbooks would you like to see published?_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

Comments/Suggestions: ( THANK YOU FOR YOUR FEEDBACK! )_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________


IBML

Printed in U.S.A.

SG24-2212-00

Documents

WOW! DRDA Supports TCP/IP: DB2 Server for OS/390 and DB2