International Technical Support Organization Database Systems ...

International Technical Support Organization
Database Systems Management:
IBM SystemView Information Warehouse
DataHub Implementation and Connectivity
June 1993
GG24-4031-00

IBM
International Technical Support Organization
Database Systems Management:
IBM SystemView Information Warehouse
DataHub Implementation and Connectivity
June 1993
GG24-4031-00

Take Note!
Before using this information and the products it supports, be sure to read the general information under
“Special Notices” on page xv.
First Edition (June 1993)
This edition applies to Version 1 Release 1 of the DataHub family of products for use with the MVS, VM,
AS/400, and OS/2 operating systems:
• IBM SystemView Information Warehouse DataHub/2, Program Number 5667-134
• IBM SystemView Information Warehouse DataHub Support/MVS, Program Number 5695-166
• IBM SystemView Information Warehouse DataHub Support/VM Feature of SQL/DS Version 3
Release 3, Program Number 5688-103
• IBM SystemView Information Warehouse DataHub Support/400, Program Number 5738-DM1
• IBM SystemView Information Warehouse DataHub Support/2, Program Number 5648-026.
Order publications through your IBM representative or the IBM branch office serving your locality.
Publications are not stocked at the address given below.
An ITSC Technical Bulletin Evaluation Form for readers′ feedback appears facing Chapter 1. If the
form has been removed, comments may be addressed to:
IBM Corporation, International Technical Support Center
Dept. 471, Building 098
5600 Cottle Road
San Jose, California 95193-0001
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 1993. All rights reserved.
Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or
disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Abstract
This document describes the implementation of the IBM SystemView Information
Warehouse DataHub family of products to operate on all SAA platforms (MVS,
VM, AS/400, OS/2). It provides guidelines on how to plan for DataHub, establish
connectivity links in the DRDA and APPC environments, and configure DataHub.
Problem determination and security issues are considered.
This document is intended for customers and technical professionals who want
to install and configure DataHub. A knowledge of distributed relational database
systems and Distributed Relational Database Architecture (DRDA) connectivity is
assumed.
DS (285 pages)
© Copyright IBM Corp. 1993 iii

iv DataHub Implementation and Connectivity

Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
How to Read This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Related Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
International Technical Support Center Publications . . . . . . . . . . . . . . xxv
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Chapter 1. Introduction to DataHub . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 DataHub Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Platform Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Tools Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 DataHub Data Flows: Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.3 Manage Authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.4 Display Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.5 Copy Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Data Flow Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 2. Planning for DataHub . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 Customer Business Requirements . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Sample Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Scenario 1: Local Management of Local Data . . . . . . . . . . . . . . 20
2.2.2 Scenario 2: Central Management of Distributed Data . . . . . . . . . . 22
2.2.3 Scenario 3: Distributed Management of Distributed Data . . . . . . . 24
2.3 Factors Affecting Implementation . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Planning for Implementation: A Checklist . . . . . . . . . . . . . . . . . . . 26
2.4.1 Gather Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.2 Design the Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.3 Determine Skills Required . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Summary and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 30
Chapter 3. DRDA Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 SNA Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Key Connectivity Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.1 SNA Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.2 DRDA Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
© Copyright IBM Corp. 1993 v

vi DataHub Implementation and Connectivity
3.2.3 RDS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.4 Cross-Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 The ITSC Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 MVS Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.1 SNA Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.2 DRDA Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.3 Testing DRDA Connections . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.5 VM Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.5.1 SNA Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.5.2 DRDA Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5.3 Binding Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.6 AS/400 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.6.1 SNA Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6.2 DRDA Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.6.3 Testing DRDA Connections . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.6.4 Binding Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.7 OS/2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.7.1 OS/2 Host Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.7.2 Relationship between OS/2 Components . . . . . . . . . . . . . . . . . 70
3.7.3 General Customization Plan . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.7.4 SNA Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.7.5 DRDA Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.7.6 Binding Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.7.7 Testing DRDA and RDS Connections . . . . . . . . . . . . . . . . . . . 98
3.7.8 Managing OS/2 Database Manager Directories . . . . . . . . . . . . . 98
3.8 Adding a New DRDA Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.8.1 DRDA Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.8.2 DRDA Client/Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.9 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Chapter 4. DataHub/2 Workstation . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.1 Component Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.2 Scenario 1: Local Management of Local Data . . . . . . . . . . . . . . . . 110
4.2.1 Required Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.2.2 Installation Procedure and Configuration . . . . . . . . . . . . . . . . 111
4.2.3 Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.3 Scenario 2: Central Management of Distributed Data . . . . . . . . . . . 114
4.3.1 Required Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.3.2 Installation Procedure and Configuration . . . . . . . . . . . . . . . . 115
4.3.3 Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.4 Scenario 3: Distributed Management of Distributed Data . . . . . . . . . 117
4.4.1 Required Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.4.2 DataHub/2 Execution: Data Requirements . . . . . . . . . . . . . . . 118
4.4.3 Installation Environment Preparation . . . . . . . . . . . . . . . . . . 119
4.4.4 DataHub/2 Workstation Installation as a Requester . . . . . . . . . . 121
4.4.5 LAN Connectivity Parameters . . . . . . . . . . . . . . . . . . . . . . . 127
4.4.6 OS/2 Database Manager Connectivity Parameters . . . . . . . . . . 143
4.4.7 DataHub/2 Database Connectivity Parameters . . . . . . . . . . . . . 144
4.5 LAN Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.5.1 LAN Server Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.5.2 Placement of LAN Server and DataHub/2 Database . . . . . . . . . 145
4.6 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.6.1 Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.6.2 Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
4.7 Codepage Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

4.8 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
4.8.1 Create the Administrator′s Folder . . . . . . . . . . . . . . . . . . . . 148
Chapter 5. DataHub Tools Conversation Connectivity . . . . . . . . . . . . . . 151
5.1 Key Connectivity Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.2 The ITSC Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
5.3 Configuring the DataHub/2 Workstation . . . . . . . . . . . . . . . . . . . 155
5.3.1 Component Relationships . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.3.2 DataHub/2 Database Definitions . . . . . . . . . . . . . . . . . . . . . 156
5.3.3 OS/2 Communications Manager Definitions . . . . . . . . . . . . . . 161
5.3.4 OS/2 Database Manager Definitions . . . . . . . . . . . . . . . . . . . 166
5.4 Configuring MVS for DataHub Support/MVS . . . . . . . . . . . . . . . . 167
5.4.1 Preparing for DataHub Support/MVS Installation . . . . . . . . . . . 167
5.4.2 Installing DataHub Support/MVS Platform and Tools Feature . . . . 168
5.4.3 Configuring DataHub Support/MVS Environment . . . . . . . . . . . 168
5.4.4 Starting DataHub Support/MVS . . . . . . . . . . . . . . . . . . . . . . 171
5.4.5 DataHub Support/MVS Connectivity Requirements . . . . . . . . . . 172
5.5 Configuring VM for DataHub Support/VM . . . . . . . . . . . . . . . . . . 175
5.5.1 VM/ESA Service Pool Support Facility . . . . . . . . . . . . . . . . . . 175
5.5.2 DataHub Support/VM Operating System Overview . . . . . . . . . . 177
5.5.3 Configuring DataHub Support/VM Environment . . . . . . . . . . . . 178
5.5.4 Operating DataHub Support/VM . . . . . . . . . . . . . . . . . . . . . 187
5.5.5 Performance Consideration . . . . . . . . . . . . . . . . . . . . . . . . 190
5.6 Configuring AS/400 for DataHub Support/400 . . . . . . . . . . . . . . . . 191
5.6.1 AS/400 Network Definition . . . . . . . . . . . . . . . . . . . . . . . . . 191
5.6.2 Configuration Considerations . . . . . . . . . . . . . . . . . . . . . . . 192
5.7 Configuring OS/2 for DataHub Support/2 . . . . . . . . . . . . . . . . . . . 193
5.7.1 OS/2 Host Components . . . . . . . . . . . . . . . . . . . . . . . . . . 193
5.7.2 DataHub Support/2 Customization . . . . . . . . . . . . . . . . . . . . 194
5.7.3 OS/2 Communications Manager Definitions . . . . . . . . . . . . . . 196
5.7.4 OS/2 Database Manager Definitions . . . . . . . . . . . . . . . . . . . 201
5.8 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Chapter 6. Problem Determination . . . . . . . . . . . . . . . . . . . . . . . . . 203
6.1 Implementation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
6.2 DataHub/2 Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
6.2.1 DataHub/2 Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
6.2.2 EMQDUMP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
6.2.3 OS/2 Communications Manager Trace Utility . . . . . . . . . . . . . 208
6.2.4 DataHub/2 Trace Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
6.2.5 Distributed Database Connection Services/2 Trace Utility . . . . . . 210
6.3 MVS Host Problem Determination . . . . . . . . . . . . . . . . . . . . . . . 210
6.3.1 DataHub Support/MVS Trace Files . . . . . . . . . . . . . . . . . . . . 210
6.3.2 An Approach to Problem Diagnosis . . . . . . . . . . . . . . . . . . . 212
6.3.3 Communication Problem Types . . . . . . . . . . . . . . . . . . . . . . 213
6.3.4 Being Prepared . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
6.3.5 Analyzing DB2 DDF Error Messages . . . . . . . . . . . . . . . . . . . 225
6.4 VM Host Problem Determination . . . . . . . . . . . . . . . . . . . . . . . . 226
6.4.1 Monitoring DataHub Support/VM Gateways and Conversation . . . 226
6.4.2 Handling System Messages . . . . . . . . . . . . . . . . . . . . . . . . 226
6.4.3 Diagnosing Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.4.4 Problems Involving the CMR . . . . . . . . . . . . . . . . . . . . . . . 229
6.4.5 Problems Involving the Task Handler and the Tools Feature . . . . 230
6.5 AS/400 Host Problem Determination . . . . . . . . . . . . . . . . . . . . . 232
6.5.1 The AS/400 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Contents vii

viii DataHub Implementation and Connectivity
6.5.2 Network Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
6.5.3 Return Codes and Error Messages . . . . . . . . . . . . . . . . . . . 236
6.5.4 SQL Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
6.5.5 Request Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.5.6 Security Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.5.7 Debugging Tools Conversation Data Flow Errors at AS/400 . . . . . 238
6.5.8 EMQ9088E Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
6.5.9 Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
6.6 OS/2 Host Problem Determination . . . . . . . . . . . . . . . . . . . . . . . 239
Chapter 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . 241
7.1 Security on the DataHub/2 Workstation . . . . . . . . . . . . . . . . . . . . 241
7.1.1 User Profile Management . . . . . . . . . . . . . . . . . . . . . . . . . 241
7.1.2 DataHub/2 User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 246
7.1.3 DataHub/2 Database Privileges . . . . . . . . . . . . . . . . . . . . . . 248
7.2 MVS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
7.2.1 DB2 Attachment to the Network Check . . . . . . . . . . . . . . . . . 248
7.2.2 VTAM and RACF Partner LU Validation . . . . . . . . . . . . . . . . . 248
7.2.3 DB2 Request Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
7.3 VM Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
7.3.1 Controlling Access to the SQL/DS Application Server System . . . 251
7.3.2 Controlling Access to the SQL/DS Application Requester System . 253
7.4 AS/400 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
7.4.1 User Profile and Password Validation . . . . . . . . . . . . . . . . . . 254
7.4.2 QEMQUSER Authorization . . . . . . . . . . . . . . . . . . . . . . . . . 254
7.4.3 Security Administration . . . . . . . . . . . . . . . . . . . . . . . . . . 255
7.5 OS/2 Managed Host Security . . . . . . . . . . . . . . . . . . . . . . . . . . 255
7.5.1 RDS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
7.5.2 Tools Conversation Security . . . . . . . . . . . . . . . . . . . . . . . . 255
7.6 Managing Password Changes . . . . . . . . . . . . . . . . . . . . . . . . . 256
7.7 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Appendix A. OS/2 Communications Manager Network Definition File . . . . 259
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Figures
1. DataHub and SystemView Strategy . . . . . . . . . . . . . . . . . . . . . . 1
2. DataHub in Information Warehouse Framework . . . . . . . . . . . . . . . 2
3. DataHub Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Selecting the Copy Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Data Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Copy Data Flows for MVS, VM, and OS/400 Platforms . . . . . . . . . . . 13
7. Copy Data Involving OS/2 Hosts . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Copy Data from OS/2 Source to Unlike Target . . . . . . . . . . . . . . . . 15
9. Copy Data to an OS/2 Target from Unlike Source . . . . . . . . . . . . . . 16
10. Copy Data from OS/2 Host to OS/2 Host . . . . . . . . . . . . . . . . . . . 16
11. Scenario 1: Local Management of Local Data . . . . . . . . . . . . . . . . 20
12. Scenario 2: Central Management of Distributed Data . . . . . . . . . . . 22
13. Scenario 3: Distributed Management of Distributed Data . . . . . . . . . 24
14. ITSC Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
15. Cross-Domain Resource Manager Definitions in MVS/VTAM . . . . . . . 41
16. Cross Domain Resource Definitions in MVS/VTAM . . . . . . . . . . . . . 41
17. LAN Address for the Network Control Program . . . . . . . . . . . . . . . 42
18. MAXDATA Definition for the Network Control Program . . . . . . . . . . 43
19. MAXBFRU and UNITSZ Definition for the Network Control Program . . . 43
20. VTAM Startup Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
21. SSCPNAME=SCG20 VTAM Startup Parameter List: ATCSTR00 . . . . . 44
22. LU Definition for DB2 in the MVS VTAM Environment . . . . . . . . . . . 46
23. IBMRDB LOGMODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
24. DB2 to VTAM Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
25. SYSIBM.SYSLOCATIONS CDB Table . . . . . . . . . . . . . . . . . . . . . 49
26. SYSIBM.SYSLUNAMES CDB Table . . . . . . . . . . . . . . . . . . . . . . . 50
27. SYSIBM.SYSUSERNAMES CDB Table . . . . . . . . . . . . . . . . . . . . . 50
28. SYSIBM.SYSMODESELECT CDB Table . . . . . . . . . . . . . . . . . . . . 50
29. SYSIBM.SYSLUMODES CDB Table . . . . . . . . . . . . . . . . . . . . . . 50
30. AVS LU Definition for SQL/DS Environment . . . . . . . . . . . . . . . . . 52
31. Main DRDA Components in an SQL/DS Environment . . . . . . . . . . . 53
32. CMS RESID NAMES File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
33. SQLVMA SQLDBN File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
34. Database Machine Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 55
35. AVS Machine Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
36. AGWPROF GCS File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
37. UCOMDIR NAMES File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
38. AS/400 and VTAM: Matching Parameters . . . . . . . . . . . . . . . . . . 61
39. VTAM: AS/400 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
40. ITSC AS/400 Network Attributes Definition . . . . . . . . . . . . . . . . . . 64
41. AS/400: Token Ring Line Description Definition . . . . . . . . . . . . . . 64
42. AS/400: Controller Description Definition . . . . . . . . . . . . . . . . . . 65
43. AS/400: Device Description Definition . . . . . . . . . . . . . . . . . . . . 65
44. ITSC AS/400 Configuration List Definition . . . . . . . . . . . . . . . . . . . 67
45. AS/400: Local and Remote Relational Database Directory . . . . . . . . 68
46. OS/2 Component Definition Relationships . . . . . . . . . . . . . . . . . . 71
47. OS/2 Host Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
48. OS/2 Communications Manager Relationships with VTAM Definitions . 75
49. LAPS: Configure Workstation Window . . . . . . . . . . . . . . . . . . . . 76
50. LAPS: Parameters for IBM Token-Ring Network Adapters Window . . . 77
51. CM/2: Communications Manager Configuration Definition Window . . . 78
© Copyright IBM Corp. 1993 ix

x DataHub Implementation and Connectivity
52. CM/2: Communications Manager Profile List Sheet Window . . . . . . . 79
53. CM/2: Token-Ring or Other LAN Types DLC Adapter Parameters
Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
54. CM/2: Local Node Characteristics Window . . . . . . . . . . . . . . . . . 80
55. CM/2: Connections List Window (Host Links) . . . . . . . . . . . . . . . . 82
56. CM/2: Adapter List Window . . . . . . . . . . . . . . . . . . . . . . . . . . 82
57. CM/2: Change Connection to a Host Window . . . . . . . . . . . . . . . . 83
58. CM/2: Change Partner LUs Window . . . . . . . . . . . . . . . . . . . . . 84
59. CM/2: SNA Features List Window (Modes) . . . . . . . . . . . . . . . . . 85
60. CM/2: Change a Mode Definition Window . . . . . . . . . . . . . . . . . . 86
61. OS/2 DBM: REXX Procedure to Define Directory Entries . . . . . . . . . 87
62. OS/2 DBM: Directory Tool Window . . . . . . . . . . . . . . . . . . . . . . 88
63. OS/2 DBM: Catalog Workstation Window . . . . . . . . . . . . . . . . . . 89
64. OS/2 DBM: Workstation Directory List . . . . . . . . . . . . . . . . . . . . 90
65. OS/2 DBM: Catalog Database Window . . . . . . . . . . . . . . . . . . . . 91
66. (Part 1 of 2) OS/2 DBM: System Database Directory . . . . . . . . . . . . 92
67. (Part 2 of 2) OS/2 DBM: System Database Directory . . . . . . . . . . . . 93
68. OS/2 DBM: Catalog Database Window . . . . . . . . . . . . . . . . . . . . 95
69. OS/2 DBM: DCS Directory List . . . . . . . . . . . . . . . . . . . . . . . . . 96
70. OS/2 DBM: Listing of DataHub/2 Database Manager Server
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
71. OS/2 DBM: REXX Procedure to Print OS/2 Database Manager
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
72. OS/2 DBM: REXX Procedure to Back Up the OS/2 Database Manager
Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
73. OS/2 DBM: REXX Procedure to Recover the OS/2 Database Manager
Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
74. Major Connectivity Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
75. Scenario 1: Local Management of Local Data . . . . . . . . . . . . . . . 110
76. Scenario 1: Database Catalogs and RDB Name Map File . . . . . . . . 112
77. Scenario 2: Central Management of Distributed Data . . . . . . . . . . 114
78. Database Connection Services Directory . . . . . . . . . . . . . . . . . . 115
79. Scenario 3: Distributed Management of Distributed Data . . . . . . . . 117
80. OS/2 Database Manager Directories . . . . . . . . . . . . . . . . . . . . 121
81. DH/2 Install: Feature Select . . . . . . . . . . . . . . . . . . . . . . . . . . 122
82. DH/2 Install: Installation Type . . . . . . . . . . . . . . . . . . . . . . . . . 122
83. DH/2 Install: Target Directories . . . . . . . . . . . . . . . . . . . . . . . . 123
84. DH/2 Install: Update Configuration . . . . . . . . . . . . . . . . . . . . . . 124
85. DH/2 Install: DataHub/2 Database Name . . . . . . . . . . . . . . . . . . 125
86. DH/2 Install: Delimiter Characters for Commands . . . . . . . . . . . . 125
87. DH/2 Install: LAN Workstation Identification . . . . . . . . . . . . . . . . 126
88. DH/2 Install: Add Program to Desktop . . . . . . . . . . . . . . . . . . . 126
89. DH/2 Install: Installation Confirmation . . . . . . . . . . . . . . . . . . . . 127
90. LAN Configurable Resources . . . . . . . . . . . . . . . . . . . . . . . . . 129
91. LAPS: Select an Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
92. LAPS: Migrate or Configure . . . . . . . . . . . . . . . . . . . . . . . . . . 133
93. LAPS: Configure Workstation . . . . . . . . . . . . . . . . . . . . . . . . . 134
94. LAPS: Parameters for IBM IEEE 802.2, DataHub/2 Workstation . . . . 135
95. LAPS: Parameters for 802.2, LAN Server . . . . . . . . . . . . . . . . . 136
96. LAPS: Configure Workstation, DataHub/2 Workstation NETBIOS . . . . 137
97. LAPS: Parameters for NETBIOS, DataHub/2 Workstation . . . . . . . . 138
98. LAPS: Parameters for NETBIOS, DataHub/2 Server . . . . . . . . . . . . 139
99. LAPS: Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
100. LAPS: PROTOCOL.INI, DataHub/2 Workstation . . . . . . . . . . . . . . 140
101. LAPS: PROTOCOL.INI, LAN Server . . . . . . . . . . . . . . . . . . . . . 141

102. LAPS: IBMLAN.INI, DataHub/2 Workstation . . . . . . . . . . . . . . . . . 142
103. LAPS 9A: IBMLAN.INI, LAN Server . . . . . . . . . . . . . . . . . . . . . . 142
104. OS/2 Database Manager Connectivity Parameters: Client . . . . . . . . 143
105. OS/2 Database Manager Connectivity Parameters: Server . . . . . . . 143
106. DataHub/2 Database Active Applications: Server . . . . . . . . . . . . . 144
107. CMD File for Codepage Change . . . . . . . . . . . . . . . . . . . . . . . 148
108. A DataHub/2 OS/2 Desktop: Administrator′s Folder . . . . . . . . . . . 148
109. DataHub Data Flows Used by DataHub Tool Functions . . . . . . . . . . 151
110. DataHub/2: OS/2 Component Relationship . . . . . . . . . . . . . . . . 156
111. DH/2: Selecting Add on Configure Pull-down Menu . . . . . . . . . . . 157
112. DH/2: Add Host Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
113. DH/2: Display Related Objects Window . . . . . . . . . . . . . . . . . . 159
114. DH/2: Adding an RDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
115. DH/2: Add RDB Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
116. ITSC Hosts and Their RDB Names . . . . . . . . . . . . . . . . . . . . . . 161
117. Partner LU Definition for an SAA RDB System . . . . . . . . . . . . . . 163
118. SNA Features List Window (CPI Communications Side Information) . . 164
119. Change CPI Communications Side Information . . . . . . . . . . . . . . 165
120. OS/2: System Database Directory . . . . . . . . . . . . . . . . . . . . . . 167
121. EMQMCI01 CLIST DataHub Support/MVS Data Set Concatenation . . . 169
122. Installation Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
123. DHS/MVS: DATAHUB.V110.SEMQMJCL Members . . . . . . . . . . . . 170
124. DHS/MVS: Abend 806, Module Not Found . . . . . . . . . . . . . . . . . 170
125. DHS/MVS Data Set APF Authorization . . . . . . . . . . . . . . . . . . . 171
126. DHS/MVS Startup Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
127. DataHub Support/MVS APPL and LOGMODE Entries . . . . . . . . . . . 173
128. DataHub Support/MVS Tool Dispatcher VTAM Application Name
Definition for EMQMACB1 APPL . . . . . . . . . . . . . . . . . . . . . . . 174
129. DataHub Support/MVS SNASVCMG and EMQMLOGM Logon Modes . 174
130. DataHub Support/MVS Startup Error . . . . . . . . . . . . . . . . . . . . 175
131. VM Service Pool Environment . . . . . . . . . . . . . . . . . . . . . . . . 176
132. DHS/VM Operating System Overview . . . . . . . . . . . . . . . . . . . 177
133. DHS/VM: Summary of Configuration Steps . . . . . . . . . . . . . . . . . 179
134. DHS/VM Environment Configuration Overview . . . . . . . . . . . . . . . 180
135. DHS/VM Files and EXECs Overview . . . . . . . . . . . . . . . . . . . . . 181
136. VTAM Sample AVS LU Definition for DataHub Support/VM . . . . . . . 183
137. DHS/VM: AGWPROF GCS Example . . . . . . . . . . . . . . . . . . . . . 184
138. DHS/VM: COMDIR NAMES File . . . . . . . . . . . . . . . . . . . . . . . . 185
139. DHS/VM: Service Pool Configuration File . . . . . . . . . . . . . . . . . . 185
140. DHS/VM: EMQVSYS CONFIG File . . . . . . . . . . . . . . . . . . . . . . 186
141. DHS/VM: PROFILE EXEC of SPM00000 and SPM00001 Machines . . . . 186
142. DHS/VM: EMQVTOOL CONFIG File . . . . . . . . . . . . . . . . . . . . . 187
143. DHS/VM Communication Flow for ACTIVATE Command . . . . . . . . . 187
144. DHS/VM Communication Flow for ALLOCATE Command . . . . . . . . 188
145. DHS/VM Communication Flow for Completing Conversations . . . . . 190
146. DHS/2: OS/2 Component Relationship Diagram . . . . . . . . . . . . . 194
147. DHS/2: Configuration File (EMQ2SYS.CFG) . . . . . . . . . . . . . . . . 195
148. Map File (DHS2.MAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
149. SNA Features List Window (Transaction Program Definitions) . . . . . 197
150. Create a Transaction Program Definition Window . . . . . . . . . . . . 198
151. Create Additional TP Parameters Window . . . . . . . . . . . . . . . . . 198
152. SNA Features List Window (Conversation Security) . . . . . . . . . . . 199
153. CM/2: Create Conversation Security Window . . . . . . . . . . . . . . . 200
154. Create Conversation Security Window (After Definition) . . . . . . . . 201
155. DataHub Support/MVS Trace Parameter Specification . . . . . . . . . . 211
Figures xi

xii DataHub Implementation and Connectivity
156. DataHub Support/MVS DASD Trace Data Set Definition . . . . . . . . . 211
157. DataHub Support/MVS DATAHUB.V110.A006.TDTRACE Data Set . . . . 212
158. DataHub Support/MVS DATAHUB.V110.STDB2C.A0060002.TRACE Data
Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
159. DDF: SQLCODE -30080, Communication Error . . . . . . . . . . . . . . . 225
160. DB2: DSNL501I Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
161. DHS/VM: Sample DataHub Support/VM AVS Console . . . . . . . . . . 227
162. Sample DataHub Support/VM CMR Alert File . . . . . . . . . . . . . . . 230
163. Example of DataHub Support/VM Trace File . . . . . . . . . . . . . . . . 231
164. Sample DataHub Support/VM Alert File . . . . . . . . . . . . . . . . . . . 232
165. AS/400: Verifying Communications . . . . . . . . . . . . . . . . . . . . . 233
166. AS/400: DSPMSG QSYSOPR Command Output . . . . . . . . . . . . . . 234
167. AS/400: Parameter ASTLVL in User Profile . . . . . . . . . . . . . . . . 235
168. AS/400: Message Logging in Job Description . . . . . . . . . . . . . . . 235
169. AS/400: Operator Message Queue Display Screen . . . . . . . . . . . 236
170. AS/400 Detailed SQLCODE . . . . . . . . . . . . . . . . . . . . . . . . . . 237
171. AS/400 Security Error Message . . . . . . . . . . . . . . . . . . . . . . . 237
172. Problem Determination Entries in DataHub Support/2 Configuration File 240
173. User Profile Management: Security Flow Diagram . . . . . . . . . . . . 244
174. DH/2: User Profile Entry Selection Diagram . . . . . . . . . . . . . . . . 247
175. DB2 Security Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
176. VM Security Inbound Processing . . . . . . . . . . . . . . . . . . . . . . . 251

Tables
1. Data Flows Used by Tool Functions . . . . . . . . . . . . . . . . . . . . . . 17
2. Data Flows Used by Copy Data . . . . . . . . . . . . . . . . . . . . . . . . . 17
3. SNA Key Connectivity Parameters Cross Reference . . . . . . . . . . . . 37
4. DRDA Key Connectivity Parameters Cross Reference . . . . . . . . . . . 37
5. The ITSC Network: SNA Key Connectivity Parameter Values, non-OS/2
Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6. The ITSC Network: DRDA Key Connectivity Parameter Values, non-OS/2
Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7. The ITSC Network: SNA Key Connectivity Parameter Values, OS/2 Hosts 39
8. The ITSC Network: RDS Key Connectivity Parameter Values, OS/2 Hosts 39
9. Communications Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 62
10. OS/2 Local Node Definitions for the ITSC Network . . . . . . . . . . . . . 80
11. OS/2 Partner LU Definitions for the ITSC Network . . . . . . . . . . . . . 85
12. Sample Verification Procedures . . . . . . . . . . . . . . . . . . . . . . . . 98
13. LAN Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
14. NETBIOS Session Information for DB2/2 . . . . . . . . . . . . . . . . . . 132
15. DB2/2 NETBIOS Resource Requirements . . . . . . . . . . . . . . . . . . 132
16. LAN Server and OS/2 Version Compatibility . . . . . . . . . . . . . . . . 144
17. DataHub/2 Administrator′s Folder Definitions . . . . . . . . . . . . . . . 149
18. DataHub/2: Key Connectivity Parameters . . . . . . . . . . . . . . . . . . 152
19. ITSC Network: DataHub Key Connectivity Parameter Values . . . . . . 154
20. ITSC Network: DataHub Key Connectivity Parameter Values . . . . . . 154
21. DataHub/2 Database Definitions Used in the ITSC Network . . . . . . . 161
© Copyright IBM Corp. 1993 xiii

xiv DataHub Implementation and Connectivity

Special Notices
This publication is intended to help customers and technical professionals plan
for and implement DataHub with APPC and DRDA connectivity. The information
in this publication is not intended as the specification of any programming
interfaces that are provided by the DataHub family of products. See the
PUBLICATIONS section of the IBM Programming Announcement for DataHub
family of products for more information about what publications are considered
to be product documentation.
References in this publication to IBM products, programs or services do not
imply that IBM intends to make these available in all countries in which IBM
operates. Any reference to an IBM 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 not infringe 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
this document. 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
Commercial Relations, IBM Corporation, Purchase, NY 10577.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The use of this information or the
implementation of any of these techniques is a customer responsibility and
depends on the customer′s ability to evaluate and integrate them into the
customer′s operational environment. While each item may have been reviewed
by IBM for accuracy in a specific situation, there is no guarantee that the same
or similar results will be obtained elsewhere. Customers attempting to adapt
these techniques to their own environments do so at their own risk.
Any performance data contained in this document was determined in a
controlled environment, and therefore, the results that may be obtained in other
operating environments may vary significantly. Users of this document should
verify the applicable data for their specific environment.
The following terms, which are denoted by an asterisk (*) in this publication, are
trademarks of the International Business Machines Corporation in the United
States and/or other countries:
ACF/VTAM
AIX
AS/400
BookManager
CM/2
CUA
DATABASE 2
DataHub
DB2
DB2/2
© Copyright IBM Corp. 1993 xv

xvi DataHub Implementation and Connectivity
Distributed Database Connection Services/2
Distributed Relational Database Architecture
DRDA
IBM
Information Warehouse
MVS/ESA
NetView
OS/2
OS/400
PS/2
QMF
RACF
SAA
SNA
SQL/DS
SQL/400
Systems Application Architecture
Systems Network Architecture
SystemView
VM/ESA
VTAM

Preface
Objectives
Audience
Document Structure
DataHub is a database systems management family of products for distributed
relational databases located on MVS, VM, AS/400, and OS/2 systems. DataHub
operates using APPC and DRDA protocols to connect to and manage the
relational databases interconnected on the network.
This book explains how to plan for DataHub and implement the DRDA and APPC
connectivity between the relational databases and the DataHub workstation. The
book clarifies the connectivity links by highlighting specific configuration
definitions that must be implemented in the network as they relate to DataHub
and the databases it manages. The document also examines capacity
considerations, problem determination, and security issues related to DataHub.
The book is written for technical professionals, database administrators, system
programmers, and users who are involved in planning, configuring, and installing
DataHub. The implementation of DataHub is a team effort. Each member of the
team should have special skills in the area or platform (DB2, SQL/DS, AS/400,
OS/2, DRDA, LAN, and VTAM) involved in the installation of DataHub. It is
assumed that readers of this book have basic prerequisite knowledge in the
areas in which they are interested. This book does not explain the basic
functions of each SAA platform and networking environment involved in the
DataHub implementation.
The document is organized as follows:
• Chapter 1, “Introduction to DataHub”
This chapter introduces DataHub and positions it in the SystemView strategy
and Information Warehouse framework. The chapter also presents an
overview of the DataHub architecture, discusses the DataHub functions, and
explains the data flows used by the DataHub functions between the different
DataHub components.
• Chapter 2, “Planning for DataHub”
This chapter discusses how to plan for the implementation of DataHub in a
customer environment. The chapter examines the factors affecting
implementation and the customer business requirements in three sample
scenarios. It also discusses the in-house skills a customer will need to
develop, suggests naming conventions, and provides a checklist of
implementation planning tasks.
• Chapter 3, “DRDA Connectivity”
This chapter addresses DRDA connectivity—a prerequisite for DataHub—with
working examples. It describes the networking environment and the key
parameters that will establish the connectivity between the network
components including the physical and logical network connections and the
© Copyright IBM Corp. 1993 xvii

How to Read This Document
xviii DataHub Implementation and Connectivity
DRDA application connections. The chapter also shows how to maintain and
manage network changes. It concludes with some recommendations for a
successful DRDA connectivity implementation.
• Chapter 4, “DataHub/2 Workstation”
This chapter discusses the components of DataHub/2 and the DataHub/2
prerequisites that have to be installed on the OS/2 platform, including LAN
requesters and server, OS/2 Communications Manager, OS/2 Database
Manager, and DDCS/2. The chapter presents various component
combinations and explains the role of each component in a particular
scenario.
• Chapter 5, “DataHub Tools Conversation Connectivity”
This chapter addresses DataHub tools conversation connectivity with working
examples. DataHub is a DRDA application and needs to be defined as such.
In addition to DRDA, DataHub uses APPC for its tools conversation flows.
This chapter shows how to establish APPC connectivity for those tools
conversation flows.
• Chapter 6, “Problem Determination”
This chapter addresses the problem determination issues of DataHub and
the network on which it operates. It includes a generic method of dealing
with LAN and network problems as well as DRDA and DataHub connectivity
problem determination. The chapter also discusses problem determination
tools that are available.
• Chapter 7, “Security Considerations”
This chapter addresses planning for network security. It includes an
overview of the security issues on the different platforms of the network. The
chapter discusses password modification issues in a distributed environment
and offers some recommendations for dealing with different security
systems.
• Appendix A, “OS/2 Communications Manager Network Definition File”
This appendix provides an example of the network definition file of a
DataHub/2 workstation configuration.
It is critical that you familiarize yourself with DataHub before reading this book.
It is also critical that you understand the different data flows DataHub uses
because you will have to implement the related connectivity parameters—the
most important part of the DataHub implementation. To this end, Chapter 1
presents an overview of DataHub and the data flows it uses. We also
recommend that you read the Database Systems Management: IBM SystemView
Information Warehouse DataHub Presentation Guide, where DataHub functions
are further explained.
DataHub planning is discussed in Chapter 2, which is a self-contained chapter.
For planning purposes we also recommend that you read Chapter 4, which
discusses more specifically the DataHub/2 environment, and Chapter 7, which
deals with DataHub security planning.
The installation of DataHub consists primarily of implementing the different
connections the product uses. DRDA connectivity is a major prerequisite for

DataHub. We recommend that you install DRDA connectivity before you install
DataHub. The implementation of DRDA connectivity is covered in Chapter 3,
which is a self-contained chapter that you may find helpful when installing any
DRDA environment.
Chapters 4 and 5 explain the implementation tasks to be carried out after the
DRDA installation has been consolidated among the participating SAA platforms.
Chapter 5 more specifically deals with the implementation of DataHub tools
conversation connectivity.
Chapters 3, 4, and 5 are structured according to the order of the installation
tasks we recommend, that is, DRDA connectivity first, the DataHub/2
environment second, and tools conversation third.
Chapter 6 deals with problem determination and is a self-contained chapter.
Chapter 7 deals with security and is also a self-contained chapter.
Preface xix

xx DataHub Implementation and Connectivity

Related Publications
Related Product Documentation
The publications listed below are considered particularly suitable for a more
detailed discussion of the topics covered in this document.
DataHub Documentation
DataHub General Information, GC26-4874
DataHub/2 Message Reference, SC26-3042
DataHub/2 Command Reference, SC26-3044
DataHub/2 User′s Guide, SC26-3045
DataHub/2 Installation and Administration Guide, SC26-3043
DataHub Support/MVS Installation and Operations Guide, SC26-3041
DataHub Support/VM Installation and Operations Guide, GC09-1322
DataHub Support/400 Installation and Operations Guide, SC41-0099
DataHub Support/2 Installation and Operations Guide, SC26-3185
DataHub Tool Builder′s Guide and Reference, SC26-3046
SystemView Documentation
SAA: An Introduction to SystemView, GC23-0576
SAA: SystemView Concepts, SC23-0578-00
SAA: SystemView System Manager/400 User′s Guide, SC41-8201
SAA: SystemView End-Use Dimensions Consistency Guide Concepts,
SC33-6472
SAA: A Guide for Evaluating SystemView Integration, GC28-1383
Information Warehouse Documentation
An Introduction to Information Warehousing, GC26-4876
Information Warehouse Architecture 1, SC26-3244
SAA Documentation
SAA Overview, GC26-4341
SAA Common Programming Interface: Summary, GC26-4675
Concepts of Distributed Data, SC26-4417
SAA Common Programming Interface: Communications Reference, SC26-4399
SAA Database Reference, SC26-4348
SAA Database Level 2 Reference, SC26-4798
SAA Common User Access: Advanced Interface Design Guide, SC34-4290
SAA Common User Access: Basic Interface Design Guide, SC26-4583
SAA Common Communications Support: Summary, GC31-6810
© Copyright IBM Corp. 1993 xxi

xxii DataHub Implementation and Connectivity
Distributed Relational Database Library Documentation
SAA Introduction to Distributed Data, GC26-4831
Distributed Relational Database Architecture Reference, SC26-4651
Distributed Relational Database Connectivity Guide, SC26-4783
Distributed Relational Database Application Programming Guide, SC26-4773
Planning for Distributed Relational Database, SC26-4650
Distributed Relational Database Problem Determination Guide, SC26-4782
IBM Distributed Data Management Level 3 Architecture: Reference, SC21-9526
DB2 Documentation
IBM DATABASE 2 Version 2 General Information, GC26-4373
IBM DATABASE 2 Version 2 Administration Guide, SC26-4374
IBM DATABASE 2 Version 2 Licensed Program Specification, GC26-4375
IBM DATABASE 2 Version 2 SQL Reference, SC26-4380
IBM DATABASE 2 Version 2 Application Programming and SQL Guide,
SC26-4377
IBM DATABASE 2 Version 2 Command and Utility Reference, SC26-4378
IBM DATABASE 2 Version 2 Messages and Codes, SC26-4379
IBM DATABASE 2 Version 2 Master Index, GC26-4772
IBM DATABASE 2 Version 2 Reference Summary, SX26-3771
IBM DATABASE 2 Version 2 Diagnosis Guide and Reference, LY27-9536,
available to IBM licensed customers only
SQL/DS Documentation
SQL/DS General Information, GH09-8074
SQL/DS Licensed Program Specifications, GH09-8076
SQL/DS Operation, SH09-8080
SQL/DS Database Administration, GH09-8083
SQL/DS System Administration, GH09-8084
SQL/DS Managing SQL/DS, SH09-8077
SQL/DS Installation, GH09-8078
SQL/DS Application Programming, SH09-8086
SQL/DS Database Services Utility, SH09-8088
SQL/DS SQL Reference, SH09-8087
SQL/DS Interactive SQL Guide and Reference, SH09-8085
SQL/DS Master Index, SH09-8089
SQL/DS Reference Summary, SX09-1173
SQL/DS Diagnosis Guide and Reference, LH09-8081
SQL/DS Messages and Codes, SH09-8079

AS/400 Documentation
OS/400 Distributed Relational Database Guide, SC41-0025
OS/400 Question-and-Answer Database Coordinator′s Guide, SC41-8086
OS/400 Database Guide, SC41-9659
OS/400 Distributed Data Management Guide, SC41-9600
SAA Structured Query Language/400 Programmer′s Guide, SC41-9609
SAA Structured Query Language/400 Reference, SC41-9608
OS/400 System Concepts, GC41-9802
AS/400 Basic Security Guide, SC41-0047
AS/400 Security Reference, SC41-8083
AS/400 Communications Management Guide, SC41-0024
AS/400 Work Management Guide, SC41-8078
AS/400 Local Area Network Guide, SC41-0004
AS/400 APPN Guide, SC41-8188
AS/400 APPC Programmer′s Guide, SC41-8189
AS/400 Network Planning Guide, GC41-9861
AS/400 Communications Configuration Reference, SC41-0001
Extended Services for OS/2 Documentation
IBM Extended Services for OS/2, G326-0161
IBM Extended Services for OS/2 Messages and Error Recovery Guide,
SO4G-1017
IBM Extended Services for OS/2 Communications Manager APPC
Programming Reference, S04G-1025
IBM Extended Services for OS/2 Command Reference, S04G-1020
IBM Extended Services for OS/2 Communications Manager Configuration
Guide, S04G-1002
IBM Extended Services for OS/2 Database Manager Programming Guide and
Reference, S04G-1022
IBM Extended Services for OS/2 Guide to Database Manager, S04G-1013
IBM Extended Services for OS/2 Guide to Database Manager Client
Application Enablers, S04G-1114
IBM Extended Services for OS/2 Guide to User Profile Management,
S04G-1112
IBM Extended Services for OS/2 Hardware and Software Reference,
S04G-1017
IBM Extended Services Structured Query Language (SQL) Reference,
S04G-1012
Related Publications xxiii

DB2/2 Documentation
DATABASE 2 OS/2 Guide, S62G-3663
DATABASE 2 OS/2 Command Reference, S62G-3670
DATABASE 2 OS/2 Information and Planning Guide, S62G-3662
DATABASE 2 OS/2 Installation Guide, S62G-3664
DATABASE 2 OS/2 Master Index and Glossary, S62G-3669
DATABASE 2 OS/2 Messages and Problem Determination Guide, S62G-3668
DATABASE 2 OS/2 Programming Guide, S62G-3665
DATABASE 2 OS/2 Programming Reference, S62G-3666
DATABASE 2 OS/2 SQL Reference, S62G-3667
DDCS/2 Documentation
Distributed Database Connection Services/2 Guide, S04G-1090
Distributed Database Connections Services/2 Version 2 Guide, S62G-3792
CM/2 Documentation
IBM Communications Manager/2 Version 1.0 User′s Guide, SC31-6108
IBM Communications Manager/2 Version 1.0 Quick Installation, SX75-0085
IBM Communications Manager/2 Version 1.0 Start Here, SC31-6104
IBM Communications Manager/2 Version 1.0 Information and Planning Guide,
SC31-7007
IBM Communications Manager/2 Version 1.0 Workstation Installation Guide,
SC31-6169
IBM Communications Manager/2 Version 1.0 Configuration Guide, SC31-6171
IBM Communications Manager/2 Version 1.0 Configuration Worksheets,
SX75-0088
IBM Communications Manager/2 Version 1.0 APPC Programming Guide and
Reference, SC31-6160
IBM Communications Manager/2 Version 1.0 Keyboard Templates, SX75-0073
VM/ESA Documentation
VM/ESA Connectivity Planning, Administration, and Operation, SC24-5448
VTAM Documentation
VTAM Network Implementation Guide, SC31-6434
VTAM Resource Definition Reference, SC31-6438
VTAM Operations, SC31-6435
VTAM Messages and Codes, SC31-6433
VTAM Programming, SC31-6436
VTAM Programming for LU6.2, SC31-6437
VTAM Diagnosis, LY43-0059
xxiv DataHub Implementation and Connectivity
VTAM Data Areas for MVS/ESA, LY43-0057
VTAM Data Areas for VM, LY43-0058

VTAM Reference Summary, LY43-0060
NCP Documentation
NCP, SSP, and EP Resource Definition Guide, SC30-3447
NCP, SSP, and EP Resource Definition Reference, SC30-3448
NCP, SSP, and EP Messages and Codes, SC30-3169
NCP, SSP, and EP Diagnosis Guide, LY30-5591
NCP and EP Reference, LY30-5605
NCP and EP Reference Summary and Data Areas, LY30-5603
SNA Documentation
SNA Technical Overview, GC30-3073
SNA Formats, GA27-3073
SNA Transaction Programmer′s Reference Manual for LU Type 6.2, GC30-3084
SNA Format and Protocol Reference Manual: Architecture Logic for LU Type
6.2, GC30-3269
SNA LU6.2 Reference: Peer Protocols, GC30-3073
RACF Documentation
System Programming Library: Resource Control Facility (RACF), SC28-1343
Resource Control Facility (RACF) Diagnosis Guide, LY28-1016
Resource Control Facility (RACF) Command Language Reference, SC28-0733
International Technical Support Center Publications
Introduction to Relational Data, GG24-3300
DB2 Distributed Database Application Implementation and Installation Primer,
GG24-3400
Distributed Relational Database Application Scenarios, GG24-3513
Distributed Relational Database Planning and Design Guide for DB2 Users,
GG24-3755
Distributed Relational Database Remote Unit of Work Implementation
DB2-DB2 and DB2-SQL/DS Volume 1 and Volume 2, GG24-3715 and
GG24-3716
Using SQL/DS in a DRDA Environment with DB2 and OS/2 DBM, GG24-3733
Distributed Relational Database Using OS/2 DRDA Client Support with DB2,
GG24-3771
OS/2 DDCS/2 and DB2 V2.3 Distributed Relational Database Performance:
Early Experience, GG24-3926
Information Warehouse Implementation Overview, GG24-3869
Database Systems Management: IBM SystemView Information Warehouse
DataHub Presentation Guide, GG24-3952
Related Publications xxv

xxvi DataHub Implementation and Connectivity

Acknowledgments
This document is the result of a residency project conducted at the International
Technical Support Center-San Jose in the first quarter of 1993.
The project was designed and managed by:
• Viviane Anavi-Chaput, DB2 Assignee, ITSC-San Jose.
We want to acknowledge the excellent work of:
• Marc Boulanger IBM Canada
• Gord Bruce IBM Canada
• Walter Brungnole IBM Brazil
• Albert Charles IBM France
• Jose Carlos Duarte Goncalves IBM Brazil
Special thanks are due to the following people for the invaluable advice and
guidance they provided in the production of this document:
• Tadakatsu Azuma IBM Japan
• Linnette Bakow IBM Development, Santa Teresa
• George Barta IBM Development, Rochester
• Lindsay Bennion IBM Development, Santa Teresa
• Ritsuko Boh IBM Japan
• Doreen Fogle IBM Development, Santa Teresa
• Stan Hoey IBM UK
• Claude Isoir IBM France
• Yukho Iwamoto IBM Japan
• Chris McCarthy IBM Development, Santa Teresa
• Jim McLaughlin IBM Development, Santa Teresa
• Barb Lidstrom BOEING Computer Services
• Masaharu Murozumi IBM Japan
• Dave Reisner IBM Development, Santa Teresa
• Kamran Saadatjoo Analyst international Corporation
• Patrick See IBM Development, Santa Teresa
• Rick Swagerman IBM Development, Toronto.
• Bill Tri IBM Australian Programming Center
Thanks also to Maggie Cutler for her editorial assistance.
Viviane Anavi-Chaput, Project Leader
International Technical Support Center-San Jose
June 1993
© Copyright IBM Corp. 1993 xxvii

xxviii DataHub Implementation and Connectivity

Chapter 1. Introduction to DataHub
DataHub* is a family of products designed to meet the challenges of managing
complex database environments while increasing productivity and reducing
costs. DataHub provides integrated database systems management functions for
IBM* Systems Application Architecture* (SAA*) relational database management
systems (RDBMSs).
This chapter introduces DataHub and the data flows it uses for its different tool
functions. A more detailed explanation of DataHub can be found in the Database
Systems Management: IBM SystemView Information Warehouse DataHub
Presentation Guide.
DataHub and SystemView Strategy
DataHub is a SystemView* conforming product in its user interface design and
approach to tools integration. Figure 1 positions DataHub in the SystemView
strategy.
Figure 1. DataHub and SystemView Strategy
Users can perform system management tasks on relational data anywhere in the
enterprise from a workstation control point (DataHub/2 workstation). A
consistent, object-action-based graphical user interface (GUI) gives a common
“look and feel” to all DataHub functions. Management includes all the traditional
data and database administration functions and is independent of both data
location and physical data characteristics. Management of RDBMSs is defined by
SystemView and Database Management.
© Copyright IBM Corp. 1993 1

DataHub in Information Warehouse Framework
DataHub′s object-action-based platform feature and integrated tools feature help
database administrators manage database objects throughout the enterprise.
DataHub′s tool integration capability is open and addresses database systems
management tasks in the areas of change, configuration, operations, and
problem management. Tool functions are initiated from the DataHub/2
workstation and may invoke other tool functions on the host systems. The tool
functions are written to predefined standards and use common services and
documented open interfaces, namely, Distributed Relational Database
Architecture* (DRDA*), Common Programming Interface - Communications
(CPI-C), and Common User Access (CUA*).
Figure 2 positions DataHub in the Information Warehouse* framework.
Figure 2. DataHub in Information Warehouse Framework
DataHub helps database administrators create and manage the Information
Warehouse environment in the following ways:
• Manage databases from single control point
From the DataHub/2 workstation DataHub helps manage operational
databases and information stores. DataHub provides a window on all
database objects and users throughout the information system.
• Display database objects
2 DataHub Implementation and Connectivity
DataHub displays and provides information on relational database objects
and their related components anywhere in the enterprise.
• Copy data to an information store
DataHub has the facility to copy database objects from one database to
another.

• Manage authorizations on relational data
1.1 DataHub Architecture Overview
With DataHub it is possible to display the authorizations for all objects and
users of a database in the system and then copy, add, or delete those
authorizations.
DataHub consists of a workstation component and host components. Each
DataHub component has a platform feature and an optional tools feature, both of
which operate as a client/server application.
The DataHub functions significantly simplify the tasks of database administrators,
system administrators, help desk personnel, system programmers, and
application programmers in a centralized or distributed database environment.
Figure 3 shows a possible DataHub configuration that supports four SAA hosts:
MVS, VM, OS/400, and OS/2.
Figure 3. DataHub Architecture
Each main DataHub user—DBA, Help Desk, and Sys Prog—has a DataHub/2
workstation that includes a GUI.
Chapter 1. Introduction to DataHub 3

1.1.1 Platform Feature
1.1.2 Tools Feature
4 DataHub Implementation and Connectivity
On each host, there is a host-specific DataHub component called DataHub
Support. The host component does not have a GUI; user access to DataHub
Support is from a DataHub/2 workstation only. In the same way, tools can be
initiated only from a DataHub/2 workstation.
The DataHub product set includes:
• The workstation component, including:
− DataHub/2 workstation platform feature
− Optional tools feature
− Optional requester feature
• The host components, including:
− DataHub Support/400 host platform feature with integrated tools feature
− DataHub Support/MVS host platform feature with an optional tools
feature
− DataHub Support/VM host platform feature with integrated tools feature
− DataHub Support/2 host platform feature with an optional tools feature.
Each DataHub Support host component is ordered separately.
The DataHub platform feature includes common services that provide
communications and run-time function between the DataHub/2 workstation and
the hosts. These common services facilitate the development, integration, and
execution of database systems management tools.
The Run function is part of the platform feature and is used to execute SQL, MVS
JCL, and Application Systems/400 SQL (AS4SQL) statements at a host. Those
statements are stored in an OS/2 file that DataHub/2 can recognize. If the input
file to Run contains only SQL, DRDA flows are used for all platforms except
OS/2, where RDS is used. For MVS JCL and AS4SQL statements, tools
conversation flows are used to send the file contents to DataHub Support at the
target host.
The DataHub Tool Builder′s Guide and Reference describes how to use the
DataHub common services when developing database systems management
tools.
The DataHub tools feature provides database systems management functions,
such as copying objects and managing authorizations. You can access the
functions through the DataHub/2 window, by entering the command and required
syntax from the command line, or by starting the command from the command
line and completing it in the DataHub/2 window. Commands can also be stored
in a command file and then retrieved and executed, thus reducing the effort
required for repetitive tasks.
The tools feature functions include the following:
• Utilities
The Utilities functions call utilities at a host. Not all Utilities functions are
available on all database managers. For instance, the local OS/2 Database
Manager (DBM) provides backup and recovery of OS/2 databases with a GUI.

The supported utilities are:
− Load
− Unload
− Backup
− Recover
− Reorganize
− Update Statistics.
• Copy Data
The Copy Data function enables you to copy object definitions like table,
view, and index, as well as table data from one database to another.
• Manage Authorizations
The Manage Authorizations function enables you to copy, add, or delete user
and object authorizations between and within databases.
• Display Status
The Display Status function enables you to see which processes are running
and the database activity on both local and distributed database
management systems (DBMSs).
Figure 4 is a sample of a DataHub/2 workstation window with database objects
and hosts displayed. The table Q.STAFF has been selected. Using the Copy
action of the Actions pull-down menu, the Q.STAFF table can be copied to any
other RDBMS.
Figure 4. Selecting the Copy Action
Chapter 1. Introduction to DataHub 5

1.2 DataHub Data Flows: Overview
Before implementing DataHub it is important to understand the different data
flows used by the DataHub tool functions. Once you understand the connectivity
issues of DataHub you can better evaluate the related connectivity
implementation tasks; that is, you first need to understand the network elements
and DRDA connectivity, implement DRDA, and then install DataHub on top of the
created DRDA environment. This is the approach we used in this book.
An understanding of data flows will also help you predict and understand
performance issues when using a given tool function in your environment.
Figure 5 depicts DRDA, Remote Data Services (RDS), and DataHub tools
conversation (TC) data flows.
Figure 5. Data Flow Overview
DataHub uses the following connectivity capabilities:
• DRDA flows
6 DataHub Implementation and Connectivity
To process SQL application programming interfaces (APIs), DataHub
requires DRDA connectivity between the DataHub/2 workstation and the SAA
non-OS/2 DRDA hosts. Connectivity between the OS/2 hosts and DataHub/2
workstation uses RDS. The DRDA connectivity between the DataHub/2
workstation and non-OS/2 DRDA hosts could use SAA Distributed Database
Connection Services/2* (DDCS/2*) at the DataHub/2 workstation or have the
DDCS/2 gateway installed at the server workstation as in Figure 5.
Remember that having a gateway is optional. In the figure we have DDCS/2
in a separate machine. All requests using DRDA flows going out of the
token-ring go through this DDCS/2 gateway. DRDA connectivity between

1.2.1 Run
managed OS/2 hosts and managed non-OS/2 DRDA hosts also requires
DDCS/2, which can reside on any OS/2 on the local area network (LAN).
• RDS flows
RDS connectivity is used to process SQL APIs between the DataHub/2
workstation and the OS/2 hosts. RDS connectivity is also used to connect
the DataHub/2 workstation to the DDCS/2 server gateway. RDS also would
be used if the DataHub database were on a separate machine.
• TC flows
A TC can be established between the DataHub/2 workstation and the hosts
to invoke remote host functions from a DataHub/2 workstation. The following
requirements apply to these TCs:
− Exchange attributes to ensure code-level compatibility.
− Send header information to allow correct trace correlation between the
DataHub/2 workstation and hosts.
− Send function requests to the host components.
− Receive function results from previous function requests.
The Run function is used to execute SQL, MVS JCL, and AS4SQL OS/400
statements at a host.
The statements for Run are in a file at the DataHub/2 workstation and may have
been generated by:
• Another DataHub tool function (Manage Authorizations, for example)
• Another file editor (an ISPF-generated SPUFI file in MVS, for example,
downloaded to the DataHub/2 workstation).
Functions
The main functions of Run and the main user options available are outlined
below.
• SQL statements
Run processes SQL data definition language (DDL), data manipulation
language (DML), or data control language (DCL). The SQL is processed
using DRDA. However, Run does not return to the user the result of the SQL
statement execution. Run returns only the return code telling how the SQL
statement executed at the host.
For SQL processing commands, the DataHub user can specify an integer
value for the COMMIT parameter, to avoid prolonged locks. The value of
integer specifies the number of statements to be processed between
COMMITs.
• JCL statements (MVS only)
All JCL statements must be fixed-length 80-byte records. DataHub/2 will
verify that the JCL statements are targeted for an MVS host. TC flows are
used to process JCL.
Usually JCL statements do not represent large volumes of data and should
not be a problem.
Chapter 1. Introduction to DataHub 7

1.2.2 Utilities
• AS4SQL statements (OS/400 only)
Run can process AS4GRANT and AS4REVOKE commands. Each AS4SQL
statement is parsed and then sent on TC flows for processing.
• Report File
8 DataHub Implementation and Connectivity
Run creates a report file containing the input statements and the results. The
REPORT parameter can have three different values:
− REPORT filename directs the report to the filename data set on the
DataHub/2 workstation. If the file already exists, the new report data will
be appended to the existing data.
− REPORT NO discards the output.
− REPORT DEFAULT causes a default filename to be created.
Data Flows
The data flows involved in the Run function are:
MVS DRDA flows are used to process SQL statements.
TC flows are used to process JCL statements.
VM DRDA flows are used to process SQL statements.
OS/400 DRDA flows are used to process SQL statements.
TC flows are used to process AS4SQL statements.
OS/2 RDS flows are used to process SQL statements.
We present below each DataHub Utilities function to help you understand the
data flow used.
Functions
Load: The DataHub Load function enables you to load data into an existing
relational table. The method that Load uses differs across the various RDBMS
platforms as follows:
DB2 The DB2 LOAD utility is used, and the user can use the DataHub
edit push-button to edit the generated MVS JCL prior to execution.
SQL/DS The DBSU DATALOAD is used.
OS/400 CPYF, CPYFRMDKT, or CPYFRMTAP is used, depending on the
device specified.
OS/2 The SQLGIMP API is used to import data from a file on the
DataHub/2 workstation or the LAN.
Unload: The Unload function extracts data from an existing relational table in
any RDBMS and places it in a sequential file at that RDBMS. For an OS/2 host,
the sequential file can be a LAN file. The method that Unload uses differs across
the various RDBMS platforms as follows:
DB2 There is no unload utility in DB2. The DataHub UNLOAD function
for DB2 generates MVS JCL for DSNTIAUL. Alternatively, the user
can select the DataHub REORG function and use the edit
push-button to edit the generated JCL and specify UNLOAD ONLY
in the JCL. A subset of data can be unloaded.

SQL/DS The DBSU DATAUNLOAD is used. Note that subsetting by row or
column is not supported.
OS/400 CPYF, CPYTODKT, or CPYTOTAP is used, depending on the device
specified. Subsetting of data is not supported.
OS/2 The SQLGEXP API is used to export data. Subsetting of data is not
supported.
Both the Load and Unload functions operate at only one RDBMS at a time; each
function produces a report that includes the statements processed and the
results of the processing.
Backup: The Backup function creates a copy of the table data suitable for
recovery. The Backup function applies only to tables; it does not support views.
The method that Backup uses differs across the various RDBMS platforms as
follows:
DB2 The DB2 COPY utility is used. The default SHRLEVEL applies; if the
table is partitioned, DataHub warns the user that all PARTS will be
copied. The warning is in the form of comments embedded in the
generated JCL. An incremental copy can be taken only if the
DataHub user edits the MVS JCL before execution.
SQL/DS The DataHub Backup function is not supported, and DataHub will
tell the user to use the Unload function.
OS/400 The CL command SAVOBJ is used, but the journal files are not
eligible for DataHub backup.
OS/2 The DataHub Backup function is not supported, and DataHub will
tell the user to use the Unload function.
Recover: The Recover function retrieves a previous backup copy of the data and
applies the changes committed since the backup was taken. Recover is therefore
to the current point in time (PIT). Again, the method that Recover uses is
platform-specific:
DB2 The DB2 RECOVER utility is used, although DataHub does not
support all options. Recover to a previous PIT is only possible by
editing the generated MVS JCL. DataHub Version 1 Release 1 does
not support RECOVER INDEX.
SQL/DS The function is not supported. If DataHub users attempt to recover
an SQL/DS table, DataHub will tell them that they should consider
using the Unload and Load functions.
OS/400 The CL commands RSTOBJ and APYJRNCHG are used. DSPJRN is
also used to determine the start and/or end points for APYJRNCHG.
OS/2 The function is not supported. If DataHub users attempt to recover
an OS/2 table, DataHub will tell them that they should consider
using the Unload and Load functions.
Reorg: The Reorg function reorganizes table and index data to reclaim space
and sort the data. Before execution, the DataHub user can specify FREESPACE
values for DB2 and SQL/DS indexes and DB2 tables and the sequencing index
for OS/400 and OS/2 tables. The method that Reorg uses is platform-specific:
DB2 The DB2 REORG utility is used. The DB2 REORG SORTDATA
parameter is supported by DataHub.
Chapter 1. Introduction to DataHub 9

1.2.3 Manage Authorizations
10 DataHub Implementation and Connectivity
SQL/DS There is no table reorg function in SQL/DS, but REORG index is
supported. The DBSU REORGANIZE is used.
OS/400 The RGZPFM command is used for tables, but there is no index
reorg function in OS/400. The DataHub user can specify which index
is to be used for sequencing the table data.
OS/2 The SQLGREOR API is used. The Reorg index is not supported.
Update Statistics: The Update Statistics function updates RDBMS catalog
statistics. The method that Update Statistics uses is platform-specific:
DB2 The RUNSTATS utility is used. The DataHub user may either specify
ALL to include table and index statistics or edit the JCL before
execution and specify RUNSTATS INDEX to limit processing to an
index.
SQL/DS The UPDATE STATISTICS FOR TABLE function is used, which
includes index statistics. If statistics for all columns are required,
the DataHub user can specify ALL.
OS/400 The DataHub Update Statistics function is not supported, as the
operating system keeps current the catalog statistics.
OS/2 The SQLGSTAT API is used. If the DataHub user specifies ALL,
index statistics are also updated.
Data Flows
The data flows used for the DataHub Utilities function are as follows, by platform:
MVS MVS uses standard DRDA flows to extract tablespace information
from the target DB2 host (this is required to map the user-selected
table to the correct DB2 tablespace). The Run function is then
invoked and uses the TC flows defined earlier.
VM Update Statistics function uses DRDA flows in VM (UPDATE
STATISTICS is an SQL statement in SQL/DS). The other utilities
use TC flows to process DBSU commands.
OS/400 Utilities use TC flows, generate OS/400 Control Language control,
and pass the command parameters to the host in the EMQDA. The
OS/400 commands are executed using the OS/400 CLI.
OS/2 Utilities functions are directly supported by OS/2 Database Services
utilities. If the utilities run on the local OS/2 DBMS, they use OS/2
flows to the Database Services APIs. Utilities that act on remote
RDBMSs use RDS.
We present below each Manage Authorizations (MA) function to help you
understand the data flow used.
Functions
Add authorizations: From the DataHub/2 workstation, MA can add SQL
authorizations that are processed at any relational database registered to
DataHub. This includes AS4SQL statements introduced by DataHub for OS/400
authorization processing.
Delete authorizations: MA can also delete authorizations at any relational
database host registered to DataHub.

1.2.4 Display Status
Copy object authorizations: Authorizations for an object at a source relational
database can be copied to a target relational database. MA evaluates and
reports any implications attributable to differences in SAA hosts. The same
relational database can be the source and target relational database.
Copy user authorizations: User authorizations can also be copied, from one
relational database to another, and within the same relational database.
Perform authorization translation: During copy, MA uses translation tables to
convert a source authorization to a target authorization. This translation is
required when the source authorization is not supported at the target system.
Processing options: MA provides a number of processing options. The DataHub
user can specify:
• Whether MA should continue or stop processing after an error.
• The commit frequency, as an integer value. The commit frequency
corresponds to the number of SQL statements processed between COMMITs
at the target relational database.
MA provides an implications report option. This is especially useful if the
DataHub user is not experienced in the host environment where this function is
being used. MA reports the following implications:
• For DB2 and SQL/DS, the objects and authorizations affected by cascading
delete requests. (There is no equivalent in OS/2 or OS/400.)
• In OS/400, the implications when PUBLIC and authorization lists are involved,
and when the object is a table or a view.
• For copy between unlike relational databases, each authorization translation.
Data Flows
The data flows involved in the MA function are:
MVS and VM DRDA flows are used for processing SQL and catalog extracts.
OS/400 TC flows are used for processing AS4SQL and catalog extracts.
OS/2 RDS is used for remote OS/2 RDBMSs, and OS/2 DBM APIs are
used for local OS/2 RDBMSs.
The Display Status function enables the user to obtain information about
database activity in OS/400, SQL/DS, and DB2 RDBMSs.
Functions
The Display Status function can be used to:
• List status of all units of work for a user at a given DataHub-managed host
• List status of all RDBMS work at a relational database
• List status of RDBMS work at another system
• Display lock for a given piece of work
• Display work holding or waiting for a lock on a given object.
At the DataHub/2 workstation Display Status coordinates the Display Status
function. It processes the input DISPLAY command, generates the Display
Status flow with the host using the platform common services, and invokes the
Chapter 1. Introduction to DataHub 11

1.2.5 Copy Data
12 DataHub Implementation and Connectivity
Display Status host component to perform the Display Status function at the host
and process the host output.
Data Flows
The Data flows involved in the Display Status function are:
MVS DataHub/2 TC flows are used for conversations with DataHub
Support/MVS on an MVS host. The DB2 Instrumentation Facility
Interface (IFI) API is used to retrieve information from DB2.
VM DataHub/2 TC flows are used for conversations with DataHub
Support/VM on a VM host. The SHOW operator command is used
to retrieve the information in VM.
OS/400 DataHub/2 TC flows are used for conversations with DataHub
Support/400 on an OS/400 host. OS/400′s CL (Control Language)
API is used to retrieve the information from OS/400.
Copy Data (CD) helps you copy relational data from one RDBMS to another, or
within the same RDBMS. The source and target RDBMSs can be like or unlike.
Functions
CD generates the necessary SQL DDL for the target system and copies related
objects at the same time. If requested, authorizations can also be copied.
Tables, views, indexes, and authorizations associated with these database
objects are eligible for CD processing. In addition, multiple tables, single or
multiple views, views on views, underlying base tables, and referential
constraints can be copied.
When the source and target RDBMSs are unlike, DDL translation might be
required. For example, a source AS/400 CHAR column data type definition with
length 4000 is translated to LONG VARCHAR for a target DB2 table definition.
CD copies objects, as well as the authorizations associated with the objects.
Optionally DataHub/2 provides an authorization translation mechanism using
data stored in tables. The objective of these tables is to relate functionally
equivalent authorizations across unlike host RDBMSs.
Three valid combinations of CD execution are available:
• Generate DDL/DCL and stop
• Generate DDL/DCL, process at target, and stop
• Generate DDL/DCL, process at target, and copy and load data.
For each of these operations, the user can optionally store the generated SQL
statements in a file at the DataHub/2 workstation.
CD usage should be considered carefully because copying data from one
RDBMS to another could have a serious impact on your network.
The unload/load method is system-specific and allows the user to select one of
the following options:
• Add the data to an existing table
• Validate that the table is empty, and stop if this is not true.

The data is FETCHed by the target host, then written to the target table (see
Figure 6 on page 13). This fetching process allows BLOCK FETCH to be used
and is more efficient than remote INSERT, which operates one row at a time.
The method used to write to the target table is platform-specific.
CD operation is perceived by the user to be a single step. If the source RDBMS
is on OS/2, this method cannot be used. Remember that OS/2 has implemented
the client DRDA capability. So, for you to copy data from an OS/2 DBM, CD has
to send the request to the OS/2 source instead of the target as it does for all
other platforms. Therefore the OS/2 DBM will use the insert process from the
source to the target.
Figure 6. Copy Data Flows for MVS, VM, and OS/400 Platforms. This figure illustrates
the connectivity between the DataHub/2 workstation and the source and target hosts. It
applies to MVS, VM, and AS/400 hosts.
Data Flows
CD uses different data flows depending on the type of platform involved. Refer to
Figure 6 to understand the following explanation of data flows:
• DataHub/2 workstation
The DataHub/2 workstation CD component coordinates the copy operation.
MA generates the required DCL, and CD calls Run to process DDL and DCL
at the target host. The DDCS/2 application requester (AR) initiates the DRDA
flows with the source and target hosts.
• Source host
The source host acts as an application server (AS) to the DataHub/2
workstation to get the SQL generation. It also acts as server for the copy
operation to the target host.
Chapter 1. Introduction to DataHub 13

• Target host
The target host is both an AS and an AR and executes DataHub functions
using TC flows. As an AS, the target processes SQL to create the objects
from the DataHub/2 workstation AR. CD at the DataHub/2 workstation
processes the command request to initiate the copy operation. The target
host is the AR for the copy and load of data.
Note that CD first verifies with the target that the requested CD operation is
valid, before generating SQL. (The operation is invalid if, for example, the user
specifies that the target table is empty, but it is not.)
The same CD procedure is not possible with the function currently available on
OS/2. The process used in this case is explained in two steps: (1) object
creation and (2) the CD operation itself.
Object creation
14 DataHub Implementation and Connectivity
In the object creation process the RDS flow is used to query the catalog to get
the object definition at the source and to create the objects at the target. Refer to
Figure 7.
Figure 7. Copy Data Involving OS/2 Hosts
• RDS used for catalog queries - if an OS/2 source
For the copy operation to extract the object definition from the source OS/2
host catalog, DataHub uses RDS, which is an OS/2 DBM API function.
• SQL processed using RDS - if an OS/2 target
As with catalog requests, processing of SQL to create the objects at a target
OS/2 host uses RDS. In fact, this function is performed by Run, which the CD
calls to process SQL.

Copy Data
Once the catalog object definition has been extracted from the source, and the
SQL object creation phase has completed at the target, CD copies and loads the
data. When an OS/2-managed host is involved, mechanisms for copying data
vary slightly across the three combinations of CD execution:
• OS/2 source and unlike target
Figure 8 shows the data flows involved in copying data from an OS/2 source
to an unlike, managed, DRDA host.
Figure 8. Copy Data from OS/2 Source to Unlike Target
The DataHub/2 workstation sends the copy request to the source DataHub
Support/2 using TC flows. DataHub Support/2 then fetches the data from the
local database and inserts it at the target system using DRDA flows through
DDCS/2.
DRDA flows are used for the copy process.
• OS/2 target and unlike source
Figure 9 on page 16 shows the data flows involved in copying data from an
unlike, managed, DRDA host to an OS/2 host.
Chapter 1. Introduction to DataHub 15

Figure 9. Copy Data to an OS/2 Target from Unlike Source
In this case, the DataHub/2 workstation sends the copy command to the
target OS/2, using TC flows. The target fetches the data from the source
database using DRDA flows and finally inserts it into the local database.
DRDA flows are used for this copy process.
• OS/2 source and target
16 DataHub Implementation and Connectivity
Figure 10 shows the data flows involved in copying data from a managed
OS/2 host to another managed OS/2 host.
Figure 10. Copy Data from OS/2 Host to OS/2 Host

1.3 Data Flow Summary
When both source and target are OS/2 hosts, the DataHub/2 workstation
sends the copy command to the target using TC flows. The target fetches the
data from the source using RDS and inserts it into its local database.
Table 1 indicates the outbound protocol used for each function initiated by the
DataHub/2 workstation for the target host environment. The Copy Data and Copy
Data with load functions use several data flows, so we show them in a separate
table (Table 2). For example, for a copy with load from a DB2 host to an OS/2
DBM host, the request is sent to the OS/2 host using the TC flows. The OS/2 host
will copy and load using the DRDA flows.
If you have a DDCS/2 gateway system in your environment, the data flows
between the gateway and the DataHub/2 workstation are always RDS.
Table 1. Data Flows Used by Tool Functions. This table shows the data flows used
between the DataHub/2 workstation and the different hosts.
Function MVS Host VM Host AS/400
Host
Run (SQL) DRDA DRDA DRDA RDS
Run (JCL) TC N/A N/A N/A
Run (AS4SQL) N/A N/A TC N/A
Display RDBMS work TC TC TC N/A
Manage Authorizations DRDA DRDA TC/DRDA RDS
Display Status DRDA DRDA DRDA RDS
Load TC TC TC RDS
Unload TC TC TC RDS
Backup TC N/A TC N/A
Recover TC N/A TC N/A
Reorg TC N/A TC RDS
Update Statistics TC DRDA N/A RDS
Table 2. Data Flows Used by Copy Data
Copy Data Steps MVS Host VM Host AS/400
Host
Object Creation
(non-OS/2)
Copy Data
(non-OS/2)
Object Creation
(OS/2 source)
Copy Data
(OS/2 source)
Copy Data
(OS/2 target)
DRDA DRDA DRDA N/A
TC/DRDA TC/DRDA TC/DRDA N/A
RDS/DRDA RDS/DRDA RDS/DRDA RDS
OS/2 Host
OS/2 Host
TC/DRDA TC/DRDA TC/DRDA TC/RDS
TC/DRDA TC/DRDA TC/DRDA TC/RDS
Chapter 1. Introduction to DataHub 17

18 DataHub Implementation and Connectivity

Chapter 2. Planning for DataHub
You have just been given the job of installing a management system for your
company′s databases. You cannot carry out the project yourself but you do
know who in your organization you need to enlist to be successful. You do know
that there are various host systems, users in several remote locations, and a
network tying them together. Your first job should be to determine which data is
to be managed, who owns the data, and who will manage it. You can then
design a DataHub solution based on your requirements.
To assist you in developing an installation plan that fits your environment, this
chapter describes three typical customer scenarios and defines the DataHub
components and other OS/2 prerequisites required for each. We also discuss
the different skills needed to implement each component.
Once you have defined your plan, you should read the subsequent chapters to
lead you through the implementation.
Before you install DataHub you must provide the correct network connectivity
and an environment that supports the DRDA architecture. Chapter 3, “DRDA
Connectivity” on page 31 shows you how to do this.
As you will see in the scenarios, there is more than one way to implement
DataHub. Some configurations provide more function and require more
components than others. We discuss the OS/2 options in Chapter 4, “DataHub/2
Workstation” on page 105.
After you have installed a network and the DataHub/2 environment, Chapter 5,
“DataHub Tools Conversation Connectivity” on page 151 will help you tie it all
together into a working, DataHub-managed system.
2.1 Customer Business Requirements
DataHub provides management of relational databases. You want to be able to
manage local data, remote data, or combinations of both. Your environment is
comprised of one or more of the following:
• Local management of local data (one to one)
All data is in the same physical location, possibly on a local network of
several workstations. The administrator is responsible for authorizing new
users, backing up the data, and restoring data in the event of a failure.
• Central management of distributed data (one to many)
The administrator in this case looks after the management of all central
databases on different host platforms. Subsets of some data are required for
application testing. The administrator also is responsible for normal backup
and restore as well as user authorization.
• Distributed management of distributed data (many to many)
Several people manage data in remote and central locations. Remote
administrators have full control over local data and some functions at the
central site. Central administrators have full control over all data.
© Copyright IBM Corp. 1993 19

2.2 Sample Scenarios
Let′s see how DataHub is used in each of these environments.
For each sample scenario, we show the required components of DataHub and
their interrelationship. You can then select those components that match your
environment and use or modify the appropriate configurations. We include the
actual configurations we used in our scenarios.
2.2.1 Scenario 1: Local Management of Local Data
20 DataHub Implementation and Connectivity
You have one OS/2 production database and would like to manage it with
DataHub just to see what function DataHub provides. Your database
administrator accesses DataHub from a control point—an OS/2 system running
DataHub/2 as illustrated in Figure 11. The database you manage resides on
what we call a source system. In this scenario, one function you use is Copy
Data for backup requirements. The database tables on the source system are
copied onto a third system, the target system. We select this scenario because
it shows the function of each DataHub component in OS/2 and the relationships
between DataHub/2, DataHub Support/2, and the OS/2 Database Manager.
Figure 11. Scenario 1: Local Management of Local Data

Components Required
• DataHub/2 workstation
− OS/2 version 2.0
− OS/2 Communications Manager and OS/2 Database Manager
− LAN Adapter and Protocol Support (LAPS)
− DataHub/2
• Managed host
− OS/2 version 2.0
− OS/2 Communications Manager and OS/2 Database Manager
− LAPS
• Target
− OS/2 version 2.0
− OS/2 Communications Manager and OS/2 Database Manager
− LAPS
− DataHub Support/2.
The managed host is the source of any data tables. DataHub/2 on the DataHub/2
workstation reads the catalog information on the managed host and target
machine. DataHub Support/2 on the target uses basic OS/2 Database Manager
Remote Data Services (RDS) to communicate with the OS/2 DBM on the
managed host. Notice that the managed host does not have any DataHub
components. We show in Chapter 4, “DataHub/2 Workstation” on page 105 how
this configuration works. For planning purposes, this scenario shows a minimum
configuration and introduces the components and their function. The managed
host cannot be a target of any DataHub functions unless DataHub Support/2 is
installed on it.
Function Provided
Full DataHub function is provided within the OS/2 platform with the managed
host as the source for data only.
Skills Required
The person implementing DataHub is probably your local database
administrator. All components are installed on the OS/2 platform, so some PS/2*
LAN skills are required.
Chapter 2. Planning for DataHub 21

2.2.2 Scenario 2: Central Management of Distributed Data
You have several host databases on different platforms (see Figure 12). One
person looks after all database administration functions. You want full DataHub
function across all platforms.
Figure 12. Scenario 2: Central Management of Distributed Data
Components Required
• DataHub/2 workstation (administrator′s workstation)
− OS/2 version 2.0
− OS/2 Communications Manager and OS/2 Database Manager
− LAPS
− DDCS/2, single-user version
− DataHub/2
22 DataHub Implementation and Connectivity

• Managed host—OS/2
− OS/2 version 2.0
− OS/2 Communications Manager and OS/2 Database Manager
− LAPS
− DDCS/2, if source or target of cross-platform function
− DataHub Support/2
• Managed host—MVS, VM, or OS/400
− Applicable operating system and database
− DataHub Support
• Network
− VTAM configured for APPC connectivity between nodes. Table 1 on
page 17 shows the protocols used between DataHub/2 and the different
hosts.
Note: You need the multiuser version of DDCS/2 to provide a gateway to DRDA
from the DataHub/2 workstation and host 1. Multiuser DDCS/2 requires an OS/2
Database Manager server. In this scenario DDCS/2 is on the managed host 1
machine. It also could have been on another machine.
If you do not have host 1, you could install the single-user version of DDCS/2 on
the DataHub/2 workstation to gain access to the other hosts. Single-user
DDCS/2 does not require an OS/2 Database Manager server.
Function Provided
• Full DataHub function is available on all managed hosts.
Skills Required
• The same OS/2 skills are required here as in scenario 1.
• Your database administrator coordinates the definition of database names
and authorizations.
• Network systems programmers help with connectivity issues.
Chapter 2. Planning for DataHub 23

2.2.3 Scenario 3: Distributed Management of Distributed Data
An enterprise has several branches in various locations. Several central
administrators control all central data and have some control of the remote
systems. Each branch uses local and central data. The remote branches are
large enough to require a LAN and host connectivity. The local data is stored on
a LAN server, which is also the communications gateway. Several people in the
branch manage the local data, and one of them is responsible for getting
subsets of local data from the central host. Figure 13 represents one of the
branch installations with three administrators.
Figure 13. Scenario 3: Distributed Management of Distributed Data
Components Required
• Same as scenario 2, plus
24 DataHub Implementation and Connectivity
− LAN server at the DataHub/2 server
− LAN requester at each DataHub/2 workstation
− OS/2 Database Manager server on the DataHub/2 server
− OS/2 Database Manager clients at each DataHub/2 workstation

− DDCS/2 multiuser version. The DDCS/2 multiuser does not have to be
on the DataHub/2 server machine. However, it must be on the same
machine as the OS/2 Database Manager server. If you put the
DataHub/2 database and DDCS/2 on different machines, you need an
OS/2 Database Manager server on each.
Refer to Chapter 4, “DataHub/2 Workstation” on page 105 for LAN design
considerations.
Function provided
• Full DataHub function is provided across platforms.
• Ease of maintenance of DataHub/2 workstations. DataHub/2 program code
and the DataHub/2 database are stored on the LAN and DataHub server
machine. Cross-platform host access is centralized in the DDCS/2 gateway.
See Table 16 on page 144 for LAN server dependencies on OS/2 versions.
Skills Required
Each additional level of access and data availability builds on the products
installed and therefore the skills in the previous scenarios. Some LAN
administration skills are required in scenario 3 because of the LAN requester
and LAN server. A help desk may be needed in this environment to assist users
in problem determination.
Chapter 2. Planning for DataHub 25

2.3 Factors Affecting Implementation
Your installation of DataHub will be unique. The following factors determine
what shape your solution will take:
• Number of databases to be managed
• Location of the data
• Type of RDBMS
• Number of administrators
• Location of the administrators
• Centralized or decentralized control
• Existing network.
Once these factors are known, you can start to place the components in the
proper locations in the network and plan the connections. In some cases you
may have to make changes to the existing environment; in other cases you can
configure the components to match the standards adopted by your organization.
2.4 Planning for Implementation: A Checklist
2.4.1 Gather Information
This section covers some of the factors you should consider for your specific
environment. Once you have gathered the information on the data you want to
manage, you can design a system using DataHub that satisfies your
requirements. You can then determine the skills required to implement the
system and establish naming conventions for your DataHub installation.
You need to know which data you want to manage, who will use and manage it,
and how it is distributed.
Data to Be Managed
Your most important design consideration is defining the data to be managed.
First, determine:
• Number and location of databases
• Number and size of tables
• Which tables to manage
26 DataHub Implementation and Connectivity
• Which DataHub functions are required
• When each function is executed
• Whether data is local or enterprise
• Where backup data is stored.
Once you understand the scope of the data, you can determine the size of the
management workload.

2.4.2 Design the Solution
Users
You need to know who uses the data and who manages it. For users of local
data, determine:
• Number and location of users
• Peak periods, time available for management functions.
For DataHub administrators, find out:
• Number and location of current administrators
• What tasks the administrators perform
• Whether management should be local or central.
Knowing who manages the data will help you determine where and how the
DataHub products should be installed to provide the function you need.
Network
The complexity of data management is influenced to a large extent by how the
data is distributed. Large networks probably have data dispersed on multiple
nodes. Your greatest challenge in installing DataHub is connecting the
DataHub/2 workstations to the managed hosts and then interconnecting the
hosts. So you must document your network definitions and include:
• Hosts and the databases they contain
• VTAM and NCP locations, names, and full definitions
• Gateway nodes if any
• Line speed of each link and protocols carried
• LAN types and speeds
• LAN bridge or router locations and segment names.
You should now have a good picture of your network topology. You will refer to
it to provide the APPC and DRDA connectivity DataHub requires.
Once you have gathered all of your data management information, you are in a
position to select and assemble the components required to implement DataHub.
DataHub/2 Workstation
Refer to Chapter 4, “DataHub/2 Workstation” on page 105 for LAN design
considerations.
• Determine topology for:
− Single DataHub/2 workstation
− LAN connections for server-based, multiple DataHub/2 workstations
• Install and configure all prerequisites for DataHub/2.
Chapter 2. Planning for DataHub 27

Managed Hosts
• Install and configure appropriate DataHub Support program and
prerequisites.
APPC Network
Provide connections between:
2.4.3 Determine Skills Required
2.4.4 Naming Conventions
28 DataHub Implementation and Connectivity
• DataHub/2 workstations and managed hosts
• Managed host to managed host if source or target of DataHub functions.
You can see now that the skills needed to implement DataHub come from more
than one person in your organization. You probably already have most of the
skills available, but this may be the first project that needs a combination of
skills in separate areas of the business. You need to have all of these areas
contribute, and you need someone to coordinate the different tasks.
Management of the DataHub Implementation Project
In a cross-platform implementation, your database administrator should be the
project coordinator. The coordinator calls on the services of the host, network,
and workstation specialists to bring all the components together. The database
administrator is also the person who can answer most of the data location and
volume questions.
LAN
Regardless of your host configuration, if you have more than one DataHub/2
workstation, they are most likely be on a LAN. Therefore additional LAN skills
are required for requester-to-server connections in setting up the LAN server
definitions for clients, DataHub/2 databases, and program files.
Network
You need appropriate skills in VTAM, SNA LU 6.2, and OS/2 Communications
Manager to define and configure the network from the workstations to the host
databases and between hosts directly. The network definitions are also used in
the workstations.
Host
For each host platform, appropriate skill is required to install and configure the
DataHub Support product and connections to the network.
When you use DataHub to manage your databases, you invoke programs on
machines connected by a network. Each of these programs, machines, and the
network must be uniquely identified. You do this by naming them. You also give
names to users, databases, tables, locations, aliases, hosts, DataHub/2
workstations, servers, logical units and their partners, and the network nodes.
Some of these names, such as the names of programs, are fixed. Most are your
choice, but you should have a standard way of selecting names. Refer to
Table 19 on page 154 and Table 20 on page 154 for the conventions we used in
the ITSC. For instance, we prefixed database names with a single character
representing the host type: O, A, V, and M for OS/2, AS/400, VM, and MVS,
respectively.

SNA Network
The SNA LU 6.2 architecture manages the connections from DataHub/2
workstations to databases and between databases. The names defined on any
node are referenced by the partner node. These names include network ID,
destination address, local address, logical unit, transmission service mode,
location name, database name, and transaction program name. Each name
becomes part of the address or conversation when setting up a link.
Your network administrators have probably defined most of the naming
standards discussed below. They are mentioned here to assist you in matching
your definitions to existing items. Refer to Chapter 3, “DRDA Connectivity” on
page 31 and Chapter 5, “DataHub Tools Conversation Connectivity” on
page 151 for more detail on DRDA and SNA definitions.
Network Identification: One physical network may provide a path for data flow
between nodes on different logical networks. The logical network is named by
VTAM or NCP definitions. A physical connection is necessary but does not
ensure the logical link. The network identification is similar to the country line
on an envelope you mail.
Logical Unit, Partner Logical Unit, Transaction Program Name: These are
defined by network and database administrators. A logical unit is a name given
to a user or application. An application at an LU refers to the LU name of the
application to which it is trying to connect. For instance, XXX is an LU on OS/2.
YYY is an LU on OS/400. XXX wants to talk to YYY. YYY is a partner LU from
XXX′s viewpoint. Once connected, XXX wants YYY to run program name ABC.
Transmission Service Mode: The name of the transmission service mode on
each end of the conversation must be the same. It defines the block size and
number of blocks to send or receive at one time. See your network administrator
for this definition.
Location and Database Names: Your database administrator should define
these.
Local Area Network
We assume that the hosts and databases already exist and are waiting to be
managed by DataHub. Your DataHub/2 workstation may be an OS/2 system that
is directly attached to your managed host. This connection requires the fewest
configuration changes and prerequisites. If you have one or more DataHub/2
workstations on a LAN, installing DataHub/2 and its prerequisites requires
adding definitions to the existing LAN. This section points out some of these
changes or additions.
You define several items within the LAN environment—on the workstations, LAN
servers, and database servers. Some of the names you give these items are
aliases. An alias is the name of a definition list. The alias is only known at the
place where it is defined. The items in the list point to the real resource, node,
database, or program being defined. A user or application refers to an alias to
access the definition of the resource. Therefore different users could refer to the
same host database by different names. This makes administration or problem
determination difficult unless some convention is used. Refer to Chapter 4,
“DataHub/2 Workstation” on page 105 for more details on aliases.
You should define conventions for:
Chapter 2. Planning for DataHub 29

• Physical resources
− Requester workstation
− LAN server or database server
− Locally administered LAN adapter address
− LAN segments, bridges, routers
• Logical resources
− DataHub/2
- Host and profile names
- RDB names
− OS/2 Database Manager
- System directory aliases
- Workstation directory aliases
- Database names.
2.5 Summary and Recommendations
30 DataHub Implementation and Connectivity
This chapter presents three scenarios that relate your business requirements to
the DataHub components. You should by now have some idea of how to install
DataHub to satisfy your requirements.
Consider the following recommendations as you read further. Keep them in
mind and relate the recommendations to the appropriate area of each
subsequent chapter.
• Test each component individually as it is installed. Before you attempt an
LU 6.2 session on a newly defined node, see if you can activate a 3270 or
5250 session. This will verify the physical connection.
• Do not wait until DataHub is installed to try your DRDA connections. If
DDCS/2 is one of your prerequisites, use the command line interface to
connect to the remote database. This will verify the OS/2 Database Manager
catalogs and logical connections.
• If you are replacing an existing function or connection with new code, make
sure the old function or connection still works before you build onto it.
• DataHub creates log, error, and report files during installation and execution.
If you have any problems, look at these files.
• Look in the product manuals to see which trace facilities are provided.
Learn how to start and read the traces available and get your VTAM, OS/2,
and host database administrator to help with problems.
• Start small. If your implementation looks like scenario 3, run a pilot on a
single DataHub/2 workstation. This approach will provide a functioning
DataHub environment without the additional complexity of clients and
servers. Your LAN administrator can set up the server once the base
DataHub/2 function works. Additional DataHub/2 clients can be added easily.
The first DataHub user will be the most difficult and requires the most work
on your part.
• Keep a log of any problems encountered and the solution. Someone else
may waste time researching a problem you have already solved.

Chapter 3. DRDA Connectivity
3.1 SNA Environment
SNA is the foundation for DRDA implementation. In this chapter we review some
SNA network concepts and definitions. The review will help database
administrators implementing DRDA and DataHub understand the networking
elements they might have to discuss with the network specialists in their
enterprises.
DRDA is the foundation for DataHub implementation. In this chapter, we explain
how to implement DRDA connectivity. We emphasize the key connectivity
parameters that link the different SAA platforms to enable them to communicate
using DRDA.
We present the definitions we used to interconnect the different hosts that are
part of the ITSC DRDA and DataHub network. The ITSC network uses the
token-ring connection to interconnect the SAA platforms. Because each
customer environment differs, you should consider our definitions only as
examples that will help you define your own network. We do not discuss all the
possible physical connections because we only implemented one of them.
We also provide you with a list of actions you need to perform to add another
relational database management system (RDBMS) to your DRDA network.
Finally, we end with some recommendations you may find useful when you
implement your DRDA network.
Before we begin to explain DRDA connectivity, it will be useful to review some
SNA network concepts and definitions.
Physical unit (PU) A PU is not necessarily a physical device. It is part of
a device (programming, circuitry, or both) that
performs control functions for the device. It takes
action during device activation and deactivation, error
recovery, and testing. A host running ACF/VTAM, a
communication controller loaded with an NCP, and a
cluster controller are examples of PUs.
Logical unit (LU) An LU is a user of the SNA network. It is the source
of requests entering the network. An I/O device, an
output printer, an application running in the host (DB2,
DataHub, TSO, CICS, IMS) are examples of LUs.
System Services Control Point (SSCP)
An SSCP is a unit of code within ACF/VTAM that
manages a particular area of the network. Starting and
stopping resources, assisting in the establishment of
connections between LUs, and reacting to network
problems are the tasks performed by the SSCP.
Network Control Program (ACF/NCP)
ACF/NCP is a product installed on the host that can be
used in conjunction with the ACF/SSP (System Service
Program) to generate the Network Control Program
© Copyright IBM Corp. 1993 31

32 DataHub Implementation and Connectivity
(NCP) load module, which is loaded from the host into
a communication controller (3745, 3720, 3725, or 3705).
The NCP controls the lines and the devices attached
to it. It transfers data to and from the device and
handles any errors that occur, including retries after
line errors.
Network Addressable Units (NAUs)
NAUs are elements in the network that ACF/VTAM can
address. LU, PU, and SSCP are elements that
ACF/VTAM can address. VTAM cannot address lines
and connections directly.
Nodes The term “node” is used in two different contexts. In
SNA terms, a node is a physical device, such as a
host processor, a communication controller, a cluster
controller, a terminal, or a printer. Nodes are
categorized according to their capability as either host
nodes, boundary nodes, or peripheral nodes. In VTAM
terms, a node is any point in a network defined by a
symbolic name. There are major nodes and minor
nodes.
Subarea addressing A subarea is a portion of the network that has a
boundary node and includes any peripheral nodes
attached to this subarea node. SSCPs and NCPs are
subarea nodes.
Domain A domain is that part of the network that has been
activated by one particular SSCP. There is only one
SSCP in a domain.
Cross-Domain Resource Manager (CDRM)
A CDRM is a definition in VTAM of the SSCPs in the
other domains. A CDRM definition is necessary for
cross-domain communication.
Cross-Domain Resource (CDRSC)
A CDRSC is the definition in VTAM of a resource that
resides outside the VTAM domain.
Session A session is a logical connection between two NAUs.
SSCP to PU, SSCP to LU, LU to LU, and SSCP to SSCP
are examples of the possible types of sessions that
can be established.
Bind In networking terms, a bind is a particular request unit
that flows from the primary LU to the secondary LU.
The bind is the first request unit to flow on the
LU-to-LU session at session startup. It is via the bind
(and bind negotiation) that the two LUs agree on the
protocols to be used on the session. The information
in the bind comes from the LOGMODE definition.
Logon mode (LOGMODE) The LOGMODE is used to determine the
characteristics of a session. It includes Class of
Service (COS), pacing, RU size, and protocol
information.

3.2 Key Connectivity Parameters
3.2.1 SNA Parameters
Logon Mode Table (MODETAB)
The MODETAB is a table that contains the LOGMODE
entries. There can be multiple MODETABs in an
SSCP.
Request unit (RU) size An RU is the part of a transmission flowing across the
network that contains data for the use of the
destination network node. The node can be an LU,
PU, or SSCP.
The RUSIZES parameter specifies the maximum length
of data one LU can send to its session partner. This
parameter is specified in the LOGMODE definition.
Path information unit (PIU)
The PIU is the basic unit that is transmitted around the
network. It has to hold enough information for it to find
its way through the network to the destination LU,
maintain the protocols that are being used on the
session, and carry the data that the user wants to
send. The PIU consists of:
• Transmission header (TH), which is 26 bytes long
• Request/response header (RH), which is 3 bytes
long
• RU, which is the message or user data.
For more information on the above concepts and definitions you should look at
VTAM and NCP publications listed in the Related Publications section of this
book.
This section explains the key connectivity parameters used to implement a
DRDA network. The parameters we discuss can be divided into three groups:
• SNA parameters
• DRDA parameters
• RDS parameters.
The key parameters discussed below are used to establish the physical and
logical connections in the SNA network.
Token-Ring Address
In a client/server environment, usually the client or the originator of the request
needs to know how to get to the server, and the server needs to know how to
send the answer back to the client. This requires that all systems be defined by
a unique network address.
In a token-ring network, as we used for the ITSC connections, the uniqueness of
the system address is assured by a 12-digit unique number known as the
token-ring address. This address is used to identify a system in the token-ring
network. If the address has already been used, your system will not be able to
connect to the network. Most token-ring installations have a nomenclature in
place to assign a unique address to a machine. Some organizations use the
physical location (for example, a building and a room number) to ensure
Chapter 3. DRDA Connectivity 33

34 DataHub Implementation and Connectivity
uniqueness. Other organizations use the employee ID number, and some others
use the universal address engraved in the token-ring card.
The requester needs to know the server token-ring address to establish an SNA
session over the token-ring network.
IDBLK
VTAM/NCP uses the IDBLK parameter to identify the machine in a switched
network, which is the kind of network we used in the ITSC. The value differs by
type of equipment. For example, an OS/2 system is usually defined with the
value 05D. Together with the IDNUM parameter, the IDBLK parameter forms a
unique identification for VTAM. Both parameters are used in the XID (exchange
identification) negotiation.
IDNUM
VTAM/NCP uses the IDNUM parameter to identify the machine or a PU in a
network.
MAXDATA/MAXBFRU
This parameter specifies the maximum message size that one system can send
to another system. This parameter affects the performance and system
requirements of all participants in a conversation: the sender, the receiver, and
other network components.
Partner Token-Ring Address
This address identifies the physical address of the partner in a token-ring
network. See token-ring address.
Network Name
This parameter identifies the name defined for the network. The same physical
network can provide connectivity for several logical networks. The nodes of a
logical network all have the same network name.
Control Point Name
An SNA control point is an LU that is used to control all sessions between the
different partners. On VM and MVS hosts, we use the SSCP.
Before a session can be established between two applications (for example,
between OS/2 Database Manager and SQL/DS), a session must be established
between the local control point or SSCP and the remote control point or SSCP.
The first qualifier of the control point name is the network name.
Logical Unit Name
An LU is a user of the SNA network. Multiple types of LUs (LU type 0, LU type 1,
LU type 2, LU type 6.2, and others) can share the same SNA network. Each
represents a protocol that is used between different devices or programs. The
most important LU type used in a DRDA and DataHub network is the LU type 6.2
(LU 6.2).
LU 6.2 enables peer-to-peer or program-to-program communications. Thus it
enables a client/server relationship between two systems to evolve over time;
that is, a system could be a requester to a specific server for a certain request
and a server for another request.

3.2.2 DRDA Parameters
Advanced program-to-program communications, or APPC, is the programming
interface that implements LU 6.2 protocols. Because one is the protocol and the
other the interface, they are sometimes used interchangeably.
Another architecture is used as a synonym for LU 6.2: advanced peer-to-peer
networking, or APPN. This architecture is based on the LU 6.2 protocols and
permits dynamic update of network ressources.
In an LU 6.2 session, each participant is represented by a generic name:
• LU name (the requester)
• Partner LU name (the server).
The LU name consists of two qualifiers, each made up of a maximum of eight
characters. The first qualifier is the network name and the second qualifier is
the LU name itself. For example, the DataHub/2 server LU name is
USIBMSC.SJA2039I.
Partner Logical Unit Name
The partner logical unit is simply another LU in the network. It defines the
application or the system with which the LU wants to establish a session. The
partner LU also has a two-part name.
Mode Name
The mode is composed of multiple parameters used during the session
negotiation. The key connectivity parameters are RU size and pacing. The
setting of these parameters depend on the applications. To establish a session,
the mode names and parameters must match at both ends.
RU Size: RU size is the parameter that specifies how many bytes of data to
send or receive. Each send/receive request has a header of 29 bytes (TH +
RH). The RU and its header form a PIU.
The RU size parameter is very important for the performance of the DRDA
network. When a system wants to establish a link with another system, the RU
size used for the communication must be determined during session negotiation.
An inappropriate RU size does not affect the session connection, but it could
have a negative impact on session performance.
Pacing: Pacing is another value that is considered during session negotiation.
The pacing parameter determines how many PIUs will be sent in one
transmission before the recipient of the transmission acknowledges receipt.
An inappropriate pacing value does not affect initial session connection, but it
could have a negative impact on session performance.
DRDA connectivity uses the LU 6.2 protocol to establish sessions between
RDBMSs.
Chapter 3. DRDA Connectivity 35

3.2.3 RDS Parameters
RDB Name
Like any other sessions between intelligent partners, each DRDA partner has a
name that is unique in the network. This name is called the RDB name. The
definition of this name varies from platform to platform. The RDB name is used
as the first qualifier of a three-part name for each relational object (for example,
DB2CENTDIST.PROD.ORG). When an RDBMS is not exchanging data with
another RDBMS, the RDB name is not very important. But if you want to
exchange data, you need to define the RDB name and the partner RDB name.
Partner RDB Name
The partner RDB name identifies the name of the other RDBMS in a DRDA
network. This parameter includes an RDB name and an SNA partner LU name.
This SNA partner LU name is required to indicate to the system where the
partner can be found.
Transaction Program Prefix
The transaction program prefix is a 1-byte character prefixed to the transaction
program name. The default value is ′07′ in hexadecimal representation.
Transaction Program Name
The transaction program name (TPN) is the name of the transaction program
that processes the DRDA request on the target host. You should use the default
value of 6DB for all DRDA hosts except VM.
Remote Data Services is an OS/2 Database Manager private protocol that
enables OS/2 Database Manager clients and servers to access remote OS/2
Database Manager servers. Two logical connection protocols can be used to
connect the machines:
• LU 6.2
• NETBIOS.
36 DataHub Implementation and Connectivity
If you use the LU 6.2 protocol, both client and server workstations will need to be
defined in the SNA network as discussed in 3.2.1, “SNA Parameters” on
page 33. Although you do have a choice of protocols to connect OS/2 Database
Manager clients and servers to OS/2 Database Manager servers, the DataHub
implementation requires the use of the LU 6.2 protocol between the DataHub/2
workstation(s) and the managed OS/2 hosts.
If you use the NETBIOS protocol, each OS/2 Database Manager client and server
workstation must be assigned a name by the installer. Because this name must
be unique in the NETBIOS network, OS/2 Database Manager adds a prefix ($SQL
for a server and #SQL for a requester) and a suffix (00) to the workstation name.
Workstation Name
When an OS/2 Database Manager client or server wants to start a NETBIOS
session with an OS/2 Database Manager server, the requester must provide the
name of the server. This name is broadcast on the NETBIOS network.
Eventually, the server, which is always listening, acknowledges the request and
tells the requester which token-ring address to use. If the server is not up for
any reason, the local NETBIOS driver code sends a NETBIOS error code of 14
(unknown name) to the requester.

3.2.4 Cross-Reference
Table 3 and Table 4, respectively, show the host terminology for the key SNA
and DRDA connectivity parameters. When possible, the real parameter names
are used. Because in OS/2 there are no commands to define resources, we
indicate the name of the parameter used in the OS/2 windows. You should use
the terminology in Table 3 and Table 4 when you contact the person responsible
for a given platform.
Table 3. SNA Key Connectivity Parameters Cross Reference
Parameter MVS Host VM Host AS/400 Host OS/2 Host
Token-ring address LOCADD (NCP) LOCADD (NCP) ADPTADR Network adapter
address
IDBLK IDBLK IDBLK EXCHID Node ID (hex)
IDNUM IDNUM IDNUM EXCHID Node ID (hex)
MAXDATA MAXDATA MAXDATA MAXDATA Transmit buffer
size
Partner token-ring
address
DIALNO DIALNO ADPTADR LAN destination
address (hex)
Network name NETID NETID LCLNETID Network ID
Control point name SSCPNAME SSCPNAME LCLCPNAME Local node name
Logical unit name APPL APPL LCLLOCNAME Local node name
Partner logical unit
name
APPL APPL RMTLOCNAME Partner logical
unit
Mode name MODEENT MODEENT MODE Transmission
service mode
RU size RUSIZES RUSIZES MAXLENRU Maximum RU size
Pacing PACING PACING INPACING Receive pacing
window
Table 4. DRDA Key Connectivity Parameters Cross Reference
Parameter MVS Host VM Host AS/400 Host OS/2 Host
RDB name LOCATION NAME DBNAME RDB See note
Partner RDB name LOCATION NAME DBNAME RDB See note
Transaction program
prefix
Transaction program
name
See note
LINKATTR RESID TNSPGM See note
Note: Because OS/2 Database Manager cannot act as a DRDA server, the DRDA parameters are not
applicable. For the DataHub environment, however, a name must be associated with each OS/2 Database
Manager database to be managed from a DataHub workstation.
Chapter 3. DRDA Connectivity 37

3.3 The ITSC Network
38 DataHub Implementation and Connectivity
The ITSC DRDA network uses token-ring technology to interconnect different
systems (see Figure 14). It is important to note that both the MVS and VM hosts
reside on the same physical machines, although in the logical view of our
network they seem far away from each other (New York and Toronto). From a
connectivity point of view, lack of proximity does not make any difference
because both hosts are accessible through one token-ring connection on the
3745 VTAM NCP. From the DataHub/2 workstation, the requests can be routed to
the Toronto system by another path.
Figure 14. ITSC Network Configuration
Table 5 on page 39 and Table 6 on page 39 show the values for the key SNA
and DRDA connectivity parameters for each non-OS/2 host on the ITSC network.
We need to know these values to interconnect all the different hosts.

Table 5. The ITSC Network: SNA Key Connectivity Parameter Values, non-OS/2 Hosts
Parameter New York
MVS Host (DB2)
Headquarters
Toronto
VM Host (SQL/DS)
Large Car Dealer
San Jose
AS/400 Host
Large Car Dealer
Token-ring address 400008210200 400008210200 400052047158
IDBLK Not applicable Not applicable 056
IDNUM Not applicable Not applicable A2054
Network name USIBMSC USIBMSC USIBMSC
Control point name SCG20 SC19M SJAS400A
Logical unit name LUDB23 LUSQLVMA SJA2054I
Table 6. The ITSC Network: DRDA Key Connectivity Parameter Values, non-OS/2 Hosts
Parameter New York
MVS Host (DB2)
Headquarters
Toronto
VM Host (SQL/DS)
Large Car Dealer
RDB name DB2CENTDIST SQLLDLR01 SJ400DLR1
Transaction program
prefix
Transaction program
name
X′07′ X′07′ X′07′
6DB SQLVMA 6DB
San Jose
AS/400 Host
Large Car Dealer
Table 7 and Table 8 show the values for the key SNA and RDS connectivity
parameters for the OS/2 systems.
Table 7. The ITSC Network: SNA Key Connectivity Parameter Values, OS/2 Hosts
Parameter DataHub/2
Workstation
OS/2 Host
(DB2/2)
Montreal
OS/2 Host
(OS/2 DBM)
Car Dealer
Paris
OS/2 Host
(OS/2 DBM)
Car Dealer
Rio de Janeiro
OS/2 Host
(DB2/2)
Car Dealer
Token-ring address 400052047135 400052047122 400052047157 400052047116
IDBLK 05D 05D 05D 05D
IDNUM A2039 A2018 A2050 A2019
Network name USIBMSC USIBMSC USIBMSC USIBMSC
Control point name SJA2039I SJA2018I SJA2050I SJA2019I
Logical unit name SJA2039I SJA2018I SJA2050I SJA2019I
Table 8. The ITSC Network: RDS Key Connectivity Parameter Values, OS/2 Hosts
Parameter DataHub/2
Works.
OS/2 Host
(DB2/2)
Montreal
OS/2 Host
(OS/2 DBM)
Car Dealer
Paris
OS/2 Host
(OS/2 DBM)
Car Dealer
Rio de Janeiro
OS/2 Host
(DB2/2)
Car Dealer
Workstation name DHSERVER MTLDBM1 PARDBM1 RIODBM1
Now that we know all the SNA, DRDA, and RDS key connectivity parameters,
let′s start customizing the network.
Chapter 3. DRDA Connectivity 39

3.4 MVS Definitions
3.4.1 SNA Definitions
40 DataHub Implementation and Connectivity
Note: In our network, we customize our environment to connect any-to-any,
which may not be realistic. In reality, you would probably interconnect one
central repository to all the other platforms. Therefore, one platform would need
to know only one partner and not five as in our implementation.
In this section we show how the key connectivity parameters have been defined
in the MVS environment for DRDA connectivity. We also explain the relationship
between the different components.
This section covers the key SNA definitions you will have to implement in
MVS/VTAM and NCP. It is not within the scope of this book to explain how to
implement a VTAM network. You should work in collaboration with your network
specialist to understand the existing VTAM environment in your enterprise. You
need to discuss with your network specialist the modifications and extensions
DataHub will require in the VTAM environment. The examples we provide in this
section are extracts of the ITSC network definitions. The ITSC network we refer
to in this section is a unique network named USIBMSC. We did not implement
interconnected networks. If you have to implement interconnected networks, the
definitions will be slightly more complex and will require more planning. Refer to
the VTAM Network Implementation Guide and VTAM Resource Definition
Reference for more information on network implementations.
Cross-Domain Definitions
A multiple-domain network (like USIBMSC) contains more than one SSCP.
Control of the resources in the network is divided among the SSCPs. Defining
the VTAM network involves identifying the domains and defining the resources in
those domains to the SSCPs.
A cross-domain resource manager (CDRM) is that part of an SSCP that supports
cross-domain session setup and takedown. Before LUs in one domain can have
cross-domain sessions with LUs in another domain, an SSCP-SSCP session must
be established between the SSCPs of the two domains. Therefore, VTAM must
know about all CDRMs with which it will communicate. You must define to VTAM
its own CDRM (host CDRM) and all other CDRMs (external CDRMs) in the
network. Thus to have a session between two SSCPs, you must have two
CDRMs defined to each VTAM: one for the host and one for the external CDRM.
Figure 15 on page 41 is an example of the CDRM definitions we implemented in
our network.

******************************************************************
* CROSS DOMAIN RESOURCE MANAGER FOR WTSCMXA *
******************************************************************
VBUILD TYPE=CDRM
USIBMSC NETWORK NETID=USIBMSC
*
SC02M CDRM SUBAREA=02, MVS FLOOR SYSTEM (WTSCMXA)
CDRDYN=YES,CDRSC=OPT,ISTATUS=ACTIVE
SC19M CDRM SUBAREA=19, WTSCVMXA
CDRDYN=YES,CDRSC=OPT,ISTATUS=ACTIVE
SCG20 CDRM SUBAREA=20, WTSCPOK
CDRDYN=YES,CDRSC=OPT,ISTATUS=ACTIVE
SC25M CDRM SUBAREA=25, WTSC3090
CDRDYN=YES,CDRSC=OPT,ISTATUS=ACTIVE
SC26M CDRM SUBAREA=26, SJMVSESA
CDRDYN=YES,CDRSC=OPT,ISTATUS=ACTIVE
Figure 15. Cross-Domain Resource Manager Definitions in MVS/VTAM
Resources controlled by VTAM in another domain are called cross-domain
resources (CDRSCs). You do not have to define CDRSCs. VTAM can dynamically
create the definition statements to represent resources that reside in other
domains. Figure 16 is an extract of the CDRSC definitions we made in our
network. Note that all external resources have not been defined; they will be
created dynamically by VTAM.
******************************************************************
* CROSS DOMAIN RESOURCES *
******************************************************************
VBUILD TYPE=CDRSC
NETWORK NETID=USIBMSC
******************************************************************
* CROSS DOMAIN RESOURCES ON WTSCVMXA *
******************************************************************
*
LUSQLDB2 CDRSC CDRM=SC19M, SQL ON WTSCVMXA
ISTATUS=ACTIVE
Figure 16. Cross Domain Resource Definitions in MVS/VTAM
Token-Ring Address
Each participant in a token-ring network must have an address. The address is
used to identify the element in the network. For example, to get into an SNA
network you always leave the token-ring network through a gate, which is the
NCP. Because the NCP is part of the token-ring, it must have an address
associated with it.
We are using the ITSC network as an example to elucidate addressing. In our
environment we could have left the token-ring through an NCP in the IBM 3745
Communication Controller to reach the SNA network and consequently access
mainframe applications.
The support for the token-ring network in an NCP is given by the NCP
Token-Ring Interface (NTRI), which is a standard function of the NCP.
Chapter 3. DRDA Connectivity 41

42 DataHub Implementation and Connectivity
The 3745 attaches to the token-ring network through the Token-Ring Network
Attachment Subsystem (TRSS). The TRSS consists of Token-Ring Adapters
(TRAs). A TRA consists of a Token-Ring Multiplexor (TRM) and Token-Ring
Interface Couplers (TICs).
Figure 17 shows the definition that was made in the NCP for TIC # 1. The TIC
address assigned is 400008210200. There are two ways of assigning a token-ring
address: universally or locally administered. A universally administered address
(UAA) is engraved on the machine by the manufacturer. The locally
administered address (LAA) is assigned by a network administrator and should
be unique. Usually the LAA is the more meaningful way of assigning an address
because it can be coded to represent a building, floor, room, and workstation,
and you could identify the resource by looking at the code. In our case our local
administrator told us to use address 400008210200 to identify the NCP.
***********************************************************************
* PHYSICAL GROUP FOR NTRI TIC #1 (PORT ADDRESS 1088) *
***********************************************************************
GT21P01 GROUP ECLTYPE=(PHY,PERIPHERAL), PHYSICAL GROUP *
NPACOLL=NO, *
LNCTL=SDLC
LT21TIC1 LINE ADDRESS=(1088,FULL), TIC ADDRESS *
LOCADD=400008210200, ADDRESS OF 1ST TIC *
MAXTSL=2044, TRANSMIT FRAME SIZE *
ADAPTER=TIC2, ADAPTER TYPE 2 16/4 *
TRSPEED=16, SPEED *
PORTADD=1, PHYSICAL PORT ADDRESS OF 1ST TIC *
RCVBUFC=4095 MAX RECEIVE BUFFER SIZE
*
PT21TIC1 PU ISTATUS=ACTIVE
*
SC21TIC1 LU ISTATUS=INACTIVE
***********************************************************************
Figure 17. LAN Address for the Network Control Program
Once the NCP (3745 Communication Controller) has the LOCADD 400008210200
assigned to it, every time an RU or message addressed to the NCP passes
through it in the token-ring, NCP takes it off the token-ring and moves it into
memory. The NCP does not reroute the message or RU to an adjacent element
in the token-ring; it looks at the TH to find out the destination address of the
message or RU and reroutes it to the requested address. The destination
address could be, for example, an SNA address outside the ring.
MAXDATA and MAXBFRU
The MAXDATA parameter included at NCP generation specifies the maximum
PIU size that VTAM can deliver to the NCP (see Figure 18 on page 43). It
indirectly limits the message size or RU that can be transmitted across the
network.
In our case the MAXDATA specified is 5000, which means that VTAM could
deliver data or a message of up to 4971 bytes (5000 - (26(TH) + 3(RH)) to the
NCP.

***********************************************************************
* PCCU SPECIFICATIONS - ACF/VTAM OS/MVS(VM) 3745 *
***********************************************************************
SC1SCGP PCCU AUTODMP=NO, AUTOMATICALLY TAKE DUMP X
AUTOIPL=NO, LOAD NCP AFTER FAILURE OR DUMP X
AUTOSYN=YES, USE THE ALREADY LOADED NCP IF OK X
BACKUP=YES, RESOURCE TAKEOVER PERMITTED X
CUADDR=922, CHANNEL-ATTACHMENT ADDRESS X
DUMPDS=NCPDUMP, DUMP DATA SET X
DUMPSTA=922-S, DUMP STATION X
LOADSTA=922-S, LOAD STATION X
MAXDATA=5000, MAXIMUM PIU SIZE X
NETID=USIBMSC, NETWORK IDENTIFIER X
SUBAREA=20, HOST SUBAREA ADDRESS X
VFYLM=YES VERIFY NCP LOAD MODULE NAME
Figure 18. MAXDATA Definition for the Network Control Program
The NCP has the capability to deliver data to VTAM. The data size that VTAM
might receive is specified indirectly through the definition of its buffer
characteristics. The MAXBFRU parameter indicates the number of buffers that
VTAM reserves to receive data. The UNITSZ specifies the VTAM buffer size. In
Figure 19, MAXBFRU=32 and UNITSZ=384, which means that a message of up
to 12286 bytes could be delivered to this VTAM.
***********************************************************************
* HOST DEFINITIONS (3745-V5R3) *
***********************************************************************
SC1SCGH HOST INBFRS=10, NCP BUFFERS FOR EACH DATA TRANSFER *
MAXBFRU=32, # VTAM BUFS FOR RCV DATA *
UNITSZ=384, VTAM IO BUFFER SIZE (IOBUF) *
BFRPAD=0, VTAM REQUIRED *
NETID=USIBMSC, NETWORK WHERE THIS HOST IS *
SUBAREA=20 SSCP SUBAREA NUMBER (HOST)
Figure 19. MAXBFRU and UNITSZ Definition for the Network Control Program
Note that the VTAM and NCP definitions are used together. Some VTAM
definitions are built at NCP generation and some NCP definitions are built at
VTAM generation. This mechanism allows activation of definitions without
regenerating NCP or VTAM.
The NCP is loaded in the Communication Controller. VTAM is started up through
a startup procedure that specifies which libraries (VTAMLIB, VTAMLST,
VTAMOBJ, NCPLOAD, and NCPDUMP) VTAM will use. VTAM startup parameters
are specified in a library member called ATCSTRXX, where xx is the suffix as
specified in the LIST parameter on the START command (see Figure 20).
S NET,,,(LIST=00).
Figure 20. VTAM Startup Command
The startup command in Figure 20 would activate the parameters in the
ATCSTR00 member (see Figure 21 on page 44).
Chapter 3. DRDA Connectivity 43

44 DataHub Implementation and Connectivity
*********************************************************************
* VTAM START LIST - ATCSTR00 - *
*********************************************************************
NOPROMPT, *
SSCPID=5411, *
SUPP=NOSUP, *
HOSTSA=20, *
NETID=USIBMSC, *
SSCPNAME=SCG20, *
HOSTPU=SCG20PU, *
CONFIG=00, *
MAXSUBA=255, *
NOTRACE,TYPE=VTAM, *
IOBUF=(650,384,12,,32,32), *
BSBUF=(975,,,,,27), *
APBUF=(16,,2,,1,3), *
LPBUF=(100,,0,,60,60), *
LFBUF=(100,,0,,24,10), *
WPBUF=(350,,0,,25,10), *
SFBUF=(60,,0,,32,10), *
SPBUF=(60,,0,,32,10), *
CRPLBUF=(160,,13,,80,80), *
IOINT=180
Figure 21. SSCPNAME=SCG20 VTAM Startup Parameter List: ATCSTR00
Partner Token-ring Address
In the previous discussion we addressed the case where an element in the
token-ring network wanted to send a message or RU out of the network to reach
a mainframe application. Now, let′s look at the opposite case, that is, when one
SNA application wants to establish a session with an element in the token-ring
network.
If one application wants to access a partner on the token-ring network, for
example, an AS/400, VTAM needs to know this partner by its name
. and by the token-ring address. VTAM can be
informed of the partner token-ring address by means of the DIALNO parameter
in the PATH macro.
Figure 39 on page 63 shows the definition we used in our environment to inform
VTAM of the required LU name and the partner token-ring address.
DIALNO=400052047158 and the LU name SJA2054I were specified. Now let′s
see what was defined on the AS/400 side. First, as can be seen in Figure 38 on
page 61, the DIALNO value specified in the PATH macro must match the
ADPTADR value specified in the AS/400 line description. (Refer to Figure 41 on
page 64 for the AS/400 token-ring line definition. Also, refer to Figure 42 on
page 65 to see how we informed AS/400 of the NCP address in case the AS/400
application wanted to leave the token-ring through the NCP gate.)

Network Name
When defining an element in a network, it is important to specify to which
network the element belongs. You might have different networks communicating,
and a network ID is required to identify the correct network. The network name
is specified as the NETID parameter to VTAM (see Figure 21 on page 44). The
parameter tells VTAM to which network it belongs. The NETID parameter is also
used in the NCP definitions. It tells the NCP to which network it belongs. In our
case, the network name is USIBMSC (see Figure 18 on page 43 and Figure 19
on page 43).
Control Point Name
This is the SSCP name, which is actually the ACF/VTAM name. In our network
the control point name has been defined through the SSCPNAME parameter.
Refer to Figure 21 on page 44 where you can see the SSCPNAME specified as
SCG20. You can see that this SSCP (VTAM) belongs to subarea 20. This is key
information that identifies SSCP SCG20. The subarea parameter is used to tie
this SSCP to other definitions. For example, the PCCU definitions in Figure 18 on
page 43 are tied to SSCP SCG20 because they refer to subarea 20.
Logical Unit Name
As stated previously the LU name can be an application program. In the MVS
environment, DB2 implements the DRDA architecture as part of the Distributed
Data Facility (DDF). DDF uses VTAM to perform distributed database
communications on behalf of DB2. So, to enable DB2 access throughout the
network we need to assign to it an LU name as well as a network ID. Refer to
Figure 22 on page 46 for the LUDB23 DB2 definition. Note that when the
ACBNAME parameter is not coded, the network-unique name (the name of the
APPL statement) is used as the ACBNAME. The ACBNAME parameter is needed
when application programs with the same APPLID are activated in multiple hosts
and are to enter in a cross-domain session. The ACBNAME parameter is also
required when terminal users in the network specify with which application
program in which host they want to establish a session.
The parameter DLOGMOD=IBMRDB specifies the log mode entry to select for
use from the log mode table AGWTAB. The parameter SECACPT=ALREADYV
specifies that the level of conversation security is set to “already verified,” which
is the recommended value.
Chapter 3. DRDA Connectivity 45

VBUILD TYPE=APPL
*---------------------------------------------------------------------*
* POUGHKEEPSIE DB2 SUBSYSTEM VTAM DEFINITION *
*---------------------------------------------------------------------*
*
LUDB23 APPL ACBNAME=LUDB23, APPCMD CAPABILITY ENABLED X
APPC=YES, X
AUTH=(ACQ), ACCESS TO VTAM FUNCTIONS X
AUTOSES=10, X
DLOGMOD=IBMRDB, X
DMINWNL=25, X
DMINWNR=25, X
DSESLIM=50, MAX NUMBER OF SESSIONS IN USE X
EAS=509, X
ENCR=NONE, X
MODETAB=AGWTAB, X
PARSESS=YES, X
SECACPT=ALREADYV, X
SONSCIP=NO, X
SRBEXIT=YES, SRB PROCESSING IN EXIT ROUTINES X
VERIFY=NONE, X
VPACING=2, X
VTAMFRR=NO
Figure 22. LU Definition for DB2 in the MVS VTAM Environment
Partner Logical Unit Name
The partner LU is simply another LU in the network. It is defined in the same
way the LU name is defined. In our network we defined several LUs that were
used as partner LUs when establishing LU-to-LU sessions. Refer to Figure 30 on
page 52 for the AVS LU definition for the SQL/DS environment. The AS/400 LU
name definition is shown in Figure 39 on page 63.
Mode Name
The session characteristics are defined through logon mode or LOGMODE. One
of the LOGMODEs we used is IBMRDB (see Figure 23).
TITLE ′ DB2IBM′
IBMRDB MODEENT LOGMODE=IBMRDB, *
COS=BACKHI, *
PSNDPAC=X′08′, PRIMARY SEND PACING COUNT *
SSNDPAC=X′08′, SECONDARY SEND PACING COUNT *
SRCVPAC=X′08′, SECONDARY RECEIVE PACING COUNT *
RUSIZES=X′8989′, RU SIZE 4096 IN 4096 OUT *
FMPROF=X′13′, *
TSPROF=X′07′, *
PRIPROT=X′ B0′, *
SECPROT=X′ B0′, *
COMPROT=X′ D0B1′, *
ENCR=B′0000′, *
PSERVIC=X′060200000000000000000300′
Figure 23. IBMRDB LOGMODE
46 DataHub Implementation and Connectivity

3.4.2 DRDA Definitions
RU Size: The RU size defines the maximum amount of data that can be sent to
the session partner in each send operation. As stated before, the RU size is one
of the elements that determines the PIU size. You can see in Figure 23 that in
our environment the RU size was specified as X′8989′ (that is, 8 x 2**9 = 8 x 512
= 4K in each direction on the session), which is the recommended value in a
DRDA environment.
Pacing: Pacing is an important concept when considering the performance of
the network. The concept of pacing is that one LU sends a specified number of
RUs and then waits for a “pacing response” from the receiving LU before it
sends any more data (RUs).
Session pacing can be established by means of the LOGMODE definitions used
in the bind when the session is set up or specified on the APPL definition in
VTAM. Session pacing applies in each direction on the session independently,
that is, each LU has a send count and a receive count. Refer to Figure 22 on
page 46 for details of the session pacing definition used in the LUDB23 APPL
definition in VTAM. VPACING=2, as specified in our environment, is the
recommended value. Remember that a session is started by one LU 6.2
application sending a BIND command. The sender of the BIND is called the
primary LU for that session; the receiver of the BIND is called the secondary LU.
The BIND sent by the primary LU contains certain session parameters (for
example, RU sizes, protocols, pacing), and the secondary LU can suggest
another set of session parameters. In the LU 6.2 architecture, this is called a
negotiable BIND. The primary LU can either accept the session parameter
suggested by the secondary LU or terminate the session.
In this section we show how the DRDA key connectivity parameters have been
defined.
RDB Name
The globally unique name for a relational database is RDB name. The
terminology used in DB2 for RDB name is LOCATION NAME. In a DB2
environment the location name and password of your local DB2 subsystem are
defined in the bootstrap data set (BSDS) by using either the installation panels
or the Change Log Inventory Utility. The LOCATION NAME and the password
that is used to identify the local DB2 and its associated LU name are kept in the
BSDS. Refer to Figure 24 on page 48 for a schematic view of the parameters
involved when connecting DB2 to VTAM.
Chapter 3. DRDA Connectivity 47

48 DataHub Implementation and Connectivity
Figure 24. DB2 to VTAM Connection
The LOCATION NAME is equivalent to the RDB_NAME in non-DB2 SAA database
managers and is used to identify DB2 to the system. The LOCATION NAME is
referred to by other subsystems that need to access this particular DB2. This
mechanism allows a database manager to connect to a DB2 subsystem without
referring to its NETID.LUNAME. The LOCATION NAME must be unique in the
network and can be up to 16 bytes long.
The LUNAME is the name by which VTAM can recognize the local DB2
subsystem as a VTAM application. It is used to define DDF in the VTAM APPL
statement. You can also define the DB2 password in the APPL PRTCT
statement. This password is optional. Refer to Figure 24. When DDF is started,
it retrieves the password from the BSDS and forwards it to VTAM for
confirmation. This process validates the connection and prevents unauthorized
LU names from getting into the network.
The LUNAME must be unique within the network and can be up to 8 bytes long.
The LUNAME is also kept in the BSDS.
We defined the LUNAME for DB2 location DB2CENTDIST as LUDB23 (see
Figure 22 on page 46).
DRDA Partners
Once the local DB2 names have been defined you need to define the DRDA
remote server as well as the remote requester subsystems by populating the
communications database (CDB) tables. The CDB tables describe the
connections between the local DB2 and the other subsystems. The following five
tables are part of the CDB:
SYSIBM.SYSLOCATIONS This table maps the LOCATION name to the
LUNAME and TPN. It must contain at least one
row for each remote server. Requesters are not
required to be defined.

SYSIBM.SYSLUNAMES This table defines the security and mode
requirements for conversations. This table has a
row for each LUNAME associated with the remote
system you want to access.
SYSIBM.SYSUSERNAMES This table is used for inbound and outbound
translations.
SYSIBM.SYSMODESELECT This table maps applications to specific VTAM
logon modes.
SYSIBM.SYSLUMODES This table defines the LU 6.2 session limits.
To define DB2 as a requester, that is, to have DB2 access remote servers, you
must include at least two rows for each remote database: one row in the
SYSIBM.SYSLUNAMES table and one row in the SYSIBM.SYSLOCATIONS table.
Others rows can be added to exploit the whole CDB capability.
To define DB2 as a server, that is, to allow other subsystems to access DB2, you
can use the defaults. If you want to:
• Use inbound translation
• Associate a specific logon mode witha specific application
• Specify any other special property for a requesting LUNAME,
you should populate the CDB according to your requirements.
For our network we defined in the CDB at location name DB2CENTDIST the
remote servers and requesters as shown in Figure 25 through Figure 29 on
page 50.
---------+---------+---------+---------+---------+---------+
LOCATION LOCTYPE LINKNAME LINKATTR
---------+---------+---------+---------+---------+---------+
DB2CENTDIST LUDB23
DB2REGNDIST01 LUDB2B
SQLLDLR01 LUSQLDB2 SQLVMA
SJ400DLR1 SJA2054I
---------+---------+---------+---------+---------+---------+
Figure 25. SYSIBM.SYSLOCATIONS CDB Table. Two DB2 location names,
DB2CENTDIST and DB2REGNDIST01, are defined. The respective LUNAMEs are LUDB23
and LUDB2B. The SQL/DS location SQLLDLR01 has LUSQLDB2 as the LUNAME and
SQLVMA as the TPN. The AS/400 location SJ400DLR1 has as its LUNAME SJA2054I.
Chapter 3. DRDA Connectivity 49

50 DataHub Implementation and Connectivity
---------+---------+---------+---------+---------+---------+---------+--
LUNAME SYSMODENAME USERSECURITY ENCRYPTPSWDS MODESELECT USERNAMES
---------+---------+---------+---------+---------+---------+---------+--
LUDB23 A N Y I
LUDB2B A N Y I
LUSQLDB2 A N Y I
SJA2054I A N N I
C N N
---------+---------+---------+---------+---------+---------+---------+--
Figure 26. SYSIBM.SYSLUNAMES CDB Table. This table defines the LUNAMEs and
indicates that inbound translation for LUNAMEs LUDB23, LUDB2B, LUSQLDB2, and
SJA2054I is required. All other LUNAMEs will be RACF checked.
---------+---------+---------+---------+---------
TYPE AUTHID LUNAME NEWAUTHID PASSWORD
---------+---------+---------+---------+---------
I CHAPUT LUDB2B CHAPUT
I STDB2A LUDB2B STDB2A
I STDB2B LUDB2B STDB2B
I STDB2C LUDB2B STDB2C
I STDB2D LUDB2B STDB2D
I STDB2E LUDB2B STDB2E
I CHAPUT LUSQLDB2 CHAPUT
I STSQLA LUSQLDB2 STDB2A
I STSQLB LUSQLDB2 STDB2B
I STSQLC LUSQLDB2 STDB2C
I STSQLD LUSQLDB2 STDB2D
I STSQLE LUSQLDB2 STDB2E
I DHJOSE SJA2054I STDB2E
---------+---------+---------+---------+---------
Figure 27. SYSIBM.SYSUSERNAMES CDB Table. These are the userid translations we
specified.
---------+---------+---------+---------+
AUTHID PLANNAME LUNAME MODENAME
---------+---------+---------+---------+
LUDB23 IBMRDB
LUDB2B IBMRDB
LUSQLDB2 IBMRDB
---------+---------+---------+---------+
Figure 28. SYSIBM.SYSMODESELECT CDB Table. These are the modes we specified.
---------+---------+---------+---------+
LUNAME MODENAME CONVLIMIT AUTO
---------+---------+---------+---------+
---------+---------+---------+---------+
Figure 29. SYSIBM.SYSLUMODES CDB Table. No definitions are included in this table.
We used defaults and did not want to change MODENAME, CONVLIMIT, and AUTO for any
specific LUNAME.

3.4.3 Testing DRDA Connections
3.5 VM Definitions
3.5.1 SNA Definitions
Application programs can be executed after they are bound to a target database.
Before you install DataHub definitions we recommend that you verify all DRDA
connections. Once you have verified the DRDA connections you can, for
example, bind SPUFI, which is an interactive tool provided in the DB2
environment, at a remote location. Because SPUFI can be bound to SQL/DS and
AS/400 databases, you can query SQL/DS and AS/400 data from DB2.
DB2 SPUFI to SQL/DS
To make SPUFI available to the SQL/DS platform, you must bind the package
DSNESM68 for the user IDs DSNESPCS and DSNESPRR at the SQL/DS site. You
can do this from DB2 by using the BIND PACKAGE option in DB2I. Before doing
the bind, you should check whether both plans include the remote SQL/DS
location name. If they do not include it, you should rebind the plans to include
the location name. Then you can use SPUFI to GRANT execute authority to
public to these plans at the remote location.
DB2 SPUFI to AS/400
To make SPUFI available to the AS/400 platform, you must bind the package
DSNESM68 in collections DSNESPCS and DSNESPRR at the AS/400 site. You
can do this from DB2 using the BIND PACKAGE option in DB2I. Before doing the
bind, you should check whether both plans include the remote AS/400 location
name. If they do not include it, you should rebind the plans to include the
location name. Then you can use SPUFI to GRANT execute authority to public to
these plans at the remote location.
In this section we show how the key connectivity parameters have been defined
in the VM environment. We also explain the relationship between the different
components.
Because we are using in the ITSC network the same Communication Controller
in VM and MVS, the SNA definitions used in the VM environment are the same
as in the MVS environment. Refer to 3.4.1, “SNA Definitions” on page 40.
Logical Unit Name
In MVS we define DB2 as a VTAM application in the VTAM APPL statement. In
VM we define the AVS application, which is related to SQL/DS (see Figure 30 on
page 52).
Chapter 3. DRDA Connectivity 51

3.5.2 DRDA Definitions
52 DataHub Implementation and Connectivity
**********************************************************************
* AVS VTAM DEFINITION FOR CONNECTING SQL/DS *
**********************************************************************
AVSVM VBUILD TYPE=APPL
*
LUSQLVMA APPL APPC=YES, X
AUTHEXIT=YES, X
AUTOSES=10, X
DLOGMOD=IBMRDB, X
DSESLIM=100, X
DMINWNL=50, X
DMINWNR=50, X
MODETAB=AGWTAB, X
PARSESS=YES, X
SECACPT=ALREADYV, X
SYNCLVL=CONFIRM, X
VERIFY=NONE, X
VPACING=2
**********************************************************************
Figure 30. AVS LU Definition for SQL/DS Environment
The parameter DLOGMOD=IBMRDB specifies the log mode entry for use from
the log mode table AGWTAB. The parameter SECACPT=ALREADYV specifies
the level of conversation security, which is set up as “already verified,” the
recommended value.
In this section we describe the key DRDA connectivity parameters in the SQL/DS
environment.
DRDA Components in SQL/DS: An Overview
Figure 31 on page 53 shows the main DRDA components in the SQL/DS
environment.

Figure 31. Main DRDA Components in an SQL/DS Environment
APPC/VM Advanced Program-to-Program Communication/VM. An
API for communication between two virtual machines that
is mappable to the SNA LU 6.2 APPC interface.
APPC/VTAM Advanced Program-to-Program Communication/VTAM. An
API providing an LU 6.2 function set as defined by SNA for
communication between application programs.
AVS APPC/VM VTAM Support. A component of VM that enables
application programs using APPC/VM to communicate with
programs anywhere in an SNA network. AVS transforms
APPC/VM into APPC/VTAM in outbound flow, and
APPC/VTAM into APPC/VM in inbound flow.
AVS Console Used to activate and deactivate gateways, monitor
DataHub Support/VM gateways and conversations, and
control GCS tracing.
CP Control Program. A component of VM that manages the
resources of a single computer so that multiple computing
systems (virtual machines) appear to exist.
GCS Group Control System. A component of VM that provides
simulated MVS services and unique supervisor services to
help support a native SNA network. VTAM and AVS run
under GCS only under the control of CP.
SQL/DS Application Requester (AR)
A CMS machine that can connect to a DRDA application
server to access a database.
Chapter 3. DRDA Connectivity 53

SQL/DS Database Machine (AS)
A CMS machine controlling access to an SQL/DS database
in which the DRDA application server code runs.
Application Server Identification
An SQL/DS application server can be identified in several ways:
Database Name This is the RDB name in DRDA terminology. It is specified,
for example, on the CONNECT TO
statement. The database name can be up to 18 characters
long. Prior to SQL/DS V3.3, the database name could be
only up to eight characters long.
Resource-id This is the transaction program name in DRDA
terminology. It is the name that VM uses to identify a
database. This name can be up to eight characters long
and is used as:
• The CMS filename for database control files with a file
type of SQLDBN, SQLFDEF, or SQLDBGEN. These
database control files reside in the production CMS
minidisk (Q-disk).
• An externally identified name when TSAF and/or AVS
are used to define the database as a GLOBAL
RESOURCE.
The resource-id is defaulted to be the same as the
database name unless the database administrator
explicitly requests two different names, or the database
name is longer than eight characters. If the two names
are different, the database name and the resource-id must
be mapped together by means of the CMS RESID NAMES
file.
In Figure 32 the SQL/DS database name (DRDA RDB
name) SQLLDLR01 is associated with the SQL/DS
resource-id SQLVMA.
RESID NAMES Q1 V 255 Trunc=255 Size=2 Line=0 Col=1 Alt=0
====>
:nick. :resid.SQLVMA
:dbname.SQLLDLR01
Figure 32. CMS RESID NAMES File
This association enables VM to translate a request that
refers to the DRDA RDB name into a shorter resource-id
that is used internally by SQL/DS for other purposes, for
example, as the name of the SQLDBN CMS file (see
Figure 33).
SQLVMA SQLDBN Q1 V 80 Trunc=80 Size=1 Line=0 Col=1 Alt=0
====>
DBMACHID=SQLMACH,DCSSID=SQLDBA,DBNAME=SQLLDLR01,AMODE=31
Figure 33. SQLVMA SQLDBN File
54 DataHub Implementation and Connectivity

Machine-id This is the CMS-id of the machine that is to be used as the
server machine. As you can see in Figure 33 the
resource-id is SQLVMA, the machine-id is SQLMACH, and
the database name is SQLLDLR01.
Communication between AVS and SQL/DS Machines: An Overview
Database Machine Definition
Figure 34 highlights the main parameters: SQLMACH is
the name of the SQL/DS database machine, in the
statement IUCV *IDENT RESANY GLOBAL; RESANY means
this machine can access any database resource; GLOBAL
means this database can be accessed from remote LUs.
The statement IUCV ALLOW means that every CMS user
can access this machine.
USER SQLMACH NOTUSED 8M 17M G
ACCOUNT ITS2000
OPTION MAXCONN 26
IUCV *IDENT RESANY GLOBAL
IUCV ALLOW
* VM/ESA Data spaces directory, next three statements.
MACHINE XC
XCONFIG ACCESSLIST ALSIZE 1022
XCONFIG ADDRSPACE MAXNUMBER 1022 TOTSIZE 2044G
OPTION MAINTCCW
IPL CMS
CONSOLE 009 3215 T OPERATOR
SPOOL 00C 3505 *
SPOOL 00D 3505 A
SPOOL 00E 1403
LINK MAINT 190 190 RR
LINK MAINT 19D 19D RR
LINK MAINT 19E 19E RR
LINK MAINT 19F 19F RR
* base machine disk
MDISK 0191 3390 2446 11 VMXP1P MR DBA2PW DBA3PW
* Service Minidisk
MDISK 0193 3390 2672 55 VMXP1P MR DBA2PW DBA2PW
* Production Minidisk
MDISK 0195 3390 2457 22 VMXP1P MR ALL DBA2PW DBA2PW
* Directory Disk
MDISK 0200 3390 1970 33 VMXP1P MR DBA2PW DBA2PW
* Log disk1
MDISK 0201 3390 2003 9 VMXP1P MR DBA2PW DBA2PW
* Data disk1
MDISK 0202 3390 2012 65 VMXP1P MR DBA2PW DBA2PW
* QMF.-------------------------------------------------
* Production disk
MDISK 0396 3390 2479 33 VMXP1P RR
* Distribution disk
MDISK 0397 3390 2512 19 VMXP1P RR
* DATA Hub.--------------------------------------------
MDISK 0197 3390 2578 15 VMXP1P RR
MDISK 0198 3390 2643 20 VMXP1P RR
Figure 34. Database Machine Definition
Chapter 3. DRDA Connectivity 55

AVS Machine Definition
In Figure 35 on page 56, the GATEWAY parameter of the
statement IUCV *IDENT GATEANY ... means that the AVS
can use any gateway defined in the AGWPROF GCS file as
shown in Figure 36 on page 57.
USER AVSVM BMESAPW 12M 17M BG 64
ACCOUNT ITS3000
MACHINE XA
IUCV *IDENT GATEANY GATEWAY REVOKE
IUCV ALLOW
OPTION MAINTCCW COMSRV MAXCONN 20 VCUNOSHR REALTIMER ACCT BMX
IPL GCS PARM AUTOLOG
NAMESAVE GCS
CONSOLE 01F 3215 T VMAINT
SPOOL 00C 2540 READER *
SPOOL 00D 2540 PUNCH A
SPOOL 00E 1403 A
LINK MAINT 190 190 RR
LINK MAINT 19D 19D RR
LINK VMAINT 595 595 RR
LINK VMAINT 19E 19E RR
LINK SQLMACH 198 198 RR
MDISK 0191 3390 436 3 VMXP1P MR RAVSOBJ WAVSOBJ
**********************************************************************
Figure 35. AVS Machine Definition
RDB Name
The RDB name is the database name. In our example the RDB name is
SQLLDLR01.
DRDA Partners
To connect VM to other DRDA platforms you need to provide definitions in:
• AVS Profile—AGWPROF GCS
• Communication directory—UCOMDIR NAMES.
AVS Profile Definition
56 DataHub Implementation and Connectivity
Gateways between VM and other platforms are defined in the AGWPROF GCS
file, which is invoked in the AVS machine initialization process (see Figure 36 on
page 57).
One global gateway should be defined for each AVS machine, for example:
• ′AGW ACTIVATE GATEWAY LUSQLDB2 GLOBAL′
• ′AGW CNOS LUSQLDB2 LUDB23 IBMRDB 10 5 5′.
The AVS profile is also used to specify inbound translation. When remote
application requesters are trying to get information from a VM application server,
you can translate the remote user ID for a valid local user ID.
Use one entry for each remote USER for which you want inbound translation, for
example:
• ′AGW ADD USERID LUDB23 STDB2B STSQLB

The STDB2B DB2 user on the LUDB23 gateway will be known as the STSQLB
SQL/DS user.
* * * * * *
/* AGWPROF GCS which activates one gateway for global resource */
/* communications and sets values for the session. */
* * * * * *
/* DataHub Support ************************************************ */
′ FILEDEF VDHTOR01 DISK POOL CONFIG J′
′ AGW ACTIVATE GATEWAY VDHTOR01 PRIVATE MANAGER EMQVCMG′
′ AGW CNOS VDHTOR01 SJA2015I IBMRDB 10 5 5′
′ AGW CNOS VDHTOR01 SJA2018I IBMRDB 10 5 5′
′ AGW CNOS VDHTOR01 SJA2039I IBMRDB 10 5 5′
′ AGW CNOS VDHTOR01 SJA2019I IBMRDB 10 5 5′
′ AGW CNOS VDHTOR01 SJA2050I IBMRDB 10 5 5′
/* */
/* DRDA Gateways for AVS systems*********************************** */
′ AGW ACTIVATE GATEWAY LUSQLVMA GLOBAL′
′ AGW ACTIVATE GATEWAY LUSQLDB2 GLOBAL′
/* Connection between LUSQLVMA and PS/2 Workstations ************** */
′ AGW CNOS LUSQLVMA SJA2015I IBMRDB 10 5 5′
′ AGW CNOS LUSQLVMA SJA2018I IBMRDB 10 5 5′
′ AGW CNOS LUSQLVMA SJA2039I IBMRDB 10 5 5′
′ AGW CNOS LUSQLVMA SJA2019I IBMRDB 10 5 5′
′ AGW CNOS LUSQLVMA SJA2050I IBMRDB 10 5 5′
/* Connection between LUSQLDB2 and AS/400 (SJA2054I)*************** */
/* SJA2054I for other RDBMS: AS/400, LUSQLVMB,LUDB23,LUDB2B ******* */
′ AGW CNOS LUSQLDB2 SJA2054I IBMRDB 10 5 5′
/* Connection between LUSQLDB2 and a DB2 (LUDB23) ***************** */
′ AGW CNOS LUSQLDB2 LUDB23 IBMRDB 10 5 5′
/* Connection between LUSQLDB2 and a second DB2 (LUDB2B) ********** */
′ AGW CNOS LUSQLDB2 LUDB2B IBMRDB 10 5 5′
/* SQL/400 USERS ************************************************** */
′ AGW ADD USERID SJA2054I CHAPUT =′
′ AGW ADD USERID SJA2054I STSQLA =′
′ AGW ADD USERID SJA2054I STSQLB =′
′ AGW ADD USERID SJA2054I STSQLC =′
′ AGW ADD USERID SJA2054I STSQLD =′
′ AGW ADD USERID SJA2054I STSQLE =′
/* DB2B USERS */
′ AGW ADD USERID LUDB2B CHAPUT =′
′ AGW ADD USERID LUDB2B STDB2A STSQLA′
′ AGW ADD USERID LUDB2B STDB2B STSQLB′
′ AGW ADD USERID LUDB2B STDB2C STSQLC′
′ AGW ADD USERID LUDB2B STDB2D STSQLD′
′ AGW ADD USERID LUDB2B STDB2E STSQLE′
/* DB23 USERS **************************************************** */
′ AGW ADD USERID LUDB23 CHAPUT =′
′ AGW ADD USERID LUDB23 STDB2A STSQLA′
′ AGW ADD USERID LUDB23 STDB2B STSQLB′
′ AGW ADD USERID LUDB23 STDB2C STSQLC′
′ AGW ADD USERID LUDB23 STDB2D STSQLD′
′ AGW ADD USERID LUDB23 STDB2E STSQLE′
Figure 36. AGWPROF GCS File
Chapter 3. DRDA Connectivity 57

Communication Directory Definition
A CMS application requester, to be able to connect to another RDBMS, needs to
access a system communication directory (usually called SCOMDIR NAMES)
and/or a user communication directory (usually called UCOMDIR NAMES). Each
entry in a communication directory defines the remote RDBMS.
For example, for the DB2 server named DB23 in Figure 37, we find:
• Transaction program name ″6DB (default DB2 and AS/400 TPN)
NOTE: The first character of the transaction program name (:tpn) is, in
fact, x′07′.
• LU names LUSQLDB2 (AVS LU name) and LUDB23 (DB2 LU name)
• dbname DB2CENTDIST (RDB name).
* * * * * * * * * * * *
*UCOMDIR NAMES file on STSQLB requester Machine.
*** * * * * * * * * * *
/* Entry to define the path to access the DB2 server DB2CENTDIST */
:nick.DB23
:tpn.″6DB
:luname.LUSQLDB2 LUDB23
:modename.IBMRDB
:security.SAME
:dbname.DB2CENTDIST
/* Entry to define the path to access the DB2 server DB2REGNDIST01 */
:nick.DB2B
:tpn.″6DB
:luname.LUSQLDB2 LUDB2B
:modename.IBMRDB
:security.SAME
:dbname.DB2REGNDIST01
/* Entry to define the path to access the AS/400 server SJ400DLR1 */
:nick.AS400
:tpn.″6DB
:luname.LUSQLDB2 SJA2054I
:modename.IBMRDB
:security.SAME
:dbname.SJ400DLR1
/* Entry to define the path to access the Local SQL/DS server SQLLDLR01*/
:nick.SQLLOCAL
:tpn.SQLVMA
:luname.*IDENT
:dbname.SQLLDLR01
Figure 37. UCOMDIR NAMES File
58 DataHub Implementation and Connectivity
Transaction Program Name
The TPN in SQL/DS is synonymous with the resource-id.

3.5.3 Binding Applications
Using the DBS Utility on a Non-SQL/DS Application Server
Before a user can use the DBS utility on a non-SQL/DS application server, you
must first preprocess the DBS utility package on a non-SQL/DS application
server, and then create the table SQLDBS.DBSOPTIONS on the non-SQL/DS
application server. You must obtain the necessary program bind and table
creation privileges for your authorization-id on the target application server. Do
the following from an SQL/DS application requester to preprocess the DBS
utility:
1. Run the SQLINIT EXEC to establish the non-SQL/DS application server as the
default application server.
2. Link to the database machine′s service disk:
LINK machid 193 193 RR
3. Enter the following to access the service disk:
ACC 193 V
4. To preprocess the DBS utility, enter the following:
SQLPREP ASM PP (PREP=SQLDBA,ARIDSQL, BLOCK,ISOL(CS),
NOPR,NOPU,CTOKEN(NO),ERROR) IN ARIDSQLP MACRO V)
5. To create the table SQLDBA.DBSOPTIONS, enter the following DBS utility
commands:
SET ERRORMODE CONTINUE;
CREATE TABLE SQLDBA.DBSOPTIONS (SQLOPTION VARCHAR(18) NOT
NULL, VALUE VARCHAR(18) NOT NULL);
CREATE UNIQUE INDEX SQLDBA.DBSINDEX ON SQLDBA.DBSOPTIONS
(SQLOPTION,VALUE);
INSERT INTO SQLDBA.DBSOPTIONS VALUES (′RELEASE′,′3.3.0′);
COMMIT WORK;
Using ISQL on a Non-SQL/DS Application Server
Before a user can make an ISQL request against a non-SQL/DS application
server, you must load the ISQL package on the non-SQL/DS application server.
Note: The SQL/DS ISQL component cannot access AS/400 databases from
SQL/DS; in this case use the DBS utility instead of ISQL.
Before you can load ISQL on a non-SQL/DS application server, you must first
preprocess the DBS utility on the non-SQL/DS application server. Then ensure
that your authorization-id has the necessary program bind and table creation
privileges on the non-SQL/DS application server. Do the following from an
SQL/DS application requester to load ISQL:
1. Run the SQLINIT EXEC to establish the non-SQL/DS application server as the
default application server.
2. Link to the database machine′s service disk:
LINK machid 193 193 RR
Chapter 3. DRDA Connectivity 59

3.6 AS/400 Definitions
3. Enter the following to access the service disk:
ACC 193 V
60 DataHub Implementation and Connectivity
4. Enter the following CMS command:
FILEDEF ARIISQLM DISK ARRIISQLM MACRO V
5. Enter the following DBS utility command to reload ISQL:
RELOAD PACKAGE (SQLDBA.ARIISQL) REPLACE KEEP INFILE
(ARIISQLM);
6. Create the table SQLDBA.ROUTINE, and eventually any other
userid.ROUTINE that you want. The following SQL statement illustrates the
creation of a routine table:
CREATE TABLE ROUTINE (NAME CHAR(8) NOT NULL, SEQNO INTEGER
NOT NULL, COMMAND VARCHAR(254) NOT NULL, REMARKS
VARCHAR(254) NOT NULL);
Using an SQL/DS Application on a Non-SQL/DS Application Server
Before an SQL/DS application can run on a non-SQL/DS application server, you
must load the application package on a non-SQL/DS application server. You
must obtain the necessary program bind and table access privileges for your
authorization-id on the target application server. The following example shows
the unload of the package from the SQL/DS side (SQLLDLR01) and the reload of
the package on the DB2 side (DB2CENTDIST):
1. The following DBS utility command unloads a package from SQL/DS
(SQLLDLR01):
UNLOAD PACKAGE (package-name) FROM (SQLLDLR01)
OUTFILE (ddname);
2. The following DBS utility command, issued in SQL/DS (SQLLDLR01), reloads
a package on DB2 (DB2CENTDIST):
RELOAD PACKAGE (package-name) REPLACE KEEP TO (DB2CENTDIST)
INFILE (ddname);
Configuring communications for a distributed relational database requires that
the local and remote systems are defined in the network. A relational database
directory associates communications configuration values with relational
databases in the distributed relational database network.
The AS/400 is an SNA compliant system. To allow the AS/400 to communicate
with MVS or VM you must have VTAM definitions. To communicate with OS/2
you need to configure the OS/2 Communications Manager. In our configuration
we used the same AS/400 line description to connect to the other hosts (MVS,
VM, and OS/2).
The most important task is to identify which parameters on the different
platforms must match.
Figure 38 on page 61 shows the matching parameters that you must define to
connect an AS/400 to a VTAM-based host. The AS/400 device descriptions are
created automatically because the AS/400 controller description was created
with the parameter APPN=*YES.

3.6.1 SNA Definitions
Figure 38. AS/400 and VTAM: Matching Parameters
If you are going to connect the AS/400 to a VTAM-based host (MVS or VM) we
recommend that you first define the VTAM and NCP names in their respective
macros and then define the AS/400 communications objects. Our AS/400 is
connected in a token-ring network, and we show the VTAM and AS/400
definitions for this connection.
The OS/2 definitions required to connect to the AS/400 are given in “Partner
Token-Ring Address and Logical Unit Name” on page 81.
VTAM
The proper VTAM macros must be coded in the host to which you will connect
the AS/400. You will need a VTAM listing to check the values.
You must define the VTAM PU, LU, PATH, and MODEENT macros to match the
AS/400 definitions. The AS/400 communication objects required to connect an
AS/400 to any other system are:
• Line description
• Controller description
• Device description.
You can find the AS/400 line description parameters using an AS/400 terminal,
by entering the WRKCFGSTS *LIN (Work with Configuration Status) command.
Chapter 3. DRDA Connectivity 61

62 DataHub Implementation and Connectivity
Then press enter, find the line description you are using, select option 8, and
press enter. Then select option 5 and press enter.
AS/400 Objects and Equivalencies
The AS/400 line description corresponds to the VTAM PATH macro. The
equivalent information on the OS/2 host is found in the OS/2 Communications
Manager LAPS.
The AS/400 controller description is equivalent to the VTAM PU macro. The
equivalent information on the OS/2 host is found in the OS/2 Communications
Manager partner LU profile.
The AS/400 device description is equivalent to the VTAM LU macro. The
equivalent information on the OS/2 host is found in the OS/2 Communications
Manager partner LU and LU profiles.
The AS/400 mode description is equivalent to the VTAM MODEENT macro. The
equivalent information on the OS/2 host is found in OS/2 Communications
Manager Transmission Service Mode profile and initial Session Limits profile.
Table 9 shows the corresponding communication objects in AS/400, VTAM, and
OS/2 Communications Manager.
Table 9. Communications Definitions
AS/400 VTAM OS/2
Line description PATH LAN adapter
Controller PU Partner LU
Device LU Partner LU and LU profile
Mode description MODEENT Mode profile
Figure 39 on page 63 shows the ITSC VTAM definition for the AS/400. You can
get this information in the VTAM listing.

********************************************************************
SWSJ004 VBUILD TYPE=SWNET, +
MAXGRP=1, +
MAXNO=1
*
SJA2054 PU ADDR=01, +
IDBLK=056,IDNUM=A2054, +
ANS=CONT,DISCNT=NO, +
IRETRY=NO,ISTATUS=ACTIVE, +
MAXDATA=4060,MAXOUT=7, +
MAXPATH=5,PASSLIM=7, +
PUTYPE=2,SECNET=NO,SSCPFM=USSSCS, +
MODETAB=POKMODE,DLOGMOD=LU62APPA, +
USSTAB=USSRDYN,LOGAPPL=SCGVAMP, +
PACING=0,VPACING=2
*
PA2054 PATH DIALNO=400052047158, +
USE=YES, +
GID=1, +
PID=1, +
REDIAL=2
*
SJA2054I LU LOCADDR=000,DLOGMOD=LU62APPA
SJA2054A LU LOCADDR=001,DLOGMOD=DTNNJE0,MODETAB=RSCSTAB
SJA2054B LU LOCADDR=002,DLOGMOD=LU62APPA
SJA2054C LU LOCADDR=003,DLOGMOD=LU62APPA
SJA2054D LU LOCADDR=004,DLOGMOD=LU62APPA
SJA2054E LU LOCADDR=005,DLOGMOD=LU62APPA
SJA2054F LU LOCADDR=006,DLOGMOD=LU62APPA
Figure 39. VTAM: AS/400 Definition
AS/400
The AS/400 system must be defined in the network so that each system can
identify itself and the remote systems in the network. To define an AS/400
system in a network you must:
1. Change or define the network attributes.
2. Create the line descriptions.
3. Create a controller description.
4. Create a class-of-service description.
5. Create a mode description.
6. Create a device description automatically or manually.
7. Create or update the local QAPPNLCL and remote QAPPNRMT configuration
list.
Chapter 3. DRDA Connectivity 63

64 DataHub Implementation and Connectivity
AS/400 Network Attributes Definition (LU Name)
Use the OS/400 CHGNETA (Change Network Attributes) command to change the
network attributes.You can press F4 (PROMPT) and type over the fields with the
new definition.
Figure 40 shows the network attributes of the ITSC AS/400.
Local System Name : SJAS400A
Local Network ID : USIBMSC
Local Control Point Name : SJAS400A
Default Local Location Name : SJA2054I
Default Mode : IBMRDB
APPN Node Type : *NETNODE
Figure 40. ITSC AS/400 Network Attributes Definition
In an AS/400 environment, DRDA can be implemented using token-ring, SDLC,
Ethernet, ISDN, or X.25 communication protocols.
Our AS/400 is connected in a token-ring LAN, connected to a 3745
Communications Controller, and to other RDBMSs through a token-ring bridge.
Token-Ring Line Description
As our AS/400 is connected in a token-ring LAN, we used the command
CRTLINTRN (Create Line Token Ring Network) to create our line description
definition. See Figure 41 for details.
CRTLINTRN LIND(TRLINE) RSRCNAME(LIN031) MAXFRAME(4060) +
ADPTADR(400052047158) EXCHID(056A2054) +
LINKSPEED(4M) + AUTOCRTCTL(*YES) +
TEXT(′ ITSC DRDA Token Ring Line 4M′)
Figure 41. AS/400: Token Ring Line Description Definition
ADAPTADR: The ADAPTADR parameter in the AS/400 line description must
match the DIALNO parameter in the VTAM PATH macro.
EXCHID: The three first bytes of the EXCHID parameter in the AS/400 line
description definition correspond to the IDBLK parameter in the VTAM PU
macro. The other five bytes of the EXCHID parameter correspond to the IDNUM
parameter in the same VTAM PU macro.
Partner Token-Ring Address (Creating a Controller Description)
If the AUTOCRTCTL parameter on a token-ring or Ethernet line description is set
to *YES, the controller description and device description are automatically
created when the system receives a session start request over the line.
The VTAM SSCPNAME value must match the AS/400 controller description
RMTCPNAME parameter.
Optionally it is possible to define the controller using the AS/400 commands
CRTCTLHOST or CRTCTLAPPC (Create Controller Description Host or APPC). See
Figure 42 on page 65.

CRTCTLHOST CTLD(TRCTLHOST) LINKTYPE(*LAN) ONLINE(*YES) +
APPN(*YES) SWTLINLST(TRLINE) +
MAXFRAME(4060) RMTNETID(USIBMSC) +
RMTCPNAME(SCG20) INLCNN(*DIAL) +
ADPTADR(400008210200) +
TEXT(′ Controler to VTAM SSCPNAME SCG20)
Figure 42. AS/400: Controller Description Definition
Partner LU Name (Creating a Device Description)
The device description describes the characteristics of the logical connection
between the AS/400 and remote systems. The device description is created
automatically or manually depending on the APPN parameter on the CRTCTLAPPC
or CRTCTLHOSTcommand.
If the parameter APPN = *YES is specified, the device description is
automatically created and attached to the appropriate controller description
when the session is established.
If the parameter APPN = *NO is specified, the device description must also
specify APPN = *NO to indicate the device is not used in an APPN network. In
this case the device description must be created manually.
The device description is equivalent to the VTAM LU macro.
To manually create a device description, you must use the CRTDEVAPPC (Create
Device Description APPC) command.
Figure 43 shows the device description of the AS/400 DRDA connection to DB2.
This device was created automatically when the first connection was established.
We present it here to point out the AS/400 definitions that must match the VTAM
definitions. If you want to create the device description manually, you can use
this definition as an example.
CRTDEVAPPC DEVD(LUDB23) LOCADR(00) RMTLOCNAME(LUDB23) +
ONLINE(*NO) + LCLLOCNAME(SJA2054I) +
RMTNETID(*NETATR) + MODE(*NETATR) + MSGQ(*LIBL/QSYSOPR) +
APPN(*YES) SNGSSN(*NO) + TEXT(′ AUTOMATICALLY CREATED BY QLUS′)
Figure 43. AS/400: Device Description Definition
Class of Service
A class of service is used to select the communication routes (transmission
groups) and assign transmission priority for sessions using APPN. The OS/400
system supplies five classes of service:
• #CONNECT
• #BATCH
• #BATCHSC
• #INTER
• #INTERSC.
Chapter 3. DRDA Connectivity 65

Other classes of service can be created using the CRTCOSD (Create
Class-of-Service Description) command.
Mode Description Definition
The mode description provides the session characteristics and number of
sessions that are used to negotiate the allowed values between the local and the
remote location. The mode description also points to the class of service to use
for the conversation.
The AS/400 mode description MAXLENRU and PACING parameters are equivalent
to the VTAM RU size and pacing definitions.
Five mode descriptions are shipped with the OS/400 system:
• BLANK (the default mode name specified in the network attributes when
system is shipped)
• #BATCH
• #BATCHSC
• #INTER
• #INTERSC.
66 DataHub Implementation and Connectivity
Other mode descriptions can be created using the CRTMODD command.
AS/400 APPN Location List Configuration
APPN locations lists are used to define the names of local locations and to
describe special characteristics of remote locations. APPN location lists are
used only by APPN configurations.
APPN Local Location List: The local location list defines the names of the
locations that are defined on the local system. Only one local location list
resides on the system. Each AS/400 in a network has one local network
identifier and a control point name.
APPN Remote Locations List: Only one APPN remote location list resides on
the system. In the ITSC DRDA network, because all hosts belong to a DRDA
configuration, and we want to go from any AR to any AS, the DRDA conversation
uses the LU 6.2 protocol. Because of DRDA, all remote locations must be
defined to the AS/400 in the APPN remote locations list.
Defining the Configuration List: The WRKCFGL (Work with Configuration List) or
ADDCFGLE (Add Configuration List Entry) commands can be used to define the
APPN configuration list.
The AS/400 Communications Configuration Reference and the AS/400 APPN
Guide contain more information about configuring for networking support and
working with location lists.
Figure 44 on page 67 shows our AS/400 remote configuration list definition.

3.6.2 DRDA Definitions
Configuration list . . . . . . . . : QAPPNRMT
Configuration list type . . . . . : *APPNRMT
Text . . . . . . . . . . . . . . . :
-----------------APPN Remote Locations------------------
Remote Remote Control
Remote Network Local Control Point Secure
Location ID Location Point Net ID Loc
LUDB23 USIBMSC SJA2054I SCG20 USIBMSC *YES
LUSQLVMA USIBMSC SJA2054I SCG20 USIBMSC *YES
Figure 44. ITSC AS/400 Configuration List Definition
To connect an AS/400 in a DRDA environment, you need to check the AS/400
coded character set identifier (CCSID) and define the AS/400 RDB directory
entry.
AS/400 CCSID
DataHub does not support a CCSID of 65535. Therefore the user profile CCSID of
the DataHub user cannot be 65535, and the CCSID of the database managed by
DataHub cannot be 65535.
In the AS/400 the CCSID is specified at:
• System level, with the system value parameter QCCSID
• User profile level, with the CCSID parameter in the AS/400 user profile.
The system value QCCSID parameter at the AS/400 used in our network is
defined as 37 (US English), and the same value is specified at DB2, SQL/DS, and
OS/2 Database Manager.
AS/400 RDB Directory
In order for an SAA RDB to access the AS/400 database through DRDA it is
necessary to create an entry in the AS/400 relational database directory. To
create the entry execute the ADDRDBDIRE (Add Relational Database Directory
Entry) or WRKRDBDIRE (Work with Relational Database Directory) command.
RDB Name: The AS/400 database is recognized by other RDBMSs through a
*LOCAL entry in the AS/400 RDB directory. In the ITSC AS/400 environment, the
AS/400 local database name is SJ400DLR1:
ADDRDBDIRE RDB(SJ400DLR1) RMTLOCNAME(*LOCAL)
Remote RDB Name: The same command is used to add the remote RDB name
to the AS/400 RDB directory. You simply repeat the command to add all the
remote RDBs:
ADDRDBDIRE RDB(DB2CENTDIST) RMTLOCNAME(LUDB23) DEV(*LOC) +
LCLLOCNAME(SJA2054I) RMTNETID(USIBMSC) +
MODE(IBMRDB) TNSPGM(*DRDA)
If you are connecting the AS/400 to an SQL/DS RDBMS, the AS/400 directory
entry parameter TNSPGM must match the SQL/DS TPNAME.
Chapter 3. DRDA Connectivity 67

3.6.3 Testing DRDA Connections
68 DataHub Implementation and Connectivity
After you have successfully completed all network definitions you must use the
WRKRDBDIRE or the ADDRDBDIRE command to define the *LOCAL OS/400
database and all the application servers that you want to access from the
AS/400. You must include an entry for each application server that the AS/400
will access.
Figure 45 shows the AS/400 relational database directory definition.
OS/400 Local Database Display Entry
Relational database . . . . . . . . . . . . . : SJ400DLR1
Remote location:
Remote location . . . . . . . . . . . . . . : *LOCAL
Device description . . . . . . . . . . . . . :
Local location . . . . . . . . . . . . . . . :
Remote network identifier . . . . . . . . . :
Mode . . . . . . . . . . . . . . . . . . . . :
Transaction program . . . . . . . . . . . . . :
Text . . . . . . . . . . . . . . . . . . . . . : OS/400 Local Databa
DB2 Host Remote Database Display Entry
Relational database . . . . . . . . . . . . . : DB2CENTDIST
Remote location:
Remote location . . . . . . . . . . . . . . : LUDB23
Device description . . . . . . . . . . . . . : *LOC
Local location . . . . . . . . . . . . . . . : SJA2054I
Remote network identifier . . . . . . . . . : USIBMSC
Mode . . . . . . . . . . . . . . . . . . . . : IBMRDB
Transaction program . . . . . . . . . . . . . : *DRDA
Text . . . . . . . . . . . . . . . . . . . . . : DB2 Server
SQL/DS Host Remote Database Display Entry
Relational database . . . . . . . . . . . . . : SQLLDLR01
Remote location:
Remote location . . . . . . . . . . . . . . : LUSQLVMA
Device description . . . . . . . . . . . . . : *LOC
Local location . . . . . . . . . . . . . . . : SJA2054I
Remote network identifier . . . . . . . . . : USIBMSC
Mode . . . . . . . . . . . . . . . . . . . . : IBMRDB
Transaction program . . . . . . . . . . . . . : SQLVMA
Text . . . . . . . . . . . . . . . . . . . . . : SQL/DS Server
Figure 45. AS/400: Local and Remote Relational Database Directory
After all SNA and DRDA directory definitions are complete, you need to test the
connection through the DRDA network. To test the connection from the AS/400,
you can use the STRSQL (Start SQL) command. Within an SQL interactive
session, you can use the CONNECT TO RDBNAME command where RDBNAME is the
same name that is specified in the AS/400 RDB directory, that is, the RDB name.
If the connection from the AS/400 to the remote database is working properly,
you will receive a message specifying that you are connected to a remote

3.6.4 Binding Applications
3.7 OS/2 Definitions
3.7.1 OS/2 Host Components
database. Otherwise an error message will be issued at your AS/400 SQL
interactive screen.
After a successful connection from the AS/400 to a remote database, we
recommend that you execute an SQL select statement against the remote
database. If you receive an error message, you should verify the AS/400
message, the job log, and message queue QSYSOPR, and use the appropriate
approach on the remote system to determine what went wrong.
It is not necessary to bind the AS/400 interactive SQL to the SQL/DS or DB2
RDBMSs. The bind is automatically done at the first successful connection. All
AS/400 users will share the package created at the remote locations.
In the sections that follow, we explain the relationship between the OS/2
components, review the general steps required to customize your OS/2
environment for DRDA connectivity, and show how to customize the SNA, DRDA,
and RDS key connectivity parameters. Also provided are screen captures of the
most important windows you will use to customize your OS/2 environment. This
document does not show how to install the different components. You must refer
to the component installation documents.
Outside the OS/2 base operating system, the components used on an OS/2
DRDA host are:
• The LAN Adapter and Protocol Support (LAPS)
The LAPS program is provided in different software:
− Extended Services for OS/2
− LAN Server/Requester (any version)
− NTS/2.
The LAPS program deals with token-ring network customization and support.
It also provides the NETBIOS protocol that could be used to connect clients
to an OS/2 Database Manager server or to interconnect OS/2 Database
Manager servers to one another (for example, connect the DataHub/2
workstation to an OS/2 host).
If you are using a physical connection other than the token-ring (for example,
SDLC), the OS/2 Communications Manager provides you with the necessary
support.
• OS/2 Communications Manager
Note: OS/2 Communications Manager is not the name of a product. When
we use the term OS/2 Communications Manager, we are really talking about
the communication manager component of Extended Services for OS/2 or the
Communications Manager/2 (CM/2) product. All the screen captures in this
chapter are screen captures of CM/2.
The OS/2 Communications Manager provides you with the LU 6.2 support
that is required for connecting the OS/2 host to the different DRDA hosts
(MVS, VM, and AS/400). The LU 6.2 protocol is also used for the DataHub
Chapter 3. DRDA Connectivity 69

tools conversation. It could also be used instead of the NETBIOS protocol to
connect OS/2 Database Manager clients to the database server.
• OS/2 Database Manager
OS/2 Database Manager provides you with a relational database interface
that is used to access either local or remote databases. You will need to
customize the different OS/2 Database Manager directories to enable the
different connections. Two protocols are used in a DataHub environment:
− DRDA for interconnection between the MVS, VM, and AS/400 hosts. The
DRDA protocol is also used to connect OS/2 Database Manager servers
to these three hosts.
− RDS is used to interconnect OS/2 Database Manager clients and servers.
Note: OS/2 Database Manager is not the name of a product. When we use
the term OS/2 Database Manager, we are really talking about the database
manager component of Extended Services for OS/2 or the DB2/2 product.
Because the directory tool interface has not changed, the examples we
provide are applicable to both products.
• Distributed Database Connection Services/2
DDCS/2 enables the DRDA architecture on the OS/2 Database Manager
platform. It is not required if you do not have any MVS, VM, or AS/400 hosts
in your organization. This product enables an additional directory, the DCS
Directory, which is customized through the OS/2 Database Manager
Directory Tool.
3.7.2 Relationship between OS/2 Components
As you will have noticed when reading the previous section, many components
are used on the OS/2 platform. Many of the values used to customize one
component are used by other components. Figure 46 on page 71 will help you
understand the relationships between the different values used. Problem
determination will become very easy if you understand those relationships.
The diagram on Figure 46 on page 71 shows the flow of three different OS/2
Database Manager requests:
• Local connect request
70 DataHub Implementation and Connectivity
• Inbound connect request, as it would be received by an OS/2 Database
Manager server workstation or a DDCS/2 gateway
• Outbound connect request, as it would be sent by an OS/2 Database
Manager client to a server or a DDCS/2 gateway or from a DDCS/2 gateway
to a DRDA server.
Figure 46 on page 71 does not show the flow for a NETBIOS type of connection
used between an OS/2 Database Manager client and an OS/2 Database Manager
server or between servers. We do not show this flow because the NETBIOS flow
does not involve OS/2 Communications Manager. It involves only the OS/2
Database Manager component.

Figure 46. OS/2 Component Definition Relationships
Local Request Flow
The local request (bottom part of the diagram), which could have been entered
on an OS/2 command line or through the OS/2 Database Manager API, comes
into OS/2 Database Manager. First OS/2 Database Manager looks in the system
directory for an alias with the name of MNYCENT. From that entry, OS/2
Database Manager determines whether that database is local or remote and the
database name. In the example, the MNYCENT database is remote, it could be
accessed through the WNYCENT workstation, and the database name is
DCSMNYC.
Then OS/2 Database Manager looks for an entry with the database name
DCSMNYC in the DCS directory. Because this directory entry exists, this OS/2
workstation is used as a DDCS/2 gateway. If OS/2 Database Manager finds
DCSMNYC, it can determine the RDB name to which it will connect and the
name of the program that will handle the request on the remote site. Because
Chapter 3. DRDA Connectivity 71

72 DataHub Implementation and Connectivity
OS/2 Database Manager has found the entry, it will use the DRDA protocol to
exchange information with the remote RDBMS.
On the other hand, using the WNYCENT workstation name entry, OS/2 Database
Manager can figure out the partner LU, the mode, and the type of protocol to use
to get to the partner RDBMS. Because the partner is a DRDA server (DB2), it is
mandatory to use the APPN protocol.
Note: If the NETBIOS protocol were used, then instead of entering the SNA
definitions, the remote OS/2 Database Manager workstation name would have
been used.
Once all information has been gathered using the OS/2 Database Manager
directory entries, OS/2 Database Manager passes that information to OS/2
Communications Manager to establish the session with the partner RDBMS. The
outbound flow is explained below under “Outbound Request Flow.”
Inbound Request Flow
When a OS/2 Database Manager client or another OS/2 Database Manager
server wants to connect to a OS/2 Database Manager server or a DCCS/2
gateway, two communication protocols could be used: NETBIOS and LU 6.2
(APPN). NETBIOS uses the OS/2 Database Manager workstation name, which is
defined at installation time, to establish the connection. This relationship is not
shown on Figure 46 on page 71. When the inbound request uses the LU 6.2
protocol, an LU to LU session will be negotiated and established between the
remote LU (client) and the local LU (server). The local node characteristics
parameters must be used by the client in order to connect to the server. The
mode name entry is used for the session negotiation between the two LUs.
Once the session has been established between the client and the server, SQL
statements can be received and executed at the server and responses
transmitted to the client. The first SQL statement to be passed by the client is
the Connect (that is, START USING DATABASE). From there on, OS/2 Database
Manager uses the same flow as the local flow to determine which database it
will use.
Outbound Request Flow
When OS/2 Database Manager wants to establish a session with a remote
partner using the LU 6.2 protocol, it passes the partner LU name, the transaction
program name, and the mode name to OS/2 Communications Manager, which in
turn performs the session allocation. OS/2 Database Manager does not need to
know where the partner LU is located. This is the OS/2 Communications
Manager′s job. Through its own table, OS/2 Communications Manager will
determine:
• At which physical address this partner LU is located
• Which control point controls the sessions
• Which protocol to use to connect (for example, token-ring, SDLC, and the
like).
Once the session has been established between DBM and the remote RDBMS,
the SQL traffic will start to flow. When the remote RDBMS is a DRDA server, the
flow is governed by the DRDA flows and protocols.

3.7.3 General Customization Plan
The following plan gives a general idea of the different steps required to
implement DRDA or RDS on the OS/2 platform:
LAPS
3.7.4 SNA Definitions
• Customize the LAPS (physical connection).
OS/2 Communications Manager
• Define your SNA LU (local node characteristics) in OS/2 Communications
Manager
• Define the different partner LU connections using OS/2 Communications
Manager connection menus
• Define the modes you will be using for the different connections in OS/2
Communications Manager.
OS/2 Database Manager
• Define the OS/2 Database Manager server workstation name. This name is
used to connect clients or other servers to the OS/2 Database Manager
server if the protocol used is NETBIOS.
• Catalog the OS/2 Database Manager Workstation entries. They will need to
refer to either the Partner LU definitions made in OS/2 Communications
Manager or other OS/2 Database Manager workstation names to which you
want to connect.
• Catalog the OS/2 Database Manager directory entries for all remote
databases. You will need to refer to the workstation entries made
previously.
• Catalog the OS/2 Database Manager database connection services entries
for the DRDA connection.
If your OS/2 host system is connected to an MVS or VM host or if you want to
use DataHub to manage RDBMSs that are located on one of those platforms,
your OS/2 workstation needs to be defined in VTAM.
OS/2 VTAM Definitions
Figure 47 on page 74 shows you the exact VTAM definitions we used for the
DataHub/2 workstation. In fact, all of our OS/2 systems are defined the same,
except for the LU names and the IDNUM.
Chapter 3. DRDA Connectivity 73

74 DataHub Implementation and Connectivity
********************************************************************
SWSJ001 VBUILD TYPE=SWNET, +
MAXGRP=1, +
MAXNO=1
*
SJA2039 PU ADDR=01, +
IDBLK=05D,IDNUM=A2039, +
ANS=CONT,DISCNT=NO, +
IRETRY=NO,ISTATUS=ACTIVE, +
MAXDATA=265,MAXOUT=1, +
MAXPATH=1, +
PUTYPE=2,SECNET=NO, +
MODETAB=POKMODE,DLOGMOD=DYNRMT, +
USSTAB=USSRDYN,LOGAPPL=SCGVAMP, +
PACING=1,VPACING=2
*
SJA2039A LU LOCADDR=002
SJA2039B LU LOCADDR=003
SJA2039C LU LOCADDR=004
SJA2039D LU LOCADDR=005
SJA2039I LU LOCADDR=0,DLOGMOD=IBMRDB
SJA2039J LU LOCADDR=0,DLOGMOD=IBMRDB
SJA2039K LU LOCADDR=0,DLOGMOD=IBMRDB
SJA2039L LU LOCADDR=0,DLOGMOD=IBMRDB
*
Figure 47. OS/2 Host Definition. This definition is used for the DataHub/2 workstation.
Figure 48 on page 75 shows the relationships that you must consider when you
customize OS/2 Communications Manager. If you do not understand the content
of the menus, we suggest you click on the Help push button or press the F1 key.
You could also refer to Figure 48 on page 75.

Figure 48. OS/2 Communications Manager Relationships with VTAM Definitions
Token-Ring Address
The OS/2 SNA connection over a token-ring network requires customization of
both the LAPS program and the OS/2 Communications Manager.
If your workstation is already attached to a token-ring network, this
customization is not necessary. However, you should take note of some
important performance parameter values, such as:
• Number of adapter receive buffers
• Receive buffer size
• Number of adapter transmit buffers
• Transmit buffer size.
The customization of the token-ring connection, which we use for our network,
requires the use of the LAPS program.
Note: For the screen captures that follow, we used the NTS/2 software.
To customize the LAN adapter, here are the steps involved using the NTS/2
software:
1. Start an OS/2 session.
2. Execute the command C:\IBMCOM\LAPS.
You will get the LAPS main window.
Note: Not all the windows have been captured. Only the most important
windows are shown in this document.
Chapter 3. DRDA Connectivity 75

3. Click on Configure....
The Configuration window will appear.
4. Select the Configure LAN Transport radio button and click on Continue....
The Configure Workstation window will appear. As shown in Figure 49, your
actual configuration will be displayed in the Current Configuration part of the
menu. You should have the IBM Token-Ring Network Adapters selected and
the two protocols associated with the Token-Ring Network Adapter:
• IBM IEEE 802.2, used by LU 6.2
Figure 49. LAPS: Configure Workstation Window
• IBM OS/2 NETBIOS, used by RDS and LAN Requester in our
configuration.
5. Select Token-Ring Network Adapters.
6. Click on Edit.
76 DataHub Implementation and Connectivity
The Parameters for IBM Token-Ring Network Adapters window will appear
as shown in Figure 50 on page 77. If you are using locally administered
addresses, enter the network adapter address that has been given to you by
your network personnel; otherwise leave the field blank.

Figure 50. LAPS: Parameters for IBM Token-Ring Network Adapters Window
7. Click on OK when you are done.
The Configure Workstation window (Figure 49 on page 76) will then
reappear.
8. You could edit the two protocol definitions in the Current Configuration box
by selecting either protocol (that is, IBM IEEE 802.2 or IBM OS/2 NETBIOS),
clicking on Edit and then clicking on OK when you are done.
9. When the LAPS configuration is finished, click on OK on the Configure
Workstation window.
10. Click on Exit on the LAPS Main Window.
The CONFIG.SYS Update window will appear.
11. If you updated your configuration, you should click on Continue... to update
your CONFIG.SYS file. If you did not update the configuration, click on Exit.
To activate the changes, you will need to shut down your workstation. Once the
system is operational again, you could verify the content of the LANTRAN.LOG in
the IBMCOM directory. This log file contains the status of the token-ring card. It
includes the token-ring address of the adapter.
IDBLK, IDNUM, Network ID, Logical Unit Name, SNA Control Point
Name
Now that your workstation is connected to the network, you need to define the
different communication parameters using the OS/2 Communications Manager
interface. The IDBLK, IDNUM, Network ID, Logical Unit Name, and SNA Control
Point Name are defined on the Local Node Characteristics window as shown in
Figure 54 on page 80. But before explaining that, let′s discuss how to get there.
1. If you use Communications Manager/2 as we did, you start the
Communications Manager Setup application from the Communications
Chapter 3. DRDA Connectivity 77

Manager/2 folder. For the Extended Services for OS/2 environment, you start
the SNA Network Definitions Configuration from the Communications
Manager folder.
2. Select the OS/2 Communications Manager configuration file you want to
customize.
The Communications Manager Configuration Definition window will appear.
3. Select Token-ring or other LAN types in the Workstation Connection Type
window.
The list of available features will change in the Feature or Application
window.
4. Select CPI Communications from the Features or Application window.
You will end up with the screen shown in Figure 51.
Figure 51. CM/2: Communications Manager Configuration Definition Window
5. Click on Configure....
78 DataHub Implementation and Connectivity
The Communications Manager Profile List Sheet window, as shown in
Figure 52 on page 79, will appear. In Extended Services for OS/2 this is
where you will end up once you have entered the name of the configuration
file.
From this window, you will be able to define all the key connectivity
parameters that are used for both the DRDA network and the DataHub tools
conversation protocol.

Figure 52. CM/2: Communications Manager Profile List Sheet Window
6. Select DLC - Token-ring or other LAN types and click on Configure....
The Token-Ring or Other LAN Types DLC Adapter Parameters window will
appear as shown in Figure 53. This window is used to customize the LU 6.2
usage of the token-ring adapter. The following parameters have an impact
on capacity and performance:
• Send window count
• Receive window count
• Maximum I-field size.
For any performance-related parameter, you should use the default value
provided.
Figure 53. CM/2: Token-Ring or Other LAN Types DLC Adapter Parameters Window
7. Once the setup is complete, click on OK.
Chapter 3. DRDA Connectivity 79

You are then back to the Communications Manager Profile List Sheet
window (Figure 52).
8. Select the SNA local node characteristics line and click on Configure....
The Local Node Characteristics window (Figure 54) will appear. On this
window, you will define your OS/2 workstation as it is known to the network.
If you have MVS or VM hosts, you will need to refer to the VTAM definition to
fill in the appropriate information (See Figure 47 on page 74).
The Network ID information must be provided by your network personnel.
The Local node name is the LU name (label of the LU macro) of one of the
LUs that are defined with LOCADDR=0. In the VTAM definition that is
provided, four independent LUs are defined for the PU. The LU SJA2039I is
an independent LU because it is defined with LOCADDR=0 and the PU is
defined as a PU type 2 (PUTYPE=2). The Local node ID (hex) values are the
IDBLK and IDNUM parameter values in the OS/2 workstation VTAM
definition.
Figure 54. CM/2: Local Node Characteristics Window
Table 10 shows you the local node definitions we used for our OS/2 system.
Table 10. OS/2 Local Node Definitions for the ITSC Network
OS/2 System Network ID Local Node
Name
DH/2 Control
Point
80 DataHub Implementation and Connectivity
Local Node
ID
9. Once you have defined your local node characteristics, click on OK.
Local Node
Alias
USIBMSC SJA2039I 05D A2039 ASJA2039
Montreal USIBMSC SJA2018I 05D A2018 ASJA2018
Paris USIBMSC SJA2050I 05D A2050 ASJA2050
Rio De Janeiro USIBMSC SJA2019I 05D A2019 ASJA2019

The Communications Manager Profile List Sheet window (Figure 52 on
page 79) will then appear.
Partner Token-Ring Address and Logical Unit Name
Now that your workstation is defined to the network, you need to define the
connection to the MVS host and the partner LUs associated with it and with
which you will exchange information.
The steps that follow start at the Communications Manager Profile List Sheet
window of Communications Manager/2 (Figure 52 on page 79). For Extended
Services for OS/2, partner definition begins right after you give the name of the
configuration file to the SNA Network Definitions Configuration program.
If your PLU resides on a network different from yours, you will have to go into
both the SNA connections dialog to define the PLU and the SNA features dialog
to change the PLU network identification. If your PLU resides on the same
network as yours, you need only to go into the SNA connections dialog to define
the PLU. The following example, which is the ITSC case, assumes only one
network.
1. Select the SNA connections line from the window and click on Configure....
The Connections List window will appear. As you can see in Figure 55 on
page 82, there are radio buttons for the type of partner you can define.
Based on the partner type you select, a list of links will appear. In Figure 55
on page 82, we have only one link defined for a host type connection. The
host on that window represents VTAM/NCP hosts. Under the peer node type,
you could find the OS/2 and AS/400 systems.
Network node type partners are special nodes that manage nodes in an
APPN network. An APPN network is made up of network node systems and
end node systems. One end node system would need to know only one
network node in order to connect to every end node in the APPN network. A
new end node that is connected to a network node is immediately known to
the other nodes. The network nodes take care of routing the connection
requests through the network. In addition, new node information is
broadcast to all network nodes. With this type of APPN network you would
not have to define all the nodes everywhere in the network.
We did not implement any network node in our OS/2 configuration.
Chapter 3. DRDA Connectivity 81

Figure 55. CM/2: Connections List Window (Host Links)
2. Let us now suppose that we want to connect to the New York system, which
is an MVS system. Select the To host radio button. The link named
MNYCENT appears. Select it and click on Change....
The Adapter List used for that link will display (see Figure 56). If you are
using another type of connection (for example, SDLC), you would have
selected an adapter type other than the token-ring. Figure 56 shows that we
are using the token-ring adapter number 0 for that link.
Figure 56. CM/2: Adapter List Window
3. Click on Continue....
82 DataHub Implementation and Connectivity
The next window that appears is used to define the remote control point
name or the remote node name. Figure 57 on page 83 shows you how we
defined the connection to the central site located in New York.

Figure 57. CM/2: Change Connection to a Host Window
The link name could be any name. For our host link, the LAN destination
address is the 3745 token-ring address as defined in the NCP. Refer to
section 3.4, “MVS Definitions” on page 40 to know how this token-ring
address has been defined. The partner node name is the control point name
of the target destination, which is the value associated with the SSCPNAME
NCP parameter. The Local PU name and the Node ID (hex) are new in the
Communications Manager/2 product. They are used for 3270 terminal
emulation. For the local PU name you need to use the PU name in the OS/2
VTAM definition (Figure 47 on page 74). For the Node ID, use IDBLK and
IDNUM in the same definition.
4. Once you have defined your remote control point, you need to define the
partner LU that will be accessible through that link. Click on Define Partner
LUs....
You will get the Change Partner LUs window. As shown in Figure 58 on
page 84, multiple partner LUs can be accessed through a link. In fact, this
window shows you all the definitions to connect to DB2 and DataHub
Support/MVS in New York and to SQL/DS and DataHub Support/VM in
Toronto.
5. Select the partner LU with which you want to work. Perform the necessary
changes, and click on Change....
Chapter 3. DRDA Connectivity 83

Figure 58. CM/2: Change Partner LUs Window
6. When finished, click on OK.
84 DataHub Implementation and Connectivity
You will be back at the Change a Connection to a Host window (Figure 57 on
page 83).
7. Click on OK to save the changes.
You will end up at the Connections List Window (Figure 55 on page 82).
8. Click on Close to terminate the definition of the links.
You will end up at the Communications Manager Profile List Sheet window
(Figure 52 on page 79).
Now that you have defined the connection to the MVS host and all partner LUs
associated with it, you could add other links to access other systems, like the
AS/400 or the OS/2. The same steps need to be performed for the peer node as
for the host node.
Table 11 on page 85 shows the partner LU definitions that are needed to
interconnect all the different ITSC systems for the DRDA network. The only
system that is not defined as a partner is the DataHub/2 workstation, because it
is always a requester in a DRDA or DataHub network.

Table 11. OS/2 Partner LU Definitions for the ITSC Network
Partner Token-Ring Address Partner Node Name Partner LU Name Partner LU Alias
Name
New York Central 400008210200 USIBMSC.SCG20 USIBMSC.LUDB23 DBNYCENT
Toronto Car Dealer 400008210200 USIBMSC.SCG20 USIBMSC.LUSQLVMA DBTORDR1
San Jose Car Dealer 400052047158 USIBMSC.SJAS400A USIBMSC.SJA2054I ASJDLR1
Montreal Car Dealer 400052047122 USIBMSC.SJA2018I USIBMSC.SJA2018I OMTLDLR1
Paris Car Dealer 400052047157 USIBMSC.SJA2050I USIBMSC.SJA2050I OPARDLR1
Rio De Janeiro Car
Dealer
400052047116 USIBMSC.SJA2019I USIBMSC.SJA2019I ORIODLR1
Note: The partner LU names for the OS/2 hosts will actually be used for DataHub Support connectivity definitions.
Mode Name
A mode definition is required to connect LUs together. The steps required to
add or modify a mode are given below. As with the other SNA definitions, we
start from the Communications Manager Profile List Sheet window (Figure 52 on
page 79).
1. Select the SNA Features line and click on Configure....
The SNA Features List window will display.
2. Select Modes from the Features list box.
The list of all modes defined locally will display as shown in Figure 59.
Figure 59. CM/2: SNA Features List Window (Modes). This window lists all the modes
defined on this workstation.
3. Click on Create... to create a new mode or select one from the modes list
box. Then click on Change....
The Change a Mode Definition window will display (Figure 60 on page 86).
For DRDA or DataHub connection, the class of service that must be selected
is #CONNECT. On this window, you specify the RU size and the Receive
pacing window, whose values are important for performance.
Chapter 3. DRDA Connectivity 85

3.7.5 DRDA Definitions
Figure 60. CM/2: Change a Mode Definition Window
4. Once you have completed the mode definition, click on OK to save it.
You will be presented with the SNA Features List window (Figure 59 on
page 85) with the new mode included in the list of modes.
5. If you have completed all your definitions, click on Close.
The Communications Manager Profile List Sheet window (Figure 52 on
page 79) will appear.
6. If you have completed all your SNA definitions, click on Close.
The Communications Manager Configuration Definition window will appear
(Figure 51 on page 78).
7. Click on Close to terminate and validate the changes that you performed.
8. Click on Close on the Communications Manager Setup window.
Once you have completed the SNA definitions to connect to the different RDBMS
partners, you need to customize the OS/2 Database Manager directories to
connect a local database name to both the partner LU and the remote RDB
name.
To define those directories, many interfaces could be used:
• The OS/2 Database Manager directory tool
• The command line interface (Extended Services for OS/2) or command line
processor (DB2/2)
• OS/2 procedure
• OS/2 program.
86 DataHub Implementation and Connectivity
We used the OS/2 Database Manager directory tool. See Figure 61 on page 87,
which provides you with a sample OS/2 REXX procedure to create the directory
entries.

Recommendation
If you are using the LAN configuration or a common DataHub/2 database, we
recommend that you use REXX procedures to catalog and uncatalog entries.
Once the REXX procedure has successfully executed on one DataHub/2
workstation, it can be executed on the other DataHub/2 workstations.
Figure 61 on page 87 shows you the listing of the REXX procedure we used.
/* REXX command to replicate directory entries to each workstation */
SAY ′ Starting workstation definitions...′ ;
SAY;
CALL DBM ′ CATALOG NetBios NODE WPARDLR1 REMOTE DHSERVER ADAPTER 0 WITH ″OS/2 Paris car dealer″′;
CALL DBM ′ CATALOG NetBios NODE WMTLDLR1 REMOTE DHSERVER ADAPTER 0 WITH ″OS/2 Montreal car dealer″′;
CALL DBM ′ CATALOG NetBios NODE WRIODLR1 REMOTE DHSERVER ADAPTER 0 WITH ″OS/2 Rio car dealer″′;
CALL DBM ′ CATALOG NetBios NODE WNYCENT REMOTE DHSERVER ADAPTER 0 WITH ″MVS New York Central ″′;
CALL DBM ′ CATALOG NetBios NODE WTORDLR1 REMOTE DHSERVER ADAPTER 0 WITH ″VM Toronto car dealer 1″′;
CALL DBM ′ CATALOG NetBios NODE WSJDLR1 REMOTE DHSERVER ADAPTER 0 WITH ″AS/400 San Jose car dealer 1″′;
SAY;
SAY ′ Starting system directory definitions...′ ;
SAY;
CALL DBM ′ CATALOG DATABASE OPARDB AS OPARDB AT NODE WPARDLR1 WITH ″OS/2 Paris car dealer″′;
CALL DBM ′ CATALOG DATABASE OMTLDB AS OMTLDB AT NODE WMTLDLR1 WITH ″OS/2 Montreal car dealer″′;
CALL DBM ′ CATALOG DATABASE ORIODB AS ORIODB AT NODE WRIODLR1 WITH ″OS/2 Rio car dealer″′;
CALL DBM ′ CATALOG DATABASE MNYCENT AS MNYCENT AT NODE WNYCENT WITH ″MVS New York central″′;
CALL DBM ′ CATALOG DATABASE VTORDB AS VTORDB AT NODE WTORDLR1 WITH ″VM Toronto car dealer 1″′;
CALL DBM ′ CATALOG DATABASE ASJDB AS ASJDB AT NODE WSJDLR1 WITH ″AS/400 San Jose car dealer 1″′;
SAY;
SAY ′ Catalog definitions ended′ ;
Figure 61. OS/2 DBM: REXX Procedure to Define Directory Entries. Listing of the REXX
procedure to define all directory entries for the DataHub/2 database clients.
RDB Name
In a DRDA network, an RDB is given a name that is used in the first part of a
three-part name (for example, DB2CENTDIST.PROD.STAFF). This name needs to
be used by the DRDA requester to identify the object it wants to use. Neither
OS/2 Database Manager nor DDCS/2 can be a server in a DRDA network. They
are always used as a requester to a DRDA server (DB2, SQL/DS, and AS/400).
That is why there are no RDB names to define in the OS/2 Database Manager
environment for DRDA connectivity.
But, as you will see in Chapter 5, “DataHub Tools Conversation Connectivity” on
page 151, the DataHub/2 and DataHub Support/2 products associate an RDB
name with each OS/2 Database Manager database that needs to be managed.
DataHub Support/2 uses the RDB name to connect to the local OS/2 DBM
database alias name.
DRDA or RDS Partners
To define the DRDA and RDS partners, the general steps you need to perform
are:
1. Catalog the workstation that will point to the OS/2 Communications Manager
definitions or the remote OS/2 Database Manager server workstation name.
2. Catalog the database in the system database directory.
3. Catalog the database in the database connection services (DCS) directory.
It is important to follow the steps in the exact order listed because it will help
you eliminate some definition problems (for example, typo errors). As Figure 46
on page 71 illustrates, there are many relationships between the OS/2
Chapter 3. DRDA Connectivity 87

Communications Manager and OS/2 Database Manager directory definitions. If
you are a beginner in OS/2 Database Manager, have this figure near you. We
are sure it will help you.
What follows are detailed steps for and further explanations of each directory
entry definition. To define directory entries using the OS/2 Database Manager
directory tools, these are the steps:
1. Start the directory tool program from the OS/2 Database Manager
application folder.
The Directory Tool window will appear.
2. Select Directory from the action menu.
The Directory pull-down menu will display (Figure 62). This menu has been
captured on the DataHub database server, which is also used as a DDCS/2
gateway. That is why all the different directories are selectable. The
minimum directory requirement for a DataHub/2 workstation is Workstation
and System Database. A standalone DataHub/2 workstation would require
that all four directories be selected unless there are no DRDA servers to
manage in the network, as in scenario 1.
Figure 62. OS/2 DBM: Directory Tool Window. This window is used to manage all the
OS/2 Database Manager directories.
The first directory entries you should create are the workstation definitions. The
system directory entries refer to the workstation definitions.
The steps are:
88 DataHub Implementation and Connectivity
1. Select the Directory action from the Directory Tool window action menu
(Figure 62).
2. Select the Workstation line from the Directory pull-down menu.
The Workstation Directory window will appear.
3. Select Workstation from the action menu.
The Workstation pull-down menu will appear.
4. Select Catalog... from the pull-down menu.

The Catalog Workstation window will appear (Figure 63 on page 89). On this
window, you will need to enter:
• A workstation name (alias) that will be referred to in the Catalog
Database window. In all our definitions, we used a W in front of the alias
name to make it easy for you to understand the relationship between the
parameter value.
• The protocol used for the connection. For DRDA connection, you always
choose APPN. For RDS connection, you could select either APPN or
NETBIOS. Figure 64 on page 90 shows our choices. For the RDS
connections, we used NETBIOS, which requires the server node name.
• If NETBIOS is selected, the server node name is required
• If the APPN (APPC) protocol is selected, you will need to enter or select
from the list box the:
− Network ID.Partner Logical Unit and the Partner Logical Unit Name
OR
Partner Logical Unit Alias
− Local Logical Unit Alias as shown in the Local node alias name field
on the Local Node Characteristics window (Figure 54 on page 80).
− Transmission Service Mode used for the APPC connection.
If you have completed all the OS/2 Communications Manager definitions, the
workstation definitions will be easy because you will be able to select from
the list box. Because the definitions have already been done, you will have
fewer problems to solve if something goes wrong.
Figure 63. OS/2 DBM: Catalog Workstation Window
Figure 64 on page 90 shows you all the definitions we used to interconnect
all DRDA and OS/2 Database Manager hosts. To get the workstation
directory list, use the following command from the OS/2 command line:
DBM LIST NODE DIRECTORY > C:\DBMWS.LST
Chapter 3. DRDA Connectivity 89

Node Directory
Number of entries in the directory = 6
Node 1 entry:
Workstation alias = WNYCENT
Comment = MVS New York Central
Comment code page = 850
Protocol = APPN
Network ID = USIBMSC
Local logical unit alias = ASJA2039
Partner logical unit = LUDB23
Transmission service mode = IBMRDB
Node 2 entry:
Workstation alias = WTORDLR1
Comment = VM Toronto car dealer 1
Comment code page = 850
Protocol = APPN
Network ID = USIBMSC
Local logical unit alias = ASJA2039
Partner logical unit = LUSQLVMA
Transmission service mode = IBMRDB
Node 3 entry:
Workstation alias = WSJDLR1
Comment = AS/400 San Jose car dealer 1
Comment code page = 850
Protocol = APPN
Network ID = USIBMSC
Local logical unit alias = ASJA2039
Partner logical unit = SJA2054I
Transmission service mode = IBMRDB
Node 4 entry:
Workstation alias = WMTLDLR1
Comment = OS/2 Montreal car dealer
Comment code page = 850
Protocol = NetBios
Adapter number = 0
Server NNAME = MTLDBM1
Node 5 entry:
Workstation alias = WPARDLR1
Comment = OS/2 Paris car dealer
Comment code page = 850
Protocol = NetBios
Adapter number = 0
Server NNAME = PARDBM1
Node 6 entry:
90 DataHub Implementation and Connectivity
Workstation alias = WRIODLR1
Comment = OS/2 Rio car dealer
Comment code page = 850
Protocol = NetBios
Adapter number = 0
Server NNAME = RIODBM1
Figure 64. OS/2 DBM: Workstation Directory List
5. Click on Catalog to save the workstation definition.
The Workstation Directory window should reappear with your new
workstation inserted in the list. You can close that window to free up the
Directory Tool window.

Now that the workstation definitions are complete, it is time to catalog the
databases using these steps:
1. Select Directory from the Directory Tool window action menu (Figure 62 on
page 88).
2. Select the System Database line from the Directory pull-down menu.
The System Database Directory window will appear with a list of all local and
remote databases that have already been defined.
3. Select Database from the action menu.
4. Select Catalog... from the Database pull-down menu.
The Catalog Database window will appear (Figure 65). On this window, you
will enter or select:
• The Alias name of the database. This name will be used by all
applications running on this workstation. If this workstation is a
database server, the requester will need to use that name as its
database name.
• The Database name. If this database is located on a DRDA server (for
example, DB2), the database name is the name of the local database in
the DCS Directory. If this database is located on an OS/2 Database
Manager server, enter the Alias name of the target database.
• Remote/Local database
Note: If you have multiple OS/2 Database Manager systems with the
same database name (for example, PERSONAL), you will need to define
a unique alias name for each of those systems. This alias will point to a
local database with the name of PERSONAL.
• If the database is remote, you will need to select the workstation on
which it is located from the list box.
Figure 65. OS/2 DBM: Catalog Database Window. This window is used to define the
System Database Directory.
Chapter 3. DRDA Connectivity 91

Figure 66 on page 92 shows you all the entries we used to define the
databases that the DataHub server could access. To get this list, use the
following command from the OS/2 command line:
DBM LIST DATABASE DIRECTORY > C:\DBMDIR.LST
System Database Directory
Number of entries in the directory = 8
Database 1 entry:
Database alias = MNYCENT
Database name = DCSMNYC
Database drive =
Database directory =
Workstation alias = WNYCENT
Database type = OS2 DBM VER. 3.00
Comment = MVS New York Central
Comment code page = 850
Directory entry type = Remote
Database 2 entry:
Database alias = VTORDB
Database name = DCSVTOR1
Database drive =
Database directory =
Workstation alias = WTORDLR1
Database type = OS2 DBM VER. 3.00
Comment = VM Toronto car dealer 1
Comment code page = 850
Directory entry type = Remote
Database 3 entry:
Database alias = ASJDB
Database name = DCSASJD1
Database drive =
Database directory =
Workstation alias = WSJDLR1
Database type = OS2 DBM VER. 3.00
Comment = AS/400 San Jose car dealer 1
Comment code page = 850
Directory entry type = Remote
Database 4 entry:
92 DataHub Implementation and Connectivity
Database alias = OMTLDB
Database name = OMTLDB
Database drive =
Database directory =
Workstation alias = WMTLDLR1
Database type = OS2 DBM VER. 3.00
Comment = DBM Montreal car dealer
Comment code page = 850
Directory entry type = Remote
Figure 66. (Part 1 of 2) OS/2 DBM: System Database Directory

Database 5 entry:
Database alias = OPARDB
Database name = OPARDB
Database drive =
Database directory =
Workstation alias = WPARDLR1
Database type = OS2 DBM VER. 3.00
Comment = DBM Paris car dealer
Comment code page = 850
Directory entry type = Remote
Database 6 entry:
Database alias = ORIODB
Database name = ORIODB
Database drive =
Database directory =
Workstation alias = WRIODLR1
Database type = OS2 DBM VER. 3.00
Comment = DBM Rio car dealer
Comment code page = 850
Directory entry type = Remote
Database 7 entry:
Database alias = EMQDB
Database name = EMQDB
Database drive = D:
Database directory =
Workstation alias =
Database type = OS2 DBM VER. 3.00
Comment = DataHub/2 Database
Comment code page = 850
Directory entry type = Indirect
Database 8 entry:
Database alias = DHDB
Database name = EMQDB
Database drive = D:
Database directory =
Workstation alias =
Database type = OS2 DBM VER. 3.00
Comment = Alias for database EMQDB
Comment code page = 850
Directory entry type = Indirect
Figure 67. (Part 2 of 2) OS/2 DBM: System Database Directory
5. In the Catalog Database window (Figure 65 on page 91) click on Catalog to
catalog the database.
The System Database Directory window will reappear. You can close that
window to free up the Directory Tool window.
Now, let′s finish the exercise by defining the Database Connection Services
(DCS) Directory.
1. Select the Directory action from the Directory Tool window action menu
(Figure 62 on page 88).
2. Select the Database Connection Services line from the Directory pull-down
menu.
The DCS Directory window will appear with the list of already defined DRDA
RDBMSs.
3. Select Database from the Directory Tool action menu.
Chapter 3. DRDA Connectivity 93

94 DataHub Implementation and Connectivity
4. Click on Catalog... from the Database pull-down menu.
You are now presented with the Catalog Database Window (Figure 68 on
page 95). This window has the same title as the window used to catalog a
System Database Directory, but it has different fields.
5. Select the local database you want to define from the list box window. The
list presented here contains all database names that have been defined as
REMOTE in the System Database Directory. Do not select OS/2 databases
because they do not support the DRDA protocol.
6. Enter the Target Database name. This is the RDB name of the target
database. This parameter is key to be able to connect to the target RDBMS.
7. You can enter the Application Requester name if it is different from the
default. You should not enter any value unless the DDCS/2 documentation
says you should.
8. Enter the parameters values. The field is composed of three values
separated by commas. The format is: ,,
Parms Definition/Value
Transaction program prefix (key connectivity parameter)
Default =X′ 07′
Recommendation
Do not define it.
Transaction program name (key connectivity parameter)
Default = 6DB
Recommendation
Define the TPN only for VM hosts. For a VM host, you need to
enter the TPN as indicated in section 3.5, “VM Definitions” on
page 51. See the Toronto car dealer DCS parameters value
(entry 2) in Figure 69 on page 96.
SQLCODE map file
This entry indicates which file contains the SQLCODE mapping
information. The name varies according to the DRDA host and
the OS/2 Database Manager version being used. Refer to the
Distributed Database Connection Services/2 Guide to know which
map file should be used for your environment.

Figure 68. OS/2 DBM: Catalog Database Window
Figure 69 on page 96 shows you all the entries we used to define the
databases that the DataHub server could access through the DRDA protocol
(DDCS/2). To get this list use the following command from the OS/2
command line:
DBM LIST DCS DIRECTORY > C:\DBMDCS.LST
Chapter 3. DRDA Connectivity 95

Database Connection Services (DCS) Directory
Number of entries in the directory = 3
DCS 1 entry:
Local database name = DCSMNYC
Target database name = DB2CENTDIST
Application requestor name =
DCS parameters = ,,C:\SQLLIB\DCS1DSN.MAP
Comment = DCS entry New York Central
Comment code page = 850
DCS directory release level = Ox0100
DCS 2 entry:
Local database name = DCSVTOR1
Target database name = SQLLDLR01
Application requestor name =
DCS parameters = ,SQLVMA,C:\SQLLIB\DCS1ARI.MAP
Comment = DCS entry Toronto Dealer 1
Comment code page = 850
DCS directory release level = Ox0100
DCS 3 entry:
96 DataHub Implementation and Connectivity
Local database name = DCSASJD1
Target database name = SJ400DLR1
Application requestor name =
DCS parameters = ,,C:\SQLLIB\DCS1QSQ.MAP
Comment = DCS entry San Jose dealer 1
Comment code page = 850
DCS directory release level = Ox0100
Figure 69. OS/2 DBM: DCS Directory List
9. Click on Catalog to catalog the new DCS entry.
The Database Connection Services Directory window will appear with the
new entry on it.
10. Now that all the catalog entries have been defined, you can close the
Directory Tool window. If you plan to test the connection, you should keep it
open in case of a problem.
OS/2 Database Manager Workstation Name
If you are using NETBIOS to connect to other OS/2 Database Manager servers,
you must know the workstation names that have been assigned to them during
installation. As you are now well aware, those names must be unique in the
network and they should conform to a certain nomenclature.
The workstation name can be changed any time after installation. But do not
change it after clients are accessing it. To get the actual definition, the following
tools could be used:
• Configuration Tool from the OS/2 Database Manager application folder

3.7.6 Binding Applications
• Command line processor.
Figure 70 is a listing of the OS/2 Database Manager command:
DBM GET DATABASE MANAGER CONFIGURATION > C:\DBMCONF.LST
Database Manager Configuration
Max requester I/O block size (RQRIOBLK) = 4096
Max server I/O block size (SVRIOBLK) = 4096
Max kernel segments (SQLENSEG) = 80
Max no. of active databases (NUMDB) = 8
Workstation name (NNAME) = DHSERVER
Communication heap size (COMHEAPSZ) = 16
Remote services heap size (RSHEAPSZ) = 16
Max remote connections (NUMRC) = 10
Workstation type = Server
Database Manager release level = Ox0300
Figure 70. OS/2 DBM: Listing of DataHub/2 Database Manager Server Configuration
You could use the same tools to modify the Workstation name. This is the
command that you will use to modify the Workstation name using the OS/2
Database Manager command line processor:
DBM UPDATE DATABASE MANAGER CONFIGURATION USING NNAME
You will need to stop OS/2 Database Manager before the change is made
effective.
Application programs can be executed after they are bound to a target database.
Before you start DataHub/2 definitions, we recommend that you verify the DRDA
and RDS connections. The interactive tool in the OS/2 environment is the
Command Line Processor. This utility can be bound to DB2/MVS, SQL/DS,
AS/400, and other OS/2 databases.
Binding to DRDA Hosts
To bind the OS/2 Database Manager utilities to DRDA hosts, execute the
following DDCS/2 command:
SQLJBIND
It is easier to execute the command from the SQLLIB directory; the command
would be SQLJBIND MNYCENT, for example.
Binding to OS/2 Database Manager Hosts
To bind the OS/2 Database Manager utilities to different versions of OS/2
Database Manager hosts, you will need to execute the following command from
the SQLLIB directory:
SQLBIND @SQLUBIND.LST /K=ALL
Chapter 3. DRDA Connectivity 97

3.7.7 Testing DRDA and RDS Connections
This section provides you with a list of commands you could execute to verify the
DRDA and RDS connections to a target host. The procedures documented in
Table 12 are valid from an OS/2 requester command line. The requester could
be a DataHub/2 workstation. Prerequisites are:
• DRDA and RDS connectivity established
• OS/2 Database Manager utilities bound to the target database.
The procedures in Table 12 use the database alias names as found in Figure 66
on page 92.
Table 12. Sample Verification Procedures. These procedures are based on an OS/2
Database Manager system accessing the different hosts using the Command Line
Processor.
Target Host Procedure
New York
Central
DB2
Toronto
Car Dealer 1
SQL/DS
San Jose
Car Dealer 1
AS/400
Rio de Janeiro
Car Dealer
OS/2
DBM START USING DATABASE MNYCENT
DBM SELECT * FROM SYSIBM.SYSTABLES
DBM STOP USING DATABASE
DBM START USING DATABASE VTORDB
DBM SELECT * FROM SYSTEM.SYSCATALOG
DBM STOP USING DATABASE
DBM START USING DATABASE ASJDB
DBM SELECT * FROM COLLECTION.SYSTABLES
DBM STOP USING DATABASE
Note: In AS/400 there is a table catalog for each collection.
Also, you need to create a NULLID collection to execute the
above statements.
DBM START USING DATABASE ORIODB
DBM SELECT * FROM SYSIBM.SYSTABLES
DBM STOP USING DATABASE
3.7.8 Managing OS/2 Database Manager Directories
98 DataHub Implementation and Connectivity
This section discusses the different procedures that could help you back up,
restore, and copy the different OS/2 Database Manager directories used in a
DRDA and DataHub environment.
But first, good management practice calls for documenting the environment.
Figure 71 on page 99 shows a sample REXX procedure that could be used to
print all the different OS/2 Database Manager configuration and directory entries
on a PS/2 printer assigned to the address LPT1. You could change the
procedure to route the output to a file.

* REXX command to print directory entries and DBM configuration */
′ CLS′;
SAY ′ Starting Printing of DBM directory and configurations′;
SAY;
′ CALL DBM LIST NODE DIRECTORY > LPT1′;
′ CALL DBM LIST DATABASE DIRECTORY > LPT1′;
′ CALL DBM LIST DCS DIRECTORY > LPT1′;
′ CALL DBM GET DATABASE MANAGER CONFIGURATION > LPT1′;
′ CALL DBM GET DATABASE CONFIGURATION FOR EMQDB > LPT1′;
SAY;
SAY ′ Lists printed′;
Figure 71. OS/2 DBM: REXX Procedure to Print OS/2 Database Manager Definitions
Backup and Restore
Because of the number of entries that could be required in the OS/2 Database
Manager directories (network of hundreds of OS/2 Database Manager
databases), we recommend that you back up those directories on all DataHub/2
workstations.
The OS/2 Database Manager recovery tool does not perform any backup or
recovery of the DBM directories. Figure 72 on page 100 and Figure 73 on
page 101 provide you with sample OS/2 REXX procedures to back up and
recover OS/2 Database Manager directories. Before using the procedures, make
sure you adapt them to your environment.
Chapter 3. DRDA Connectivity 99

100 DataHub Implementation and Connectivity
/* Procedure to backup the DBM directories */
sqllib = ′ C:\SQLLIB′;
backvol = ′ A′
CLS;
SAY;
SAY ′ Make sure you do have a diskette in drive ′ backvol;
PAUSE
SAY;
SAY ′ Creating the sub-directory on drive A:′
′ MKDIR ′ backvol′:\SQLNODIR′;
′ MKDIR ′ backvol′:\SQLGWDIR′;
′ MKDIR ′ backvol′:\SQLDBDIR′;
′ MKDIR ′ backvol′:\SQLDCDIR′;
′ MKDIR ′ backvol′:\SQLDDDIR′;
SAY;
SAY ′ Backup of the DBM directories′;
SAY;
SAY ′ Backup of the Workstation directory′;
′ COPY ′ sqllib′ \SQLNODIR\*.* ′ backvol′:\SQLNODIR′;
SAY;
SAY ′ Backup of the System directory′;
′ COPY ′ sqllib′ \SQLDBDIR\*.* ′ backvol′:\SQLDBDIR′;
SAY;
SAY ′ Backup of the DCS directory′;
′ COPY ′ sqllib′ \SQLGWDIR\*.* ′ backvol′:\SQLGWDIR′;
SAY;
SAY ′ Backup of the Volume C: directory′;
′ COPY C:\SQLDBDIR\*.* ′ backvol′:\SQLDCDIR′;
SAY;
SAY ′ Backup of the Volume D: directory′;
′ COPY D:\SQLDBDIR\*.* ′ backvol′:\SQLDDDIR′;
SAY;
SAY ′ Backup terminated on volume ′ backvol;
Figure 72. OS/2 DBM: REXX Procedure to Back Up the OS/2 Database Manager
Directories

* Procedure to recover the DBM directories */
sqllib = ′ C:\SQLLIB′;
backvol = ′ A′
CLS;
SAY;
SAY ′ Make sure you do have a diskette in drive ′ backvol;
PAUSE
SAY;
SAY ′ Recovery of the DBM directories′;
SAY;
SAY ′ Recovery of the Workstation directory′;
′ COPY ′ backvol′ \SQLNODIR\*.* ′ sqllib′:\SQLNODIR′;
SAY;
SAY ′ Recovery of the System directory′;
′ COPY ′ backvol′:\SQLDBDIR\*.* ′ sqllib′ \SQLDBDIR′;
SAY;
SAY ′ Recovery of the DCS directory′;
′ COPY ′ backvol′:\SQLGWDIR\*.*′ sqllib′ \SQLGWDIR′;
SAY;
SAY ′ Recovery of the Volume C: directory′;
′ COPY ′ backvol′:\SQLDCDIR\*.* C:\SQLDBDIR′;
SAY;
SAY ′ Recovery of the Volume D: directory′;
′ COPY ′ backvol′:\SQLDDDIR\*.* D:\SQLDBDIR′;
SAY;
SAY ′ Recovery terminated from volume ′ backvol;
Figure 73. OS/2 DBM: REXX Procedure to Recover the OS/2 Database Manager
Directories
Replicating the OS/2 Database Manager Database Directories
This section discusses the requirement of replicating the OS/2 Database
Manager directory entries from one DataHub/2 workstation to another.
Replication is required only when you want to add another DataHub/2
workstation. It could be used for either scenario 3 (DataHub database server) or
scenario 2 when you are adding a new stand-alone workstation.
One way to replicate data is to use the backup and recovery procedures
provided in the previous section. Before using the procedures, however, you
must ensure that the two workstations have the same set of local databases and
volume directories. The target system would need to recatalog the local
database if it does not exist in the source system.
Another way to replicate directory entries is to use a REXX procedure with OS/2
Database Manager CATALOG commands (see Figure 61 on page 87). To
replicate, you would need to execute the procedure on the target system.
Chapter 3. DRDA Connectivity 101

3.8 Adding a New DRDA Host
3.8.1 DRDA Client
102 DataHub Implementation and Connectivity
This section covers in general the steps required to add another RDBMS to an
existing DRDA network.
A new DRDA host means different things for different platforms. In the case of
DB2, it means adding a new set of address spaces. For SQL/DS, it means
adding a new SQL/DS server machine. For AS/400 you have only one RDBMS
per machine.
The steps required differ for platforms that can act as a DRDA client/server and
for those that can act only as a DRDA client. If a platform can act only as a
DRDA client, it only needs to know the DRDA servers. When a platform can act
as both a DRDA client and server, it needs to define itself (that is, define the
RDB name) and the other DRDA servers. In addition, the platform needs to be
known by the other DRDA partners (that is, clients and servers).
The OS/2 Database Manager and the newly announced DB2/6000 fall within the
DRDA-client-only category. The steps listed below are for the OS/2 platform, but
the ideas are applicable to the DB2/6000 platform as well.
The steps required to add a new OS/2 host are:
1. Install OS/2 Communications Manager and OS/2 Database Manager
2. Customize OS/2 Communications Manager
• Define the local node characteristics
• Define the standard mode name for DRDA and RDS connectivity
3. Customize OS/2 Database Manager
• Define the workstation name for NETBIOS connectivity
4. Define the remote RDBMS to which this system will connect
• Customize OS/2 Communications Manager
− Define the link (token-ring, SDLC, ...)
− Define the local control point (Network ID.Logical Unit)
− Define the partner LU (Network ID.Logical Unit)
• Customize OS/2 Database Manager
− Define the workstation alias (NETBIOS or APPN)
− Define the system database alias
− Define the DCS directory (RDB name) if the partner is a DRDA server
• Test the connection to the partners from the new OS/2 host
That is, CONNECT TO (DB2/2) or START USING DATABASE
(Database Manager component of Extended Services for
OS/2).
5. If this new OS/2 host is a new version of OS/2 Database Manager in the
network, you may want to bind the new OS/2 Database Manager utilities to
the different partners:

3.8.2 DRDA Client/Server
• If the partner is an OS/2 host, issue the following command:
SQLBIND @SQLUBIND.LST /K=ALL
• If the partner is a DRDA server, issue the following command:
SQLJBIND
• Test the bind operation by executing a simple SQL statement on each
partner.
6. If this new OS/2 host is accessed by another OS/2 system (for example, a
DataHub/2 workstation) with a different version of OS/2 Database Manager
installed:
• You may want to bind the OS/2 Database Manager utilities to the new
OS/2 host. Issue the following command from the other OS/2 hosts:
SQLBIND @SQLUBIND.LST /K=ALL .
• Test the bind operation by executing a simple SQL statement on this new
RDBMS.
Adding a new DRDA client/server in a network is a little more complex than
adding a new DRDA client. This new host could be a client to many other DRDA
hosts and a server to many DRDA clients including OS/2 and DB2/6000 hosts.
The steps required to add a new DRDA client/server host are:
1. Install and customize the host RDBMS
• Define the RDB name
• Define the local LU (for example, the VTAM Application ID)
2. Define the new RDBMS host to all other RDBMS hosts (if required)
• Define the new partner LU (Network ID.Logical Unit)
• Define the new RDB name in a local table (for example: OS/2 Database
Manager workstation, system and DCS directories)
• Test the connection to the new RDBMS (for example: CONNECT TO
(DB2/2)) or START USING DATABASE
(Database Manager component of Extended Services for OS/2)
• You may need to bind the different versions of utilities used in the actual
network to the new RDBMS. For example, you may need to bind
different versions of OS/2 Database Manager utilities.
3. Define the RDBMS hosts to which this new RDBMS host will connect:
• Define the partner LUs (Network ID.Logical Unit) (for example, DB2
SYSIBM.SYSLUNAMES)
• Define the RDB names in a local table (for example, DB2
SYSIBM.SYSLOCATIONS)
• Test the connection to the RDBMS (for example, CONNECT TO
(DB2))
• If this new RDBMS is a new version of an RDBMS in the DRDA network,
you may need to bind the new version to the partner RDBMS.
Chapter 3. DRDA Connectivity 103

3.9 Recommendations
Our recommendations concerning DRDA connectivity are as follows:
• Implement DataHub products only after your DRDA network is running
successfully.
• Define a nomenclature for:
104 DataHub Implementation and Connectivity
− RDB name
− OS/2 Database Manager workstation name (for NETBIOS connection)
− OS/2 Database Manager workstation alias name
− OS/2 Database Manager database alias name
− OS/2 Database Manager DCS database alias name
− OS/2 Communications Manager node alias name
− Logical unit name (if not done already).
• Implement the DataHub/2 workstation as a DRDA participant before installing
DataHub/2. This requires the installation of OS/2 Database Manager,
DDCS/2, and the APPC support of OS/2 Communications Manager.
• Perform regular backup of the OS/2 Communications Manager configuration
files.
• Perform regular backup of the OS/2 Database Manager directories.
• Put a copy command in the STARTUP.CMD file to copy the
C:\MUGLIB\ACCOUNTS\NET.ACC to another directory for backup purposes.

Chapter 4. DataHub/2 Workstation
This chapter covers the installation and configuration of the DataHub/2
workstation and its prerequisites for:
• Scenario 1: Local Management of Local Data
Scenario 1 has the least number of prerequisites and no installation
dependencies on other machines. We show the required products and the
installation sequence.
• Scenario 2: Central Management of Distributed Data
Scenario 2 is similar to scenario 1, with the addition of DDCS/2 for
cross-platform DRDA. The installation sequence is not dependent on the
other platforms.
• Scenario 3: Distributed Management of Distributed Data
Installation of DataHub/2 in scenario 3 requires a more complex operating
environment. We show:
− Installation environment preparation
− DataHub/2 requester installation
− Connectivity parameters for:
- LAN
- OS/2 Database Manager
- DataHub/2 database.
We also discuss LAN design considerations and explain how your design can
affect performance.
Depending on your requirements, prerequisite products can include some or all
of the following:
• OS/2 Communications Manager
• OS/2 Database Manager client
• OS/2 Database Manager server
• DDCS/2
• LAN requester
• LAN server.
For each scenario we show:
• The products required for each machine
• The installation procedure
• A process flow between products and machines
When appropriate, we present some configuration tricks or other items that may
not be obvious.
© Copyright IBM Corp. 1993 105

DataHub/2 Prerequisites: Installation Sequence
Install the required components in the following sequence for each machine
(you may not need all of these products in your environment):
• Base operating system
• OS/2 Communications Manager*
• LAPS*
• OS/2 Database Manager
• LAN server or requester
• CSDs or ServicePak.
4.1 Component Configuration
106 DataHub Implementation and Connectivity
*LAPS and OS/2 Communications Manager sequence. The latest version of
LAPS is packaged with NTS/2, a separate product. The NTS/2 product is
included in LAN Server Versions 2 and 3. OS/2 Communications Manager in
Extended Services for OS/2 provides a version of LAPS. Install LAPS from
NTS/2 after OS/2 Communications Manager if you use Extended Services for
OS/2. This ensures that the older version of LAPS is overlaid with the newer
version. Communications Manager/2 does not contain any LAPS function.
Install LAPS from NTS/2 before Communications Manager/2. You can now
install the latest or your current version of LAN server and finally, the correct
CSDs or ServicePak for your environment.
We now show how the OS/2 products link to the other OS/2 prerequisites and
how to define the links within each product. We end up with a stack of products,
with the prerequisite of a layer below the layer requiring it.
The top of the stack is the DataHub/2 application. The bottom is the physical
network. See Figure 74 on page 107. We omit the LAN server and requester
from the diagram because they only provide redirection for file access and do
not require direct links to the other products.

Figure 74. Major Connectivity Layers
We discuss below the parameters that link components and show how the entry
against a parameter at one level relates to the name of a parameter at another
level. Eventually we can create a network address.
What Is an Alias?
We use the term alias several times in the next few paragraphs. An alias is the
label for a list of definitions for local or external components. An alias is only
known within the local OS/2 system.
User Profile Management
Before a user even gets to DataHub/2, User Profile Management (UPM) verifies
the originator′s access to system resources. The local user ID is used to refer to
a set of user profiles on the DataHub/2 workstation. A profile is not necessary
but is used to facilitate logon to managed hosts. Refer to 7.1.1, “User Profile
Management” on page 241 for a detailed explanation of security. The password
Chapter 4. DataHub/2 Workstation 107

associated with the local UPM user ID is used to encrypt the passwords stored in
the DataHub/2 workstation profile. A local ID can have several profiles, so a
user can select different sets of management tasks for each entry into
DataHub/2.
The DataHub/2 Connect Request
DataHub/2 has a list of names representing the physical location of each
managed host. These names are aliases and are tied to a symbolic destination.
Symbolic destination definition is expanded in OS/2 Communications Manager.
Within a host alias, DataHub/2 lists the RDBs. The database name entry includes
reference to the database alias name as it is cataloged in OS/2 Database
Manager. The DataHub/2 definitions are stored in an OS/2 Database Manager
database owned by DataHub/2. So we have two links external to DataHub/2: the
symbolic destination and the database alias name.
OS/2 Database Manager Function
DataHub/2 uses a database to store definitions of hosts, RDBs, and their
symbolic destinations. Once the connection is made, DataHub/2 can extract
additional definitions from the RDB itself. The OS/2 Database Manager
directories have more work to do than DataHub/2 in creating the logical
connection to the remote database. OS/2 Database Manager uses the system
database and workstation directories to do this. If the RDB is not local, OS/2
Database Manager can use its own RDS component to connect to other OS/2
Database Managers or DDCS/2 to connect to other platforms.
System Database Directory: You also assign an alias for the name you want to
refer to the database in OS/2 Database Manager. A local application accessing
the database will connect to this alias. The system database directory also
contains the definition for the actual name of the database, as it is known by
OS/2 and, optionally, a workstation alias.
Workstation Directory: This term can be confusing because it does not define a
physical terminal but rather the name of a link from the database manager to a
communications connection. A database in the system database directory can
only have one workstation alias associated with it, but a workstation, being a
connection to another database manager, could be used to connect to several
databases on one database manager. The workstation directory has as many
entries as there are separate remote connections. If a database connection is
provided from a local application to another OS/2 database system, the
connection is made through the RDS component of OS/2 Database Manager.
The protocols used are:
• RDS
− NETBIOS or LU 6.2 protocols
• Cross-platform connections
− LU 6.2 only.
108 DataHub Implementation and Connectivity
DDCS/2 Connectivity Function
Definitions within DDCS/2 are straightforward. DDCS/2′s primary job is to
provide the DRDA function for the OS/2 Database Manager and cross-platform
consistency.
If the database to which you are trying to connect is on a different platform, enter
the name of the local database as defined in the local system database directory

and the name of the target database as defined at the remote site. DDCS/2 is
not used to access databases on other OS/2 platforms. OS/2 uses RDS for like
platforms.
OS/2 Communications Manager Function
OS/2 Communications Manager provides the logical connection between
applications and the adapters connected to the physical network. This includes
configuration of the application description and destination. All the data from the
configuration of the different components is funnelled through OS/2
Communications Manager and passes to the network adapter. When combined
with the protocol selection and signal generation provided by LAPS, the network
delivers a string of bits to the designated receiver.
LAPS Function
The NETBIOS definition requires you to enter the remote server′s node name
and is only supported within the LAN environment. APPC connections are
references within the workstation directory to entries in the local OS/2
Communications Manager. If your environment uses SDLC or X.25 as a physical
network, you must replace the LAPS component of our samples with the
appropriate configuration and drivers. The majority of the definitions in all the
layers above do not change. Any changes will be driven by compatibility
requirements with the receiving application′s network.
Application Server
The reverse process occurs at the receiver. When the receiver recognizes its
network address in the string of bits in the network adapter, it passes the
message up through a parallel set of layers. Requests are directed through the
communications protocols and are presented to the application servers. We
have now connected to the remote application.
Chapter 4. DataHub/2 Workstation 109

4.2 Scenario 1: Local Management of Local Data
4.2.1 Required Products
You have an OS/2 database and would like to run a pilot using DataHub/2. You
can use DataHub/2 to copy tables from the managed host, perform utilities, and
manage authorizations. The DataHub/2 workstation, the managed host, and the
target of copy functions are on different machines. See Figure 75.
Figure 75. Scenario 1: Local Management of Local Data
The minimum required levels and versions of products are listed below. For
instance, where the list shows OS/2 Database Manager, DB2/2 could be installed
instead.
DataHub/2 Workstation
• OS/2 version 2.0
• OS/2 Communications Manager and OS/2 Database Manager client
• LAPS
• DataHub/2
110 DataHub Implementation and Connectivity

Managed Host (Source Data)
• OS/2 version 2.0
• OS/2 Communications Manager and OS/2 Database Manager server
• LAPS
Target
• OS/2 version 2.0
• OS/2 Communications Manager and OS/2 Database Manager server and
client
• LAPS
• DataHub Support/2
4.2.2 Installation Procedure and Configuration
4.2.3 Process Flow
This is the simplest DataHub scenario to install. The products install on each
machine with no dependency on the install status of the other machines.
Obviously all installations must be complete before DataHub executes.
The DataHub/2 programs, files, messages, and designated database (DDB) are
local to the DataHub/2 workstation. We can use all of the DataHub/2 tools
features to manage the host. We manage the host by using it as a source only.
We cannot use the host as a target for any copy function because DataHub
Support/2 is not installed on the source machine. DataHub Support/2 is installed
on the target machine. DataHub/2 connects to DataHub Support/2 using LU 6.2
tools conversations. DataHub Support/2 accesses the local OS/2 Database
Manager, which then uses RDS to connect to the OS/2 Database Manager on the
managed host.
The DataHub/2 workstation must be at least an OS/2 Database Manager client.
We do not need it to be a database server in this scenario. DataHub/2 is
installed as a server for stand-alone operation. We install both the platform and
tools features, with access to the DataHub/2 database.
The target machine must have OS/2 Database Manager installed as both a
server, to talk to the DataHub/2 workstation, and a client, to talk to the managed
host.
The managed host must be a OS/2 Database Manager server to receive RDS
requests from the target and the DataHub/2 workstation. We do not need client
function.
See 1.2, “DataHub Data Flows: Overview” on page 6 for a more detailed
presentation of flows for each DataHub function.
Let′s assume we want to use DataHub/2 to copy the sample database tables
from the host to the target. The database directory entries for each machine are
shown in Figure 76 on page 112. This is the flow:
• DataHub/2 reads the catalog data from the host and the target to verify that
the objects exist at the source and do not exist at the target. RDS is used to
connect to both host and target machines.
Chapter 4. DataHub/2 Workstation 111

112 DataHub Implementation and Connectivity
• DataHub/2 then generates the DDL for these tables and creates the objects
on the target using RDS if the objects do not already exist.
• DataHub/2 on the DataHub/2 workstation sends the copy request to DataHub
Support/2 on the target. This is a tools conversation flow, and therefore the
protocol used is LU 6.2, configured for the symbolic destination of the target
database.
• DataHub Support/2 then sends an SQL select statement to the local OS/2
Database Manager, which uses RDS to connect to the host. This is not a
DataHub specific flow, just standard RDS to the OS/2 Database Manager on
the host.
• OS/2 Database Manager on the host runs the select statement and sends the
result back to the target using RDS.
• DataHub Support/2 receives the result of the select statement and inserts the
rows into the local table. A completion code is returned to DataHub/2 at the
DataHub/2 workstation.
Figure 76. Scenario 1: Database Catalogs and RDB Name Map File
DataHub/2 Workstation
This DataHub/2 workstation configuration shows the simplicity of cataloging the
databases and configuring DataHub/2.
OS/2 Database Manager: There is no difference in the cataloging of the remote
databases just because they are used by DataHub/2. The local aliases relate to
workstation names that link to the remote machines using RDS. Both remote
database managers must be installed as servers.

DataHub/2: The configuration lists two RDBs: DBMMTLDLR1 and DBMRIODLR1.
The database names are added to the definitions within the RDB and relate to
local database aliases in the OS/2 Database Manager catalog.
Target
You configure the local OS/2 Database Manager and DataHub Support/2 on this
machine.
OS/2 Database Manager: Standard catalog procedure applies. One database is
local and one is remote on the managed host.
DataHub Support/2: The only item we discuss in this installation is the DataHub
Support/2 map file.
There is no configuration pull-down menu for DataHub Support/2. There is also
no such thing as an RDB in OS/2 Database Manager as there is on the other
database managers. OS/2 uses an alias as the application′s label for the
database. If the alias name of the DataHub Support/2 host′s database matches
the RDB name of the DataHub/2 workstation, a map file is not necessary. If the
names are different, a map file is required, but only on the DataHub Support/2
machine. The map file relates an RDB name on the DataHub/2 workstation to an
OS/2 Database Manager alias on the DataHub Support/2 machine. This ensures
compatibility among the database managers, DataHub/2, DataHub Support/2, and
DataHub Support on all platforms.
DataHub Support/2 RDB Name Map File
The map file is a flat ASCII file with one entry for each RDB and local alias
pair.
• Path to the map file
− The OS/2 CONFIG.SYS file points to DataHub Support/2 configuration
by using system variable EMQ2SYS.
− The file named in EMQ2SYS has DataHub keyword records, one being
RDBNAMEMAP.
− RDBNAMEMAP lists the filename of the map.
• Map file contents
− Column 1 of the map file contains the RDB name (18 characters
maximum).
− Column 20 contains the local alias name (8 characters maximum).
We now have a link from the DataHub/2 RDB name to a local alias at DataHub
Support/2. The local alias defines an entry in the workstation directory that links
to the remote database, Sample, on the managed host.
Managed Host
DataHub/2 has no impact on this machine′s configuration. It is set up as an
OS/2 Database Manager server.
Chapter 4. DataHub/2 Workstation 113

4.3 Scenario 2: Central Management of Distributed Data
4.3.1 Required Products
Scenario 2 is similar to scenario 1, with the addition of hosts other than OS/2.
See Figure 77. The OS/2 target machine shown in scenario 1 is removed
because the AS/400, MVS, and VM hosts participate as both source and target
machines for OS/2 and each other. In other words, the target machine of
scenario 1 can be a target for the non-OS/2 hosts and a source. We must install
DDCS/2 to provide DRDA connectivity to hosts on non-OS/2 systems. The
multiuser version of DDCS/2 requires OS/2 Database Manager to be installed as
a server. Single-user DDCS/2 can operate using either stand-alone or server
versions of OS/2 Database Manager.
Figure 77. Scenario 2: Central Management of Distributed Data
Our discussion is limited to the installation of OS/2 components, not the OS/400,
MVS, or VM components required for this scenario.
DataHub/2 Workstation
• OS/2 version 2.0
• OS/2 Communications Manager and OS/2 Database Manager client
• LAPS
• DDCS/2 single-user version
• DataHub/2
114 DataHub Implementation and Connectivity

Managed OS/2 Host
• OS/2 version 2.0
• OS/2 Communications Manager and OS/2 Database Manager server and
client
• DDCS/2 if source or target of cross-platform function
• LAPS
• DataHub Support/2
4.3.2 Installation Procedure and Configuration
4.3.3 Process Flow
The OS/2 component installation is the same as in scenario 1, with the addition
of DDCS/2.
OS/2 Database Manager catalogs are similar to those in scenario 1. A map file
is still required if the RDB and alias names on the DataHub Support/2 host are
different. The change in this scenario is the addition of cross-platform DRDA.
RDS took care of access to remote databases in scenario 1. We add DDCS/2 to
one of the OS/2 systems to provide this connectivity. DDCS/2 provides the
DRDA flow plus the Database Connection Services directory to relate the local
database alias to a remote non-OS/2 RDB name. Figure 78 shows our DCS
directory for the three non-OS/2 hosts.
Figure 78. Database Connection Services Directory
We use the same function, copy table, as in scenario 1, except that the source
and target machines are on different platforms:
• DataHub/2 at the DataHub/2 workstation checks the database catalogs at the
source and target machines. The flow to the OS/2 target is RDS. DDCS/2
provides the DRDA link to the non-OS/2 host.
Chapter 4. DataHub/2 Workstation 115

116 DataHub Implementation and Connectivity
• DataHub/2 then issues the command to copy the table. The command is
passed to the DataHub Support/2 target host using a tools conversation, LU
6.2.
• DataHub Support/2 receives the request, resolves the target RDB name
using the map file if necessary, and passes the select statement to the
source host through DDCS/2. In our case DDCS/2 is local on the target
machine. It could also be on another machine.
• DDCS/2 establishes the DRDA link to the remote RDBMS using LU 6.2.
• DataHub Support/2 on the target host then receives the data through the
DRDA link and inserts the data into the local tables.
• DataHub Support/2 on the target host then forwards a completion code to the
requesting DataHub/2.

4.4 Scenario 3: Distributed Management of Distributed Data
When you implement DataHub as we do in this scenario (see Figure 79), you
increase the number of products required. You also change the configuration of
some of the components in the other scenarios, such as LAN links and
connections to the server′s databases. We therefore present more sections with
more details for this scenario. The sections are:
• Required Products
• DataHub/2 Execution: Data Requirements
• Installation Environment Preparation
• DataHub/2 Workstation Installation as a Requester
• LAN Connectivity Parameters
• OS/2 Database Manager Connectivity Parameters
• DataHub/2 Database Connectivity Parameters.
Figure 79. Scenario 3: Distributed Management of Distributed Data
Normally you install a DataHub/2 workstation with local program code, data, and
designated database. But if you need several DataHub/2 workstations, why
duplicate all the files, databases, and catalogs? The OS/2 LAN server and OS/2
Database Manager RDS can provide access to the data DataHub/2 needs to
operate as a DataHub/2 workstation.
To scenario 2 we add centralized DataHub/2 program code on a LAN server.
The server is also a DataHub/2 workstation and provides a central DataHub/2
database. DataHub/2 workstations not on the server are DataHub/2 requesters.
Chapter 4. DataHub/2 Workstation 117

4.4.1 Required Products
Install the products listed below on each machine. Note that you must provide
the proper LAN requester, server, and OS/2 Database Manager connections
before you begin the DataHub/2 workstation installation.
DataHub/2 Workstations (Requesters)
• OS/2 version 2.0
• OS/2 Communications Manager and OS/2 Database Manager client
• LAPS
• LAN requester
• DataHub/2 requester
Managed OS/2 Host
In scenario 3, the OS/2 managed host also contains the central DataHub/2
database and all the code and files to be shared with the requesters. We can
also use the machine as a DataHub/2 workstation.
• OS/2 version 2.0
• OS/2 Communications Manager and OS/2 Database Manager client and
server
• DDCS/2
• DataHub/2
• DataHub Support/2
• LAPS
• LAN Server
4.4.2 DataHub/2 Execution: Data Requirements
Let′s set the stage by showing how DataHub/2 operates as a requester.
DataHub/2 executes using one database and five types of files. The database
contains the configuration of the managed hosts, including host name, symbolic
destination name, and database alias name.
The files are:
118 DataHub Implementation and Connectivity
• Data files. Installation history, configuration, and the name of the DataHub/2
database.
• Executable files. Programs for the various functions.
• Dynamic link library. Code and resources that can be loaded for execution.
• Help files. Press F1 to see contextual help during configuration or execution.
• Include files. Header and import libraries used by tool builders and the
sample tool included with the tools feature.
The database and any of these files can be local or on a server. The
combinations may seem endless, but several options are realistic, as described
below.

DataHub/2 Database Placement
A central database provides consistent definitions to all DataHub/2 workstations.
An administrator who needs unique access may want a local database, or a test
and development department may want to be independent of central control. A
requester may even have databases in different locations for different instances
of DataHub/2 on one machine. This would be two logical DataHub/2
workstations. If your administrators manage the same hosts, you are a good
candidate for one central DataHub/2 database. See Section 4.5, “LAN Design
Considerations” on page 144 for more details on database placement.
File Placement
You can use the same decision process for file placement, with the following
additional information: Data files are updated by each DataHub/2 process. This
includes the log file, EMQCELOG.0n0, where n is a number representing the
instance of DataHub/2 that created the log. A central log may be more difficult
to use for problem determination if there are several DataHub/2 workstations
because there is no userid associated with a log. But a local log may be more
difficult for the central administrator to access. You could have the best of both
situations by having the user′s local data files on the LAN server. Files would
then be associated with the user and accessible by the LAN administrator.
You probably want to store one copy of the DLLs and help files centrally. If you
want your administrators to develop their own tools and utilities, you could make
these files local to each DataHub/2 workstation.
Now that we know how DataHub/2 accesses the data we can understand what
we must do to make the files and database available before we install
DataHub/2.
4.4.3 Installation Environment Preparation
The install process either creates a new DataHub/2 database, uses an existing
local DataHub/2 database, or uses an existing cataloged remote database. The
first two options simplify the prerequisites needed to install a DataHub/2
requester. If you want to use a central database on the server, you must have
access to it before you start to install a DataHub/2 requester because the
installation checks to see whether the database selected is in fact a DataHub/2
database. This is true for the files also, because the install process updates
some of the files on the server. For our purposes in this scenario, we assume
that the DataHub/2 code installed on the DataHub/2 workstation in scenario 2
becomes our DataHub/2 server. We show the steps you must complete to install
a DataHub/2 requester that has data files on the local drive and common
DataHub/2 files and the DataHub/2 database at the server.
DataHub/2 Server
LAN Server Administration Simplified: The LAN server provides resource
sharing to the LAN requesters. Resources in our scenarios are files or printers.
The LAN administrator gives each resource an alias name. An access profile is
then defined for each alias, and users are given access to the resource. We
highly recommend that you define groups of users and give resource access to
groups rather than individual users. In this way you can just add a user to a
previously defined group, and the user has all accesses, with very little effort on
the part of the administrator.
Chapter 4. DataHub/2 Workstation 119

LAN Server Access Profile Tip
Versions of the LAN server over the years have changed the defaults for
access. Early version defaults gave access to everything for all users.
Newer version defaults are not as generous. Access must be defined, or a
user does not get to a resource. This applies to subdirectories. If you
organize your server so that DLLs and files are in subdirectories, you must
use the APPLY function within the access profile definition menu. This gives
users access to data in subdirectory levels below the directory that the
access profile defines.
On the LAN server you define aliases, define access profiles, and grant users
access, as follows:
1. LAN server must be running during requester install.
2. Define an alias for the directory on the server where the DataHub/2 shared
files reside. (The EMQDIR directory is the default.) We used the alias
DATAHUB and assigned drive H.
3. Define access profiles for the alias.
We used access type XR, to give DataHub/2 LAN requesters execute and
read access to the central files. The requesters cannot delete the DataHub/2
system files with this restricted access. If the user′s log and error files are
on the server, access must be RCD (read, create, and delete) for the
directory that contains the user′s files.
4. Add userids to LAN server UPM for requesters.
5. Assign logon assignments for users. We recommend groups if there are
several users.
OS/2 Database Manager: The DataHub/2 database on the DataHub/2 server
must be available to the DataHub/2 requester during the requester installation
process. OS/2 Database Manager on the server provides this access through
RDS. OS/2 Database Manager must be running as a server, and access to the
DataHub/2 database tables must be granted for the new requesters. To grant
access use the sample command file, EMQGRANT.CMD, provided in the
executable files directory by the install procedure. To use it, enter: EMQGRANT
database_name user_type userid_list, where the parameters are:
• database_name is the name of the DataHub/2 database
• user_type is
− USER a DataHub/2 user with no additional authority
− ADMIN a DataHub/2 user with authority to grant, install tools, and
customize functions.
DataHub/2 Requester
You must complete the following steps at the requester before you start to install
DataHub/2:
1. Start LAN requester.
2. Sign on to domain.
120 DataHub Implementation and Connectivity
3. Start OS/2 Database Manager.
4. Catalog the remote DataHub/2 database

• System database directory
• Workstation directory
− NETBIOS server node name
or
− APPC LU and PLU definitions.
5. Stop and start OS/2 Database Manager to activate the changes.
Figure 80 shows the requester′s directories for the central DataHub/2 database
stored on the server. The installer on the requester machine must have DBADM
authority to use the DataHub/2 database on another workstation. DHDB is the
alias and the local database name on the requester. The workstation directory
defines the NETBIOS link from the local database to the OS/2 Database Manager
node name, DHSERVER, which is the managed host and LAN server.
Figure 80. OS/2 Database Manager Directories
You now have access to the files and DataHub/2 database on the server.
4.4.4 DataHub/2 Workstation Installation as a Requester
To install DataHub/2 as a requester:
1. Log on locally (Logon /l).
2. Insert DataHub/2 diskette 1
Only one diskette, the Platform diskette, is needed for a requester
installation. The remainder of the code is already installed on the server.
3. Type A:Install.
Figure 81 on page 122 through Figure 89 on page 127 show the installation
screens and how to access files on the server.
Figure 81 on page 122 shows the first screen you see after the installation
Logo. We store the code on the server, so we only use the platform feature.
Chapter 4. DataHub/2 Workstation 121

Figure 81. DH/2 Install: Feature Select
122 DataHub Implementation and Connectivity
4. Click on Platform Feature and the Continue push button.
Figure 82. DH/2 Install: Installation Type
5. Click on Requester Installation and the Continue push button. The server
option is for stand-alone or server installations. The Target Directories
screen (Figure 83 on page 123) will display.

Figure 83. DH/2 Install: Target Directories
The screen in Figure 83 shows how to define the target directories for local
data files with all common files on the server. Note that these files are
accessed and verified during the install, so you must have the LAN requester
and server active and the requester logged on. In our case we assigned the
common files at the server to a user′s H: disk. This disk is really the
EMQDIR on the server′s C: disk. We used subdirectories for each file type in
our installation, but this is not necessary. (If you use subdirectories, do not
forget to APPLY the access profiles in LAN server to the subdirectories.) We
recommend that you leave all files in the EMQDIR directory.
6. Update the files entries for your configuration. Click on the Continue push
button to get to the Update Configuration screen (Figure 84 on page 124)
where you can change the default for the DataHub/2 environment variable.
This variable points to the directory where the DataHub/2 data files are
stored.
Chapter 4. DataHub/2 Workstation 123

124 DataHub Implementation and Connectivity
Figure 84. DH/2 Install: Update Configuration
On the DataHub/2 Database Name screen (Figure 85 on page 125) you enter
the local alias for the DataHub/2 database. In our case this points to the
server through the OS/2 Database Manager directories. Note that the install
procedure accesses the database to ensure it is valid. Therefore we need to
have OS/2 Database Manager running both locally and at the server, with
the database cataloged and present on the server.
7. Click on the Continue push button to enter the alias and see the next screen.

Figure 85. DH/2 Install: DataHub/2 Database Name
The remaining screens are straightforward and do not require further
explanation.
Figure 86. DH/2 Install: Delimiter Characters for Commands
Chapter 4. DataHub/2 Workstation 125

126 DataHub Implementation and Connectivity
Figure 87. DH/2 Install: LAN Workstation Identification
Figure 88. DH/2 Install: Add Program to Desktop

Figure 89. DH/2 Install: Installation Confirmation
4.4.5 LAN Connectivity Parameters
8. Reboot your requester workstation to activate the CONFIG.SYS file changes.
9. You can now click on the DataHub/2 icon to start configuring the DataHub/2
workstation.
This section introduces the terminology for the configurable LAN components
that are internal to each machine in your network. You can configure most of
these components to suit the size and function of your machines. Defaults satisfy
most operating conditions. For instance, if a LAN requester attempts to log on to
a server, and the server is not active, the requester′s network drivers wait a
certain amount of time and retry. The application is notified that the server is
not responding after all the retries fail. You do not normally adjust the wait time
or retry count. You should, however, adjust the number of requesters a server
can support if your network is larger than the defaults can handle. Servers can
theoretically handle over 1000 requesters, but the response time at any
requester could be unpredictable.
LAPS defines and configures all NETBIOS and 802.2 resources. LAPS places the
definitions in the PROTOCOL.INI file, which is read when the device drivers are
loaded.
Chapter 4. DataHub/2 Workstation 127

Tuning versus Execution
128 DataHub Implementation and Connectivity
The discussion that follows is not presented as an exhaustive reference for
LAN tuning purposes. It is meant to introduce you to the LAN parameters
terminology and to give you a basic understanding of the interrelationships
among parameters. Once you have this information, you can determine the
demands your environment places on the resources and adjust the
parameters to make DataHub/2 work. If you increase the value of a
parameter more than necessary, two things can happen:
• You get a configuration error message that tells you to lower the
parameter or raise another so it fits.
• Performance may suffer because another resource has been reduced
dynamically to make yours fit.
Refer to the Parmtune guide in the IBM marketing tools repository if you want
to tune all OS/2 components for maximum performance.
The LAN adapter card provides the physical connection for all local applications
to applications running on other machines on the network. If more than one
application is communicating, the target of the conversations may be different.
Therefore the adapter has to provide links to more than one address. The
protocols of the conversations may also be different. The access or
programming interface for each application to the communications software
could be different. Figure 90 on page 129 represents the layers required to
provide several applications with access to several targets using several
protocols. A server machine has to satisfy more requests for connectivity than a
single requester.
We show the resources needed for a DataHub/2 workstation and server in
scenario 3.
Figure 90 on page 129 shows how an application request from the DataHub/2
workstation flows through the configurable components to a server application.
The return flow is the same. In our case the applications can be LAN requester,
OS/2 Database Manager, and DataHub/2. Normally the flow is specific to a
request, but changes to RDS and NETBIOS in recent releases have improved
performance because the protocols allow conversations at lower level interfaces.
The flow is therefore dependent on which level of code you run.
DataHub/2 Workstation
LAN Requester: LAN requester always uses NETBIOS (flow 1). Before the
current version of LAPS, NETBIOS used a SAP, F0 to access the network (flow 3).
The NETBIOS version in LAPS uses a direct interface to 802.2 (flow 2), and so
fewer SAPs need to be defined.
(A SAP is a service access point for an application to gain access to a network.
Each protocol is given a specific SAP access number. If the connection uses a
SAP, the SAP number is appended to the source and destination addresses.
Newer versions of some device drivers bypass the SAP layer.)

Figure 90. LAN Configurable Resources
OS/2 Database Manager: The client function of OS/2 Database Manager on our
requester uses RDS (flow 6) to access the database on the server. Refer also to
Figure 104 on page 143 and Figure 105 on page 143 for definitions within OS/2
Database Manager for the connection configuration.
RDS: RDS can use either NETBIOS or LU 6.2 to connect to the network. If you
select NETBIOS (flow 4), you end up in flow 2 or flow 3, depending on the
NETBIOS version. This uses up another NETBIOS name and another session. It
may require another link. We explain each account in more detail below. If RDS
uses LU 6.2, a private SAP (SAP 84, flow 5) is used up as is another 802.2 user.
DataHub/2: DataHub/2 uses both LU 6.2 (flow 8) for the tools conversations, and
the API to OS/2 Database Manager (flow 7) to access the catalogs. Flow 8 uses
the SNA SAP 04. Flow 7 ends up connecting through flow 6 to RDS.
Chapter 4. DataHub/2 Workstation 129

NETBIOS: DataHub/2 flat files and executable code can be accessed by the
DataHub/2 workstation using LAN Requester, which uses NETBIOS protocol.
A link is established when the requester calls the server using the server′s
NETBIOS node name. A session is set up when the requester asks for data. We
have just used up part of three different configurable resources: one NETBIOS
name, one session, and one link station.
802.2: The DataHub/2 connection to the DataHub/2 server is provided by APPC,
which uses LU 6.2 sessions. LU 6.2 is part of SNA, which uses SAP 04. Now we
have used up more resources: a SAP, an 802.2 user, another link station, and
one or more LU 6.2 sessions. The LU 6.2 sessions are configured in OS/2
Communications Manager. NETBIOS is also an 802.2 user and may or may not
use a SAP. The NETBIOS link station is provided by 802.2.
We have now connected all the DataHub/2 workstation applications to the
network.
SAPs, Users, Link Stations, NCBs, Names, and Sessions
When we define resources, we reserve either main or network adapter memory.
The adapter has a fixed amount of memory and therefore the number of
resources you can define is limited. For instance, one adapter can support 254
users or sessions. This is a theoretical limit based on addressability and would
probably never be attained.
LAN Resource Configuration Roadmap
Table 13 shows the LAN resources, where they are stored, and how to configure
or update the parameters.
Table 13. LAN Resources
Location Resource Update from
IBMCOMProtocol.INI
Netbeui_nif
Landd_nif
IBMLANIBMLAN.INI
Line beginning NET1,
last 3 numbers
• 802.2 resources
− SAPs
You can see that depending on how you have configured RDS and which
level of NETBIOS you use, you can run DataHub/2 with from one to three
SAPs defined.
− Users
130 DataHub Implementation and Connectivity
NETBIOS sessions
NCBs, names
802.2 link stations
SAPs, users
Reserved by
requester/server
LAPS or system editor
LAPS or system editor
NCBs, sessions, names System editor only
Each SAP becomes an 802.2 user, as does NETBIOS if it does not use a
SAP, so if we have three SAPs plus NETBIOS, we need four 802.2 users.

− Link stations
We could have several applications connected to either NETBIOS or a
SAP, but each connection from a local application to another remote
application uses a link station. For instance, a LAN server machine,
which also provides 3270 gateway function, needs a link station for each
LAN requester, plus another for each downstream 3270 user. These link
stations within the server would connect to one NETBIOS name for the
server, and one SNA SAP. So 20 workstations accessing two
applications at the server create a need for 40 link stations at the server,
and two SAPs if the server applications use SAPs.
• NETBIOS resources
− Network control blocks (NCBs)
The conversation between applications through the network requires
several stages to initiate, wait for response, keep track of addresses,
pass requests, receive results, check status, and other housekeeping
chores. NCBs within NETBIOS handle these low level jobs. There are
more NCBs than there are other NETBIOS resources. OS/2 Database
Manager reserves a high number of NCBs, as does the LAN requester or
server. Refer to Table 15 on page 132 and Figure 102 on page 142.
These reservations plus any additional requirements for other local
applications using NETBIOS must be put in the PROTOCOL.INI NCB.
− Names
Each reference by an application through NETBIOS to another application
requires a NETBIOS name. The local LAN requester needs to withdraw
one name from the NETBIOS Names account to connect to the LAN
server and another name to register the local NETBIOS name. Similarly
if RDS uses NETBIOS to reach out and touch the database server, it uses
up another name for the remote node name. In our example above with
20 requesters, the server must be able to allocate 20 NETBIOS names to
talk to 20 requesters if they are all active.
− Sessions
The logical link between applications is handled by a session. Several
sessions can share a link station if the applications on one end of the
link communicate with other applications at the same destination.
DataHub/2 Server
All connections from the network to the server applications are the same as the
DataHub/2 workstation. We used different levels of OS/2 and OS/2 Database
Manager on our requester and server. This means that the levels of software
and device drivers do not have to be the same across your environment.
OS/2 Database Manager Reserved Resources: The server needs more
resources to connect to several requesters than a requester needs to connect to
one server. Some of these resources are user defined and some are fixed by
the application. Refer to Table 14 on page 132 for minimum configuration
values for sessions.
Chapter 4. DataHub/2 Workstation 131

Table 14. NETBIOS Session Information for DB2/2
DB2/2
Workstation
Type
SQLNETB
Default
DB2/2 Overhead
Maximum
Number of
Concurrent
Sessions Using
Default
SQLNETB
Server 64 5 59
Client 16 3 13
The number of sessions reserved for OS/2 Database Manager is defined in
environment variable SQLNETB. You can change this value in the CONFIG.SYS
file if your requirements are different from the defaults. Table 15 shows the
NCBs and NETBIOS names reserved by DB2/2. The NETBIOS NCBs and names
values cannot be changed. You must configure sufficient resources in LAPS to
satisfy both OS/2 Database Manager and LAN server or requester demands.
Table 15. DB2/2 NETBIOS Resource Requirements
DB2/2 Workstation
Type
132 DataHub Implementation and Connectivity
Commands (NCBs) Names
Server 46 4
Client 24 2
LAN Requester and Server Reserved Resources: Normally the LAN requester or
server program is invoked during startup of a machine. The configuration of
requester or server functions is specified in the IBMLAN.INI file. The line
beginning Net1 specifies how many LAN resources to reserve. Refer to
Figure 102 on page 142. Reservation is made for NCBs, sessions, and NETBIOS
names. If the number of parameters defined in LAPS for these resources is only
enough for requester or server function, subsequent requests by applications for
additional resources or RDS links will fail.
LAPS Configuration Samples
Figure 91 on page 133 through Figure 102 on page 142 show the screens you
use to configure the stations, sessions, names, SAPs, commands, and users that
the network needs to provide connections. We show the details of the
configuration for both a DataHub/2 workstation and a DataHub/2 server. Our
server is configured for seven DataHub/2 workstations. LAPS installs itself in the
IBMCOM directory. Figure 91 on page 133 and Figure 92 on page 133 get you
started.

Figure 91. LAPS: Select an Option
Click on Configure to see the next screen.
Figure 92. LAPS: Migrate or Configure
Click on Configure LAN transports and the Continue push button to see the next
screen.
Chapter 4. DataHub/2 Workstation 133

Figure 93. LAPS: Configure Workstation
134 DataHub Implementation and Connectivity
Figure 93 shows adapter and protocol selection menus. Scroll down under
Network Adapters until you see the adapter installed in the machine you want to
configure. Note that you can configure LAPS on a machine and use the
configuration on another machine. Click on the adapter and the Add push button
in the Network Adapters dialog box. Then click on the IBM Token-Ring Network
Adapters and select IBM IEEE 802.2. Click on IBM IEEE 802.2 and the Add push
button in the Protocols dialog box. Now you are ready to edit the parameters for
802.2. To edit the parameters for NETBIOS, repeat the process you used for
802.2.

Figure 94 shows the 802.2 protocol parameter edit screen for the DataHub/2
workstation. We highlight the stations, SAPs, and user fields. You can use the
defaults for a requester. You use up memory if you increase any of the
parameters, so you should not use more resources than necessary.
Figure 94. LAPS: Parameters for IBM IEEE 802.2, DataHub/2 Workstation
The IBM marketing tools repository has an OS/2 tuning guide that is available to
you from your marketing representative or systems engineer. The guide is
called Parmtune and discusses basic and advanced elements of OS/2, OS/2
Database Manager, OS/2 Communications Manager, and LAN server.
The parameters for maximum link stations and maximum number of users for
the DataHub/2 workstation are the defaults from installation. We reduced the
number of SAPs to show how NETBIOS and RDS do not use a SAP under LAPS.
Our DataHub/2 workstation has access to an H: disk on the LAN server, two 3270
host sessions, a command line interface to the server′s sample database, and
DataHub/2 running. The single SAP is used only for 3270.
Chapter 4. DataHub/2 Workstation 135

136 DataHub Implementation and Connectivity
For the LAN server machine we increased the link stations, SAPs, and users to
allow the server to provide connections from five DataHub/2 workstations to the
server′s processes, database, and data (see Figure 95). The LAN server
program does not provide the connection from the requester to the database on
the server, but the LAPS configuration supplies resources for RDS.
Figure 95. LAPS: Parameters for 802.2, LAN Server

In the Configure Workstation window (Figure 96) click on NETBIOS and the Edit
push button to display the Parameters for IBM OS/2 NETBIOS.
Figure 96. LAPS: Configure Workstation, DataHub/2 Workstation NETBIOS
Chapter 4. DataHub/2 Workstation 137

138 DataHub Implementation and Connectivity
Figure 97 and Figure 98 on page 139 show similar screens for the NETBIOS
component. We highlight the parameters we are interested in: sessions,
commands, and names. Notice the differences between the requester and
server parameters.
Figure 97. LAPS: Parameters for NETBIOS, DataHub/2 Workstation

Figure 98. LAPS: Parameters for NETBIOS, DataHub/2 Server
In the Exiting LAPS window, click on the Exit push button to exit the LAPS
configuration process.
Figure 99. LAPS: Exit
Figure 100 on page 140 shows the results of configuring LAPS. The
PROTOCOL.INI file in the IBMCOM directory contains the LAPS parameters. You
could edit them directly here rather than using the LAPS configuration. Changes
do not take effect until you stop and restart the local server or requester. Notice
the differences between the requester and server parameters.
Chapter 4. DataHub/2 Workstation 139

PROT_MAN
DRIVERNAME = PROTMAN$
IBMLXCFG
IBMTOK_nif = IBMTOK.nif
LANDD_nif = LANDD.NIF
NETBEUI_nif = NETBEUI.NIF
LANDD_nif
DriverName = LANDD$
Bindings = IBMTOK_nif
NETADDRESS = ″T400032047101″
ETHERAND_TYPE = ″I″
SYSTEM_KEY = 0x0
OPEN_OPTIONS = 0x2000
TRACE = 0x0
LINKS = 41
MAX_SAPS = 1 ***** See text *****
MAX_G_SAPS = 0
USERS = 4
TI_TICK_G1 = 255
T1_TICK_G1 = 15
T2_TICK_G1 = 3
TI_TICK_G2 = 255
T1_TICK_G2 = 25
T2_TICK_G2 = 10
IPACKETS = 250
UIPACKETS = 100
MAXTRANSMITS = 6
MINTRANSMITS = 2
TCBS = 64
GDTS = 30
ELEMENTS = 800
NETBEUI_nif
DriverName = netbeui$
Bindings = IBMTOK_nif
ETHERAND_TYPE = ″I″
USEADDRREV = ″YES″
OS2TRACEMASK = 0x0
SESSIONS = 41
NCBS = 55 ***** See text *****
NAMES = 20
SELECTORS = 5
The remainder of the file is not shown here.
Figure 100. LAPS: PROTOCOL.INI, DataHub/2 Workstation
140 DataHub Implementation and Connectivity

PROT_MAN
DRIVERNAME = PROTMAN$
IBMLXCFG
IBMTOK_nif = IBMTOK.nif
LANDD_nif = LANDD.NIF
NETBEUI_nif = NETBEUI.NIF
LANDD_nif
DriverName = LANDD$
Bindings = IBMTOK_nif
ETHERAND_TYPE = ″I″
SYSTEM_KEY = 0x0
OPEN_OPTIONS = 0x2000
TRACE = 0x0
LINKS = 50
MAX_SAPS = 6 ***** See text *****
MAX_G_SAPS = 0
USERS = 6
TI_TICK_G1 = 255
T1_TICK_G1 = 15
T2_TICK_G1 = 3
TI_TICK_G2 = 255
T1_TICK_G2 = 25
T2_TICK_G2 = 10
IPACKETS = 250
UIPACKETS = 100
MAXTRANSMITS = 6
MINTRANSMITS = 2
TCBS = 64
GDTS = 30
ELEMENTS = 800
NETBEUI_nif
DriverName = netbeui$
Bindings = IBMTOK_nif
ETHERAND_TYPE = ″I″
USEADDRREV = ″YES″
OS2TRACEMASK = 0x0
SESSIONS = 60
NCBS = 95 ***** See text *****
NAMES = 40
SELECTORS = 5
The remainder of the file is not shown here.
Figure 101. LAPS: PROTOCOL.INI, LAN Server
Figure 102 on page 142 shows the IBMLAN.INI file. We are interested in the
three numbers at the end of the Net1 line. This is where the requester and
server reserve connectivity resources defined in the 802.2 and NETBIOS
Chapter 4. DataHub/2 Workstation 141

configurations. Notice the difference in these numbers between the OS/2 LAN
requester in Figure 102 on page 142 and the OS/2 LAN server in Figure 103 on
page 142. Spreadsheets are available on IBM marketing tools to assist you in
tuning these parameters. CNFGLS13 will tune servers up to version 3.0;
CNFGLS30 applies to version 3.0 specifically. These tools can be given to
customers.
; OS/2 LAN Requester initialization file
networks
net1 = NETBEUI$,0,LM10,32,20,14 ***** See text *****
; This information is read by the redirector at device initialization time.
requester
COMPUTERNAME = REQGORD
DOMAIN = SIGD2471
; The following parameters generally do not need to be
; changed by the user.
charcount = 16
chartime = 250
charwait = 3600
keepconn = 600
keepsearch = 600
maxcmds = 16
The remainder of the file is not shown here.
Figure 102. LAPS: IBMLAN.INI, DataHub/2 Workstation
; OS/2 LAN Server initialization file
networks
net1 = NETBEUI$,0,LM10,32,40,21 ***** See text *****
; This information is read by the redirector at device initialization time.
requester
142 DataHub Implementation and Connectivity
COMPUTERNAME = SIGS2471
DOMAIN = SIGD2471
; The following parameters generally do not need to be
; changed by the user.
charcount = 16
chartime = 250
charwait = 3600
keepconn = 600
keepsearch = 600
maxcmds = 16
The remainder of the file is not shown here.
Figure 103. LAPS 9A: IBMLAN.INI, LAN Server

4.4.6 OS/2 Database Manager Connectivity Parameters
Just as the LAN Server is configured to support a number of users, the OS/2
Database Manager also has parameters you may have to change to satisfy your
requirements. The command to display the configuration is:
• C: DBM GET DATABASE MANAGER CONFIGURATION
Figure 104 and Figure 105 show the results of the command for both an OS/2
Database Manager client and our server. You can change these parameters and
the parameters in Figure 106 on page 144 by using the configuration tool of
OS/2 Database Manager.
Database Manager Configuration
Max requester I/O block size (RQRIOBLK) = 4096
Max server I/O block size (SVRIOBLK) = 0
Max kernel segments (SQLENSEG) = 25
Max no. of active databases (NUMDB) = 3
Workstation name (NNAME) = DHCLIENT
Communication heap size (COMHEAPSZ) = 4
Remote services heap size (RSHEAPSZ) = 2
Figure 104. OS/2 Database Manager Connectivity Parameters: Client
Database Manager Configuration
Max requester I/O block size (RQRIOBLK) = 4096
Max server I/O block size (SVRIOBLK) = 4096
Max kernel segments (SQLENSEG) = 802
Max no. of active databases (NUMDB) = 8
Workstation name (NNAME) = DHSERVER
Communication heap size (COMHEAPSZ) = 16
Remote services heap size (RSHEAPSZ) = 14
Figure 105. OS/2 Database Manager Connectivity Parameters: Server
Comheapsz and Rsheapsz define the amount of memory to allocate for
communicating between RDS requesters and the server code. More requesters
require more communications buffers to be defined at the server. In our
implementation we have a connection from each DataHub/2 workstation. The
DataHub/2 program runs as two processes, each of which requires access to the
DataHub/2 database. Therefore 14 remote connections will service 7 DataHub/2
requesters. We increased the Comheapsz on the requester from the default of 2
to 4 to enable full DataHub/2 function from a client.
Chapter 4. DataHub/2 Workstation 143

4.4.7 DataHub/2 Database Connectivity Parameters
4.5 LAN Design Considerations
4.5.1 LAN Server Compatibility
144 DataHub Implementation and Connectivity
Now that the OS/2 Database Manager can support our connections, we need
access to the DataHub/2 database. See Figure 106.
Figure 106. DataHub/2 Database Active Applications: Server
You must update the maximum active applications database parameter. As in
Rsheapsz, the DataHub/2 application runs as two processes, so the maxappls
parameter must reflect the number of DataHub/2 workstations multiplied by 2.
LAN server compatibility and placement of the LAN server and DataHub/2
database are the main design considerations.
Table 16 shows the base operating systems and the LAN Server version that will
run. We mixed DataHub/2 on different levels of OS/2 and OS/2 Database
Managers with complete interoperability. You should ensure that your server is
compatible with the operating system level on the database server machine.
Table 16. LAN Server and OS/2 Version Compatibility
OS/2 V 1.3 OS/2 V 2.0
LS 2.0 Entry Yes Yes
LS 2.0 Advanced Yes No
LS 3.0 Entry No Yes
LS 3.0 Advanced No Yes

4.5.2 Placement of LAN Server and DataHub/2 Database
4.6 Performance
4.6.1 Placement
The LAN server program must be installed on the same machine as the
DataHub/2 server code because of the way DataHub/2 makes its internal files
available to the DataHub/2 requester. The DataHub/2 requester must be a LAN
requester so that the DataHub/2 code can access the files.
Each requester can run with a local DataHub/2 designated database or use a
central database on the DataHub/2 server. The central database could even be
on a different database server not running DataHub/2. This setup would require
RDS and network activity for every database access, however, and is not
generally recommended.
Here we do not discuss how fast DataHub runs. Rather, we discuss two
performance factors that can influence your design. One such factor is how you
place and combine the various products on the network; another is the workload
that each product load places on a machine.
You are probably installing DataHub on an existing LAN or network. The
topology of the network is probably the result of satisfying user requirements
previously defined, such as access to applications and data.
In a local data environment, performance is not an issue because you are
accessing and managing local data. Performance is determined by the amount
of data and the speed of the processor and disk drive.
In a distributed environment, such as in our scenarios 2 and 3, your performance
will be affected by the network topology. Depending on the additional load
imposed by DataHub, you may need to select components to fit the topology or
change the topology to fit your requirements.
Let′s look at some of factors that affect capacity and performance in a scenario
that is more complex than ours.
Your users are requesters of a LAN server machine, which also provides host
connect gateway function. One OS/2 database resides on the gateway. Another
resides on a remote non-OS/2 host and is accessed by DDCS/2. Keep in mind
that the user′s observed response time includes the performance of all system
and network components from the user′s keyboard through the local processor,
LAN, gateway, wide area network (WAN), host processor, and the return trip.
Performance of this network is determined by:
• Number of files or programs transferred between the server and requesters
• How much data is transferred between the local network and the host
• Line speed of the host connection
• Number of database accesses at the server.
Recent experience with customers in similar situations shows that often the
performance bottleneck of a network as perceived by the user is not at the
server but at the workstation (requester). The network may be a performance
Chapter 4. DataHub/2 Workstation 145

4.6.2 Workload
consideration if the local LAN is connected to the WAN by a low-speed line. The
LAN is almost never a performance problem if properly designed.
Several benchmarks have been run over the last few years for all components of
OS/2. But benchmarks have not been run for every combination of LAN
requester, OS/2 Communications Manager, OS/2 Database Manager, and
DDCS/2. Now we are adding a DataHub/2 component to the available mix. So
your mileage will vary. The performance figures in this section are offered as a
guideline only.
The performance of any function varies drastically depending on the machine
model, amount of memory installed, type of disk, network adapter, line speed,
and user workload. You should use the following numbers to determine whether
your scenario is a light, reasonable, or impossible load on the configuration:
• Local processor
Most benchmarks run on OS/2 show the performance knee at around 60%
processor utilization. This means that a CPU running xx functions per
minute at 50% will not run twice as many with the same response time. The
effect of mixing functions like communications and database calls cannot be
predicted by adding the loads linearly.
• OS/2 Communications Manager
Benchmarks run at the Raleigh ITSC indicate that a high-end gateway
machine can serve up to 50 typical users of 3270 sessions on a 56KB line
with reasonable (1 to 2 sec) response time. Line speed becomes the limit,
and the processor utilization stays linear, below 50%.
• LAN Server
Server performance is measured by the number of 512-byte sectors the
server can access from disk and forward to a requester per minute. The unit
is a request per minute, or RPM. If the user is downloading a DataHub/2
program module, divide the size of the program by 512 to determine the
number of requests. Determine the number of users and frequency of
access and do your arithmetic to come up with the server load. A general
rule of thumb for an average-sized server running at a high processor
utilization is 15,000 to 20,000 RPMs. HPFS and Advanced Server versions
will exceed this figure. If your peak load is 5,000 requests, you have used up
less than 25% of your server.
• OS/2 Database Manager
146 DataHub Implementation and Connectivity
The START USING DATABASE command takes a certain amount of time
depending on where the database is, how busy the database server is,
whether the user is logged on, and whether the database manager has been
started. The START USING DATABASE command is usually issued only
during initialization of the application. If your application starts and stops
databases, count 15 sec for local databases. Remote starts can take from a
few seconds to minutes depending on whether sessions already exist
between the requester and the remote database and how many nodes
manage the session. Depending on buffer sizes, physical location of data,
and type of SQL call, performance can vary from 1,000 to 50,000 SQL calls
completed per minute. Your application′s performance is very dependent on
the database design, which determines the number of calls. In one customer
application the response time was reduced from 18 to 2 seconds by

duplicating a few fields from one table to another instead of accessing two
tables.
− RDS versus ARI
An OS/2 Database Manager request using RDS causes all the selected
data to be sent from the OS/2 Database Manager server to the RDS
requester through the LAN. If the requester executes another select
statement, it is sent to the server and the results returned. The
application remote interface (ARI) is more efficient than RDS because
you can send one request (to run a series of statements) to the server,
and only the result of all the statements is returned to the calling
application. This process reduces the processor load at the requester
but transfers it to the server, which is presumably a faster machine.
• OS/2 Database Manager and LAN server tuning conflicts
Disk caching to memory is normally a good idea with LAN server. But OS/2
Database Manager defeats the benefits of disk caching because the
database buffer pools accomplish a similar purpose for database data.
When an OS/2 Database Manager disk read is necessary because the data
is not in the buffer pool, a disk cache would be flushed of data accessible to
the LAN server. The data would then be in the cache and the buffer pool,
but LAN server would have no need for the cached data because it is
database data. System Performance Monitor/2 (SPM/2) can be used to
determine the application working set of memory. You can then balance
buffer pools, swapping and possibly set up a Vdisk for any repetitive-read
LAN server data if there is sufficient real memory.
• DDCS/2
The performance of DDCS/2 is dependent on several considerations such as
row size, block fetch, block size, and network configuration (requesters to
gateway through RDS using NETBIOS or APPC). Generally, performance in a
realistic environment varies between 2,000 and 10,000 rows per minute
returned from the DB2 or SQL/DS host.
The above numbers give you a rough starting point from which to determine the
load your application imposes on a server. The art of predicting performance
depends on how well you can analyze the exact functions called for by your
application mix. SPM/2 is a tool you can use to provide information on disk and
memory utilization plus the load by application. You can then use the
information to determine which factors to analyze and tune for better
performance.
Chapter 4. DataHub/2 Workstation 147

4.7 Codepage Support
4.8 Recommendations
An OS/2 database is stored in whatever codepage was in effect when the
database was created. Access through RDS to a remote database with a
different codepage does not work. This is an implementation restriction in the
RDS architecture. You can, however, start another OS/2 process, change the
codepage using the CHCP nnn command (where nnn is the new codepage), and
issue a DBM START USING DATABASE against the database. One of our
implementations had a local DataHub/2 database with codepage 437, and
another OS/2 DataHub/2 instance running against a remote DataHub/2 database
using codepage 850. Note that the two processes must use different EMQDIR
system variables to point to the correct DataHub/2 data file location. We use
local data files for each instance. Figure 107 shows the OS/2 command file for
codepage change.
CHCP 850
SET EMQDIR=C:EMQ850
DATAHUB.EXE
EXIT
Figure 107. CMD File for Codepage Change
The challenge of installing DataHub/2 is in getting the prerequisite platform
running. In our examples, each scenario builds on the success of its
predecessor.
4.8.1 Create the Administrator′s Folder
148 DataHub Implementation and Connectivity
Figure 108 shows an administrator′s OS/2 folder we used to run DataHub/2. It
provides easy access to the logs and error reports your administrator uses to
manage the DataHub/2 environment. Some of the icons are used only for initial
installation and configuration, such as LAPS. Table 17 on page 149 lists the
definitions we used to set up the Administrator′s folder.
Figure 108. A DataHub/2 OS/2 Desktop: Administrator′s Folder

Table 17. DataHub/2 Administrator′s Folder Definitions
SNA network
definition
LAPS
Directory tool
User profile
management
IBM DataHub/2
Path and File
Name
C:CMLIBAPPN
APPNC2.EXE
C:IBMCOM
LAPS.EXE
C:SQLLIB
DIRECT.EXE
C:MUGLIB
UPMACCTS.EXE
D:EMQDIR
DATAHUB.EXE
Some of the entries in Table 17 are specific to our environment. You should
change the drive and path data to match your environment.
• Verify each component as you install it.
You may want to test OS/2 Database Manager connectivity using RDS before
invoking DataHub/2.
• See if you can START USING the DataHub/2 database at the DataHub/2
database server.
If you have a LAN Server, make sure the requesters have access to the files.
If one or a small number of users functions through the server but an
additional user cannot, review the LAN configurable parameters.
• Start with a single DataHub/2 workstation.
Parameters
[Enter Node Definition
(.NDF) file Name]
EMQCELOG.010 EPM.EXE D:EMQDIREMQCELOG.010
EMQRREPT.TXT EPM.EXE D:EMQDIREMQRREPT.TXT
OS/2 full screen *
DBM command
line
C:OS2CMD.EXE
/K DBM.CMD -S &
STARTDBM.EXE
The experience you gain can be transferred to the more detailed
configuration required by a central database and files.
Working
Directory
C:CMLIB
C:IBMCOM
C:SQLLIB
D:EMQDIR
C:SQLLIB
Chapter 4. DataHub/2 Workstation 149

150 DataHub Implementation and Connectivity

Chapter 5. DataHub Tools Conversation Connectivity
In this chapter we discuss the implementation of tools conversation data flows
that DataHub uses between DataHub/2 and DataHub Support host components.
Figure 109 summarizes the different data flows that DataHub uses.
The chapter describes the DataHub key connectivity parameters and emphasizes
how they should relate to and match each other. The chapter explains the
definitions that must be made at the DataHub/2 workstation to add a managed
host and a managed RDB in the DataHub/2 database, as well as the definitions
that must be made in the OS/2 Communications Manager and the OS/2
Database Manager. The chapter ends with recommendations for a successful
DataHub installation.
Figure 109. DataHub Data Flows Used by DataHub Tool Functions
© Copyright IBM Corp. 1993 151

5.1 Key Connectivity Parameters
The DataHub/2 workstation manages different and multiple RDBs. To have the
DataHub system working properly, it is very important to understand which
parameters are key to connectivity.
OS/2 Communications Manager, VTAM/NCP, and AS/400 communications
definitions must have some matching parameters to ensure the successful
operation of DataHub. The DataHub key connectivity parameters are:
• Symbolic destination name
• Partner logical unit name
• Partner transaction program name
• Mode name
• Host RDB name
• OS/2 Database Manager database alias name
• Subsystem name, if the RDB is a DB2.
Table 18 shows the key connectivity parameters that must be defined to add an
RDB in the DataHub/2 workstation configuration and where to find the related
parameter for each host, if applicable.
Table 18. DataHub/2: Key Connectivity Parameters
Parameter DataHub/2
Workstation
Symbolic
destination name
Partner LU
name
CPI
communications
side info
MVS Host VM Host AS/400 Host OS/2 Host
n/a n/a n/a n/a
n/a VTAM APPL VTAM APPL LOCNAME Local node
name
Partner TP name TP name n/a RESID AS/400 program
name
Transaction
program
Host RDB name RDB Location DBNAME *LOCAL RDB Map file
MODE name Transmission
service mode
OS/2 database DBM System
Directory alias
MODEENT MODEENT MODE
description
Transmission
service mode
n/a n/a n/a Map file
Symbolic Destination Name
A symbolic destination name is a name or an alias name given to an OS/2 SNA
resource that defines the characteristics of an LU 6.2 conversation between an
OS/2 system and another host, which can be another OS/2 system. In a
DataHub environment, the symbolic destination name represents a DataHub
Support component to which DataHub/2 will send requests using the tools
conversation protocol. The symbolic destination name includes definition of the:
• Partner logical unit name (DataHub Support component)
• Partner transaction program name
• Mode name
• Conversation security type.
152 DataHub Implementation and Connectivity

The symbolic destination name is defined in OS/2 Communications Manager. It
is used by DataHub/2 to associate a specific host with a DataHub Support
application that will handle the tools conversation on that host.
This parameter is configured to DataHub/2 in the Add Host dialog, in the
Symbolic Destination field.
Partner Logical Unit Name
In addition to the DRDA connectivity requirements, DataHub sessions are
established between the DataHub/2 workstation and the DataHub Support
components on the different managed hosts. Those sessions are what we call
the tools conversation and are LU 6.2 sessions (APPC). Therefore a logical unit
name must be assigned to the DataHub Support components. For the MVS and
VM hosts, DataHub Support/MVS and DataHub Support/VM will need to be
added to the VTAM definitions.
For the AS/400 and OS/2 environments, you do not have applications to define.
You only need to connect to the system using the proper link definitions as
defined in 3.6, “AS/400 Definitions” on page 60 and “Partner Token-Ring
Address and Logical Unit Name” on page 81. For those environments, the
transaction program name that will handle that request on the managed host
distinguishes a DRDA or an RDS request from a tools conversation request.
Partner Transaction Program Name
The transaction program name is the name of a program or an alias to a
program name that, in the case of a DataHub Support environment, processes
the tools conversation requests at the managed host location. The
implementation of the transaction program name varies for each platform.
Mode Name
The mode name is composed of multiple parameters that are used during the
session negotiation between DataHub/2 and the DataHub Support components.
The mode name must be defined at each location. The name and the class of
service must match.
Host RDB Name
The SAA RDB name is used to identify a host database at the DataHub/2
workstation. This is an important parameter, because for each host you can
associate one or more RDB names. MVS and VM allow you to have multiple
DB2 subsystems and SQL/DS database machines, respectively.
Although OS/2 hosts cannot act as servers in a DRDA network, which means
they do not have a DRDA RDB name associated with them, DataHub/2 requires
such a definition. In DataHub/2 you associate one RDB name with each OS/2
Database Manager database you want to manage.
OS/2 Database Manager Database Alias Name
The OS/2 Database Manager database alias name is not a key connectivity
parameter in terms of customizing the DataHub Support components. But the
value is key at both the DataHub/2 workstation and the OS/2 managed hosts.
This value is used for any DataHub/2 function using the DRDA or RDS protocol to
execute. The name defined in DataHub/2 is used to connect to OS/2 Database
Manager, which in turn will connect to the managed host.
Chapter 5. DataHub Tools Conversation Connectivity 153

5.2 The ITSC Network
DB2 Subsystem Name
This parameter is key only when the RDB is a DB2 system. It is used in the
tools conversation protocol.
The DRDA ITSC network we want to manage from a DataHub/2 workstation is
described in 3.3, “The ITSC Network” on page 38. Because DRDA and RDS
connectivity are the basis for DataHub implementation, you should refer to the
different definitions we use for DRDA connectivity. Many of those definitions are
used to customize the different components of the DataHub/2 workstation.
As explained in 5.1, “Key Connectivity Parameters” on page 152, each managed
host must be identified by some names. Some must be unique, like the RDB
name and logical unit name. Some are specific to the environment setup, like
the TP name and the mode name.
Table 19 and Table 20 show you the values assigned to each ITSC DataHub/2
managed host.
Table 19. ITSC Network: DataHub Key Connectivity Parameter Values. MVS, VM, and AS/400 DataHub
Managed Hosts
Parameter New York
DB2
Headquarters
Toronto
SQL/DS
Large Car Dealer 1
Symbolic dest. name SMNYCENT SVTORDR1 SASJDLR1
San Jose
AS/400
Car Dealer 1
Partner logical unit name USIBMSC.EMQMACB1 USIBMSC.VDHTOR01 USIBMSC.SJA2054I
Partner TP name EMQVRSID QDMU/QSTSC
Mode name EMQMLOGM IBMRDB IBMRDB
Host RDB name DB2CENTDIST SQLLDLR01 SJ400DLR1
Host DBM database alias
name
MNYCENT VTORDB ASJDB
Note: The AS/400 program name will always be QDMU/QSTSC.
Table 20. ITSC Network: DataHub Key Connectivity Parameter Values. OS/2 DataHub Managed Hosts
Parameter Montreal
OS/2 DBM
Car Dealer 1
Paris
OS/2 DBM
Car Dealer 1
Symbolic dest. name SMTLDLR1 SPARDLR1 SRIODLR1
Rio De Janeiro
DB2/2
Car Dealer 1
Partner logical unit name USIBMSC.SJA2018I USIBMSC.SJA2050I USIBMSC.SJA2019I
Partner TP name EMQ2T EMQ2T EMQ2T
Mode name IBMRDB IBMRDB IBMRDB
Host RDB name DBMMTLDLR1 DBMPARDLR1 DBMRIODLR1
Host DBM database alias
name
154 DataHub Implementation and Connectivity
OMTLDB OMTLDB ORIODB

5.3 Configuring the DataHub/2 Workstation
The DataHub/2 workstation as described in Chapter 4, “DataHub/2 Workstation”
on page 105 needs definitions in:
• DataHub/2 database
• OS/2 Communications Manager
• OS/2 Database Manager directories
• OS/2 User Profile Management.
5.3.1 Component Relationships
The following DataHub key connectivity parameters are unique for the DataHub/2
workstation:
• Symbolic destination name. The partner LU name and the partner TP name
are derived from this parameter to enable the communication between the
DataHub/2 workstation and the different DataHub Support partners.
• The OS/2 Database Manager database alias name. This parameter, which is
assigned to an RDB name, is the key parameter to connect DataHub/2 to
OS/2 Database Manager, which in turn will establish connection between the
DataHub/2 application and the source or target databases.
Figure 110 on page 156 shows the relationship among the three main
components used in a DataHub/2 environment. The security aspect of
DataHub/2 is discussed in 7.1, “Security on the DataHub/2 Workstation” on
page 241.
When the request requires the use of DRDA or RDS, DataHub/2 will connect to
the OS/2 Database Manager database alias name entered in the RDB
configuration. The OS/2 Database Manager processes the request using the
different directory entries and OS/2 Communications Manager definitions as
shown in Figure 46 on page 71.
If, however, the request requires the use of the tools conversation protocol, the
symbolic destination name defined in either the host configuration or the RDB
configuration will be used. DataHub/2 asks OS/2 Communications Manager to
establish a conversation with a DataHub Support partner using this name. OS/2
Communications Manager then uses its own definitions to establish the session.
These definitions include:
• Partner logical unit name
• Partner transaction program name
• Mode name
• Conversation security type.
Once OS/2 Communications Manager establishes the session, the DataHub/2
request is sent to the DataHub Support partner to be executed at the host.
Chapter 5. DataHub Tools Conversation Connectivity 155

Figure 110. DataHub/2: OS/2 Component Relationship. This figure explains the
relationship among the values for different components used in the DataHub/2
environment.
5.3.2 DataHub/2 Database Definitions
We use the term “database definitions” to customize DataHub/2 because it is
through OS/2 Database Manager database tables that DataHub/2 defines the
different hosts it manages.
This section shows how to add a managed host and a managed RDB to the
DataHub/2 database. The important names you need to define in the DataHub/2
database are:
• Host name
• Symbolic destination name
• Host RDB name
156 DataHub Implementation and Connectivity
• OS/2 Database Manager database alias name

• DB2 subsystem name (MVS only).
We assume that you have started the DataHub/2 workstation and have the
DataHub/2 - Untitled window displayed at your workstation (see Figure 111).
Figure 111 shows the different hosts that have been defined in our DataHub/2
database. Note that the hosts are listed in ascending order.
If you have not defined any hosts, your screen will be empty, but you should
have the Host object displayed on the window.
To add a host to the DataHub/2 database, you perform these steps:
1. Select the Host object on the DataHub/2-Untitled window
2. Select Configure from the action bar.
The Configure pull-down menu will then appear.
Figure 111. DH/2: Selecting Add on Configure Pull-down Menu
3. Select Add... from the Configure pull-down menu.
The Add Host window will appear (Figure 112 on page 158).
4. Fill in the Host field.
The Host field can have any value you want. The value will be used in the
DataHub/2 user profile to associate a userid and/or password with the
managed host for the tools conversation requests. The field should reflect
the type of host system (MVS, VM, AS/400, OS/2). Most importantly, it should
reflect the physical location of the host. The host name must be unique in
the DataHub/2 database.
Chapter 5. DataHub Tools Conversation Connectivity 157

Recommendation
A good naming convention should be defined for:
• Host name
• Symbolic destination name
• Partner LU name
• Partner LU alias name
• OS/2 Database Manager database alias name.
That naming convention should be used on every DataHub/2 workstation,
regardless of the DataHub/2 configuration being used.
5. On the Add Host window, fill in the Symbolic destination field.
The symbolic destination name can be a name of up to eight characters long
and must be the same name you use in the OS/2 Communications Manager
CPI-Communications side information. You should use the same name as the
host name. To help you recognize the relationship with other definitions,
however, we did not use the same name.
6. Select your Operating System Type.
7. Select the OK push button when you have completed your host definition.
Figure 112. DH/2: Add Host Window
158 DataHub Implementation and Connectivity
The host that you added will appear on the DataHub/2 main menu.
Now you must define the RDB on the new host. Note that multiple RDBs could
exist on one host (for example MVS, VM, and OS/2).
The steps to add an RDB to a host are:
1. Select the host name from the DataHub/2 main menu.
The Display Related Objects window will appear as shown in Figure 113 on
page 159.
2. Select the RDB line from the window and click on the Display push button.

Figure 113. DH/2: Display Related Objects Window
The DataHub/2-Untitled window will be refreshed with an RDB object added
under the new host.
3. Select the RDB object and select Configure from the action bar.
The Configure pull-down menu will appear. The DataHub/2 window should
now look like that shown in Figure 114.
4. Select Add... from the Configure pull-down menu.
Figure 114. DH/2: Adding an RDB
The Add RDB window will appear as shown in Figure 115 on page 160, but
all the field values will be blank.
In the RDB field, you will need to insert the DRDA RDB name of the target
RDB. This name is exactly the same as the name used for DRDA
connectivity. Chapter 3, “DRDA Connectivity” on page 31 explains in detail
how this value is defined in each host system. This name must be unique in
the DRDA network and in the DataHub/2 database. Even if the OS/2
Database Manager does not support the DRDA server environment, a unique
RDB name must be assigned to an OS/2 Database Manager database.
In the OS/2 database field, enter the database alias name as defined in the
OS/2 Database Manager system directory.
Chapter 5. DataHub Tools Conversation Connectivity 159

In the Symbolic destination field, do not enter any value unless you have
multiple DataHub Support components implemented on that host for
performance or testing reasons. You enter a value in this field to specify a
different symbolic destination name from that specified at the host level.
If the host is an MVS host, the DB2 subsystem field will be enabled to enter
the DB2 subsystem name.
Figure 115 shows how we defined our DB2 RDB located in New York.
5. Select the proper String Delimiter and Decimal Separator radio buttons.
6. Click on the OK push button when you have completed the RDB definition.
Figure 115. DH/2: Add RDB Window
160 DataHub Implementation and Connectivity
The refreshed DataHub/2-Untitled window will appear with the new RDB added
under the new host.
Figure 116 on page 161 shows all the hosts we have defined in the DataHub/2
database for the ITSC network and their RDB names. The RDB shown as
selected is the MVS DB2 RDB that we defined under the MNYCENT host.

Figure 116. ITSC Hosts and Their RDB Names
Table 21 shows the DataHub/2 database definitions we used in the ITSC
network. You will need to refer to these definitions as you continue with the
DataHub/2 workstation configuration.
Table 21. DataHub/2 Database Definitions Used in the ITSC Network
DataHub/2 Host
Name
Symbolic
Destination
Name
Operating
System Type
RDB Name OS/2 Database DB2 Subsystem
ASJDLR1 SASJDLR1 AS/400 SJ400DLR1 ASJDB n/a
MNYCENT SMNYCENT MVS DB2CENTDIST MNYCENT DB23
OMTLDLR1 SMTLDLR1 OS/2 DBMMTLDLR1 OMTLDB n/a
OPARDLR1 SPARDLR1 OS/2 DBMPARDLR1 OPARDB n/a
ORIODLR1 SRIODLR1 OS/2 DBMRIODLR1 ORIODB n/a
VTORDLR1 SVTORDR1 VM SQLLDLR01 VTORDB n/a
5.3.3 OS/2 Communications Manager Definitions
Depending on the DataHub configuration you select, the OS/2 Communications
Manager could require many definitions on the DataHub/2 workstation. Unlike
DRDA connectivity, where you could use a DDCS/2 gateway to get to all the
managed hosts, the tools conversation protocol requires OS/2 Communications
Manager definitions at each DataHub/2 workstation. If you are not using a
DDCS/2 gateway but are using the LU 6.2 protocol for RDS connectivity, many of
the DataHub tools conversation protocol requirements may be familiar to you.
This section shows you how to define the OS/2 Communications Manager
parameters specific to DataHub tools conversation connectivity. It considers the
following definitions:
• Local node characteristics
Chapter 5. DataHub Tools Conversation Connectivity 161

• Communications link
• Partner LU
• CPI Communications side information: symbolic destination name
• Mode name.
162 DataHub Implementation and Connectivity
Local Node Characteristics
Each DataHub/2 workstation must be customized for SNA connectivity whatever
the DataHub/2 configuration used. If you use the single DataHub/2 workstation
configuration as in scenarios 1 and 2, your SNA definitions for DRDA connectivity
are already complete. If your DataHub/2 workstation is using a DDCS/2 gateway
and the NETBIOS protocol to access it (as in scenario 3), you need to define your
workstation in the SNA network. This definition is necessary because the tools
conversation protocol requires a session to be established between the
DataHub/2 workstation and the DataHub Support components. If one of the
managed hosts is an MVS or VM host, VTAM definitions will be required for each
DataHub/2 workstation (see Figure 47 on page 74 and Figure 137 on page 184).
The steps required to define the local node characteristics are presented in
“IDBLK, IDNUM, Network ID, Logical Unit Name, SNA Control Point Name” on
page 77. Table 10 on page 80 shows how each OS/2 workstation has been
defined for the ITSC network.
Communications Link
On each DataHub/2 workstation, one link must be defined for each managed
OS/2 and AS/400 host. Links are defined as peer nodes. Only one link is
needed for MVS and VM managed hosts because VTAM and NCP take care of
the routing between them.
To define the communications links between the DataHub/2 workstation and the
managed hosts, you should refer to “Partner Token-Ring Address and Logical
Unit Name” on page 81. Table 11 on page 85 shows the values we used for the
ITSC network. It is important to note that Table 11 on page 85 is related to
DRDA connectivity. For DataHub tools conversation connectivity, the partner LU
will be different. In a DRDA session, the partner LU is an RDB system. For a
tools conversation session, the partner LU is the DataHub Support component.
Partner LU
For the MVS and VM managed hosts, a partner LU definition is required for
every instance of DataHub Support. There could be multiple instances of
DataHub Support in MVS and VM systems.
For the AS/400, the partner LU used for the tools conversation protocol is the
same as DRDA. For the OS/2, the partner LU used for the tools conversation
protocol is shown on Table 11 on page 85. What differs is the transaction
program name that will handle the request at the managed host. The
transaction program name is defined in the symbolic destination name
definitions discussed below.
To define a partner LU, you need to get through the link definitions as explained
in “Partner Token-Ring Address and Logical Unit Name” on page 81.
Figure 117 on page 163 shows the Change Partner LUs window for the host link
(MVS and VM hosts). You can see all the partner LUs already defined for DRDA
and DataHub tools conversation connectivity. It shows how we add (change) the

DataHub Support/MVS partner LU. The partner LU name (EMQMACB1) must
match the APPL name in the VTAM definition as shown in Figure 128 on
page 174. When you add a partner LU in your link definition, the new name will
appear in the LU name list box window.
The partner LU Alias name can be any name, but it must have a significant
name so that it can be easily referred to.
Because the DataHub Support partner LU name (USIBMSC.EMQMACB1) or its
alias name will be used later in the symbolic destination name definition, you
should define the partner LU and the link before defining the symbolic
destination name.
Figure 117. Partner LU Definition for an SAA RDB System
Symbolic Destination Name
The symbolic destination name is an alias to a group of definitions related to a
partner, which in this case is a DataHub Support component.
You will need to define one symbolic destination name for every DataHub
Support component in the network. If your configuration contains multiple
DataHub/2 workstations, those definitions could be split among workstations.
You do not need to define a symbolic destination name if you are not going to
use it from your workstation.
To define a symbolic destination name, start the OS/2 Communications Manager
setup function and select the appropriate choices until you end up at the SNA
Features List window (see Figure 118 on page 164). The steps required are
listed in “IDBLK, IDNUM, Network ID, Logical Unit Name, SNA Control Point
Name” on page 77. On the SNA Features List window, perform the following
steps:
Chapter 5. DataHub Tools Conversation Connectivity 163

1. Select the CPI Communications side information
The list of all symbolic destination names already defined will appear in the
Definition list box.
2. Select the Create... push button or the definition with which you want to work
(in this case SMNYCENT).
3. Click on the Change... push button.
Figure 118. SNA Features List Window (CPI Communications Side Information)
164 DataHub Implementation and Connectivity
4. The Change CPI Communications Side Information window will appear with
the actual definition for the DataHub Support/MVS symbolic destination name
in New York (see Figure 119 on page 165). You need to fill in the fields in
this window.
The Symbolic destination name field could contain any value, but the value
must be the same as the one specified in the DataHub/2 database definition.
For the Partner LU fields, you could use either the fully qualified name (that
is, USIBMSC.EMQMACB1) or the partner LU alias name for the DataHub
Support component. For the AS/400 and the OS/2 host, you use the LU
names for those systems (see 3.6, “AS/400 Definitions” on page 60 and
“IDBLK, IDNUM, Network ID, Logical Unit Name, SNA Control Point Name”
on page 77).
The TP name field is used to define the program that will process the request
on the host side. The value can be explicit as in the AS/400, or it could refer
to a definition on the host side. These are the values for the TP names for
the different hosts:
• MVS: can be any name

• VM: same as the value assigned to the RESOURCEID parameter in the
EMQVSYS CONFIG DHS/VM configuration file
• AS/400: QDMU/QSTSC (library name/program name)
• OS/2: an alias to an OS/2 program name (for example, EMQ2T). EMQ2T
must be defined in the OS/2 host as a transaction program. Both the
alias and the program name must be the same.
In the Mode name field, you enter the mode that will be used for that
connection. It must have been defined through the SNA Features List
window.
In the Security type field, you could select Same or Program. DataHub/2
will enforce program security and use the DataHub/2 user profile
information to send the request to the appropriate host. If you select the
Program security type from this window, you will have to click on the
Continue... push button (which replaces the OK push button when you
select Program security type) and fill in some security information on the
Change CPI Communications Program Security window.
Note: The security information you provide on the window in Figure 119
will be overridden by the DataHub/2 user profile security information.
Recommendation
We recommend that you select security type = same. DataHub/2 will
enforce program security and will use the DataHub/2 user profile for the
security information.
Figure 119. Change CPI Communications Side Information
Chapter 5. DataHub Tools Conversation Connectivity 165

5. Click on the OK push button when you have completed the Change CPI
Communications Side Information window.
The SNA Features List window will reappear with the new symbolic
destination name in the list box, if the requested function was to add a
definition.
6. Click on the Close push button when you have completed the symbolic
destination name definitions. If required, you could add a specific mode
name to your actual mode name definition by selecting the Modes line from
the Features box.
You should now go through different windows until your configuration is
validated and your active configuration is updated.
Table 19 on page 154 shows the symbolic destination names and all the other
parameters we used to define the RDBs in our DataHub/2 configuration.
Appendix A, “OS/2 Communications Manager Network Definition File” on
page 259 shows the OS/2 NDF file that was created for our DataHub/2
workstation OS/2 Communications Manager configuration.
Mode Name
If required, you could add a new mode to your mode list if the modes that are
already defined (for example, IBMRDB) do not satisfy your requirements.
You would use the procedure in “Mode Name” on page 85 to add a new mode
to your system. Note that you will need to define the new mode on every host
that will use it.
5.3.4 OS/2 Database Manager Definitions
166 DataHub Implementation and Connectivity
One important parameter that must be defined when adding an RDB to the
DataHub/2 database is the OS/2 database name. This OS/2 database name is
the alias name defined in the OS/2 Database Manager system directory that
points to the target managed RDB. Using that alias name and the different
related entries in the different directories, OS/2 Database Manager will direct the
connect request to the proper host.
To gain an understanding of all of the relationships among OS/2 Database
Manager, DDCS/2, and OS/2 Communications Manager definitions, you should
refer to 3.7.2, “Relationship between OS/2 Components” on page 70. From an
OS/2 Database Manager perspective, DataHub/2 is another program that makes
SQL requests, such as connect and select.
Complete instructions for defining the OS/2 Database Manager system directory
entries can be found in 3.7.5, “DRDA Definitions” on page 86. Those entries
should be defined and tested before you even start to implement DataHub.
Figure 120 on page 167 shows all the OS/2 Database Manager system directory
definitions we used for the ITSC network. The MNYCENT alias corresponds to
the DataHub/2 and DB2 RDB name, DB2CENTDIST.

Figure 120. OS/2: System Database Directory
5.4 Configuring MVS for DataHub Support/MVS
DataHub Support/MVS must be installed to allow DataHub/2 to manage the DB2
databases at the host.
DataHub Support/MVS supports users working at a DataHub/2 workstation by
receiving the DataHub commands they initiated. Depending on the function that
a user action triggers, DataHub might use different connectivity because there
are two types of information flow between SAA DBMSs: the DRDA flow, which
uses SNA LU 6.2, and the tools conversation flow, which is a private DataHub
protocol that also uses LU 6.2. Some DataHub functions, such as DISPLAY RDB
WORK and UTILITIES, use the tools conversation flow.
This section focuses on the important parameters that must be defined and
match OS/2 Communications Manager and Database Manager, VTAM, NCP, and
DB2 system tables.
5.4.1 Preparing for DataHub Support/MVS Installation
The steps required to prepare for DataHub Support/MVS installation are listed
below. More details can be found in Chapter 2 of the DataHub Support/MVS
Installation and Operations Guide.
The preparation steps are:
1. Verify that the system hardware is at the required level.
Chapter 5. DataHub Tools Conversation Connectivity 167

2. Verify that the system software products are the required release level.
3. Determine which JES run class or classes will be used by DataHub
Support/MVS and for tools you plan to add to the environment.
4. Define two output hold classes for use by DataHub Support/MVS Tool
Dispatcher and tools.
5. Define the MVS data set high-level qualifier to RACF or to a functionally
equivalent security package so that users can create, update, and delete
data sets.
6. Verify connectivity requirements between the DataHub Support/MVS host
and DataHub/2 workstation.
7. If running in a JES3 environment, ensure that the DataHub Support/MVS Tool
Dispatcher is executing on the JES3 global processor.
8. Determine whether there is a need, due to site-dependent restrictions or
requirements, for a TSO OUTPUT command exit or a jobcard exit.
5.4.2 Installing DataHub Support/MVS Platform and Tools Feature
DataHub Support/MVS is installed using SMP/E. The installation does not differ
from other IBM product installations; that is, create the JCL to read the tape,
allocate the required SMP/E CSI, allocate the SMP/E data set and initialize the
CSI zones, and use unloaded jobs for Receive, Apply, and Accept the product.
The above process should be repeated twice: once for DataHub Support/MVS
Platform installation and a once for the DataHub Support/MVS Tools Feature
installation. The installation procedure is very easy, but it requires that your
system programmer tailor and set up the MVS requirements.
More details can be found in Chapter 3 of the DataHub Support/MVS Installation
and Operations Guide as well as in the DataHub Support/MVS Program
Directory.
5.4.3 Configuring DataHub Support/MVS Environment
168 DataHub Implementation and Connectivity
This section discusses the configuration process and relates some of our
experiences during our environment customization.
EMQMCI01 CLIST
After the SMP/E installation you need to customize DataHub Support/MVS. This
is done by executing a configuration CLIST called EMQMCI01. The EMQMCI01
CLIST will prompt you, as in the DB2 customization process, with panels where
you should supply parameter information that will replace the defaults to reflect
your environment.
Before running the EMQMCI01 CLIST in our environment, we concatenated
DataHub data sets in the TSO logon procedure (see Figure 121 on page 169).

........................
........................
/*****************************************************************/ +
/* SYSPROC */ +
/*****************************************************************/ +
ALLOC FI(SYSPROC) SHR DA( +
′ DSN230.NEW.DSNTEMP′ +
′ DATAHUB.V110.SEMQMCLB′ +
′ DSN230.DSNCLIST′ +
........................
........................
/*****************************************************************/ +
/* ISPPLIB */ +
/*****************************************************************/ +
ALLOC FI(ISPPLIB) SHR DA( +
′ DSN230.LOCAL.PLIB′ +
′ DATAHUB.V110.SEMQMPLB′ +
′ STWALTE.DDB.PANEL.LIB′ +
′ STL.TEST.PANELS′ +
........................
........................
/*****************************************************************/ +
/* ISPMLIB */ +
/*****************************************************************/ +
ALLOC FI(ISPMLIB) SHR DA( +
′ DSN230.LOCAL.MLIB′ +
′ DATAHUB.V110.SEMQMMLB′ +
′ STWALTE.DDB.MESSAGE.LIB′ +
........................
........................
Figure 121. EMQMCI01 CLIST DataHub Support/MVS Data Set Concatenation
DataHub Support/MVS Data Sets
During both the installation and customization process you should use the data
sets listed in Figure 122 on page 170.
Chapter 5. DataHub Tools Conversation Connectivity 169

DATAHUB.SMP.GLOBAL.CSI DATAHUB.V110.EMQJCL
DATAHUB.SMP.GLOBAL.CSI.DATA DATAHUB.V110.INSTALIB
DATAHUB.SMP.GLOBAL.CSI.INDEX DATAHUB.V110.SEMQMCLB
DATAHUB.SMPLOG DATAHUB.V110.SEMQMDBR
DATAHUB.SMPMTS DATAHUB.V110.SEMQMHDR
DATAHUB.SMPPTS DATAHUB.V110.SEMQMJCL
DATAHUB.SMPSCDS DATAHUB.V110.SEMQMLIB
DATAHUB.SMPSTS DATAHUB.V110.SEMQMLMD
DATAHUB.V110.AEMQMCLB DATAHUB.V110.SEMQMMLB
DATAHUB.V110.AEMQMDBR DATAHUB.V110.SEMQMPLB
DATAHUB.V110.AEMQMHDR DATAHUB.V110.SEMQMPRM
DATAHUB.V110.AEMQMMLB DATAHUB.V110.SEMQMSAM
DATAHUB.V110.AEMQMMOD DATAHUB.V110.SEMQMSLB
DATAHUB.V110.AEMQMPLB DATAHUB.V110.STDB2C.A0060002.TRACE
DATAHUB.V110.AEMQMSAM DATAHUB.V110.STDB2C.J31982.JESMSG
DATAHUB.V110.AEMQMSLB DATAHUB.V110.STDB2C.J31982.TOOLMSG
DATAHUB.V110.A006.TDTRACE
DATAHUB.V110.EMQDB23.SYSDISC
Figure 122. Installation Data Sets
170 DataHub Implementation and Connectivity
Customization Jobs
After you have run the EMQMCI01 CLIST, members are included in the
DATAHUB.V110.SEMQMJCL data set (see Figure 123). These members are jobs
that have to be submitted to finalize the customization process. Most members
are skeletons that will be used during DataHub Support/MVS functions and tool
execution.
EMQBKUP EMQJOB
EMQDB2BB EMQLOAD
EMQDB2BC EMQMAIN
EMQDB2BD EMQRECOV
EMQDB2BL EMQREORG
EMQDB23B EMQUNLD
EMQDB23C EMQUSTAT
EMQDB23D EMQ000D
EMQDB23L EMQ000E
EMQJES EMQ0007
Figure 123. DHS/MVS: DATAHUB.V110.SEMQMJCL Members
When submitting the required jobs you will get an 806 abend (see Figure 124) if
you did not include the C RUNTIME library SEDCLINK and the C common library
SIBMLINK. The SIBMLINK PLI library contains the IBMBLIIA module.
IEF403I STDB2CA - STARTED - TIME=15.32.59
CSV003I REQUESTED MODULE IBMBLIIA NOT FOUND
CSV028I ABEND806-04 JOBNAME=STDB2CA STEPNAME=QSRDB
IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=806 REASON CODE=00000004
Figure 124. DHS/MVS: Abend 806, Module Not Found

DataHub Support/MVS Data Set APF Authorization
DataHub Support/MVS needs to run as APF authorized for using JES and MVS
commands and for performing cross-memory post. In our environment we
included the DATAHUB.V110.SEMQMLIB data set in SYS1.PARMLIB(IEAAPF00)
as shown in Figure 125.
............... ......,
............... ......,
DATAHUB.V110.SEMQMLIB STDB2A,
............... ......,
............... ......,
Figure 125. DHS/MVS Data Set APF Authorization
More details can be found in Chapter 3 of the DataHub Support/MVS Installation
and Operations Guide as well as in the DataHub Support/MVS Program
Directory.
5.4.4 Starting DataHub Support/MVS
Once you have completed the preparation steps, you can start DataHub
Support/MVS, either as a started task or a batch job. We used a batch job to
start DataHub Support/MVS (see Figure 126 on page 172).
Chapter 5. DataHub Tools Conversation Connectivity 171

STDB2AMQ JOB (999,POK),
// ′ DATAHUB/MVS′,
// CLASS=A,MSGCLASS=T,MSGLEVEL=(1,1),
// TIME=1439,NOTIFY=&SYSUID
//**************************************************************
//*
//* DATAHUB SUPPORT/MVS TOOL DISPATCHER
//*
//**************************************************************
//EMQMAIN PROC PRM=EMQOUT#3,DCLS1=Y,TCLS=T,
// OCLS=X,RS=6M
//*
//TD EXEC PGM=EMQMCA02,PARM=′/&PRM ′,REGION=&RS,
// TIME=1440
//STEPLIB DD DSN=DATAHUB.V110.SEMQMLIB,DISP=SHR
//JCLLIB DD DSN=DATAHUB.V110.SEMQMJCL,DISP=SHR
//PARMLIB DD DSN=DATAHUB.V110.SEMQMPRM,DISP=SHR
//*
//EMQMDUMP DD SYSOUT=&DCLS1
//CEEDUMP DD SYSOUT=&DCLS1
//TDTRACE DD SYSOUT=&TCLS,DCB=(LRECL=80,BLKSIZE=6160,RECFM=FB)
//SYSPRINT DD SYSOUT=&TCLS
//STDOUT01 DD SYSOUT=&OCLS
//STDOUT02 DD SYSOUT=&OCLS
//STDOUT03 DD SYSOUT=&OCLS
//STDERR01 DD SYSOUT=&OCLS
//STDERR02 DD SYSOUT=&OCLS
//STDERR03 DD SYSOUT=&OCLS
//SYSABEND DD SYSOUT=&DCLS1
//PLIDUMP DD SYSOUT=&DCLS1
//EMQMAIN PEND
//WALTER EXEC EMQMAIN
Figure 126. DHS/MVS Startup Job
5.4.5 DataHub Support/MVS Connectivity Requirements
172 DataHub Implementation and Connectivity
Before you test DataHub Support/MVS you have to make sure that the
connectivity requirements are in place. In order for DataHub/2 to communicate
with the DataHub Support/MVS and DB2 subsystems that it manages you have to
set the required DRDA and tools conversation connectivity.
DRDA Connectivity
In fact, we suggest that, before you begin to start to install DataHub, you have
your DRDA connectivity implemented and tested. This will make it easy to
determine the causes of eventual connectivity problems.
DRDA connectivity is covered in detail in Chapter 3, “DRDA Connectivity” on
page 31.

DataHub Tools Conversation Connectivity
DataHub tools conversation connectivity, which is an LU 6.2 connection using
DataHub tools conversation protocols, is required between DataHub/2 and
DataHub Support/MVS. The Tool Dispatcher handles the communication
functions for DataHub Support/MVS. It must be defined as a VTAM application.
You define the Tool Dispatcher as you would your applications, that is, update
the ATCCONnn member in your VTAMLST library to include the EMQMACB1
application. You also need to define a LOGMODE that will be used to establish
the characteristics of the session between DataHub/2 and DataHub Support/MVS.
Refer to 5.1, “Key Connectivity Parameters” on page 152 and analyze Figure 110
on page 156 to understand the connections made from DataHub/2 to DataHub
Support/MVS.
The application name and the logmode name are specified during the
customization process. Refer to Figure 127 for the entries you want to activate
when establishing sessions between the DataHub Support/MVS LU and the
DataHub/2 LU.
� �
DataHub Support/MVS Release 1
CONFIGURE TOOL DISPATCHER REQUIRED PARAMETERS
===>
Enter data below:
Started Task ===> EMQMAIN_ Name of procedure member
Steplib ===> ____________________________________________
STEPLIB for DataHub
Support/MVS load module
Trace Flags ===> 00110101101011010001 DataHub Support/MVS trace flags
Application ===> EMQMACB1 VTAM application id
Mode Name ===> EMQMLOGM VTAM logmode name
Maximum Users ===> 25_ Maximum concurrent users
JES Name ===> ____ JES subsystem name
JES Character ===> _ JES command character
� �
Figure 127. DataHub Support/MVS APPL and LOGMODE Entries
If the ACB name is specified on the VTAM APPL statement of the DataHub
Support/MVS Tool Dispatcher, and it is different from the VTAM application
name, then either the VTAM application name or the ACB name can be entered
in the Application field in Figure 127. Nevertheless, the VTAM application name
must be entered in the OS/2 Communications Manager partner LU name
definition for DataHub Support/MVS (see Figure 117 on page 163).
If the ACB name is not defined explicitly in the VTAM APPL definition, it will
default to the VTAM application name, and in this case the VTAM application
name will be entered in the Application field in Figure 127.
You can find the DataHub Support/MVS VTAM APPL definition in the EMQAPPL
member of the DATAHUB.V110.SEMQMSAM data set. In fact, the EMQAPPL
Chapter 5. DataHub Tools Conversation Connectivity 173

174 DataHub Implementation and Connectivity
member includes four VTAM APPL definitions. One VTAM APPL definition is
required for each copy of DataHub Support/MVS you install. Refer to Figure 128
on page 174 for the EMQMACB1 APPL definition.
*
VBUILD TYPE=APPL
EMQMACB1 APPL ACBNAME=EMQMACB1,
AUTH=(ACQ,PASS),
APPC=YES,
SONSCIP=YES,
SECACPT=CONV,
EAS=500,
MODETAB=EMQMODE,
AUTOSES=0
Figure 128. DataHub Support/MVS Tool Dispatcher VTAM Application Name Definition for
EMQMACB1 APPL
You will also find in the DATAHUB.V110.SEMQMSAM data set the EMQMODE
member that contains a modetab definition, which includes two logmodes. Refer
to Figure 129 for the contents of the EMQMODE member.
*/*
*/* LU 6.2 ENTRY SNASVCMG - SERVICE MANAGER SESSIONS
*/*
EMQMODE MODETAB
MODEENT LOGMODE=SNASVCMG, LOGON MODE NAME X
TYPE=0, X
FMPROF=X′13′, FUNCTION MANAGEMENT PROFILE X
TSPROF=X′07′, TRANSMISSION SERVICES PROFILE X
PRIPROT=X′ B0′, PRIMARY LOGICAL UNIT PROTOCOL X
SECPROT=X′ B0′, SECONDARY LOGICAL UNIT PROTOCOL X
COMPROT=X′ D0B1′, COMMON LOGICAL UNIT PROTOCOLS X
RUSIZES=X′8585′, TRANSMISSION SERVICES USAGE FIELD X
PSERVIC=X′060200000000000000000300′, X
PSNDPAC=X′00′, X
SRCVPAC=X′00′, X
SSNDPAC=X′00′
*
* APPLICATION TO APPLICATION LOGMODES
*
MODEENT LOGMODE=EMQMLOGM, LOGON MODE NAME X
TYPE=0, X
FMPROF=X′19′, FUNCTION MANAGEMENT PROFILE X
TSPROF=X′07′, TRANSMISSION SERVICES PROFILE X
RUSIZES=X′8D8D′, TRANSMISSION SERVICES USAGE FIELD X
PSERVIC=X′060200000000000000000300′, X
PSNDPAC=X′00′, X
SRCVPAC=X′00′, X
SSNDPAC=X′00′
*
MODEEND
END
Figure 129. DataHub Support/MVS SNASVCMG and EMQMLOGM Logon Modes

When submitting the DataHub Support/MVS startup job, you might get an error
like that shown in Figure 130 on page 175 if you did not define the DataHub
Support/MVS Tool Dispatcher to VTAM by using the VTAM APPL statement.
$HASP373 STDB2AMQ STARTED - INIT 3 - CLASS A - SYS XA01
IEF403I STDB2AMQ - STARTED - TIME=14.51.59
09 EMQM005C DataHub - Unable to open VTAM ACB. APPLID = EMQMACB1 RC =....
R 9,END
+EMQM025W DataHub - Internal Error - Refer To Trace File ′ DATAHUB.V11....
+EMQM013I DataHub - termination is complete.
...........................................
...........................................
Figure 130. DataHub Support/MVS Startup Error
If you get a startup error, you have to pick up the generated APPL VTAM
definition that has been included as the EMQAPPL member of the
DATAHUB.V110.SEMQMSAM data set and include it in the VTAM definitions.
Because your OS/2 system is connecting to the MVS system or because you
want to manage RDBMSs that are located in that platform, you also need to
define the OS/2 workstation to VTAM. Please refer to Chapter 3, “DRDA
Connectivity” on page 31 for details on how to define your OS/2 workstation to
VTAM.
Please refer to 5.1, “Key Connectivity Parameters” on page 152 for the symbolic
destination name definition that has to be made to enable DataHub/2 to connect
to VTAM (SSCP) and the DataHub Support/MVS that will be accessed in the MVS
environment.
5.5 Configuring VM for DataHub Support/VM
This section presents information that will help you understand how DataHub
Support/VM works. First we briefly introduce the main components of DataHub
Support/VM and explain the main DataHub Support/VM control files you have to
set up to configure DataHub Support/VM. Then we describe how to start and
operate DataHub Support/VM. Finally we discuss a performance consideration.
5.5.1 VM/ESA Service Pool Support Facility
The DataHub Support/VM platform uses the Service Pool Support Facility of
VM/ESA. It is an efficient way of serving an environment in which host
transactions are short. Figure 131 on page 176 shows a simple Service Pool
environment with the resulting path from an APPC connection.
Chapter 5. DataHub Tools Conversation Connectivity 175

Figure 131. VM Service Pool Environment
176 DataHub Implementation and Connectivity
What Is a Service Pool?
A Service Pool consists of several identical virtual machines set up to handle
transactions. Typically, these transactions would originate outside the VM/ESA
system, such as from a workstation. AVS facilitates Service Pool management.
A private gateway LU can have a Conversation Management Routine (CMR)
associated with it whenever Service Pool Support is required. The CMR is
commonly known as the Service Pool manager and is product dependent:
DataHub Support/VM provides its own CMR, which controls the routing from a
workstation to a Service Pool virtual machine through AVS.
Theoretically a Service Pool can consist of up to 100,000 Service Pool virtual
machines sharing the same Service Pool save segment. In Figure 131 the
Service Pool consists of two virtual machines (identified as SPM00000 and
SPM00001).
Why Have a Service Pool?
The Service Pool can increase performance for an environment in which host
transactions are short. The design lets a set of virtual machines remain logged
on, saving initialization time between transactions, with additional virtual
machines logged on only on demand. A Service Pool provides:
• An efficient means of accessing data existing at only one location (in a
common saved segment area). As an alternative to one server, if the private
server is busy, the system can go to another Service Pool machine for
service.
• A general method of supporting SNA-connected independent workstations
that require many short requests for host services.

5.5.2 DataHub Support/VM Operating System Overview
Figure 132 shows the operating system components that are required for
DataHub Support/VM processing. The CMR is loaded into Group Control System
(GCS) private storage, where it executes. AVS and VTAM run as applications
under GCS. The Service Pool machines are private Service Pool machines that
run under the Conversational Monitor System (CMS) operating system.
Figure 132. DHS/VM Operating System Overview
An explanation of these components is as follows:
AVS Console Used to activate and deactivate gateways, monitor
DataHub Support/VM gateways and conversations, and
control GCS tracing.
CMR1 The Conversation Management Routine that manages the
local Service Pool machines (SPM00000 and SPM00001).
The CMR selects a Service Pool machine ID to process the
inbound request from DataHub/2. The CMR executes as
an entity of AVS.
DataHub/2 IBM SystemView Information Warehouse DataHub/2. The
origin of DataHub requests. When an action is selected (for
example, “Load”), a command is sent to DataHub
Support/VM to perform it (or some part of it).
GW1 Gateway LU. All inbound and outbound DataHub tools
conversations for CP are processed through the gateway
LU. One or more DataHub LUs can be defined to VTAM,
each associated with a DataHub Support/VM CMR.
Chapter 5. DataHub Tools Conversation Connectivity 177

SPM00000, SPM00001
The IDs of Service Pool machines on this system that
process requests from DataHub/2. These machines are
private Service Pool machines that run private resource
managers. Each Service Pool machine is capable of
processing any DataHub request and is selected by CMR1
only when available (not currently in use by another
DataHub request).
TH DataHub Support/VM Task Handler (private resource
manager). The controlling routine of the VM host
component that will process a DataHub/2 request. It
controls the Service Pool machine in which the functions of
the DataHub Support/VM tools feature execute to process
DataHub requests. There is a predefined number of
DataHub Support/VM Task Handlers, each executing in its
own Service Pool machine and each processing one
DataHub/2 request at a time.
5.5.3 Configuring DataHub Support/VM Environment
178 DataHub Implementation and Connectivity
Configuration Steps
Figure 133 on page 179 shows the different steps to configure the DataHub
Support/VM environment. These steps are fully described in the DataHub
Support/VM Installation and Operations Guide.

Summary of Steps to Configure the DataHub Support/VM Environment
Notes:
• Perform the steps in order.
• Mandatory steps are preceded by squares (•).
• Conditional steps are preceded by triangles (►).
• Optional steps are preceded by circles (•).
1. • Grant Authorizations to DataHub/2 Host User IDs
a. • Grant authorization to SQL/DS databases.
b. ► Grant authorization to production SFS directories.
c. • Grant authorization to work SFS directories.
2. • Set up AVS Environment
a. • Determine number of Service Pool machines
b. • Define the AVS virtual machine to GCS.
c. • Define gateway LUs to VTAM.
d. • Define/redefine AVS CP directory.
e. • Redefine AVS machine PROFILE GCS (EXEC).
f. • Redefine AVS machine AGWPROF GCS (EXEC).
For each DataHub Support/VM gateway:
a. • Create Service Pool configuration file.
3. • Set up Service Pool Environment
a. • Set up COMDIR NAMES file.
b. ► Create EMQVPROF EXEC.
For each Service Pool machine:
a. • Create Service Pool machine CP directory entry.
b. • Define Service Pool machine PROFILE EXEC.
4. • Customize DataHub Support/VM Files
a. • Customize system configuration file.
b. • Customize tool table.
c. • Customize EMQVTAPE EXEC.
Figure 133. DHS/VM: Summary of Configuration Steps
Chapter 5. DataHub Tools Conversation Connectivity 179

Environment Configuration Overview
Figure 134 is an overview of the main control files required to configure DataHub
Support/VM.
Figure 134. DHS/VM Environment Configuration Overview
180 DataHub Implementation and Connectivity
Files and EXECs Relationship
Figure 135 on page 181 shows the relationship between the DataHub
Support/VM files and EXECs that must be created or customized during
configuration of the DataHub Support/VM environment.

Figure 135. DHS/VM Files and EXECs Overview
AGWPROF GCS The AVS machine′s AGWPROFILE EXEC can be used to
automatically execute the FILEDEF statements for the
Service Pool configuration file and the ACTIVATE and
CNOS statements for DataHub Support/VM gateways.
CMR DataHub Support/VM Conversation Management Routine
CMR Alert File The DataHub Support/VM CMR writes a record to this file,
EMQVCMR ALERT whenever it encounters an error
situation.
CSRV DataHub Support/VM Common Services
DataHub Support/VM Alert File
The components of DataHub Support/VM write to this file
in error situations.
DataHub Support/VM Trace File
The components of DataHub Support/VM write trace
records to this file.
EMQVDCSS EXEC If the DataHub Support/VM Task Handler is to be loaded
into a saved segment, CMS invokes this EXEC to:
• Load the saved segment
• Invoke the DataHub Support/VM Task Handler.
EMQVINIT EXEC If the DataHub Support/VM Task Handler is to be loaded
into the Service Pool machine′s nucleus extension, CMS
invokes this EXEC to:
• Issue a FILDEF for EMQVLOAD LOADLIB on the
DataHub Support/VM production minidisk or SFS
Chapter 5. DataHub Tools Conversation Connectivity 181

182 DataHub Implementation and Connectivity
directory that contains the DataHub Support/VM Task
Handler
• Load the DataHub Support/VM Task Handler into the
nucleus extension
• Invoke the DataHub Support/VM Task Handler.
EMQVPROF EXEC The PROFILE EXEC and the DataHub Support/VM Task
Handler invoke the EMQVPROF EXEC if products required
by DataHub Support/VM are installed in SFS directories.
The EMQVPROF EXEC accesses SFS directories required
for DataHub Support/VM operation.
EMQVPUSH EXEC When the Service Pool machine is logged on, the last step
of its PROFILE EXEC invokes the EMQVPUSH EXEC, which:
• Determines the program to be given control in the
Service Pool machine (by pushing either EMQVINIT or
EMQVDCSS onto the program stack)
• Reads the system configuration file to obtain the
SYSADMIN, RESOURCEID, and DCSS keywords and
passes their values to the EMQVINIT or EMQVDCSS
EXECs.
EMQVTAPE EXEC Tools can invoke this EXEC to request a tape to be
mounted and attached.
PROFILE EXEC Each Service Pool machine′s PROFILE EXEC invokes the
EMQVPROF EXEC if products required by DataHub
Support/VM are installed in SFS directories. The PROFILE
EXEC also invokes the EMQVPUSH EXEC, which
determines the program to be given control in the Service
Pool machine.
PROFILE GCS The AVS machine′s PROFILE EXEC contains the
statements to access the DataHub Support/VM CMR
production minidisk and the GLOBAL LOADLIB commands
for the LOADLIB required to operate DataHub Support/VM.
Service Pool Configuration File
As part of the AGW ACTIVATE GATEWAY command issued
by the DataHub Support/VM operator, the DataHub
Support/VM CMR reads the Service Pool configuration file
to obtain the user IDs of the Service Pool machines to use
for DataHub requests.
TH DataHub Support/VM Task Handler
TOOL DataHub Support/VM Tools Feature
Tool Table This file, EMQVTOOL CONFIG, describes all tools
supported by DataHub Support/VM.
System Configuration File
This file, EMQVSYS CONFIG, is read by:
• The EMQVPUSH EXEC to obtain the SYSADMIN,
RESOURCEID, and DCSS keyword values
• The DataHub Support/VM Task Handler to obtain
configurable values.

Main DataHub Support/VM Control and EXEC File Examples
VTAM: AVS LU Definition
Figure 136 shows an example of the statements used to
define a VTAM application for an AVS gateway to be used
for DataHub Support/VM.
**********************************************************************
* AVS VTAM DEFINITION FOR CONNECTING DHS/VM *
**********************************************************************
AVSVM1 VBUILD TYPE=APPL
*
VDHTOR01 APPL APPC=YES, X
AUTHEXIT=YES, X
AUTOSES=10, X
DLOGMOD=IBMRDB, X
DSESLIM=100, X
DMINWNL=50, X
DMINWNR=50, X
MODETAB=AGWTAB, X
PARSESS=YES, X
SYNCLVL=CONFIRM, X
SECACPT=ALREADYV
Figure 136. VTAM Sample AVS LU Definition for DataHub Support/VM
AVS Profile Definition
Gateways between VM and other platforms are defined in
the AGWPROF GCS file invoked during AVS machine
initialization. Some entries must be added for DataHub
Support. They are highlighted in the Figure 137 on
page 184.
Chapter 5. DataHub Tools Conversation Connectivity 183

184 DataHub Implementation and Connectivity
/* AGWPROF GCS which activates one gateway for global resource */
/* communications and sets values for the session. */
/* DataHub Support */
′ FILEDEF VDHTOR01 DISK POOL CONFIG J′
′ AGW ACTIVATE GATEWAY VDHTOR01 PRIVATE MANAGER EMQVCMG′
′ AGW CNOS VDHTOR01 SJA2015I IBMRDB 10 5 5′
′ AGW CNOS VDHTOR01 SJA2018I IBMRDB 10 5 5′
′ AGW CNOS VDHTOR01 SJA2039I IBMRDB 10 5 5′
′ AGW CNOS VDHTOR01 SJA2019I IBMRDB 10 5 5′
′ AGW CNOS VDHTOR01 SJA2050I IBMRDB 10 5 5′
/* */
/* DRDA Gateways for AVS systems*********************************** */
′ AGW ACTIVATE GATEWAY LUSQLVMA GLOBAL′
′ AGW ACTIVATE GATEWAY LUSQLDB2 GLOBAL′
/* Connection between LUSQLVMA and PS/2 Workstations ************** */
′ AGW CNOS LUSQLVMA SJA2015I IBMRDB 10 5 5′
′ AGW CNOS LUSQLVMA SJA2018I IBMRDB 10 5 5′
′ AGW CNOS LUSQLVMA SJA2039I IBMRDB 10 5 5′
′ AGW CNOS LUSQLVMA SJA2019I IBMRDB 10 5 5′
′ AGW CNOS LUSQLVMA SJA2050I IBMRDB 10 5 5′
/* Connection between LUSQLDB2 and AS/400 (SJA2054I)*************** */
/* SJA2054I for other RDBMS: AS/400, LUSQLVMB,LUDB23,LUDB2B ******* */
′ AGW CNOS LUSQLDB2 SJA2054I IBMRDB 10 5 5′
/* Connection between LUSQLDB2 and a DB2 (LUDB23) ***************** */
′ AGW CNOS LUSQLDB2 LUDB23 IBMRDB 10 5 5′
/* Connection between LUSQLDB2 and a second DB2 (LUDB2B) ********** */
′ AGW CNOS LUSQLDB2 LUDB2B IBMRDB 10 5 5′
...
...
...
Figure 137. DHS/VM: AGWPROF GCS Example
Communication Directory Definitions
Each Service Pool machine needs to define the same
communication directory as defined in the DRDA
environment (see Figure 138 on page 185).

* * * * * * * * * * * *
*UCOMDIR NAMES file on STSQLB requester Machine.
*** * * * * * * * * * *
/* Entry to define the path to access the DB2 server DB2CENTDIST */
:nick.DB23
:tpn.″6DB
:luname.LUSQLDB2 LUDB23
:modename.IBMRDB
:security.SAME
:dbname.DB2CENTDIST
/* Entry to define the path to access the DB2 server DB2REGNDIST01 */
:nick.DB2B
:tpn.″6DB
:luname.LUSQLDB2 LUDB2B
:modename.IBMRDB
:security.SAME
:dbname.DB2REGNDIST01
/* Entry to define the path to access the AS/400 server SJ400DLR1 */
:nick.AS400
:tpn.″6DB
:luname.LUSQLDB2 SJA2054I
:modename.IBMRDB
:security.SAME
:dbname.SJ400DLR1
/* Entry to define the path to access the Local SQL/DS server SQLLDLR01*/
:nick.SQLLOCAL
:tpn.SQLVMA
:luname.*IDENT
:dbname.SQLLDLR01
Figure 138. DHS/VM: COMDIR NAMES File
Service Pool Configuration File
The Service Pool configuration file (Figure 139) contains
the user IDs of the Service Pool machines available to
DataHub Support/VM CMR. This file can have a file name
and file type of your choosing, because a FILEDEF
command is used to define this file in the AGWPROF GCS
file (Figure 137 on page 184). The Service Pool
configuration file is read only during gateway activation.
* First record specifies number of detail records
0002
* start of detail records
SPM00000
SPM00001
Figure 139. DHS/VM: Service Pool Configuration File
System Configuration File
The system configuration file, EMQVSYS CONFIG, is used
by the DataHub Support/VM Task Handler to read any
configurable values (see Figure 140 on page 186). The
most important keyword is RESOURCEID. The name given,
EMQVRSID, must contain the TP name used by DataHub/2
when allocating a conversation to DataHub Support/VM.
Chapter 5. DataHub Tools Conversation Connectivity 185

186 DataHub Implementation and Connectivity
* DataHub Support/VM System Configuration File
SYSADMIN=EMQVADM
WORKMODE=H
RESOURCEID=EMQVRSID
Figure 140. DHS/VM: EMQVSYS CONFIG File
Service Pool Machine PROFILE EXEC
Each Service Pool machine needs a PROFILE EXEC (see
Figure 141).
/* PROFILE EXEC for Service Pool Machines */
′ ACCESSM0 ON′
′ SET MSG ON′
′ SET IMSG ON′
′ SET EMSG ON′
′ SET WNG ON′
′ SET RUN ON′
′ ACCESS 19F Z′
′ ACCESS 198 J′
′ ACCESS 195 Q′
′ GLOBAL TXTLIB IBMLIB CMSLIB EDCBASE VMLIB CMSSAA′
′ GLOBAL LOADLIB EDCLINK EMQVLOAD ARISQLLD′
′ SET SERVER ON′
′ SET FULLSCREEN SUSPEND′
′ SET AUTOREAD OFF′
′ SET LANGUAGE AMENG ( ADD ARI USER′
′ SET FILEPOOL VMSYS:′
′ SET COMDIR FILE USER UCOMDIR NAMES *′
′ ESTATE ARISRMBT MODULE A′
′ IF RC = 28 THEN′
′ SQLINIT DB(SQLLDLR01) PROTOCOL(AUTO) SSSNAME(ARIQSTAT)′
′ EXEC EMQVPUSH′
EXIT
Figure 141. DHS/VM: PROFILE EXEC of SPM00000 and SPM00001 Machines
Note: The SQLINIT DB(SQLLDLR01)... statement does not
mean that this Service Pool machine can access only this
database. SQLINIT is done only to set up the SQL/DS
bootstrap modules. A transaction from DataHub/2 can run
on any Service Pool machine against any database located
at this host.
Tool Table Example All tools supported by DataHub Support/VM are specified
in the tool table, EMQVTOOL CONFIG (see Figure 142 on
page 187). The DataHub Support/VM Task Handler reads
the tool table to determine the tool program to invoke.
The tool table is read only during Service Pool machine
logon.

* Data Support/VM Tool Table
0002 EMQ EMQVL00 01010 09-30-1993 Load Utility
0004 EMQ EMQVR00 01010 09-30-1993 Reorg Utility
0005 EMQ EMQVU00 01010 09-30-1993 Unload Utility
0007 EMQ EMQVM00 01010 09-30-1993 Copy Utility
000D EMQ EMQVN00 01010 09-30-1993 Display Status at Host
000E EMQ EMQVQ00 01010 09-30-1993 Display Status at RDB
3000 XMP XMPVTIME 01010 12-15-1993 Sample Tool
Figure 142. DHS/VM: EMQVTOOL CONFIG File
5.5.4 Operating DataHub Support/VM
This section describes how to operate DataHub Support/VM.
Activating DataHub Support/VM Gateways
Figure 143 illustrates the flow for the AGW ACTIVATE GATEWAY command for
gateway1. The steps of the communication flow are as follows:
Figure 143. DHS/VM Communication Flow for ACTIVATE Command
1. The AGW ACTIVATE GATEWAY and CNOS requests are issued from the AVS
console at the VM host, or from the AGWPROF GCS file when the AVS
machine is logged on.
AVS receives the AGW ACTIVATE GATEWAY request, activates the gateway,
and returns the “GATEWAY ACTIVATED” message to the AVS console.
2. AVS Loads the DataHub Support/VM CRR (CMR1) into GCS private storage
and invokes it with an ACTIVATE event.
Chapter 5. DataHub Tools Conversation Connectivity 187

3. The DataHub Support/VM CMR (CMR1) reads and validates the Service Pool
configuration file with a ddname matching the gateway name in the AGW
ACTIVATE GATEWAY request.
4. If there are no errors during validation, the DataHub Support/VM CMR
(CMR1) invokes CP to log off all of the Service Pool machines. The message
“userid LOGGED OFF” is displayed on the AVS console for each Service
Pool machine that is logged off (“userid” is the Service Pool machine ID).
The DataHub Support/VM CMR (CMR1) then returns control to AVS. The
DataHub Support/VM CMR (CMR1) then returns control to AVS.
5. AVS returns messages from the DataHub Support/VM CMR (CMR1) to the
AVS console. See “DataHub Support/VM CMR Messages and Codes” in the
DataHub Support/VM Installation and Operations Guide.
If the gateway has been activated successfully and the DataHub Support/VM
CMR did not return any error messages, the gateway is ready to receive
requests from DataHub/2
Allocating Conversations
Once a DataHub Support/VM gateway is activated, communication between
DataHub/2 and DataHub Support/VM can begin. Figure 144 illustrates the
communication flow for an ALLOCATE conversation request. SPM00000 is the
Service Pool machine user ID that will be autologged when needed.
Figure 144. DHS/VM Communication Flow for ALLOCATE Command
188 DataHub Implementation and Connectivity
The following sequence of events illustrates the flow of an inbound DataHub/2
request to a DataHub Support/VM host:
1. A remote program issues an ALLOCATE conversation with a private DataHub
resource. The remote program specifies a target LU, target transaction
program name (TPN) pair as (GW1,TH). TH (Task Handler) is the resource

name specified in the system configuration file under the RESOURCEID
keyword. GW1 is defined to VTAM as being owned by AVS, so VTAM routes
the request to AVS.
2. Because DataHub Support/VM CMR (CMR1) is associated with GW1, AVS
invokes it.
3. The DataHub Support/VM CMR (CMR1) passes back to AVS the selected
Service Pool machine ID to be used by the conversation. The Service Pool
machine selected can be any machine from the Service Pool configuration
file that is available (not currently in use by another DataHub request). In
Figure 144 on page 188, CMR1 passes back SPM00000 as the Service Pool
machine ID.
4. AVS translates the incoming connection request to an APPC/VM CONNECT
request for a private resource TH located at SPM00000.
5. CP verifies that the DataHub/2 user ID and password pair that was sent is
valid. If the pair is not valid, the connection request is rejected and a
connection is not established. If the pair is valid, CP routes the verified user
ID to SPM00000.
6. If SPM00000 is not logged on, CP automatically logs it on and executes the
PROFILE EXEC.
7. CMS invokes either the EMQVINIT or EMQVDCSS EXEC. In this example, it
invokes the former, which loads the DataHub Support/VM Task Handler from
the EMQVLOAD LOADLIB. (The EMQVDCSS EXEC would load the DataHub
Support/VM Task Handler from a saved segment.)
8. SPM00000 DataHub Support/VM Task Handler establishes a conversation
with the remote DataHub/2 program.
Completing Conversations
Once the conversation with the remote DataHub/2 is established, the
conversation can be completed. Figure 145 on page 190 illustrates the
conversation flow for the remainder of the conversation.
Chapter 5. DataHub Tools Conversation Connectivity 189

Figure 145. DHS/VM Communication Flow for Completing Conversations
5.5.5 Performance Consideration
190 DataHub Implementation and Connectivity
To complete the conversation, the following sequence of events occurs:
1. Data passes back and forth between DataHub/2 and the DataHub
Support/VM Task Handler in the Service Pool machine, using the services of
VTAM, AVS, CP, and CMS. The DataHub Support/VM CMR (CMR1) is not
invoked again until conversation deallocation.
2. The DataHub Support/VM Task Handler receives the request from DataHub/2
and determines which tool to invoke.
3. The tool processes the request (it may invoke SQL/DS) and returns control to
the Task Handler.
4. The Task Handler returns a message to DataHub/2 indicating that the tool
has completed.
The main performance consideration in the DataHub Support/VM platform is the
number of Service Pool machines associated with a gateway through one CMR.
This number depends on:
• Number of DataHub/2 users attached to the VM host
• Length of time for the average request (For example, requests for Copy Data
and Utilities will run longer than requests for Display Status; therefore more
Service Pool machines are required for these types of requests.)
• Maximum number of tasks running at the same time
• Future expansion considerations.

Recommendations
• Initially, it is recommended that there be at least 1 Service Pool machine
for 1-10 DataHub/2 workstations connected to the VM host.
• If the usage on VM host is frequent, 2 Service Pool machines are
recommended for each 2-5 DataHub/2 workstations.
• If there are a large number of DataHub/2 workstations and the usage on
the VM host is infrequent, 1 Service Pool machine is recommended for
each 1-25 DataHub/2 workstations.
Note: Having more Service Pool machines than needed does not incur additional
CPU overhead (except for their maintenance), because there will only be as
many Service Pool machines running as needed during the peak period.
You can monitor Service Pool machine usage by referring to the CMR alert file,
EMQVCMR ALERT, on the AVS machine′s A-disk. If there are not enough Service
Pool machines available to process DataHub/2 requests, this file will contain
many occurrences of the following record:
WARNING: Service Pool machine not available. Symptom data is: gateway name.
5.6 Configuring AS/400 for DataHub Support/400
The SystemView Information Warehouse DataHub Support/400 program product
handles the CPI-C conversation with the DataHub/2 workstation and coordinates
requests to function on the AS/400 host.
We do not cover all the installation and configuration tasks in detail because
they are explained in the DataHub Support/400 Installation and Operations Guide.
The tasks required to install and configure DataHub Support/400 are:
• Configure APPC.
• Configure DRDA.
• Install DataHub Support/400.
5.6.1 AS/400 Network Definition
• Verify the DataHub Support/400 installation.
• Create the QEMQUSER collection.
• Bind DataHub/2 to the AS/400,
• Bind DataHub Support/400 to the other hosts (if necessary).
• Bind other DataHub Support hosts to the AS/400 host.
• Configure DataHub Support/400 as a prestart job (optional).
The detailed steps to define the AS/400 in the network are described in 3.6,
“AS/400 Definitions” on page 60.
Chapter 5. DataHub Tools Conversation Connectivity 191

5.6.2 Configuration Considerations
DataHub Support/400 configuration is very simple. This section gives some
important tips that clarify some AS/400 caracteristics.
AS/400 RDBMS Considerations
The AS/400 has an integrated relational database. Therefore an RDBMS does not
have to be installed.
DataHub/2 and all DataHub products can only access or manage OS/400
database objects that are located in an OS/400 collection.
QEMQUSER Collection
After the installation of DataHub Support/400 you must execute the
QDMU/QSTUTCCL program. The program creates the QEMQUSER collection.
The QSTUTCCL program does not require the SAA SQL/400 program product.
To execute this program enter the CALL QDMU/QSTUTCCL. command.
Binding DataHub Support/400 to Other Hosts
To use all the DataHub/2 functions, the DataHub Support/400 program must be
bound to all other RDBMSs. To do this, sign on to the AS/400 system as
QEMQUSER user and enter the following control language command:
CRTSQLPKG QDMU/QSTCSQL RDB(xxxxxxxx)
where xxxxxxxx is the name of the RDBMS to which you want to bind DataHub
Support/400.
DataHub Support/400 as a Prestart Job
DataHub Support/400 can optionally be set up as a prestart job. This means that
the DataHub Support/400 task is ready to begin processing whenever DataHub/2
requests work to be done. The prestart job provides better performance when
DataHub/2 accesses the AS/400 system.
To use DataHub Support/400 as a prestart job, do the following:
1. Determine the subsystem in which DataHub Support/400 jobs run. The IBM
supplied defaults are QBASE and QCMN.
If you want to set up a separate subsystem for DataHub Support/400,
consider the following:
a. You need to have communications entries in the subsystem for each of
the DataHub/2 workstation services running DataHub/2.
b. You need to add the prestart job entries to the subsystem.
c. You must start the subsystem before you start QCMN or QBASE.
2. Stop the subsystem.
3. Add a prestart job entry as follows:
ADDPJE SBSD(subsystem_name) PGM(QDMU/QSTSC)
The other parameters can be varied, depending on the expected use of the
product and your environment.
Refer to the AS/400 Work Management Guide, SC41-8078, for more
information on prestart jobs.
4. Start the subsystem.
192 DataHub Implementation and Connectivity

5.7 Configuring OS/2 for DataHub Support/2
5.7.1 OS/2 Host Components
This section covers all the OS/2 definitions that allow the DataHub/2 workstation
to manage OS/2 Database Manager databases. It shows how to customize the
different components used for DataHub tools conversation connectivity. Because
the OS/2-managed host must be a participant in the DRDA and the RDS network,
you should have already implemented this OS/2 host in that network. (See 3.7,
“OS/2 Definitions” on page 69.)
This section does not cover how to install the DataHub Support/2 component.
You should refer to the DataHub Support/2 Installation and Operations Guide for
more information.
The same prerequisite components are required on the DataHub Support/2 host
as on the DataHub/2 workstation. The only exception is that DataHub/2 requires
the server version of OS/2 Database Manager because the DataHub/2
workstation will need to access that machine as a client using the RDS protocol.
The DDCS/2 software is not required if this OS/2 host does not connect to a
DRDA server to transfer data from or to it (for example, the DataHub copy data
operation).
What is different from a DataHub/2 workstation are the definitions that will be
required. The DataHub/2 workstation needs to know all the hosts that are
managed by the DataHub/2 product. The OS/2-managed host needs to know
only the host(s) to which data will be transferred in a copy operation.
If you use one host as a data repository from where you copy data, all the
managed hosts have to know that repository host and need to connect to it. If
you use the OS/2 Database Manager system to capture data that eventually will
be transfered to a central site, the OS/2 Database Manager system needs to
know only one system.
OS/2 Host Component Relationship
Another difference between the DataHub/2 workstation and the DataHub
Support/2 hosts is the relationship between the different components.
Figure 146 on page 194 shows the key connectivity parameters relationship on
the OS/2-managed host. It shows only the tools conversation flow on this
workstation. To understand the RDS connectivity, you should refer to Figure 46
on page 71 and follow the Inbound request: CONNECT.
The tools conversation request that has been sent by the DataHub/2 workstation
contains the following information:
• Logical unit name
• Network ID
• Mode name to use
• Transaction program name that will process the request locally
• Data that will contain the RDB name.
The program that is associated with the transaction program name will execute
the request and connect to the OS/2 Database Manager database using the RDB
name mapping information provided in the DataHub Support/2 map file.
Chapter 5. DataHub Tools Conversation Connectivity 193

The map file name and location are defined by the RDBNAMEMAP parameter in
the DataHub Support/2 configuration file. The configuration file name and
location are defined by the SET EMQ2SYS parameter in the OS/2 CONFIG.SYS
file.
Figure 146. DHS/2: OS/2 Component Relationship Diagram
5.7.2 DataHub Support/2 Customization
Three files need to be customized to enable DataHub Support/2 to work properly:
• OS/2 configuration file (CONFIG.SYS)
• DataHub Support/2 configuration file
• DataHub Support/2 map file.
194 DataHub Implementation and Connectivity

OS/2 Configuration File (CONFIG.SYS)
When you install the DataHub Support/2 product, many lines are updated, and
this line is inserted:
..............
SET EMQ2SYS=\EMQ2SYS.CFG
..............
where indicates the directory in which the DataHub Support/2
product is installed. This line sets up the OS/2 system variable EMQ2SYS so
that, when the DataHub protocol handler program is started by OS/2
Communications Manager, the program knows where to find the DataHub
Support/2 configuration file.
DataHub Support/2 Configuration File
The DataHub Support/2 configuration file contains many entries. One entry is
very important for connectivity purposes: the RDBNAMEMAP parameter. This
parameter points to the map file that associates a DataHub/2-defined RDB name
with an OS/2 Database Manager database alias name.
Note: Because this entry is not included during install, you need to add it
yourself. Figure 147 shows the definitions we used.
* DataHub Support/2 Configuration File
TOOLTABLE=D:\EMQ2\EMQ2TOOL.CFG
ALERTPATH=D:\EMQ2\ALERT
TRACEPATH=D:\EMQ2\TRACE
RDBNAMEMAP=D:\EMQ2\DHS2.MAP
Figure 147. DHS/2: Configuration File (EMQ2SYS.CFG)
DataHub Support/2 RDB Name Map File
A map file is necessary to map an RDB name to an OS/2 Database Manager
database alias name. If the RDB name and the database alias name are the
same, no entry is necessary. Figure 148 shows you the map file we used for the
ITSC network. All the RDB names are defined because we want to be able to
copy from one RDB name to another. In a real production environment, you
might need only one or two entries.
The first column represents the RDB name as defined in the DataHub/2
database. The second column is the OS/2 Database Manager database alias
name. You should compare this figure with the System Database Directory
window in Figure 120 on page 167.
DB2CENTDIST MNYCENT
DBMMTLDLR1 OMTLDB
DBMRIODLR1 ORIODB
DBMPARDLR1 OPARDB
SQLDDLR01 VTORDB
SJ400DLR1 ASJDB
Figure 148. Map File (DHS2.MAP)
Chapter 5. DataHub Tools Conversation Connectivity 195

5.7.3 OS/2 Communications Manager Definitions
The OS/2 Communications Manager is required on a DataHub Support/2 host.
This section explains which components you need to customize. It also explains
in detail the two components that are specific for a DataHub Support/2
implementation.
First you need to add this host to the SNA network. In addition to the physical
connection (which we do not discuss in this document except for the token-ring
connection), you will need to customize OS/2 Communications Manager for the
proper SNA definitions. Specifically, you need to:
• Define the local node characteristic.
• Add or change a conncection to a host, which includes defining the partner
logical unit (remote RDB).
• Add mode (if necessary).
These definitions are explained in detail in “IDBLK, IDNUM, Network ID, Logical
Unit Name, SNA Control Point Name” on page 77. The following definitions are
specific to DataHub Support/2 and are explained below:
• Transaction program name
• Conversation security.
Transaction Program Name
The transaction program name is an alias for a DataHub Support/2 program
name. The alias can be any name, but it must be the same name as the name
used in the symbolic destination name definition. The example shown in
Figure 119 on page 165 is for the DataHub Support/MVS component, which
could be any name. For the DataHub Support/2 component the TP name must
be the same at both ends (that is, the DataHub/2 workstation and the DataHub
Support/2 workstation).
To add a transaction program definition, you need to start the OS/2
Communications Manager setup program and go through the windows until you
get to the SNA Features List window. This procedure is documented in “IDBLK,
IDNUM, Network ID, Logical Unit Name, SNA Control Point Name” on page 77.
Then follow this procedure:
196 DataHub Implementation and Connectivity
1. Select the Transaction program definitions line from the SNA Features List
window.
The already defined transaction program will appear in the list box. As can
be seen in Figure 149 on page 197, no definition exists.

Figure 149. SNA Features List Window (Transaction Program Definitions)
2. Click on the Create... push botton.
The Create a Transaction Program Definition window will the appear.
3. Fill in the appropriate information.
The transaction program (TP) name alias must be the same name as defined
in the DataHub/2 workstation.
The OS/2 program path and file name must indicate the directory in which
DataHub Support/2 is installed. The name of the program for the actual
version of DataHub Support/2 is EMQ2T.EXE.
You also need to specify conversation security if you want to protect the
execution of this program from a remote location. You will define later what
security will be used for this TP program. Figure 150 on page 198 shows the
TP name definition we used for all our OS/2 managed hosts.
4. Click on the Continue... push button when you have finished.
The Create Additional TP Parameters window will then appear (Figure 151
on page 198).
Chapter 5. DataHub Tools Conversation Connectivity 197

Figure 150. Create a Transaction Program Definition Window
5. Click on the Background radio button in the Presentation type field.
6. Click on the Non-queued, Attach Manager started radio button in the
Operation type field.
7. Click on the OK push button.
198 DataHub Implementation and Connectivity
The SNA Features List window (Figure 149 on page 197) should then
reappear with the new TP name added to the list box.
Figure 151. Create Additional TP Parameters Window
Conversation Security
Conversation security protects access to local ressources from a remote system.
The definition simply tells OS/2 Communications Manager to use the OS/2 User
Profile Management security system instead of specific userid and password
definitions.
The conversation security specifications are done from the SNA Features List
window. These are the steps to be performed from that window:

1. Select the Conversation security line.
The list of userids defined will be shown in the list box. As shown in
Figure 152, none is defined, and we will need to create one entry.
2. Click on the Create... push button.
Figure 152. SNA Features List Window (Conversation Security)
The Create Conversation Security window will then appear (see Figure 153
on page 200).
3. Click on the Utilize User Profile Management check box.
A generic ID (*) will then appear in the User ID field as shown in Figure 152.
4. Click on the Add push button.
Chapter 5. DataHub Tools Conversation Connectivity 199

Figure 153. CM/2: Create Conversation Security Window
A refreshed Create Conversation Security window will appear with the
generic ID (*) to indicate that the UPM security system is used for
conversation security (Figure 154 on page 201).
5. Click on the OK push button.
200 DataHub Implementation and Connectivity

Figure 154. Create Conversation Security Window (After Definition)
The SNA Features List window will reappear with the generic ID added to the
list box.
5.7.4 OS/2 Database Manager Definitions
Your OS/2 Database Manager directories must be customized to enable
DataHub/2 and DataHub Support/2 to connect. OS/2 Database Manager
directory entries are necessary for:
• Each local database managed through the DataHub/2 workstation
• Each remote RDBMS to which this system will connect for the copy function.
Most OS/2 Database Manager customers use the same database name for
databases that are spread throughout a network. For each of the OS/2 Database
Manager managed databases, two entries are required in the System Database
directory:
1. One entry with the same value for the alias and the database name. This
entry is added when the database is created.
2. One alias to the real database name. This alias must be unique in the
DataHub/2 network. A nomenclature must be decided on in order to help
you define those aliases.
Refer to 3.7.5, “DRDA Definitions” on page 86 for the different steps involved in
defining OS/2 Database Manager directories.
Chapter 5. DataHub Tools Conversation Connectivity 201

5.8 Recommendations
We recommend that you use a meaningful naming convention for every name
you create. Establish a plan to define the names that you will use in the OS/2
Communications Manager and the hosts with which you want to connect and
identify the names that must match. The object names you must consider are:
• Host name
• RDB name
• Symbolic destination name
• LU name
• Partner LU alias name
202 DataHub Implementation and Connectivity
• OS/2 DBM database alias name.
We recommend that your organization′s database administrator (that is, the
DataHub/2 user) coordinate the installation and testing of the DataHub Support
components . to ensure that the local DataHub/2 workstation definitions match
the managed host definitions.

Chapter 6. Problem Determination
6.1 Implementation Strategy
This chapter provides guidelines to help you perform problem determination. As
a DataHub/2 user, you probably will be the first to discover that a problem exists.
Some problems, such as those caused by incorrect local definitions, will be easy
to resolve locally. This chapter explains the tools you have on your DataHub
Support workstation to perform problem determination.
Usually, the DataHub/2 user is a database administrator who knows what to do
with RDBMS problems. But problem determination in a complex environment
like distributed databases will be a team effort. The DataHub/2 user will need
help from host personnel.
Host personnel have many tools and logs they can use to help DataHub/2 users
perform their problem determination tasks. These tools and logs are discussed
in the host problem determination sections later in this chapter.
Despite the availability of host problem determination aids, we recommend that
you have a Help Desk to assist you in determining the source of network
problems.
Before describing problem determination, let us review some key
implementation strategy recommendations. A good implementation strategy will
eliminate many of the problems that you could encounter later with DataHub.
Before implementing your DataHub environment, we highly recommend that you
install and test, step by step, all components starting with the lowest level of
security. We suggest, for example, that you use the same userid and password
for all the RDBMS hosts and the DataHub/2 workstation. To avoid problems
related to security and authorization checking, at least when you get started, that
userid should have database administration privileges on all RDBMS systems.
Let us assume that all RDBMSs are operational and used locally by applications.
Your distributed databases may not be implemented yet, because of lack of
remote management tools like the DataHub family of products. In this case, your
distributed systems would be installed in a development environment for
application development and testing.
The principal steps we highly recommend are:
1. Install the DRDA and/or RDS environment on one RDBMS host.
2. Install the DRDA and/or RDS environment on the DataHub/2 workstation.
3. Test the DRDA and/or RDS connectivity between the RDBMS host and the
DataHub/2 workstation.
4. Install the DRDA and/or RDS environment on all the other RDBMS hosts that
will be managed.
5. Test the DRDA and/or RDS connectivity between the new RDBMS hosts and
the DataHub/2 workstation.
© Copyright IBM Corp. 1993 203

6.2 DataHub/2 Workstation
204 DataHub Implementation and Connectivity
6. If a function such as Copy Data is to be used, customize and test the DRDA
and/or RDS environment for RDBMS-to-RDBMS connectivity for the hosts
that will be involved in the copy operation.
Now that the DRDA and/or RDS environment is operational, you could start
implementing the DataHub products:
1. Install and customize DataHub/2 on the DataHub/2 workstation.
2. Test the DataHub/2 customization using a local database (for example,
SAMPLE created using the OS/2 Database Manager SQLSAMPL program).
3. Test the DataHub/2 customization using a remote RDBMS.
4. Install one of the DataHub Support components on one of the hosts.
5. Customize the DataHub Support host. Then test the connection between the
DataHub/2 component on the DataHub/2 workstation and the new DataHub
Support component. We suggest that you use:
• Run JCL Function with DataHub Support/MVS
• RDBMS WORK with DataHub Support/VM and DataHub Support/400
• Copy Function with DataHub Support/2.
See “Appendix C: Verifying your DataHub installation” in the DataHub/2
Installation and Administration Guide for more information.
6. Install the other DataHub Support components on the other hosts.
7. Customize the DataHub Support host. Then test the connection between the
DataHub/2 component on the DataHub/2 workstation and the new DataHub
Support components.
Now that you have implemented the easiest function, you could start using the
Copy Data function, which involves two different host RDBMSs:
1. Test the Copy Data function between two RDS hosts (that is, OS/2).
2. Test the Copy Data function between two DRDA hosts.
3. Test the Copy Data function between one DRDA host and an RDS host (that
is, OS/2).
Note: The number of steps involved in using the Copy Data function depends
on your configuration.
Now that you have tested DRDA and DataHub tools conversation connectivity,
you can increase the complexity of your environment by implementing more
security in the system, if your company policies so require.
In this section, we discuss connectivity problems only and not other types of
problems that could occur on the DataHub/2 workstation. You must refer to the
DataHub/2 Installation and Administration Guide (SC26-3043), appendixes D and
E, and the DataHub/2 Message Reference (SC26-3042) for a complete picture of
problem determination.
The tools that are discussed in this section are the:
• DataHub/2 log file

6.2.1 DataHub/2 Log File
• EMQDUMP command
• OS/2 Communications Manager trace utility
• DataHub/2 trace utility.
• DDCS/2 trace utility.
Other tools exist on the DataHub/2 workstation. For example, reports are
produced during DataHub/2 operation and can be used for operations-related
problem determination.
You may also have to use other tools that relate to OS/2 Database Manager and
OS/2 base operating system problems. For such problems you should refer to
the DATABASE 2 OS/2 Messages and Problem Determination Guide, which
explains in detail such tools as FFST/2 and OS/2 dumps.
The DataHub/2 log file is certainly the most important tool the DataHub/2 user
has for problem determination. As soon as a problem appears on the DataHub/2
message window, the DataHub/2 user should immediately view the DataHub/2
log file. Why? Let us explain.
Problem determination starts when an error message appears on the DataHub/2
message window. If the message is self-explanatory, you can correct the
problem using the DataHub/2 documentation as a reference.
But many times, the message is a general message like this one:
010 DataHub D:\EMQDIR\EXE\DATAHUB.EXE 1993-03-20-10.49.01.31
EMQ9018I The program, EMQQS.EXE, ended with the return code, 12, for the action,
DISPLAY.
For such messages, you will need to display the DataHub/2 log file. You can find
this file in the directory specified by the CONFIG.SYS SET
EMQDIR= configuration parameter. The directory could contain
many log files, depending on the number of DataHub/2 programs active on your
workstation.
Recommendation
Because you will need to access the log file very frequently, we recommend
that you create an object on the OS/2 desktop that will start an OS/2 editor
session passing the name of the log file as a parameter. This is explained in
4.8, “Recommendations” on page 148.
Recommendation
Because the log file could become very big, we suggest that you rename the
active log file and, if disk space is important, archive the old files for future
reference. The sample messages we are using in this section are taken from
our old log files.
Chapter 6. Problem Determination 205

When you open the log file, the problem you are looking for is stored at the end
of the file. Make sure the problem on which you are working is the “good” one
by verifying the date and time information.
Frequently, the error will create multiple entries in the log file. The first entry is
the most important one. For example, for the general error message presented
above, these were the log file entries:
011 DISPLAY D:\EMQDIR\EXE\EMQQS.EXE 1993-03-20-10.48.40.28
EMQ9251W Exceptional return code, CM_TP_NOT_AVAILABLE_NO_RETRY, received from
communication service, CMRCV.
010 DataHub D:\EMQDIR\EXE\DATAHUB.EXE 1993-03-20-10.49.01.31
EMQ9018I The program, EMQQS.EXE, ended with the return code, 12, for the action,
DISPLAY.
Some problems consist of four entries in the log file. A line with dashes
separates the different DataHub/2 sessions.
Recommendation
206 DataHub Implementation and Connectivity
In a LAN server configuration, the user data, which includes the log file,
should be put on the user′s workstation as explained in 4.4.3, “Installation
Environment Preparation” on page 119. Such placement will prevent having
entries for different users in the same log file.
Now that you know the real source of the problem, the most current problems
should be easy to solve. Just by looking into the log file, we were able to fix
many common user customization and installation problems, such as:
• DataHub/2 database not found or defined
• OS/2 Database Manager database alias name not defined (or incorrectly
entered in the DataHub/2 database configuration)
• Improper authority on the DataHub/2 package
• DataHub/2 package not bound to the target RDBMS
• No DataHub/2 user profile entry defined for the target RDBMS
• Lack of resources in OS/2 Database Manager, for example:
− Communication heap size (comheapsz)
− RDS heap size (rsheapsz)
− Maximum number of remote connections (numrc)
• Lack of resources in the DataHub/2 database
− Maximum active applications (maxappls).
Many of the messages are OS/2 Database Manager messages because
DataHub/2 uses OS/2 Database Manager to execute most functions.
A good part of the problem determination solution is to understand the
protocol(s) used by each DataHub/2 function. Refer to 1.2, “DataHub Data Flows:
Overview” on page 6 for the protocols used by the different DataHub/2 functions.
If the function that fails is a display of tables, you will not need to find problems
related to the tools conversation protocol.

6.2.2 EMQDUMP Command
In 1.2, “DataHub Data Flows: Overview” on page 6 you will find a table that
associates the protocol with the DataHub/2 function. All the functions, except
one, use one protocol. Because the copy data function may consist of multiple
steps that use different protocols, you need to know at which step the problem
occurred.
Now, let′s say that a problem is not of the easy-to-determine category. For
example, you will surely have few of the problems shown here:
011 DISPLAY H:\EXE\EMQSGPRO.EXE 1993-03-03-15.53.07.66
SQL30080N A communication error ″000F-00000000″ occurred sending or receiving
data from the remote database. SQLSTATE=58019
This problem will certainly be familiar to you:
011 DISPLAY H:\EXE\EMQSGPRO.EXE 1993-03-03-17.07.37.44
SQL30080N A communication error ″0003-00000004″ occurred sending or receiving
data from the remote database.
The SQL30080N message is the most common communication message. It
occurs when OS/2 Database Manager tries to establish a session with another
RDBMS. The good news is that this not a DataHub/2 problem.
For more difficult problems like those listed above, you will need to use different
tools and even consult with other specialists.
The EMQDUMP command (that is, EMQDUMP.CMD) gathers diagnosis and
configuration information from the DataHub/2 workstation and puts it all in one
file. This file can be used for problem determination by your support personnel
or sent to an IBM support service representative.
The EMQDUMP command creates an EMQDUMP.ZIP file containing the following
information:
• CONFIG.SYS file
• DataHub/2 configuration, log, and trace files
• OS/2 Communications Manager configuration files (.NDF, .SEC, .CF2, .CFG)
• OS/2 Database Manager configuration information
• DataHub/2 database tables (IXF format)
• Directory listings of DataHub/2 directories
• Install level files (.LVL)
• OS/2 SYSLEVEL information.
For more information regarding use of the EMQDUMP command refer to the
DataHub/2 Installation and Administration Guide.
Chapter 6. Problem Determination 207

6.2.3 OS/2 Communications Manager Trace Utility
The OS/2 Communications Manager trace utility is to be used when an LU 6.2
error appears in the DataHub/2 log file or when you are using OS/2 Database
Manager directly through the command line processor interface or a program
other than DataHub/2.
The LU 6.2 errors are easy to recognize. First, they appear with the OS/2
Database Manager SQL30080 message when there is a DRDA or RDS
connectivity problem. Second, they consist of two parts (for example,
0003-00000004). The first part is the primary return code, and the second part is
the secondary return code.
Recommendation
Before implementing DRDA and DataHub, we recommend that you make sure
you have these books available in your organization to help with problem
determination:
• IBM Extended Services for OS/2 Communications Manager APPC
Programming Reference (S04G-1025) or Communications Manager/2 APPC
Programming Guide and Reference (SC31-6160)
• Systems Network Architecture Formats (GA27-3073)
• Systems Network Architecture Format and Protocol Reference Manual:
Architecture Logic for LU Type 6.2 (GC30-3269)
The IBM Extended Services for OS/2 Communications Manager APPC
Programming Reference (S04G-1025) contains a chapter that explains what these
primary and secondary return codes mean. If you cannot figure out what the
words means, you should contact your communications specialist for help. This
specialist could ask you to perform a local trace. Another solution is to trace on
the host side (MVS, VM, or AS/400).
To understand the trace, you need to understand the format of the data flowing
through the network. The most important code to find is the sense code that is
sent by the remote Control Point to indicate why the session has not been
established. If you understand the LU 6.2 formats and protocols, you will be able
to do exact problem determination.
To create a trace file from OS/2 Communications Manager, you need to:
• Start the OS/2 Communications Manager trace facility specifying what you
want to trace (for example, IBMTRNET, APPC). The way you start the trace
varies among the different versions of OS/2 Communications Manager.
• Reproduce the error.
• Stop the OS/2 Communications Manager trace facility.
• Format the trace.
208 DataHub Implementation and Connectivity
To start an OS/2 Communications Manager APPC trace, you can use a command
from the OS/2 command line. The following command is the command you use
to trace APPC on the token-ring network:
CMTRACE START /API APPC SERVICES /DATA IBMTRNET /STORAGE 16 /EVENT 1 2 3 4 5 12

6.2.4 DataHub/2 Trace Utility
After the trace is started, you need to reproduce the problem and then issue the
APPNF command to format the trace data that has been stored in
memory (that is, STORAGE 16 (16K)). The APPNF stops the trace
and creates three files with three different suffixes:
.TRC Unformatted trace. Normal OS/2 Communications
Manager trace format. A good knowledge of the LU 6.2
formats and protocols is required to understand the trace.
.DET Formatted trace. This file contains the field names and
their associated values. It is easier to read than the .TRC
file. But a good understanding of the LU 6.2 protocol is
required to understand the field names, their use, and
their possible values. For example, from this file, you can
get the sense code value to explain why you are getting
the famous APPC return code 0003-00000004.
.SUM Summary of the formatted trace. This file contains a
summary of the LU 6.2 session. It does not contain any
detailed information to help you do problem
determination.
It is of no use to do a trace if you do not understand it or if no one in your
organization understands it. The good news is that there is another solution to
APPC traces: talk with your host support personnel and exchange your
definitions. As a DataHub/2 user, you should use your customized .NDF file
which can be found in the :\CMLIB (CM/2) or the
:\CMLIB\APPN (Extended Services for OS/2) directory.
You need to exchange with your communications specialist the DRDA key
connectivity parameters as indicated in Table 3 on page 37 and Table 4 on
page 37, and the DataHub key connectivity parameters as indicated in Table 18
on page 152. Perhaps your definitions match, but the problem is that the partner
logical unit (for example, DB2, SQL/DS AVS machine, OS/2 host) is not
operational. Another possibility could be that you run into a host or NCP
capacity problem if you cannot allocate a session at prime shift when you know
that your definitions are good.
You use the DataHub/2 trace utility to solve connection problems for the
functions that use the tools conversation protocol as indicated in 1.2, “DataHub
Data Flows: Overview” on page 6. For example, the only way to find which
symbolic destination name DataHub/2 passes to OS/2 Communications Manager
is to use the DataHub/2 trace utility.
The DataHub/2 trace utility enables you to trace everything that is happening on
your DataHub/2 workstation. If you activate the DataHub/2 trace with all the
available options, you will end up with a trace file that will be too big and, even
worse, your response time will be significantly degraded.
The DataHub/2 trace facility is available from the Trace... action in the Options
pull-down menu on the DataHub/2 main window.
You should trace only the necessary components. For connectivity problems,
you activate these check boxes from the DataHub/2 Trace Controls window:
Chapter 6. Problem Determination 209

• Perform Trace
− On the PWS platform
− On the PWS tools
− On the host (if necessary)
• Trace Controls for Communications Manager
− Entry/Exit
− Input
− Output
• Trace Controls for Tools conversation flows (internal).
For an understanding of the CPI-C (Common Programming Interface -
Communications) verbs that are used between DataHub/2 and OS/2
Communications Manager, consult the SAA Common Programming Interface
Communications Reference (SC26-4399).
6.2.5 Distributed Database Connection Services/2 Trace Utility
All the tools we have discussed up until now are used for SNA connection
problems. Problems also can occur with the DRDA connection, however. The
DDCS/2 SQLJTRC utility provides a record of the data exchanged between the
DDCS/2 gateway workstation and the host RDBMS.
The SAA Distributed Database Connection Services/2 Version 2 Guide explains
how to use this utility. You will also need to understand the DRDA verbs and
protocols. Those are explained in these documents:
• IBM Distributed Data Management Architecture Level 3:
(SC21-9526)
Reference
• Distributed Relational Database Problem Determination Guide (SC26-4782).
6.3 MVS Host Problem Determination
To help customers and IBM technical professionals find solutions for their
communication problems, this section explains how to analyze problems in the
MVS environment. First it addresses the DataHub Support/MVS trace
mechanisms. It suggests an approach to problem diagnosis, reviews the
communication problem types, and explains in general how to deal with each
problem type. It also addresses DB2 and DDF error messages.
6.3.1 DataHub Support/MVS Trace Files
210 DataHub Implementation and Connectivity
DataHub Support/MVS uses the Tool Dispatcher trace file, which contains
diagnostic information for all activity within the Tool Dispatcher, and trace files,
which contain diagnostic information for all activity for a particular conversation
with a single DataHub/2 workstation
During the DataHub Support/MVS customization process you provide information
to set up the default trace options and DASD characteristics on where to put the
trace records when the trace mechanism is activated. Basically two panels are
involved in this setup. Refer to Figure 155 on page 211 and Figure 156 on
page 211 where you can see the values we supplied during customization.

� �
DataHub Support/MVS Release 1
CONFIGURE TOOL DISPATCHER REQUIRED PARAMETERS
===>
Enter data below:
Started Task ===> EMQMAIN_ Name of procedure member
Steplib ===> DATAHUB.V110.SEMQMLIB_______________________
STEPLIB for DataHub
Support/MVS load modules
Trace Flags ===> 00110101101011010001 DataHub Support/MVS traceflags
Application ===> EMQMACB1 VTAM application id
Mode Name ===> EMQMLOGM VTAM logmode name
Maximum Users ===> 25_ Maximum concurrent users
JES Name ===> JES2 JES subsystem name
JES Character ===> $ JES command character
� �
Figure 155. DataHub Support/MVS Trace Parameter Specification
The default trace flags are “00110101101011010001,” where 1 indicates “on” and
0 indicates “off.” Refer to Chapter 4 of the DataHub Support/MVS Installation and
Operations Guide for more details on the meaning of the trace flags.
The file where the traces are recorded as well as the interval of the conversation
trace are set up in the customization panel shown in Figure 156. In our case
defaults are used for most of the parameters.
� �
DataHub Support/MVS Release 1
CONFIGURE TOOL DISPATCHER OPTIONAL PARAMETERS
===>
Enter data below:
Conversation Trace Datasets:
Device Type ===> SYSDA___
Volume Serial 1 ===> STDB2A Volume Serial 2 ===> ______
Space Units ===> ____ CYLS, TRKS, or BLKS
Primary ===> _____ In above units
Secondary ===> _____ In above units
Block Size ===> _____ Multiple of 80
Retention Period===> ____ Days to retain the trace data set
Refresh rate in seconds:
Tools ===> ____ Monitor active tools
Conversations ===> ____ Monitor active conversations
� �
Figure 156. DataHub Support/MVS DASD Trace Data Set Definition
Chapter 6. Problem Determination 211

A DataHub user can request tracing to be done for both the DataHub
Support/MVS platform feature and tools feature. The Tool Dispatcher trace is
initiated by the MVS operator. Tracing to the conversation′s trace file is initiated
by the DataHub/2 workstation user. Refer to “Tracing on DataHub Support/MVS”
in the DataHub Support/MVS Installation and Operations Guide for details on how
to activate and deactivate the tracing facility at the Tool Dispatcher when it is
started as a started task or a batch job. Also refer to DataHub Support/MVS
Installation and Operations Guide, Appendix B, for the initialization parameter
defaults.
The Tool Dispatcher trace file name has the format “xxx.Annn.TDTRACE,” where
in our environment it is “DATAHUB.V110.TDTRACE” (see Figure 157).
� �
EDIT ---- DATAHUB.V110.A006.TDTRACE -------------------------- COLUMNS 00
COMMAND ===> SCROLL ===>
****** ***************************** TOP OF DATA ************************
000001 4 1993-03-18-15.35.34.336129 EMQMCR01 CS IE
000002 5(01000020)(000E) 49 - åáXà‰à•àjä•äåäbä„àãá‘àlàià„à«ànà{àòàgàuà•
000003 6on file ′ DATAHUB.V110.STDB2C.J31982.RESULT′ .
000004 4 1993-03-18-15.35.35.577628 EMQMCR01 CS IE
000005 5(01000020)(000E) 46 - ä•äåäbä„à㢰ñ_àòàgàuà•à“ä - remove on fi
000006 610.STDB2C.J31982.RESULT′ .
000007 4 1993-03-18-15.35.35.842220 EMQMCR01 CS IE
000008 6(01000020)(000E) Function EMQMCR01: Returned from function sSendE
000009 4 1993-03-21-07.26.31.595502 EMQMCC01 CS IE
000010 5(00000000)(0000) Data received from conversation not allocated, V
000011 60, Conv key= ????
****** **************************** BOTTOM OF DATA **********************
� �
Figure 157. DataHub Support/MVS DATAHUB.V110.A006.TDTRACE Data Set
Refer to the DataHub Support/MVS Installation and Operations Guide for the
trace file formats.
The trace files, which contain diagnostic information about all activity for a
particular conversation with a single DataHub/2 workstation, look like the file
shown in Figure 158.
� �
EDIT ---- DATAHUB.V110.STDB2C.A0060002.TRACE ----------------- COLUMNS 00
COMMAND ===> SCROLL ===>
****** ***************************** TOP OF DATA ************************
000001 11993-03-18-15.35.35.095715Error Log
000002 4MNYCENT 1993-03-18-15.35.35.137122 EMQMCR01 CS IE
000003 549 - åáXà‰à•àjä•äåäbä„àãá‘àlàià„à«ànà{àòàgàuà•à“ä - fopen on
000004 6V110.STDB2C.J31982.RESULT′ .
****** **************************** BOTTOM OF DATA **********************
� �
Figure 158. DataHub Support/MVS DATAHUB.V110.STDB2C.A0060002.TRACE Data Set
6.3.2 An Approach to Problem Diagnosis
212 DataHub Implementation and Connectivity
In any error situation, it is important to understand the circumstances under
which a problem is occurring, so that information pertinent to the problem can
be gathered.

For example, a user has reported receiving an SNA sense 084E0000 when trying
to access data at a remote site. The sense code in the manual suggests that
invalid session parameters are being sent. This information indicates that the
session is probably just being established, and that the BIND parameters may
not be acceptable to one of the LUs. The BIND parameters are taken from the
LOGMODE entry used for the session.
With this in mind, to diagnose the problem, we need more information on the
circumstances surrounding the problem. For example, you might want to use a
display command to check whether there are any sessions with this remote site.
If there are, were they established using the same LOGMODE entry as that being
used by the failing session attempt? Has this LOGMODE ever successfully
established a session, or is it only newly installed? Have any changes been
made recently to the LOGMODE table? (For example, has the table been
reloaded using a MODIFY command just prior to the start of the problem?)
Usually, the LOGMODE will be newly installed or recently changed.
At this stage, you might want to check any changes. If this does not help
determine the problem, the next step is to take a VTAM buffer trace of the
session setup and find the PIU that caused the bad sense. In this set of
circumstances, it will probably be a BIND PIU. Check which LU rejected the bind;
that is, which LU sent the negative response (with the sense).
Remember that the bind flows first from PLU to SLU, and that a BIND response
then flows from SLU to PLU. This BIND response may contain parameters that
have been altered by the SLU. From the VTAM buffer trace, using the Systems
Network Architecture Formats (GA27-3136), you can work out each parameter
and probably determine which parameter is causing the BIND to be rejected. If
the problem still has not been found, comparing the failing parameters with
those on a working session establishment between two DDF LUs may be of help.
In this example, we started with an SNA sense code. Checking the sense code in
the manual put us in the session setup area. We knew how the session setup
should occur, so we could look for changes or problems in that particular area.
We did not, for example, look into buffer usage, whether VTAM CPU utilization
was high, and so forth. These points were extraneous and could have further
complicated the problem during the diagnosis.
Often, the key to a problem is found by looking up the codes received in the
relevant manual. Too often, a lot of time is wasted by not really understanding
the problem. A rational approach to understanding the problem and the
situation that caused the problem may resolve the problem quickly and prevent
the same problem from reoccurring.
6.3.3 Communication Problem Types
The VTAM Diagnosis manual has a chapter on the procedures to be used when
diagnosing each particular problem type. Please refer to that chapter in
conjunction with reading this section.
Chapter 6. Problem Determination 213

Abends
All programs may abnormally end (abend) at one time or another. Most
applications have some sort of recovery processing for avoiding actual
termination of the application. VTAM is fairly typical in this respect and usually
attempts to recover before terminating.
VTAM abends fall into two categories: those where the abend occurs in the
VTAM address space, and those where the abend occurs in the VTAM code in a
user (for example, DDF) address space.
The link pack area (LPA) contains a lot of VTAM code that is accessible by all
address spaces. Remember that VTAM has many of its control blocks in the
common service area (CSA). These control blocks are also accessible by all
address spaces. In this way, each address space can do a certain amount of
VTAM processing in its own address space. In general, this is I/O processing:
sending and receiving data across the application interface. Therefore the DDF
address space may abend in a VTAM module and cause a dump of the DDF
address space to be taken.
VTAM has several MVS abend codes that are reserved for VTAM′s use only.
These are ABEND0A7, 0A8, 0A9, 0AA, 0AB, 0AC and 0AD. The most commonly
occurring of these abends is ABEND0A9. The value in general purpose register
15 (GPR15) gives some indication of the problem.
Sometimes the ABEND0A9 is preceded by an ABEND0C4. Always look for an
indication of a previous error. This could be another abend, or an error
message to the user or the console. It is not necessarily a VTAM message and
may not occur immediately before the abend. LOGREC is a good source for
finding abends that may have been missed on the console by the operators. It is
important to start diagnosing a problem when the first sign of trouble occurs, as
later problems are often part of the aftermath of the original problem. Recovery
routines will normally retry the failing process before eventually terminating.
If there is no other indication of a problem, check whether a dump has been
taken. For an ABEND0C4 or ABEND0A9, usually an SVC dump of the address
space will be taken. In general, for complete diagnosis of a VTAM problem, the
CSA needs to be dumped.
From the dump, you should be able to determine the location of the failure. This
is often included in a dump summary, formatted at the top of the dump. Using
this information you can check in INFOSYS (if INFOSYS is available at your site),
for known problems in this area. If INFOSYS is not available or a fix cannot be
found, you should call the IBM Support Center with the following information to
find an answer to the problem:
• Abend code
• Failing module name
214 DataHub Implementation and Connectivity
This information can be gathered from the dump, or sometimes from the
console log messages issued at abend time. If the module name is not
included in the dump summary information, locate the PSW address (second
word of the PSW) in the dumped storage. Work backward through the dump
(toward zero) until an eyecatcher is encountered. The eyecatcher includes
the module name. All VTAM module names start with IST. (The eyecatcher
is alphanumeric data usually written at the front of the module. It can be
read from the EBCDIC conversion area on the right-hand side of the dump.

For example, in the dump, the module name could be
x′C9E2E3D6D9C6C2C1′. In the EBCDIC conversion area, you would see
′ISTORFBA′.)
• Offset of PSW into this module
Usually, just before the eyecatcher is an x′47....′ instruction, which branches
around the eyecatcher and into the module code. This instruction is the start
of the module. Subtract the address of this instruction from the PSW address
to determine the offset. Remember that this is in hex, not decimal. If the
module is in the LPA, an LPA map can be generated. The LPA map
indicates the start of the module. Work out the offset using this start
address.
• Latest maintenance to hit this module
This information can be gathered either from the dump or by using SMP/E.
Again, find the eyecatcher, which will normally include an assembly date and
the latest PTF to be applied to the module. Write down both the assembly
date and the PTF number.
• Registers at the time of the abend
This information can be taken from either the console log or the dump.
Register 15 sometimes contains a return code that will assist in problem
diagnosis; for example, on an ABEND0A9.
• Recent maintenance applied
PTFs or APARs that have been recently applied may have contributed to the
circumstances that caused the problem.
• Recent changes to the system
In general, problems occur only after changes have been made to a system.
Keep an open mind when looking at recent changes. Even changes that
appear totally unconnected may be the cause of the problem.
• Frequency of the abend
How often the abend has occurred can give some idea of the magnitude of
the problem. If the abend occurs frequently, something fairly fundamental is
wrong. If it is a one-time occurrence, an obscure set of circumstances,
perhaps timing related, may have caused the problem.
The IBM Support Center personnel may request additional information. The
console log around the time of the abend and the dump should be kept, in case
further diagnosis of the problem requires more information from the dump.
Hang Situations
When the problem is a hang, it can be very difficult to determine its cause.
Always look for any indication of a problem on the console log. If the log
contains nothing of immediate interest, try to determine the extent of the hang.
Try to put the users that are hung into groups with common characteristics:
• Are only users of one particular application hung?
For example, local DB2 (on DBD1) requests are working, but requests to
another remote DB2 (DBD2) are hanging. Some areas that could be
investigated include:
− What is the status of the remote application LU (LUDBD2)?
Chapter 6. Problem Determination 215

216 DataHub Implementation and Connectivity
A D NET,ID=,SCOPE=ALL command issued on the host
owning the application indicates whether the application is active and
has any sessions with the local DDF. If the status is not ACTIV, check
the meaning of the status in the manual and take appropriate action.
The same command issued on the local host displays the CDRSC status.
Make sure this is ACTIV (or ACT/S) also.
− Are sessions already set up?
The command given above indicates whether there are active sessions.
Three sessions are required for system use: one with a LOGMODE of
SNASVCMG, and two with SYSTOSYS LOGMODE. If there are no
sessions, check the virtual route between the subareas.
− Are the sessions working?
By repeating the displays, check the send and receive counts on the user
sessions. Also, a DISPLAY THREAD(*) DETAIL command shows whether
there is a conversation on each session. The user may be hung waiting
for a conversation to end. When a session becomes available for a new
conversation, the user′s remote database access is processed.
− Are local requests on the remote host (DBD2) working?
If not, this would appear to be a problem on the other host. Look for an
abend, loop, or wait problem. Check the remote host console for any
relevant messages. Check whether DB2 commands on the remote host
(DBD2) work.
For example, if no commands work, this could mean a problem in DB2.
If most commands work, but a cancel thread command does not, this
may indicate a problem in either the DDF address space or VTAM.
If local requests are working, the problem would appear to be in either
the network or the DDF address space.
− Is the virtual route between the two subareas open and active?
Use a D NET,ROUTE command to see whether the virtual route is
operational. If the virtual route is blocked, there could be a host or an
NCP storage shortage problem somewhere in the network.
− Is any network traffic flowing between the two hosts?
Check whether there are any other network users hung. If there are, this
hung is most likely a network problem.
− Is the CDRM to CDRM session between the two hosts active?
A D NET,ID= command can be used to display the
status of the CDRMs, both of which should be ACTIV.
• Are all the hung users in one particular part of the network?
For example, all hung users may have terminals on one controller. In this
case, the problem could be the controller. Display the status of the
controller, for it may need to be recycled. Another example: all the hung
users are accessing the network through one particular link, and the link has
many errors. Slow responsetimes could therefore result because of error
recovery and retries. Investigate the link problem.
When a device or line connected to an NCP becomes inoperative (INOP),
NCP generates a Miscellaneous Data Record (MDR). MDRs are sent to the
owning SSCP. They are found in LOGREC and can be viewed by requesting

an EREP report. The MDRs can also be seen online using the NetView
Hardware Monitor (or an equivalent) product. These records contain
information on why the resource became INOP. They are very useful for
problem determination.
• Are all users that are in session working and only those that are causing a
session to be established hung?
In this circumstance, the problem could be a VTAM problem. Remember
that most of the send and receive data processing is done in the user′s
address space. All session establishment is done in VTAM′s address space.
Check the following areas:
− VTAM commands
Do VTAM commands work? If they do, VTAM is working. If they do not,
VTAM may be in a wait (unlikely) or loop (more likely) or perhaps is
unable to get a share of the CPU.
− CPU usage
Does any particular address space have very high CPU utilization? If so,
monitor this, as the address space could be in a loop.
− VTAM paging
Is VTAM doing a large amount of paging? If so, what looks like a loop in
VTAM could be VTAM running a very long chain of control blocks.
• Are all users hung?
If so, this is could be a more fundamental problem with the operating
system. Check whether any MVS commands are working.
In any hang situation, the results (or lack of results) from a variety of displays
can give a clear picture of the scope of the problem. The more information that
is available, the easier the problem diagnosis is, and, usually, the faster the
resolution will be. It is a discouraging and time-consuming task to try to find a
problem in a VTAM dump when all you know is that there is a hang.
If the hang only occurs on a session when one particular request is made, often
a VTAM buffer trace can be used to see the last PIUs flowing on the session.
These PIUs can often hold the key to the problem.
Loops
When a loop is suspected, a variety of actions can be taken:
• CPU usage
Usually a loop can be readily found by displaying CPU usage. Of course, it
is necessary to have some idea of “normal” CPU usage for the suspected
address space, for comparison purposes. In general, any address space
using an unusually high amount of CPU should be suspect.
• Paging rates
The paging rates can be monitored to check for any abnormally high rates.
Of course, “normal” usuage is again needed for comparison purposes.
• Loop recording
The 3090 and 308X CPUs have a hardware facility to record up to 490 PSWs.
This facility is activated from the hardware console and can be used to trace
a loop. The output is dumped when an SVC or stand-alone dump is taken.
Chapter 6. Problem Determination 217

This can be very helpful when debugging a loop problem. For more
information on this facility, consult the documentation for your particular
CPU.
• VTAM internal trace
If the VTAM internal trace (VIT) is active, this can give some insight into the
problem. If the loop causes entries to be written to the VIT, the trace table
will probably wrap before the operators have determined that VTAM is in a
loop. However, if the loop does not cause trace entries to be written, the VIT
can be invaluable in determining the event that initiated the loop.
• Dumps
When a loop is encountered, not much can be done to recover the situation.
Usually, a dump will have to be taken and the system restarted. Dumps can
be taken in any of the following ways:
− MVS dump command
If the CPU has multiple processors, MVS commands may still be working.
If so, requesting a dump of the looping address space may be sufficient
to obtain a dump.
− Restart dump
If the CPU has only a single processor, a restart dump can be taken.
− Standalone dump
If neither of the above dumping methods is appropriate, a standalone
dump can be taken. Normally, this is the least efficient choice, as the
entire system is taken down, and an IPL is required to recover.
With a multiprocessor CPU a loop can appear as degraded performance. For
example, if the CPU has four processors and one is processing the loop, this
leaves three CPUs for normal processing. This reduction in processing power
will normally cause some performance degradation. Any users associated with
the looping address space will normally be hung.
Before calling the IBM Support Center, try to have the following information
available:
• Looping modules
Try to determine the modules involved in the loop using VTAM Diagnosis
(LY30-5601).
• Maintenance level of the module(s)
Gather this information from SMP/E.
• Messages
Look for any messages on the console that may have triggered the loop. If
one message is being issued repeatedly, include it in the description of the
loop.
• Trace output
Have available the output from any traces taken, together with any
information you have obtained from the trace.
• Dump
218 DataHub Implementation and Connectivity

• Console log
Have these available in case further diagnosis is required.
Storage Shortage
Storage shortages can manifest themselves in any of the following ways:
• VTAM messages
A VTAM message indicating a storage shortage may be received at the
console. This message normally indicates the MVS subpool where the
shortage has occurred. Using this subpool number, the area of storage
experiencing the shortage can be determined. For example, subpool 231
(SP231) is CSA, while subpool 17 (SP17) is in the address space private area.
The most common storage shortage problems involve CSA. VTAM uses
large amounts of CSA for its control blocks and buffers containing data that
is being sent around the network. This problem can occur for a variety of
reasons. For example, if one application is flooding another with data, and
the second application is unable to receive the data and process it at an
adequate rate, the buffers build up in VTAM storage. This situation can be
avoided by using session pacing.
If VTAM is unable to get enough storage to issue a message, the normal
storage shortage message is accompanied by an IST999E message.
• RCPRI and RCSEC
The primary return code (RCPRI) and secondary return code (RCSEC) are
both given to DDF when an APPCCMD macro has completed. On occasion,
these codes may indicate that there is a storage shortage in VTAM.
For example, if RCPRI is x′0084′ and RCSEC is x′0000′, there was a storage
shortage while VTAM was receiving data or sending a pacing response. An
RCPRI of x′0098′ with RCSEC of x′0000′ indicates there is a temporary
storage shortage while sending data. Usually this return code means that
the send request has temporarily depleted the buffer pool to such an extent
that the pool must be expanded. The expansion had not occurred before the
completion of the APPCCMD macro.
• SNA sense code
Some SNA sense codes indicate there may be a storage shortage. For
example, a user may be accessing data from the remote database and
receive ′084C0000′. Checking this sense code in the manual tells us that
there is a permanent insufficient resource condition. This resource could be
storage. Other sense codes, such as ′800A000′, indicate a storage type
problem, but not necessarily a storage shortage.
• Abends
Several MVS abends (for example, ABEND878 and ABEND80A) indicate
storage shortage problems. These are uncommon in VTAM.
• Hangs
Depending on the storage shortage and the processing that is occurring, the
storage shortage could manifest itself in a hang situation. For example, if a
virtual route becomes blocked because of storage shortages, all the sessions
that had been using that session will hang until the storage shortage is
relieved and the virtual route reopens.
Chapter 6. Problem Determination 219

When you receive any of these indications of a storage shortage problem you
can use the following steps to find out more information about the shortage:
• Determine the area of storage shortage
This is important, as the VTAM display command has information about the
VTAM CSA usage. This will not help diagnosis if the storage shortage is in
VTAM private. However, CSA usage should probably be checked anyway.
The area can be determined by checking the MVS subpool number (for
example, as given in a message). The following subpools are in the CSA
area: SP227, SP228, SP231, SP239, and SP241.
• Display buffer usage
If the storage shortage has occurred in one of the CSA subpools, a D
NET,BFRUSE command can be used to determine the amount of CSA storage
VTAM is using.
Within this display, look for VTAM pools that have been expanded many
times. Usually the buffer use display gives a good idea of which VTAM pool
is causing the storage shortage.
• Monitor buffer usage
When looking at a buffer shortage, it is often helpful to know whether the
onset of the problem was gradual or immediate. If regular buffer usage
displays are done, gradual increases in buffer use can be seen. These
gradual increases may take days to manifest themselves as storage
shortage problems. In fact, if VTAM is taken down regularly, the storage
shortage symptom may never be seen.
Another benefit of regular monitoring of the buffers is that, when a problem
does occur, “normal” buffer usage for that host is known, so the buffer
values can be compared.
If the onset of the buffer shortage is very fast, check the system console (or
log), looking for some event that has triggered the problem. The event could
be virtually anything. For example, an NCP has a problem and large
amounts of data that were heading out onto the network are now caught in
VTAM while recovery of the NCP is attempted.
• Take a dump
To determine the cause of the problem, a dump is usually necessary. When
taking the dump, be sure to include CSA in the dumping options. Without
CSA the dump is almost useless. The VTAM Diagnosis manual has a
discussion on how to find each of the VTAM pools and which control blocks
are allocated in each pool.
• Traces
220 DataHub Implementation and Connectivity
The SMS option on the VTAM Internal Trace can be very helpful when
looking at storage-related problems. When used in conjunction with other
options (PSS, SSCP, and PIU, for example), the SMS option can provide
insight into the processing that is causing the storage shortage.
The SMS storage trace can be used to monitor the buffer pool usage if
regular displays are inconvenient.

Storage shortage problems fall into the following main categories:
• No session pacing
In this case, the VTAM IO buffers (IOBUFs) are being flooded by one
application. Finding the IOBUFs in the dump can often lead to the
application at fault. Usually the problem will have started after the
introduction of (or changes to) an application. Look for any changes in the
system that could have caused the problem.
• Control blocks not freed
There have been problems in the past where control blocks were not freed
when they were no longer needed. These control blocks gradually fill large
amounts of CSA. This type of problem can normally be found with a search
in INFOSYS, if this is available at the site, or RETAIN, if a call is placed with
the IBM Support Center. If a known problem is not found, the IBM Support
Center should be contacted for further problem diagnosis.
• Buffer pool unable to expand
If the buffer pool has been scheduled for expansion by VTAM, but for some
reason is unable to expand, a storage shortage error may be received. This
could be a transient condition while the buffer pool is being expanded.
If this is not a transient condition, check that the pool is eligible for
expansion; that is, an expansion limit and expansion number have been
assigned to the buffer pool. If dynamic expansion has not been allowed, the
pool may have used all of its base allocation. In this case, the base
allocation should be increased.
Diagnosing storage shortage problems can be quite difficult. However, in
general, with a dump and an idea of where the shortage occurs, the problem
source can be identified.
When contacting the IBM Support Center, have available as much relevant
information as possible. Remember to check for any changes that have been
made at the site. Many applications use VTAM′s services. Changes made for
one application may adversely affect another application.
Incorrect Output
Incorrect output problems can take a variety of forms. In general, the problems
can be grouped into two categories. In the first category, the remote access
request fails and an SQL return code and SNA sense code are received. In the
second category the request works, but the data received is inconsistent.
Request fails with return code: When a remote database access fails, normally
the user receives a DB2 DDF message. The message and error code should be
investigated and, depending on the type of error, the appropriate action taken.
For example, a user receives an SNA sense code of x′800A0000′. Checking this
sense code in the SNA Formats manual tells us that either the PIU was too long
or the buffering available for the PIU was insufficient.
To diagnose the problem, it would be easiest to look at the PIUs to check that
the length is not over the RUSIZE maximum that we have defined in the
MODETAB entry for this session. Remember we defined an RUSIZE of 4K. To
do this, we should take a VTAM buffer trace of the attempted remote access.
This is done by starting the trace with ID=. In a DB2 to DB2
environment, we have the option of tracing eihter (or both) of the DB2 systems:
Chapter 6. Problem Determination 221

222 DataHub Implementation and Connectivity
that is, the local and/or remote DB2 LU. If the remote DB2 system is traced, we
see the PIUs (and the lengths of these PIUs) that the remote DB2 is sending.
Because large amounts of data will be coming from the remote host, these large
PIUs are more likely to be too long than the smaller requests from the local DB2.
If the local DB2 is traced, we should see the large PIUs arriving from the remote
DB2. In this trace we would look for a PIU that has the sense included as part of
the RU.
In fact, in this example, the trace of the remote LU did not show the sense code.
The PIUs leaving the remote DB2 had a length in the TH of x′1003′. This length
includes the 4K x′1000′ data RU and three bytes of RH. So, the PIU had a total
length of x′101D′ including the TH. This should be acceptable.
However, the trace of the local DB2 LU shows each of these large PIUs with the
800A0000 sense. So, the PIUs have left the remote DB2 normally, but
somewhere along the path between the two hosts, the buffering available for the
PIU was insufficient.
Now that we know a bit about the problem, a search in INFOSYS (or a call to the
IBM Support Center for a RETAIN search) uncovers an informational APAR that
indicates that the MAXBFRU specifications should be checked on any links
between the two hosts. (MAXBFRU is the maximum amount of storage available
for buffering a PIU destined to flow over that link.) In our case, the MAXBFRU
specification on our CTC was allowed to default to one 4K page. Our PIU was 4K
plus the TH and RH, so there was insufficient buffering available for our PIU. It
was truncated and given the ′800A0000′ sense code, which was then returned to
the user. Increasing the MAXBFRU definition resolved the problem.
Often a search in INFOSYS or a RETAIN search will reveal information on the
effect of particular VTAM definitions. This will often lead to a resolution, if not
directly, then indirectly, by indicating new areas that can be checked for errors.
Of course, each problem must be treated individually, depending on the
information received from the sense codes. Often a VTAM buffer trace will help
in understanding a problem that results in a SNA sense code. From the trace,
you can see exactly what is happening on the session and the sequence of
events leading up to the issuance of the sense.
Inconsistent Data: Under normal circumstances, the network will not cause
inconsistent data. Remember that if there is a network problem, all the network
users are likely to be affected, not just one application. So, inconsistent data is
more likely to be a problem within the database.
For example, if a user does a remote update and the commit fails to complete,
the data on the database could be updated or not, depending on how far the
commit progressed. A DB2 code, for example, x′00D300FE′, may be received
when a DDF thread is cancelled. In these circumstances a local request for the
“updated” data should be made to check the actual state of the data so that
users do not receive inconsistent data.

6.3.4 Being Prepared
Unexpected Messages
Sometimes the first indication of a problem is a message received at the
console. In general, the meaning of the message should be reviewed in the
VTAM Messages and Codes or IBM DATABASE 2 Version 2 Messages and Codes
manual and the appropriate action taken.
For example, message DSNL013I VTAM OPEN ACB FAILED ERROR=90 is
received. This message indicates that a problem was encountered while DDF
was trying to open its ACB. The open ACB error code should be checked in
VTAM Programming manual. The error codes are listed in the section describing
the OPEN macro.
In this case, an error code of 90 means that VTAM could not find a resource in
the VTAM definitions that matches the name in the ACB′s APPLID field. This is
probably because the application major node is not active.
Often an open ACB error will be attributable to the ACB not closing properly
when the application was last inactivated. The console log should be checked
around the time of the last inactivation for any sign of an error.
In an environment where software is constantly being upgraded and changed,
problems are virtually unavoidable. Spending some time in preparation for
those problems can sometimes decrease the impact and resolution time for the
problem.
For example, if the problem is well documented the first time it occurs, you may
have enough information to determine the cause of the problem and thus avoid
having to re-create the problem to gather additional documentation. If you do
have to re-create the problem, getting all the required information at that time
will prevent additional re-creation attempts to get even more information.
Re-creating problems, if such an approach is at all viable, can be very
time-consuming and should be kept to a minimum.
With this in mind, we suggest that you check the following items at your site:
• Number of dump data sets
Make sure an adequate number of data sets are available. These data sets
should be checked regularly for dumps and cleared out. The dumps should
not be deleted without first diagnosing the problem.
In some circumstances, a dump is essential to further problem diagnosis.
Without a dump, diagnosis stops until the problem occurs again. A dump
lost because of full dump data sets can cause an extra outage that could
have been avoided.
• Dump data sets large enough
Ensure that the dump data sets are large enough to take a whole dump.
Partial dumps may not have the required information in them and may thus
necessitate a reoccurrence to get good documentation.
• CSA included in dump options
VTAM has a large number of control blocks in CSA. Whenever a dump is
taken of VTAM, or for a VTAM-related problem, it is essential that CSA be
dumped. Often, without CSA, the problem cannot be determined, and a
Chapter 6. Problem Determination 223

eoccurrence is needed to get more information. CSA should be specified
on the default options for MVS SVC dumps.
• VTAM Internal Trace
The default for the VIT is no tracing options with two pages running
internally. This will log any errors that occur in the system, but without a
time stamp these errors cannot be related to outside symptoms. (Remember,
only the VIT running externally to GTF will have a time stamp.)
In general, if the internal table can be increased to, for example, 50 pages,
and some options are included, the table can be of more use for general
diagnosis. This is merely a precaution, so selection of the VIT options to run
is arbitrary. The SSCP, PSS, MSG, and PIU options would give some idea of
the processing being done by VTAM prior to the dump being taken. Of
course, while actively pursuing a problem, specific options will be required,
and the trace table should be further increased in size. The VIT should not
cause noticeable degradation in performance, although, of course, it does
involve some overhead in CPU utilization. Some options cause more trace
records to be written than others (LOCK, for example).
• GTF
Make sure that the GTF procedure is in place and that the data set collecting
the trace records is large enough. The data set will wrap if it is not large
enough, and important information could be lost.
• Traces
It is important to know how to take traces and format records from the GTF
trace data set. If there is a problem in this area, it should be fixed as soon
as possible. For example, if you have a very severe problem that requires a
trace, it is important that the trace be produced quickly and efficiently. This
is not the time to find out you have a problem in the trace setup—the
resolution of the original problem will only be delayed. Jobs to format the
trace records should be readily available.
• Stand-alone dump
The stand-alone dump facility should be ready and working. If a severe
problem is encountered, often the only way to get a dump is to take a
stand-alone dump.
• Manuals
Manuals containing diagnostic information should be readily available.
Without them, diagnosing the problem may be impossible.
• INFOSYS
INFOSYS and other problem-oriented databases can be invaluable when
trying to determine the cause of a problem. They contain the information on
known problems in the code, as well tips and hints on definitions (and
common problems occurring because of incorrect definitions) and tuning.
• Problem tracking
224 DataHub Implementation and Connectivity
The site should have a system set up for tracking problems. This can be on
paper or on the system. For an ongoing problem, recording each
occurrence, with the available documentation, aids in a clear understanding
of the progress of the problem. In this way, changes in the state of the
problem can be identified, and probable causes for these changes
investigated.

For example, a user has a hang problem. The problem was thought to be
described by an APAR. The PTF to fix the problem described by the APAR
was applied. After this, an intermittent ABEND0C4 occurs. By being able to
refer back to records of the hang problem, perhaps a link between the two
problems can be found. Perhaps there is no link. Without documentation of
the progress of the problems, this possible link would not be investigated.
With a problem tracking system, a colleague can take over a problem when
the original person handling it is unavailable.
• IBM Support Center
The IBM Support Center (or the equivalent support personnel) should be
contacted for difficult problems that cannot be resolved. The telephone
number for the IBM Support Center and the customer number for the site
should be readily available.
6.3.5 Analyzing DB2 DDF Error Messages
In a DRDA environment, if there is a communication problem, you always get an
SQLCODE -30080 (see Figure 159).
� �
DSNE625I CONNECT TO LOCATION DB2REGNDIST01 PERFORMED, SQLCODE IS 30080
DSNT408I SQLCODE = -30080, ERROR: COMMUNICATION ERROR 0008 (0000)
DSNT418I SQLSTATE = 58019 SQLSTATE RETURN CODE
DSNT415I SQLERRP = DSNLVCNS SQL PROCEDURE DETECTING ERROR
� �
Figure 159. DDF: SQLCODE -30080, Communication Error
Figure 160 shows the corresponding MVS console message.
� �
DSNL501I - CNOS PROCESSING FAILED 339
FOR LU LUDB2B AND MODE IBMRDB
RTNCD=00 FDBK2=0B RCPRI=0008 RCSEC=0000 SENSE=087D0001
� �
Figure 160. DB2: DSNL501I Message
Looking up SENSE=087D0001 in the VTAM Messages and Codes manual enables
you to conclude that there was a problem establishing a session between the
SSCPs.
A distributed logical unit of work can run unsuccessfully for any number of
reasons, including the following:
• Local DDF is not started.
• Remote DDF is not started.
• Remote DB2 system is not started.
• VTAM LU is not active.
• VTAM path errors have occurred.
• VTAM failure has occurred.
• Session or conversation failures have occurred.
• DB2 Communications Database entries are incorrect.
• Security failure.
In addition to the IBM DB2 Messages and Codes manual, you should refer to the
DB2 - APPC/VTAM Distributed Database Usage Guide to understand DB2 DDF
error messages.
Chapter 6. Problem Determination 225

6.4 VM Host Problem Determination
This section describes the main tools and facilities available in VM to monitor
and debug the DataHub Support/VM platform.
6.4.1 Monitoring DataHub Support/VM Gateways and Conversation
To query DataHub Support/VM gateways and conversations, use the
AGW QUERY command. as described in VM/ESA Connectivity Planning,
Administration, and Operation.
Query gateways to determine:
• Which gateway is associated with DataHub Support/VM
• The status of DataHub Support/VM gateways.
Query conversations to determine:
• The state of DataHub conversations
• The remote LU
• The alternate user ID
• The state of DataHub conversations
6.4.2 Handling System Messages
226 DataHub Implementation and Connectivity
• The DataHub Support/VM gateway with which the DataHub conversation is
associated
• The path ID (required to deactivate conversations).
While you are running DataHub Support/VM, DataHub Support/VM-related
messages may be displayed on your AVS console. Figure 161 on page 227
shows an example of an AVS console file. The messages in the file are
described below.

Ready;
agw activate gateway oedgwsv2 private manager emqvcmg
Ready;
AGWVTB002I Gateway OEDGWSV2 is activated
1 --► DMKSND045E SQLUSR1 not logged on
CNOS for OEDGWSV2 OMMGWSV1 AGW2AGW1 has been completed
CURRENT VALUES: LIMIT = 0020 WINNER = 0010 LOSER = 0010
CNOS COMMAND VALUES: LIMIT = 0020 WINNER = 0010 LOSER = 0010
AWGWVTC149I End
SQLUSSR1 : Ready; T=0.01/0.02 08:15:33
agw q gateway
Ready;
GATEWAY = OEDGWSV2 PRIVATE ACTIVE CONV COUNT = 00000000
MANAGER = EMGVCMG
AWGWVTC149I End
agw deactive gateway oedgwsv2
Ready;
CNOS for OEDGWSV2 OMMGWSV1 AGW2AGW1 has been completed
CURRENT VALUES: LIMIT = 0000 WINNER = 0010 LOSER = 0000
CNOS COMMAND VALUES: LIMIT = 0020 WINNER = 0010 LOSER = 0010
Ready;
agw activate gateway oedgwsv2 private manager emqvcmg
Ready;
AGWVTB002I Gateway OEDGWSV2 is activated
2 --► SQLUSR1 : CONNECT= 00:02:39 VIRTCPU= 000:000:37 TOTCPU= 000:01:28
3 --► SQLUSR1 : LOGOFF AT 12:01:23 EST FRIDAY 10/01/93
4 --► MSG FROM AVSVM:CSIABD228E Subtask of ′ AGWDSPMN′ failed-System abend 0C1-0000
5 --► EMQV020S Error occurred in CMR while attempting ACTIVATE event.
6 --► EMQV020S Reason Code = 07. DEACTIVATE Gateway CAIBMOML.OEDGWSV2.
CNOS for OEDGWSV2 OMMGWSV1 AGW2AGW1 has been completed
CURRENT VALUES: LIMIT = 0020 WINNER = 0010 LOSER = 0010
CNOS COMMAND VALUES: LIMIT = 0020 WINNER = 0010 LOSER = 0010
AGWVTC149I End
Figure 161. DHS/VM: Sample DataHub Support/VM AVS Console
Statement 1: DMKSND045E SQLUSR1 not logged on
This statement is displayed whenever the DataHub Support/VM CMR logs off a
Service Pool machine and it is not logged on. SQLUSR1 is the user ID of the
Service Pool machine.
A Service Pool machine is not logged on under the following conditions:
• First time use
• After an AVS abend
• After it is logged off from the AVS console.
Statements 2 and 3: SQLUSR1:CONNECT= ...LOGOFF AT ...
These statements are displayed whenever the DataHub Support/VM logs off a
Service Pool machine.
Chapter 6. Problem Determination 227

6.4.3 Diagnosing Problems
Statement 4: MSG FROM AVSVM: CSIABD228E subtask of ′AGWDSPMN′ failed
-System Abend 0C1-0000
This statement is displayed whenever the DataHub Support/VM CMR subtask
abends. An alert record is also written to the CMR alert file, and a GCS dump is
taken.
Statements 5 and 6: EMQV020s Error occurred in CMR ...Reason Code=07 ...
These statements are also displayed whenever the DataHub Support/VM CMR
subtask abends. This and all other messages displayed by DataHub Support/VM
are described in “DataHub Support/VM CMR Messages and Codes” of the
DataHub Support/VM Installation and Operations Guide.
When trying to resolve a problem, you should determine which DataHub
Support/VM function was executing when the problem occurred; then refer to the
problem involving either:
• The CMR
or
• The Task Handler and the Tools Feature.
For diagnosing a problem you have to know with which other products the
components of DataHub Support/VM interact.
The DataHub Support/VM components interact with other products as follows:
The DataHub Support/VM CMR interacts with:
• AVS using parameter lists associated with AVS events
• GCS system services (including GCS Trace Facility)
• CP using CP commands to control the Service Pool machine environment.
The DataHub Support/VM Task Handler interacts with:
• The system to dynamically load the tool module and DataHub Support/VM
Common Services modules
• CMS system services to:
− Set up the tool environment
− Specify an abend exit routine that will gain control should the Service
Pool machine abend
− Set up the trace environment, including trace facility management.
• DataHub/2 to:
228 DataHub Implementation and Connectivity
− Issue CPI-C calls for program-to-program communication with DataHub/2.
The Display Status function of the DataHub Support/VM tools feature interacts at
the host with:
• CMS system services to load the status of the shared segment.
The Display Status function of the DataHub Support/VM tools feature interacts at
the RDB with:

• The SQL/DS Resource Adapter to connect to like SQL/DS databases to get
the status of those databases.
The Copy Data function of the DataHub Support/VM tools feature interacts with:
• The SQL/DS Resource Adapter to connect to like SQL/DS and unlike
RDBMSs, and to fetch and insert data.
The Utilities of the DataHub Support/VM tools feature interacts with:
6.4.4 Problems Involving the CMR
• The SQL/DS DBS utility to load data, unload data, or reorganize an index.
If AVS abends, each DataHub Support/VM CMR is invoked with an abend event
so that it can log off its set of Service Pool machines and put itself in shutdown
mode.
If one of the Service Pool machines abends, control is given to an abend exit,
which causes the connection between the Service Pool machine and DataHub/2
to be severed. The DataHub Support/VM CMR gains control with a deallocate
event after the severance occurs and marks the Service Pool machine available
for use. When VTAM notifies AVS of an Attention Loss between an LU 6.2
session and the associated DataHub Support/VM LU, AVS invokes the associated
DataHub Support/VM CMR. The CMR will sever all connections for that session
and log off the Service Pool machines that are associated with the session. The
Service Pool machines are reset and marked available for use.
AVS Console Messages issued by AVS and the DataHub Support/VM
CMR are displayed on the AVS console. See VM/ESA
Connectivity Planning, Administration, and Operation for
the messages displayed by AVS. See the chapter entitled
″Messages and Codes″ in the DataHub Support/VM
Installation and Operations Guide for the messages
displayed by DataHub Support/VM CMR. Figure 161 on
page 227 shows a sample AVS console.
CMR Alert File The DataHub Support/VM CMR alert file contains the alert
records of all DataHub Support/VM CMRs on the GCS
system. This file will be created on the AVS machine′s
A-disk when DataHub Support/VM CMR detects the first
alert situation. Alert records are written under the
following conditions:
• Unexpected parameters from AVS
• Missing or invalid control blocks
• I/O errors
• GETMAIN/FREEMAIN errors
• CMR message repository errors
• Unexpected errors from CP or GCS commands.
Each alert record identifies:
• The gateway where the problem occurred
• The date and the time
• The CMR module that issued the alert (for example,
EMQVC00)
Chapter 6. Problem Determination 229

• A brief description of the problem.
Figure 162 shows the layout of alert records that are
written to the DataHub Support/VM CMR alert file.
* CMR Alert File Layout
*
*The set of records written for each Alert consist of 3 or more records:
*First record specifies: timestamp and product/feature
*Second record specifies:release/lvl, ABEND code, module, alert code
*Third record specifies: alert string constant
*Fourth and subsequent records specify: symptom string (in blocks of 80)
93-123-08.15.55 PIDS/5688103 DataHub Support/VM Feature
LVLS/330 AV/S0806 U0000 RIDS/EMQVCGM 3
Error loading repository. Symptom data is: gateway name, R15.
Gateway name = CAIBMOML.OEDGWSV2 R15 = 0004.
93-123-08.16.10 PIDS/5688103 DataHub Support/VM Feature
LVLS/330 AV/S0000 U0000 RIDS/EMQVC30 1
WARNING: Service Pool machine not available. Symptom data is: gateway name.
Gateway name = CAIBMOML.OEDGWSV2
93-123-08.17.21 PIDS/5688103 DataHub Support/VM Feature
LVLS/330 AV/S00C1 U0000 RIDS/EMQVC00 4 See also: GCS SYSTEM DUMP
Unknown abend. Symptom data is gateway name, event name.
Gateway name = CAIBMOML.OEDGWSV2 Event name = ACTIVE.
93-123-08.18.09 PIDS/5688103 DataHub Support/VM Feature
LVLS/330 AV/S0000 U0000 RIDS/EMQVC00 3
SEVERE ERROR: CMR communication area is invalid. There is no symptom data.
Figure 162. Sample DataHub Support/VM CMR Alert File
This file has four alert records. The second record
indicates that there were no Service Pool machines to
process a DataHub/2 request. The third alert record
indicates that a GCS system dump has been produced.
GCS Trace File The DataHub Support/VM CMR uses the GTRACE macro to
write the trace records in the trace table. The IBM Support
Center may want the GCS trace records for problem
resolution.
GCS System Dump A GCS system dump is taken whenever the DataHub
Support/VM CMR cannot recover from an abend. The
dump is sent to the reader of the AVS machine or to a
specified user ID in the GCS collection. The IBM Support
Center may want the GCS trace records for problem
resolution.
6.4.5 Problems Involving the Task Handler and the Tools Feature
230 DataHub Implementation and Connectivity
Errors may occur at any time between DataHub/2 and DataHub Support/VM.
After the error has occurred, if the conversation still exists between them, an
attempt is made to end the conversation in a controlled manner. How the error
is handled depends on where it is detected and the state of the detecting
program.
Four types of errors are related to CPI-C verbs:
• Communication link failures

• Communication configuration errors
• DataHub errors:
− Internal error related to CPI-C verbs
− Unexpected flow from DataHub/2
• CPI-Communications system errors.
DataHub Support/VM Trace File
DataHub Support/VM tracing is controlled by DataHub/2.
When tracing is enabled, DataHub Support/VM programs
write trace information to the DataHub Support/VM trace
file (see Figure 163). This file is created on the reader of
the SYSADMIN user ID on the same VM system as the
Service Pool machine.
* Trace File Layout
*
4 1992-03-26-15.24.43.153174 EMQVT00 CS EX
6Entered Task Handler.
4 1992-03-26-15.24.43.154000 EMQVT00 CS IP
6Entered Task Handler input parameter is: szResourceID=STARVIEW.
4 1992-03-26-15.24.43.155003 EMQVT00 CS IN
5Globals initialization complete. EMQCGLOBAL structure at address X′005CD344′: a
5cEyeCatcher=EMQCGLOBAL, pHostSpecificGlobal=X′005CD4D8′, pEmqdaIn=X′00000000′,
.
.
.
.
4 1992-03-26-15.24.43.155453 EMQVT10 CS IN
5Entered function EMQVT10 with input parameters: pEmqcGlobal=X′005CD344′, pHostS
5pecificGlobal=X′005CD4D8′, szResourceID=STARVIEW, ppToolTable=X′005CD12C′, psEx
6ecuteProf=X′005CD14C′ .
.
.
.
.
Figure 163. Example of DataHub Support/VM Trace File
Note: For more information see “Diagnosis Problems” in
the DataHub Support/VM Installation and Operations Guide.
DataHub Support/VM Alert File
The DataHub Support/VM alert file (Figure 164 on
page 232) contains the alert records for the DataHub
Support/VM Task Handler, tools feature, and Common
Services.
If abnormal or unusual error situations are encountered,
alert records normally will be written to the reader of the
SYSADMIN user ID on the same VM system as the Service
Pool machine.
Chapter 6. Problem Determination 231

* Alert File Layout
*
*The set of records written for each Alert consist of 3 or more records:
*First record specifies: timestamp and product/feature
*Second record specifies:release/lvl, ABEND code, module, alert code
*Third record specifies: alert string constant
*Fourth and subsequent records specify: symptom string (in blocks of 80)
1993-08-12-10.54.34.123456 PIDS/5688103 DataHub Support/VM Feature
LVLS/330 AB/S999 RIDS/EMQVT40 5
EMQVT36 Returned unexpected return code. Symptom data is: bad return code.
Figure 164. Sample DataHub Support/VM Alert File
6.5 AS/400 Host Problem Determination
6.5.1 The AS/400 Tools
Note: For more information see “Diagnosing Problems” in
the DataHub Support/VM Installation and Operations Guide.
This section explains the tools and facilities that are available in the AS/400
system to help with problem determination.
As DataHub is a cooperative processing product, it is important to consider that,
in a problem determination situation, the problem could be in the network, the
workstation, or the AS/400 system. A debug approach should be hierarchical,
beginning with the simple tools and ending using more complex tools, like a
trace.
To find information about a problem in a situation where for any reason DataHub
does not work or you receive specific error messages, you should begin looking
at the workstation, and after that, at the AS/400. The first place to look is the
EMQCELOG.010 log, which is located at the workstation. You should read the log
and try to understand the meaning of the error messages. If the log does not
give you any clues about the problem, it is time to debug the problem directly on
the AS/400 system.
The tools that you can use for problem determination are:
• Display configuration, network, lines, controllers, devices
• Error messages
• Job log
• Spool files
• QSYSOPR message queue
• System log
• Traces
− Communication
− DataHub
232 DataHub Implementation and Connectivity

6.5.2 Network Problems
The DataHub Support/400 and the DataHub/2 workstation uses one of two
communication protocols, depending on the DataHub function that is being used.
For example, Utilities use a private protocol (CPI-Communications side
information at the OS/2 Communications Manager) or LU 6.2 protocol. Depending
on the function you use, a different approach should be followed. Table 1 on
page 17 shows the functions and respective protocol used; you should use the
information in the table to drive your debug approach.
This section shows the AS/400 commands in mnemonic form. If you are not
familiar with the AS/400 platform, it is possible to navigate through the AS/400
using the OS/400 menus.
The AS/400 network verification steps are:
1. Verify the line description (Work with Configuration Status)
WRKCFGSTS *LIN
Figure 165 shows an AS/400 WRKCFGSTS command output screen. If the
TRLINE is active, as it is in Figure 165, everything will work properly.
However, if it is not active, you must vary it offline, and vary it back online.
Work with Configuration Status SJAS400A
03/20/93 08:51:01
Position to . . . . . Starting characters
Type options, press Enter.
1=Vary on 2=Vary off 5=Work with job 8=Work with description
9=Display mode status ...
Opt Description Status -------------Job--------------
TRLINE ACTIVE
TRCTLJOE ACTIVE
DHCLIENT ACTIVE
QPCSUPP ACTIVE/TARGET DHCLIENT QSECOFR 004030
QPCSUPP ACTIVE/TARGET QXFSERV QSECOFR 004035
QPCSUPP ACTIVE/TARGET QXFSERV QSECOFR 004035
QPCSUPP ACTIVE/TARGET DHCLIENT QSECOFR 004038
QPCSUPP ACTIVE/TARGET DHCLIENT QSECOFR 004039
QPCSUPP ACTIVE/TARGET DHCLIENT QSECOFR 004052
Bottom
Parameters or command
===>
F3=Exit F4=Prompt F12=Cancel F23=More options F24=More keys
Figure 165. AS/400: Verifying Communications
2. Verify the AS/400 log (Display Message Queue QSYSOPR):
DSPMSG QSYSOPR
Figure 166 on page 234 shows a display of the QSYSOPR queue.
Chapter 6. Problem Determination 233

234 DataHub Implementation and Connectivity
5738SS1 V2R2M0 920925 SJAS400A 03/20/93 09:09:13
Display Device . . . . . : DSP01
User . . . . . . . . . . : QSECOFR
Work with Messages
System: SJAS400A
Messages in: QSYSOPR
Type options below, then press Enter.
4=Remove 5=Display details and reply
Opt Message
QWTSCVMXA distribution queue.
SNADS router 003916/QSNADS/QROUTER started.
Subsystem QSNADS started.
Subsystem QSNADS in library QSYS starting.
All sessions ended for device LUSQLDB2.
Communications device LUDB23 was allocated to subsystem QCMN.
Program start request received on communications device SJA2019I00
was rejected with reason codes 713, 0.
Communications device SJA2019I00 was allocated to subsystem QCMN.
Controller SJA2019I contacted on line TRLINE.
An adapter has inserted or left the token-ring on line TRLINE.
An adapter has inserted or left the token-ring on line TRLINE.
F1=Help F3=Exit F5=Refresh F16=Remove messages not needing a reply
F17=Top F18=Bottom F24=More keys
Figure 166. AS/400: DSPMSG QSYSOPR Command Output
The QSYSOPR message queue contains all error messages that the AS/400
sends, including communication errors. If there is any message related to
your problem, move the cursor to any point over the message, and press
PF1 or the Help key to get the detailed information.
3. Check the spooled files of the DataHub user
Another way to verify AS/400 problems is to receive the error message in a
spool file. In a debug situation it is better to have the highest level of
message logging. On the AS/400, the DataHub user profile should have an
assistance level of *ADVANCED. The assistance level is the ASTLVL
parameter on the user profile. Also verify that the job description associated
with the user profile has the parameters Level 4, Severity 00, and Text
*SECLVL.
Figure 167 on page 235 shows the AS/400 Change User Profile screen and
the parameter ASTLVL.

Change User Profile (CHGUSRPRF)
Type choices, press Enter.
User profile . . . . . . . . . . USRPRF > DHJOSE
User password . . . . . . . . . PASSWORD *SAME
Set password to expired . . . . PWDEXP *NO
Status . . . . . . . . . . . . . STATUS *ENABLED
User class . . . . . . . . . . . USRCLS *PGMR
Assistance level . . . . . . . . ASTLVL *ADVANCED
Current library . . . . . . . . CURLIB *CRTDFT
Initial program to call . . . . INLPGM *NONE
Library . . . . . . . . . . .
Initial menu . . . . . . . . . . INLMNU MAIN
Library . . . . . . . . . . . *LIBL
Limit capabilities . . . . . . . LMTCPB *NO
Text ′ description′ . . . . . . . TEXT ′ DataHub User′
Figure 167. AS/400: Parameter ASTLVL in User Profile
Figure 168 shows the AS/400 job description, with the message logging.
Display Job Description
Job description: QDFTJOBD Library: QGPL
Message logging:
Level . . . . . . . . . . . . . . . . . . . . : 4
Severity . . . . . . . . . . . . . . . . . . . : 0
Text . . . . . . . . . . . . . . . . . . . . . : *SECLVL
Log CL program commands . . . . . . . . . . . . : *NO
Accounting code . . . . . . . . . . . . . . . . : *USRPRF
Print text . . . . . . . . . . . . . . . . . . . : *SYSVAL
Routing data . . . . . . . . . . . . . . . . . . : QCMDI
Request data . . . . . . . . . . . . . . . . . . : *NONE
Device recovery action . . . . . . . . . . . . . : *SYSVAL
Figure 168. AS/400: Message Logging in Job Description
To view the spool files for the DataHub user, type the command WRKSPLF
userid, where userid is the user profile of the DataHub user.
Figure 169 on page 236 shows detailed information about an error message.
The same information can be found at the spooled file, QPJOBLOG.
Chapter 6. Problem Determination 235

Additional Message Information Page 1
5738SS1 V2R2M0 920925 SJAS400A 03/19/93 19:05:44
Message ID . . . . . . : CPF1269Severity . . . . . . . : 00
Date sent . . . . . . : 03/17/93 Time sent . . . . . . : 09:00:07
Message type . . . . . : Information
From job . . . . . . . . . . . : LUSQLVMA
User . . . . . . . . . . . . : STSQLB
Number . . . . . . . . . . . : 003655
Message . . . . : Program start request received on communications device
LUSQLVMA was rejected with reason codes 605, 1506.
Cause . . . . . : The program start request was rejected in job
003655/STSQLB/LUSQLVMA. The device belongs to remote location LUSQLVMA. If
the device is an advanced program-to-program communications (APPC) dev ice,
the program start request was received on mode IBMRDB with unit-of-work
identifier USIBMSC.LUSQLVMA-A732A86F56AD-0001.
Recovery . . . : For more information on reason codes and their meanings,
see the Communications: Intersystem Communications Function Programmer′ s
Guide, SC41-9590. See the job log for more information about the problem.
Figure 169. AS/400: Operator Message Queue Display Screen
4. Check the system history log
Use the DSPLOG (Display LOG) command to check all the messages on the
AS/400. We recommend that you press F4 (Prompt) and specify a starting
date and time; otherwise you will receive the entire system log.
5. Use traces
Depending on the information that you find in the previous logs, you may
want to use the AS/400 trace facilities.
There are three communications traces (ICF, CPI, JOB); you should use the
trace that is appropriate for the problem.
6.5.3 Return Codes and Error Messages
6.5.4 SQL Return Codes
236 DataHub Implementation and Connectivity
Important error codes are recorded in the system log or in the QSYSOPR
message queue. We strongly recommend that you use the AS/400 help facility to
get detailed information about the messages. If you do not understand the
meaning of any AS/400 message, the help facility tells you where you can find
the respective information.
To verify the meaning of an SQLCODE in the AS/400, you can use the DSPMSGD
(Display Message Description) command.
Suppose you are looking for the meaning of SQLCODE -0551. You can use the
command:
DSPMSGD RANGE(SQL0551) MSGF(QSQLMSG)
Figure 170 on page 237 shows the output screen for the DSPMSGD command.

6.5.5 Request Codes
6.5.6 Security Errors
range(sql0551) msgf(qsqlmsg)
Display Device . . . . . : DSP01
User . . . . . . . . . . : QSECOFR
Select Message Details to Display
System: SJAS400A
Message ID . . . . . . . . . : SQL0551
Message file . . . . . . . . : QSQLMSG
Library . . . . . . . . . : QSYS
Message text . . . . . . . . : Not authorized to object &1 in &2 type *&3.
Select one of the following:
1. Display message text
2. Display field data
5. Display message attributes
30. All of the above
Selection
F3=Exit F12=Cancel
(C) COPYRIGHT IBM CORP. 1980, 1992.
Figure 170. AS/400 Detailed SQLCODE
The request codes that you find in the job log, system log, or spool file log can
be identified in the AS/400 Communications APPC Programmer′s Guide
(SC41-8189).
The AS/400 identifies everything in the system as an object. The proper
authority must be granted to allow DataHub users to access the AS/400 objects
or functions. Otherwise the operation will be denied, and an error message
issued.
Figure 171 shows the message that a DataHub user receives if the authority was
not granted to the DataHub package before the user tries to access AS/400
services or functions.
Additional Message Information
5738SS1 V2R2M0 920925 SJAS400A 03/19/93 18:57:43
Message ID . . . . . . : CPF2218 Severity . . . . . . . : 30
Date sent . . . . . . : 03/16/93 Time sent . . . . . . : 09:41:27
Message type . . . . . : Information
From job . . . . . . . . . . . : QSYSARB
User . . . . . . . . . . . . : QSYS
Number . . . . . . . . . . . : 003252
Message . . . . : User DHJOSE not authorized to *SQLPKG QEMQUSER/EMQ1010
Cause . . . . . : Job 003524/DHJOSE/AS400LU02 does not have authority to
object EMQ1010 in library QEMQUSER with object type *SQLPKG. If the name of
the job is not displayed, the job completed before the message was sent.
Recovery . . . : Have the security officer give user DHJOSE authority to
object EMQ1010.
Technical description . . . . . . : The authorization event detected was
00020101.
Figure 171. AS/400 Security Error Message
Chapter 6. Problem Determination 237

To grant authority to any user, you can use the following AS/400 commands:
• EDTOBJAUT
• GRTOBJAUT
• SQL command grant (if the object is a package, table, or view).
6.5.7 Debugging Tools Conversation Data Flow Errors at AS/400
6.5.8 EMQ9088E Message
Some DataHub functions like RDBMS Work and the Utilities (for example, unload,
reload, and reorganize) use tools conversation data flows, as described in the
OS/2 Communications Manager CPI Communications side information definition.
When using DataHub/2 to access any SAA RDB server, the error messages are
also logged at the workstation EMQCELOG.010 log file.The log contains the
detailed error message information to use to debug the problem that you are
having.
Note: Not only are private protocol messages logged in EMQCELOG.010; all
messages that you receive when using DataHub/2 are logged. This
includes DRDA, SQL, syntax, and other error messages.
The EMQ9088E message is issued (you can see it in the EMQCELOG.010 log). The
message contains detailed error information. The most probable errors that
could occur are:
• EMQ9088E No_Host_user_id
Verify that the profile you have defined at the OS/2 Communications
Manager CPI Communications side information matches the AS/400 user
profile, including the password.
• EMQ9088E Emq_failure_no_retry
Verify userid, password, communications, OS/2 Database Manager
• EMQ9088E SQLERROR
Verify the meaning of the SQLCODE. You can verify the SQLCODE using the
DSPMSGD command at an AS/400 terminal session:
DSPMSGD RANGE(SQLXXXX) MSGF(QSQLMSG)
where XXXX is the SQLCODE. It is also possible to verify the SQLCODES in
any SAA RDB messages manual, because they are the same, for example,
-0551 means no authority, -0204 means object not found.
• The profile that is being used at OS/2 Communications Manager CPI
Communications side information must exist at the AS/400, and a valid
password must be specified.
• EMQ9088E Connect Error
238 DataHub Implementation and Connectivity
The problem could be the definitions at the OS/2 Communications Manager.
The CPI Communications side information definition must match the AS/400
Partner LU definition. Verify the AS/400 SYSOPR message, and the spool
files for the userid. Verify the physical connection between the DataHub
workstation and the AS/400, for example, the lines, controllers, and devices.
At an AS/400 session verify the network status using the WRKCFGSTS (Work
with Configuration Status) command.

6.5.9 Traces
• EMQ9251W CM_TP_NOT_AVAILABLE_NO_RETRY
The OS/2 Communications Manager CPI Communications side information
parameter TPNAME must be QDMU/QSTSC.
It is possible to use AS/400 trace facilities for problem determination. The
recommended approach is to search in this sequence:
1. DataHub EMQCELOG.010 file
2. AS/400 QSYSOPR message queue
3. AS/400 system log
4. AS/400 spool file.
After you have looked in all the log files and the spool files, and you have not
found out what the problem is, you can start a trace based on the symptoms you
have found in the log.
The AS/400 traces are:
• Communications traces
It is possible to specify the object (a line, a controller) you want to trace.
• ICF traces
Used to trace all intersystem communications functions.
• CPI-C Traces
Traces all CPI Communications that occur in a job in which the command is
entered.
• Job traces (TRCJOB or STRSRVJOB)
It is possible to trace a specific job at the AS/400. To identify which job you
want to trace, use the WRKACTJOB (Work with Active Jobs) command to see
the job attributes required to start a trace.
• AS/400 GO CMDTRC command
6.6 OS/2 Host Problem Determination
This command displays a menu with many trace and debug options that
enable you to identify the correct trace facility to use for your problem.
On OS/2 managed hosts, you can use the same OS/2, OS/2 Database Manager,
OS/2 Communications Manager, and DDCS/2 tools for problem determination as
you use on the DataHub/2 workstation. However, people skilled in the use of
those tools are usually not available at the OS/2 host location.
Therefore, simple procedures could be set up to help the user start and stop the
appropriate trace utility and create the output to be sent to the appropriate
person.
The Distributed Console Access Facility/2 (DCAF/2) program could be used to
access the remote OS/2 host from a central point. Then a specialist could do the
appropriate problem determination remotely.
Chapter 6. Problem Determination 239

240 DataHub Implementation and Connectivity
When the tools conversation protocol is being used between the DataHub/2 and
the DataHub Support/2 workstations, the DataHub/2 user could request a trace to
be performed on the DataHub Support/2 host. The trace will be stored in a
directory specified by the TRACEPATH parameter in the DataHub Support/2
configuration file as shown in Figure 172.
Alert files are another source of information to use for problem determination on
the DataHub Support/2 platform. Those files are stored in a directory that is
specified by the ALERTPATH entry in the DataHub Support/2 configuration file.
More information on these alerts can be found in the DataHub Support/2
Installation and Operations Guide.
* DataHub Support/2 Configuration File
TOOLTABLE=D:\EMQ2\EMQ2TOOL.CFG
ALERTPATH=D:\EMQ2\ALERT
TRACEPATH=D:\EMQ2\TRACE
RDBNAMEMAP=D:\EMQ2\DHS2.MAP
Figure 172. Problem Determination Entries in DataHub Support/2 Configuration File.
Sample EMQ2SYS.CFG file.

Chapter 7. Security Considerations
This chapter presents an overview of the different security systems used on the
DataHub platforms and explains how the different platforms interact with each
other concerning security. It also deals with the issue of password modification
as enforced in most organizations and the management of those changes.
Finally, it proposes some recommendations to help you control DataHub security
issues.
7.1 Security on the DataHub/2 Workstation
7.1.1 User Profile Management
This section describes the security system used on the DataHub/2 workstation.
It also discusses the security implications of configurations involving a
DataHub/2 database server, an OS/2 LAN server, and a DDCS/2 gateway system.
As explained in 1.2, “DataHub Data Flows: Overview” on page 6, several
protocols are used to connect a DataHub/2 workstation to the different managed
hosts. The protocol used to send the request to the managed host determines
which security information is sent with the request.
If the request uses either the DRDA or RDS protocol, the User Profile
Management security system is used to define which userid/password
combination is sent to the managed host. If the tools conversation protocol is
used, the DataHub/2 user profile security information is used.
User Profile Management (UPM) controls access of certain resources available
on an OS/2 workstation. Both the LAN server and OS/2 Database Manager
(DB2/2 or Extended Services for OS/2) use UPM security.
Different versions of UPM are delivered with different versions of those products.
LAN Server version 3 and DB2/2 deliver version 3 of UPM. LAN Server version 2
and Extended Services for OS/2 deliver UPM version 2. This implies that you
need to plan your software installation carefully. Extended Services for OS/2
should not be installed after LAN Server version 3, and LAN Server version 2
should not be installed after DB2/2. But LAN Server version 3 and Extended
Services for OS/2 could work on the same machine.
When you install Extended Services for OS/2, LAN server/requester, or DB2/2,
UPM is automatically installed or updated on the workstation. A new group of
applications is added to the OS/2 desktop. This group provides the LOGON,
LOGOFF, and UPM applications.
UPM provides you with programs and menus to:
• Manage users
• Manage groups
• Manage your personal information (password, logon user profile).
Naturally, you will need to have the appropriate authority in order to manage
users and groups on the appropriate domain.
UPM manages the local domain (OS/2 Database Manager) and the LAN domain.
© Copyright IBM Corp. 1993 241

Before we explain what those domains are, we should point out that, if a
workstation is used as a LAN server or as a LAN domain controller and as an
OS/2 Database Manager database server, only one security system is used for
both domains. For example, when an administrator adds a user to the LAN
domain, that user is also given access to OS/2 Database Manager databases.
That user will have access to authorities granted to the group to which he or she
belongs (that is, the UPM group) and to the authorities granted to public.
Local Domain
The local domain is the local workstation domain. Through the local domain,
you control access and privileges to local OS/2 Database Manager resources
like OS/2 Database Manager directories. Even if your workstation does not have
a local database (that is, it uses the Distributed feature of OS/2 Database
Manager), you still have to log on to the local workstation to access the local
database directories (system and workstation directories) and a remote
database server or DDCS/2 gateway machine.
One way to log on to the local OS/2 Database Manager domain is to type this
command on the OS/2 command line:
LOGON /p= /L
You could also execute the LOGON program from the UPM folder. Or, a
program could do the logon for you through the UPM APIs.
Recommendation
242 DataHub Implementation and Connectivity
Every DataHub/2 user should put the LOGON command (that is, LOGON /L
and LOGON /D= (if applicable)) in the OS/2
STARTUP.CMD file to automate the logon process.
Although not recommended, the userid and password information could differ
between your local OS/2 workstation and other systems (OS/2 and non-OS/2
systems). UPM provides a solution through the user logon profile facility. This
facility, which is available from the local domain environment, permits a user to
associate a userid and password with a specific node (workstation). The node
name indicated in the user logon profile must have the same value as the
workstation alias name in the OS/2 Database Manager workstation directory.
Note: Please note that UPM uses the term node and that OS/2 Database
Manager uses the terms workstation and node for the same object.
You do not have to use the user logon profile if you access all RDBMSs with the
same userid and password.
To access the user logon profile facility, these are the steps you need to perform
if your workstation is NOT connected to a LAN domain controller:
1. Select the User Profile Management folder from your OS/2 desktop.
2. Select the User Profile Management application from the UPM folder.
The User Profile window will appear.
3. Select Actions from the Action menu.
4. Select the Add/change user logon profile... from the Actions pull-down
menu. If you are logged on to the LAN domain, this action will not be

available on the pull-down menu. You will need to select Use Domain from
the same pull-down menu (see the procedure below).
You need to perform the following steps if your workstation is connected to a
LAN domain controller:
1. Select the User Profile Management folder from your OS/2 desktop.
2. Select the User Profile Management application from the UPM folder.
3. Select Actions from the Action menu.
4. Select Use domain... from the Actions pull-down menu.
The Use Domain window will appear showing the active domain.
5. Click on the Local radio button.
6. Click on the OK push button.
The User Profile window will appear.
7. Select Actions from the Action menu.
8. Select Add/change user logon profile... from the Actions pull-down menu.
If you do not have a user logon profile, you could log on using this command on
the OS/2 command line:
LOGON /p= /N=
If you did not use the user logon profile, did not log on using the node logon
command, and are not logged on (local logon), the logon process to the target
host will not succeed. You will then get an error message and be presented
with a menu to log on to that particular host.
Figure 173 on page 244 shows the logic related to security information between
the different components, whether the database you want to access is local or
remote to your workstation.
Chapter 7. Security Considerations 243

244 DataHub Implementation and Connectivity
Figure 173. User Profile Management: Security Flow Diagram
LAN Domain
The second domain which is controlled by User Profile Management (UPM) is
the LAN domain. The LAN domain, as used in scenario 3, requires the user to
be defined to the domain. To access any resources, such as the DataHub/2
programs and help facilities, the user needs to log on to the domain. The OS/2
command that could be used is:
LOGON /p= /D=
You could also execute the LOGON program from the UPM folder, or a program
could do the logon for you through the UPM APIs.

Security Aspects for the Three Scenarios
As explained in Chapter 4, “DataHub/2 Workstation” on page 105, many
DataHub/2 configurations are possible. Each configuration will have different
impacts on security. This section discusses two different configurations: (1)
DataHub/2 stand-alone configuration (scenarios 1 and 2) and (2) the LAN server,
DataHub/2 server, and the DDCS/2 gateway installed on the same machine
(scenario 3). It also describes the impact of having the LAN server, DataHub/2
server, and DDCS/2 gateway installed on different machines.
Scenario 1: This configuration implies that three security systems are used:
one on the DataHub/2 workstation and one on each of the OS/2 hosts. The
DataHub/2 database is managed locally and is usually used by only one user.
No group needs to be defined to grant authorities to the DataHub/2 database.
Two workstations will need to be defined on the DataHub/2 workstation in the
OS/2 Database Manager workstation (node) directory.
If different combinations of userid and password are used on each OS/2 system,
we recommend that you create a separate user logon profile entry and a
separate OS/2 Database Manager workstation entry for each OS/2 host.
Scenario 2: From a security point of view, scenario 2 is more complex than
scenario 1 because of the additional hosts. However, on the DataHub/2
workstation, this configuration implies having to add user logon profile entries if
the userid and password definitions are different on those new hosts. In our
case, we were using different userids on the New York (MVS) and Toronto (VM)
systems. Using the UPM user logon profile and different OS/2 Database
Manager workstation names for each host helped us automate the logon process
to the different hosts (that is, we eliminated the prompts for userid and
password).
Recommendation
If you are using different userids or passwords on the target hosts, we highly
recommend that you use a different workstation name for each host even if
you are using a DDCS/2 gateway machine to get to those hosts.
Take a look at our OS/2 Database Manager client workstation directory
definitions in Figure 61 on page 87. We used different workstation names
even though we were using the same workstation (DDCS/2 gateway machine)
to connect to the target RDBMS. We used this configuration for scenario 3.
Scenario 3: In scenario 3, the LAN server, the DataHub/2 server, and the
DDCS/2 gateway are installed on the same machine. The only installation factor
to consider is the version of LAN server and OS/2 Database Manager being
installed as discussed in the previous section.
This configuration is the simplest of all DataHub/2 configurations because only
one security system is installed on the machine. Both LAN server and OS/2
Database Manager use the same security definitions. You need to define the
users and the groups only once. This scenario is recommended for a multiple
user configuration that uses the LAN server to share the DataHub/2 code and
data and where all users share the DataHub/2 database.
Chapter 7. Security Considerations 245

From a security point of view, the difference between scenario 2 and 3 is the fact
that users will need to log on to the LAN domain in order to use the DataHub/2
code.
Other Configurations: Many other configurations are possible in a LAN
environment. Before you opt to use any of the following configurations, consider
their security aspects:
• One server: a LAN server
7.1.2 DataHub/2 User Profiles
246 DataHub Implementation and Connectivity
− LAN server machine to share the DataHub/2 product
− Local DataHub/2 database and local DDCS/2 gateway
• One server: a DDCS/2 gateway
− DDCS/2 gateway machine
− Local DataHub/2 database and code
• Two servers: a LAN server and a DDCS/2 gateway
− LAN server machine to share the DataHub/2 product
− Local DataHub/2 database
− DDCS/2 gateway machine
• Three servers: a LAN server, a DataHub/2 server, and a DDCS/2 gateway
− LAN server machine to share the DataHub/2 product
− DataHub/2 database server
− DDCS/2 gateway machine.
Each of these configurations implies the use of multiple security systems (for
example, OS/2 UPM) that need some coordination. With these systems,
password modification in one system is not automatically reflected in the other.
A (costly) solution is to install the LAN server code on each server. Because
password changes are broadcast among all LAN servers controlled by the same
domain controller, the password changes of the LAN side will be reflected on
each OS/2 Database Manager system.
DRDA or RDS requests use the OS/2 UPM facility to provide the security
information to the target hosts. In the case of the DataHub tools conversation
protocol, the DataHub/2 user profile security information is used in the requests
sent to the DataHub Support components.
Each user can have multiple profiles, but only one profile is active at one time.
To send a request to the target host, there must be an entry associated with that
host in the active DataHub/2 user profile. If this entry is not defined, you will find
a message like this one in the DataHub/2 log:
011 COPY D:\EMQDIR\EXE\EMQDTTOP.EXE 1993-03-10-11.04.03.97
EMQ9088E The Common Service, EmqConnect, has returned with return code,
EMQ_NO_HOST_USER_ID.
The tricky question is, Which host is the target host? When the request is a
reorganize, the answer is very easy because the process involves only one host.

But when the request is a Copy Data that involves two hosts, it is more difficult
to figure out which DataHub/2 user profile entry will be sent along with the
request. Figure 174 on page 247 will help you understand which host will get
the DataHub/2 request and, by the same logic, which DataHub/2 user profile
entry will be sent with the request. The complexity is caused by the fact that the
OS/2 Database Manager can only be a requester in a DRDA network. When a
Copy Data function is requested that involves one OS/2 Database Manager
database and one DRDA server RDBMS, the request will always be sent to the
DataHub Support/2 component, which will process the request.
Because the security information sent with the Copy Data request is used for
both conversation security validation on the target host and the Copy Data
function itself, in order to succeed, the Copy Data function requires that the
security information be the same on both the source and the target RDBMS.
Figure 174. DH/2: User Profile Entry Selection Diagram
Chapter 7. Security Considerations 247

7.1.3 DataHub/2 Database Privileges
7.2 MVS Security
If you have only one DataHub/2 workstation as in scenario 1 and 2, you will not
need to be concerned about privileges. For scenario 3 (multiple database
administrators and probably help-desk personnel), you should use OS/2 UPM
groups to assign privileges to the DataHub/2 package and database tables.
Before granting privileges to the DataHub/2 database tables, you will need to
grant execute on the DataHub/2 package to all DataHub/2 users. This should be
done using the different groups defined in the OS/2 UPM. Please refer to the
DataHub/2 Installation and Administration Guide for more information on the
package name and the different forms of grant commands, which differ from
platform to platform. The package name for the first release of DataHub/2 is
QEMQUSER.EMQP1010.
To grant privileges to the different DataHub/2 database tables, DataHub/2
provides you with this command:
EMQGRANT
The value could be USER or ADMIN. A USER value gives
select-only authority, which is appropriate for help-desk personnel. The ADMIN
value gives all privileges to the group or a specific user.
If DataHub/2 ships requests that DB2 is to process, DB2 should be connected to
a network. DB2 is one of the many LUs that have been defined to VTAM, as
mentioned in section 3.4.2, “DRDA Definitions” on page 47 and shown in
Figure 24 on page 48. Before your request gets to DB2, DB2 has to connect to
VTAM. This is the first check that is done before DB2 connects to the network
and a session is established with VTAM. The first check is done to prevent
unauthorized connection to the network.
If DB2 to VTAM connection is allowed, the next step is to verify whether the
partner LU that is sending the request (DataHub/2) is valid or not. This check is
made by RACF and VTAM.
Finally, when the conversation is established, DB2 will check whether it can
accept and process the request coming from DataHub/2
7.2.1 DB2 Attachment to the Network Check
Before installing the DB2 distributed database capability, you have to choose a
LOCATION, a LUNAME, and a password, which should be provided to the DB2
installation CLIST. This will generate the required job to include these definitions
in the DB2 BSDS. When defining DB2 to VTAM, the LUNAME is the APPL macro
label, and the password is checked against the APPL PRTCT parameter. These
definitions allow VTAM to control which DB2 can be connected to the network.
7.2.2 VTAM and RACF Partner LU Validation
248 DataHub Implementation and Connectivity
The validation of the LU that is sending the request is done by VTAM and RACF.
If you specify VERIFY=REQUIRED on the APPL statement when defining your
DB2, you are activating the requesting partner LU verification. RACF and VTAM
will check if the request comes from a valid LU. If you specify VERIFY=NONE,

7.2.3 DB2 Request Checking
you are indicating that you do not want connection verification, and any LU can
connect to your DB2.
Once the conversation is established, the requester application (DataHub/2)
sends a “remote attach request,” which is submitted to a security check
mechanism that will conform to what you have specified in the APPL SECAPT
VTAM parameter and in the communication database tables. You should code
SECACPT=ALREADYV on the VTAM APPL statement to ensure that all
conversations received contain an authorization ID; they may contain a
password. If the password is supplied by the requester, it will be passed to RACF
at the local site to be checked.
Refer to Figure 175 on page 250 for a overview of the security mechanism. You
will find more details in the DB2 and VTAM literature. The steps taken at the
server site are:
Password check If no password arrived with the remote request, DB2
checks the acceptance option specified in the
USERSECURITY column in the CDB
SYSIBM.SYSLUNAMES table. See steps 1 and 2.
SYSLUNAMES check If the USERNAMES column of SYSLUNAMES contains an
I or B, the authorization ID that comes from the
requester is subject to translation. Translation is done
according to what is specified in the
SYSIBM.SYSUSERNAMES table. If it is not an I or B, it is
RACF checked anyway. Refer to step 3.
ID check for connections DB2 calls RACF for verification. If the ID or password
cannot be verified, DB2 rejects the request. See step 5.
Connection processing The remote request is treated as a local connection
request. See steps 6 and 7.
SYSUSERNAMES check DB2 searches the SYSIBM.SYSUSERNAMES table for a
row that tells it how to translate the ID. If there is no
such row, DB2 rejects the request. See steps 10 and 11.
Inbound requests can be managed by DB2 or by RACF. If you do not specify I or
B in the USERNAMES column of the SYSIBM.SYSLUNAMES table for a particular
LU name, you are selecting RACF check. In this case you have to provide the
proper definitions and password to RACF.
Chapter 7. Security Considerations 249

Figure 175. DB2 Security Mechanism
250 DataHub Implementation and Connectivity

7.3 VM Security
This section presents an overview of VM security in the DRDA and DataHub
environments.
7.3.1 Controlling Access to the SQL/DS Application Server System
The user ID and eventually the password (if the conversation level security is
SECURITY=PGM) configured at DataHub/2 are sent to the VM host (AS) and
verified as valid at the CP where the Service Pool machine resides. The
DataHub/2 host user ID and password are valid if:
• The DataHub Support host user ID exists in a VM system where DataHub
Support/VM is running
• The password is a valid password for the DataHub/2 host user ID (if
SECURITY=PGM).
NOTE: SECACPT=ALREADYV should be coded in the AVS VTAM APPL
statement if you want to use either SECURITY=SAME or SECURITY=PGM for
your conversation. If you specify SECACPT=CONV, only SECURITY=PGM can
be used.
Figure 176 shows the four inbound processing steps.
Figure 176. VM Security Inbound Processing
Chapter 7. Security Considerations 251

Inbound Processing
1. LU Verification
The first step occurs when two RDBMSs are establishing an LU6.2 session.
DRDA defines the LU6.2 flows that will be used to establish the session.
Session-level security is provided by specifying VERIFY=REQUIRED in the
VTAM APPL statement (defining AVS) and supplying a password in the prtct
field in the same APPL statement.
If VERIFY=NONE, session-level security is skipped.
2. AVS Validation Translation
If the incoming conversation uses SECURITY=SAME, the incoming LU and
user ID must be defined in the target AVS gateway. AVS also offers user ID
translation services for this type of conversation-level security.
3. RACF or CP Password Check
If the incoming conversation uses SECURITY=PGM, the external security
system will be invoked. In the case of RACF, this requires the VMEVENT of
APPCPWVL to be controlled (which is the default). Otherwise, the password
will be verified by CP. If SECURITY=SAME, the password is not checked,
only the DataHub/2 host user ID has to be defined in VM.
Note: Inbound ALLOCATE requests to DataHub Support/VM must indicate
conversation security (SECURITY=PGM).
4. Connection Authorization
In SQL/DS, the RDBMS is a complete virtual machine, and it controls the
connection as an SQL privilege.
A DataHub/2 host user ID must have at least CONNECT authority to the
SQL/DS databases that are supported by DataHub Support/VM.
A DataHub/2 host user ID must also have various levels of authorization to
execute the following functions of the DataHub Support/VM tools feature:
Display Status
At Host None
At RDB Requires EXECUTE privilege on the Display Status
package QEMQUSER.EMQVQS00 to allow DBSPACE
NAME support. This is optional authority needed to get
the DBSPACE NAME.
Copy Data
Utilities
252 DataHub Implementation and Connectivity
Requires authority to select from the source table,
authority to insert into the target table, and EXECUTE
privilege on package QEMQUSER.EMQVCS00 at both
the source and the target RDB.
Load Data Must be the owner of the table, have SELECT and
INSERT privileges on the table, or have DBA authority.
The input file may be on tape or disk, but if it is read
from disk, it must be a shared file system (SFS) file.
The DataHub/2 host user ID also requires read
authority to the SFS file in the specified directory.

Unload Data Must have at least SELECT privilege on the table. The
output file can be written to tape or disk, but if it is
recorded to disk, it must be an SFS file. The DataHub/2
host user ID also requires write authority to the SFS
directory.
Reorganize Index Must be the owner of the index, or have DBA authority.
In the case of primary or unique keys, must be the
owner of the table, or have DBA authority. Must have
EXECUTE privilege on package
QEMQUSER.EMQVCS00.
7.3.2 Controlling Access to the SQL/DS Application Requester System
The mechanism to control access to the SQL/DS AR system is the same as the
single-site security mechanism, for example, for:
• End user signon to VM
• CP or RACF protection of the SQL/DS production disk that contains the AR
code. Users need to link and access this disk before they can use the AR
function.
Outbound Processing
To access a remote database the user must access the COMDIR that contains
an entry for that database. The COMDIR contains information such as the source
and target LU names, and type of conversation-level security to be used (for
example, PGM or SAME). Each user can access up to two COMDIRs
(system-level and user-level) at a given time. The user-level COMDIR is
searched first.
The administrator is likely to define the COMDIR to be accessed by everyone,
but users can define and access their own COMDIR for connection.
For SECURITY=PGM, the COMDIR allows you to specify the user ID and
password that will be used for the connection. The preferred approach is to
define the user ID and password in the user′s CP directory as the APPCPASS
records.
Preventing Users from Making Outbound Requests
All remote access requires the use of AVS gateways. Therefore we can control
the outbound requests by making appropriate CP directory definitions for the
user′s or AR′s AVS virtual machine. For example, you can have entries in AVS
that only accept connection requests from specific users, or from all users (IUCV
level-security: ALLOW, ANY, or specific user IDs). Similarly, you can also have
entries in the user′s directory that allow the user to connect through any of the
AR′s AVS gateways, or only through specific gateways. However, if users have
access to any target LUs that have sessions between the two sides, it will be up
to the target site to reject the connection.
Chapter 7. Security Considerations 253

7.4 AS/400 Security
This section presents an overview of AS/400 security. Detailed information on
AS/400 security can be found in the AS/400 Basic Security Guide (SC41-0047) and
the AS/400 Security Reference (SC41-8083).
AS/400 does not have an external security subsystem. All security is handled
through the OS/400 operational system.
The OS/400 QSECURITY system value definition establishes the security level of
the AS/400 system. We recommend that you use at least level 30 in order to
have user profile and password validation and control access to all objects in the
system. Therefore to access any object in an AS/400 system you must have the
appropriate authorization.
7.4.1 User Profile and Password Validation
7.4.2 QEMQUSER Authorization
254 DataHub Implementation and Connectivity
To use the DRDA environment, the user profile and password can be validated at
remote locations, or you can implement a security mechanism that ensures that
all remote accesses are controlled by the local system. It is possible to define
the links and connections as secure locations, or as security already verified. In
such cases you assume that the user who is entering your database had the
user profile and password validated and can access your database with a default
profile.
Another method of validation is to specify secure location=NO. In this case the
user profile and password must match a predefined user profile at the local
system.
This is valid for all DBMSs, so, when trying to connect to a remote database, you
must use a user profile and a password valid at the remote system. Or you can
define a scheme to have a default user profile at each platform, defining the
communications links as secure or already verified, or you can use a translation
mechanism if one is available, as is possible under DB2.
The AS/400 system does not provide any outbound translation to solve the
potential conflicts in the network. These conflicts must be resolved at the
application server.
The OS/400 Distributed Relational Database Guide (SC41-0025) has more datailed
information about AS/400 security in a DRDA environment.
During the installation process of DataHub Support/400 the QEMQUSER user
profile is created, and this user profile is the owner of the QEMQUSER collection.
We recommend that you not change the owner of the QEMQUSER collection,
because QEMQUSER needs at least *OBJOPER and *ADD privileges on that
collection.
To connect a specific DataHub/2 workstation to an AS/400 host, you must bind
the DataHub/2 workstation to the AS/400. The package name is EMQP1010, and it
is located in the AS/400 QEMQUSER collection.
To allow users other than QEMQUSER to access the DataHub Support/400
functions it is necessary to:

7.4.3 Security Administration
7.5 OS/2 Managed Host Security
7.5.1 RDS Security
• Start an AS/400 SQL interactive session by issuing the STRSQL command and
then execute the following command:
GRANT EXECUTE ON PACKAGE QEMQUSER.EMQP1010 TO USERID
or
• Use the AS/400 GRTOBJAUT command
or
• Use the OS/2 Database Manager command line interface and the grant
command.
The OS/400 CRTUSRPRF (Create User Profile), WRKUSRPRF (Work With User
Profile), or CHGUSRPRF (Change User Profile) commands must be used to create
an OS/400 user profile or to change the password. It is also possible to change a
password just by going through the OS/400 menus.
The AS/400 security officer has *SECADM authority and is usually responsible for
managing user profiles, passwords, authorization lists, and all security-related
tasks under OS/400.
Authorization lists can be created to manage a group of users that need access
to the same objects. We recommend that you create authorization lists to
facilitate security administration.
This section discusses how the inbound requests sent by the DataHub/2
workstation are validated. The good news about the OS/2 managed hosts is that
all RDS and tools conversation requests are validated using the OS/2 UPM
facility.
Section 7.1.1, “User Profile Management” on page 241 discusses how the OS/2
UPM facility is used to validate the RDS request. The OS/2 managed host is a
server to a DataHub/2 workstation. The DataHub/2 user most be defined in the
OS/2 managed host (that is, defined in OS/2 managed host UPM) in order to
access the local RDBMS. When applicable, a group should be assigned to a
DataHub/2 user to help manage the OS/2 Database Manager privileges.
7.5.2 Tools Conversation Security
The first level of security when a request is sent from a DataHub/2 workstation to
an OS/2 workstation is conversation security. Specify Same in the Security type
field. Program security is enforced by DataHub/2, and the DataHub/2 user profile
security information is sent along with the tools conversation request.
On the OS/2 managed host side, the transaction program definition (see
“Transaction Program Name” on page 196) indicates that the security
information is required. However, the conversation security definition (see
“Conversation Security” on page 198) indicates that the OS/2 UPM facility is
used to validate the incoming request.
Chapter 7. Security Considerations 255

DataHub Support/2 also uses one or more userids and passwords sent (in
encrypted format) from the DataHub/2 workstation to issue logons of the process
executing the DataHub Support/2 tool functions. If a user-supplied encryption
routine is used at the DataHub/2 workstation then a matching user-supplied
routine (which uses the same encryption algorithm) must be installed at each
DataHub Support/2 host managed by the DataHub/2 workstation. Failure to have
matching encryption routines will cause the DataHub Support/2 tool functions to
fail various authorization checks.
The userid and password for the DataHub Support/2 host must also be supported
at all hosts that you intend to use in copy data operations involving this DataHub
Support/2 host.
7.6 Managing Password Changes
The EMQCRYPT.DLL must match at both DataHub/2 and DataHub Support/2.
Before discussing the problems associated with password changes, let us
summarize the different locations where passwords are defined:
• At the DataHub/2 workstation
− UPM
− UPM user profile (one per host; optional if all your userids and
passwords are the same on every host)
− DataHub/2 user profile ( one entry per managed host)
• At the LAN server, DataHub/2 server, DDCS/2 gateway (optional)
− UPM
• At each managed host.
As you can imagine, changing passwords every month is a major issue if you
have hundreds of hosts to manage, as would be the case in a distributed OS/2
environment. Naturally, one person cannot manage hundreds of host systems;
dividing the responsibility among a group of people would minimize the
problems. Another solution is to use one userid and password for all the
database administrators and another userid and password for the help-desk
personnel. Everyone should be advised when a password is changed.
To summarize, if you change your password on a specific host, you will need to
reflect that password change in:
• OS/2 UPM
• DataHub/2 user profile.
256 DataHub Implementation and Connectivity
Note: When you change your UPM password on the DataHub/2 workstation, you
will be prompted by DataHub/2 for your old and new UPM passwords because
the OS/2 UPM password is used to encrypt the DataHub/2 user profile.
DataHub/2 will prompt you the first time you start DataHub/2 after an OS/2 UPM
password change.

7.7 Recommendations
Our principal recommendations about security are:
• If you are using the LAN Server configuration or a DataHub/2 database
server configuration:
− Assign UPM users to groups
− Grant DataHub/2 database authority to a group.
One group will have administration authority (select and update) on the
DataHub/2 database. Another will have user authority (select) on the
DataHub/2 database.
• Use the same userid and password for every host system you access.
• If different combinations of userid and password are used on each of the
managed hosts, we recommend that you create one OS/2 UPM logon profile
entry for each host.
• Use a different workstation name for each host even if you are using a
DDCS/2 gateway machine to get to those hosts. Use the OS/2 Database
Manager workstation alias as the OS/2 UPM node name.
• If your organization permits it, never change your password.
• Clean up the OS/2 UPM sessions by logging off all functions. This is
automatically done when you shut down your workstation.
• Back up the NET.ACC file from the C:\MUGLIB\ACCOUNTS directory. The
copy command should be put in the STARTUP.CMD procedure so that the
NET.ACC file is copied before the LAN server or OS/2 Database Manager is
started.
Chapter 7. Security Considerations 257

258 DataHub Implementation and Connectivity

Appendix A. OS/2 Communications Manager Network Definition File
This is the listing of the network definition file (NDF) used for the DataHub/2
workstation in scenario 2. It contains all symbolic destination name definitions
and the links to attach to any of the ITSC managed hosts.
DEFINE_LOCAL_CP FQ_CP_NAME(USIBMSC.SJA2039I )
DESCRIPTION(DataHub Control Point Workstation)
CP_ALIAS(ASJA2039)
NAU_ADDRESS(INDEPENDENT_LU)
NODE_TYPE(EN)
NODE_ID(X′05DA2039′)
HOST_FP_SUPPORT(YES);
DEFINE_LOGICAL_LINK LINK_NAME(OMTLDLR1)
DESCRIPTION(OS/2, Montreal, Car dealer)
FQ_ADJACENT_CP_NAME(USIBMSC.SJA2018I )
ADJACENT_NODE_TYPE(LEARN)
DLC_NAME(IBMTRNET)
ADAPTER_NUMBER(0)
DESTINATION_ADDRESS(X′400052047122′)
CP_CP_SESSION_SUPPORT(NO)
ACTIVATE_AT_STARTUP(NO)
LIMITED_RESOURCE(USE_ADAPTER_DEFINITION)
LINK_STATION_ROLE(USE_ADAPTER_DEFINITION)
SOLICIT_SSCP_SESSION(NO)
EFFECTIVE_CAPACITY(USE_ADAPTER_DEFINITION)
COST_PER_CONNECT_TIME(USE_ADAPTER_DEFINITION)
COST_PER_BYTE(USE_ADAPTER_DEFINITION)
SECURITY(USE_ADAPTER_DEFINITION)
PROPAGATION_DELAY(USE_ADAPTER_DEFINITION)
USER_DEFINED_1(USE_ADAPTER_DEFINITION)
USER_DEFINED_2(USE_ADAPTER_DEFINITION)
USER_DEFINED_3(USE_ADAPTER_DEFINITION);
DEFINE_LOGICAL_LINK LINK_NAME(ORIODLR1)
DESCRIPTION(OS/2, Rio de Janiero, Car dealer)
FQ_ADJACENT_CP_NAME(USIBMSC.SJA2019I )
ADJACENT_NODE_TYPE(LEARN)
DLC_NAME(IBMTRNET)
ADAPTER_NUMBER(0)
DESTINATION_ADDRESS(X′400052047116′)
CP_CP_SESSION_SUPPORT(NO)
ACTIVATE_AT_STARTUP(NO)
LIMITED_RESOURCE(USE_ADAPTER_DEFINITION)
LINK_STATION_ROLE(USE_ADAPTER_DEFINITION)
SOLICIT_SSCP_SESSION(NO)
EFFECTIVE_CAPACITY(USE_ADAPTER_DEFINITION)
COST_PER_CONNECT_TIME(USE_ADAPTER_DEFINITION)
COST_PER_BYTE(USE_ADAPTER_DEFINITION)
SECURITY(USE_ADAPTER_DEFINITION)
PROPAGATION_DELAY(USE_ADAPTER_DEFINITION)
USER_DEFINED_1(USE_ADAPTER_DEFINITION)
USER_DEFINED_2(USE_ADAPTER_DEFINITION)
USER_DEFINED_3(USE_ADAPTER_DEFINITION);
DEFINE_LOGICAL_LINK LINK_NAME(OPARDLR1)
© Copyright IBM Corp. 1993 259

260 DataHub Implementation and Connectivity
DESCRIPTION(OS/2, Paris, Car dealer)
FQ_ADJACENT_CP_NAME(USIBMSC.SJA2050I )
ADJACENT_NODE_TYPE(LEARN)
DLC_NAME(IBMTRNET)
ADAPTER_NUMBER(0)
DESTINATION_ADDRESS(X′400052047157′)
CP_CP_SESSION_SUPPORT(NO)
ACTIVATE_AT_STARTUP(NO)
LIMITED_RESOURCE(USE_ADAPTER_DEFINITION)
LINK_STATION_ROLE(USE_ADAPTER_DEFINITION)
SOLICIT_SSCP_SESSION(NO)
EFFECTIVE_CAPACITY(USE_ADAPTER_DEFINITION)
COST_PER_CONNECT_TIME(USE_ADAPTER_DEFINITION)
COST_PER_BYTE(USE_ADAPTER_DEFINITION)
SECURITY(USE_ADAPTER_DEFINITION)
PROPAGATION_DELAY(USE_ADAPTER_DEFINITION)
USER_DEFINED_1(USE_ADAPTER_DEFINITION)
USER_DEFINED_2(USE_ADAPTER_DEFINITION)
USER_DEFINED_3(USE_ADAPTER_DEFINITION);
DEFINE_LOGICAL_LINK LINK_NAME(ASJDLR1 )
DESCRIPTION(AS/400, San Jose, Car dealer)
FQ_ADJACENT_CP_NAME(USIBMSC.SJAS400A )
ADJACENT_NODE_TYPE(LEARN)
DLC_NAME(IBMTRNET)
ADAPTER_NUMBER(0)
DESTINATION_ADDRESS(X′400052047158′)
CP_CP_SESSION_SUPPORT(NO)
ACTIVATE_AT_STARTUP(NO)
LIMITED_RESOURCE(USE_ADAPTER_DEFINITION)
LINK_STATION_ROLE(USE_ADAPTER_DEFINITION)
SOLICIT_SSCP_SESSION(NO)
EFFECTIVE_CAPACITY(USE_ADAPTER_DEFINITION)
COST_PER_CONNECT_TIME(USE_ADAPTER_DEFINITION)
COST_PER_BYTE(USE_ADAPTER_DEFINITION)
SECURITY(USE_ADAPTER_DEFINITION)
PROPAGATION_DELAY(USE_ADAPTER_DEFINITION)
USER_DEFINED_1(USE_ADAPTER_DEFINITION)
USER_DEFINED_2(USE_ADAPTER_DEFINITION)
USER_DEFINED_3(USE_ADAPTER_DEFINITION);
DEFINE_LOGICAL_LINK LINK_NAME(MNYCENT )
DESCRIPTION(MVS, New York, Central distribution)
FQ_ADJACENT_CP_NAME(USIBMSC.SCG20 )
ADJACENT_NODE_TYPE(LEN)
DLC_NAME(IBMTRNET)
ADAPTER_NUMBER(0)
DESTINATION_ADDRESS(X′400008210200′)
CP_CP_SESSION_SUPPORT(NO)
ACTIVATE_AT_STARTUP(NO)
LIMITED_RESOURCE(USE_ADAPTER_DEFINITION)
LINK_STATION_ROLE(USE_ADAPTER_DEFINITION)
SOLICIT_SSCP_SESSION(YES)
PU_NAME(SJA2039 )
NODE_ID(X′05DA2039′)
EFFECTIVE_CAPACITY(USE_ADAPTER_DEFINITION)
COST_PER_CONNECT_TIME(USE_ADAPTER_DEFINITION)
COST_PER_BYTE(USE_ADAPTER_DEFINITION)
SECURITY(USE_ADAPTER_DEFINITION)

PROPAGATION_DELAY(USE_ADAPTER_DEFINITION)
USER_DEFINED_1(USE_ADAPTER_DEFINITION)
USER_DEFINED_2(USE_ADAPTER_DEFINITION)
USER_DEFINED_3(USE_ADAPTER_DEFINITION);
DEFINE_PARTNER_LU FQ_PARTNER_LU_NAME(USIBMSC.LUDB23 )
DESCRIPTION(DB2, New York, DB2CENTDIST)
PARTNER_LU_ALIAS(DBNYCENT)
PARTNER_LU_UNINTERPRETED_NAME(LUDB23 )
MAX_MC_LL_SEND_SIZE(32767)
CONV_SECURITY_VERIFICATION(NO)
PARALLEL_SESSION_SUPPORT(YES);
DEFINE_PARTNER_LU FQ_PARTNER_LU_NAME(USIBMSC.LUSQLVMA )
DESCRIPTION(SQL/DS, Toronto, Car dealer 1)
PARTNER_LU_ALIAS(DBTORDR1)
PARTNER_LU_UNINTERPRETED_NAME(LUSQLVMA)
MAX_MC_LL_SEND_SIZE(32767)
CONV_SECURITY_VERIFICATION(NO)
PARALLEL_SESSION_SUPPORT(YES);
DEFINE_PARTNER_LU FQ_PARTNER_LU_NAME(USIBMSC.SJA2018I )
DESCRIPTION(OS/2, Montreal, Car dealer)
PARTNER_LU_ALIAS(OMTLDLR1)
PARTNER_LU_UNINTERPRETED_NAME(SJA2018I)
MAX_MC_LL_SEND_SIZE(32767)
CONV_SECURITY_VERIFICATION(NO)
PARALLEL_SESSION_SUPPORT(YES);
DEFINE_PARTNER_LU FQ_PARTNER_LU_NAME(USIBMSC.SJA2019I )
DESCRIPTION(OS/2, Rio de Janiero, Car dealer)
PARTNER_LU_ALIAS(ORIODLR1)
PARTNER_LU_UNINTERPRETED_NAME(SJA2019I)
MAX_MC_LL_SEND_SIZE(32767)
CONV_SECURITY_VERIFICATION(NO)
PARALLEL_SESSION_SUPPORT(YES);
DEFINE_PARTNER_LU FQ_PARTNER_LU_NAME(USIBMSC.EMQMACB1 )
DESCRIPTION(DHS/MVS, New York, Central Distribution)
PARTNER_LU_ALIAS(DHNYCENT)
PARTNER_LU_UNINTERPRETED_NAME(EMQMACB1)
MAX_MC_LL_SEND_SIZE(32767)
CONV_SECURITY_VERIFICATION(NO)
PARALLEL_SESSION_SUPPORT(YES);
DEFINE_PARTNER_LU FQ_PARTNER_LU_NAME(USIBMSC.SJA2050I )
DESCRIPTION(OS/2, Paris, Car dealer)
PARTNER_LU_ALIAS(OPARDLR1)
PARTNER_LU_UNINTERPRETED_NAME(SJA2050I)
MAX_MC_LL_SEND_SIZE(32767)
CONV_SECURITY_VERIFICATION(NO)
PARALLEL_SESSION_SUPPORT(YES);
DEFINE_PARTNER_LU FQ_PARTNER_LU_NAME(USIBMSC.SJA2054I )
DESCRIPTION(AS/400, San Jose, Car dealer 1)
PARTNER_LU_ALIAS(ASJDLR1)
PARTNER_LU_UNINTERPRETED_NAME(SJA2054I)
MAX_MC_LL_SEND_SIZE(32767)
CONV_SECURITY_VERIFICATION(NO)
Appendix A. OS/2 Communications Manager Network Definition File 261

262 DataHub Implementation and Connectivity
PARALLEL_SESSION_SUPPORT(YES);
DEFINE_PARTNER_LU FQ_PARTNER_LU_NAME(USIBMSC.VDHTORD1 )
DESCRIPTION(DHS/VM, Toronto, Car dealer 1)
PARTNER_LU_ALIAS(DHTORDR1)
PARTNER_LU_UNINTERPRETED_NAME(VDHTORD1)
MAX_MC_LL_SEND_SIZE(32767)
CONV_SECURITY_VERIFICATION(NO)
PARALLEL_SESSION_SUPPORT(YES);
DEFINE_PARTNER_LU_LOCATION FQ_PARTNER_LU_NAME(USIBMSC.LUDB23 )
DESCRIPTION(DB2, New York, DB2CENTDIST)
WILDCARD_ENTRY(NO)
FQ_OWNING_CP_NAME(USIBMSC.SCG20 )
LOCAL_NODE_NN_SERVER(NO);
DEFINE_PARTNER_LU_LOCATION FQ_PARTNER_LU_NAME(USIBMSC.LUSQLVMA )
DESCRIPTION(SQL/DS, Toronto, Car dealer 1)
WILDCARD_ENTRY(NO)
FQ_OWNING_CP_NAME(USIBMSC.SCG20 )
LOCAL_NODE_NN_SERVER(NO);
DEFINE_PARTNER_LU_LOCATION FQ_PARTNER_LU_NAME(USIBMSC.SJA2018I )
DESCRIPTION(OS/2, Montreal, Car dealer)
WILDCARD_ENTRY(NO)
FQ_OWNING_CP_NAME(USIBMSC.SJA2018I )
LOCAL_NODE_NN_SERVER(NO);
DEFINE_PARTNER_LU_LOCATION FQ_PARTNER_LU_NAME(USIBMSC.SJA2019I )
DESCRIPTION(OS/2, Rio de Janiero, Car dealer)
WILDCARD_ENTRY(NO)
FQ_OWNING_CP_NAME(USIBMSC.SJA2019I )
LOCAL_NODE_NN_SERVER(NO);
DEFINE_PARTNER_LU_LOCATION FQ_PARTNER_LU_NAME(USIBMSC.EMQMACB1 )
DESCRIPTION(DHS/MVS, New York, Central Distribution)
WILDCARD_ENTRY(NO)
FQ_OWNING_CP_NAME(USIBMSC.SCG20 )
LOCAL_NODE_NN_SERVER(NO);
DEFINE_PARTNER_LU_LOCATION FQ_PARTNER_LU_NAME(USIBMSC.SJA2050I )
DESCRIPTION(OS/2, Paris, Car dealer)
WILDCARD_ENTRY(NO)
FQ_OWNING_CP_NAME(USIBMSC.SJA2050I )
LOCAL_NODE_NN_SERVER(NO);
DEFINE_PARTNER_LU_LOCATION FQ_PARTNER_LU_NAME(USIBMSC.SJA2054I )
DESCRIPTION(AS/400, San Jose, Car dealer 1)
WILDCARD_ENTRY(NO)
FQ_OWNING_CP_NAME(USIBMSC.SJAS400A )
LOCAL_NODE_NN_SERVER(NO);
DEFINE_PARTNER_LU_LOCATION FQ_PARTNER_LU_NAME(USIBMSC.VDHTORD1 )
DESCRIPTION(DHS/VM, Toronto, Car dealer 1)
WILDCARD_ENTRY(NO)
FQ_OWNING_CP_NAME(USIBMSC.SCG20 )
LOCAL_NODE_NN_SERVER(NO);
DEFINE_MODE MODE_NAME(#INTER )

COS_NAME(#INTER )
DEFAULT_RU_SIZE(YES)
RECEIVE_PACING_WINDOW(7)
MAX_NEGOTIABLE_SESSION_LIMIT(8)
PLU_MODE_SESSION_LIMIT(8)
MIN_CONWINNERS_SOURCE(4);
DEFINE_MODE MODE_NAME(IBMRDB )
DESCRIPTION(Logmode for DRDA connection)
COS_NAME(#CONNECT)
DEFAULT_RU_SIZE(YES)
RECEIVE_PACING_WINDOW(4)
MAX_NEGOTIABLE_SESSION_LIMIT(32767)
PLU_MODE_SESSION_LIMIT(8)
MIN_CONWINNERS_SOURCE(0);
DEFINE_MODE MODE_NAME(EMQMLOGM)
DESCRIPTION(Mode for DHS/MVS)
COS_NAME(#CONNECT)
DEFAULT_RU_SIZE(YES)
RECEIVE_PACING_WINDOW(4)
MAX_NEGOTIABLE_SESSION_LIMIT(32767)
PLU_MODE_SESSION_LIMIT(1)
MIN_CONWINNERS_SOURCE(1);
DEFINE_DEFAULTS IMPLICIT_INBOUND_PLU_SUPPORT(NO)
DESCRIPTION(Created on 02-25-93 at 09:50a)
DEFAULT_MODE_NAME(BLANK)
MAX_MC_LL_SEND_SIZE(32767)
DEFAULT_TP_OPERATION(NONQUEUED_AM_STARTED)
DEFAULT_TP_PROGRAM_TYPE(BACKGROUND)
DEFAULT_TP_CONV_SECURITY_RQD(NO)
MAX_HELD_ALERTS(10);
DEFINE_TP TP_NAME(EMQ2T)
DESCRIPTION(DataHub Support/2)
PIP_ALLOWED(NO)
FILESPEC(C:\EMQ2\EMQ2T.EXE)
CONVERSATION_TYPE(EITHER)
CONV_SECURITY_RQD(YES)
SYNC_LEVEL(EITHER)
TP_OPERATION(NONQUEUED_AM_STARTED)
PROGRAM_TYPE(BACKGROUND)
RECEIVE_ALLOCATE_TIMEOUT(INFINITE);
DEFINE_CPIC_SIDE_INFO SYMBOLIC_DESTINATION_NAME(SMTLDLR1)
DESCRIPTION(DHS/2, Montreal, Car dealer)
FQ_PARTNER_LU_NAME(USIBMSC.SJA2018I )
MODE_NAME(IBMRDB )
TP_NAME(EMQ2T);
DEFINE_CPIC_SIDE_INFO SYMBOLIC_DESTINATION_NAME(SRIODLR1)
DESCRIPTION(DHS/2, Rio de Janiero, Dealer 1)
PARTNER_LU_ALIAS(ORIODLR1 )
MODE_NAME(IBMRDB )
TP_NAME(EMQ2T);
DEFINE_CPIC_SIDE_INFO SYMBOLIC_DESTINATION_NAME(SMNYCENT)
DESCRIPTION(DHS/MVS, New York, Central Distribution)
Appendix A. OS/2 Communications Manager Network Definition File 263

PARTNER_LU_ALIAS(DHNYCENT )
MODE_NAME(EMQMLOGM)
TP_NAME(ANY);
DEFINE_CPIC_SIDE_INFO SYMBOLIC_DESTINATION_NAME(SPARDLR1)
DESCRIPTION(DHS/2, Paris, Car dealer)
PARTNER_LU_ALIAS(OPARDLR1 )
MODE_NAME(IBMRDB )
TP_NAME(EMQ2T);
DEFINE_CPIC_SIDE_INFO SYMBOLIC_DESTINATION_NAME(SASJDLR1)
DESCRIPTION(DHS/400, San Jose, Car dealer 1)
PARTNER_LU_ALIAS(ASJDLR1 )
MODE_NAME(IBMRDB )
TP_NAME(QDMU/QSTSC);
DEFINE_CPIC_SIDE_INFO SYMBOLIC_DESTINATION_NAME(SVTORDR1)
DESCRIPTION(DHS/VM, Toronto, Car dealer 1)
PARTNER_LU_ALIAS(DHTORDR1 )
MODE_NAME(IBMRDB )
TP_NAME(EMQVRSID);
START_ATTACH_MANAGER;
264 DataHub Implementation and Connectivity

Glossary
This glossary contains the terms and abbreviations
used in the DataHub/2 user interface and publications.
Each entry contains a definition of the term and often
includes detailed information about how the term
applies specifically to the way you use DataHub/2.
A
action. One of the defined tasks that DataHub/2
performs. In DataHub/2, for example, an action might
be to display database activity, to add authorizations,
or to run JCL or SQL.
action bar. The area at the top of a DataHub/2
window with entries that enable a user to access the
selections available in that window. For example,
when you select Help on the action bar, the Help
pull-down menu is displayed. See also DataHub/2
window.
Add function. In DataHub/2, Add is a function that
adds authorizations for one or more users on one or
more objects.
To use the Add function, select an object from the
client area, then select Add from the Actions
pull-down menu or use the DataHub/2 ADD command.
This function is part of the DataHub/2 tools feature.
Advanced program-to-program communications
(APPC). (1) An implementation of the Systems
Network Architecture (SNA) logical unit (LU) 6.2
protocol that allows interconnected systems to
communicate and share the processing of programs.
See logical unit 6.2 (LU 6.2). (2) The general facility
characterizing the LU 6.2 architecture and its various
implementations in products. (3) Sometimes used to
refer to the LU 6.2 architecture and its product
implementations as a whole, or an LU 6.2 product
feature in particular, such as an APPC application
programming interface.
alias name. A name unique within one of two or
more interconnected networks that is assigned by a
gateway system service control point and is used in
that subnetwork to represent a network addressable
unit that resides in another subnetwork. Alias names
must be predefined within a gateway system service
control point; if an alias is not provided, it is assumed
to be the same as the real name.
APPC. See Advanced Program-to-Program
Communications.
append. To add information to the end of an existing
file.
application requester (AR). The source of a request
to a remote RDBMS. When an application uses SQL
to access a remote relational database, the function
receiving the application request must determine
where the data is located and connect with the
remote relational database system. In DRDA
architecture terms the function that makes this
connection is the application requester. See also
application server.
application server (AS). The target of a request from
an application requester. The function that receives
the requests from the application requester and
forwards them to the database management system.
See also application requester.
application tracing. The recording of information
about each processing event during the execution of
an application. The contents of the trace record vary,
depending on what is relevant for an event. Typically,
the time when events occurred, their duration, and
the way they were performed are recorded.
AR. See application requester.
AS. See application server.
AS/400. Application System/400.
authorization. A general term for the privileges and
authorities that allow users to access objects and
perform actions on objects in local and remote RDBs.
Authorizations can be on individual objects, grouped
by object type, or grouped by the user to whom they
apply. See also user authorizations and object
authorizations.
authorization ID. The user identification of data
associated with a set of privileges. An authorization
ID may represent an individual, an organizational
group, or a function.
authorization statement. A GRANT or REVOKE
statement used to modify authorizations. Additional
AS/400 authorizations are accessed with the
AS4GRANT and AS4REVOKE statements.
B
Backup. In DataHub/2, Backup is a function that
saves a copy of an OS/400 or DB2 relational table in a
form suitable for subsequent recovery.
To use the Backup function, select an object from the
client area, then select Backup from the Utilities
pull-down menu, or use the DataHub/2 BACKUP
command. This function is part of the DataHub/2
tools feature.
© Copyright IBM Corp. 1993 265

ase product. A relational database management
product, that is, DB2, SQL/DS, OS/400, or OS/2
Database Manager.
BookManager READ. BookManager READ is an IBM
licensed program used to find and read softcopy
books that are available on your host or workstation.
There are four versions of this application for use on
different platforms (READ/MVS, READ/VM, READ/2,
and READ/DOS).
bufferpool. Virtual storage reserved to satisfy the
buffering requirements for tables or indexes.
Bufferpools are applicable to DB2 environments only.
C
cascading delete. The deletion of multiple
authorizations after a single authorization is selected
for deletion. If a user has an authorization that can
be granted to other users, and it has been granted to
other users, deletion of the original authorization will
lead to the subsequent deletion of the authorizations
that were granted. This applies to all authorizations
that were granted from the original user and
subsequently. For example, Erik grants an
authorization to Jane, who in turn grants it to Pam
and Gavin. Gavin grants it to James and Moira. If all
of the users have only one instance of this
authorization, deleting it from Erik will delete it from
all of them.
If a user has been granted an authorization by more
than one other user, that authorization is retained by
the user if the granting users have their
authorizations deleted, providing there is at least one
authorization remaining.
cascading pull-down. A pull-down that is invoked
from another pull-down.
catalog. (1) A set of system tables maintained by
OS/2 Database Manager. Catalog tables are created
when the database is created and contain information
about tables, views, and indexes. (2) A utility that
records a database and information about the
database.
CCSID. See coded character set identifier.
CL. See control language.
client area. The part of the DataHub/2 window inside
the border and below the action bar. It is the
workspace containing the objects with which you can
work. In DataHub/2, you can build a treelike
representation of all or some of the hosts, RDBs, and
objects that are configured to DataHub/2, using a
series of display actions. You can then use actions to
perform tasks on selected objects.
code page. A particular assignment of hexadecimal
identifiers to graphic characters.
266 DataHub Implementation and Connectivity
code point. An identifier that tells a tool (either the
host or the workstation component) how to interpret
the data following the code point in a tools
conversation flow.
coded character set identifier (CCSID). An SAA
Code Page Architecture (CPA) 2-byte (unsigned)
binary number that uniquely identifies an encoding
scheme and one or more pairs of character sets and
code pages.
collapse. A CUA term relating to the table of
contents of an online publication. To collapse a topic
you can either use the mouse to click on the minus
sign beside the topic, or you can highlight that topic
and press the minus (-) key. The minus sign that
appears beside the topic indicates that you can
expand the topic.
collection. A user-defined grouping of objects (for
example, tables, views, or packages) that are
contained within an RDB. In DataHub/2, the collection
is the second qualifier of a fully qualified object name,
rdb.collection.object, for example:
POKDDB1.FINANCE.USER_TABLE
In this example, FINANCE is the name of the
collection for this table.
command. A request to execute a particular
DataHub/2 function. You can issue a DataHub/2
command from an OS/2 window, a DataHub/2 window,
or a C program.
commit. The process that allows data in an RDB that
has been changed by one application or user to be
accessed by other applications or users. When a
COMMIT occurs, locks are freed so that other
applications can access the data that was just
committed.
commit frequency. The number of SQL statements to
be run before a COMMIT is to be issued.
Setting the commit frequency to a low number
minimizes the amount of work that may need to be
performed again if an SQL statement fails. Setting
the commit frequency to a higher number will cause
more locking to occur, restricting access to the
database. The value you set should depend on the
activity, size, and security of the RDBs being updated.
commit point. A point in the commit process that
occurs when data, changed by a user or application,
is considered complete. The data is updated and all
locks on the data are freed.
Common Programming Interface (CPI). Definitions of
those application development languages and
services that have (or are intended to have)
implementations on and a high degree of
commonality across the SAA environments. One of
the three SAA architectural areas (the other two

eing Common Communications Support and
Common User Access).
Common User Access (CUA). Guidelines for the
dialog between a person and the workstation or
terminal. One of the three SAA architectural areas
(the other two being Common Programming Interface
and Common Communications Support).
Communications Manager. A component of OS/2
Extended Services that lets a workstation connect to a
host and use the host resources as well as the
resources of other PWSs to which the workstation is
attached, either directly or through a host.
contextual help. Help that gives information about
the specific item the cursor is on. The help is
contextual because it provides information about a
specific item as it is currently being used. Contrast
with general help.
continue on error. An error-handling option
available for most DataHub/2 functions. When you
specify this option, DataHub/2 will continue to run an
application when it encounters a non-severe error (an
error with a severity code less than or equal to 8).
Contrast with stop on error.
control language. The set of all commands with
which a user requests system functions on an AS/400
system.
control point. The programmable workstation where
DataHub/2 started executing.
cooperative processing. In SAA usage, the
coordinated use of a programmable workstation with
one or more linked systems to accomplish a single
goal.
Copy Data. In DataHub/2, Copy Data is a function
that is used to:
• Copy basic database objects (tables, views, and
indexes). This can be within one RDB or between
two RDBs, one at a time or in groups.
• Copy authorizations from one or more objects at
a source RDB to corresponding objects at a target
RDB. You can copy either:
− Authorizations for all users on the object
− Authorizations for selected users on the
object.
• Copy authorizations held by a user on objects to
another user within one or between two RDBs.
You can copy either:
− All authorizations on all objects authorized for
a user
− The authorizations for one or more selected
objects authorized for a user.
To use the Copy Data function, select Copy from the
Actions pull-down menu or use the DataHub/2 COPY
command. This function is part of the DataHub/2
tools feature.
CPI. See Common Programming Interface.
CPU time. In DataHub/2, the amount of CPU time
used by the RDBMS work unit selected from a display
request since it began processing.
The time is in the format specified for the OS/2
system on which DataHub/2 is running. The time
format has three decimal places for milliseconds
separating the time by the decimal separator
specified for the OS/2 system.
For example, if the OS/2 system uses the JIS time
format with a comma decimal separator, the time will
appear as:
1 day 01:13:14,138
If the time is less than a day, it will appear as:
12:54:32,002
If the time is greater than 30 days, it will appear as:
>30 days 12:54:32,002
CUA. See Common User Access.
customize. To change the system characteristics or
defaults to meet user or site requirements.
D
DASD. See direct access storage device.
data control language. SQL language statements
used to control user authorization to relational
database objects.
data definition language. SQL language statements
used to create definitions of relational database
objects.
data integrity. (1) The condition that exists as long
as accidental or intentional destruction, alteration, or
loss of data does not occur. (2) Preservation of data
for its intended use. See also integrity.
data link control. (1) In Systems Network
Architecture, the protocol layer that consists of the
link stations that schedule data transfer over a link
between two nodes and perform error control for the
link. (2) In Communications Manager, a profile
containing parameters for a communication adapter.
database. In DB2, a collection of table spaces and
index spaces.
database administrator (DBA). An individual or
group responsible for the design, development,
operation, safeguarding, maintenance, and use of a
database. DBA is the highest authority level an
SQL/DS user can have.
Glossary 267

database catalog. A database table that defines the
database, for example, authorizations, structure,
views.
Database Manager. A component of OS/2 Extended
Services consisting of Database Services, Query
Manager, and Remote Data Services. Database
Manager is based on the relational model of data and
allows users to create, update, and access databases.
DATABASE 2 (DB2). A program that provides a
full-function relational database management system
on MVS and supports access from MVS applications
running under IMS, CICS, TSO, or batch
environments.
DataHub. IBM SystemView Information Warehouse
DataHub. This refers to the overall family of DataHub
components including:
• IBM SystemView Information Warehouse
DataHub/2 (DataHub/2)
• IBM SystemView Information Warehouse DataHub
Support/MVS (DataHub Support/MVS)
• IBM SystemView Information Warehouse DataHub
Support/VM (DataHub Support/VM)
• IBM SystemView Information Warehouse DataHub
Support/2 (DataHub Support/2)
• IBM SystemView Information Warehouse DataHub
Support/400 (DataHub Support/400).
DataHub platform feature. The platform feature of
DataHub provides you with the ability to display
objects in all your managed databases and run
dynamic SQL and JCL. It provides the base on which
you can install the tools feature or tools from other
sources.
DataHub tools feature. The tools feature of DataHub
provides the ability to copy data between host
databases, manage authorizations at those
databases, and query the status of database requests.
It also provides such utilities as load, unload, and
backup host databases.
DataHub Support. IBM SystemView Information
Warehouse DataHub Support. This term is used to
refer to the general collection of host DataHub
components. The following components are the
“managed host” components that are managed from
the DataHub/2 control point:
• DataHub Support/MVS
• DataHub Support/VM
• DataHub Support/400
• DataHub Support/2.
DataHub/2. The workstation component of DataHub
running under OS/2.
268 DataHub Implementation and Connectivity
DataHub/2 database. The database that contains the
DataHub/2 internal tables, which store information
such as supported host names and additional tool
information.
DataHub Support/2. The host component of DataHub
for the OS/2 environment.
DataHub Support/400. The host component of
DataHub for the OS/400 environment.
DataHub Support/MVS. The host component of
DataHub for the MVS environment.
DataHub Support/VM. The host component of
DataHub for the VM environment.
DataHub/2 window. The primary window of
DataHub/2, which is the first window you see after
you have logged on to DataHub/2. The main
components of the DataHub/2 window are the action
bar at the top of the window and the client area below
the action bar. See also action bar and client area.
DataHub/2 workstation. The programmable
workstation where DataHub/2 is running.
DBA. See database administrator.
DBCS. See double-byte character set.
dbspace. A logical allocation of space in a storage
pool contained in a database. Contains one or more
tables and their associated indexes. Dbspaces are
applicable to SQL/DS environments only.
DB2. See DATABASE 2.
DDCS/2. See Distributed Database Connection
Services/2.
DDS. See Distributed Data Services.
default value. A value used by DataHub/2 when you
have not specified a value. This value can be set by
the system and overridden by you.
Delete function. In DataHub/2, Delete is a function
that is used to delete authorizations for one or more
users on one or more objects.
To use the Delete function, select Delete from the
Actions pull-down menu or use the DataHub/2 DELETE
command. This function is part of the DataHub/2
tools feature.
delimited ASCII (DEL) file format. A DEL file is a
sequential ASCII file with row and column delimiters.
Each DEL file is a stream of ASCII characters
consisting of cell values ordered by row and then by
column.

direct access storage device (DASD). A device for
storing data in which access time is effectively
independent of the location of the data.
Display function. In DataHub/2, there are two
functional features of the Display function:
• To display objects on the client area on the
DataHub/2 window. This function is part of the
DataHub/2 platform feature.
• To obtain information about database activity at
any part of the network of systems within your
company. The information can be used to assist
in identifying problems arising in the distributed
database network. This function of Display is part
of the DataHub/2 tools feature and is referred to
as ″Display Status.″
Whether you are displaying objects or database
activity, the same Display action is selected from the
Actions pull-down and the same DISPLAY command is
used.
To use the Display function, select Display from the
Actions pull-down menu or use the DataHub/2
DISPLAY command.
Display Status function. See Display function.
distributed data. Data that is distributed across
multiple RDBMSs in a network but appears to users
as a logical whole, locally accessible.
Distributed Data Services (DDS). The OS/2
implementation of Distributed Data Management
(DDM). DDM (and DDS in OS/2) is a prerequisite for
Distributed Relational Database Architecture (DRDA).
distributed database. A database that appears to
users as a logical whole, locally accessible, but is
composed of databases in multiple RDBMSs.
Distributed Database Connection Services/2. A
software connection between a database client on a
workstation and a database on a host.
distributed environment. An environment in which an
organization′s data is distributed among different
computing environments that may be in different
geographical locations. A common characteristic of
distributed environments is a distributed database.
distributed processing. Processing that involves
resources or functions dispersed among two or more
interconnected processors.
Distributed Relational Database Architecture. A
connection protocol for distributed relational database
processing that is used by IBM′s relational database
products. DRDA consists of protocols for
communication between an application and a remote
RDBMS, and for communication between RDBMSs.
distributed relational database system. A system
involving multiple locations connected together in a
communications network, in which each location may
be one or more relational database systems. In a
distributed relational database management system,
a user at one location can access any data in the
network as if the data were stored at the user′s
location.
DLC. See data link control.
DLL. See dynamic link library.
double-byte character set. A set of characters in
which each character occupies two bytes. Languages
such as Japanese, Chinese, and Korean, which
contain more symbols than can be represented by 256
code points, require double-byte character sets.
Entering, displaying, and printing DBCS characters
requires special hardware and software support.
DRDA. See Distributed Relational Database
Architecture.
dynamic link library. A file containing a dynamic link
routine that is linked at load or run time.
E
elapsed time. In DataHub/2, the total time since the
RDBMS work unit selected for a display request
began processing.
The time is in the format specified for the OS/2
system on which DataHub/2 is running. The time
format has three decimal places for milliseconds
separating the time by the decimal separator
specified for the OS/2 system.
For example, if the OS/2 system uses the JIS time
format with a comma decimal separator, the time will
appear as:
1 day 01:13:14,138
If the time is less than a day, it will appear as:
12:54:32,002
If the time is greater than 30 days, it will appear as:
>30 days 12:54:32,002
entry field. An area of the window where you can
type information. Its boundaries are usually
indicated. See also selection field.
expand. A CUA term relating to the table of
contents of an online publication. To expand a topic,
you can either click on the plus sign beside the topic
or highlight the topic and press the plus (+) key. The
minus sign that appears beside the topic indicates
that you can collapse the topic.
extended help. See general help.
Glossary 269

F
foreign key. A key that is specified in the definition
of a referential constraint. A table with a foreign key
is a dependent table. The key must have the same
number of columns, with the same descriptions, as
the primary key of the parent table.
from requester type requester name. In DataHub/2,
this phrase is applicable when the unit of work is
servicing a distributed request. It indicates the type
and name of the system that is acting as a requester
to the serving work unit.
The valid values for the requester type are:
• DB2 vv.rr.m
• SQL/DS vv.rr.m
• OS/400 vv.rr.m
• OS/2 Database Manager vv.rr.m
Where:
vv.rr.m indicates the version (vv), release (rr),
and modification level (m) of the requester.
See also RDBMS work unit, serving work, and on
server type server name.
function. In DataHub/2, function is a general term
used to describe both the action you can perform
using the DataHub/2 window and the command you
can run from a command line.
G
gateway. A functional unit that connects two
computer networks of different network architectures.
general help. Help that provides information about
the contents of the application window from which you
requested help. Contrast with contextual help.
grant. Gives authority to a user ID or group ID.
H
host. A computer that usually performs network
control functions and provides end users with
services such as computation and database access.
The host environments that are supported in DataHub
are MVS, OS/400, OS/2, and VM.
I
IBM Extended Services for OS/2. An IBM licensed
program that contains the Database Manager and
Communications Manager components and uses a
base operating system equivalent to the IBM
Operating System/2 Standard Edition Version 1.30.1.
270 DataHub Implementation and Connectivity
IBM Structured Query Language/400. An IBM
licensed program that provides a set of commands to
access and manipulate data on an OS/400 system.
Applications written using SQL/400 can be easily
transported to other IBM systems.
implication message. Extra information given to a
user before executing a copy object operation, or an
add, delete, or copy authorization operation. The
purpose of an implication message is to alert the user
to an important consequence of the execution of the
operation.
index. A set of pointers that are logically ordered by
the values of a key. Indexes provide quick access to
data and can optionally enforce uniqueness on the
rows in a table. A fully qualified index name is of the
form rdb.collection.object.
Information Presentation Facility (IPF). The OS/2
programming tool used to develop help information
for DataHub/2.
integrity. The condition that exists when data,
systems, and programs are protected from
inadvertent or malicious destruction or alteration.
See also data integrity.
IPF. See Information Presentation Facility.
J
JCL. See job control language.
JES. See job entry system.
job control language (JCL). A control language used
to identify an MVS job to an operating system and to
describe the job′s requirements.
job entry system (JES). An MVS job administration
system. MVS jobs are submitted through JES, which
controls the job execution and produces an output of
the job results.
job name. The identifier of the job associated with
the RDBMS work unit selected for the display details
request. Job name is applicable to OS/400 and MVS
environments only.
K
• OS/400—Job name is the fully qualified job
identifier. See also SYSID (OS/400).
• MVS—Job name corresponds to the DB2
correlation identifier.
keyword. A part of a DataHub/2 command parameter
that is shown in uppercase letters in the syntax
diagram. See also parameter.

L
LAN. See local area network.
like. Refers to two or more instances of the same
RDBMS, for example, two instances of SQL/DS.
Contrast with unlike.
like environments. A network of similar RDBMSs
that provide access to data residing at any of the
locations containing a participating instance of the
RDBMS. Contrast with unlike environments.
Load function. In DataHub/2, Load is a function that
inserts or replaces rows in an existing relational
table, or view (OS/2), from data contained in existing
sequential files at any RDBMS.
To use the Load function, select an object from the
client area, then select Load from the Utilities
pull-down menu or use the DataHub/2 LOAD
command. This function is part of the DataHub/2
tools feature.
local area network (LAN). A network of devices that
are connected to one another for communication. A
local area network can be connected to a larger
network. See also wide area network.
local identifier. In DataHub/2, the unique identifier
assigned to the RDBMS work unit at the system
selected for the display request. The local identifier
is the system-specific identifier (SYSID). See also
SYSID (MVS), SYSID (OS/400), and SYSID (VM)..
local system. The RDBMS in the user′s processor.
Contrast with remote system.
local work. In DataHub/2, local work is a unit of work
that does not use distributed database services. The
request and the processing of the request both
happen at the same database. DataHub/2 displays
local units of work under the heading “local work.”
The definition of a local unit of work is different for
each host environment and query that is requested at
a host or RDB:
• Display at RDB:
− OS/400—A unit of work is classified as local
when an application is running at the selected
RDB and is accessing relational data at that
same RDB.
− MVS—A unit of work is classified as local
when an application is running at the selected
RDB and is accessing relational data at that
same RDB.
− VM—In SQL/DS the unit of work is never
classified as local. Units of work on VM are
classified as either requesting or serving to
allow DataHub/2 to show the relationship
between the SQL/DS requester and the
SQL/DS database virtual machine.
• Display at host:
− OS/400—Only one RDB can reside at an
OS/400 host. A unit of work is classified as
local when an application is running at the
host currently being processed by DataHub/2
and accessing data at the RDB located at the
host.
− MVS—One or more RDBs can reside at an
MVS host. DataHub/2 provides information
for each RDB. Therefore, a unit of work is
classified as local when an application is
running at the RDB currently being processed
by DataHub/2 and accessing relational data at
that same RDB.
− VM—In SQL/DS the unit of work is never
classified as local. Units of work on VM are
classified as either requesting or serving to
allow DataHub/2 to show the relationship
between the SQL/DS requester and SQL/DS
database system.
location. In DataHub/2, a location is either the name
of a host or a relational database. The location is
represented by an identifier of 1 to 18 characters.
lock. A mechanism for controlling access to a
database object to maintain that object′s integrity.
See also LOCKID.
LOCKID. Lock identifier. An alphanumeric string of 1
to 73 characters that allows the host to identify an
object on the host system on which locks are held or
requested. LOCKIDs are system specific and defined
by each host. See also LOCKID (MVS), LOCKID
(OS/400), and LOCKID (VM).
LOCKID (MVS). The lock identifier (LOCKID) for an
MVS system is made up of a DB2 internal lock name
and a DB2 internal hash token. It is of the form:
lock_name.hash_token
Where:
lock_name Is a character representation, from
the set 0-9 and A-F, of a DB2
internal lock name representing the
hexadecimal values in LOCKID.
.(period) Is a one-character delimiter.
hash_token Is a character representation, from
the set 0-9 and A-F, of a DB2
internal hash token representing
the hexadecimal values in LOCKID.
There is one exception: for a DB2 internal system
lock or latch, in which case the LOCKID is SYSLOCK
or LATCH, respectively.
LOCKID (OS/400). The lock identifier (LOCKID) for an
OS/400 system can be one of these formats:
Glossary 271

lib/obj*type
lib/file(member)
lib/file(member)*ACCPTH
lib/file(member)*DATA
lib/file(member)recno
Where:
lib Is the object library, which is from 1 to
10 characters long.
/ Is a one-character separator between
the library and object name.
obj Is the object name, which is from 1 to
10 characters long.
*type Is the object type, which is from 1 to 7
characters long. The delimiter
(asterisk) separates the object name
from the object type.
file Is the file name, which is from 1 to 10
characters long.
( Is a one-character separator, opening
parenthesis, between the file and
member names.
member Is a file member name, which is from
1 to 10 characters long.
) Is a one-character separator, closing
parenthesis, between the member
name and the last part of the LOCKID.
*ACCPTH Is a constant that indicates that
database file members with
associated access paths (indexes)
have locks on the access path.
*DATA Is a constant that indicates that
database file members have a lock on
a control block.
recno Is 1 to 10 characters long from the set
0-9, representing a relative record
number.
LOCKID (VM). The lock identifier (LOCKID) for a VM
system is a dbspace number made up of 1 to 5 digits,
from the set 0-9, that does not contain any leading
zeros or blanks and no trailing blanks.
The exception is for database locks. In this case,
LOCKID is made up of two characters, DB.
lock mode. In DataHub/2, the lock attribute that
specifies the type of access that concurrently running
programs can have to a resource that has been
locked by the RDBMS work unit selected for display
lock request. For example, a lock mode of S for share
indicates the lock owner and any concurrent
application processes can read, but not change, the
locked data. The exact meaning of lock modes may
differ for each host due to differences in the RDBMS.
272 DataHub Implementation and Connectivity
lock object name. In DataHub/2, the name of the
object on which a lock is being requested or held by
the RDBMS work unit selected for a display lock
request.
lock type. In DataHub/2, the type of database object
(for example, dbspace, table space, or index key) on
which the lock is being requested or held by the
RDBMS work unit selected for a display lock request.
logical unit. (1) A port through which an end user
accesses the SNA network in order to communicate
with another end user and through which the end user
accesses the functions provided by system services
control points. (2) A type of network addressable unit
that enables end users to communicate with each
other and gain access to network resources.
logical unit 6.2. A port through which an application
in a distributed processing environment accesses the
SNA network to communicate with another application
using the SNA general data stream (which is a
structured data system).
LU. See logical unit.
LU name. A 1- to 8-character name of a logical unit
within an SNA network. A logical unit is a port
through which a user communicates with another user
over an SNA network.
LU 6.2. See logical unit 6.2
LUW. Logical unit of work. See also unit of work,
and RDBMS work.
LUWID. Logical unit of work identifier. A unique
identifier for a distributed unit of work that can be
used to access it at both the application requester or
application server from the display RDBMS work
action. The LUWID identifies the components of a
unit of work. It consists of:
• A netname, which is a 1- to 8-character network
ID.
• An LU name, which is a 1- to 8-character name of
a logical unit within an SNA network. A logical
unit is a port through which a user communicates
with another user over an SNA network.
• An LUW instance, which is 12 hexadecimal
characters long. With the netname and LU name,
the LUW instance provides a unique identifier for
a unit of work.
• Period (.) separator between the parts of the
LUWID.
An example of an LUWID is:
SAN_JOSE.STL.0000011F6C22
LUW instance. Twelve hexadecimal characters that,
with the netname and LU name, provide a unique
identifier of a unit of work.

M
map. To copy information in one form to another.
For example, to copy data contained in an input file
on a disk to tables in a database.
Multiple Virtual Storage (MVS). Multiple Virtual
Storage, consisting of MVS/System Product Version 1
and the MVS/370 Data Facility Product operating on a
System/370 processor.
MVS. See Multiple Virtual Storage.
N
national language support (NLS). Support in a
product that allows direct interaction in the language
and code pages of the customer′s country.
navigation path. The path taken by a user when
using the DataHub/2 window, to reach an object using
a series of display actions.
netname. A 1- to 8-character name identifying a
network. An example of a netname is:
SAN_JOSE
Networking Services/2. An IBM program that
requires OS/2 Communications Manager and provides
Advanced peer-to-peer networking (APPN) services.
NLS. See National Language Support.
node. A host environment instance (an MVS, VM,
OS/400, or OS/2 system) in which a DataHub
component is running. A node can have one or more
DRDA1 requesters and/or server components.
Non-delimited ASCII (ASC) file format. As ASC file is
a sequential ASCII file with row delimiters used to
exchange data with any ASCII product. Each ASC file
is a stream of ASCII characters consisting of data
values organized by row and column.
nonlabeled tape. A tape that has no labels. Tape
marks are used to indicate the end of the volume and
the end of each data file.
number of locks. In DataHub/2, the number of locks
that the RDBMS work unit selected for a display locks
request is waiting for or holding.
O
object authorizations. In DataHub/2, the
authorizations associated with an object, such as a
table, view, or package. Object authorizations can be
copied from one object to another of the same object
type. Contrast with user authorizations.
object generators. The mechanism used to generate
a list of object occurrences for an object type. The
object occurrences may have been retrieved either:
• By a specific program
or
• By executing SQL at a remote RDB.
A tool that returns objects to the DataHub/2 window is
regarded as an object generator, for example, the
DataHub Display tool.
object occurrences. A component of a database
environment. In DataHub/2, an example of an object
occurrence might be a relational database named
RCHAS333 that appears under the RDB object type in
the client area. Object occurrences are displayed
under the name and icon of the object type. See also
object type.
object type. A type of object associated with a
database environment. In DataHub/2, examples of
object types are databases, tables, and views. Object
types are displayed in the client area above the
object occurrences they represent. See also object
occurrences.
OEM. original equipment manufacturer.
omit. To remove objects that you are not working
with when you are working in the client area.
on server type server name. In DataHub/2, this
phrase is applicable when the unit of work is servicing
a distributed request. It indicates the type and name
of the system that is acting as a server to the
requesting work unit.
The valid values for the server type are:
• DB2 vv.rr.m
• SQL/DS vv.rr.m
• AS/400 vv.rr.m
Where:
vv.rr.m indicates the version (vv), release (rr),
and modification level (m) of the server.
See also RDBMS work unit, requesting work, and
from requester type requester name.
Operating System/2 (OS/2). An IBM licensed
program that can be used as the operating system for
PWSs. The OS/2 licensed program can perform
multiple tasks simultaneously.
Operating System/400 (OS/400). An IBM licensed
program that can be used as the operating system for
the AS/400 system.
optimizer statistics. The statistics used by the
RDBMS optimizer to determine the best access paths
to data.
OS/2. See Operating System/2.
Glossary 273

OS/400. See Operating System/400.
OS/2 ES. See IBM Extended Services for OS/2.
output field. A field in a device file in which data can
be modified by the program and sent to the device
during an output operation.
P
package. The control structure produced when the
SQL statements in an application program are bound
to an RDBMS. The RDBMS uses the control structure
to process SQL statements encountered during
statement execution.
package section. Identifies the section number within
the package assigned to the currently running SQL
statement. In DataHub/2, the package section is
associated with the RDBMS work unit selected for a
display details request at an SQL/DS RDB.
pane. One of the separate areas within a split
window. Panes can be sized by the user; resizing of
the panes does not take place, however, until either
the mouse button is released, or the enter key has
been pressed. Horizontal scrolling is independent
within each pane, but vertical scrolling is across the
two panes.
pane key. A key, or combination of keys, that can be
used to perform a function at a pane.
parameter. A keyword, a variable, or a combination
of keywords and variables used in conjunction with a
command to affect its result. In DataHub/2 command
syntax, required parameters are displayed on the
main path of the syntax diagram, and optional
parameters are displayed below the main path. The
default parameter is underlined.
participating instance. An RDBMS that is part of a
distributed relational database system.
peer node. An end point of a communications link or
a junction common to two or more links in a network.
Nodes can be processors, communication controllers,
cluster controllers, terminals, or workstations. Nodes
can vary in routing and other functional capabilities.
Personal Computer/Integrated Exchange Format
(PC/IXF) file format. IMPORT accepts only PC/IXF
files, not host IXF files. PC/IXF is a structured
description of a database table that contains an
external representation of the internal table.
physical unit. A set of protocols and services
defined by Systems Network Architecture for
communication between application programs.
plan. In DataHub/2, a group of one or more
packages. Plans are applicable to DB2 environments
only.
274 DataHub Implementation and Connectivity
pop-up window. A movable window, fixed in size, in
which you provide information required by DataHub/2
so that it can continue to process your request.
Presentation Manager. The interface of the OS/2
program that presents a graphics-based interface to
applications and files installed and running on the
OS/2 program.
primary key. A unique, non-null key that is part of
the definition of a table. A table cannot be defined as
a parent if it does not have a primary key.
privilege. The right or authority to access a specific
database object in a specified way.
privilege hierarchy. A structure that shows the
authorizations granted to users, and the users who
granted them.
profile. A DataHub/2 profile is linked to your OS/2
user ID and identifies the host user IDs and
passwords that are to be used when that profile is
active.
programmable workstation (PWS). A workstation
that has some degree of processing capability and
that allows a user to change its functions.
prompt. A symbol or action that requests you to
enter information.
PU. See physical unit.
pull-down menu. A list of choices extending from a
selected action-bar choice that gives you access to
actions, routings, and settings related to an object.
push button. A rectangle with text inside. Push
buttons are used in windows for actions that occur
immediately when the push button is selected.
PWS. See programmable workstation.
Q
qualifier. In DataHub/2, the specification of some
criteria that can be used to limit the number of object
occurrences of an object type that are to be
displayed.
R
radio button. A circle with text beside it. Radio
buttons are combined to show a user a fixed set of
choices from which only one can be selected. The
circle is partially filled when a choice is selected.
RDB. See relational database.

RDB name. The DRDA unique identifier for a
database within a network.
RDBMS. See relational database management
system.
RDBMS work. The database component of a running
application. When a program is run against an RDB,
the RDB creates a logical unit of work on the user′s
behalf.
In DataHub/2, RDBMS work is a display request using
the DataHub/2 window that provides a summary list of
the units of work (local, requesting, or serving work)
executing at a host or RDB.
When using the DataHub/2 DISPLAY command, the
equivalent function is RDBMS WORK SHORT. See
also local work, requesting work, or serving work.
RDBMS_WORK DEPENDENT UNITS. In DataHub/2,
RDBMS_WORK DEPENDENT UNITS is the DataHub/2
DISPLAY command that provides a list of the
dependent RDBMS work units for a lock held,
requested, or waited for by another RDBMS work unit.
You can determine the units of work currently running
that are affecting or being affected by the locks that a
unit of work is requesting.
When using the DataHub/2 window, the equivalent
Display Status function is Display Dependent RDBMS
work.
RDBMS_WORK DETAILS. In DataHub/2,
RDBMS_WORK DETAILS is the DataHub/2 DISPLAY
command that provides detailed status and
application information for a specific unit of work.
When using the DataHub/2 window, the equivalent
Display Status function is Display Details.
RDBMS_WORK LOCKS. In DataHub/2,
RDBMS_WORK LOCKS is the DataHub/2 DISPLAY
command that provides a list of the locks held,
requested, or waited for by the specified RDBMS work
units.
When using the DataHub/2 window, the equivalent
Display Status function is Display Locks.
RDBMS work needing lock. In DataHub/2, RDBMS
work needing lock is the result of a display request
when selecting the related object type of Dependent
RDBMS work using the DataHub/2 window. It
provides a list of the units of work that are holding or
requesting locks on an object or objects. You can
determine the units of work currently running that are
affecting or being affected by the locks that a unit of
work is requesting.
When using the DataHub/2 DISPLAY command, the
equivalent function is RDBMS_WORK DEPENDENT
UNITS.
RDBMS_WORK SHORT. In DataHub/2,
RDBMS_WORK SHORT is the DataHub/2 display
command that provides a summary list of the RDBMS
work units that match the qualifier or qualifiers that
you have specified.
When using the DataHub/2 window, the equivalent
Display Status function is Display RDBMS work.
RDBMS_WORK SQL STATEMENT. In DataHub/2,
RDBMS_WORK SQL STATEMENT is the DISPLAY
command that provides the SQL statements for the
selected RDBMS work units (local, requesting, or
serving work). RDBMS work SQL statement is
applicable to OS/400 and MVS environments only.
When using the DataHub/2 window, the equivalent
Display Status function is Display SQL statement.
RDBMS work unit. In DataHub/2, RDBMS work is a
recoverable sequence of operations that is sometimes
referred to as a logical unit of work. The RDBMS
ensures the consistency of the data by verifying that
either all the data changes made during a unit of work
are performed, or none of them is performed.
The RDBMS work unit is displayed as either local
work, requesting work, or serving work.
RDS. See remote data services.
Recover function. In DataHub/2, Recover is a
function that retrieves a backup copy of a table and
applies log or journal changes to return the table to
its current state at a distributed OS/400 or DB2
system.
To use the Recover function select an object from the
client area and select Recover from the Utilities
pull-down menu, or you can use the DataHub/2
RECOVER command. This function is part of the
DataHub/2 tools feature.
referential constraint. The relationship between two
tables that controls the association of data between
them, ensuring consistency. Referential constraint
ensures that references from a parent table to a
related table will give valid data.
refresh. An action that updates the information at
which you are currently looking. The contents of the
window can be updated to reflect the current status of
the information.
related object type. In DataHub/2, an object type that
can be navigated to from a selected object. The
relationships between objects determine which
objects can be displayed with other objects. For
example, tables are related to views and indexes and
therefore you can navigate to a view or an index from
a table.
relational database (RDB). An object consisting of a
relational database management system catalog and
all the relational database objects it describes. A
relational database′s implementation depends on its
SAA context:
Glossary 275

MVS A DB2 subsystem instance.
VM An SQL/DS server machine.
OS/400 An occurrence of the OS/400 operating
system. The OS/400 host name and the
RDB name can differ, but there is a
one-to-one correspondence.
OS/2 An occurrence of an OS/2 database.
There can be more than one RDB for
each copy of Database Manager.
relational database management system. A system
that manages relational databases. In DataHub/2,
relational database management systems are:
• DB2
• SQL/DS
• OS/400 database
• OS/2 Database Manager.
remote data access. The ability to use data
maintained by a remote system.
remote data services. A Database Manager
component that enables an application to access
Database Manager and a database on a remote
workstation. The application does not need to know
the physical location of the database. Remote data
services determines the database location and
manages the transmission of the request to Database
Manager and the reply back to the application.
remote system. An RDBMS other than the local
RDBMS. Often used to describe the relationship
between an application requester and an application
server.
Contrast with local system.
Reorganize function. In DataHub/2, Reorganize is a
function that reorganizes DB2 tables and indexes,
SQL/DS indexes, and OS/400 and OS/2 Database
Manager tables to reclaim space and sort the data,
providing more efficient access to data.
To use the Reorganize function you can select an
object from the client area and then select
Reorganize from the Utilities pull-down menu, or you
can use the DataHub/2 REORG command. This
function is part of the DataHub/2 tools feature.
requester. The source of a request to a server.
requesting work. In DataHub/2, requesting work is a
unit of work that has initiated a request to use the
distributed database at another RDBMS (server).
DataHub/2 displays requesting units of work under the
heading ″Requesting work.″
The definition of a requesting unit of work is different
for each host environment and query that is
requested at a host or RDB.
• Display at RDB:
276 DataHub Implementation and Connectivity
MVS A unit of work is classified as
requesting when an application is
running at the selected RDB and
accessing relational data on a
different RDB.
With DB2 it is possible that a unit of
work at a single RDB can be
classified as both serving and
requesting. A CONNECT statement
issued from another RDB results in
the unit of work being classified as a
serving unit of work. However, if the
SQL statement contains a three-part
table name that refers to another
DB2, the unit of work will be classified
as requesting.
OS/400 A unit of work is classified as
requesting when an application is
running at the selected RDB and
accessing relational data on a
different RDB.
VM Units of work at an SQL/DS RDB will
never be classified as requesting.
Units of work will always be classified
as serving at an RDB. See also
serving work for VM.
• Display at host:
MVS One or more RDBs can reside at an
MVS host. DataHub/2 provides
information for each RDB at the host.
Therefore, a unit of work is classified
as requesting when an application is
running at the RDB being processed
by DataHub/2 and accessing
relational data on a different RDB.
With DB2 it is possible that a unit of
work at a single RDB can be
classified as both serving and
requesting. A CONNECT statement
issued from another RDB results in
the unit of work being classified as a
serving unit of work. However, if the
SQL statement contains a three-part
table name that refers to another
DB2, the unit of work will be classified
as requesting.
OS/400 One RDB can reside at an OS/400
host. A unit of work is classified as
requesting when an application is
running at the RDB being processed
by DataHub/2 and accessing
relational data on a different RDB.
VM A unit of work is classified as
requesting when an application is
running at the selected host and is
accessing relational data at any RDB.
Therefore, units of work at a VM host
will always be classified as
requesting.

eturn code. A value returned to a program to
indicate the results of an operation requested by that
program.
Run function. In DataHub/2, Run is a function that
can be used to perform actions on objects by running
files containing JCL or SQL statements.
To use the Run function you can select Run from the
Actions pull-down menu, or you can use the
DataHub/2 RUN command. This function is part of the
DataHub/2 platform feature.
S
SAA. See Systems Application Architecture.
scroll bar. A part of a window, associated with a
scrollable area, that a user interacts with to see
information that is not currently visible.
secondary user. In DataHub Support, a second or
alternative user ID associated with the RDBMS work
unit selected for the display details request. Not
applicable to OS/400.
select. To explicitly identify one or more object types
or occurrences to which a subsequent action will
apply.
selection field. A set of related choices. See also
entry field.
selection list. Choices that a user can scroll through
to select one choice.
sequence number. A number that identifies the
physical location of a record in a data set.
sequential data set. A data set whose records are
organized on the basis of their successive physical
positions, such as on magnetic tape. Several of the
DB2 database utilities require sequential data sets.
server. The target of a request from a requester.
serving work. In DataHub/2, serving work is a unit of
work that is running at a distributed database (server)
as a result of a distributed request. DataHub/2
displays serving units of work under the heading
″Serving work.″
The definition of a serving unit of work is different for
each host environment and query that is requested at
a host or RDB.
• Display at RDB:
MVS A unit of work is classified as serving
when data is being accessed at the
selected RDB and the application is
running at a different RDB.
With DB2 it is possible that a unit of
work at a single RDB can be
classified as both serving and
requesting. A CONNECT statement
issued from another RDB results in
the unit of work being classified as a
serving unit of work. However, if the
SQL statement contains a three-part
table name that refers to another
DB2, the unit of work will be classified
as requesting.
OS/400 A unit of work is classified as serving
when data is being accessed at the
selected RDB and the application is
running at a different RDB.
VM A unit of work is classified as serving
when data is being accessed at the
selected RDB. Therefore, units of
work at an SQL/DS RDB will always
be classified as serving.
• Display at host:
MVS One or more RDBs can reside at an
MVS host. DataHub/2 provides
information for each RDB at the host.
Therefore, a unit of work is classified
as serving when data is being
accessed at the RDB being processed
by DataHub/2 and the application is
running at a different RDB.
With DB2 it is possible that a unit of
work at a single RDB can be
classified as both serving and
requesting. A CONNECT statement
issued from another RDB results in
the unit of work being classified as a
serving unit of work. However, if the
SQL statement contains a three-part
table name that refers to another
DB2, the unit of work will be classified
as requesting.
OS/400 One RDB can reside at an OS/400
host. Therefore, a unit of work is
classified as serving when data is
being accessed at the RDB being
processed by DataHub/2 and the
application is running at a different
RDB.
VM Units of work at a VM host are never
classified as serving. Units of work
are always classified as requesting at
a host. See also requesting work for
VM.
severity code. A code that indicates the seriousness
of an error condition.
site. A specific RDBMS in a distributed relational
database system. Synonymous with location.
site autonomy. The condition in which different
database sites can be administered independently.
Single nodes in the distributed system can still
Glossary 277

operate even when connections to other nodes have
failed.
SNA. See Systems Network Architecture.
snapshot. A snapshot is a stored database object
like a table, but for read-only data access. A
snapshot is periodically refreshed from the base
objects in its definition.
SQL. See Structured Query Language.
SQL/DS. See Structured Query Language/Data
System.
SQL executed. In DataHub/2, the number of SQL
statements processed by the RDBMS work unit
selected for the display details request.
SQL statement. In DataHub/2, display SQL statement
provides the statement in Structured Query Language
(SQL) that is currently being executed for the local,
requesting, and serving work units.
SQL/400. See IBM Structured Query Language/400.
state. In DataHub/2, indicates whether the RDBMS
work unit selected for a display request is waiting for
a lock (Wait), holding the lock (Held), or requesting
the lock (Req).
status. In DataHub/2, a character string describing
the current status (for example, Communication wait,
Not active, or I/O wait) of the RDBMS work unit (s)
listed as a result of a Display RDBMS work request.
stop on error. An error-handling option available for
most functions in DataHub/2. When you specify this
option, DataHub/2 will stop running an application
when it encounters an error with a severity code
greater than or equal to 8. Contrast with continue on
error.
storage group. The named set of host disk space
(DASD volumes) on which the DB2 data can be
stored. Storage groups are applicable to DB2
environments only.
storage pool. A specific set of available storage
areas. The database administrator uses these areas
to control storage of the database. A storage pool
contains one or more dbspaces. Storage pools are
applicable to SQL/DS environments only.
Structured Query Language (SQL). A language that
can be used within host programming languages, or
interactively, to define and manipulate data and to
control access to resources in a relational
environment.
Structured Query Language/400. IBM Structured
Query Language/400. An IBM licensed program that
provides a set of commands to access and
manipulate data on an OS/400 system. Applications
278 DataHub Implementation and Connectivity
written using SQL/400 can be easily transported to
other IBM systems.
Structured Query Language/Data System. An IBM
licensed program that is the SAA version of SQL for
the VM and VSE environments.
subsystem. A DB2 subsystem is defined to
DataHub/2 when an MVS host or RDB is configured to
DataHub/2. The Display status function identifies the
subsystem associated with the RDBMS work unit
selected for the display details request. Subsystems
are applicable to MVS and OS/400 environments only.
MVS Subsystem corresponds to the DB2
connection identifier.
OS/400 Subsystem is the name of the
subsystem in which the OS/400 job
for the RDBMS work unit is running.
syntax diagram. A diagram that uses graphic
notation to describe the structure of a command.
SYSID. See system-specific identifier.
SYSID (MVS). The system-specific identifier (SYSID)
for an MVS system is a 39-character string made up
of the agent control element (ACE) and the logical
unit of work identifier (LUWID). It is of the form:
ACE.NETNAME.LUNAME.LUW_instance
Where:
ACE The agent control element
(ACE) address is the
internal representation for
an active user (thread).
An ACE is unique for a
given thread for the life of
the thread. It is an
8-hexadecimal-character
representation of the host
ACE address.
. (period) Is a one-character
delimiter.
NETNAME Is a network identifier
which is from 1 to 8
characters long.
LUNAME Is a logical unit within an
SNA network which is from
1 to 8 characters long.
LUW_instance Is a unique identifier for a
unit of work which is a
12-hexadecimal-character
string.
An example of an MVS SYSID is:
1234ABCD.SYDNEY.LUNAME12.FFEDC3456788
SYSID (OS/400). The system-specific identifier
(SYSID) for an OS/400 system is a fully qualified
OS/400 job name. It is of the form:

jobnumber/userid/job name
Where:
jobnumber The system assigned job
number. This is 6 characters
long from the set 0-9.
/ Is a one-character separator
between the parts of the job
name.
userid Is a user identification that is 1
to 10 characters long.
job name Is a job name that is from 1 to
10 characters long. The first
character must be alphabetic.
An example of an OS/400 SYSID is:
533420/STEVEY/DISTDBDB14
SYSID (VM). The system-specific identifier (SYSID)
for a VM system is a special identifier made up of the
VM user ID and a time stamp. It is of the form:
userid.timestamp
Where:
userid Is a user identification, from 1 to
8 characters long. If delimited
with double quotes, it can be up
to 10 characters long.
. (period) Is a one-character delimiter.
timestamp Is the character representation
of the host time-of-day (TOD)
clock value, which is exactly 16
characters from the set 0-9 and
A-F.
An example of a VM SYSID is:
JANETF.AFEDAEEDEACDE000
Systems Application Architecture (SAA). A set of
IBM software interfaces, conventions, and protocols
that provide a framework for designing and
developing applications that are consistent across
systems.
Systems Network Architecture (SNA). The
description of the logical structure, formats, protocols,
and operational sequences for transmitting
information units through the networks as well as the
operational sequences for controlling the
configuration and operation of networks.
system-specific identifier. A string of alphanumeric
characters used to identify a work item. The SYSID
has different characters used to uniquely identify a
unit of work at an RDBMS. See also SYSID (MVS),
SYSID (OS/2), SYSID (OS/400), and SYSID (VM).
T
table. A named data object consisting of a specific
number of named vertical rows and some number of
unordered horizontal rows. A fully qualified table
name is of the form rdb.collection.object.
table column. A table column is a vertical component
of a table that consists of a name and a particular
data type. All values in a particular column share this
same data type.
table space. In DB2, a page set that is used to store
the records of one or more DB2 tables. Table spaces
are applicable to DB2 environments only.
three-part name. The fully qualified name of an SQL
object such as a table or view. A three-part name
usually consists of an RDB name, a collection ID, and
an object name.
time in state. In DataHub/2, the amount of time that
the RDBMS work unit selected for a display request
has been in the current state. See also state.
The time is in the format specified for the OS/2
system on which DataHub/2 is running. The time
format has three decimal places for milliseconds
separating the time by the decimal separator
specified for the OS/2 system.
For example, if the OS/2 system uses the JIS time
format with a comma decimal separator, the time will
appear as:
1 day 01:13:14,138
If the time is less than a day, it will appear as:
12:54:32,002
If the time is greater than 30 days, it will appear as:
>30 days 12:54:32,002
tool. One or more application programs that perform
DataHub user function such as copying database
objects or querying the status of a logical unit of
work.
tools conversation flows. Communications, carried
out using services provided by the DataHub
platforms, between the host and workstation
components of a DataHub tool.
trace controls. Parameters that determine whether
tracing will occur, which processing will be traced,
and where tracing output is to be written.
trace record. Trace output generated by DataHub/2.
Each trace record consists of header and detail
sections.
transparency. The ability to access remote data as
though it were local.
Glossary 279

U
UNC. See universal naming convention.
unit of recovery. A logical unit of work that
represents a recoverable sequence of operations
within a single resource manager, such as an instance
of DB2. The initiation and termination of a unit of
recovery define the points of consistency within a job.
See also unit of work and RDBMS work.
unit of work. See RDBMS work.
universal naming convention (UNC). A name used to
identify the server and netname of a resource, taking
the form: servernamenetnamepath and filename,
or servernamenetnamedevicename. See also
netname.
unlike. Refers to two or more different RDBMSs, for
example, SQL/DS and DB2. Contrast with like.
unlike environments. A network of dissimilar
RDBMSs that provide access to data residing at any
of the locations containing a participating
management system (for example, an RDBMS on an
MVS system and an RDBMS on a VM system
accessing data at each other′s sites). Contrast with
like environments.
Unload function. In DataHub/2, Unload is a function
that takes data from an existing relational table, or
view (OS/2), and stores it at a sequential file at the
RDBMS where the table, or view (OS/2), exists.
To use the Unload function you can select an object
from the client area and then select Unload from the
Utilities pull-down menu, or you can use the
DataHub/2 UNLOAD command. This function is part
of the DataHub/2 tools feature.
Update Statistics function. In DataHub/2, Update
Statistics is a function that updates the RDBMS
optimizer catalog statistics on DB2, SQL/DS, and OS/2
Database Manager systems. The optimizer uses
these statistics to determine the best access paths to
data.
To use the Update Statistics function you can select
an object from the client area and then select Update
statistics from the Utilities pull-down menu, or you
can use the DataHub/2 UPDATE STATS command.
This function is part of the DataHub/2 tools feature.
user. In DataHub/2, the identification of the user who
is running the rdbmswork listed as a result of a
display RDBMSwork request.
MVS The user is the primary authorization ID.
OS/400 The user is the OS/400 user ID.
VM For a requester, the user is the VM user
ID. For a server, the user is the SQL ID.
280 DataHub Implementation and Connectivity
user authorizations. In DataHub/2, the set of all
authorizations on objects for a user. User
authorizations can be copied from one user to
another. In DataHub/2 user authorizations are
displayed in the client area as authorization
occurrences for objects. Contrast with object
authorizations.
user exit. A point in an IBM-supplied program where
a user-written routine can be given control.
user group. The name of a grouping of related user
IDs. User groups are applicable to OS/400
environments only.
user ID. A string of characters that identifies a user
to a system (RDBMS or host). Most of the RDBMSs
refer to this as the authid. See also authorization ID
V
variable. A part of a DataHub/2 command parameter
that you supply and is shown in lowercase letters in
the syntax diagram.
view. An alternative representation of data from one
or more tables. A view can include all or some of the
columns contained in the tables or the views on which
the table is defined.
view column. A vertical component of a view that
consists of a name and a particular data type. All
values in a particular column share this same data
type.
virtual machine. A functional simulation of a
computer and its associated devices. VM manages
the computer′s resources in such a way that all
workstation users have their own virtual machine. All
users can work at their virtual machines as though
each is the only person using the real computer.
Virtual Telecommunications Access Method. An IBM
licensed program that controls communication and
the flow of data in a computer network. It provides
single-domain, multiple-domain, and multiple network
capability. VTAM runs under MVS, OS/VS1, VM, and
VSE.
VM. See virtual machine.
VTAM. See Virtual Telecommunications Access
Method.
W
where clause. Used for subselecting rows from a
table or view. In IBM DataHub, the where clause
must conform to the syntax of the query language
subselect where clause for the RDBMS being
selected.

wide area network. A network of devices that are
connected to one another for communication over a
larger distance. See also local area network.
wildcard character. A character match string used to
substitute for unknown or unspecified characters or
words. In DataHub/2, the percent symbol (%) is used
as the wildcard character, and a trailing % is allowed
for the qualifier.
window. An area of the screen with visible
boundaries within which information is displayed. A
window can be smaller than, or the same size as, the
screen. Windows can appear to overlap on the
screen. See also DataHub/2 window.
Worksheet File (WSF) file format. An OS/2 file format
used to load and unload data in worksheet formats
supported by LOTUS products (1-2-3 and Symphony).
Database Manager supports a subset of the
worksheet records that is the same for all the LOTUS
products. Each WSF file represents one worksheet.
Glossary 281

282 DataHub Implementation and Connectivity

List of Abbreviations
APPC Advanced
program-to-program
communications
APPN Advanced
program-to-program
networking
API Application programming
interface
AR Application requester
AS/400 Application System/400
AS Application server
BSDS Bootstrap data set
CCSID Coded character set identifier
CD Copy Data
CDB Communication database
CICS Customer Information Control
System
CL Control language
CLI Command-line interface
CM Communications Manager
CM/2 Communications Manager/2
CPI Common Programming
Interface
CUA Common User Access
DASD Direct access storage device
DBA Database administrator
DBCS Double-byte character set
DBMS Database management
system
DB2 DATABASE 2
DB2/2 DATABASE 2/2
DBM IBM Extended Services for
OS/2 Database Manager
DCL Data control language
DDCS/2 Distributed Database
Connection Services/2
DDL Data definition language
DDF Distributed data facility
DH DataHub
DH/2 DataHub/2
DHS DataHub Support
DHS/2 DataHub Support/2
DHS/400 DataHub Support/400
DHS/MVS DataHub Support/MVS
DHS/VM DataHub Support/VM
DML Data manipulation language
DRDA Distributed Relational
Database Architecture
DRDB Distributed relational
database
DS Display status
DUW Distributed unit of work
GUI Graphical user interface
IBM International Business
Machines Corporation
ISQL Interactive Structured Query
Language
ITSC International Technical
Support Center
JCL Job control language
JES Job entry system
LAN Local area network
LAPS LAN adapter and protocol
support
LU Logical unit
LU6.2 Logical unit 6.2
MA Manage authorizations
NAU Network addressable unit
NCP Network Control Program
NETBIOS Network Basic Input/Output
System
OEM Original equipment
manufacturer
OS/2 Operating System/2
OS/2 ES IBM Extended Services for
OS/2
OS/400 Operating System/400
PIU Path information unit
PU Physical unit
PWS Programmable workstation
RACF Resource Access Control
Facility
RDB Relational database
RDBMS Relational database
management system
RDS Remote Data Services
RH Request/response header
© Copyright IBM Corp. 1993 283

RU Request unit
RUW Remote unit of work
SAA Systems Application
Architecture
SAP Service access point
SNA Systems Network
Architecture
SPUFI SQL Processor Using File
Input
SQL Structured Query Language
284 DataHub Implementation and Connectivity
SQL/400 Structured Query
Language/400
SQL/DS Structured Query
Language/Data System
TC Tools conversation
TH Transmission header
UPM User profile management
VM Virtual Machine
VTAM Virtual Telecommunications
Access Method

Index
Numerics
802.2 130
802.2 resources 130
link stations 131
SAP 130
users 130
A
ACF/NCP
See network control program
activating DataHub Support/VM gateways 187
adding a new DRDA host 102
administrator′s folder 148
alert file 181
alias 107
APPC/VM 53
APPC/VTAM 53
application server 109
architecture 3
platform feature 4
tools feature 4
AS/400 network definition 191
AS/400 RDBMS considerations 192
AVS 53
AVS console 53, 177
AVS machine 56
AVS profile 56
AVS profile definition 183
B
bind 32
binding DataHub Support/400 to other hosts 192
C
CDRM
See cross-domain resource manager
CDRSC
See cross-domain resource
CMR 177
codepage support 148
communication directory 58
communication directory definitions 184
communications link 162
component relationship 70, 155, 193
control point name 34, 45, 66, 77
control program 53
Copy Data 12
CP
See control program
cross-domain resource 32, 41
cross-domain resource manager 32, 40
customer business requirements 19
D
data flows 6
DRDA flows 6
RDS flows 7
TC flows 7
database name 54
DataHub
DataHub tools conversation connectivity 151
DataHub/2 workstation 105
DRDA connectivity 31
introduction 1
planning 19
problem determination 203
security 241
DataHub key connectivity parameters
DB2 subsystem name 154
host RDB name 153
mode name 153
OS/2 Database Manager database name 153
partner logical unit name 153
partner transaction program name 153
symbolic destination name 152
DataHub Support/2
configuration file 195
configuring OS/2 for 193
customization 194
OS/2 Communications Manager definitions 196
OS/2 Database Manager definitions 201
OS/2 host components 193
problem determination 239
RDB name map file 113, 195
security 255
DataHub Support/400
configuring AS/400 for 191
AS/400 network definition 191
configuration considerations 192
prestart job 192
problem determination 232
security 254
DataHub Support/MVS
configuring MVS for 167
connectivity requirements 172
environment configuration 168
installation preparation 167
installing the platform and tools feature 168
starting DataHub Support/MVS 171
problem determination 210
security 248
DataHub Support/VM
configuring VM for 175
environment configuration 178
operating system 177
© Copyright IBM Corp. 1993 285

DataHub Support/VM (continued)
configuring VM for (continued)
performance considerations 190
service pool support 175
system operation 187
problem determination 226
security 251
DataHub tools conversation connectivity 151, 173
configuring AS/400 for DataHub Support/400 191
configuring MVS for DataHub Support/MVS 167
configuring OS/2 for DataHub Support/2 193
configuring the DataHub/2 workstation 155
configuring VM for DataHub Support/VM 175
ITSC network example 154
key connectivity parameters 152
recommendations 202
DataHub/2 requester 120
DataHub/2 server 119, 131
DataHub/2 workstation 105, 128, 155
codepage support 148
configuration 106, 155
component relationship 155
DataHub/2 database definitions 156
OS/2 Communications Manager definitions 161
OS/2 Database Manager definitions 166
connect request 108
database definitions 156
database placement 119
DRDA connectivity 69
installation 111, 115, 119, 121
LAN design considerations 144
performance 145
prerequisite products 105
problem determination 204
recommendations 148
scenario 1: local management of local data 110
scenario 2: central management of distributed
data 114
scenario 3: distributed management of distributed
data 117
security 241
tools conversation connectivity 127, 143, 144, 155
DB2 subsystem name 154
DDCS/2
See Distributed Database Connection Services/2
Display Status 11
Distributed Database Connection Services/2 70, 108
domain 32
DRDA components in SQL/DS 52
APPC/VM 53
APPC/VTAM 53
AVS 53
AVS console 53
AVS machine 56
AVS profile 56
communication directory 58
control program 53
database name 54
286 DataHub Implementation and Connectivity
DRDA components in SQL/DS (continued)
group control system 53
machine-id 55
resource-id 54
SQL/DS application requester 53
SQL/DS database machine 54, 55
DRDA connectivity 31, 172
adding a new DRDA host 102
AS/400 definitions 60
ITSC network example 38
key connectivity parameters 33
MVS definitions 40
OS/2 definitions 69
recommendations 104
SNA environment 31
VM definitions 51
DRDA flows 6
DRDA key connectivity parameters
cross-reference 37
DRDA parameters 35
SNA parameters 33
DRDA parameters
partner RDB name 36, 48, 56, 67
RDB name 36, 47, 56, 67, 87
transaction program name 36, 58, 67
transaction program prefix 36
F files
placement 119
relationship with EXECs 180
functions
Copy Data 12
Display Status 11
Manage Authorizations 10
Utilities 8
G
gateway LU 177
GCS
See group control system
group control system 53
H
host RDB name 153
I
IBMLAN.INI 141
IDBLK 34, 63, 77
IDNUM 34, 63, 77
implementation checklist 26
Information Warehouse framework 2
introduction to DataHub 1
architecture 3
data flows 6, 17

ITSC network example 38, 154
K
key connectivity parameters
DataHub 152
DRDA 33
L
LAN adapter and protocol support 69, 109, 127
LAN design considerations 144
LAN server compatibility 144
placement of LAN server 145
LAN requester 128
LAN requester and server reserved resources 132
LAN resource configuration 130
802.2 resources 130
NETBIOS resources 131
LAN server access profile 120
LAN server administration
LAPS
119
See LAN adapter and protocol support
LAPS configuration samples 132
link stations 131
local node characteristics 162
location name 47
logical unit 31
logical unit name
LOGMODE
See logon mode
34, 45, 51, 64, 77
logon mode 32
logon mode table
LU
See logical unit
33
M
machine-id 55
Manage Authorizations 10
managing directories 98
map file 113, 195
MAXDATA/MAXBFRU 34, 42
mode name 35, 46, 66, 85, 153, 166
MODETAB
See logon mode table
N
names 131
NAU
See network addressable unit
NCB
See network control blocks
NETBIOS 130
NETBIOS resources 131
names 131
network control blocks 131
sessions 131
network addressable unit 32
network control blocks 131
network control program 31
network name 34, 45, 66, 77
nodes 32
O
OS/2 Communications Manager 69, 109
definitions 161, 196
OS/2 configuration file 195
OS/2 Database Manager 70, 108, 120
database alias name 153
definitions 166, 201
reserved resources 131
OS/2 host components 69, 193
Distributed Database Connection Services/2 70
LAN adapter and protocol support 69
OS/2 Communications Manager 69
OS/2 Database Manager 70
relationship between OS/2 components 70
P pacing 35, 47, 66, 85
partner logical unit name 35, 46, 65, 81, 153, 162
partner RDB name 36, 48, 56, 67
partner token-ring address 34, 44, 64, 81
partner transaction program name 153
password changes 256
path information unit 33
performance 145, 190
placement 145
workload 146
physical unit 31
PIU
See path information unit
placement 145
planning for DataHub 19
customer business requirements 19
factors affecting implementation 26
implementation checklist 26
recommendations 30
sample scenarios 20
platform feature 4
platform feature function
Run 7
problem determination 203
AS/400 host 232
DataHub/2 workstation 204
implementation strategy 203
MVS host 210
OS/2 host 239
VM host 226
PROTOCOL.INI 127, 139
PU
See physical unit
Index 287

Q QEMQUSER collection 192
R
RDB name 36, 47, 56, 67, 87
RDS 129
RDS flows 7
RDS parameters 36
workstation name 36, 87
recommendations 104, 202
request unit 33
resource-id 54
RU
See request unit
RU size 35, 47, 66, 85
Run 7
S sample scenarios 20
scenario 1: local management of local data 20
scenario 2: central management of distributed
data 22
scenario 3: distributed management of distributed
data 24
SAP
See service access point
scenario 1: local management of local data 110
installation procedure and configuration 111
process flow 111
required products 110
scenario 2: central management of distributed
data 114
installation procedure and configuration 115
process flow 115
required products 114
scenario 3: distributed management of distributed
data 117
DataHub/2 database connectivity parameters 144
DataHub/2 execution: data requirements 118
DataHub/2 workstation installation as a
requester 121
installation environment preparation 119
LAN connectivity parameters 127
OS/2 Database Manager connectivity
parameters 143
required products 118
security 241
AS/400 254
DataHub/2 workstation 241
MVS 248
OS/2 managed host 255
password changes 256
VM 251
service access point 128, 130
service pool 175, 176
configuration file 185
288 DataHub Implementation and Connectivity
service pool (continued)
machine 186
session 32, 131
SNA environment 31
bind 32
cross-domain resource 32
cross-domain resource manager 32
domain 32
logical unit 31
logon mode 32
logon mode table 33
network addressable unit 32
network control program 31
nodes 32
path information unit 33
physical unit 31
request unit 33
session 32
subarea 32
system services control point 31
SNA parameters
control point name 34, 45, 66, 77
cross-domain resource 41
cross-domain resource manager 40
IDBLK 34, 63, 77
IDNUM 34, 63, 77
logical unit name 34, 45, 51, 64, 77
MAXDATA/MAXBFRU 34, 42
mode name 35, 46, 66, 85
network name 34, 45, 66, 77
pacing 35, 47, 66, 85
partner logical unit name 35, 46, 65, 81
partner token-ring address 34, 44, 64, 81
RU size 35, 47, 66, 85
token-ring address 33, 41, 64, 75
SQL/DS application requester 53
SQL/DS database machine 54, 55
SSCP
See system services control point
subarea 32
symbolic destination name 152, 163
system configuration file 185
system database directory 108
system services control point 31
SystemView strategy 1
T
task handler 178
TC flows
See tools conversation flows
testing
DRDA and RDS connections for OS/2 98
DRDA connections for AS/400 68
DRDA connections for MVS 51
DRDA connections for VM 59
token-ring address 33, 41, 64, 75
tool table example 186

tools conversation flows 7
tools conversation key connectivity parameters 152
tools feature 4
TPN
See transaction program name
transaction program name 36, 58, 67, 196
transaction program prefix 36
U
UPM
See user profile management
user profile management 107
users 130
Utilities 8
Backup 9
Load 8
Recover 9
Reorg 9
Unload 8
Update Statistics 10
W workload 146
workstation directory 108
workstation name 36, 87
Index 289

ITSO Redbook Evaluation
International Technical Support Organization
Database Systems Management:
IBM SystemView Information Warehouse
DataHub Implementation and Connectivity
June 1993
Publication No. GG24-4031-00
Your feedback is very important to help us maintain the quality of ITSO redbooks. Please fill out this
questionnaire and return it using one of the following methods:
• Mail it to the address on the back (postage paid in U.S. only)
• Give it to an IBM marketing representative for mailing
• Fax it to: Your International Access Code + 1 914 432 8246
• Send a note to REDBOOK@VNET.IBM.COM
Please rate on a scale of 1 to 5 the subjects below.
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction ____
Organization of the book
Accuracy of the information
Relevance of the information
Completeness of the information
Value of illustrations
____
____
____
____
____
Grammar/punctuation/spelling
Ease of reading and understanding
Ease of finding information
Level of technical detail
Print quality
____
____
____
____
____
Please answer the following questions:
a) Are you an employee of IBM or its subsidiaries: Yes____ No____
b) Do you work in the USA? Yes____ No____
c) Was this redbook published in time for your needs? Yes____ No____
d) Did this redbook meet your needs?
If no, please explain:
Yes____ No____
What other topics would you like to see in this redbook?
What other redbooks would you like to see published?
Comments/Suggestions: ( THANK YOU FOR YOUR FEEDBACK! )
Name Address
Company or Organization
Phone No.

ITSO Redbook Evaluation
GG24-4031-00 IBM ®
Fold and Tape Please do not staple Fold and Tape
BUSINESS REPLY MAIL
FIRST-CLASS MAIL PERMIT NO. 40 ARMONK, NEW YORK
POSTAGE WILL BE PAID BY ADDRESSEE
IBM International Technical Support Organization
Department 471/E2
650 Harry Road
San Jose, CA
USA 95120-6099
NO POSTAGE
NECESSARY
IF MAILED IN THE
UNITED STATES
Fold and Tape Please do not staple Fold and Tape
GG24-4031-00
Cut or Fold
Along Line
Cut or Fold
Along Line

IBM ®
Printed in U.S.A.
GG24-4031-00