Sg244656 VTAM Subarea To APPN

IBML
Subarea to APPN Migration:

VTAM and APPN Implementation
Jerzy Buczak, Michael Li, Anar Kermali, Rabinder Mokha, Ken Oag
International Technical Support Organization
http://www.redbooks.ibm.com
This book was printed at 240 dpi (dots per inch). The final production redbook with the RED cover will
be printed at 1200 dpi and will provide superior graphics resolution. Please see “How to Get ITSO
Redbooks” at the back of this book for ordering instructions.
SG24-4656-01
IBML
SG24-4656-01
International Technical Support Organization
Subarea to APPN Migration:

VTAM and APPN Implementation
May 1998
Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix L, “Special Notices” on page 263.
Second Edition (May 1998)
This edition applies to OS/390 Version 2, Release 5, Program Number 5647-A01.
Comments may be addressed to:

IBM Corporation, International Technical Support Organization
Dept. HZ8 Building 678
P.O. Box 12195
Research Triangle Park, NC 27709-2195
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 1996 1998. 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.
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
The Team That Wrote This Redbook . . . . . . . . . . . . . . . . . . . . . . . . . vii
Comments Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Scope and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 APPN Terminology and Functionality . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Types of SNA Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Types of SNA Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Some Confusing Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Types of Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.5 Network Control Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.6 Dependent LU Support in APPN . . . . . . . . . . . . . . . . . . . . . . 9
1.2.7 HPR Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.8 Types of SNA Data Units . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.9 APPN Directory Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.10 APPN Topology and Class of Service . . . . . . . . . . . . . . . . . . 13
1.2.11 Other APPN Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.12 APPN Session Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 2. Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1 Subarea Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Combined Subarea and APPN Network after Migration . . . . . . . . . . . 21
Chapter 3. Planning for Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Planning Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 VTAM/NCP Software Upgrades . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.2 VTAM/NCP and APPN Node Roles . . . . . . . . . . . . . . . . . . . . . 26
3.1.3 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.4 IBM 3746 Model 900 and Model 950 APPN Migration . . . . . . . . . . 34
3.1.5 Checking Existing Switched LEN Connections . . . . . . . . . . . . . . 34
3.1.6 Dynamically Defining Switched Resources . . . . . . . . . . . . . . . . 35
3.1.7 APPNCOS Start Option and Table . . . . . . . . . . . . . . . . . . . . . 36
3.1.8 Transmission Group Profiles . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.9 ISTINCLM and User-Defined Logmode Table Requirement . . . . . . 38
3.1.10 Multipath Channel Conversion . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.11 Multipath Channel Conversion for APPN . . . . . . . . . . . . . . . . 40
3.1.12 APPN Node Roles and Connectivity . . . . . . . . . . . . . . . . . . . 43
3.1.13 Checking Your NCP Buffer Pools . . . . . . . . . . . . . . . . . . . . . 43
3.1.14 Specifying Adjacent CP Names . . . . . . . . . . . . . . . . . . . . . . 44
3.1.15 Topology Reporting for Switched Connections . . . . . . . . . . . . . 45
3.1.16 Directories and Registration . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.17 Border Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1.18 Connection Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1.19 Specifying Search Order Parameters for Subarea and APPN . . . . 53
3.1.20 Search Reduction Parameters . . . . . . . . . . . . . . . . . . . . . . . 56
3.1.21 Summary of VTAM Start Options . . . . . . . . . . . . . . . . . . . . . 56
3.2 Migration Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapter 4. Migrating a CMC Host to ICN . . . . . . . . . . . . . . . . . . . . . . 61

4.1 VTAM Definitions for ICN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
 Copyright IBM Corp. 1996 1998 iii

4.1.1 APPN-Related Start Options . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.2 APPN Network Topology and Directory Databases . . . . . . . . . . . 64
4.1.3 APPN Class of Service and TG Profiles . . . . . . . . . . . . . . . . . . 64
4.2 Migration Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2.1 Convert Node to ICN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2.2 Convert Links to APPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2.3 3174 as an NN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2.4 CM/2 as an APPN Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Chapter 5. Migrating a Data Host to an MDH or a Pure EN . . . . . . . . . . . 95

5.1 VTAM Start Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.2 Converting Subarea MPC to ANNC . . . . . . . . . . . . . . . . . . . . . . . 96
5.3 Defining a Network Node Server . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.3.1 Resource Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.4 Check the Subarea Environment . . . . . . . . . . . . . . . . . . . . . . . . 100
5.5 Testing the MDH Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.5.1 Start RAS as an MDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.5.2 Check CP-CP and SSCP-SSCP Sessions . . . . . . . . . . . . . . . . 102
5.5.3 Check the Subarea Routes . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5.4 Check Network Node Server List . . . . . . . . . . . . . . . . . . . . . 104
5.5.5 Testing LU Session Establishment . . . . . . . . . . . . . . . . . . . . 105
5.6 Changing the Data Host from MDH to EN . . . . . . . . . . . . . . . . . . 108
5.6.1 Convert NCP Channel Connection to FID2 . . . . . . . . . . . . . . . 109
5.6.2 Testing the End Node Configuration . . . . . . . . . . . . . . . . . . . 110
5.6.3 Testing LU Session Establishment . . . . . . . . . . . . . . . . . . . . 112
5.7 Benefits of Converting Subarea Data Host to an EN . . . . . . . . . . . . 112
5.8 Hints on Potential Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Chapter 6. Border Node Support . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.1 Border Node Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.1.1 Definitions for Border Node Function . . . . . . . . . . . . . . . . . . 118
6.2 Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.2.1 Search for Nonexistent Resource . . . . . . . . . . . . . . . . . . . . 126
6.2.2 Search for Real Resource . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.3 Benefits and Issues on Border Node . . . . . . . . . . . . . . . . . . . . . 128
6.4 Recommendations on APPN Borders . . . . . . . . . . . . . . . . . . . . . 129
Chapter 7. VR-Based TG Implementation . . . . . . . . . . . . . . . . . . . . . 131

7.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.1.1 VTAM Definitions for VR-Based TG . . . . . . . . . . . . . . . . . . . 133
7.2 Testing VR-TG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.3 Hints on VR-TG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Chapter 8. SSCP Takeover in a Combined Subarea and APPN Network . . . 141

8.1 Example of APPN SSCP Takeover . . . . . . . . . . . . . . . . . . . . . . . 143
Chapter 9. Searching and Routing in a Mixed Subarea/APPN Network . . . 151

9.1 Searching in a Subarea Network . . . . . . . . . . . . . . . . . . . . . . . 151
9.1.1 LEN and APPN Resources in a Subarea Network . . . . . . . . . . . 153
9.2 Searching in an APPN Network . . . . . . . . . . . . . . . . . . . . . . . . 154
9.3 How VTAM Combines the Search Algorithms . . . . . . . . . . . . . . . . 155
9.3.1 Search Originating from Subarea Network or Local LU . . . . . . . 156
9.3.2 Search Originating from APPN Network . . . . . . . . . . . . . . . . . 158
9.3.3 Some Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . 160
9.4 Composite Network Node Routing . . . . . . . . . . . . . . . . . . . . . . . 161
iv Subarea to APPN Migration: VTAM and APPN Implementation

9.4.1 Example of CNN Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Chapter 10. Logmode and COS Resolution in a Mixed Network . . . . . . . 167

10.1 Subarea COS Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
10.2 APPN COS Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
10.3 COS Resolution in a Combined Network . . . . . . . . . . . . . . . . . . 171
10.3.1 VTAM′s Methods of COS Resolution . . . . . . . . . . . . . . . . . . 171
10.3.2 An Example of a Mixed Network . . . . . . . . . . . . . . . . . . . . 173
10.4 Issues and Possible Solutions . . . . . . . . . . . . . . . . . . . . . . . . 178
Chapter 11. Sysplex Considerations . . . . . . . . . . . . . . . . . . . . . . . . 181

11.1 All Nodes Subarea Capable . . . . . . . . . . . . . . . . . . . . . . . . . . 181
11.2 APPN Within Sysplex Only . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
11.3 APPN Everywhere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
11.4 APPN and Subarea Everywhere . . . . . . . . . . . . . . . . . . . . . . . 186
Chapter 12. Management of a Combined Network . . . . . . . . . . . . . . . . 189

12.1 Principles of Network Management in APPN . . . . . . . . . . . . . . . . 189
12.2 Familiar Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
12.2.1 Status and Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
12.2.2 Problem Investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
12.2.3 Remote Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
12.2.4 Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 193
12.2.5 Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
12.3 New Functions Available in APPN . . . . . . . . . . . . . . . . . . . . . . 193
Appendix A. VTAM Node Types . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Appendix B. VTAM APPN and APPN-Related Start Options . . . . . . . . . . 197
Appendix C. VTAM APPN Commands . . . . . . . . . . . . . . . . . . . . . . . 203

C.1 APPN Operands for VTAM Modify Commands . . . . . . . . . . . . . . . 203
C.2 APPN Operands for VTAM Vary Commands . . . . . . . . . . . . . . . . 204
C.3 APPN Operands for VTAM Display Commands . . . . . . . . . . . . . . . 205
Appendix D. VTAM Subarea Initial Definitions . . . . . . . . . . . . . . . . . . 207

D.1 VTAM RAA Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
D.1.1 VTAM Start Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
D.1.2 VTAM Configuration List . . . . . . . . . . . . . . . . . . . . . . . . . . 208
D.1.3 Path Tables for RAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
D.1.4 Adjacent SSCP Table, CDRM and CDRSC Major Nodes . . . . . . . 210
D.1.5 Locally Attached 3174 Definitions . . . . . . . . . . . . . . . . . . . . 211
D.1.6 CTC and MPC Definitions from RAA to RAS . . . . . . . . . . . . . . 211
D.1.7 Switched Major Node Definitions . . . . . . . . . . . . . . . . . . . . 212
D.1.8 NCP RA5NCPX Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 215
D.1.9 NCP RA8NCPX Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 224
D.2 VTAM RAS Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
D.2.1 VTAM Start Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
D.2.2 VTAM Configuration List . . . . . . . . . . . . . . . . . . . . . . . . . . 233
D.2.3 Multipath Channel Connection to RAA . . . . . . . . . . . . . . . . . 234
D.2.4 Local Non-SNA Definitions . . . . . . . . . . . . . . . . . . . . . . . . 234
D.2.5 Channel Connection to NCP Subarea 8 . . . . . . . . . . . . . . . . . 235
D.2.6 Adjacent SSCP Table and CDRM Major Node . . . . . . . . . . . . . 235
D.2.7 Path Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Contents v
Appendix E. VTAM APPN Migration Definitions . . . . . . . . . . . . . . . . . 237
E.1.1 Transmission Group Profile Default Table IBMTGPS . . . . . . . . . 237
E.1.2 APPN Entries in ISTINCLM IBM Default Logmode Table . . . . . . . 239
E.1.3 RAAMDLS Customized MODEL Major Node . . . . . . . . . . . . . . 241
Appendix F. VTAM Definitions with RAA as ICN . . . . . . . . . . . . . . . . . 243

F.1 VTAM RAA Definitions Updated for ICN . . . . . . . . . . . . . . . . . . . 244
Appendix G. VTAM Definitions with RAA as ICN and RAS as MDH . . . . . 245
G.1 VTAM RAA Definitions Updated for MDH . . . . . . . . . . . . . . . . . . 246
G.1.1 Configuration List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
G.1.2 CDRM Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
G.1.3 ANNC Definitions from RAA to RAS . . . . . . . . . . . . . . . . . . . 247
G.2 VTAM RAS Definitions Updated for MDH . . . . . . . . . . . . . . . . . . 248
G.2.1 Start Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
G.2.2 Configuration List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
G.2.3 CDRM Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
G.2.4 ANNC Definitions from RAS to RAA . . . . . . . . . . . . . . . . . . . 250
Appendix H. VTAM Definitions with RAA as ICN and RAS as EN . . . . . . . 251

H.1 VTAM RAA Definitions Updated for Pure EN . . . . . . . . . . . . . . . . 252
H.2 VTAM RAS Definitions Updated for Pure EN . . . . . . . . . . . . . . . . 253
H.2.1 RAS Start Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
H.2.2 Configuration List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
H.2.3 RAS to NCP Channel Connection . . . . . . . . . . . . . . . . . . . . 254
Appendix I. Additional Definitions for SSCP Takeover . . . . . . . . . . . . . 255

I.1.1 RAS Defined for SSCP Takeover . . . . . . . . . . . . . . . . . . . . . 255
I.1.2 Channel-Attached Major Node RASCA8 . . . . . . . . . . . . . . . . . 256
I.1.3 Adjacent CP Table on RAA . . . . . . . . . . . . . . . . . . . . . . . . . 256
Appendix J. Configuration Services Exit . . . . . . . . . . . . . . . . . . . . . 257

J.1 Default ISTEXCCS Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . 257
J.2 Alternate ISTEXCCS Invocations . . . . . . . . . . . . . . . . . . . . . . . . 258
J.3 Sample Model Major Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Appendix K. New Function Added by APARs . . . . . . . . . . . . . . . . . . 261
Appendix L. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Appendix M. Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . 265

M.1 International Technical Support Organization Publications . . . . . . . 265
M.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
M.3 Other Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
How to Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

How IBM Employees Can Get ITSO Redbooks . . . . . . . . . . . . . . . . . . 267
How Customers Can Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . 268
IBM Redbook Order Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
ITSO Redbook Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
vi Subarea to APPN Migration: VTAM and APPN Implementation

Preface
This redbook is the first of two volumes containing detailed coverage of the
migration of a subarea network to an APPN network. It focuses on the migration
steps and requirements that can be used as guidelines to accomplish the
migration in a simple and constructive manner. The first volume covers the
implementation of the basic VTAM APPN functions including border node, VR-TG
and network management. The second volume (SG24-5204) completes the
coverage of a typical customer′s network using HPR, DLUR and APPN/HPR
routers such as 3746, 2216 and 2210. In each case tested examples and
definitions illustrate the theory.
The first eight chapters in this volume are based on the first edition of this book
(SG24-4656-00). They have been rewritten to improve the explanations and
clarify the examples. They have also been updated with information on the
latest release of eNetwork Communications Server for OS/390.
Some knowledge of SNA subarea networks and familiarity with the functions,
terms and data flows of APPN networks is assumed.
The Team That Wrote This Redbook

This redbook was updated by:
Jerzy Buczak
Systems Management and Networking ITSO Center, Raleigh
Chapter 9, Chapter 10, and Chapter 11 are based on presentations developed

by:
Johnathan Harter
CS OS/390 Development, Research Triangle Park
Chapter 12 is based on a presentation created by:
John Parker
IBM United Kingdom, Manchester
The original version of this book was the result of a project designed and
managed by:
Michael Li
The authors of the first edition of the redbook were:
Anar Kermali
IBM Canada
Rabinder Mokha
IBM Australia
Ken Oag
National Australia Bank, Australia
 Copyright IBM Corp. 1996 1998 vii

This publication is the result of a residency conducted at the Systems
Management and Networking ITSO Center, Raleigh.
Thanks to the following people for the invaluable advice and guidance provided
in the production of both editions of this document:
Pepe Boo
IBM Spain, Madrid
Roy Brabson
Fran Collins
Networking Software Sales and Opportunity Solutions, Dallas
Gwendolyn Dente
Washington System Center, Gaithersburg
Jim Fletcher
CS OS/390 Design, Research Triangle Park
Nancy Gates
Washington System Center, Gaithersburg
Johnathan Harter
John Klonowski
John Parker
IBM United Kingdom, Manchester
Sam Reynolds
Juan Rodriguez
Carla Sadtler
Suvas Shah
Communications Manager and Communications Server Architecture,
Research Triangle Park
Ann Wright
Comments Welcome
Your comments are important to us!
We want our redbooks to be as helpful as possible. Please send us your

comments about this or other redbooks in one of the following ways:
viii Subarea to APPN Migration: VTAM and APPN Implementation

• Fax the evaluation form found in “ITSO Redbook Evaluation” on page 275 to
the fax number shown on the form.
• Use the electronic evaluation form found on the Redbooks Web sites:
For Internet users http://www.redbooks.ibm.com/
For IBM Intranet users http://w3.itso.ibm.com/
• Send us a note at the following address:
redbook@us.ibm.com
Preface ix
x Subarea to APPN Migration: VTAM and APPN Implementation
Chapter 1. Introduction
The history of APPN within VTAM is relatively new. In 1993, IBM introduced
APPN into the mainframe environment with VTAM V4R1 and NCP V6R2. There
were many restrictions, which meant that some customers did not feel the need
to migrate to or implement VTAM V4R1. They could not see any real benefits.
For example, channel-to-channel connections were not supported. Dependent
LUs had to be adjacent to the subarea network. SNI connections had to be used
at all network boundaries. Route calculation was haphazard between the APPN
network and the subarea network.
VTAM V4R2 addressed most of these issues in terms of APPN. Border node
functions, connection networks, APPN host-to-host connection, VR-TG, and
Dependent LU Requester/Server functions were all introduced with this release.
The latest generally available release at the time of writing is VTAM V4R4.1,
which is actually part of eNetwork Communications Server for OS/390 Release 5
and not available separately. CS OS/390 Release 5 provides full support for
high-performance routing (HPR), which was introduced for some configurations
by V4R3 and developed fully by V4R4. HPR utilizes a rapid transport protocol
(RTP) connection to transport session traffic between session endpoints. HPR
routes can traverse existing subarea routes using VR-based TGs between
intermediate nodes.
HPR improves reliability by switching sessions to alternate paths, if they are

available, bypassing link and/or node failures. Sessions are not disrupted. HPR
also tolerates “hits”, maintaining sessions while corrective action is taken to
restore a failed link or node on the session path. HPR also reduces storage and
processing requirements in intermediate nodes along the session path, because
those nodes have no session awareness.
There are many different products and platforms which support APPN and can
therefore be integrated into an APPN network. These include platforms made by
many companies other than IBM. The list includes offerings from companies
such as Apple Computers, Brixton Systems, Cabletron Systems, Cisco Systems,
Bay, 3Com, Nortel, Unisys and many others. The list of non-IBM suppliers for
LEN platforms, which can participate in APPN networks, is even longer. The
user should determine the level of support offered by these vendors.
1.1 Scope and Objectives

Many readers will be familiar with the concepts of APPN. Some readers may not
be familiar with the newer functions, such as HPR. The objective of this redbook
is not to teach these functions and concepts, although the most important
functions and terms will be explained. We refer the customer to the relevant
manuals which have been used in the construction of this publication. A list of
related publications can be found in Appendix M, “Related Publications” on
page 265.
The main objective of this book is to outline the most important steps required to
migrate an existing subarea network to a mixed subarea and APPN network. It
is envisaged that mixed subarea/APPN/HPR environments will exist for some
years to come. These three SNA protocols can coexist and be intermixed quite
 Copyright IBM Corp. 1996 1998 1

successfully, allowing customers to make use of different aspects of each
protocol where it is useful in their network.
Some connections in a subarea network may never become APPN-capable;

SNI-connected networks belonging to different organizations may not be
APPN-capable at the same time, requiring these links to remain defined in the
subarea network. Customers will, however, be able to take advantage of many
of the features available from APPN and HPR.
The objective of this book, therefore, is to define a subarea network and migrate
it using a number of easy-to-follow steps to a mixed subarea and APPN network.
These steps will help readers to migrate their own networks in a simple and
constructive way. Although the network which we are working with will not
match every reader′s network, whether due to size or actual devices used, we
simulate as many scenarios as possible. The migration will include the use of
APPN functions such as border node capability, VR-TG, ANNC, and SSCP
Takeover/Giveback. A companion book (SG24-5204) will cover extensions to the
base VTAM APPN network including HPR, DLUR/S and APPN routers such as
3746, 2216 and 2210.
Note
This pair of redbooks covers migration from subarea to APPN, and then to
HPR, in two separate volumes. We must emphasize that this is purely to
help the reader understand APPN and HPR, and is not intended as a
recommendation to perform the migration in two phases. The difference
between APPN and HPR is small compared to the difference between
subarea and APPN. You may find it advantageous to let VTAM′s defaults
take you all the way to HPR as you implement APPN.
1.2 APPN Terminology and Functionality

For a comprehensive description of APPN and its terminology, we recommend
Inside APPN - the Essential Guide to the Next-Generation SNA , SG24-3669-03. In
this section we explain some of the terms and expressions which we consider
especially relevant to the VTAM migration project.
1.2.1 Types of SNA Network

An SNA network can actually comprise elements that conform to any of three
distinct architectures, if you count HPR as being just a variation of APPN:
• APPN, the subject of this redbook
• Subarea, which has its origins in the 1970s when processing power was
expensive and network control functions had to be centralized
• Low entry networking, which is a predecessor of APPN but, because of its
simplicity, was easily integrated with subarea networking before VTAM
supported APPN
2 Subarea to APPN Migration: VTAM and APPN Implementation

1.2.1.1 Subarea Networking
A subarea network comprises a group or groups of connected subarea nodes,
with lower-function type 1, type 2 or type 2.1 nodes connected to the periphery.
A subarea node is an ACF/VTAM or ACF/NCP node acting as a traditional SNA

type 5 or type 4 node, respectively. Type 4 subarea nodes provide the SNA
functions that route and control the flow of data in a subarea network. Type 5
subarea nodes (system services control points, or SSCPs) provide these same
functions as well as the SNA functions that control network resources, support
transaction programs, support network operators, and provide end-user services.
A subarea node can only support APPN connections as LEN connections. LEN
support is the same as provided in V3R2 to V3R4.2 of VTAM.
Subarea networking uses an addressing scheme that consists of a subarea

number, representing the subarea a resource belongs to, and an element
address, which uniquely identifies that resource within the subarea. On a
connection between subarea (type 4 and/or type 5) nodes, the origin and
destination of a PIU are identified by these subarea and element addresses.
A subarea network may be divided into independent subnetworks which are

identified by unique NetIDs. Such subnetworks have their topologies and
addressing schemes isolated from one another. This results in simplified
definitions and greater flexibility, but at the cost of less than optimal session
routing.
Each resource in a subarea network is uniquely identified by its NetID and its
resource name.
1.2.1.2 APPN Networking

An Advanced Peer-to-Peer Networking (APPN) network comprises a group or
groups of connected type 2.1 nodes. APPN allows direct communications
between any network-attached devices without the need for specific platforms or
SSCP intervention. APPN builds upon the low-entry networking (LEN)
architecture and advanced program-to-program communication (APPC) to
provide the dynamics and ease-of-use required in today′s distributed networks.
Some of the benefits of APPN include:

• If a resource wants a session with any other resource in the network, APPN
network nodes locate the destination resource. The originator does not need
to know anything about the location of the other resource. The location of
the destination resource does not need to be defined to the originator.
• When a session is requested, the APPN network nodes determine the best
route for the session at the time of the session request. No routes need to
be predefined.
• Independent LUs on APPN nodes may establish sessions with each other
without the use of an SSCP.
• Network definition is minimized; only local resources need to be defined.
APPN nodes use local-form session identifiers (LFSIDs) instead of subarea

addresses for communicating with each other in an APPN network. The LFSID
identifies a session uniquely, but is valid only on a node′s local link. When a PIU
passes from one link to another, the routing node translates the LFSID from the
inbound link to the LFSID on the outbound link.
Chapter 1. Introduction 3
An APPN network may be divided into subnetworks, although the APPN scheme
is more flexible than the subarea scheme. APPN resources are also identified
uniquely by their NetID and resource name.
1.2.1.3 Low Entry Networking

A low entry networking (LEN) node is a type 2.1 node that can function in both a
subarea and an APPN environment. A LEN node provides peer-to-peer
connectivity to subarea nodes, APPN nodes and other LEN nodes. Unlike
subarea or APPN nodes, a LEN node cannot establish network control sessions
with any other node. Therefore, a LEN node cannot register its resources with
any server; nor can it take part in a search for an unknown target resource.
LEN nodes can directly communicate with other LEN nodes without requiring the
services of an SSCP. An SSCP is required if LEN nodes are to communicate
with each other across a subarea network, but the communication with the SSCP
is done by the subarea boundary function and is transparent to the LEN nodes.
The great disadvantage of LEN connections, apparent in both subarea and APPN
networks, is that no network control functions (such as searching) can take place
over them. As a result, much more predefinition is required than for the
equivalent APPN or subarea connection.
1.2.1.4 High-Performance Routing

High-performance routing is an extension of APPN that takes advantage of fast
links with low error rates. HPR replaces base APPN′s intermediate session
routing (ISR) with automatic network routing (ANR) and provides the following
benefits:
• The ability to reroute sessions nondisruptively around failed nodes and links
• The ability to tolerate “network hits”, in other words short-term connection
failures
• Improved intermediate routing performance
• Adaptive rate-based (ARB) congestion control to assure maximum link
utilization while avoiding network congestion
HPR provides interoperation with existing APPN nodes by sharing existing APPN
topology, control point protocols and algorithms. HPR has two major
components, rapid transport protocol (RTP) and automatic network routing
(ANR). The endpoints of an HPR connection (which may be network nodes or
end nodes) implement RTP, whereas the intermediate nodes implement ANR.
LU-LU sessions can use HPR for part of the session path, without requiring
end-to-end HPR.
When HPR is in use, LFSIDs are not used for the HPR portion of the sessions.
Instead, ANR labels are used by each node to route HPR network layer packets
(NLPs).
1.2.2 Types of SNA Node

With the addition of APPN to VTAM′s subarea capability, there are many more
roles and combinations of roles that a node in a network can play.

1.2.2.1 Communications Management Configuration
A communications management configuration (CMC) is a subarea VTAM that
owns NCPs and has session establishment and error recovery responsibility for
one or more data hosts. A CMC, when migrating to APPN, should be converted
into an interchange node (ICN).
1.2.2.2 Data Host

A data host is a subarea VTAM that owns application LUs, but has no
responsibility for LUs in the network. A data host does not own or activate any
NCPs. It may own local LUs. A data host, when migrating to APPN, can be
converted into a migration data host (MDH) or a pure APPN EN.
1.2.2.3 Network Node

A network node (NN) is an APPN node that supports its own end users and the
end nodes it serves by providing directory and route selection services. It
performs intermediate routing of data for sessions that cross it. To perform
these network services, network nodes maintain a topology database and a
directory services database. This capability of network nodes to identify and
remember the locations of resources and links significantly reduces the amount
of system definition required.
A network node supports CP-CP sessions, but need not support either
SSCP-SSCP sessions or subarea connections. VTAM, when defined as a “pure”
network node, is not able to own or activate NCPs and has no subarea number
defined. When VTAM is defined as both a subarea node and an APPN network
node, it can own and activate NCPs. Such a VTAM, in conjunction with one or
more NCPs, is known as a composite network node (CNN) and appears as a
single APPN node.
1.2.2.4 End Node

An end node (EN) is an APPN node that has no network topology or directory
capability; the EN only provides these services for its own local APPN resources.
An end node does not perform intermediate routing of sessions; it can only be
the origin or destination of a session. The EN relies on an adjacent network
node to act as its network node server providing any needed network services.
The EN may have active connections to multiple adjacent network nodes;

however, only one of these network nodes at a time can act as its network node
server. The EN selects its network node server by establishing CP-CP sessions
with an adjacent APPN network node. The EN can register its resources with the
network node server so that the network node knows what resources are
available in its domain. Without a network node server, an APPN end node can
function as a LEN node, and establish LU-LU sessions with a partner LU in an
adjacent APPN or LEN node, provided that the location of the partner LU has
been predefined. An EN can attach to any LEN or APPN node regardless of its
network ID. An EN can also have direct connections (but not CP-CP sessions) to
any number of other ENs.
1.2.2.5 Migration Data Host

A migration data host is a VTAM node which acts as both an APPN EN and a
type 5 subarea node. An MDH is dedicated to processing application programs
and does not control network resources, except for local resources, just like a
data host in a subarea network. The MDH is defined with a subarea number and
supports FID4 (subarea) connections to other subarea VTAMs. It can be
connected to other APPN nodes, LEN nodes, and subarea nodes. An MDH
cannot perform intermediate routing, except wholly within a subarea network,
although its locally attached LEN nodes and dependent LUs can establish
sessions with resources in other APPN or subarea domains.
1.2.2.6 Interchange Node

An interchange node (ICN) is a VTAM network node that supports both APPN
and subarea connections and provides the capability for communication between
them. The ICN supports SSCP-SSCP sessions with other VTAM nodes as well as
CP-CP sessions with adjacent APPN network nodes and end nodes. The ICN
translates APPN session setup flows to the subarea network and subarea
session setup flows to the APPN network. An ICN can own and activate NCPs
yet continue to participate in the APPN network. It works with the NCP to allow
the NCP to perform HPR automatic network routing.
1.2.2.7 Composite Network Node

A composite network node (CNN) is the combination of one VTAM and one or
more NCPs that it owns. A composite network node appears to an APPN
network as a network node and can function as an interchange node. The CNN
can be attached to other APPN nodes and also to other subarea nodes.
1.2.2.8 Border Node

A border node is an APPN network node enhancement that enables connectivity
between APPN network nodes with different network identifiers (NetIDs). APPN
topology information does not cross the border node connection (APPN
subnetwork boundary). An APPN subnetwork boundary is assumed by VTAM
when a border node-capable VTAM is connected to a network node with a
different network identifier. An APPN subnetwork boundary can also be defined
explicitly. APPN borders can be defined between subnetworks with the same
NetID, and they can also be used to connect disjoint networks with the same
NetID via an intermediate network.
An APPN subnetwork boundary is always between two network nodes. An end

node is considered to be in the same subnetwork as its network node server,
regardless of NetID.
Two types of border node are defined in the APPN architecture: peripheral
border node and extended border node.
1.2.2.9 Peripheral Border Node

A peripheral border node (PBN) manages an APPN subnetwork boundary by
pretending to be an end node to one network and a network node to the other
network. A session traversing a border managed by a PBN cannot cross any
other network borders; in other words, such a border allows only a single
cross-network hop. There are other restrictions regarding sessions crossing
such a border, which are detailed in Chapter 6, “Border Node Support” on
page 115.
1.2.2.10 Extended Border Node

The extended border node (EBN) can manage an APPN subnetwork boundary in
the same way as a PBN, but with some of the PBN restrictions still in effect
(please refer to Chapter 6, “Border Node Support” on page 115 for details). The
EBN, however, is designed to work in pairs, with two connected EBNs managing
the border between them. This configuration allows full APPN and HPR functions

across the border, and all the PBN restrictions are removed. In particular, a
session can traverse multiple subnetwork boundaries if those boundaries are
managed by pairs of EBNs.
1.2.2.11 Branch Extender Node

A branch extender node (BXN) is an extension of the PBN architecture designed
for small remote locations where an EBN would be too large, complex and
expensive. In a similar fashion to a PBN, a BXN pretends to be an end node to
the backbone network and a network node to its local resources. However,
unlike a PBN:
• A BXN permits central resource registration requests to cross its border.
• A BXN allows other BXNs downstream (on the local side), thus sessions can
cross multiple BXN borders.
• A BXN can act as a DLUR to its downstream resources, when the DLUS is
upstream.
1.2.3 Some Confusing Terminology

Much of the terminology used in APPN, subarea and LEN networking is the
same, but some terms can mean different things in different architectures.
1.2.3.1 Domain
The concept of a domain is different in subarea and APPN networks. In a
subarea network, it means a VTAM and all the resources it owns (with which it
has SSCP-PU or SSCP-LU sessions). In an APPN network, it means a network
node and all the resources it serves; this therefore includes resources on end
nodes served by the network node.
1.2.3.2 Transmission Group

In a subarea network, a transmission group (TG) is a link between subarea (type
4 or 5) nodes. Connections to peripheral (type 2 or 2.1) nodes are not regarded
as TGs. Subarea networking supports both parallel TGs (between any two
subarea nodes) and multilink TGs (implemented only between NCPs). Parallel
TGs are independent connections between the same two nodes, with distinct TG
numbers, that can be selected individually for a session path. Multilink TGs
comprise multiple physical connections but have a single TG number and are
treated as a single connection for route selection purposes.
In APPN, every connection between two nodes is known as a TG, and is

represented in the (local or network) topology database. Indeed, every TG is in
the TDB twice, once in each direction. Thus the criteria for choosing a TG for a
session path can differ in each direction. Base APPN supports parallel TGs, but
the use of multilink TGs requires an RTP connection between the TG partners.
1.2.4 Types of Connection
1.2.4.1 Boundary Function TG

In subarea networking, the boundary function is that component which translates
the backbone protocols to the peripheral protocols used to communicate with
type 2 or type 2.1 nodes. A connection between the subarea backbone and an
APPN node appears as peripheral to the subarea network, and therefore
requires the use of a boundary function. At the same time this connection is an
APPN TG. Therefore this type of connection is referred to as a boundary
function transmission group (BF-TG).
1.2.4.2 Virtual Route-Based Transmission Group
A virtual route-based transmission group is a VTAM-specific routing function that
enables two APPN-capable VTAM nodes to define an APPN connection between
them across a subarea route . Such an APPN connection is reported to the APPN
topology database in the usual ways, but has a unique TG number of 255.
A VR-TG connection can support CP-CP sessions as well as SSCP-SSCP

sessions. The two VTAM nodes connected by a VR-TG must be either ICNs or
MDHs, since they require both subarea and APPN capability.
One advantage of VR-TG is that it provides full APPN function across an existing
subarea network, thus alleviating the need to redefine connections when a
speedy migration is desired. A VR-TG allows APPN LU-LU sessions to be set up
using subarea virtual routes across the subarea portion of an SNA network.
Please refer to Chapter 7, “VR-Based TG Implementation” on page 131 for a full
description.
1.2.4.3 Interchange Transmission Group

When a subarea network adjoins an APPN network and VR-TG is not used,
resources in the subarea network are represented to APPN as being on an end
node served by the interchange node that handles the subarea/APPN boundary.
Thus LUs in the APPN network are able to find, and to establish sessions with,
LUs in the subarea network. The CP name given to the “virtual” end node is
that of its actual SSCP owner; the “virtual” TG that connects the ICN to the EN is
given a TG number of 254 and is referred to as an interchange transmission
group (IC-TG).
1.2.5 Network Control Sessions
1.2.5.1 SSCP-SSCP Sessions

The SSCP-SSCP session is a network control session in a subarea network that
allows two type 5 nodes to communicate, for the purpose of enabling end-user
sessions between logical units owned by those nodes. SSCP-SSCP sessions can
only be established between two hosts with subarea function.
Within a subnetwork, in order to establish an LU-LU session the SSCPs that own
the LUs must be in session with each other. If the LUs are in different
subnetworks the SSCPs that own them must be able to communicate with each
other using a chain of SSCP-SSCP sessions. The links in the chain are the
gateway SSCPs that control the subnetwork boundaries.
For dependent LUs, the SSCPs must also establish SSCP-PU and SSCP-LU
sessions before an LU-LU session can be set up. Independent LUs are those
which do not require SSCP-LU sessions. This leads to the major difference
between a type 2 and a type 2.1 node; the latter can support independent LUs as
well as dependent while the former can only handle dependent LUs.
1.2.5.2 Control Points and CP-CP Sessions

The control point (CP) is the function in an APPN end node or network node that
corresponds to the SSCP in a subarea network. The CP is responsible for
providing network services to the LUs on its node, although if it is an EN CP it
will route most such requests to its network node server. APPN nodes
communicate network control information by means of CP-CP sessions rather
than SSCP-SSCP sessions.

CP-CP sessions are sets of two parallel half-duplex network control sessions
between adjacent nodes in an APPN network, and are used to exchange network
information. Each pair of sessions comprises an LU 6.2 contention-winner
session and an LU 6.2 contention-loser session (seen from either partner′s point
of view) that together provide CP-CP connectivity. Both the sessions must be
active in order for the partner CPs to begin or continue their interactions. Once
the CP-CP sessions are established, the capabilities of the control points are
exchanged. APPN requests are sent on the contention-winner (CONWINNER)
session and replies to the requests are received on the contention-loser
(CONLOSER) session.
You are not required to have CP-CP sessions between each and every node in
the network. Direct CP-CP sessions are not required between the endpoints of
an LU-LU session. A network node can have CP-CP sessions with any other
network node to which it has an APPN connection. It also maintains CP-CP
sessions with each of the end nodes it serves. End nodes can be attached to
several network nodes but can only establish CP-CP sessions with one network
node server at a time. CP-CP sessions between end nodes and their network
node servers are used for resource registration and locating destination LUs
when the end node wishes to set up a session. CP-CP sessions between
network nodes are used to register resources with a central directory server,
perform searches for resources, and exchange topology information. Direct
CP-CP sessions between end nodes are never permitted.
A LEN node does not support CP-CP sessions. Therefore, its independent LUs
cannot request an APPN network search, nor can they be found dynamically.
Similarly, because those independent LUs have no SSCP-LU sessions they suffer
the same restrictions in a subarea network. Some predefinition is always
required if an LU on a LEN node is to establish a session.
1.2.6 Dependent LU Support in APPN

An APPN network can carry dependent LU sessions as long as the rules of
subarea networking are not broken. A node containing dependent LUs must be
directly connected to a subarea node, and its sessions must always pass
through that subarea node before being routed through the backbone. If these
conditions are met such sessions can traverse APPN FID2 and HPR connections
as well as FID4 and peripheral subarea connections.
However, to provide the full flexibility of APPN to dependent LU sessions, the

Dependent LU Requester/Server function is needed. This removes the rule
about direct connection to a subarea node and allows an APPN/HPR path all the
way to the node containing the dependent LUs.
1.2.6.1 Dependent LU Server

A dependent LU server (DLUS) is a network node which provides support to
dependent LUs located in remote APPN end nodes or network nodes with DLUR
function. The DLUS function is only provided by a VTAM network node or
interchange node. By implementing this function, VTAM is able to provide SSCP
services through normal SSCP-PU and SSCP-LU session flows that are
encapsulated and sent over LU 6.2 sessions between the DLUS and the DLUR.
The dependent LU can be located anywhere within the network or
interconnected networks, as long as it has a dependent LU requester node
available to it. A DLUS can serve multiple DLURs.
1.2.6.2 Dependent LU Requester
The dependent LU requester function allows an end node or network node to
provide a remote boundary function for dependent LUs. This function relieves
the restriction that dependent LUs and their type 2.0 PUs be directly attached to
the VTAM or NCP boundary function. The DLUR function may reside in the same
node as the dependent LU or be provided by a node adjacent to and upstream
from the dependent LU.
The major advantage of using DLUR and DLUS is that dependent LU sessions
can fully utilize the APPN network. They do not need to flow via a subarea node
adjacent to the dependent LU; they can take the optimum path through the
network as calculated by an APPN network node. They can also take advantage
of HPR.
1.2.7 HPR Functions
1.2.7.1 Rapid Transport Protocol (RTP)

Rapid transport protocol is a connection-oriented, full-duplex transport protocol
used in HPR for transporting data across HPR subnets. All data flowing over an
RTP connection is carried in network layer packets (NLPs). RTP provides
end-to-end recovery with selective retransmission, non-disruptive path switch,
and adaptive rate-based (ARB) flow and congestion control procedures. RTP
provides translation between base APPN (ISR) and HPR protocols for sessions
that have both HPR and non-HPR portions. RTP can be implemented on both
end nodes and network nodes.
Any APPN configuration of VTAM V4R4 or above can support RTP, whether
across native APPN connections or VR-TG connections. NCP cannot support
RTP, and the HPR portion of a session cannot terminate in an NCP.
1.2.7.2 Automatic Network Routing (ANR)

Automatic network routing is a low-level routing mechanism that minimizes cycle
and storage requirements for routing packets through intermediate nodes. ANR
routing is significantly faster than base APPN routing. Unlike base APPN,
intermediate ANR nodes are not aware of SNA sessions or RTP connections
passing through the node. ANR can be implemented on network nodes only.
NCP V7R3 or above as part of a composite network node provides ANR

capability, whether across VR-TG or native APPN connections. VTAM V4R4 or
above can perform ANR in any APPN-capable configuration.
1.2.7.3 Nondisruptive Path Switch

When a link or node outage occurs in the path of the RTP connection, the RTP
endpoint attempts to find an alternate route to maintain the connection. If an
alternate route which satisfies the class of service for the failed RTP connection
is available, a new RTP connection is activated over the alternate route. SNA
sessions using this RTP connection are not interrupted and session data flows
are automatically switched to the new RTP connection with no time-out or loss of
data (nondisruptive path switch).
When an RTP connection fails, the RTP endpoint will attempt to find a new route
until the path switch timer expires. The path switch timer duration is modifiable
and can take a different value for each transmission priority.

1.2.7.4 Adaptive Rate-Based Flow and Congestion Control
Adaptive rate-based congestion control protocol is used by HPR to regulate the
flow of data over an RTP connection by adaptively changing the sender′s data
rate based on feedback on the receiver′s data rate. This protocol allows high
link utilization and prevents congestion before it occurs. The ARB algorithm is
implemented on the RTP endpoints of a connection.
1.2.8 Types of SNA Data Units

Both subarea and APPN networks make use of path information units (PIUs) to
transfer data. HPR acts more like a DLC and can have PIUs embedded in its
packets.
1.2.8.1 FID2
FID2 is the type of format identifier (FID) in a transmission header (TH) used
between a type 4 or 5 subarea node and an adjacent peripheral (type 2.0 or 2.1)
node. It is also used between adjacent APPN or LEN nodes. The format of a
FID2 header differs depending on whether a type 2.1 node is one of the partners
or not. FID2 refers to the hex digit 2 at the start of the header. A FID2
connection in this book refers to an APPN or LEN connection between two nodes
over which the FID2 PIUs flow.
1.2.8.2 FID4
FID4 is the type of format identifier in the transmission header (TH) used to route
data between subarea nodes. FID4 refers to the starting hex digit of 4 in such a
header. A FID4 connection refers to a subarea connection between two nodes
over which the FID4 PIUs flow.
1.2.8.3 FID5
FID5 is the type of format identifier in the transmission header (TH) used for
sessions flowing over RTP connections and was introduced to accommodate the
new enhanced session addressing algorithm. The FID5 TH contains the 8-byte
session address which is assigned at each RTP endpoint. This session address
is unique per session and direction (PLU-to-SLU and SLU-to-PLU). Each side
assigns the session address that has to be used by the session partner, when
sending data, to address the session. The FID5 PIU is imbedded in the network
layer packet (NLP).
1.2.8.4 Network Layer Packet

The network layer packet is used (instead of a PIU) to carry information across
an HPR connection. An NLP contains the following:
• A network layer header (NHDR), containing ANR labels for routing.
• A transport header (THDR), containing data used by RTP such as flow control
and path switch information.
• If there is data, a FID5 PIU for LU-LU or CP-CP session traffic. For
non-session traffic (route setup, for example), the data field contains the
appropriate HPR GDS variables.
1.2.9 APPN Directory Services
1.2.9.1 Directory Database

In an APPN network, each network node keeps a directory of resources which it
has (usually) located either by information received from served end nodes
(registered entries) or by successful searches. This directory is kept in cache
memory, although some nodes (such as VTAM) allow some of it to be
checkpointed to disk. The information in the directory shows the owning control
point and (if the owning CP is an end node) its network node server.
The directory database is regarded as an indication of the location of a resource,

rather than an absolute fact. Thus when a network node is asked to locate a
remote resource, it will normally verify the location of that resource by sending a
directed search request to its network node server.
1.2.9.2 Central Directory Server

In a large network it may be undesirable to have the APPN directory distributed
throughout all NNs, so the use of one or more central directory servers (CDSs) is
recommended.
A CDS provides a focal point for locating resources in the network. The
resource location information is forwarded to the CDS by the network node
serving the resources, at the request of the actual owner (the NN or a served
EN). The CDS directory is exactly the same as any NN′s directory, except that it
is usually larger.
If an NN searching for a target resource cannot find it in its own directory, the
search request is forwarded to the CDS. If the CDS is unaware of the resource,
the CDS then sends the search to other central directory servers, if they exist in
the network. If the search receives a negative response (resource is unknown)
from these other central directory servers, then a broadcast search is issued by
the original central directory server. If the resource is located by the search, its
location will be added to the CDS database and also to the database of the NN
initiating the search.
A central directory server is presently only implemented by VTAM. A CDS is

identified as such in the topology database thus enabling other NNs to find it.
If a central directory server is not used, a broadcast search is initiated from the
network node server on behalf of directly attached LUs, LEN-attached LUs or LUs
attached to served end nodes. The search information retrieved is not
communicated to other network nodes. It is stored in the network node server′ s
directory services database. If another network node receives a request for the
same resource and does not have the location information, it will issue another
broadcast search.
You can see from this that a central directory server can bring many benefits to
an APPN network by reducing the numbers of searches. Bear in mind that it is
possible to have more than one central directory server in an APPN network.

1.2.10 APPN Topology and Class of Service
1.2.10.1 APPN Topology Database

The topology databases (TDBs) are part of the topology and routing services
(TRS) of APPN. These databases are used to locate resources and calculate
routes for sessions. There are two types of topology database, network and
local. Network nodes maintain both network and local topology databases,
whereas end nodes keep only local information. These databases are kept in
cache memory, although some implementations (VTAM among them) allow
checkpointing to disk. For more information regarding network routing and
resource location, refer to VTAM Network Implementation Guide , SC31-8563.
1.2.10.2 Network Topology Database

The network topology database is found in every network node. It is usually
referred to simply as “the topology database”. It contains current and complete
information about every network node in the network. It also keeps information
on all transmission groups connecting those network nodes. This information is
the same in all network node topology databases. There is no information about
LUs, end nodes or LEN nodes. Connection information for ENs and LEN nodes is
provided to the NN as part of session setup.
Network nodes exchange topology database update (TDU) messages to keep

their databases current. Exchanging the entire database after CP-CP session
establishment between network nodes could require a considerable amount of
overhead for large networks. Therefore, at this time, the two nodes only inform
each other of changes that occurred while their CP-CP sessions were inactive.
In VTAM it is possible to checkpoint and save the TDB to increase the speed of
network restarts. Checkpoints can be issued via a VTAM MODIFY command and
automatically occur when bringing down VTAM with a Z NET or a Z NET,QUICK.
After VTAM is restarted only new information is exchanged. For VTAM to restart
using the checkpointed TDB the start option INITDB should be set to ALL or
TOPO. The default is ALL.
1.2.10.3 Local Topology Database

A local topology database is found in both network nodes and end nodes. In a
network node, the local TDB contains information about all attached end nodes
and their local links that the NN is made aware of. In an end node, the local
TDB is used to determine a route to the network node server and supply the TG
vectors connecting the EN to that server and other network nodes. This
information is then stored in the network node server′s own local TDB. In VTAM,
local TDBs are not saved between restarts.
1.2.10.4 APPN Topology and Routing Services

For more information on this subject, we suggest you consult Chapter 5 in Inside
APPN - the Essential Guide to the Next-Generation SNA , SG24-3669, and Chapter
10 in VTAM Network Implementation Guide , SC31-8563. These chapters describe
routing and session setup in both a subarea network and in an APPN network.
Having said this, a brief overview is warranted here.
The APPN topology and routing services component consists of the following
three parts:
• Topology database manager
• Route selection services
• Class of service manager
The topology database manager is covered under 1.2.10.1, “APPN Topology

Database” on page 13. Route selection services and the class of service
manager are used together with the topology database manager to set up an
optimal session path for an LU-LU session based on the individual
characteristics of a resource and the location of its session partner. These
characteristics will vary for different types of sessions. For example, interactive
session traffic is very different from file transfer traffic. APPN class of service
specifications (covered in 1.2.10.5, “APPN Class of Service” on page 15)
comprise the desired characteristics (route attributes) for a particular session.
In APPN, transmission groups are defined between APPN and/or LEN nodes.
FID4 connections (subarea-subarea) are not included in the APPN topology
database (unless VR-TG is used), while FID2 TG connections are. The
transmission groups are described by APPN characteristics. Some of these are
user-defined, and others are dynamically defined.
These characteristics are used to compute a weight. The weight of an APPN TG

in the network is obtained by comparing the actual value for each TG
characteristic (stored in the topology database) with the acceptable ranges of
values for that characteristic as specified in the APPN COS table.
Where all the actual TG values fall within the ranges specified by an entry in the
APPN COS table, the weight associated in that entry is the TG weight attributed
to that TG. These TG weights are then aggregated over all possible TGs to form
the route weight. They are used in conjunction with a user-defined node
weighting for each intermediate node on the route. In VTAM this is defined as
the route additional resistance (a value between 0 and 255). The path chosen for
a session is the route with the lowest total (TGs plus nodes) weight.
The following is a list of attributes defining a TG:

• Cost-per-connect time: Represented by a single byte value (0-255).
Meaningful for a switched connection.
• Cost-per-byte: The relative cost of transmitting a single byte over a TG.
Meaningful for a packet-switched connection.
• Security: Security protection provided on a TG. Seven defined levels.
• Propagation delay: The length of time it takes for a signal to travel from one
end of a TG to the other. For example, satellite links have high propagation
delay.
• Effective capacity (or speed): The highest bit transmission rate allowable on
a TG.
• User-defined values: Three additional user-defined values. Integers between
0 and 255.
VTAM V4R1 introduced the new VTAM definition statement TGP. Used in
conjunction with the PU parameter TGP= it allows TG characteristics to be
easily and conveniently defined for each connection. There are also new VTAM
commands for displaying and modifying transmission group profile
characteristics. See VTAM Resource Definition Reference, SC31-8565 and VTAM
Operation, SC31-8567.

1.2.10.5 APPN Class of Service
Both subarea and APPN route selection depends on the class of service
specified for the session. However, APPN class of service is different from
subarea class of service which implicitly defines the path that a session takes
using a virtual route mapped to an explicit route. APPN class of service
explicitly defines the characteristics of nodes and transmission groups which are
to be used for sessions and specifies an APPN class of service weighting for that
session.
The APPN class of service consists of line and node characteristics. Line
characteristics include security, line speed, propagation delay and cost (in terms
of units of time and by byte). Node characteristics are the level of congestion
allowed and the desirability of the node for intermediate routing. This
desirability of a node for intermediate routing is called the route resistance.
The APPN COS also specifies which of four transmission priorities (low, medium,
high, network) a session is to take.
There are seven architected APPN class of service entries, as follows:

1. CPSVCMG: Used by CP-CP sessions with network transmission priority.
2. SNASVCMG: Used by LU-LU CNOS sessions with network transmission
priority. Also used for DLUR/S sessions and management sessions.
3. #BATCH: Batch class of service using low transmission priority. High
bandwidth and low cost are favored over short delay.
4. #BATCHSC: The same as #BATCH with a m i n i m u m level of security
required.
5. #INTER: Interactive class of service with high transmission priority. Short
delay is favored over high bandwidth and low cost.
6. #INTERSC: The same as #INTER with some security required.
7. #CONNECT: Used by LU-LU sessions with medium transmission priority.
Often used as the default APPN COS if no other COS has been requested.
Note
It is strongly recommended that these APPN classes of service be used

whenever possible, since these are defined in all APPN nodes. The
consequence of defining your own APPN class of service is that you will have
to update every node in the network which will use that APPN class of
service.
1.2.11 Other APPN Terminology
1.2.11.1 Network Node Server

The network node server (NNS) is a network node that provides resource
location and route selection services to the LUs it serves. These LUs can be on
the network node itself, on attached LEN nodes, or on end nodes that have
established CP-CP sessions with this network node as their NNS. Any network
node can be a network node server for end nodes that are attached to it.
However, care must be taken with VTAM end nodes because they require a
particular APPN option (session services extensions) to be supported by their
network node server. At present only VTAM provides support for session
services extensions, although 2216 support has just been announced.
1.2.11.2 APPN Node-to-Node Connection

An APPN node-to-node connection (ANNC) enables a VTAM node to attach to
another node through a high-performance direct channel path using APPN
protocols. An ANNC is built on multipath channel (MPC) connectivity, and
requires at least two subchannels, one for reading and one for writing. ANNC
used to be known as APPN host-to-host connection (AHHC) when only VTAM
hosts supported the protocol. The ANNC channel can, of course, be used for
intermediate routing if one end is a network node.
1.2.11.3 Local-Form Session ID

The local-form session identifier (LFSID) is a 17-bit value that uniquely identifies
a session on a FID2 connection. In base APPN (not HPR), each session is
identified on each session stage (hop between nodes) by a unique LFSID. The
partner nodes on a connection build one LFSID for each session on that
particular connection (session stage). Each intermediate node therefore controls
two session stages (connections in and out of this node) and controls an LFSID
on each stage per session. The intermediate node uses session connectors
(tables) in order to change the LFSID received on one stage to the appropriate
LFSID on the other stage.
The LFSID is found in the transmission header (FID2) of the message.
LFSID is not used by HPR. Instead, sessions are identified by the session
address in the FID5 header.
1.2.11.4 RTP Connection Identifiers

An RTP pipe is a logical connection between two RTP-capable nodes, which can
carry multiple sessions with the same APPN class of service. Each session
flowing on an RTP pipe is identified by the session address in the FID5 header,
but there may also be multiple RTP connections between multiple functions in
the same two nodes. These are distinguished by means of the network
connection endpoints (NCEs) and the transport connection identifiers (TCIDs).
An NCE identifies an RTP endpoint within an HPR node. Exactly what functions
an NCE represents depends on the implementation. VTAM usually has one NCE
for all its LU-LU sessions, one for CP-CP sessions, and one for Route Setup
flows. Other NCEs may be defined for specific functions.
A TCID identifies a particular RTP pipe as seen by one of the RTP partners.
Each partner assigns a TCID to the connection which is subsequently used by
the other partner in the RTP header it sends. Thus an RTP pipe has two NCEs
(one at each end) and two TCIDs (one in each direction).
1.2.11.5 Fully Qualified Procedure Correlated ID

The fully qualified procedure correlated identifier (FQPCID) is a network-unique
identifier. It is used to identify a session across an APPN network. It is
generated by an origin node during session initiation and is sent on all
messages between nodes that relate to a particular session. This includes
Locate (search), BIND and UNBIND.

1.2.11.6 Generalized Data Stream (GDS)
The Generalized Data Stream is architected to provide a defined interface
between transaction programs which use LU 6.2 protocols. The RU portion of an
LU 6.2 PIU contains a function management header (typically FMH5) and a series
of one or more GDS variables. There are GDS mappings for the architected
commands which flow on CP-CP sessions. These commands include Locate, CP
capabilities, Topology Database Update, Register Resource, Route Setup and
others. For more information on GDS variables, see SNA Formats, GA27-3136.
1.2.12 APPN Session Setup

Before any session setup can take place, the APPN network must be connected.
The user defines the links connecting each node, at least from one side. When a
connection is established an automatic activation sequence takes place using
XID format 3 DLC exchanges. In this exchange, rules are established and
capabilities and roles are negotiated. In some cases, this is followed by the
establishment of sessions between the control points (CPs) of the two nodes.
For a VR-TG connection, the XID3 exchanges are replaced by similar exchanges
over the SSCP-SSCP session.
When CP-CP sessions have been established, topology updates and resource
registration flows take place. Once the network topology has been established
between network nodes and connections made to end nodes, LU-LU sessions
can be started. To establish an LU-LU session, there are four basic steps, as
follows:
1. The LU specifies the desired attributes for the session. It provides a mode,
which is resolved to an APPN COS by its CP (or, in some cases, its NN
server).
2. The destination LU (DLU) is located. Based on the information in its topology
and directory databases, the NN server issues one of the following:
• A directed search to the DLU′s NNS (if the NNS has knowledge of the
DLU location in its directory database and therefore needs only to verify
that it has not moved)
• A referred search (to search the central directory server′s database)
• A broadcast search (issued by either a central directory server, or a
network node server if there is no CDS in the network)
3. The network node server of the primary LU chooses the optimal route. The
topology database, the session COS and the APPN COS table are used to
calculate the route.
Note that, if the session path contains an IC-TG, the network node server of
the OLU (which is not necessarily the PLU) will calculate the route. This is
necessitated by the differences in the session setup flows for APPN and
subarea.
4. Finally, the session is established by forwarding the BIND from the PLU to
the SLU. The BIND contains a Route Selection Control Vector (RSCV) built
by the NN which calculated the route. The RSCV identifies the nodes and
TGs along the route from the PLU to the SLU. The RSCV allows the BIND to
flow on its chosen path, as each intermediate NN builds its routing tables to
match the LFSIDs to the session.
For HPR-capable networks, the session setup is the same as for basic APPN with
some exceptions. The network topology database is aware of which nodes are
RTP-capable, which are ANR-capable and which are neither. When the RSCV is
created, it contains the same information which is therefore available to
CP(PLU). Thus the PLU node can identify where on the session path an RTP
connection is possible. If a suitable RTP connection already exists (same APPN
COS and same HPR portion of the route as the new session), it is used for the
new session. Otherwise, a route setup message flows at the point where the
BIND would be sent in base APPN. The route setup protocol obtains ANR
forward and reverse labels for the route. The RTP connection is then
established and the BIND is sent on it.

Chapter 2. Network Configuration
As mentioned in Chapter 1, the objective of this document is to outline the main

steps required to migrate an existing subarea network to a combined subarea
and APPN network. Before we start with the main objective, it would be useful
to describe the initial subarea network and the final network after migration,
which is the combined subarea and APPN network. This would help in better
understanding the migration steps detailed in the following chapters. This
chapter describes the initial subarea network, the software and hardware level of
resources making up this test network, and the related VTAM definitions of all
these resources.
SNA network sizes vary from a few to thousands of nodes. So it is recognized

that this test subarea network that we set up at the ITSO in Raleigh may not
include all types of resources or connections that an implementation might have;
but we have attempted to set up a network which would be close to being a
typical subarea network.
Note that the VTAM systems described here are all V4R3. When the tests
described in this book were conducted, V4R3 was the current level of VTAM.
V4R4 was used in the second volume. The major differences between V4R3,
V4R4 and CS OS/390 Release 5 (the latest available level of VTAM) are in the
HPR and sysplex areas. In this volume, the differences between V4R3, V4R4 and
CS OS/390 R5 operation are minimal, and are pointed out where they occur.
2.1 Subarea Network

Figure 1 on page 20 shows the configuration of the subarea network used in the
tests.

Figure 1. Initial Subarea Network
The subarea network consists of the following:

• Two MVS/ESA V4R3 systems which run in virtual machines under VM/ESA
V1R2. Both the MVS/ESA systems are running VTAM V4R3.
− VTAM RAA (subarea 10) provides the function of a communications
management configuration (CMC). A complete list of major nodes on
RAA has been included in D.1, “VTAM RAA Definitions” on page 208.
− VTAM RAS (subarea 28) is a data host.
RAS is connected to RAA by a subarea multipath channel (MPC) link. A
complete list of major nodes on RAS has been included in D.2, “VTAM
RAS Definitions” on page 233.
• A 3745-41A configured as a twin-dual node; that is, an NCP running
independently in each of the two CCUs. The NCPs are at Version 7 Release
3, and ACF/SSP V4R3 is used for generation and loading. Both NCPs are
activated and loaded from RAA.
− The local NCP, RA5NCPX (subarea 5), is channel-attached to the CMC
RAA and has a token-ring interface coupler (TIC) with a MAC address of
400001050001. A copy of the NCP major node has been included in D.1.8,
“NCP RA5NCPX Definitions” on page 215.
− The remote NCP, RA8NCPX (subarea 8), has an INN link to RA5NCPX and
a channel connection to data host RAS. It also has a TIC, with a MAC
address of 400001080001. A copy of the NCP major node has been
included in D.1.9, “NCP RA8NCPX Definitions” on page 224.

• Local and remote 3174s, all running microcode level C6. Although the 3174s
are configured as APPN network nodes, VTAM treats them as LEN nodes
because it does not understand APPN. The 3174s contain both dependent
and independent LUs.
− Local 3174-11L (PU name RAALCLP) with a channel connection to RAA.
The local major node definitions are included in D.1.5, “Locally Attached
3174 Definitions” on page 211.
− Remote 3174-11R (PU name P3174C1) with an SDLC connection to
RA5NCPX. The PU definitions for the 3174 are part of the NCP source in
D.1.8, “NCP RA5NCPX Definitions” on page 215.
− Remote 3174-63R (PU name RAATRPU1) with a token-ring connection
using a MAC address of 400031740004. The PU definitions for the 3174
are in the switched major node RAASWMN1 and are shown in D.1.7,
“Switched Major Node Definitions” on page 212.
• PS/2 machines running Communications Manager or Communications
Server, configured as LEN nodes, with both dependent and independent LUs.
− PS/2 (PU name RA8CM2A) with an SDLC connection to RA8NCPX. The
PS/2 also has a token-ring connection to its local LAN segment, and
provides an SNA Gateway (server) function for a PS/2 requester machine
connected to the same token-ring segment. The PU definitions for the
PS/2 are part of the NCP source included in D.1.9, “NCP RA8NCPX
Definitions” on page 224.
− Three PS/2 machines with PU names RAATRPU2-4, with token-ring
connections to RA5NCPX as their host gateway. The PU definitions for
the three PS/2s are in switched major nodes RAASWMN2-4 and are
shown in D.1.7, “Switched Major Node Definitions” on page 212.
The PS/2s are running Communications Manager/2 and OS/2 Warp Version
3, except the two acting as the SNA Gateway server and requester. These
two have Communications Server/2 Version 4 (at the time the latest version)
installed.
Communications Server for OS/2 Warp is the follow-on product to
Communications Manager/2 V1.11. The current version (Version 5) has
numerous improvements over Communications Manager, particularly in the
areas of HPR, DLUR and branch extender function.
• An AS/400, actually an APPN network node, is seen by the subarea network
as a LEN node with dependent and independent LU capabilities. The PU
definitions for the AS/400 are in the switched major node RAASWMN5 and
are shown in D.1.7, “Switched Major Node Definitions” on page 212.
Note: VTAM RAA is the CMC in this subarea network and thus owns all the SNA
network resources defined on the NCPs, 3174 controllers, CM/2 and CS/2
machines, and AS/400. VTAM RAS is only a data host.
2.2 Combined Subarea and APPN Network after Migration

This section describes the combined subarea and APPN network after all the
migration steps have been carried out. All the migration steps, along with the
necessary definitions, are described in detail in the following chapters.
Refer to Figure 2 on page 22 for the final configuration of the network. A

complete list of major nodes for VTAM definitions used in the APPN migration
Chapter 2. N e t w o r k Configuration 21
has been included in Appendix F, “VTAM Definitions with RAA as ICN” on
page 243, Appendix G, “VTAM Definitions with RAA as ICN and RAS as MDH”
on page 245, and Appendix H, “VTAM Definitions with RAA as ICN and RAS as
EN” on page 251.
Figure 2. Combined Subarea and APPN Network after Migration
As part of the migration to a combined subarea and APPN network:

• RAA has now been transformed into an interchange node (ICN) and its CP
name is RAA, which is the same as its SSCP name. It is defined as a
network node (NN) while maintaining its subarea number. RAA is in fact a
composite network node (CNN), since it also owns the two NCPs RA5NCPX
and RA8NCPX. To the APPN network, a CNN appears as one network node,
while to the subarea network each of the three nodes is distinct.
• RAS has been transformed into a migration data host (MDH) and its CP
name is RAS, which is the same as its SSCP name. It is defined as an end
node (EN) while maintaining its subarea number. To the APPN network, it
appears as an EN and to the subarea network it is still a subarea domain.
• The two NCPs are now part of the CNN along with RAA and are not separate
nodes within the APPN network.
• All 3174s, except P3174C1, are left as Type 2.1 LEN nodes. P3174C1 has
been migrated to a network node (CP name CP31742) with an APPN
subnetwork (peripheral) boundary to the rest of the network.
• The three CM/2 machines on the local token-ring are migrated to a network
node (CP name CP05147), an end node (CP name CP05137) and the third one
is left as a LEN node.

• The Communications Server PS/2 (PU name RA8CM2A) is now an APPN
network node with CP name CP05160. It has a different NetID from RAA,
requiring the use of a peripheral subnetwork boundary.
• The AS/400 on the LAN is still a network node, but now its connection to
RAA is APPN. Once again it has a peripheral subnetwork boundary with the
rest of the APPN network. Its CP name is RALAS4A.
In the migrated network, the subarea links left are:

• The channel connection between NCP RA5NCPX and the CMC host RAA.
This must always remain a FID4 connection because this is the link over
which RAA activates and owns RA5NCPX.
• The channel connection between NCP RA8NCPX and the data host RAS.
This need not be a FID4 connection, although it is shown as such in the
diagram. Later in the book we investigate some scenarios in which it is a
FID2 connection.
• The SDLC INN link between NCP RA5NCPX and RA8NCPX. This must remain
FID4 because RAA owns and manages RA8NCPX over it.
The mixed network has the following characteristics:

• There are APPN connections between RAA and the following: RAS, CP05160,
RALAS4A, CP05137, CP05147 and CP31742. APPN protocols will be used for
searches and session setup.
• There are APPN connections between other NNs and ENs and between NNs
out in the network.
• Some of the existing explicit route (ER), virtual route (VR), PATH and CDRM
definitions are still required to support the following connections:
− The subarea connections between VTAM RAA and the NCPs within the
composite network node
− The subarea connection between VTAM RAA and VTAM RAS
− SNI connections, if any, to other adjacent subarea networks
Note
The migrated network we have shown here has both subarea and APPN
connections between the interchange node RAA and the migration data host
RAS. This is because our objective was to show every possible type of
connection and migration scenario. In real life, we do not recommend that
parallel APPN and subarea connections remain between any two VTAMs.
Either use VR-TG (in which case you have parallel APPN connections), or
migrate all FID4 links to FID2 (native APPN). 5.6, “Changing the Data Host
from MDH to EN” on page 108 and Chapter 7, “VR-Based TG
Implementation” on page 131 describe these two more desirable endpoints
of a migration.
Chapter 2. N e t w o r k Configuration 23
Chapter 3. Planning for Migration
The planning of an APPN environment is the most important part of the whole
process of migrating towards an APPN network, whether you as a user have a
large or a small SNA network. Get this right and you will have few problems.
There are many tasks to be done on the drawing board before touching a single
parameter. Additionally, there are many changes to hardware and software,
which can be made before initializing APPN on VTAM nodes.
This chapter concentrates on these planning steps and gives the customer an
insight into the most important ones for subarea to APPN migration. The
scenarios described later in this book are for a small- to medium-sized network.
In spite of this, the reader will still find the scenarios relevant to any network.
We have two VTAMs and two NCPs where other networks may have dozens of
VTAMs and NCPs. The migration process will be fairly similar. Customers will
have to decide on various parameters based on their own networks and how
those networks are presently defined. We will give some guidance on how to
answer these questions. This chapter therefore outlines guidelines for different
customer situations and leads into the practical chapters where we have
migrated our own network.
Most customers will want to know how to incorporate their existing dependent
logical units, such as 3270s, into an APPN network. This is covered in this
planning chapter and also in subsequent chapters where the need arises. The
next stage of dependent LU support (DLUR/DLUS) is covered in SG24-5204, as is
migration to remote DLUR nodes and HPR routers such as the 3746-9X0, 2216
and 2210.
In this book we have also covered subnetting (using the extended and peripheral
border node functions) to show how to split networks into smaller, more
manageable networks with less broadcasting of topology exchanges. Customers
will also see how the border node function can be used to migrate from SNI
environments.
Chapter 9 to Chapter 12, although not based on testing in our limited laboratory
environment, give some guidance relevant to larger networks. They cover
issues such as searching, route selection, determining class of service and
APPN network management. The larger the network, the more significant these
topics become.
3.1 Planning Steps

APPN eliminates the need for many predefinitions, allowing them to be done
dynamically. This will reduce the complexity of definition in many SNA networks.
It will also allow network systems programmers to delete many existing
definitions. A customer may decide to keep many definitions or reduce them
accordingly. Candidates for deletion and/or dynamic definition are adjacent CP
names, adjacent link station names, switched major nodes, cross domain
resources, independent logical unit definitions (for example, CDRSCs defined
with ALSLIST= or LUs defined with LOCADDR=0) and path tables.
Larger SNA sites will want to reduce reliance on definitions but will be reluctant
at first to do this for a number of reasons. Amongst these are security and the

requirement for terminal definitions in applications such as CICS and/or IMS. It
is recommended that these sites use a staged approach, keeping static
definitions initially and migrating to a more dynamic environment after APPN
implementation. We will show how you can have some control over dynamic
definitions.
3.1.1 VTAM/NCP Software Upgrades

For the migration scenarios used in this book, the levels of VTAM and NCP
software were at the latest available releases. As stated in Chapter 2, “Network
Configuration” on page 19 we were using VTAM V4R3 and NCP V7R3. These,
and later, release levels include many APPN performance, usability, and
functional enhancements. It is recommended that you upgrade to the latest
stable levels in order to take advantage of these improvements. For example,
although APPN and APPN boundary functions are supported starting with VTAM
V4R1 and NCP V6R2, HPR requires at a minimum VTAM V4R3 and NCP V7R3.
VTAM V4R2 or higher is required for DLUS support; APPN across an
NCP-controlled subnetwork boundary requires a minimum level of NCP V7R1.
HPR on an interchange node requires VTAM V4R4, while HPR across an
NCP-attached subnetwork boundary requires NCP V7R5. You may learn the
other advantages of migrating to CS OS/390 V2R5 and NCP V7R6 by consulting
Planning for Integrated Networks , SC31-8062.
Note that VTAMs and NCPs not supporting APPN may participate in APPN
networks as pure subarea nodes, LEN nodes, or as components of composite
network nodes.
You should review all the available maintenance for VTAM, particularly as new
function is often added via the maintenance process in between VTAM releases.
Where such functions are referred to in the book, we quote the APARs that
introduced them. We also list the recent ones in Appendix K, “New Function
Added by APARs” on page 261.
3.1.2 VTAM/NCP and APPN Node Roles

It is important to know what roles your VTAMs will play in the APPN
environment. Sit down with your network diagram and assign APPN node roles
according to the following criteria. If you have a CMC environment with a
takeover SSCP, designate both these as interchange nodes (subarea and NN).
This allows the backup CMC to take over the network.
Coding HOSTSA and NODETYPE=NN for the CMC and the backup CMC allows
both VTAMs to load, activate and own NCPs. If the backup VTAM was coded as
an EN (NODETYPE=EN), that VTAM could not participate in a network
takeover/giveback because the NODETYPE= start option cannot be changed
dynamically to convert the EN into an NN. The primary CMC VTAM will be a
CNN since it owns the network and its NCPs. After SSCP takeover, the backup
CMC becomes a CNN. The backup ICN will require FID4 connections to the
subarea network to allow it to take over NCPs. Refer to Chapter 8, “SSCP
Takeover in a Combined Subarea and APPN Network” on page 141 for more
information on APPN SSCP takeover.
Other VTAMs in the network would be designated as data hosts in the subarea
network (for example, they have channel-attached major node connections to
NCPs). These should initially be migrated to migration data hosts (MDHs) with
HOSTSA= and NODETYPE=EN specified in the ATCSTRxx member. These can

be migrated to pure ENs by removing the HOSTSA= parameter. See Chapter 5,
“Migrating a Data Host to an MDH or a Pure EN” on page 95 for more
information on migrating VTAM nodes to MDHs and ENs and the benefits of
doing so.
If you only have one VTAM in the network, make this an ICN as above. For all
intents and purposes, this is the CMC.
Another VTAM role to plan for is the designation of a central directory server.
Depending on the size of your network, you should have at least one CDS in
your network. The default registration value for VTAM applications is to register
with the NN server and a CDS. Using a CDS will reduce network broadcast
searches.
If you have an SNA network that consists of three or four remote sites, each of
which contain multiple VTAMs and NCPs, you may want to think about
configuring a CDS (or two) at each of these sites to reduce search traffic
between sites. It is common for the ICN to be given the role of central directory
server. Alternatively or in addition to using an alternate CDS, use subnetting.
See 3.1.16.1, “Setting up a Central Directory Server” on page 46 for more
information.
When designing your APPN network using your existing network diagrams, you
will want to decide the following:
• Which nodes to designate as NNs and which nodes to designate as ENs
• Which network connections can be converted to FID2 APPN connections and
which links must remain FID4 subarea links
In making these decisions, you will want to know the storage limitations of
various APPN platforms that comprise your network, the traffic flow patterns in
your network, and the traffic type. Understanding these issues will help you plan
for use of the border node function, plan adequately for the coding conventions
influencing network searches, and avoid an invalid network design.
For example, if you discover in your network analysis that you have existing
APPN subnets whose NNs have limited storage capacity (3174, for example), you
may be led to a design decision involving continued LEN connectivity or
peripheral boundary attachment until such a time as the capacity constraints can
be overcome with either a replacement platform or with an APPN subnet
redesign.
LEN or peripheral boundary connection will isolate the APPN subnet from the
greater VTAM/APPN network, thus respecting the capacity limitations of the NNs
in question. For more information and migration scenarios on APPN subnetwork
boundaries, see Chapter 6, “Border Node Support” on page 115.
A proper understanding of network attachments and traffic flows will make the
task of coding certain VTAM start options (SORDER, SSEARCH, and so on) and
VTAMLST members (ADJCLUST, ADJSSCP, and so on) more logical than
otherwise would be the case. For more information about the VTAM start
options and VTAMLST, see VTAM Resource Definition Reference, SC31-8565, and
VTAM Network Implementation Guide , SC31-8563.
Finally, your network design must be valid, allowing for all required
communication, thus avoiding the following common design errors:
Chapter 3. Planning for Migration 27

• Erroneously placing ENs or MDHs in the middle of the network, where they
are incapable of performing intermediate node routing of APPN traffic or
converting subarea requests to APPN requests
• Severely limiting if not preventing the flow of BSC 3270 traffic, which requires
FID4 connections on the session path
• Failing to give a VTAM end node another VTAM as a network node server.
This is a very easy error to make, especially when you remember that VTAM
may pretend to be an end node when managing a peripheral border.
Replacing an NCP with a 3746-9X0 can easily lead to just this situation, as
shown in Figure 3.
┌─────────────┐ ┌───────────┐ ┌───────────┐ ┌─────────────┐

│ │ │ │ │ │ │ │
│ VTAM1 │ │ Gateway │ │ Gateway │ │ VTAM2 │
│ ├─────┤ ├──────────┤ ├─────┤ │
│ NET1.SSCP1 │FID4 │ NCP1 │ FID4 │ NCP2 │ │ NET2.SSCP2 │
│ │ │ │ │ │ │ │
└─────────────┘ └───────────┘ └───────────┘ └─────────────┘
┌─────────────┐ ┌───────────┐ ┌───────────┐ ┌─────────────┐

│ │ │ │ │ │ │ │
│ VTAM1 NN │ │ 3746-950 │ │ │ │ VTAM2 NN │
│ ├─────┤ ├──────────┤ NCP2 ├─────┤ │
│ NET1.CP1 │FID2 │ NN │ FID2 │ │ │ NET2.CP2 │
│ │ │ │ │ │ │ │
└─────────────┘ └───────────┘ └───────────┘ └─────────────┘
Figure 3. VTAM EN With Non-VTAM NN Server
Consider the situation in the upper diagram in Figure 3. Two VTAM/NCP sites
are connected via a null SNI network, which isolates their network topologies yet
permits any LU-LU sessions across the network boundary. If it is desired to
replace one of the NCPs by a 3746-950 as in the lower diagram, the following
considerations apply:
1. Both VTAMs must be converted to APPN because the 3746 does not support
subarea connections.
2. VTAM2 must become an NN because it owns an NCP.
3. VTAM1 must also become an NN because at the time of writing the 3746
does not support session services extensions. Thus if VTAM1 was an end
node it would have no suitable network node server.
4. Because VTAM1 and VTAM2 are network nodes with different NetIDs, there
must be an APPN border between them. This can be on either side of the
3746.
5. Because the 3746 does not presently support the border node function, such
an APPN border must be a peripheral border.

6. One of the VTAMs must manage the peripheral border, and therefore must
pretend to be an end node served by the 3746.
7. However, the 3746 cannot function fully as a network node server for a VTAM
because it does not support session services extensions.
The result is that dependent LU sessions cannot traverse the APPN connection
between the two VTAMs. Even if DLUR is implemented on the 3746, not all
configurations will work. You must wait until the 3746 (or the 2216, for that
matter) supports the extended border node function, of which session services
extensions are a subset.
Stop Press
Support for the extended border node and session services extensions
functions has just been announced for the 2216. Planned availability is June
1998.
We have dealt earlier in this section with VTAM and NCP roles, but we have not
looked at other nodes which will participate in your APPN network. There are
many such devices that act as NNs, ENs or LEN nodes. These include AS/400,
RS/6000, PS/2 and many others. 3746, 2216, 2210 and 3174 nodes can participate
in APPN but cannot be configured as end nodes.
It is not necessary or recommended that you have an APPN network that

consists mainly of NNs. You should try to limit the number of NNs in your
network; this will keep topology exchanges and searches to a minimum. NNs
should have the capacity to maintain topology and directory databases as well
as providing network services for your application LUs and end nodes. Thus an
NN should be regarded as a server or router rather than just another
workstation, and an appropriate choice of hardware should be made. Your
major NNs should be where your major routing nodes and CMCs are now.
You may want to cluster ENs around non-VTAM NNs to reduce the number of
CP-CP sessions with VTAM and the registration traffic that accompanies these.
However, in doing so, you must take into account not only the capacity
limitations of various NN platforms, but also their usefulness as NNs in a session
setup and in a failure/recovery situation. Remember that a VTAM EN must have
another VTAM as its NN server because, at the time of writing, only VTAM
supports session services extensions.
In the case where a VTAM fails and another VTAM takes over its NCPs, you
should be aware that:
• All CP-CP sessions to the failed VTAM will be terminated, even though the
NCP and cross-domain LU-LU sessions remain active.
• A new XID exchange will take place to establish the new relationship
between the connection partners.
• The CP name presented to the adjacent node will change.
Therefore, for takeover to function smoothly attached nodes must be able to:
• Tolerate receipt of XIDs on an existing connection
• Tolerate CP name change when the CP-CP sessions are reestablished
Some nodes do not support these functions (APPN options 1001 and 1004).
Therefore, you may want to upgrade them or replace them with platforms that do

support this function. You may want to delay their integration into the
VTAM/APPN network until options 1001/1004 are available on them, or you may
want to develop detailed backup/recovery plans for your VTAM/APPN network to
address the lack of the function. Please refer to Inside APPN - the Essential
Guide to the Next-Generation SNA for the latest information on which IBM
products support function set 1004.
To estimate APPN storage requirements in VTAM, use the application on the

eNetwork Communications Server for OS/390 Web site at
http://www.networking.ibm.com/vta/vtastor.html
Although the 3174 can only be defined as an NN, it is not a good choice for an
NN. This is due to its traditional boundary node function and the fact that it has
minimal storage capacity for topology databases. It is recommended that it
either be left connected via LEN, or isolated from the backbone using VTAM′ s
border node function.
NCP cannot be an NN by itself. To the APPN network, it is part of the composite

network node consisting of a VTAM and all its owned NCPs.
3.1.3 Naming Conventions

Every SNA network has some sort of naming convention. Even if not required for
management purposes, a naming convention is needed to ensure that the SNA
rule requiring unique names is not broken.
When migrating to APPN, you will need some conventions for new resources
such as CP names and possibly additional network names (see 3.1.17, “Border
Node” on page 49 and Chapter 6, “Border Node Support” on page 115 for more
information on subnetting and APPN borders).
Before implementing an APPN environment, it is important to make sure that CP

names are not duplicated. Prior versions of VTAM did not enforce unique CP
names for LEN nodes, simply because these CP names were not used in any
network flows and had local meaning only. The only case where a CP name
mattered in pre-V4R1 VTAM was where CPNAME was coded on a switched PU
definition statement to identify a resource. In an APPN environment CP names
are also LU names and must be unique.
It is quite possible that your network will have APPN-capable resources with
duplicate CP names, which are currently attached as LEN nodes. This must be
resolved prior to nodes becoming APPN nodes. Specifying CONNTYPE=LEN for
a connection causes VTAM to avoid checking for duplicate CP names, except
when CPNAME is coded on a switched PU. At the same time, it forces the
connection to remain LEN even though both partners are APPN-capable.
Also, when converting a LEN to an APPN node, ensure that the adjacent link
station name (VTAM-defined PU name) for an adjacent node is different from the
CP name of that node; the PU name and the CP name are now in the same
name space and will be considered duplicate names if they are the same.
CP-CP sessions will not be set up and a sense code will be issued by VTAM.
In order to highlight the importance of these naming conventions, we ran three

tests to see what effect naming conventions had on a particular connection. We
connected a PC end node to a VTAM network node (via an NCP) using various

combinations of definitions. In all the tests we used static switched major node
definitions in VTAM.
3.1.3.1 Test 1 CPNAME/PUNAME

In the first test the EN was a PC running CM/2 V1.11 and defined with VTAM RAA
as its network node server. The actual CP name, VTAM′s PU name and VTAM′ s
definition of the CP name were the same. Table 1 summarizes the definitions
used.
Table 1. PU and CP Names (1)

Where Value
Local node name (FQ_CP_NAME) in RAATRPU2
CM/2
VTAM PU name (name on PU statement RAATRPU2
in switched major node)
VTAM CP name (CPNAME= on PU RAATRPU2
statement)
The following results were observed.
IST590I CONNECTIN ESTABLISHED FOR PU RAATRPU2 ON LINE J0005021

IST1086I APPN CONNECTION FOR USIBMRA.RAATRPU2 IS ACTIVE - TGN = 21
IST663I BFINIT REQUEST FROM RA5NCPX FAILED , SENSE=100300211
IST664I REAL OLU=USIBMRA.RAATRPU2 REAL DLU=USIBMRA.RAA
* RAAAN D NET,ID=RAATRPU2,E
RAAAN IST097I DISPLAY ACCEPTED
′ RAAAN
IST075I NAME = RAATRPU2 , TYPE = PU_T2.1
IST486I STATUS= ACTIV , DESIRED STATE= ACTIV
IST1043I CP NAME = RAATRPU2, CP NETID = USIBMRA , DYNAMIC LU = NO
IST1105I RESOURCE STATUS TGN CP-CP TG CHARACTERISTICS
IST1106I RAATRPU2 AC/R 21 YES2 982D000000000000000001710080808
IST1482I HPR = NO - OVERRIDE = N/A - CONNECTION = NO
IST136I SWITCHED SNA MAJOR NODE = RAASWMN2
IST081I LINE NAME = J0005021, LINE GROUP = EG05L01 , MAJNOD = RA5NCPX
IST654I I/O TRACE = OFF, BUFFER TRACE = OFF
IST1500I STATE TRACE = OFF
IST355I LOGICAL UNITS:
IST080I RAATLU22 ACTIV RAATLU23 ACTIV RAATLU24 ACTIV
IST080I RAATLU25 ACTIV
3
IST314I END

Figure 4. Displays and Sense Codes for RAATRPU2
Figure 4 shows the displays observed in VTAM. What happened here was that
the APPN connection was established successfully (after XID3 exchange), but
then the PC tried to establish CP-CP sessions with VTAM. The NCP sent in
BFINIT, but VTAM rejected this with a sense code 1 which means “BFINIT
invalid for resource type”. The BFINIT has the OLU name RAATRPU2 on it, but
VTAM regards it as a PU name.

The display of the link station from VTAM shows 2 that the connection is a
valid APPN connection, supports CP-CP sessions and has been stored in the
APPN topology database (local TDB in this case). However, there are no CP-CP
sessions active. The CP name is conspicuous by its absence in the list of LUs
3 on this connection.

For the second test, the only change was to modify the coded CPNAME in the
VTAM definitions, as shown in Table 2.
In this case there is no match between the CP name coded in the switched
major node and the actual CP name presented on the XID3 from CM/2. VTAM
set up the connection because dynamic PU definition was in effect, but no CP-CP
sessions were possible because the LU name of the CP was still the same as
VTAM′s link station name.

Where Value
Local node name (FQ_CP_NAME) in RAATRPU2
CM/2
VTAM CP name (CPNAME= on PU RAATRCP2
statement)

For the third test, we changed the actual CP name in CM/2 and left the VTAM
definitions as in Test 2. Table 3 shows the definitions we now had.

Where Value
Local node name (FQ_CP_NAME) in RAATRCP2
CM/2
VTAM CP name (CPNAME= on PU RAATRCP2
statement)
Now the definitions are correct and the names are unique. Figure 5 on page 33
shows the VTAM display of the link station RAATRPU2. Now RAATRCP2 is seen
in the list of sessions 1 on this link station, so we know that the PC′s CP name
is a valid LU name. The display of VTAM′s topology database shows at 2 that
there are indeed CP-CP sessions between the two nodes. The following results
were observed:

C RAAAN DISPLAY NET,ID=RAATRPU2,SCOPE=ALL

′ RAAAN
IST486I STATUS= ACTIV--L--, DESIRED STATE= ACTIV
IST1043I CP NAME = RAATRCP2, CP NETID = USIBMRA , DYNAMIC LU = NO
IST1106I RAATRPU2 AC/R 21 YES 982D0000000000000000017100808080
IST080I RAATRCP2 ACT/S----Y 1
IST314I END
* RAAAN D NET,TOPO,LIST=EN
′ RAAAN
IST350I DISPLAY TYPE = TOPOLOGY
IST1295I CP NAME NODETYPE ROUTERES CONGESTION CP-CP WEIGHT
IST1296I USIBMRA.WTR05115 EN *NA* *NA* YES *NA*
IST1296I USIBMRA.CP05147 EN *NA* *NA* YES *NA*
IST1296I USIBMRA.RAATRCP2 EN *NA* *NA* YES2*NA*
IST1296I USIBMRA.RAATRPU2 EN *NA* *NA* NO 3*NA*
IST314I END

Figure 5. Displays of RAATRPU2 with C P N A M E = R A A T R C P 2
Note the “----Y” in the entry for RAATRCP2 1, meaning that the resource has
been created dynamically. All independent LUs in session with VTAM′s own
resources are represented by CDRSCs. Although the new CP name is defined
as a CP name in the switched major node, it is not defined as an LU anywhere.
Therefore, the CDRSC is created dynamically when the BIND arrives for the first
CP-CP session.
Note also that the previous CP name 3 of the PC is still in the topology
database since the default time for resources to remain in the topology database
is 15 days. You can manually delete this entry using the following command:
F NET,TOPO,ID=RAATRPU2,TYPE=FORCE
Figure 6 on page 34 shows the results.

* RAAAN F NET,TOPO,ID=RAATRPU2,TYPE=FORCE

RAAAN IST097I MODIFY ACCEPTED
RAAAN IST223I MODIFY TOPO COMMAND COMPLETED
′ RAAAN
IST1296I USIBMRA.WTR05115 EN *NA* *NA* YES *NA*
IST1296I USIBMRA.RAATRCP2 EN *NA* *NA* YES *NA*
IST314I END

Figure 6. Using F NET,TOPO to Delete Directory Entries
Note: You may be asking why ENs are shown in this display, when only network
nodes are represented in the topology database. In fact, the D NET,TOPO
command causes VTAM to display its local topology as well as the network
topology. Thus attached end nodes are displayed as well as attached network
nodes.
The lesson learned here is to review your naming conventions for CP names and
PU names.
For network names (NetIDs), you can usually use your existing names. If you
decide to subnet, you may require more network names. Depending on your
strategy you may have the same NetID for different APPN networks or use a
different one for each. See 3.1.17, “Border Node” on page 49 for more
information.
3.1.4 IBM 3746 Model 900 and Model 950 APPN Migration
If you use 3745-17A, 3745-21A, 3745-31A, 3745-41A or 3745-61A controllers, you
may also have the Model 900 expansion unit attached. This can offload DLC
functions in separate processors for SDLC, token-ring, frame relay, X.25 and
ESCON connections. The 3746-950 is a stand-alone version of the 3746-900, from
which an upgrade path is available. These controllers provide an excellent
migration path to APPN.
For information on APPN migration using the 3746 Model 900 and 3746 Model
950, please refer to the HPR and DLUR Implementation volume of this book,
SG24-5204.
3.1.5 Checking Existing Switched LEN Connections

A method is available for checking the LEN connections that are currently
established in your network. This involves the use of the VTAM configuration
services XID exit ISTEXCCS, which can be used for connection status recording
of incoming XIDs on switched devices or devices that VTAM sees as switched
such as token-ring. To invoke the exit for connection status recording, do the
following:
1. Add a CSDATA DD statement to your VTAM procedure. This statement
should point to an 80-byte record sequential data set.
2. In the sample ISTEXCCS exit, which can be found in SYS1.ASAMPLIB,
remove the comments on the line specified by 1 in Figure 7 on page 35.

***********************************************************************
* *
* Dynamic build is active by default. Call if PU defined and *
* connection status are inactive by default. ′ Uncomment/comment′ *
* the following 3 OIs to change the default activation of these *
* features. Subsequent processing will examine the bits in the *
* FEATURES byte and prepare for the activation of the appropriate *
* feature(s). *
* *
***********************************************************************
SPACE 1
BVPROC DS 0H Process BEGIN vector @V1A
2 OI FEATURES,DB Activate dynamic builds.
* CMNT * OI FEATURES,CID Activate call if PU defined.
* CMNT * OI FEATURES,CS1 Activate connection status.
Figure 7. Portion of ISTEXCCS Exit
Note:
1Remove * CMNT * from this line.
2If you do not want dynamic builds of PUs and dependent LUs at this
time, replace the * CMNT * on this line. The default exit has no comment.
Reassemble and link-edit the exit, then re-install according to your site′s normal
procedures. The MODIFY EXIT command enables you to activate, deactivate, or
replace the exit without recycling VTAM.
All connection status records will be recorded in the CSDATA data set for later
processing. Refer to VTAM Customization , LY43-0110 for a description of this
exit and the IBM-supplied default which can also be found in
SYS1.ASAMPLIB(ISTEXCCS). Users must be licensed for VTAM to obtain this
manual.
3.1.6 Dynamically Defining Switched Resources

VTAM switched resources can already be defined dynamically in subarea
networking. However, APPN provides dynamic definition of other functions
(remote LUs, routes and so on) so an APPN migration is a good opportunity to
remove as many static definitions as possible from your network.
VTAM provides three methods of defining switched adjacent link stations, two
dynamic and one static:
• Configuration services XID exit ISTEXCCS
In conjunction with the model terminal support major node, this exit can be
used to define dynamically PUs and LUs for switched incoming connections.
This also includes leased connections that appear to VTAM as switched
connections, such as token-ring devices and DLUR resources. The user
must define the exit and a model major node. The model major node is
coded using VBUILD TYPE=MODEL. The IBM-supplied default exit is coded
with the dynamic build function activated.
• DYNPU definition keyword.
This method is also available only for switched incoming connections, but
this time there is no provision for dependent LU definition. The DYNPU

keyword is coded on the GROUP, LINE or PU statement for a physical link.
The DYNPUPFX parameter can be used to specify the first two characters of
the link station name; if not specified, CN is used and the rest of the name is
created from a VTAM internal sequence number.
Note: With VTAM V4R1, DYNPU cannot be used with the ISTEXCCS exit
since the exit is always driven first and either builds a definition or rejects
the request. With V4R2, the exit can specify at initialization time whether or
not it is to be invoked when VTAM receives a connection request on an
APPN BF-TG. Thus DYNPU can be used for APPN connections and the exit
can be used for other connections.
• PU definition statement.
This is the standard static method for leased and switched PUs. Most of you
should be familiar with this definition already. This method is the only one
available for connections outbound from VTAM, with the exception of
connection network links which use the DYNPU method.
If dependent LUs are required, then the recommended method to use is the
configuration services XID exit, since DYNPU=YES causes only a PU (no LUs) to
be created. The ISTEXCCS exit gives control over PU and LU names and allows
security control in conjunction with the session management exit.
To give you a quick insight into the way the exit works, we have included a
description in Appendix J, “Configuration Services Exit” on page 257.
3.1.7 APPNCOS Start Option and Table

The IBM-supplied APPN class of service table is called COSAPPN. The table
should be copied from SYS1.ASAMPLIB (COSAPPN) to your VTAMLST data set.
This table is a source file and is not assembled and link-edited.
Note
It is not recommended that you change this table or add to it. If you do
decide to do this, you will have to update every APPNCOS table in every
APPN node through which your session may pass.
You may want to put an entry for your APPN COS table in the ATCCONnn
configuration list so that VTAM activates it at initialization. However, if VTAM is
started as an APPN NN or EN, it will activate the one called COSAPPN
automatically if it is found in VTAMLST.
There are two new VTAM start options associated with APPN class of service,
namely APPNCOS and ISTCOSDF. APPNCOS specifies an APPN class of service
which VTAM will use for a session under certain circumstances (see Figure 8 on
page 39). During initial testing APPNCOS should default to NONE. This will
allow you to resolve any APPN COS resolution problems, since sessions with an
unknown APPN COS will fail. After testing, change the default to #CONNECT to
allow unresolved APPNCOS sessions to use a medium-priority class of service
with relatively undemanding route requirements.
ISTCOSDF tells VTAM which types of resource can use the default mode entry
ISTCOSDF, and is invoked if no mode name is available for a session. This
could happen in an APPN-to-subarea session setup situation, as described in
Chapter 10, “Logmode and COS Resolution in a Mixed Network” on page 167.

ISTCOSDF defaults to INDLU (independent LUs), which is a good default since
the “mode unknown” condition is likely to occur when the session request
comes from an APPN PLU (see Chapter 10). The mode ISTCOSDF is an LU 6.2
mode which uses the #CONNECT APPN COS.
For information on how VTAM selects an APPNCOS entry, see 3.1.9, “ISTINCLM
and User-Defined Logmode Table Requirement” on page 38 and Figure 8 on
page 39.
3.1.8 Transmission Group Profiles

These profiles are used to associate TG characteristics with specific
connections. The profile entry coded for a connection is then used in
conjunction with the APPN COS in calculating paths for individual sessions. If
you decide not to use this table, all APPN connections will have default
characteristics, or will have to be coded individually with all of the
characteristics. Leaving the TG characteristics to default can be unwise.
Although most APPN nodes assume reasonable characteristics, sometimes
VTAM cannot determine what those characteristics should be and applies the
basic defaults. In particular:
• NCP line speeds are not usually coded correctly (if at all) since the 3745 is
perfectly capable of working out the speed of attached lines. VTAM,
however, has no idea what the real line speed is and assumes 8 Kbps.
• A VR-TG could comprise a number of alternative routes, each of a different
capacity. Again, VTAM assumes the lowest value of 8 Kbps for what could
be an ESCON connection.
Note
Having the wrong TG characteristics could result in unsuitable routes being

chosen for your APPN sessions. Perhaps more importantly, it will affect the
HPR flow control algorithms resulting in poor performance.
The IBM-supplied transmission group profile member is called IBMTGPS. A

default member can be found in SYS1.ASAMPLIB (IBMTGPS) and is shown in
E.1.1, “Transmission Group Profile Default Table IBMTGPS” on page 237.
The TG profile table is useful in defining profiles which can be pointed to by the
TGP= parameter on APPN connections. Although all of the parameters which
make up a transmission group profile table entry can be specified on each
connection, you may feel it is more easily managed by having a single table.
You can add entries to this table depending on your network setup. The table
should be copied from SYS1.ASAMPLIB (IBMTGPS) to your VTAMLST data set.
You should put an entry for IBMTGPS in your ATCCONnn configuration list so
that VTAM activates this table. This table is not assembled and link-edited.
If you activate a new TGP definition, it is used for subsequent link activations but
will not update existing TG characteristics unless you issue a MODIFY TGP
command for the existing TG.

3.1.9 ISTINCLM and User-Defined Logmode Table Requirement
The APPN class of service is separate from the subarea class of service, but
both are specified by coding them in the mode table entries. The old COS=
parameter is now joined by an APPNCOS=parameter. You might not use
subarea COS (allowing the blank COS to be used for all sessions), but APPN
requires the use of an APPN COS and you must make sure that one is available.
There are different ways to approach this. The IBM-supplied table ISTINCLM has
been updated with the APPNCOS= parameter for every entry and therefore will
not pose a problem. Although the new version is supplied in SYS1.VTAMLIB, if
you do not use this data set in your VTAMLIB concatenation you should check
that the new version of ISTINCLM will be picked up by the VTAM start procedure.
For user-defined logmode tables, you can do one or more of the following three
things:
1. Update all your logmode entries with an APPNCOS operand, which equates
to one of the entries in the APPNCOS table COSAPPN. The value chosen
will depend on the session path selection criteria.
Note
CS OS/390 Development strongly recommends that you consolidate all
your user-defined mode tables into a single table.
2. Add two new tables, as follows:

a. APPNTOSA. This maps APPN class of service names to subarea class of
service names in a table defined in a new major node using VBUILD
TYPE=APPNTOSA.
b. SATOAPPN. This maps subarea class of service names to APPN class of
service names in a table defined in a new major node using VBUILD
TYPE=SATOAPPN.
Examples of these COS mapping tables are shown in Chapter 10, “Logmode
and COS Resolution in a Mixed Network” on page 167. Their use requires
VTAM V4R3 or later.
3. Add entries to the APPNCOS table for every (subarea) COS name in your
logmode table. If VTAM does not find a valid APPN COS in the mode entry it
will look for an APPN COS with the same name as the subarea COS, if
coded. This method is not recommended because it requires that all
APPNCOS tables in all nodes (including non-VTAM nodes) through which the
session passes also be updated and maintained with these entries.
The APPNCOS is selected in a different manner from subarea COS. In APPN the
COS is chosen at the OLU end of the session, whereas in a subarea network the
COS is chosen at the SLU end.
VTAM will select an APPNCOS for a session in the following way if there is no
SATOAPPN COS mapping table:

┌───────────┐
│Is APPNCOS │ YES
│coded in │ use
│logmode │──────── that
│table? │ name
└─────┬─────┘
NO
┌───────────┐ ┌───────────┐
│Is COS │ │Is there │ YES
│coded in │ YES │an APPNCOS │─────── use
│logmode │──────── │by that │ that
│table? │ │name? │ name
└─────┬─────┘ └─────┬─────┘
NO NO
┌───────────┐ ┌────────────┐
│Default to │ │Is APPNCOS │ YES
│#CONNECT │ │start option│────── use
│(ignore │ │coded? │ that
│APPNCOS │ └─────┬──────┘ name
│start │ NO
│option) │
└───────────┘ Fail session
Figure 8. APPN Class of Service Decision Tree
If COS mapping tables are used, then the input COS (subarea or APPN) is used
to determine the output COS (APPN or subarea, respectively). The first COS
resolved by VTAM is always a subarea COS, and is always chosen by looking up
mode tables. Subsequent COS resolution is done by using the mapping tables if
they exist.
For a more detailed discussion of COS selection and mapping, please refer to
Chapter 10, “Logmode and COS Resolution in a Mixed Network” on page 167.
3.1.10 Multipath Channel Conversion

If your site has channel-to-channel links between VTAMs, these will need to be
converted to multipath channel (MPC) if you wish to use them as APPN BF-TGs.
MPC has several benefits over the old channel-to-channel protocol:
• Greater availability, since multiple parallel paths can be defined within a
single TG
• Better performance, because there is no channel turnaround time
• The ability to exploit high-performance data transfer (HPDT), which is
described in HPR and DLUR Implementation , SG24-5204
MPC is available on the more recent types of CTC connection, as far back as the
IBM 3088 and the VM virtual CTC links. However, it may not be supported on
older or non-IBM hardware and you will need to check this with the appropriate
supplier. If MPC is not supported then VR-TG is the only way to implement
APPN over the CTC connection. VTAM V4R2 or later is required to run APPN
over multipath channel connections.

MPC also supports subarea connections as from VTAM V4R1. You may wish to
convert old CTC to MPC even if you do not go all the way to APPN BF-TG, but
the definitions are different from both old CTC and APPN MPC. Subarea MPC
definitions use channel attachment major nodes as do their predecessors, but
the details of the coding differ as shown in Figure 9 and Figure 10.
*******************************************************************
* *
* CA MAJORNODE FOR RAA(10) TO RAS(28) - FOR FID4 MPC CONNECTION *
* *
*******************************************************************
RAACRAS VBUILD TYPE=CA
RAAGMP1 GROUP LNCTL=MPC,ISTATUS=ACTIVE,MAXBFRU=3
RAALMP1 LINE READ=(C12), *
WRITE=(C14)
RAAPMP1 PU PUTYPE=4,TGN=1
Figure 9. VTAM RAA MPC Definitions for FID4 Traffic
*******************************************************************
* *
* CA MAJORNODE FOR RAS(28) TO RAA(10) - FOR FID4 MPC CONNECTION *
* *
*******************************************************************
RASCRAS VBUILD TYPE=CA
RASGMP1 GROUP LNCTL=MPC,ISTATUS=ACTIVE,MAXBFRU=3
RASLMP1 LINE READ=(C14), *
WRITE=(C12)
RASPMP1 PU PUTYPE=4,TGN=1
Figure 10. VTAM RAS MPC Definitions for FID4 Traffic
The READ subchannels on one system must correspond to the WRITE

subchannels on the other system; in this example our C12 on RAA was
connected to C12 on RAS.
These are examples and users should arrange the channel addresses with their
MVS systems programmer prior to implementing. See VTAM Resource
Definition Reference , SC31-8565.
This is all you need for the MPC for subarea connectivity, although for better
availability and performance you may require multiple READ and WRITE
subchannels. See the chapter on tuning I/O for MPC connections in the Network
Implementation Guide , SC31-8563.
3.1.11 Multipath Channel Conversion for APPN

The FID2 APPN MPC channel definitions use the local SNA major node and a
new major node, the transport resource list (TRL) major node. When you
migrate your VTAM nodes to APPN, whatever their node type, you should
migrate the channel connections to APPN node-to-node connection (ANNC),
which is another name for APPN over an MPC connection.
This is done by changing the CA major node for MPC to a local SNA major node
with a TRLE operand pointing at a transport resource list element name. The

local SNA major node also defines the connection type (that is, type 2.1
connection). Add XID=YES to the local SNA major node on both sides.
At the same time create a transport resource list (TRL) definition specifying
L N C T L = M P C . The TRL element (TRLE) is not a resource but describes the
connectivity characteristics of the multipath channel connection. VTAM places
all TRLE definitions in a single major node labelled ISTTRL, which cannot be
deactivated. If you need to change the definition while it is active, use the
command V NET,ACT,ID=trl major node name,UPDATE=ALL.
These LOCAL and TRL definitions must be created at both VTAM nodes and
must match READ and WRITE channels in the same way as the CA major node
for MPC. The TRL major node must be activated before the PUs that reference
it; otherwise the PU activation will fail. Therefore, the local SNA major node for
an ANNC connection must be defined in the ATCCONnn member after the TRL
major node.
Figure 11 and Figure 12 on page 42 are examples:
****************************************************************
* AHHC DEFINITION FOR MPC LINK FROM RAA (SA10) TO RAS (SA28) *
****************************************************************
RAAAHHC VBUILD TYPE=TRL
*
RAAAHHCT1 TRLE LNCTL=MPC,
READ=(C14),2
WRITE=(C12)36
****************************************************************
****************************************************************
RAAAHHC VBUILD TYPE=LOCAL
RAAAHHC1 PU TRLE=RAAAHHCT,1
XID=YES,4
CONNTYPE=APPN,
CPCP=YES,
TGP=CHANNEL,5
ISTATUS=ACTIVE
Figure 11. RAA ANNC Definitions for FID2

****************************************************************
* AHHC DEFINITION FOR MPC LINK FROM RAS (SA28) TO RAA (SA10) *
****************************************************************
RASAHHC VBUILD TYPE=TRL
*
RASAHHCT1 TRLE LNCTL=MPC,
READ=(C12),3
WRITE=(C14)26
****************************************************************
****************************************************************
RASAHHC VBUILD TYPE=LOCAL
RASAHHC1 PU TRLE=RASAHHCT,1
XID=YES,4
CONNTYPE=APPN,
CPCP=YES,
TGP=CHANNEL,5
ISTATUS=ACTIVE
Figure 12. RAS ANNC Definitions for FID2
Notes:
1The label on the TRLE definition must match the TRLE= operand in the ANNC
local major node.
2The READ address C14 in RAA must relate to the WRITE address on the RAS
side. In our configuration each subchannel has the same address on each side.
3The WRITE address C12 in RAA must relate to the READ address on the RAS
side.
4Make sure that XID=YES is defined; otherwise, this is seen as a type 2.0
node and activation will fail.
5CHANNEL is a transmission group profile found in the IBMTGPS profile table.
6VTAM V4R4 introduced a new parameter MPCLEVEL which defaults to HPDT

meaning that HPDT is to be used on this connection if both partners support it
(V4R3 does not). This may not be desirable, particularly in three cases:
1. If one or both of the session partners is configured for ANR or no HPR
support
2. If VTAM′ s HPDT-capable partner is not another VTAM (for example, a 2216)
3. If you have not applied APAR OW26200 to your VTAM nodes
The implications of HPDT are described in detail in HPR and DLUR

Implementation , SG24-5204. You may wish to code MPCLEVEL=NOHPDT on
your TRLE definitions until you have determined that none of the potential issues
will arise.

3.1.12 APPN Node Roles and Connectivity
Your strategy here will depend on how many APPN-capable nodes you have in
your network, that will be using LEN connections prior to migration.
Once a VTAM host is made APPN-capable, the default start options will
automatically try type 2.1 connections as APPN connections. If your naming
convention for CP names and PU names has not been reviewed, there may be a
conflict between the VTAM PU name, the VTAM-defined CPNAME and the
attached node′s CP name. If there is a conflict, you may find that these nodes
will still be connected as LEN nodes. See 3.1.3, “Naming Conventions” on
page 30 for more information.
The initial problem can be overcome by coding CONNTYPE=LEN in ATCSTRxx

or on the GROUP, LINE or PU definition statements. This will allow you to
migrate individual nodes one at a time, or in groups of similar nodes.
You can refer to the scenarios in Chapter 4, “Migrating a CMC Host to ICN” on
page 61 for a practical demonstration of what happens to different type 2.1
devices with different configurations. The node type of each adjacent type 2.1
node can be specified on the PU by NN=YES or NO. If this differs from the
attached node′s actual role, the connection will fail. If not coded, the node type
will be determined in the XID3 when the connection is activated; this is the
recommended way.
To convert a LEN connection to APPN in VTAM, code the following:

• Change CONNTYPE=LEN to CONNTYPE=APPN in ATCSTRxx or on the
GROUP, LINE or PU definition statement. The CONNTYPE start option can be
changed dynamically while VTAM is running.
Note: Beware of the CPCP= parameter in ATCSTRxx which defaults to
LEASED, allowing CP-CP sessions for LEASED connections only.
• Specify APPN parameters on the GROUP, LINE or PU definition statement.
NN= should be coded on connections for which you are sure of the adjacent
node type. CPCP=YES should be coded if CPCP sessions are permitted.
TGP= should be coded to point at a specific transmission group profile. See
3.1.8, “Transmission Group Profiles” on page 37.
• Define the connection as APPN in the adjacent type 2.1 node, if not already
defined.
3.1.13 Checking Your NCP Buffer Pools

You should check your NCP pool values to ensure that enough session control
blocks are available for independent LU (APPN) sessions. A common sense
code if these pools are depleted is 0812000n. You may need to perform an NCP
generation to increase these values, unless:
• You have NTuneMON and NTuneNCP, or
• You have NCP V7R1 or higher, with the DYNPOOL operand coded on the
BUILD statement.
These NCP values should already be in place if you are using LEN connections,
but migration to full APPN is likely to result in more independent LUs
establishing more sessions with your VTAMs.

The following values should be checked in your NCP decks. A full description of
the operands can be found in NCP, SSP and EP Resource Definition Reference ,
SC31-6224.
1. LUDRPOOL
• NUMILU
2. BUILD
• NAMTAB
• AUXADDR
• ADDSESS
• MAXSESS
3. Independent LU (if coded in NCP, which is not recommended)
• MAXSESS
• RESSCB
In addition, check the MAXSESS and RESSCB operands on VTAM′s independent

LU (CDRSC) definitions.
3.1.14 Specifying Adjacent CP Names

An adjacent CP major node, ISTADJCP, is automatically created when a VTAM
node is activated. Adjacent CP names can be defined dynamically or statically.
They are defined in the following ways:
• Static adjacent CP names are defined by the use of an adjacent CP major
node or by the use of CPNAME on the PU definition statement.
• Dynamic adjacent CP names are defined by VTAM if the start option
DYNADJCP is YES (default). The dynamic adjacent CP entries are created
during XID processing when a link to the adjacent node is activated.
It is recommended that dynamically defined CP names be used whenever

possible unless you have a specific requirement to define them. You may want
to define other adjacent VTAMs, but you may not want to have to define every
CP in the network. Remember, one objective with APPN is to reduce definition
as far as possible.
If you set up CP-CP sessions between VTAM and any adjacent node, the CP
name is automatically defined as a CDRSC by VTAM regardless of your other
definitions or start options. However, if ILUs other than the adjacent CP attempt
to set up sessions across the connection, you will have to ensure that dynamic
LU definition is in effect. This can be achieved in one of three ways:
• Code DYNLU=YES as a start option (the easiest and the recommended
option).
• Code DYNLU=YES on the ADJCP statement (if using static CP definition).
• Code DYNLU=YES on each PU (link station) definition for the adjacent node.
Unless these independent LUs are defined (statically or via DYNLU) you will see
session setup failures such as:

IST663I BFINIT REQUEST FROM ISTPUSA0 FAILED , SENSE=08970015

IST664I REAL OLU=USIBMRA.RASAT02 REAL DLU=USIBMRA.RAATLU37
IST889I SID = F627D164E6B56EF7
IST314I END

Figure 13. DYNLU Failure in RAA for RASAT02 CDRSC
After this error, we created and activated the following adjacent CP major node:
*******************************************************************
* *
* ADJCP TABLE FOR RAA *
* SG24-4656 SUBAREA TO APPN MIGRATION GUIDELINES *
* *
* RAS SUBAREA 28 IS THE ONLY OTHER VTAM IN THE NETWORK *
* CP05147 IS AN APPN NODE RUNNING COMMUNICATION SERVER *
* *
*******************************************************************
RAAADJCP VBUILD TYPE=ADJCP
RAS ADJCP NETID=USIBMRA,DYNLU=YES
CP05147 ADJCP NETID=USIBMRA,DYNLU=YES
Figure 14. RAA ADJCP Table (RAAADJCP) with Entry RAS
The display of the link station then confirmed 1 that dynamic LU definition was
in effect:
C RAAAN DISPLAY NET,ID=RAAPUAHC,SCOPE=ALL

′ RAAAN
IST075I NAME = RAAPUAHC , TYPE = PU_T2.1
IST1043I CP NAME = RAS , CP NETID = USIBMRA , DYNAMIC LU = YES1
IST1106I RAAPUAHC AC/R 21 YES 988D0000000000000000017100808080
IST136I LOCAL SNA MAJOR NODE = RAALCL2
IST1314I TRLE = RAAAHHCT STATUS = ACTIV CONTROL = MPC
IST080I RAS ACT/S----Y
IST314I END

Figure 15. Display of AHHC FID2 Link Station after Activation of RAAADJCP
For more information on dynamic LU definition, please refer to VTAM Resource

Definition Reference , SC31-8565.
3.1.15 Topology Reporting for Switched Connections

By default, switched connections are reported to the APPN topology database
when the connections are activated. The keyword on the switched major node
that controls this is TOPO=.
An alternative in an APPN network is to make the connection auto-active. This

means that the connection is dialled only when a session requires it, although its

details are always in the topology database. This is accomplished by coding
TOPO=connection_cost on the switched major node, so that only a session
whose APPN COS allows that cost can be established over the link.
An auto-active connection requires existing CP-CP sessions for the session

setup flows to occur. Therefore, an alternate path between the same two nodes
is needed.
Refer to VTAM Resource Definition Reference , SC31-8565 for a more complete

description.
3.1.16 Directories and Registration

VTAM uses the directory services component of APPN to learn and maintain
information about the location of resources (LUs) in the network. Entries are
added to this database by resource definition, resource registration, and
dynamically through searches.
3.1.16.1 Setting up a Central Directory Server

Please refer to 1.2.9, “APPN Directory Services” on page 12 for information on
central directory servers and their functions. It is possible to have more than
one CDS in the network. For a discussion on setting up multiple CDSs in the
network, refer to VTAM Network Implementation Guide, SC31-8563, and the
CDSREFER start option in VTAM Resource Definition Reference , SC31-8565. If
there is a CDS in the network, an NN will not send out broadcast searches.
Instead it sends directed search requests to a CDS, and the CDS initiates the
broadcast if necessary.
Only VTAM supports the CDS function, although most other products will make
use of a CDS if one exists in the network. In general, you would choose your
CMC host VTAM(s) to be the CDS(s).
Consider checkpointing the CDS′s directory database at various intervals. Use

the F netproc,CHKPT command to checkpoint the APPN databases. Also, VTAM
will automatically checkpoint the directory and topology databases after a Z NET
or Z NET,QUICK command. VTAM will not checkpoint after HALT NET,CANCEL is
issued; therefore, if this is the way that you normally shut down VTAM, you
should arrange to issue the MODIFY CHKPT command prior to shutdown.
The directory database in a CDS is exactly the same as on an ordinary network

node, only bigger. The CDS is configured simply by coding the CDSERVR=YES
option in the VTAM start parameters. Configuration parameters relevant to a
CDS are:
1. CDSERVR=YES in ATCSTRxx for the designated central directory server(s)
2. DIRTIME (the time after which directory entries will be deleted), which
defaults to eight days
3. DIRSIZE (the max i mum number of entries in the database before the oldest
entries are deleted), which defaults to 100. The default value will probably
be too small for a CDS.
4. INITDB (which databases to load from a checkpoint data set at initialization
time), which defaults to ALL (both directory and topology).
5. Define the DSDB1, DSDB2 and DSDBCTRL DD names in your VTAM start
procedure. DSDBCTRL is used to determine which data set will be used by
VTAM to load the APPN directory database. Checkpoints alternate between

DSDB1 and DSDB2. In order to size these data sets use the following
information:
• Only dynamic (not defined or registered) entries are saved in the
checkpoint data set.
• Each 1000-byte logical record holds 29 entries.
• The number of entries kept is the smaller of DIRSIZE and the actual
number of remote resources in your network.
• Therefore, allocate space for enough 1000-byte entries to accommodate
the above.
The recommended block size is 6000 bytes.
6. Specify CDSERVR=NO in VTAM NNs which are not to act as CDSs. NO is
the default. CDSERVR is not valid on end nodes.
7. Specify CDSREFER= in non-CDS NNs to define the number of CDSs between
which each NN will distribute its registration and search requests. A small
number (1 or 2) is recommended.
3.1.16.2 Registering Resources

An end node can register its own resources to its NN server, so that it need not
be searched during subsequent domain broadcasts. A VTAM EN, indeed,
refuses to be searched on a broadcast because it assumes that it has registered
all the resources which will be the targets of searches. An EN which registers
its resources at its NN server can also ask for those resources to be registered
at a CDS. The registration request is forwarded by the NN server to the CDS
over a chain of CP-CP sessions, just like a search request.
LEN nodes cannot perform registration because they have no CP-CP sessions
with their network node server. Any target resources on a LEN node must be
predefined somewhere, normally on their NN server.
Resource registration is controlled in VTAM using the REGISTER operand on the

APPL, CDRSC, LOCAL and LU definition statements. Check the default definition
statement values in Table 4.
Table 4. Default Registration Values for Resources

Major Node Definition Statement Default Registration
Application Program APPL Central directory server
(REGISTER=CDSERVR) 1
CDRSC CDRSC No registration
(REGISTER=NO) 2
Local Non-SNA LOCAL Network node server
(REGISTER=NETSRVR)
LUGROUP LU Network node server
(REGISTER=NETSRVR)
Local SNA LU LU Network node server for
Model LU dependent LUs,
NCP LU LOCADDR ≠ 0
Switched LU (REGISTER=NETSRVR)
No registration for
independent LUs,
LOCADDR = 0
(REGISTER=NO) 2

Note that:
1Applications default to being registered at a CDS since they are most
likely to be search targets. The exception is TSO user applications
(TSOxxxxx), which are not registered anywhere because they are never the
target of a search.
2Independent LUs, by default, are not registered anywhere because they
are assumed to belong to some other node which is responsible for
maintaining their registration. As mentioned above, CDRSCs representing
LEN LUs should be defined on their network node server.
We found that the default registration values were sufficient in the laboratory
network. You may want to review their values.
3.1.16.3 Network Node Server List

A VTAM EN up to the CS OS/390 Release 5 level establishes CP-CP sessions
with the first network node it connects to, provided that this connection is
allowed by the network node server list (if active). Thus the NNS list (a member
of VTAMLST) has no influence on the order in which NN servers are tried at
initialization time. Only if CP-CP sessions to a NN server fail does VTAM try to
contact alternative NN servers in the order specified in the NNS list. A future
release of VTAM is planned which will move CP-CP sessions to a newly
connected NN, if that new NN is higher in the NNS list than the existing one.
Set up a preferred NN server list in each VTAM EN or MDH. If you do not specify
this list, the VTAM EN or MDH will set up CP-CP sessions with the first network
node it finds. Apart from the unpredictability of this, if VTAM chooses a
channel-attached 3746 or 3174 as its NN server your network will not function.
Dependent LU sessions require the APPN session services extensions option in
both EN and NN server; only VTAM currently supports the option.
You can control (to some extent, as described above) which NN is the preferred
NN server and define secondary NN servers. For example, you may want to put
your takeover ICN host node as the secondary preferred NN server.
To set up an NN server list in an EN, add a network node server list major node
to VTAMLST. An example is shown below. Activate your network node server
list by adding it to your ATCCONxx configuration list and restarting VTAM, or
activate it using the following command:
V NET,ACT,ID=network node server list
*******************************************************************
* *
* NETWORK NODE SERVER LIST MAJOR NODE FOR RAS *
* USES RAA AS ITS NETWORK NODE SERVER *
* THIS IS SUBAREA 28 PRIOR TO MIGRATION FOR RED BOOK *
* *
*******************************************************************
RASNNSVR VBUILD TYPE=NETSRVR,
ORDER=FIRST 1
RAA 2 NETSRVR NETID=USIBMRA,
SLUINIT=REQ
Figure 16. Network Node Server List for RAS

ORDER=FIRST 1 is the default and should be used to make VTAM select
servers in the order of the coded entries. ORDER=NEXT causes VTAM to select
servers in a “round robin” fashion, starting with the next entry after the one it
last used. 2 should be the name of your NN server. You need SLUINIT=REQ
(the default) to ensure that VTAM checks the selected NN for session services
extensions support.
If you wish to change your list dynamically, this can be done by issuing
VARY,NET,ACT,ID=netsrvr list name after updating the table. Then you must issue
VARY NET,TERM on the CP-CP sessions between this EN and the existing NN server
to force VTAM to use the new list.
Note: Issuing a VARY TERM command to terminate the CP-CP sessions might
cause later session establishment requests to fail. To resolve the problem,
reactivate the CP-CP sessions or else reactivate the link with CPCP=NO so that
it will no longer be used in directed search routing. Refer to VTAM Operation ,
SC31-8567.
3.1.17 Border Node

A border node is a network node with additional capabilities that allow it to
communicate directly with another network node with a different NetID. Within
an APPN subnetwork (which shares a common topology database), all NNs must
have the same NetID although ENs and LEN nodes can have any NetID they like.
An APPN border allows distinct subnetworks to establish sessions between each
other, but isolates the topologies to minimize the number of broadcast searches
and topology updates that flow. For more information and migration scenarios
on APPN borders, see Chapter 6, “Border Node Support” on page 115.
Border node support is sometimes referred to as APPN multiple network

connectivity support. It has several flavors and can be used in a number of
ways.
The first thing to remember is that there are two types of border (peripheral and
extended) and two types of border node (peripheral and extended). An extended
border requires two extended border nodes (EBNs); both EBNs share the
management of the border, and full support is available for the establishment of
any type of session. A peripheral border is managed by just one border node,
which can be an EBN or a peripheral border node (PBN). There are restrictions
on the establishment of sessions across a peripheral border, and even more
restrictions if it is managed by a PBN.
A peripheral border is formed between two NNs, where one (the border
manager) pretends to be an EN and the other takes no part in controlling the
border. Since an EN is allowed to have a different NetID from its NN server, this
works quite well. However:
• A peripheral border must be the first and/or the last border on a session
path. If a session crosses more than two network borders, all the ones in
the middle must be extended borders.
• A peripheral border managed by a PBN can be the only border on a session
path. Only two subnetworks can be connected in this manner.
• Because a peripheral border relies on one node having an EN appearance,
dependent LU sessions crossing such a border need session services
extensions support in both nodes. This means that both nodes must be
VTAM, so you might as well have an extended border with more function.

• The use of DLUR/S across network borders requires an EBN to be present at
certain points, even if the border it manages is peripheral. Please see
Chapter 6, “Border Node Support” on page 115 for details.
Peripheral border node support is specified in APPN option set 1014.
An extended border is formed between two NNs where both support the APPN
extended border node function, option 1016.
3.1.17.1 SNI and Border Node Considerations

If you have SNI boundaries, you should consider carefully whether each
connection is a candidate for conversion to an APPN border node connection.
First, is this an internal (intra-enterprise) SNI connection? If so, do you want to
keep the SNI definitions which are complex, but have been defined a long time
and are seldom changed? Or do you want to migrate this part of the network to
border node and reduce definitions? Another good reason for considering
conversion is that an APPN border can be established over any type of
connection, whereas an SNI boundary is always within an NCP.
Secondly, if this is an external SNI link to a trading partner, has the partner
migrated to APPN? If not, you must leave the connection as SNI. If the partner
does support APPN, do you want to change the SNI link to an APPN border node
connection? Remember that the APPN node on the partner′s side must also be
VTAM (or NCP, but not a 3746 or 2216, at the time of writing) if you want any
dependent LU sessions across the border.
Your SNI setup may include the use of VTAM′s session management exit and be
complicated by specific SNI GWNAU statements for security purposes.
Converting this to APPN may require a re-design of the code and the use of the
APPN directory services management exit (DSME) to enforce the same level of
security that you have already. The question is, can an APPN border do what
you already do with SNI?
3.1.17.2 Subnetting Using Border Node

You should seriously think about subnetting (dividing an existing network into
smaller pieces) if you have a large SNA subarea network that you are migrating.
Subnetting will allow you to limit TDUs and broadcast searches across your
network while retaining your existing NetID. You may also want to use
subnetting to partition your network for network management and administrative
reasons.
To subnet you must decide where you want your borders to be. You can choose
a different NetID or keep the same NetID throughout your network.
If your CMC is to be converted into an EBN, make sure that your takeover VTAM
ICN is also capable of EBN support by coding the same parameters in that
VTAM′s start options. This will allow it to take over border node connections
during takeover processing.
To turn on border node support in VTAM, specify BN=YES in the VTAM start
options of your chosen NN(s). There are a number of controls available to
customize your border node support:
1. VTAM start options
• BN=YES turns on border node functions for this VTAM NN.

• BNDYN specifies how much dynamic definition VTAM will use when
deciding on its cross-border search routing. VTAM uses adjacent cluster
tables (similar to adjacent SSCP tables) to do this, and BNDYN has
similar functions to SSCPDYN and DYNASSCP.
The options are NONE, LIMITED and FULL. Use NONE when you want
complete control over cross-border routing. Use LIMITED when you want
VTAM to make some sensible decisions based on NetID matches. Use
FULL sparingly, and only in small networks, because FULL may result in
excessive searching.
• BNORD has a similar effect to SSCPORD, but on the adjacent cluster
tables. BNORD=PRIORITY allows VTAM to reorder the tables based on
the success or failure of searches. BNORD=DEFINED leaves the table
entries in the same order.
• SNVC, which defaults to 3, limits searches to a given number of
networks. SNVC may be coded individually for each cluster table entry.
SNVC=1 means that a search will be confined to only one network
(SNVC defines the number of subnetworks on the search path, not the
number of borders).
• XNETALS is not new (as a start option or link station keyword), but its
defaults have changed. In VTAM V4R4 and above, APPN connections
always default to XNETALS=YES unless the XNETALS start option has
been coded as NO. For an APPN border XNETALS=YES is required.
• NETID (again not a new option) is always required in APPN, regardless of
whether a border is being used.
2. The N A T I V E = keyword on the PU or adjacent CP definition is used to force a
same NetID connection to be an APPN border. Use NATIVE=NO on an
NN-to-NN connection to do this. An NN-to-NN connection with differing
NetIDs will always become a border, provided of course that at least one of
the NNs has BN capability.
3. Adjacent cluster tables are used in the same way as adjacent SSCP tables to
define cross-border searching patterns. They are defined using VBUILD
TYPE=ADJCLUST members in VTAMLST.
Adjacent cluster tables allow you to define which adjacent APPN
subnetworks VTAM should search when looking for a partner resource. If
you have subnetted your network you should define an ADJCLUST table;
otherwise, VTAM will not search for resources in adjacent same-NetID
networks unless the BNDYN=FULL VTAM start option is in effect. The
following is an example which we have used in our migration scenario:

*******************************************************************
* *
* ADJCLUST TABLE FOR RAA *
* *
*******************************************************************
VBUILD TYPE=ADJCLUST
USIBMRA NETWORK NETID=LANNET1,
BNDYN=LIMITED,
SNVC=3
RA8CM2A NEXTCP CPNAME=RA8CM2A,
SNVC=1
Figure 17. Adjacent Cluster Table
Note: We must stress the importance of using an extended border wherever

possible, when connecting VTAM to other APPN subnetworks. A peripheral
border has many restrictions, most importantly relating to dependent LU
sessions. If you need an APPN border in a remote location away from VTAM, we
recommend the use of the branch extender function. This function (implemented
in Communications Server/2, 2216 and 2210) is similar to a peripheral border but
has some distinct advantages:
• It supports dependent LU sessions, since it implements DLUR within the
branch extender node.
• It allows CDS registration of resources across its boundary, which is not
possible across a peripheral or extended boundary.
See Chapter 6, “Border Node Support” on page 115 for some migration border
node scenarios.
3.1.18 Connection Networks

You should take advantage of the connection network function. A connection
network is a method of defining any-to-any connectivity between nodes
connected to the same shared access transport facility (SATF), such as a
token-ring or an ATM network.
To set up a connection network, an EN must define a connection to a virtual

node (VN) representing the SATF, as well as its connection to its NN server.
Since CP-CP sessions are used to determine that the session route passes
through the SATF, the EN-to-NNS connection must be predefined. All other
connections to nodes on the SATF can be safely left to the connection network
function. An NN must define the VN connection, plus connections to other NNs
where CP-CP sessions are required.
For example, you may have two ENs on a token-ring that wish to communicate
with each other. Without a connection network, the connection between them
would have to be predefined on at least one of them; otherwise all sessions
would be routed via their NN server. With a connection network they can
communicate directly without this extra definition.
A connection network can be defined in the following major nodes:

1. An NCP major node for token-ring links. Code VNNAME and VNGROUP on
the NTRI physical line definition statement. The VNNAME represents the CP
name of the virtual network node, and must be the same for all nodes that

share the connection network. The VNGROUP keyword specifies the name
of the logical peripheral line group containing dial-out links over which the
connections will be made.
2. An XCA major node (for LAN connections via a 3172 or an OSA). Code
VNNAME and VNGROUP on the PORT definition statement. The VNGROUP
keyword specifies the line group in this XCA definition over which the
connections will be made. Specify DIAL=YES and CALL=INOUT on the line
group definition to which the VNGROUP refers.
3. An XCA major node for an ATM network. Code the name of the virtual node
as the fourth operand on the DLCADDR(1) keyword in the switched
(DIAL=YES) GROUP statement on the port where the connection network is
to be defined.
In both cases you need DYNPU=YES (the default). A transmission group profile,
TGP, can be specified on the NTRI physical LINE and the XCA major node PORT
definition statements.
If your installation does not allow dynamic adjacent CP definition, you can
predefine the virtual node as an adjacent CP by coding VN=YES on the ADJCP
definition.
Connection networks cannot traverse network boundaries. A link between two

network nodes with different NetIDs must be defined and cannot be set up by
means of a connection network.
If a VTAM NN owns multiple TICs that are defined on the same connection
network, you may find that sessions from other nodes are distributed throughout
the TICs. Thus (for example) an end node with four parallel sessions to a VTAM
application may use four TICs, and therefore four logical lines. This obviously
has an impact on NCP storage. One way round this, if the VTAM NN is the NN
server of the nodes which are setting up these sessions, is not to define the NN
on the connection network. The links used for the CP-CP sessions have to be
predefined in any case, and the NN can still calculate routes between ENs across
the connection network.
3.1.19 Specifying Search Order Parameters for Subarea and APPN

Chapter 9, “Searching and Routing in a Mixed Subarea/APPN Network” on
page 151 discusses in detail the search algorithms used by VTAM in a mixed
subarea and APPN environment. In this section we summarize the main options
that you can specify to influence the searching.
We stated in Chapter 1, “Introduction” on page 1 that most existing large SNA

networks will not initially migrate fully to APPN but will have a mixture of
subarea and APPN networks. Because you may have combined networks, you
will want to specify the order in which VTAM searches for a resource.
A VTAM interchange node provides directory services for both APPN and
subarea networks. A VTAM migration data host can receive a request for a
search from a resource within its domain, and this request can be forwarded into
either the APPN or the subarea network. Thus each node type may have to
decide whether a given search request is forwarded into subarea or APPN, or
both, and in which order. VTAM provides options for you to use to control this
process.

3.1.19.1 The SORDER Start Option
This parameter is used for searches when a request is received from the
subarea network or from a resource within this VTAM′s subarea domain. For
searches originating in the APPN network the SORDER option has no effect.
SORDER can be specified in the following four ways:
1. SORDER=APPN. This is the default, which indicates that VTAM will search
APPN first unless the target resource is in the subarea directory (CDRSC
with another VTAM as owner). Essentially VTAM adds a dummy entry
ISTAPNCP to its adjacent SSCP tables, always at the head of the table. This
entry means “search the APPN network” rather than “search that VTAM”.
2. SORDER=SUBAREA. Most users will want to set SORDER=SUBAREA
initially, since many resources will still reside in the subarea network in the
early stages of migration. VTAM adds the dummy entry ISTAPNCP at the
end of each adjacent SSCP table.
3. SORDER=ADJSSCP. This option allows the installation the flexibility of
deciding exactly where the APPN network comes in the search order. You
must code the ISTAPNCP entry yourself, where you want it, in each table. If
there is no ISTAPNCP entry in a particular table then the APPN network will
not be searched. As an example, you might use SORDER=ADJSSCP if you
want your production subarea network searched first, then your APPN
network, followed by your development subarea network. See Figure 18 and
Figure 19, which show, respectively, a coded and displayed ADJSSCP table
with ISTAPNCP.
*******************************************************************
* *
* ADJSSCP TABLE FOR RAA *
* *
* *
*******************************************************************
VBUILD TYPE=ADJSSCP
RAK ADJCDRM
ISTAPNCP ADJCDRM
RAS ADJCDRM
Figure 18. ADJSSCP Table with ISTAPNCP Entry
* RAAAN D NET,ADJSSCPS,E

′ RAAAN
IST350I DISPLAY TYPE = ADJACENT SSCP TABLE
IST623I DEFAULT ADJACENT SSCP TABLE
IST624I RAK
IST624I ISTAPNCP
IST624I RAS
IST1454I 3 RESOURCE(S) DISPLAYED
IST314I END

Figure 19. ADJSSCP Table Display with ISTAPNCP Entry
4. SORDER=APPNFRST. This forces APPN to be searched first, even if VTAM

has a subarea CDRSC for the resource which shows a valid VTAM owner.

This option is recommended when, for example, you need an HPR (and
therefore an APPN) connection under all possible circumstances.
A new parameter on the D NET,ADJSSCPS command allows the user to discover

the search order for a specific resource. D NET,ADJSSCPS,CDRSC=nnnnnnnn will
show an adjacent SSCP list, complete with ISTAPNCP if applicable, with the
order of search for that resource.
If SSCPORD=PRIORITY (the default) is in effect, VTAM will reorder adjacent

SSCP tables according to the success or failure of searches. The APPN entry
ISTAPNCP takes part in this reordering process just as any other SSCP name.
3.1.19.2 The SSEARCH Start Option

This parameter controls whether a search request originating in the APPN
network is forwarded to the subarea network. Unlike SORDER, this is valid on
an interchange node only.
1. SSEARCH=YES is the default. The subarea network will be searched.
2. SSEARCH=NO specifies that the subarea network should not be searched.
3. SSEARCH=CACHE. If this is coded, then VTAM will search the subarea
network provided it has good reason to believe that the resource can be
found there. “Good reason” means that VTAM has a subarea CDRSC which
is either predefined, or where the VTAM owner has been identified on a
successful search.
4. SSEARCH=APPNFRST. This is the same as SSEARCH=YES (the subarea
network is searched), but the whole APPN network is always searched first.
Normally the subarea network is searched in between the APPN directory
check and the full broadcast search.
It is recommended that you code (or allow to default) SSEARCH=YES in the
initial stages of migration. This will allow a search request to continue into the
subarea network if the search has not found the resource in the APPN network.
3.1.19.3 The CDRSCTI Start Option

The CDRSCTI start option, which controls the aging of dynamically defined
CDRSCs, is set by default to eight minutes. Since the presence of a CDRSC has
a major effect on VTAM′s search algorithms, it may be necessary to increase
this time in order to minimize the potential for unnecessary broadcasts of the
APPN network. The maximum value allowed is eight days.
3.1.19.4 Adjacent SSCP Tables

Adjacent SSCP processing and definition has changed slightly since its initial
inception with SNI in 1984. From VTAM V4R2 onwards it is now possible to
define five types of adjacent SSCP tables which are used to help VTAM locate
resources. The following five types are included here for reference purposes:
1. Default table for all networks. It follows the VBUILD, or a NETWORK
statement with no NETID coded.
2. Default ADJCDRM list for a specific network. It follows a NETWORK
statement with NETID coded.
3. CDRM specific list with no NetID. It follows the CDRM statement which has
no NETID specified.
4. CDRM specific list with a specific NetID. It follows the CDRM statement with
an associated NETID specified.

5. ADJLIST of adjacent SSCPs. ADJLIST is coded in a CDRSC statement. It
specifies the name of the ADJLIST definition statement which contains the
list of adjacent SSCPs to be used for all session requests for this CDRSC.
Note that the use of an ADJLIST for a given CDRSC overrides all other
search options for that particular resource.
3.1.20 Search Reduction Parameters

Introduced with VTAM V4R2 are new parameters to reduce searches of the
network and improve network performance. These parameters allow VTAM to
prohibit exhaustive searches for resources that do not exist in the network.
Although they apply to both subarea and APPN networks, we recommend that
they are considered seriously for an APPN migration because of APPN′s greater
potential for extensive searching.
With search reduction, the user can specify the number of requests that will be
denied once a search target has been determined to be unreachable
(SRCOUNT), and/or specify a timer value (SRTIMER) reflecting a period of time
during which VTAM will deny session requests for that resource. If the network
had just been started and all of the 10,000 LUs tried to log on to a nonexistent
resource, carefully chosen search reduction parameters could make VTAM send
out just one search instead of 10,000. The three new parameters are as follows:
1. SRCHRED. This enables search reduction. The default is OFF.
2. SRCOUNT. The default for this is 10 (VTAM suppresses ten searches before
trying to locate the target again). For larger networks, this can be increased
to 1000 but will vary depending on your individual network configuration.
This is a parameter to watch after APPN migration.
3. SRTIMER. This defaults to 30 seconds (VTAM suppresses searches for 30
seconds before trying to locate the target again). As for SRCOUNT, the
optimum value varies depending on your network size.
All three search reduction options can be changed dynamically using the F
netproc,VTAMOPTS command.
3.1.21 Summary of VTAM Start Options

This section lists the VTAM start options you should review prior to migration,
and after initial testing. Many of these parameters have been discussed in
previous sections.
3.1.21.1 Initial VTAM Start Options

Most of the APPN start options will default very well. Others you have to check.
The following is a list of parameters which require initial attention:
• APPNCOS
• CONNTYPE
• CPCP
• DYNADJCP
• DYNLU
• HOSTSA
• INITDB
• ISTCOSDF
• NETID
• NODETYPE
• SSCPNAME

• VRTG
• VRTGCPCP
• XNETALS
3.1.21.2 Post-Initial Testing Start Options

The following parameters will require attention after the initial testing phase:
• APPNCOS
• AUTHLEN
• CACHETI
• CDRSCTI
• CDSERVR
• CDSREFER
• CONNTYPE
• DIRSIZE
• DIRTIME
• INITDB
• ISTCOSDF
• NUMTREES
• SRCHRED
• SRCOUNT
• SRTIMER
3.1.21.3 Multi-Domain Migration Start Options

For multi-domain migration sites, check the following parameters:
• HOSTSA
• SORDER
• SSEARCH
3.1.21.4 Multi-Network Start Options

These options need addressing if you decide to implement APPN borders:
• BN
• BNDYN
• BNORD
• SNVC
3.1.21.5 Advanced Options

Some options which cover advanced tuning and security are:
• SECLVLCP
• VERIFYCP
• NUMTREES
• RESUSAGE
• ROUTERES

3.2 Migration Checklist
Migration Checklist
Task Reference Check
VTAM/NCP software upgrades 3.1.1, “VTAM/NCP Software

Upgrades” on page 26
VTAM/NCP and APPN node roles 3.1.2, “VTAM/NCP and APPN

Node Roles” on page 26
Naming conventions 3.1.3, “Naming Conventions” on

page 30
Using the 3746 Model 9X0 3.1.4, “IBM 3746 Model 900 and
Model 950 APPN Migration” on
page 34
Checking existing switched LEN connections 3.1.5, “Checking Existing

Switched LEN Connections” on
page 34
Dynamically defining switched resources 3.1.6, “Dynamically Defining

Switched Resources” on
page 35
APPNCOS table requirement 3.1.7, “APPNCOS Start Option

and Table” on page 36
IBMTGPS profile requirement 3.1.8, “Transmission Group

Profiles” on page 37
ISTINCLM and user-defined logmode tables requirement 3.1.9, “ISTINCLM and

User-Defined Logmode Table
Requirement” on page 38
Multipath channel (MPC) conversion prior to APPN migration 3.1.10, “Multipath Channel
Conversion” on page 39
Multipath channel (MPC) conversion for ANNC 3.1.11, “Multipath Channel

Conversion for APPN” on
page 40
APPN node roles and connectivity 3.1.12, “APPN Node Roles and
Connectivity” on page 43
Checking your session pools 3.1.13, “Checking Your NCP

Buffer Pools” on page 43
Specifying adjacent CP names 3.1.14, “Specifying Adjacent CP

Names” on page 44
Topology reporting for switched connections 3.1.15, “Topology Reporting for

Switched Connections” on
page 45
Setting up a central directory server 3.1.16.1, “Setting up a Central

Directory Server” on page 46
Registering resources with NNS and CDS 3.1.16.2, “ R e g i s t e r i n g

Resources” on page 47
Setting up a network node server list 3.1.16.3, “Network Node Server

List” on page 48
SNI and border node considerations 3.1.17.1, “SNI and Border Node
Considerations” on page 50
Subnetting using border node 3.1.17.2, “Subnetting Using

Border Node” on page 50
Setting up connection networks 3.1.18, “Connection Networks”

on page 52
Setting the SORDER start parameter 3.1.19.1, “The SORDER Start

Option” on page 54
Setting the SSEARCH start parameter 3.1.19.2, “The SSEARCH Start


Task Reference Check
Setting the CDRSCTI start parameter 3.1.19.3, “The CDRSCTI Start

Search reduction parameters 3.1.20, “Search Reduction

Parameters” on page 56

Chapter 4. Migrating a CMC Host to ICN
Once all the planning for the design of the mixed APPN and subarea network
has been completed, we can begin the migration.
The test network has been described in previous chapters, but for convenience it
has been drawn again in Figure 20. VTAM RAA, which is also the CMC host in
the subarea network, will be converted to an interchange node. By creating an
interchange node, we introduce the option of establishing an APPN connection
with any APPN-capable node while maintaining the current subarea
configuration. An ICN is necessary in the network, since only an ICN can load
and activate an NCP and also establish SNI links to external subarea networks.
The CMC host must be migrated to an ICN before migrating any data host to an
MDH or an EN.
Under a subarea network, the CMC host being the focal point of the network is
normally the target adjacent SSCP for network searches. On the same grounds,
the ICN is the focal point in an APPN network and thus should be the central
directory server for an APPN network. Thus, the VTAM RAA host will also
provide the central directory server function for our network.
As mentioned before, we make the RAA node APPN-capable but it will still use
subarea protocols for session establishment in the subarea part of the network.
Figure 20. Mixed APPN/SA Network

4.1 VTAM Definitions for ICN
Before starting the CMC host VTAM as an interchange node, we have to code
the VTAM APPN-related start options, allocate and catalog the APPN network
topology and directory databases, and copy the APPN class of service
(COSAPPN) and TG profile (IBMTGPS) members from SYS1.SAMPLIB into our
VTAMLST data set.
4.1.1 APPN-Related Start Options

Code the additional new VTAM APPN-related start options seen in Figure 21 in
order to make the CMC APPN-capable. A brief description of the APPN-related
start options, with defaults highlighted, is given in Appendix B, “VTAM APPN
and APPN-Related Start Options” on page 197. You may want to use the
defaults or decide on the values depending on the type of your environment.
APPNCOS=#CONNECT 8
CDSERVR=YES, 3
CONNTYPE=LEN, 2
CPCP=YES, 4
DIRSIZE=0, 1 10 DEFAULT
DIRTIME=8D, 1 DEFAULT
DYNADJCP=YES, 1 9 DEFAULT
HPR=NONE, 5
HOSTSA=10, 6
INITDB=ALL, 1 DEFAULT
NODETYPE=NN, 6
NUMTREES=100, 1 DEFAULT
RESUSAGE=100, 1 DEFAULT
ROUTERES=128, 1 DEFAULT
SSCPNAME=RAA, 7 SSCPNAME/CPNAME
SORDER=SUBAREA, 11
SSEARCH=YES, 1 DEFAULT
Figure 21. VTAM Start Options for ICN
Notes:
1These start options will default to these values if not coded. In our test, we
coded them for clarity.
2CONNTYPE=APPN is the default only if NODETYPE= is coded. If you let this

default or code it as APPN, then the XID rules for parallel TGs are enforced. In
other words, two TGs to the same CP name are assumed to be to the same CP.
So, if you have nodes with duplicate CP names, you should make them unique
before this node becomes an APPN node.
In our test, we used CONNTYPE=LEN as a migration step to specify that the

connections are established as LEN connections as opposed to APPN. CP-CP
sessions are not supported in this case and VTAM does not check for duplicate
CPNAMEs. This environment is similar to subarea.
3Code CDSERVR=YES to make the ICN a central directory server.

CDSERVR=NO is the default.

4CPCP=YES must be coded, or overridden at the PU level, to allow CP-CP
sessions to be established on any APPN connections. The default is LEASED
which prevents CP-CP session establishment over switched links (of which we
have some examples). CPCP=YES does not, of course, apply to LEN
connections.
5HPR=NONE must be coded if you do not want VTAM to provide HPR support.
HPR=RTP is the default for all VTAM APPN nodes from V4R4 onwards.
HPR=NONE is usually safe and will make problem determination easier in the
initial stages of migration. However, it will prevent the establishment of HPDT
connections such as XCF (sysplex Cross-System Coupling Facility), and MPC to a
2216. We coded HPR=NONE initially, but a better plan may be to let HPR=RTP
default and override it individually on non-HPDT connections until you are happy
that the connections work correctly.
6Both HOSTSA and NODETYPE=NN start options are required for VTAM to act
as an interchange node.
7SSCPNAME is used as the CP name of this VTAM. VTAM′s CP is an

additional LU, with the same name as the SSCP, that is used to establish CP-CP
sessions as well as performing other CP functions.
8Specify a value for APPNCOS, which will be used as a default APPN class of
service if a requested class of service cannot be found in the topology and
routing services class-of-service database. APPNCOS=NONE is the default
value. We recommend that you run with APPNCOS=NONE until problems are
encountered; then dynamically change to APPNCOS=#CONNECT until problems
are resolved, then switch back to NONE. Otherwise, you might end up routing all
sorts of unknown session traffic over the same links and performance will be
affected.
9If DYNADJCP is specified as NO, then an ADJCP definition must be created

for each adjacent control point (CP). Otherwise, the link activations and CP-CP
sessions will fail.
10The DIRSIZE default of 0 means no limit is assigned for the maximum

number of dynamic APPN resources stored in the VTAM directory services
database. If you have a large network, then it is advisable to limit the size of the
directory services database at non-CDS NNs. VTAM enforces a minimum of 1000
entries.
11The SORDER start option controls the order in which the APPN and subarea
networks are searched when a search request for an unknown LU is received at
this node from the subarea network. SORDER=APPN (the default value)
specifies that the APPN network is to be searched first (or almost first - see
Chapter 9, “Searching and Routing in a Mixed Subarea/APPN Network” on
page 151). Specify SORDER=SUBAREA or ADJSSCP initially, to ensure that the
subarea network is searched early on in the algorithm. This will ensure that the
operation is as close as possible to the subarea case, in the early stages of
migration. If you code SORDER=ADJSSCP you must also modify your adjacent
SSCP tables, as described in Chapter 9.
Chapter 4. Migrating a CMC Host to ICN 63

4.1.2 APPN Network Topology and Directory Databases
Allocate and catalog the following VTAM data sets before VTAM initialization,
and add DD statements for these data sets in the VTAM start procedure. See
3.1.16.1, “Setting up a Central Directory Server” on page 46 for more
information.
• SYS1.DSDB1
• SYS1.DSDB2
• SYS1.TRSDB
• SYS1.DSDBCTRL
SYS1.DSDB1 and SYS1.DSDB2 contain APPN directory information which is used

to initialize the directory database when VTAM is restarted.
SYS1.TRSDB is required for checkpointing the network topology database. The

information in this data set is used to initialize the network topology database
whenever VTAM is restarted.
SYS1.DSDBCTRL contains the current status of SYS1.DSDB1 and SYS1.DSDB2. It

is read by VTAM during initialization to determine whether SYS1.DSDB1 or
SYS1.DSDB2 will be used to load the APPN directory database.
The first time VTAM is started with these new data sets, and the INITDB start
option is set to ALL or TOPO, the following VTAM message will be received:
IST1288I TOPOLOGY DATASET RETRIEVAL WAS NOT SUCCESSFUL, CODE = 9
This is normal because nothing was saved in the data sets.
When the checkpoint operation occurs, if there are no cache entries to

checkpoint the following VTAM messages will be received:
IST1122I CHKPT TO DATASET DSDB2 WAS NOT SUCCESSFUL, CODE= 7
IST1123I MODIFY CHKPT TO DATASET TRSDB WAS SUCCESSFUL
The only entries that VTAM saves in the directory checkpoint data set are
dynamic entries. These are entries which have been made as a result of a
successful search, whether from this NN (which saves the target LU location) or
to this NN (which saves the origin LU location). Directory entries registered to a
CDS (but not an NNS) are also regarded as dynamic.
Note: If you only have one NN in your network, there is no need to checkpoint
as there will be no network searches.
4.1.3 APPN Class of Service and TG Profiles

Copy the COSAPPN and IBMTGPS files from SYS1.SAMPLIB into your VTAMLST.
COSAPPN contains the default APPN classes of service and is required if VTAM
is configured as an APPN node. IBMTGPS contains the default TG profiles.
Although this file is not required, it is strongly recommended that you include
this in VTAMLST. It makes the definition of APPN TG characteristics much
easier.
By default, a blank subarea COS (and therefore a low transmission priority) will
be used for CP-CP sessions that traverse subarea VRs. This applies also to
DLUR/DLUS control sessions. Therefore, we recommend that:

• You update your mode table entries for CPSVCMG and CPSVRMGR with an
appropriate COS value such as ISTVTCOS. The IBM-supplied table
ISTINCLM does not include these, so it will need updating if it is the one you
use for these mode names. CPSVCMG is used for CP-CP sessions and
CPSVRMGR is used for DLUR/DLUS sessions.
• You apply APAR OW26928 which adds COS=ISTVTCOS to the session
requests received by the VTAM CP as SLU. Adding subarea COS entries as
above only affects the CONWINNER (CP as PLU) sessions.
A copy of the default APPN COS table supplied by IBM is shown in VTAM
Resource Definition Reference , SC31-8565.
4.2 Migration Results

This first stage of migration actually comprises two phases. First we restart the
CMC VTAM as an ICN and a CDS, without converting any of the LEN connections
to APPN. We specify the VTAM start option CONNTYPE=LEN instead of
CONNTYPE=APPN. This allows all of the APPN-capable adjacent nodes to be
treated as LEN devices, which is how they are treated when VTAM is a subarea
node.
The second phase is to migrate each device, individually, from LEN to APPN
connection by specifying CONNTYPE=APPN on the link station (PU) definition of
the device on the host. You could opt to merge the two phases together,
depending on the size of your network, by specifying CONNTYPE=APPN as a
VTAM start option. The CONNTYPE value on the PU statement will default to
APPN. This will result in all of the APPN-capable devices behaving as APPN
nodes in one step instead of individually. We advise that you proceed with care.
4.2.1 Convert Node to ICN

We start VTAM with NODETYPE=NN and CONNTYPE=LEN in the start options.
We display the VTAM APPN-related start options on RAA, as shown in Figure 22
on page 66.

d net,vtamopts,function=appnchar

IST097I DISPLAY ACCEPTED
IST1188I ACF/VTAM V4R3 STARTED AT 17:16:05 ON 11/07/95
IST1349I COMPONENT ID IS 5695-11701-301
IST1348I VTAM STARTED AS INTERCHANGE NODE
IST1189I APPNCOS = #CONNECT BN = NO
IST1189I BNDYN = ***NA*** BNORD = ***NA***
IST1189I CDSERVR = YES 1 CDSREFER = ***NA***
IST1189I CONNTYPE = LEN 2 CPCP = YES 3
IST1189I DIRSIZE = 0 DIRTIME = 691200S
IST1189I DYNADJCP = YES HPR = NONE
IST1189I HPRPST = LOW 60S HPRPST = MEDIUM 60S
IST1189I HPRPST = HIGH 60S INITDB = ALL
IST1189I IOPURGE = 0 NODETYPE = NN 4
IST1189I NUMTREES = 100 RESUSAGE = 100
IST1189I ROUTERES = 128 SECLVLCP = ***NA***
IST1189I SNVC = ***NA*** SORDER = SUBAREA
IST1189I SRCHRED = OFF SRCOUNT = 10
IST1189I SRTIMER = 30S SSEARCH = YES
IST1189I VERIFYCP = NONE VFYRED = YES
IST1189I VFYREDTI = OFF VRTG = NO
IST1189I VRTGCPCP = YES
IST314I END

Figure 22. Display of APPN-Related VTAM Start Options
Notes:
1Shows that this network node is a central directory server.
2Shows that connections will be established as LEN by default.
3Shows that this APPN node supports CP-CP sessions with adjacent nodes.
4Shows that this node is an APPN network node.
We issue the DISPLAY MAJNODES command, with the result seen in Figure 23
on page 67.

* RAAAN D NET,MAJNODES

′ RAAAN
IST350I DISPLAY TYPE = MAJOR NODES
IST089I VTAMSEG TYPE = APPL SEGMENT , ACTIV
IST089I ISTPUSA0 TYPE = PU T4/5 , ACTIV
IST089I ISTPDILU TYPE = CDRSC SEGMENT , ACTIV
IST089I ISTADJCP TYPE = ADJCP MAJOR NODE , ACTIV
IST089I ISTCDRDY TYPE = CDRSC SEGMENT , ACTIV
IST089I ISTDSWMN TYPE = SW SNA MAJ NODE , ACTIV
IST089I RAAATSO TYPE = APPL SEGMENT , ACTIV
IST089I RAAANETV TYPE = APPL SEGMENT , ACTIV
IST089I RAACDRM TYPE = CDRM SEGMENT , ACTIV
IST089I RAACDILU TYPE = CDRSC SEGMENT , ACTIV
IST089I RAACTCA TYPE = CA MAJOR NODE , ACTIV
IST089I RAAMPC1 TYPE = CA MAJOR NODE , ACTIV
IST089I RAALCL1 TYPE = LCL SNA MAJ NODE , ACTIV
IST089I RAAXCA1 TYPE = XCA MAJOR NODE , ACTIV
IST089I RAASWMN1 TYPE = SW SNA MAJ NODE , ACTIV
IST089I RAAVM TYPE = LCL 3270 MAJ NODE, ACTIV
IST089I RA8NCPX TYPE = PU T4/5 , ACTIV
IST089I RA5NCPX TYPE = PU T4/5 , ACTIV
IST1454I 23 RESOURCE(S) DISPLAYED
IST314I END

Figure 23. Display of VTAM Major Nodes
Note that the major node ISTRTPMN for RTP is not part of the above list. This is
because, in VTAM V4R3, an ICN could not act as an RTP endpoint. This
restriction was removed in VTAM V4R4.
As expected, no APPN connections or CP-CP sessions have been established

with adjacent PCs or 3174s configured as APPN nodes. The DISPLAY TOPO
command can be used to find out what CP-CP sessions are active. Figure 24
shows that there is only one NN, one ICN and one CDS (actually, these are all
this VTAM) as seen by RAA, but there are no adjacent CPs 1 so there cannot
possibly be any CP-CP sessions. Because CONNTYPE=LEN has been coded, all
the adjacent connections are seen by VTAM as LEN and the true nature of the
attached nodes is not known by VTAM′s topology and routing component.
* RAAAN D NET,TOPO

′ RAAAN
IST1306I LAST CHECKPOINT ADJ NN EN SERVED EN CDSERVR ICN BN
IST1307I NONE 1 0 1 0 0 1 1 0
IST314I END

Figure 24. Display of Topology Summary
Figure 25 on page 68 shows the display of the topology with LIST=NN,

LIST=CDSERVR, and LIST=ICN, which provides more information on the
individual APPN nodes. Note that the display shows RAA as the only NN, CDS
and ICN in the network.

* RAAAN D NET,TOPO,LIST=NN

′ RAAAN
IST1296I USIBMRA.RAA NN 128 NONE *NA* *NA*
IST314I END
* RAAAN D NET,TOPO,LIST=CDSERVR
′ RAAAN
IST314I END
* RAAAN D NET,TOPO,LIST=ICN
′ RAAAN
IST314I END

Figure 25. Display of Topology with L I S T = N N , LIST=CDSERVR, L I S T = I C N
We establish TSO sessions from a CM/2 node defined as an EN with RAA as its
NNS, as well as from a CM/2 node defined as a LEN node. Dependent LU-LU
sessions are established, but no CP-CP sessions are established with VTAM by
either node. The end node is capable of establishing CP-CP sessions, but
because VTAM has CONNTYPE=LEN specified it declares at connection setup
time that such sessions are not acceptable.
We display the PU and link station RAATRPU4, and a dependent LU RAATLU44,

for one of these CM/2 machines, as shown in Figure 26 and Figure 27 on
page 69. VTAM sees no difference between CM/2 nodes defined as ENs or NNs,
because VTAM sees them both as LEN nodes. The displays are the same as
before conversion.
* RAAAN D NET,ID=RAATRPU4,E

′ RAAAN
IST1043I CP NAME = CP05137 , CP NETID = USIBMRA , DYNAMIC LU = NO
IST080I RAATLU42 ACTIV RAATLU43 ACTIV RAATLU44 ACT/S
IST314I END

Figure 26. Display of CM/2 PU

* RAAAN D NET,ID=RAATLU44,E

′ RAAAN
IST075I NAME = USIBMRA.RAATLU44 , TYPE = LOGICAL UNIT
IST486I STATUS= ACT/S , DESIRED STATE= ACTIV
IST1447I REGISTRATION TYPE = NETSRVR
IST977I MDLTAB=***NA*** ASLTAB=***NA***
IST861I MODETAB=ISTINCLM USSTAB=US327X LOGTAB=***NA***
IST934I DLOGMOD=D4C32XX3 USS LANGTAB=***NA***
IST597I CAPABILITY-PLU INHIBITED,SLU ENABLED ,SESSION LIMIT 00000001
IST135I PHYSICAL UNIT = RAATRPU4
IST082I DEVTYPE = LU
IST171I ACTIVE SESSIONS = 0000000001, SESSION REQUESTS = 0000000000
IST206I SESSIONS:
IST634I NAME STATUS SID SEND RECV VR TP NETID
IST635I RASAT01 ACTIV-P F627D164E40DE7C6 1 0 USIBMRA
IST314I END

Figure 27. Display of CM/2 LU
The display of the 3174 configured as an APPN NN (PU name P3174C1) is shown
in Figure 28. Once again, VTAM perceives this as a LEN connection.
* RAAAN D NET,ID=P3174C1,E

′ RAAAN
IST075I NAME = P3174C1 , TYPE = PU_T2.1
IST1043I CP NAME = CP31742 , CP NETID = USIBMRA , DYNAMIC LU = YES
IST081I LINE NAME = L3174C1 , LINE GROUP = RA5GSFL0, MAJNOD = RA5NCPX
IST080I RA317411 ACTIV RA317C12 ACTIV RA317C13 ACTIV
IST080I RA317C14 ACTIV
IST314I END

Figure 28. Display of the 3174 Link Station/PU
4.2.2 Convert Links to APPN

We now activate the APPN function for each device individually by specifying
CONNTYPE=APPN on the PU definition in the host, rather than start VTAM with
CONNTYPE=APPN.
4.2.3 3174 as an NN
In our test environment, the 3174-11L (PU name RAALCLP) and the remote
token-ring attached 3174-63R (PU name RAATRPU1) are left as type 2.0 devices.
The remote SDLC-attached 3174-11R (link station name P3174C1) is configured
as an APPN network node, and VTAM is told to treat the connection as APPN.
Figure 29 on page 70 shows the network diagram with the 3174s and their PU
names and CP names, where applicable, and can be used as a reference.

Figure 29. ICN/CNN with 3174s
The APPN function in the 3174 has been enabled by responding to Question 510
with 1, as shown in Figure 30. Question 511 defines the 3174′s CP name.
Question 512 allows you to define a connection network on this 3174, so that
nodes on the LAN need not define the link to the 3174 unless it is their NN
server.
________________ Common SNA ________________

500 - 0 501 - USIBMRA 502 - ________
APPN Support Fields:
510 - 1 511 - CP31742 512 - VN31742

Figure 30. Configuration Panel on 3174-11R
Note: For channel-attached 3174s, Question 242 has to be answered with a 1 as

well. This is to enable the shared type 2.0/2.1 link support.
VTAM Definitions: To activate the APPN support in VTAM, CONNTYPE=APPN is

coded on the PU statement for the 3174 in the NCP (see 1 in Figure 31 on
page 71). XID=YES is required 2 because it defaults to NO for a leased
connection.

P3174C1 PU ADDR=C1, POLL ADDRESS = C1
CONNTYPE=APPN, 1
DATMODE=HALF, HALF DUPLEX
MAXDATA=265, MAXIMUM AMOUNT OF DATA
MAXOUT=7, MAX SDLC FRAMES BEFORE RESPONSE
PACING=0, PACING SET BY BIND IMAGE
PASSLIM=8,
PUDR=YES,
PUTYPE=2,
RETRIES=(,4,5),
DISCNT=(NO), (V) VTAM
ISTATUS=ACTIVE, (V) VTAM
SSCPFM=USSSCS, (V) VTAM
USSTAB=US327X, (V) VTAM
MODETAB=AMODETAB,
DLOGMOD=M2SDLCQ,
XID=YES, 2 FOR T2.1 NODE (LEN)
DYNLU=YES,
VPACING=0 (V) VTAM
Figure 31. NCP Definitions for 3174-11R
Session Setup: When the NCP major node is recycled to effect the change
(changing XID= requires an NCP generation), the following messages are
issued to indicate that an APPN connection and CP-CP sessions have been
established:
IST1086I APPN CONNECTION FOR USIBMRA.CP31742 IS ACTIVE - TGN = 21

IST1096I CP-CP SESSIONS WITH USIBMRA.CP31742 ACTIVATED

Figure 32. APPN Connection Establishment
Note: This group of messages will be issued for all APPN connections
established with CP-CP sessions. If no CP-CP sessions are established, then
only message IST1086I will be issued.
Various VTAM displays can be used to verify whether CP-CP sessions have been
established. A display of the CP name CP31742 in Figure 33 on page 72 shows
a number of interesting points.
CP31742 is an adjacent CP 1, just as it would be if LEN connected. However, it

is now also a dynamically defined CDRSC as seen at 2 (status modifier -----Y)
and 5 (in major node ISTCDRDY), as well as an independent LU 8. It is both
these things because it has established two sessions 9 with its partner CP,
RAA. One of these sessions has RAA as the PLU and one as the SLU. The
logmode used by default is CPSVCMG 4, which also specifies the COS name
CPSVCMG.
The two CP-CP sessions are using the adjacent link station P3174C1 10, which
has the same name as the PU. However, the ALSLIST 7, which is the list of
link stations VTAM will use to find this resource if it receives a session request,
does not include P3174C1. This is because CP31742 is an APPN node and must
be found using APPN mechanisms, not by a predefined connection. The notation
ISTAPNPU 7 signifies to VTAM that it must use APPN to find the location of
CP31742.

Since CP31742 is an NN CP, it has no network node server as seen at 6. Being
a CDRSC it has not been registered anywhere by this VTAM 3. By default,
only applications and dependent LUs are registered; contrast this display with
that of a VTAM owned dependent LU in Figure 27 on page 69.
As well as being seen as a CDRSC / ILU to the subarea side of VTAM, CP31742
is also in the APPN directory 11. It is known there as a “dynamic NN” entry
12, since it was neither predefined in VTAM nor registered with it. Its location
has been discovered dynamically.
* RAAAN D NET,ID=CP31742,E

′ RAAAN
IST075I NAME = USIBMRA.CP31742 , TYPE = ADJACENT CP 1
IST486I STATUS= ACT/S----Y, DESIRED STATE= ACTIV 2
IST1447I REGISTRATION TYPE = NO 3
IST1333I ADJLIST = ***NA***
IST861I MODETAB=***NA*** USSTAB=***NA*** LOGTAB=***NA***
IST934I DLOGMOD=CPSVCMG USS LANGTAB=***NA*** 4
IST597I CAPABILITY-PLU ENABLED ,SLU ENABLED ,SESSION LIMIT NONE
IST231I CDRSC MAJOR NODE = ISTCDRDY 5
IST1184I CPNAME = USIBMRA.CP31742 - NETSRVR = ***NA*** 6
IST1044I ALSLIST = ISTAPNPU 7
IST082I DEVTYPE = INDEPENDENT LU / CDRSC 8
IST171I ACTIVE SESSIONS = 0000000002, SESSION REQUESTS = 0000000000 9
IST206I SESSIONS:
IST1081I ADJACENT LINK STATION = P3174C1 10
IST635I RAA ACTIV/CP-S EE4B79FF13F208DF 0018 0001 0 0 USIBMRA 9
IST635I RAA ACTIV/CP-P F7FF6164D39CEBE3 0001 002C 0 0 USIBMRA
IST924I -------------------------------------------------------------
IST075I NAME = USIBMRA.CP31742 , TYPE = DIRECTORY ENTRY 11
IST1186I DIRECTORY ENTRY = DYNAMIC NN 12
IST314I END

Figure 33. Display of 3174 CPNAME CP31742
The display of the 3174 link station in Figure 34 on page 73 is equally

interesting. It shows 1 that the connection has been reported to the APPN
topology database (AC/R), that the TG number is 21, and that the TG
characteristics are that long string of hex in IST1106I. There are easier ways of
displaying the TG characterictics: use DISPLAY TOPO.
Figure 34 on page 73 also shows that HPR is not active 2 and that the 3174′ s
CP is in session 3.

* RAAAN D NET,ID=P3174C1,E

′ RAAAN
IST075I NAME = P3174C1 , TYPE = PU_T2.1
IST1043I CP NAME = CP31742 , CP NETID = USIBMRA , DYNAMIC LU = YES
IST1106I P3174C1 AC/R 21 YES 982D0000000000000000017100808080 1
IST1482I HPR = NO - OVERRIDE = N/A - CONNECTION = NO 2
IST081I LINE NAME = L3174C1 , LINE GROUP = RA5GSFL0, MAJNOD = RA5NCPX
IST080I RA317411 ACTIV RA317C12 ACTIV RA317C13 ACTIV
IST080I RA317C14 ACTIV
IST080I CP31742 ACT/S----Y 3
IST314I END

Figure 34. Display of 3174 Link Station P3174C1
Figure 35, Figure 36 on page 74 and Figure 37 on page 74 show the NetView
Session Monitor displays of the 3174 CP-CP sessions.
NLDM.SESS PAGE 1

SESSION LIST
NAME: CP31742 DOMAIN: RAAAN
------------------------------------------------------------------------------
***** PRIMARY ***** **** SECONDARY ****
SEL# NAME TYPE DOM NAME TYPE DOM START TIME END TIME
( 1) RAA CP RAAAN CP31742 CP RAAAN 11/16 18:16:53 *** ACTIVE ***
( 2) CP31742 CP RAAAN RAA CP RAAAN 11/16 18:16:52 *** ACTIVE ***

Figure 35. NLDM List of Sessions between RAA and CP31742

NLDM.CON SESSION CONFIGURATION DATA PAGE 1

-------------- PRIMARY ---------------+-------------- SECONDARY --------------
NAME RAA SA 000A EL 00000007 | NAME CP31742 SA 0005 EL 000000E8
--------------------------------------+---------------------------------------
DOMAIN RAAAN PCID USIBMRA.RAA.F7FF6164D39CEBE3 DOMAIN RAAAN
+-------------+ +-------------+
RAA | CP | --- --- | CP | CP31742
+-------------+ APPN TP 03 +-------------+
SUBA TP 00
VR 00
ER 00
RER 00
APPNCOS CPSVCMG 4

SUBACOS N/A
LOGMODE CPSVCMG 4
PADJ CP N/A
SADJ CP CP31742

Figure 36. NLDM Display of CP Session 1

NAME CP31742 SA 0005 EL 000000E9 | NAME RAA SA 000A EL 00000008
--------------------------------------+---------------------------------------
DOMAIN RAAAN PCID USIBMRA.CP31742.EE4B79FF13F208DF DOMAIN RAAAN
+-------------+ +-------------+
CP31742 | CP | --- --- | CP | RAA
+-------------+ +-------------+
SUBA TP 00
VR 00
ER 00
RER 00
APPNCOS N/A
SUBACOS N/A
LOGMODE CPSVCMG 4
PADJ CP CP31742
SADJ CP N/A

Figure 37. NLDM Display of CP Session 2
Note that the mode and APPN COS used here are both CPSVCMG 4. This is
required for, and unique to, CP-CP sessions. The APPN COS for the CONLOSER
session is not relevant to RAA because the 3174 chose it and calculated the
route.
In general, it is recommended that a 3174 defined as an NN should be isolated

using the border node function. This is because we do not want it to exchange
topology information in the network. The 3174 has limited storage and cannot
handle the topology database for a large APPN network. To define the
connection to the 3174 as a cross-border connection, code NATIVE=NO on the

PU definition or change the NetID of the 3174. Note that VTAM has to be started
with BN=YES in order to make this possible. This is further discussed under a
separate section in Chapter 6, “Border Node Support” on page 115.
4.2.4 CM/2 as an APPN Node

Communications Manager and Communications Server PCs can act as network
nodes, end nodes or LEN nodes. Here we describe how you can configure CM/2
as an APPN node. Figure 38 shows the network diagram with CM/2 devices on
the token-ring with their PU names and CP names shown, for reference.
Figure 38. Network Diagram of CM/2s
4.2.4.1 CM/2 as Network Node

VTAM Definitions: The CM/2 machine CP05147, whose VTAM link station name
is RAATRPU3, is configured as a network node. For VTAM to recognize it as
such, specify CONNTYPE=APPN 1 on the PU definition, since the VTAM start
option is specified as CONNTYPE=LEN. Figure 39 on page 76 shows the VTAM
definitions for the PU. Note that we still use the traditional method
(IDBLK/IDNUM) to identify the node to VTAM. With APPN we recommend you
use CPNAME instead. IDBLK/IDNUM should be reserved for DLUR resources
because they can have multiple PUs within a single node (single CP).

VBUILD TYPE=SWNET,
MAXNO=1,
MAXGRP=1
RAATRPU3 PU ADDR=01,
IDBLK=05D,
IDNUM=05147,
CONNTYPE=APPN, 1
MAXOUT=7,
MODETAB=ISTINCLM, (V) VTAM
DLOGMOD=D4C32XX3, (V) VTAM
MAXPATH=1,
PASSLIM=7,
PUTYPE=2
RAATLU32 LU LOCADDR=2
Figure 39. VTAM Definitions for CM/2 NN
Configuration in Communications Manager: In practice, your CM/2 node may

already be configured as an APPN node so you will not need to make any
changes. However, we occasionally illustrate the setup of CM/2 and CS/2 nodes
in this book in order to relate the parameters to the VTAM configuration. CM/2
and CS/2 setup is the same in principle, with differences in detail as well as
differences due to new functions introduced in CS/2.
To configure CM/2 as a network node, select SNA local node characteristics from
the configuration list as shown in Figure 40 on page 77.

Figure 40. CM/2 Configuration List
Select the Network Node option from the next window as shown in Figure 41,
and fill in the fully qualified CP name (NetID and node name).
Figure 41. CM/2 Local Node Characteristics
Next, go back and select SNA connections from the configuration list shown in
Figure 40 to define a logical link to the host. In both CM/2 and CS/2, there are

two ways to define a link (such as ours) which is both APPN and dependent
subarea, in other words a combined type 2 and type 2.1 connection. They are:
1. Define a link to a host, and select APPN Support.
2. Define a link to another APPN node, and select Solicit SSCP-PU session.
Either will do the job; we used the first method throughout our testing.
From the connection list shown in Figure 42, create a new token-ring connection
(or edit an existing one), with the partner node type being a host.
Figure 42. CM/2 Connections List
The Connection to a Host window is displayed as shown in Figure 43 on

page 79.

Figure 43. CM/2 Panel for Connection to Host
The option for APPN support has to be selected, otherwise no CP-CP sessions
will be established. The local PU name has only local significance, and does not
have to match VTAM′s PU name.
Session Setup: The VTAM switched major node (and Communications Manager,
if necessary) are recycled to effect the change. A display of the topology for all
NNs now shows CP05147 with CP-CP sessions to RAA 2, as in Figure 44.
* RAAAN D NET,TOPO,LIST=NN

′ RAAAN
IST1296I USIBMRA.CP31744 NN 128 NONE YES *NA*
IST1296I USIBMRA.CP31743 NN 128 NONE NO *NA*
IST1296I USIBMRA.CP05147 NN 128 NONE 2 YES *NA*
IST314I END

Figure 44. Display of Topology for NNs
We test the APPN route to RAA using APING, an LU 6.2 application on the CM/2
workstation. The display of CP05147 shows two additional parallel sessions (as
well as the CP-CP sessions) as shown in Figure 45 on page 80 3.


′ RAAAN
IST075I NAME = USIBMRA.CP05147 , TYPE = ADJACENT CP
IST486I STATUS= ACT/S----Y, DESIRED STATE= ACTIV
IST1447I REGISTRATION TYPE = NO
IST934I DLOGMOD=CPSVCMG USS LANGTAB=***NA***
IST231I CDRSC MAJOR NODE = ISTCDRDY
IST1184I CPNAME = USIBMRA.CP05147 - NETSRVR = ***NA***
IST1044I ALSLIST = ISTAPNPU
IST082I DEVTYPE = INDEPENDENT LU / CDRSC
IST206I SESSIONS:
IST1081I ADJACENT LINK STATION = RAATRPU3
IST635I RAA ACTIV-S ECC35935AFFF7BF4 0004 0003 0 0 USIBMRA
IST635I RAA ACTIV-S ECC35935AEFF7BF4 0001 0001 0 0 USIBMRA 3
IST635I RAA ACTIV/CP-S ECC35935ADFF7BF4 000E 0001 0 0 USIBMRA
IST635I RAA ACTIV/CP-P F7FF6164D39CEA0B 0001 002F 0 0 USIBMRA
IST924I -------------------------------------------------------------
IST075I NAME = USIBMRA.CP05147 , TYPE = DIRECTORY ENTRY
IST1186I DIRECTORY ENTRY = DYNAMIC NN
IST314I END

Figure 45. Display of CM/2 CP CP05147
4.2.4.2 CM/2 Defined as a LEN Node

We leave the CM/2 machine CP05150 connected via LEN. This is exactly the
same as it was in subarea, and no extra work needs to be done unless we
decide to change the CONNTYPE start option to APPN. If we do that, we must
make sure that either CONNTYPE=LEN on the PU definition for CP05150, or that
the CM/2 setup itself is for a LEN node.
VTAM Definitions: While the default VTAM connection is LEN, the definitions for
CP05150 do not change, as shown in Figure 46 on page 81.

VBUILD TYPE=SWNET,
MAXNO=1,
MAXGRP=1
IDBLK=05D,
IDNUM=05150,
MAXOUT=7,
MAXPATH=1,
MODETAB=ISTINCLM,
PASSLIM=7,
PUTYPE=2
Figure 46. VTAM Definition for RAATRPU2
Configuration in Communications Manager: In CM/2, configuration of a LEN

node is done simply by selecting End node - no network node server, as seen in
Figure 47. The Connection to a Host panel in Figure 48 on page 82 need not
have APPN switched on; CM/2 treats all connections as type 2.1 by default.
Figure 47. SNA Local Node Characteristics

Figure 48. SNA Connections
Session Setup: Session setup will be the same as it was in the pure subarea
network. The CM/2 LEN node is not recognized by VTAM as an end node, since
it is not included in the topology display in Figure 49 and no CP-CP sessions are
established (see Figure 50 on page 83).
′ RAAAN
IST314I END
Figure 49. Display of Topology with L I S T = E N

C RAAAN DISPLAY NET,ID=RAATRPU2,SCOPE=ALL
′ RAAAN
IST314I END
Figure 50. Display of PU RAATRPU2
4.2.4.3 CM/2 as EN with RAA as its NNS

We define the third CM/2 machine, CP05137, as an end node. It has dependent
LUs (and no DLUR), so it must be directly attached to the VTAM CNN. However,
its network node server need not be a VTAM because it does not use session
services extensions (it uses subarea protocols for the dependent LUs, not
APPN). Here we make VTAM its NN server.
VTAM Definitions: Figure 51 shows the definitions for the PU in VTAM. Once
again, we ensure that CONNTYPE is APPN 1 because we are overriding the
start option which defaults such connections to LEN.
VBUILD TYPE=SWNET,
MAXNO=1,
MAXGRP=1
IDBLK=05D,
IDNUM=05137,
CONNTYPE=APPN, 1
MAXOUT=7,
MODETAB=ISTINCLM, (V) VTAM
MAXPATH=1,
PASSLIM=7,
PUTYPE=2
RAATRPH4 PATH DIALNO=0004400001050001,
GRPNM=EG05L01
Figure 51. VTAM Definitions for RAATRPU4
Configuration in Communications Manager/2: To configure the CM/2 as an EN

with NNS, select SNA node local characteristics from the configuration list and
then End node to network node server as in Figure 52 on page 84. Note that you

have to provide the MAC address for your NNS. In our example, the MAC
address was for RA5NCPX.
Figure 52. CM/2 Local Node Characteristics
The connection to the host (or to a network node depending on which

configuration path you have taken) is defined in the same way as for the network
node (Figure 43 on page 79). The partner node name need not be filled in;
APPN will look after that.
Session Setup: The VTAM switched major node and (if changed) the
Communications Manager are recycled to effect the changes. A display of the
network topology for adjacent ENs shows that CP05137 has CP-CP sessions with
RAA 1 (Figure 53).

′ RAAAN
IST1296I USIBMRA.RAATRCP2 EN *NA* *NA* NO *NA*
IST1296I USIBMRA.CP05137 EN *NA* *NA* 1 YES *NA*
IST314I END

Figure 53. Display of TOPOLOGY with L I S T = E N
A display of CP05137 is shown in Figure 54 on page 85. Much of the displayed

information is similar to that shown for an adjacent network node (Figure 33 on
page 72) but some is different.
CP05137 is an adjacent CP 1, a dynamically defined CDRSC ( 2 and 5), and
an independent LU 8, just as the 3174 NN. Being a CDRSC it does not require
registration 3. The logmode used by default is CPSVCMG again 4, the actual

link station being used is the VTAM PU 9, and the link station to be used when
locating the resource is the APPN network as denoted by ISTAPNPU 7.
The NETSRVR value is shown as “not applicable” at 6. This is because, when
CP05137 is viewed as a CDRSC (from the subarea side of VTAM) it is located by
subarea searching and not by APPN searching. On the other hand, when
CP05137 is viewed as a directory entry 12 (from the APPN side of VTAM), it
must be found via its network node server. That NNS is RAA itself 14. The EN
is seen as a “registered EN” 13 in the directory. This means that the EN is
served by this VTAM as an NNS.
CP05137 has the usual two CP-CP sessions with RAA 11. In this particular
display we have also performed an APING which resulted in the other two
sessions shown 10. These are not CP-CP sessions since they have no “/CP”
status modifier.

′ RAAAN
IST075I NAME = USIBMRA.CP05137 , TYPE = ADJACENT CP 1
IST486I STATUS= ACT/S----Y, DESIRED STATE= ACTIV 2
IST1447I REGISTRATION TYPE = NO 3
IST934I DLOGMOD=CPSVCMG USS LANGTAB=***NA*** 4
IST231I CDRSC MAJOR NODE = ISTCDRDY 5
IST206I SESSIONS:
IST1081I ADJACENT LINK STATION = RAATRPU4 9
IST635I RAA ACTIV-S ECC35935B478D526 0004 0003 0 0 USIBMRA 10
IST635I RAA ACTIV-S ECC35935B378D526 0001 0001 0 0 USIBMRA
IST635I RAA ACTIV/CP-S ECC35935B078D526 0007 0001 0 0 USIBMRA 11
IST635I RAA ACTIV/CP-P F7FF6164D4861C5B 0001 0007 0 0 USIBMRA
IST924I -------------------------------------------------------------
IST075I NAME = USIBMRA.CP05137 , TYPE = DIRECTORY ENTRY 12
IST1186I DIRECTORY ENTRY = REGISTERED EN 13
IST1184I CPNAME = USIBMRA.CP05137 - NETSRVR = USIBMRA.RAA 14
IST314I END

Figure 54. Display of EN CP05137
4.2.4.4 CM/2 as EN with a CM/2 NN as its NNS

One could also have the CM/2 defined as an EN with another CM/2 NN acting as
its network node server instead of the VTAM. To allow dependent LU sessions,
however, one of three options must be taken:
1. Define a second connection from the EN, to the VTAM boundary function (our
NCP in this case)
2. Use the gateway function on the NN server, which passes the dependent LU
sessions through to the VTAM boundary function (this is what we do in our

next example. but using Communications Server instead of Communications
Manager)
3. Use the dependent LU requester function, as described in SG24-5204
4.2.4.5 Defining a CS/2 NN as a Gateway

In our test environment, we configure the SDLC-connected PC CP05160 as a
gateway to serve a second PC (CP05221) with dependent LUs. CP05221 does not
have a direct connection to a subarea node. Both CP05160 and CP05221 are
running Communications Server Version 4. Please see Figure 55.
Figure 55. CM/2 as a Gateway
VTAM Definitions: In VTAM, we specify CONNTYPE=APPN on the PU definition

for CP05160, exactly as before. The only difference is that we must add
CP05221′s dependent LUs to the PU definition since they appear to be on
CP05160. See Figure 56 on page 87 for an example of an SDLC-attached CS/2
definition; note the XID=YES 1 which must always be specified on a leased
APPN connection.

RA8CM2A PU ADDR=C1, 3270 ADDRESS=′ C′ ( EBCDIC)
CONNTYPE=APPN,
MAXDATA=1033, MAXIMUM AMOUNT OF DATA (CM/2)
MAXOUT=7, MAX SDLC FRAMES BEFORE RESPONSE
PACING=0, PACING SET BY BIND IMAGE
ANS=CONTINUE, KEEPS CROSS-DOMAIN RUNNING
PASSLIM=7,
PUTYPE=2,
RETRIES=(,1,4), 4 RETRIES, 1 SECOND BETWEEN
DISCNT=(NO), (V) VTAM ONLY
ISTATUS=ACTIVE, (V) VTAM ONLY
USSTAB=US327X, (V) VTAM ONLY
XID=YES 1
**********************************************************************
RA8CM2A2 LU LOCADDR=2,DLOGMOD=D4C32XX3
Figure 56. VTAM Definitions for CP05160 / CP05221
Configuration in Communications Server: In CS/2 we still select SNA local node

characteristics as in Figure 57, but after that the configuration is different.
Figure 57. Communications Server Configuration List
We define the node as a network node and provide the necessary information as
seen in Figure 58 on page 88.

Figure 58. Local Node Characteristics
We then select SNA connections as before to get Figure 59, which allows us to
define a new link or change the existing logical link definition to the host.
Figure 59. Communications Server Connections List
We are then presented with the adapter list (Figure 60 on page 89) where we
select the required adapter and click on Continue.

Figure 60. Adapter List
The next panel is the Connection to a Host window (Figure 61); clicking on
Additional parameters yields the window shown in Figure 62 on page 90 where
we can select APPN support.
Figure 61. Communications Server Connections to Host

Figure 62. Additional Connection Parameters
To configure a gateway, select Gateway Hosts and Host LU Pools from the
Configuration List window. The details of gateway configuration are beyond the
scope of a book on APPN; see the CS/2 or CM/2 documentation for advice on
how to do this.
Session Setup: The NCP and the Communications Server machine are recycled
to implement the changes. A display of both the link station (Figure 63) and the
control point LU (Figure 64 on page 91) show that CP-CP sessions have been
established 6 between CP05160 and RAA.
* RAAAN D NET,ID=RA8CM2A,E

′ RAAAN
IST075I NAME = RA8CM2A , TYPE = PU_T2.1
IST1106I RA8CM2A AC/R 21 YES 982D0000000000000000017100808080
IST081I LINE NAME = LCM2A , LINE GROUP = G08XLLL , MAJNOD = RA8NCPX
IST080I RA8CM2A2 ACTIV RA8CM2A3 ACTIV RA8CM2A4 ACTIV
IST080I RA8CM2A5 ACTIV
IST080I CP05160 ACT/S----Y 6
IST314I END

Figure 63. Display of PU RA8CM2A


′ RAAAN
IST934I DLOGMOD=CPSVCMG USS LANGTAB=***NA***
IST1044I ALSLIST = ISTAPNPU
IST082I DEVTYPE = INDEPENDENT LU / CDRSC
IST206I SESSIONS:
IST1081I ADJACENT LINK STATION = RA8CM2A
IST635I RAA ACTIV/CP-S ECBF6035AD440142 008E 0001 1 0 USIBMRA 6
IST635I RAA ACTIV/CP-P F7FF6164D40C014E 0001 00B0 1 0 USIBMRA
IST924I -------------------------------------------------------------
IST075I NAME = USIBMRA.CP05160 , TYPE = DIRECTORY ENTRY
IST1186I DIRECTORY ENTRY = DYNAMIC NN
IST314I END

Figure 64. Display of CP05160
Note that each adjacent CP with which VTAM sets up sessions is added
dynamically to the major node ISTCDRDY. Figure 65 shows four of them: the
three PCs and the 3174. The LEN CM/2 node is not represented. Its CP LU has
been predefined and therefore lives in another major node.
* RAAAN D NET,ID=ISTCDRDY,E

′ RAAAN
IST075I NAME = ISTCDRDY , TYPE = CDRSC SEGMENT
IST478I CDRSCS:
IST483I RAKTX082 ACT/S----Y, CDRM = RAK , NETID = USIBMRA
IST483I CP05160 ACT/S----Y, CDRM = ***NA***, NETID = USIBMRA
IST483I RAKAN ACT/S----Y, CDRM = RAK , NETID = USIBMRA
IST483I SCHANLUC ACT/S----Y, CDRM = RAK , NETID = USIBMSC
IST483I RAKANLUC ACT/S----Y, CDRM = RAK , NETID = USIBMRA
IST483I RAIANLUC ACT/S----Y, CDRM = RAK , NETID = USIBMRA
IST483I RABANLUC ACT/S----Y, CDRM = RAK , NETID = USIBMRA
IST314I END

Figure 65. Display of ISTCDRDY

4.2.4.6 Communications Server EN Using CS/2 Gateway as its NNS
As the last step, we look at defining the CS/2 CP05221 as an end node with
CP05160 as its network node server.
VTAM Definitions: In this scenario, VTAM is not aware of the CS/2 node, except
as some remote LUs. The CP (CP05221) can be reached using normal APPN
mechanisms, while the dependent LUs appear to be on the link station
RA8CM2A which also connects to CP05160. These dependent LUs are defined
under the PU RA8CM2A, as in Figure 56 on page 87.
Configuration in Communications Server: CP05160 needs no extra definitions to

handle CP05221, because by default its token-ring port will accept all incoming
connections. It is usual to do this for a network node, and to define explicitly the
EN-to-NN connections in the end node, which we do for CP05221.
From the Configuration List panel, we select Local Node Characteristics and
define the node type, the CP name and the IDBLK/IDNUM (which are not
necessary as VTAM will never see them).
As with the network node CP05160, we select:

• SNA Connections to reach the Connection List
• To Host to get the list of host connections
• The connection we are interested in, to get the Adapter List
• Continue to get the Connection to Host panel where we enter the destination
MAC address which is that of CP05160
• Additional Parameters where we select APPN Support
This configuration path will result in CP05221 choosing CP05160 as its network
node server, because it is the only link available to an APPN network node. If
there are multiple NN links on an EN, we can influence the choice of NN server
but we must take the other configuration path:
• SNA Connections to reach the Connection List
• To Network Node to get the list of NN connections
• The connection we are interested in, to get the Adapter List
• Continue to get the Connections to Network Node panel where we enter the
destination MAC address
• Additional Parameters where we select Use this network node connection as
your preferred server and (if the NNS is also VTAM or a gateway, as now)
Solicit SSCP-PU session
Session Setup: When we restart CP05221 the connection is made at once and
CP-CP sessions are established between CP05221 and CP05160. We can now
set up two very different kinds of session between RAA and CP05221:
• Independent LU 6.2 sessions (for example, using APING) take an APPN path
between the two control points RAA and CP05221, using CP05160 as an
intermediate routing node. VTAM RAA sees CP05221 as an ILU/CDRSC, on
link station RA8CM2A, but not an adjacent CP.
• Dependent LU sessions (for example, logging on to TSO) take the same
physical path, but using CP05160 as an interchange between VTAM and
CP05221. Thus VTAM sees the dependent LUs as being owned by itself and

on the PU RA8CM2A. CP05221 sees CP05160 as its VTAM boundary node. If
you want these dependent LU sessions to use the full power of an APPN
network then you need DLUR on CP05221.
At this stage, when all the resources have been converted to APPN, you can
convert the VTAM start option CONNTYPE to APPN. Subsequently you can let
any new end nodes be connected using native APPN. If a new node attached to
the APPN network can only be configured as a network node, you should check
whether it has enough power and storage to participate in what could be a large
APPN network. The 3174, in particular, will often have to be isolated from the
backbone network because of its limited resources.

Chapter 5. Migrating a Data Host to an MDH or a Pure EN
At the time of migrating the CMC host to an interchange node, the data host is
not touched at all; that is, it remains as a pure subarea node. All connections to
and from the data host are still subarea connections. Once the interchange
node migration has been completed, the next step is to migrate the data hosts.
For a discussion on the roles of VTAM hosts in an APPN network, refer to 3.1.2,
“VTAM/NCP and APPN Node Roles” on page 26.
In our test network, in addition to the CMC or interchange node RAA, there is a
VTAM data host RAS. In this chapter we discuss the migration of this VTAM
data host to a migration data host (MDH). We then look at converting the
migration data host to a pure end node and discuss why a user might want to do
that. Even though we only use one VTAM data host in the test network for
migration to an MDH, the migration process will be the same for a real network
with numerous VTAM data hosts.
Note: If you only have one VTAM host, then the discussion in this chapter does
not have relevance to your network. A single VTAM should always be converted
to an NN or an ICN. If it becomes an EN or an MDH, it will not be able to take a
full part in your APPN network. It will be unable to own an NCP, and it will not
be able to establish dependent LU sessions unless the dependent LUs are
directly attached to it (because it needs session services extensions in its NN
server).
In order to convert the VTAM data host to an APPN-capable migration data host,
certain VTAM start options and major node definitions have to be modified or
added. For a discussion on what must be considered while planning the data
host migration, refer to Chapter 3, “Planning for Migration” on page 25.
5.1 VTAM Start Options

For our data host RAS, the changes made to the VTAM start options are shown
in Figure 66.
CONNTYPE=LEN 1
CPCP=YES 2
DYNADJCP=YES 3 DEFAULT
HPR=NONE 4
HOSTSA=28 5 << no change
NODETYPE=EN 6
SORDER=SUBAREA 7
VRTG=NO 8 DEFAULT
Figure 66. VTAM Start Options for Migration Data Host
We specify CONNTYPE=LEN 1 in the start options and use CONNTYPE=APPN

on individual PU (type 2.1) definitions for which we want RAS to establish APPN
connections. By doing this, we control whether a connection to an APPN node
should be attempted as an APPN connection or as a LEN connection. In the
VTAM definitions for the channel connections to VTAM RAA and to NCP
RA8NCPX (refer to Figure 68 on page 98 and Figure 86 on page 109), we specify
CONNTYPE=APPN for these connections.

2 Specifies that CP-CP sessions on all APPN connections (leased and
switched) will be supported.
3 We will allow adjacent control point (ADJCP) minor nodes to be created
dynamically and placed in the major node ISTADJCP.
4 At this point we do not want this VTAM to provide any HPR support.
5 For a migration data host we need to keep this start option and also add
NODETYPE 6.
6 A migration data host is an APPN end node.
7 We want to search the subarea network first when a search request
originates on the MDH. In this particular example we wish to ensure that the
proven methods work before making changes to the search patterns.
An MDH will never receive a request from another subarea node and forward it
into the APPN network.
8 In the start options we specify VRTG=NO, and override this value by coding
the VRTG operand for specific CDRM definition statements. By doing this we
can control which SSCP-SSCP sessions will support VR-based transmission
group connections. When VRTG is specified on the CDRM statement, it is also
easier to identify whether an SSCP-SSCP session is supporting VR-TG
connections or not.
For full details on all the APPN-related VTAM start options available, refer to
Appendix B, “VTAM APPN and APPN-Related Start Options” on page 197.
5.2 Converting Subarea MPC to ANNC

In our network, the data host RAS has two channel connections (one multipath
channel connection to VTAM RAA and the other channel connection to NCP
RA8NCPX). When the data host RAS is a subarea node, both these connections
are FID4 type connections as shown in Figure 67 on page 97. As part of the
data host migration, we convert the VTAM-to-VTAM channel connection to a FID2
connection and leave the channel connection to NCP RA8NCPX as FID4 for
subarea access. Conversion of the NCP channel connection to an FID2 is
discussed in 5.6.1, “Convert NCP Channel Connection to FID2” on page 109,
when we look at making the migration data host into a pure end node (that is,
removing its subarea capability).

Figure 67. FID4 Connections from VTAM RAS
To migrate the multipath channel (MPC) connection to an APPN node-to-node

channel (ANNC) connection, VTAM definition changes are required on both sides
of the connection.
Note: If your network has channel-to-channel connections between VTAM

domains, you must ensure they are capable of MPC before migration to ANNC.
APPN does not support the old bidirectional CTC protocol. See 3.1.10, “Multipath
Channel Conversion” on page 39.
In our network we change the definitions on VTAMs RAA and RAS. On each of
the two VTAMs:
• Change the CA major node for MPC to a local SNA major node with a TRLE
operand pointing at the transport resource list element (TRLE) name.
• Create a TRL major node with LNCTL=MPC defined. This contains the
TRLEs for your MPC connections. The transport resource list element is not
a resource, but describes the connectivity characteristics of the multipath
channel that is being used by the ANNC.
The definitions set up on RAS and RAA are as shown below:
Chapter 5. Migrating a Data Host to an MDH or a Pure EN 97

****************************************************************
****************************************************************
RASLCL2 VBUILD TYPE=LOCAL
RASPUAHC PU TRLE=RASAHHCT 1
CONNTYPE=APPN,
CPCP=YES,
TGP=CHANNEL, 2
ISTATUS=ACTIVE
Figure 68. RAS ANNC Link Station Definitions
****************************************************************
****************************************************************
*
RASAHHCT 1 TRLE LNCTL=MPC,
READ=(C14), 3
WRITE=(C12) 4
Figure 69. RAS ANNC TRLE Definitions
****************************************************************
****************************************************************
RAALCL2 VBUILD TYPE=LOCAL
RAAPUAHC PU TRLE=RAAAHHCT 1
CONNTYPE=APPN,
CPCP=YES,
TGP=CHANNEL, 2
ISTATUS=ACTIVE
Figure 70. RAA ANNC Link Station Definitions
****************************************************************
****************************************************************
*
RAAAHHCT 1 TRLE LNCTL=MPC,
READ=(C12), 4
WRITE=(C14) 3
Figure 71. RAA ANNC TRLE Definitions
Notes:
1 The value on the TRLE= operand must match the label on the TRLE
definition.

2 CHANNEL is a transmission group profile found in the IBMTGPS
default profile table.
3 The READ address C14 in RAS must be connected to the WRITE
address on the other side (that is, in RAA).
4 The WRITE address C12 in RAS must be connected to the READ
address on the other side (that is, in RAA).
5.3 Defining a Network Node Server

As discussed in 3.1.16.3, “Network Node Server List” on page 48, it is preferable
to set up a network node server list in a VTAM end node or migration data host,
and to allow it to register its local resources with the NNS.
For our migration data host RAS, we set up the network node server list major
node as in Figure 72.
*******************************************************************
* NETWORK NODE SERVER LIST MAJORNODE FOR RAS *
* USES RAA AS ITS NETWORK NODE SERVER *
*******************************************************************
RASNNSVR VBUILD TYPE=NETSRVR, X
ORDER=FIRST 1 DEFAULT
RAA 2 NETSRVR NETID=USIBMRA, X
SLUINIT=REQ DEFAULT
3 NETSRVR SLUINIT=REQ DEFAULT
Figure 72. Network Node Server List for RAS (EN)
Notes:
1 This is the default and specifies that the EN always attempts to find an
NNS from the NNS list starting with the first entry.
2 We prefer our ICN RAA to be the NNS for this EN.
3 The nameless entry acts as a backup, in case none of the listed
servers are active. Any other adjacent NN, not included in the NNS list,
will be considered as a potential NNS for this EN. However, we ensure
that any NN chosen as a server will support session services extensions,
by coding SLUINIT=REQ. Without session services extensions no
dependent LU sessions can be established between the VTAM EN and the
rest of the network.
The nameless entry must be the last entry in the list.
5.3.1 Resource Registration

Resources which reside on a VTAM end node that may be the target of an APPN
search must either specify or default to REGISTER=NETSRVR or
REGISTER=CDSERVR to be found. Refer to Table 4 on page 47 for a list of
defaults.
On a VTAM APPN host, the default for applications (APPL minor nodes) is to
register at the central directory server, and the default for dependent LUs is to

register at the NN server. But the default for an independent LU (which is in fact
a CDRSC) is not to be registered anywhere. Thus, if you have LEN connections
attached to a VTAM EN, and there is no other way to reach those LEN resources,
they should be registered at the EN′s NN server (and, perhaps, the CDS).
Resources belonging to a VTAM network node have the same registration

defaults, except that registration is only performed to a CDS. There is no need
for an NN to register its own resources with itself, as it already knows where
they are.
Resources that will never be search targets should not be registered as this
wastes directory space and network setup time. Such resources include TSO
user applications and NetView operator tasks. By default TSO user applications
are not registered, but you may wish to change the default
(REGISTER=CDSERVR) for other such applications.
The resources on our migration data host, RAS, are all either applications or
dependent LUs; for these resources we do not need to specify the REGISTER
operand on the definition statements because the defaults are acceptable. In
fact, in our network the NNS is the CDS so there is only one registration step for
each resource owned by RAS. RAS does not have any LEN ILUs defined, but if
we create one, it will have to be registered with RAA if it is to be the target of an
APPN search.
5.4 Check the Subarea Environment

Before we shut down and restart VTAM RAS, we display some of the subarea
characteristics, which are compared with similar displays produced after RAS is
started as an MDH. These comparisons help in understanding the changes
expected with the migration.
Figure 73 shows a display of RAS from RAA. RAS is seen as an adjacent

CDRM. We do not expect this to change when RAS becomes an MDH.
C RAAAN DISPLAY NET,ID=RAS,SCOPE=ALL

′ RAAAN
IST075I NAME = USIBMRA.RAS , TYPE = CDRM
IST815I AUTOMATIC RECOVERY IS SUPPORTED
IST231I CDRM MAJOR NODE = RAACDRM
IST476I CDRM TYPE = EXTERNAL
IST637I SUBAREA= 28 ELEMENT= 1
IST675I VR = 0, TP = 2
IST389I PREDEFINITION OF CDRSC = OPT
IST636I CDRSCS OWNED BY RAS -
IST080I RASAN ACT/S----Y RASANLUC ACT/S----Y
IST314I END

Figure 73. Display of RAS CDRM on RAA
Figure 74 on page 101 shows that there are two subarea paths available
between RAA and RAS. One is directly to RAA (subarea 10 1) and the other is

to RAA′s owned NCP (subarea 8 2). We can expect this to change when we
convert the CTC link to APPN.
C RASAN DISPLAY NET,ROUTE,DESTSUB=10,ER=ALL,TEST=NO

RASAN IST097I DISPLAY ACCEPTED
′ RASAN
IST535I ROUTE DISPLAY 11 FROM SA 28 TO SA 10
IST808I ORIGIN PU = ISTPUS28 DEST PU = ***NA*** NETID = USIBMRA
IST536I VR TP STATUS ER ADJSUB TGN STATUS CUR MIN MAX
IST537I 0 0 INACT 0 10 11 ACTIV1
IST537I 1 0 INACT 1 8 21 INACT
IST537I 3 2 ACTIV 3 10 1 ACTIV3 11 10 30
IST314I END

Figure 74. Display of Paths from SA28 to SA10
5.5 Testing the MDH Configuration

Once the VTAM definitions discussed in the previous sections are ready,
subarea data host VTAM RAS is shut down and restarted as an MDH with our
new definitions.
5.5.1 Start RAS as an MDH

The following messages at VTAM startup confirm that RAS has been started
successfully as an MDH:
IST020I VTAM INITIALIZATION COMPLETE FOR V4R3

IST1348I VTAM STARTED AS MIGRATION DATA HOST

Figure 75. MDH Initialization
Once VTAM initialization is complete, the display of APPN-related VTAM start

options on RAS (Figure 76 on page 102) show the definitions that are set up for
the MDH. As the display shows, a number of VTAM start options are not
applicable to an MDH (or an EN for that matter). These start options only have
meaning when VTAM is set up as an ICN (or an NN).

* RASAN D NET,VTAMOPTS,FUNCTION=APPNCHAR

′ RASAN
IST1348I VTAM STARTED AS MIGRATION DATA HOST
IST1189I APPNCOS = NONE BN = ***NA***
IST1189I BNDYN = ***NA*** BNORD = ***NA***
IST1189I CDSERVR = ***NA*** CDSREFER = ***NA***
IST1189I CONNTYPE = APPN CPCP = YES
IST1189I DIRSIZE = ***NA*** DIRTIME = ***NA***
IST1189I DYNADJCP = YES HPR = NONE
IST1189I HPRPST = LOW 60S HPRPST = MEDIUM 60S
IST1189I HPRPST = HIGH 60S INITDB = ***NA***
IST1189I IOPURGE = 0 NODETYPE = EN
IST1189I NUMTREES = ***NA*** RESUSAGE = ***NA***
IST1189I ROUTERES = ***NA*** SECLVLCP = ***NA***
IST1189I SNVC = ***NA*** SORDER = SUBAREA
IST1189I SRCHRED = OFF SRCOUNT = 10
IST1189I SRTIMER = 30S SSEARCH = ***NA***
IST1189I VERIFYCP = NONE VFYRED = YES
IST1189I VFYREDTI = ***NA*** VRTG = NO
IST1189I VRTGCPCP = YES
IST314I END

Figure 76. RAS VTAMOPTS for APPN Characteristics
5.5.2 Check CP-CP and SSCP-SSCP Sessions

Before we can establish APPN connectivity between RAA and RAS, we must
redefine the CTC connection between the VTAMs (RAA still has it as a subarea
connection):
• Inactivate the MPC major node in RAA which defines the subarea channel
link
• Activate the associated TRL major node (see Figure 71 on page 98)
• Activate the LOCAL major node for the ANNC connection (see Figure 70 on
page 98).
When the CP-CP sessions between ICN VTAM and the MDH VTAM are
established successfully, we get the following messages on RAS:
IST1086I APPN CONNECTION FOR USIBMRA.RAA IS ACTIVE - TGN = 21

IST093I RASPUAHC ACTIVE
IST1096I CP-CP SESSIONS WITH USIBMRA.RAA ACTIVATED

Figure 77. ANNC Activation
The display of the TRLE defined for this ANNC link, Figure 78 on page 103,
shows that the READ 1 and WRITE 2 devices defined for the ANNC link are
both active and online. This display also shows the name of the link station 3.

C RASAN DISPLAY NET,ID=RASAHHCT,SCOPE=ALL

′ RASAN
IST075I NAME = RASAHHCT , TYPE = TRLE
IST087I TYPE = LEASED , CONTROL = MPC
IST1221I WRITE DEV = 0C12 STATUS = ACTIVE 1 STATE = ONLINE
IST1221I READ DEV = 0C14 STATUS = ACTIVE 2 STATE = ONLINE
IST1068I PHYSICAL RESOURCE (PHYSRSC) = RASPUAHC 3
IST314I END

Figure 78. Display of Active TRLE RASAHHCT
RAS as a migration data host establishes both CP-CP and SSCP-SSCP sessions
with RAA. When we display RAS from itself, Figure 79 shows that is is both a
CDRM 4 and a control point 5. It has both an SSCP-SSCP session 6 and a
pair of CP-CP sessions 7 8 with its partner.
C RASAN DISPLAY NET,ID=RAS,SCOPE=ALL

′ RASAN
IST075I NAME = USIBMRA.RAS , TYPE = CDRM 4
IST1046I CP USIBMRA.RAS ALSO EXISTS
IST815I AUTOMATIC RECOVERY IS SUPPORTED
IST231I CDRM MAJOR NODE = VTAMSEG
IST476I CDRM TYPE = HOST
IST637I SUBAREA= 28 ELEMENT= 1
IST388I DYNAMIC CDRSC DEFINITION SUPPORT = YES
IST206I SESSIONS:
IST635I RAA 6 ACTIV F7FF6164D40C039B 1 2 USIBMRA
IST924I -------------------------------------------------------------
IST075I NAME = USIBMRA.RAS , TYPE = HOST CP 5
IST1046I SSCP USIBMRA.RAS ALSO EXISTS
IST934I DLOGMOD=***NA*** USS LANGTAB=***NA***
IST231I APPL MAJOR NODE = VTAMSEG

Figure 79 (Part 1 of 2). SSCP-SSCP and CP-CP Sessions between RAA and RAS

′ RASAN

IST075I NAME = USIBMRA.RAS , TYPE = CDRM
IST271I JOBNAME = NET28 , STEPNAME = NET28 , DSPNAME = IST1936D
IST1050I MAXIMUM COMPRESSION LEVEL - INPUT = 0 , OUTPUT = 0
IST206I SESSIONS:
IST635I RAA 7 ACTIV/CP-S F627D164E666BEE5 0068 0001 0 0 USIBMRA
IST635I RAA 8 ACTIV/CP-P F7FF6164D40C03A5 0001 0061 0 0 USIBMRA
IST314I END

Figure 79 (Part 2 of 2). SSCP-SSCP and CP-CP Sessions between RAA and RAS
The CP-CP sessions show up as one contention winner 7 (from RAS′s point of
view) and one contention loser 8.
5.5.3 Check the Subarea Routes

With the migration of RAS to an MDH, the channel connection between RAS and
RAA is no longer available for subarea routes. The channel connection is now a
FID2 ANNC link. If we now display the subarea paths between RAS and RAA, we
can see the difference as in Figure 80.
* RASAN D NET,ROUTE,DESTSUB=10

′ RASAN
IST535I ROUTE DISPLAY 1 FROM SA 28 TO SA 10
IST808I ORIGIN PU = ISTPUS28 DEST PU = ***NA*** NETID = USIBMRA
IST536I VR TP STATUS ER ADJSUB TGN STATUS CUR MIN MAX
IST537I 0 0 INACT 0 1 10 1 INOP
IST537I 0 1 INACT 0 10 1 INOP
IST537I 1 0 INACT 1 2 8 1 ACTIV3
IST537I 1 2 ACTIV 1 8 1 ACTIV3 31 30 90
IST537I 2 0 INACT 2 2 8 1 ACTIV3
IST537I 3 0 INACT 3 1 10 1 INOP

Figure 80. Subarea Paths with RAS as an MDH
All the direct subarea paths (those with subarea 10 adjacent) are now INOP 1,
while those through subarea 8 are carrying the SSCP session 2. Compare this
with Figure 74 on page 101.
5.5.4 Check Network Node Server List

In the display of the network node server list for RAS (Figure 81 on page 105),
we can see that a predefined NNS list in the form of major node RASNNSVR 4
exists and its current network node server is RAA 5.

* RASAN D NET,NETSRVR

′ RASAN
IST350I DISPLAY TYPE = NETWORK NODE SERVER LIST
IST1252I DEFINED NETWORK NODE SERVER LIST, NAME = RASNNSVR 4
IST1253I USIBMRA.RAA SLUINIT = REQ
IST924I -------------------------------------------------------------
IST1254I SERVER LIST PROCESSED ORDER = FIRST
IST924I -------------------------------------------------------------
IST1255I OTHER NETWORK NODES ALLOWED AS SERVERS
IST1253I NONE
IST924I -------------------------------------------------------------
IST1256I CURRENT NETWORK NODE SERVER
IST1253I USIBMRA.RAA 5 SLUINIT = REQ
IST314I END

Figure 81. Network Node Server List for RAS
5.5.5 Testing LU Session Establishment

Once we have checked that the subarea and APPN connections have been
activated as expected, we test session establishment between LUs.
We set up a session between a dependent LU (RAATLU44) in the

token-ring-attached PS/2 end node (owned by RAA) and TSO on RAS (application
name RASAT). Figure 82 illustrates.
Figure 82. LU-LU Session Testing with VTAM EN
The display of the primary LU RASAT01 as seen from the ICN RAA is shown in
Figure 83 on page 106.

C RAAAN DISPLAY NET,ID=RASAT01,SCOPE=ALL

′ RAAAN
IST075I NAME = USIBMRA.RASAT01 , TYPE = CDRSC 1
IST479I CDRM NAME = RAA , VERIFY OWNER = NO 2
IST1184I CPNAME = USIBMRA.RAS - NETSRVR = ***NA***
IST206I SESSIONS:
IST1081I ADJACENT LINK STATION = RAAPUAHC 5
IST635I RAATLU44 ACTIV-S F627D164E6B56F61 0 0 USIBMRA
IST924I -------------------------------------------------------------
IST075I NAME = USIBMRA.RASAT01 , TYPE = DIRECTORY ENTRY 6
IST1186I DIRECTORY ENTRY = DYNAMIC LU 7
IST1184I CPNAME = USIBMRA.RAS - NETSRVR = USIBMRA.RAA
IST314I END

Figure 83. Display of PLU RASAT01
The display provides us with a lot of new information about the session, which is
now using an APPN connection.
1 shows that RASAT01 is a CDRSC, just as it would have been in the subarea
environment. However, its owning VTAM is shown as RAA 2 rather than RAS.
This implies that RASAT01 is seen by RAA as an independent LU, which fact is
confirmed in the message IST082I 4. The adjacent link station list is ISTAPNPU
3, meaning that RAA expects to find this independent LU using the APPN
network. The actual link station being used is RAAPUAHC 5, which is the
ANNC link between the two VTAMs.
RAA also knows RASAT01 as a directory entry 6. It is known as a dynamic LU

7, which means that it has been discovered as a result of a successful APPN
search. The main TSO application RASAT has been registered, but the
subsidiary applications do not get registered. RASAT01 has initiated a session
with the SLU RAATLU44, which resulted in this directory entry being added when
RAA recognized the target LU as being one of its own.
The perceptive reader will ask why the session has taken an APPN path when
SORDER=SUBAREA was specified in the start options on both VTAMs. The
reason is that RASAT was registered to RAA by RAS when the CP-CP sessions
were started. The original session request came from RAA′s subarea domain,
and RAA searched its local directories before trying any network searching. Its
subarea directory had no knowledge of RASAT, but its APPN directory did. Thus
RAA knew RASAT as an APPN resource and sent an APPN Locate to RAS to
verify its availability.

Please see Chapter 9, “Searching and Routing in a Mixed Subarea/APPN
Network” on page 151 for a detailed discussion on how the VTAM search
algorithms work.
The NetView Session Monitor display for the same session, Figure 84, provides
us with APPN-related information on the session characteristics:
• The primary LU for the session is reached via the link station (RAAPUAHC)
3 representing the ANNC connection, as seen in the previous display.
• The mode entry M2SDLCQ has neither subarea COS nor APPN COS defined.
Thus there is no subarea COS defined for the session 4, but VTAM has
used the default APPN COS #CONNECT 5 for the APPN part of the session.
A blank (or missing) COS is not permitted in APPN. For a further discussion
of how VTAM selects a class of service when a session traverses both APPN
and subarea networks, please see Chapter 10, “Logmode and COS
Resolution in a Mixed Network” on page 167.
• The adjacent CP at the PLU side of the session is RAS 6 (an APPN node)
and the adjacent CP at the SLU side is CP05137 7. Although CP05137 has
an APPN connection to RAA, this session does not use it and it does not
appear in the NetView APPN Route display (Figure 85 on page 108). The
dependent LU RAATLU44 is directly attached to the NCP boundary function
and uses peripheral subarea protocols for the route extension to CP05137.

NAME RASAT01 SA 000A EL 0000008F | NAME RAATLU44 SA 0005 EL 00000082
--------------------------------------+---------------------------------------
DOMAIN RAAAN C-C PCID USIBMRA.RAS.F627D164E6B56F61 DOMAIN RAAAN
+-------------+ +-------------+
RAA | CP/SSCP | --- --- | |
ISTPUSA0(0000) | SUBAREA PU | APPN TP 01 | SUBAREA PU | RA5NCPX (0000)
+------+------+ SUBA TP 00 +------+------+
| VR 00 |
+------+------+ ER 00 +------+------+
(0085) | CUA | RER 00 | LINK | J0005027
+------+------+ +------+------+
| APPNCOS #CONNECT 5 |
+------+------+ SUBACOS N/A 4 +------+------+
RAAPUAHC(0086) | PU | LOGMODE M2SDLCQ | PU | RAATRPU4(003F)
3 +------+------+ PADJ CP RAS 6 +------+------+
| SADJ CP CP05137 7 |
+------+------+ +------+------+
RASAT01 (008F) | ILU | | LU | RAATLU44(0082)
+-------------+ +-------------+

Figure 84. NLDM Display for LU-LU Session
The Session Monitor APPN route (AR) display, Figure 85 on page 108, shows the
APPN route taken by the session. 8 is APPN TG21 between the VTAMs, the
ANNC connection.
Normally the TG numbers of connections between APPN nodes are allocated

dynamically. The two nodes negotiate the TG numbers starting with 21 and
going up to 239 if there are that many FID2 connections between them. TG
numbers 1-20 are reserved for predefined TG numbers (usually switched
connections which need to be registered in the topology database before being
dialled). TG 240 is reserved for multilink APPN TGs, TG 254 for interchange

transmission groups and TG 255 for VR-TGs. In our definitions for the ANNC link
we defined no TG numbers so we got TG 21.
If you wish to code a preferred TG number, then both CPNAME= and NETID=
parameters must also be coded on the link station definitions.
NLDM.AR APPN SESSION ROUTE CONFIGURATION PAGE 1

-- PRIMARY ---+-- SECONDARY --+--------------- PCID ---------------+- DOMAIN -
NAME RASAT01 | NAME RAATLU44 | USIBMRA.RAS.F627D164E6B56F61 | RAAAN
--------------+---------------+------------------------------------+----------
+---------+
| CP |
|RAS |
+----+----+
TG021 | 8
+----+----+
| CP |
|RAA |
+---------+
COSNAME #CONNECT APPN TP 01

Figure 85. APPN Route
5.6 Changing the Data Host from MDH to EN

In the previous sections of this chapter, we discussed the migration of a subarea
data host RAS to an MDH. In a real network, the user may leave the data host
as an MDH or make it a pure end node with no subarea connections or
SSCP-SSCP sessions. In a pure end node, resources local to the data host can
still establish SSCP-PU and SSCP-LU sessions with the data host VTAM.
Unless there is a specific need to retain a data host as an MDH, it can be made
a pure end node. For example, if VTAM must support BSC 3270 sessions then it
requires a subarea path into the network and must therefore remain an MDH.
Note
The one thing you should never do is have independent subarea and APPN
paths between the same VTAM nodes. This leads to unpredictable session
routes and possibly session failures. If you require both subarea and APPN
connections between two nodes, use a VR-TG to integrate the two.
The migration scenario we are describing is presently in breach of the rule

stated above, as we wish to detail each migration step separately. To continue
the conversion of RAS, we have two choices:
1. To implement VR-TG over the existing subarea connection, as described in
Chapter 7, “VR-Based TG Implementation” on page 131. This might well
have been the first step in the migration because it avoids any temporary
breaches of the rule about parallel APPN and subarea paths.
2. To convert the subarea connection to an APPN BF-TG.

In this section we convert the migration data host RAS to a pure end node and
test the connectivity for various types of session setup. To convert RAS to a
pure end node, we need to make the following changes:
• Remove the HOSTSA parameter from the VTAM start options.
• Change any remaining FID4 connections to FID2. In our test network, we
have a FID4 connection from RAS to NCP RA8NCPX. In 5.6.1, “Convert NCP
Channel Connection to FID2,” we detail the changes required to convert the
NCP connection from FID4 to FID2.
5.6.1 Convert NCP Channel Connection to FID2

In the subarea network, the channel connection from VTAM RAS to NCP
RA8NCPX is defined using a CA major node with LNCTL=NCP. A copy of these
definitions can be found in major node RASCA8, in D.2.5, “Channel Connection
to NCP Subarea 8” on page 235. To convert the NCP channel connection from a
FID4 to a FID2 connection, the following changes are required:
• Create a new local SNA major node on VTAM RAS, defining the connection
to the NCP as type 2.1 with APPN capability.
• Remove the CA major node with LNCTL=NCP from VTAM RAS.
• Change the PU definition parameters in the NCP RA8NCPX major node, to
redefine the channel link as a type 2.1 connection. Once the definitions have
been updated, the NCP module is regenerated and reloaded into the 3745.
The new local SNA definitions created on VTAM RAS for the NCP type 2.1
connection are shown in Figure 86. XID=YES is required for a type 2.1
connection.
Note: A reader of the previous edition of this book has kindly pointed out that
the definitions should include a MAXBFRU keyword. MAXBFRU now defaults to
5 but used to default to 1 until very recently. Unless your I/O buffers are very
large, a MAXBFRU of 1 is likely to result in a connection failure as soon as a
reasonably large PIU arrives. MAXBFRU=15 is more appropriate for an NCP
connection.
*******************************************************************
* CA MAJNODE FOR CHANNEL CONNECTION (TYPE2.1) TO RA8NCPX *
* (FID2 connection) *
*******************************************************************
RASCA8 VBUILD TYPE=LOCAL
RASE20P PU PUTYPE=2,
CUADDR=E20,
XID=YES,
CPCP=YES,
CONNTYPE=APPN
Figure 86. RAS to RA8NCPX Type 2.1 Connection Definitions
The definition changes required in the NCP RA8NCPX to convert the NCP
channel link to a FID2 connection are shown in Figure 87 on page 110. The
keyword PUTYPE is changed from PUTYPE=5 to PUTYPE=2 1 and the
keyword XID=YES 2 has been added.
Note that ISTATUS=INACTIVE 3 on the GROUP definition is not desirable for a
type 2.1 connection. For a subarea connection to a host INACTIVE is required,

but for a FID2 connection it means exactly what it says. We learned this the hard
way, having to activate this connection manually after the NCP was loaded.
***********************************************************************
******** LNCTL=CA definitions for NCP RA8NCPX **********************
***********************************************************************
RA8GCA GROUP LNCTL=CA, X
ISTATUS=INACTIVE3 STOP VTAM ACTIVATING CHANNEL LINK
RA8CE20 LINE ADDRESS=0, 1ST CA. PHYSICAL POSTION 5 X
CA=TYPE6-TPS, 3745 CHANNEL ADAPTOR TYPE X
CASDL=120, INTERVAL BEFORE CHANNEL SLOWDOWN X
CONNTYPE=APPN, APPN CONNECTION X
DELAY=0.2, CHAN ATTN DELAY X
DYNADMP=NONE, NO EP SUBHANNELS TO DUMP DATA OVER X
NCPCA=ACTIVE, NATIVE SUBCHANNEL(NSC) ACTIVE X
TIMEOUT=120 INTERVAL BEFORE CHANNEL DISCONTACT
RA8PCA PU PUTYPE=2, 1 PERIPHERAL TYPE 2.1 CONNECTION X
XID=YES, 2 FOR TYPE 2.1 FID2 X
TGP=CHANNEL, TG profile X
TGN=1
Figure 87. NCP L N C T L = C A Definitions for Type 2.1 Connection
5.6.2 Testing the End Node Configuration

Once the VTAM and NCP definitions have been updated, we reactivate the NCP
from RAA and restart RAS. The following messages at startup confirm that RAS
is a pure end node:
IST020I VTAM INITIALIZATION COMPLETE FOR V4R3

IST1348I VTAM STARTED AS END NODE

Figure 88. EN Initialization
When we display RAS from itself (see Figure 89 on page 111), we see that it is a
CP only 3, and not a CDRM. It has CP-CP sessions with RAA but no SSCP
session. A display of RAS from RAA would show RAS as an adjacent CP and
not a CDRM.

C RASAN DISPLAY NET,ID=RAS,SCOPE=ALL

′ RASAN
IST075I NAME = USIBMRA.RAS , TYPE = HOST CP 3
IST231I APPL MAJOR NODE = VTAMSEG
IST271I JOBNAME = NET28 , STEPNAME = NET28 , DSPNAME = IST1A14E
IST1050I MAXIMUM COMPRESSION LEVEL - INPUT = 0 , OUTPUT = 0
IST206I SESSIONS:
IST635I RAA ACTIV/CP-S F627D164E6E76370 0012 0001 0 0 USIBMRA
IST635I RAA ACTIV/CP-P F7FF6164D4ABC52A 0001 000B 0 0 USIBMRA
IST314I END

Figure 89. Display of RAS as a Network Resource
There are no subarea paths to display as RAS no longer has the ability to
establish ERs and VRs. Although RAS has no “externally known” subarea
number, it still has an internal number. All VTAM pure NNs and ENs use a
number of one (1) for the purpose of network address assignment. VTAM traces
will continue to show network addresses with subarea number 1 being used. All
remote resources (CDRSCs) will have element addresses associated with
subarea 1.
With RAS as an end node, there are two APPN FID2 connections between the
ICN RAA and the end node RAS, as shown in Figure 90 on page 112. The direct
channel link from RAS to RAA is TG 21, and the channel link from RAS to
RA8NCPX is TG 22. The TG numbering simply reflects the order in which the
two links were activated.

Figure 90. FID2 Connection from End Node RAS
5.6.3 Testing LU Session Establishment

As we did in the case of RAS as a migration data host, we tested the following
LU-LU session establishment:
• Log on from a dependent LU owned by RAA to TSO on RAS.
• Log on from a local SNA LU on RAS to TSO on RAA.
• Use APING to establish LU 6.2 sessions between RAS and partner nodes
connected to RAA via the token-ring.
The tests conducted for LU-LU sessions showed that the same sessions could be
established with data host RAS as an end node, as were possible in the
traditional subarea network and RAS as an MDH.
5.7 Benefits of Converting Subarea Data Host to an EN

Once a data host has been converted to a pure end node, some VTAM
definitions are no longer required and can be removed. You no longer need to
maintain them when things change! In our simple environment the following
definitions are redundant after RAS has become an end node:
• On VTAM end node RAS:
− All PATH definitions: RAS is a pure end node and does not use subarea
paths.

− All CDRM definitions: CDRM is for SSCP-SSCP sessions only and RAS
does not understand these. RAS only has one pair of CP-CP sessions to
its network node server.
− All CDRSC definitions: no predefined CDRSCs are required on RAS,
since it owns no LEN connections. All search requests originating on
RAS will be handled by its network node server RAA.
− All adjacent SSCP definitions: since there is only one entry in an
adjacent SSCP table relevant to APPN (see Chapter 9, “Searching and
Routing in a Mixed Subarea/APPN Network” on page 151) there is no
need to code any tables.
− The SORDER= start option can be removed because it is not valid for a
pure end node.
• On the ICN RAA:
− Path definitions to subarea 28 (RAS′s old subarea) can be removed.
RAS does not understand ERs, VRs or FID4 connections.
− CDRM definition for RAS: the SSCP session to RAS has been replaced by
a pair of CP-CP sessions.
− CDRSC definitions for resources owned by RAS: all network resources
which might be search targets (local LUs and most applications) will be
automatically registered with RAA.
− Remove RAS from the adjacent SSCP tables, since RAS is no longer an
adjacent SSCP.
5.8 Hints on Potential Problems

One of the problems we found with activating the ANNC FID2 connection
between RAA and RAS was the XID=YES parameter missing from the PU
statement for the local SNA definitions (refer to Figure 86 on page 109). With no
XID=YES specified on the PU statement, the link station failed to activate and
we saw error messages as shown in Figure 91.
IST1222I WRITE DEVICE 0C12 IS INOPERATIVE, NAME IS RASAHHCT

IST1222I READ DEVICE 0C14 IS INOPERATIVE, NAME IS RASAHHCT
IST259I INOP RECEIVED FOR RASPUAHC CODE = 01
IST619I ID = RASPUAHC FAILED - RECOVERY IN PROGRESS
IST129I UNRECOVERABLE OR FORCED ERROR ON NODE RASPUAHC - VARY
INACT SCHED
IST105I RASPUAHC NODE NOW INACTIVE

Figure 91. Link Station RASPUAHC Activation Problem
The display of TRLE RASAHHCT on RAS (Figure 92 on page 114) shows that the
I/O READ and WRITE devices are still 2 offline and in RESET status. When the
ANNC link between RAA and RAS is successfully activated, the TRLE display is
as in Figure 78 on page 103, with the READ/WRITE devices showing as active
and online.

C RASAN DISPLAY NET,ID=RASAHHCT,SCOPE=ALL

RASAN IST075I NAME = RASAHHCT, TYPE = TRLE
′ RASAN
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST087I TYPE = LEASED , CONTROL = MPC
IST1221I WRITE DEV = 0C12 STATUS = RESET 2 STATE = OFFLINE
IST1221I READ DEV = 0C14 STATUS = RESET 2 STATE = OFFLINE
IST1068I PHYSICAL RESOURCE (PHYSRSC) = RASPUAHC
IST314I END

Figure 92. Status of TRLE on RAS Having Problem
The other mistake we made was not to point the local SNA PU to the correct
TRLE, as discussed in 5.2, “Converting Subarea MPC to ANNC” on page 96.
This causes an activation error with the sense code 08170009.
A potential issue when converting a subarea network to APPN concerns NCP

resources. When a connection between an NCP and another subarea node is
migrated from FID4 to FID2 (BF-TG), two things happen:
1. The NCP now performs a boundary function instead of an INN function,
because APPN connections are seen by the subarea network as peripheral
connections. Since NCP code is more efficient at handling INN than
peripheral connections, you can expect an increase in 3745 processor
utilization.
2. The NCP now becomes aware of individual LU-LU sessions, rather than
having them grouped on VRs. Therefore, more storage will be required in
the 3745.
If your 3745(s) are heavily utilized, there are two things you could do:
• Migrate direct to HPR from subarea. HPR uses minimal resources in
intermediate routing nodes (which an NCP always will be for an HPR
connection) because there is no session awareness in such nodes.
• Implement VR-TG over the subarea connection. This is transparent to the
NCP, but means you will still have to maintain the appropriate subarea path
tables.

Chapter 6. Border Node Support
The APPN border node function is roughly equivalent to subarea SNI, but the
differences are significant. For instance, an SNI border is inside an NCP
whereas an APPN border is between two nodes. The functions and benefits of
an APPN border node are:
• The border node function allows two network nodes with different NetIDs to
connect to each other. This connection provides directory services for the
search process and LU-LU connectivity.
• The border node function allows the partition of a single network into
subnetworks (the subnetworks having the same NetID).
• The border node function allows a network with a single NetID to be
partitioned into several parts, separated by networks of differing NetIDs.
• The border node function allows two network nodes, with the same or
different NetIDs, to isolate their network topologies from one another. This
results in the reduction of network overhead and allows nodes with limited
resources to participate in APPN networking. It also reduces the storage
requirement for the topology database in each of the network nodes within
the subnetwork.
• The APPN COS definitions on both sides are isolated. This reduces the
administrative requirement for coordinated definitions.
• The extended border node function between two VTAM network nodes is
activated with minimal definitions. The border nodes use dynamic processes
to exchange their capabilities and information on reachable networks.
• Cross network connection can be made through channel-to-channel links, as
well as any other APPN connection where at least one partner supports the
border node function. There is no need for an NCP, although NCP
connections can of course be used.
• Sessions can be established across the subnetwork boundaries. Searches
can cross borders but since the network topologies are independent the
route chosen for a session across a border may not be the optimum route.
There are two types of border node in APPN, and two types of border . The node
types are:
• An extended border node (EBN) provides for the multi-subnetwork
environment the full function available within a single network. Some of the
functions may not work as efficiently as within one network, but there are no
restrictions on network design, and any or all session paths can be used.
Today only VTAM (as NN, ICN or CNN) can be an extended border node,
although 2216 support has been announced.
• A peripheral border node (PBN) provides a limited set of functions. For
example:
− A PBN does not support session services extensions.
− The DLUR/DLUS pipe cannot cross a border managed by a PBN, nor can
any session from a DLUR dependent LU.
− Therefore, a peripheral border node supports only PLU-initiated LU 6.2
sessions across a border it manages.
− A PBN cannot partition a network into multiple pieces with the same
NetID.

Today only an AS/400 can be a peripheral border node.
The border types are:

• An extended border is formed by two extended border nodes connected to
each other. This provides the full function of APPN borders. Each border
node is fully aware of the other′s nature and the management of the border
is shared between them.
• A peripheral border is formed when:
− Two peripheral border nodes are connected to each other. One pretends
to be an EN and manages the border.
− An EBN is connected to a PBN; the EBN pretends to be an EN and
manages the border.
− An EBN or a PBN is connected to an NN; the border node pretends to be
an EN and manages the border.
In each case the PBN function relies on the fact that an EN can have a
different NetID from that of its NNS. Because of this “fiddle” various
restrictions apply to a peripheral border. For example, a peripheral border
can only be the first (or last) network boundary a session path crosses; all
those in the middle must be extended borders. It is also undesirable to
connect two networks using multiple peripheral borders. This configuration
can lead to poor session paths or session establishment failures.
6.1 Border Node Implementation

In this chapter we discuss the implementation of border node functions, as part
of the migration of the subarea network to a mixed subarea and APPN network.
For our test network, we make changes to the network definitions to create
APPN subnetworks with border node connections, as in Figure 93 on page 118.
We are connecting an EBN (VTAM) to various network nodes that do not support
border node functions, therefore we are creating peripheral borders managed by
an extended border node . These borders have restrictions on dependent LU
traffic, because not all of the partner NNs support session services extensions.
Also, they must be at the ends of any session path that crosses them. However,
these factors are not of concern in our environment because:
• Our dependent LUs are still directly connected to VTAM boundary functions,
and therefore obey the rules. Their sessions do not cross any borders.
• All our borders are managed by the same VTAM, so they will always be at
the ends of a session path.
To create these APPN subnetworks, we perform the following border

node-related tasks:
• Set up the interchange node RAA as a border node-capable VTAM.
• Set up a subnetwork boundary between the ICN RAA and 3174 network node
CP31742, with both having the same NetID. Because the 3174 does not
provide border node function, VTAM RAA will offer a peripheral subnetwork
boundary to provide APPN subnetwork interconnection. VTAM will pretend
to be an end node served by the 3174. In this case, however, it will not
register its LUs to the 3174 and it will permit itself to be searched on an
APPN broadcast. This is because, as a border node, VTAM must accept
searches to remote resources of which it has no immediate knowledge.

Note that the 3174 does not support session services extensions. Therefore,
no dependent LU sessions can be established across the boundary unless:
− The dependent LUs are directly connected to the NCP (as in our
example); in other words, they are on the 3174 or served by it as a
gateway. In this case RAA owns them and they are in fact in RAA′ s
subnetwork.
− The dependent LUs are serviced by a DLUR on the 3174 side of the
boundary, and RAA is their DLUS. Even then these LUs can only have
sessions with resources in RAA′s subnetwork, never with resources in
their own subnetwork. DLUR and DLUS are described in the HPR and
DLUR Implementation redbook, SC24-5204.
For a medium- to large-sized network, a user may want to set up such a
subnetwork boundary to stop the 3174 or a similar box from participating in
the network topology database exchange.
• Set up a subnetwork boundary between the ICN RAA and the CS/2 network
node CP05160, with the CS/2 in a different NetID. Since CS/2 does not
provide border node function, VTAM RAA will offer a peripheral subnetwork
boundary to provide APPN subnetwork interconnection.
Again, there will be some restrictions on dependent LU sessions across the
network border because CS/2 does not support session services extensions.
In a user network with numerous remote locations, a user may want to set
up such a subnetwork boundary to stop the CS/2 or a similar box, with
limited processing and storage resource, from participating in the network
topology database exchange and updates of the backbone network.
However, in such a case the branch extender node function may be
preferable, as it provides benefits that a peripheral border cannot give.
Branch extender node is described more fully in HPR and DLUR
Implementation .
You should avoid the use of peripheral borders when connecting two VTAMs (by
configuring one VTAM as an EBN and the other as an NN). Dependent LU
sessions will work (because both partners support session services extensions),
but the other restrictions on peripheral borders still apply. Thus:
• A peripheral border cannot be an intermediate border on a session path that
traverses more than three subnetworks.
• Multiple peripheral borders between the same subnetworks will not work
reliably.
• If you use DLUR/DLUS, then:
− If the DLUR/DLUS sessions cross the border, the EBN must be on the
DLUS side of the border.
− The dependent LU′s session partner (the PLU) must be connected to the
DLUS by an extended border (two EBNs).
Figure 93 on page 118 illustrates how we set up the APPN borders in our test
environment.
Chapter 6. Border Node Support 117

Figure 93. Diagram Showing APPN Subnetworks
Note:
• If you use an NCP to provide the boundary function for the intersubnetwork
connection (in other words, if one side of the APPN border is an NCP) you
need NCP V7R1 or later.
• If you use HPR across an APPN border where one side (or both) is an NCP,
you need NCP V7R5 or later.
• An APPN border cannot be set up across a connection network. In other
words, any connection between two network nodes with different NetIDs
must be explicitly defined.
6.1.1 Definitions for Border Node Function

To enable APPN multiple network connectivity support, you need to code only
the BN=YES start option on a VTAM network node (that is, NODETYPE=NN
must also be specified). In addition, there are some controls available in the
form of VTAM start options and VTAM tables which allow you to customize the
VTAM border node function. For a description of the customization controls
available, please refer to the chapter “Implementing an APPN network” in the
VTAM Network Implementation Guide , SC31-8563.
6.1.1.1 VTAM Start Options

For our ICN, RAA, we added the following VTAM start options to the ones
defined earlier while setting up RAA as an ICN (refer to Figure 21 on page 62):

BN=YES 1
BNDYN=LIMITED 2 DEFAULT
BNORD=PRIORITY 3 DEFAULT
SNVC=3 4 DEFAULT
Figure 94. Border Node-Related VTAM Start Options
Notes:
1 is required to specify that this VTAM node is to provide the extended
border node function.
2, 3, and 4 are meaningful only when BN=YES is specified.
2 specifies that all active border nodes, native or nonnative, may be
added to the routing list (adjacent cluster table), provided certain
conditions are met. These conditions effectively allow dynamic rerouting
of search requests only when the target LU has the NetID of an adjacent
network, or when a previous incoming search has identified where that
NetID is located. BNDYN is roughly equivalent to SSCPDYN in an SNI
environment.
Coding BNDYN=FULL allows all searches to be routed to all adjacent

networks, and is not recommended in a large network. Coding
BNDYN=NONE forces you to define the routing criteria manually.
3 specifies that for cross-subnet searches, search preference is given to

nodes for which the most recent search was successful and to nodes
whose NetID matches the target LU′s NetID. BNORD is roughly
equivalent to SSCPORD in an SNI environment.
4 specifies that this border node VTAM will search a maximum of three
subnetworks, when looking for a resource. To allow a search request to
traverse at least one APPN border, a value of SNVC=2 is required.
SNVC=1 restricts a search to just its native network.
For further details on these VTAM start options, refer to the chapter “Start
Options” in the VTAM Resource Definition , SC31-8565.
6.1.1.2 Adjacent Cluster Routing List

The adjacent cluster routing list allows you to define which adjacent APPN
subnetworks VTAM should search. This list is used when a border node
determines it is unable to satisfy a search request from within its own domain.
The adjacent cluster routing function is similar to the adjacent SSCP search
function in a subarea environment.
For our network, we set up an adjacent cluster routing list for border node RAA,
as in Figure 95 on page 120.

VBUILD TYPE=ADJCLUST
DEFAULT NETWORK 5
NEXTCP CPNAME=USIBMRA.RAA
*
USIBMRA NETWORK NETID=USIBMRA 6
NEXTCP CPNAME=USIBMRA.RAA
NEXTCP CPNAME=USIBMRA.CP31742
*
USIBMRAX NETWORK NETID=USIBMRAX 7
NEXTCP CPNAME=USIBMRAX.CP05160
Figure 95. Adjacent Cluster Routing List for RAA Border Node
Notes:
5 is the routing list (with no NETID parameter), which will be used as a
default when:
• A non-network qualified request is received
• A network qualified request is received and the network identifier is
not defined in any other NETWORK statements
The entry for RAA itself has a special meaning. It means:

• If the search request comes from the native network, ignore this entry.
• If the search request comes from an adjacent network (across a
border), issue a broadcast (or ask the CDS if there is one) in the
native network.
6 is the routing list used when USIBMRA is the network ID specified on
the request.
7 is the routing list used when USIBMRAX is the network ID specified on
the request.
The BNDYN and SNVC parameters can be specified in the ADJCLUST

table, if you want closer control of cross-border routing. Otherwise, as as
in our example, the values for these parameters will be taken from the
VTAM start options (refer to 6.1.1.1, “VTAM Start Options” on page 118).
Because we have BNDYN=LIMITED, VTAM will dynamically add entries to the

table when it finds that either:
• The target of the search request matches the NetID of an adjacent network,
or
• The target network is already known from a previous search originating from
it.
Coding BNDYN=NONE will ensure that VTAM does not forward any search
unless the target network is predefined in the adjacent cluster table.
Thus, looking at the entry 6 for USIBMRA (the native network):
• If the 3174 (CP31742) sends in a search for USIBMRA. node , RAA will search
its own network. It will not forward the search to CP31742 for obvious
reasons. Nor will it forward the search to the CS/2 node (CP05160), despite

BNDYN=LIMITED, since the NetID of CP05160 (USIBMRAX) does not match
the NetID of the target (USIBMRA).
• If a node in the native network sends in a search for USIBMRA. node , RAA
will not search its own network as part of the border node function (although
it will do so if it is also the NNS or the CDS responsible for such a search).
RAA will forward the search to CP31742, but not to CP05160. The coding of
the adjacent cluster table in this way ensures that both networks with a
NetID of USIBMRA are searched for a target resource.
6.1.1.3 Mapping APPN Class of Service

Because the topology databases are not exchanged across a subnetwork
boundary, route calculation is done independently for each subnetwork.
Therefore, a valid APPN class of service is required in each subnetwork which a
session path is to cross. As you may have experienced with the COS table in a
subarea environment, it is likely that you will find different APPN COSs defined in
different APPN subnetworks. Thus, there is the need for a border node COS
mapping table, BNCOSMAP, to define how an APPN COS name from an adjacent
APPN subnetwork (nonnative COS name) should be mapped to the native
subnetwork COS name.
In the case of an extended border (two EBNs connected), the mapping of

non-native APPN COS to native APPN COS will be done by the EBN on the SLU
side of the session . With a peripheral border (which we have), the node which
does not understand borders (3174, CS/2) cannot do this so VTAM will have to
use the table to map in both directions.
In our network, we rely on the VTAM start option APPNCOS=#CONNECT to

ensure that all session requests with unknown APPN COS names are assigned a
valid COS. If an adjacent subnetwork uses an APPN COS unknown in the native
network, this will result in all sessions originating in the adjacent network, and
all unknown-COS sessions in the native network, using the same class of
service. This may not be acceptable; you may find batch and interactive, secure
and unsecure sessions using the same routes and priorities.
The recommendation is to identify the unmatched APPN COS and include it in

the border node COS mapping table. For a further description and examples,
refer to ″Border Node COS Mapping Definitions″ in VTAM Resource Definition
Reference , SC31-8565.
6.1.1.4 Definition Changes

The definition changes required for creating subnetwork boundaries for the 3174
node (CP31742) and CS/2 node (CP05160) are minimal.
• To create a subnetwork boundary between VTAM RAA and the
SDLC-attached 3174 (CP31742), with both having the same NetID, we only
need to add the NATIVE=NO parameter 7 on the PU definitions (P3174C1)
for the 3174 in NCP RA5NCPX (as shown in Figure 96 on page 122). When
the border node VTAM sees the NATIVE=NO parameter, it will create a
subnetwork boundary for the APPN connection to the other node.
This is the only circumstance in which a specific definition for a border is
required. If VTAM as an EBN finds a strange NetID in an adjacent network
node it will automatically set up a peripheral border.

• To create a subnetwork boundary between VTAM RAA and the
SDLC-attached CS/2 (CP05160), with the CS/2 having a different NetID, we
need to:
− Ensure that the adjacent link station (RA8CM2A) is given the same NetID
as the adjacent node. In our case we do not need to define anything,
since the default XNETALS start option allows an APPN connection to
assume the correct NetID. If we code the NETID keyword as shown 8
then the NetID presented by the adjacent node must match it or the
connection will fail.
− In CS/2, change the value of the network ID field on the Local Node
Characteristics panel, from USIBMRA to USIBMRAX. We also changed
the NetID of the remote end node CP05221 to USIBMRAX. This is not
strictly necessary (an EN can take any NetID it likes) but it is probably a
better reflection of how a real network would be set up. Note that if we
had not done this we would have needed to change our adjacent cluster
tables; by default VTAM will not look for a USIBMRA. node in the
USIBMRAX network.
Without any extra definitions, VTAM will establish a peripheral border between
itself and CP05160, simply because it will discover a non-native NetID on the
adjacent connection.
P3174C1 PU ADDR=C1, POLL ADDRESS = C1

...
PUTYPE=2,
NATIVE=NO,7 FOR SUBNETWORK CONNECTION
XID=YES, FOR T2.1 NODE
DYNLU=YES,
....
Figure 96. NCP Definition Change for Network Node CP31742 (3174)
RA8CM2A PU ADDR=C1,
...
PUTYPE=2,
NETID=USIBMRAX,8 FOR SUBNETWORK CONNECTION
XID=YES, FOR T2.1 NODE
...
Figure 97. NCP Definition Change for Network Node CP05160 (CS/2)
6.2 Test Results

To test the border node function, we start VTAM RAA with the definitions
discussed in 6.1.1, “Definitions for Border Node Function” on page 118. Before
we activate the links to the newly defined subnetworks, we display the APPN
topology on VTAM RAA.
VTAM displays confirm that RAA is now defined as a border node 1 (refer to
Figure 98 on page 123) but as it has no cross-border connections, it is not acting
as one yet ( 2 and 3 in the topology display in Figure 99 on page 123).

* RAAAN D NET,VTAMOPTS,OPTION=BN

′ RAAAN
IST1348I VTAM STARTED AS INTERCHANGE NODE
IST1189I BN = YES 1
IST314I END

Figure 98. VTAMOPTS for RAA as Border Node
* RAAAN D NET,TOPO

′ RAAAN
IST1307I 11/28/95 17:09:35 1 2 4 2 1 1 0 2
IST314I END
* RAAAN D NET,TOPO,ID=RAA,LIST=ALL
′ RAAAN
IST1297I ICN/MDH CDSERVR RSN
IST1298I YES YES 202
IST1223I BN NATIVE
IST1224I NO 3 YES

Figure 99. Network Topology without any Border Node Connections
With the ADJCLUST definitions (see Figure 95 on page 120) now active, we
display the adjacent cluster list on RAA. Refer to Figure 100 on page 124 for
details. Note that the entries defined in the adjacent cluster list (Figure 95 on
page 120) are listed with a TYPE of DEFINED 4; that is, they are the predefined
entries in the adjacent cluster table. Because the links to the two nodes,
CP31742 and CP05160, have not yet been activated from RAA, they both are
shown as NOT ACTIVE 5.

* RAAAN D NET,ADJCLUST,SCOPE=ALL
′ RAAAN
IST350I DISPLAY TYPE = ADJACENT CLUSTER TABLE
IST1325I DEFINED TABLE FOR DEFAULT_NETID DYNAMICS = LIMITED
IST1326I CP NAME TYPE STATE STATUS SNVC
IST1327I USIBMRA.RAA 4DEFINED ACTIVE *** N/A *** N/A
IST924I --------------------------------------------------------
IST1325I DEFINED TABLE FOR USIBMRA DYNAMICS = LIMITED
IST1327I USIBMRA.RAA 4DEFINED ACTIVE *** N/A *** N/A
IST1327I USIBMRA.CP31742 4DEFINED NOT ACTIVE5NOT SEARCHED 003
IST924I --------------------------------------------------------
IST1325I DEFINED TABLE FOR USIBMRAX DYNAMICS = LIMITED
IST1326I CP NAME TYPE STAT STATUS SNVC
IST1327I USIBMRAX.CP051604DEFINED NOT ACTIVE5NOT SEARCHED 003
IST314I END

Figure 100. ADJCLUST Display on RAA without any Border Node Connections
Next, we activate the connections from RAA to the two nodes, CP31742 and
CP05160, and establish CP-CP sessions between RAA and each of the two
nodes.
Once the CP-CP sessions are active, we display the network topology on RAA
and find that some changes have occurred. Refer to Figure 101 on page 125 for
details. The topology display now shows that there is one border node 6
active in this subnetwork. We can also see that this border node is RAA itself
7.
From the list of APPN transmission groups originating at RAA, we can also see
that the links to CP31742 and CP05160 now have a TGTYPE of INTERCLUST 8;
that is, they are links to different APPN clusters or subnetworks.

* RAAAN D NET,TOPO

′ RAAAN
IST1307I NONE 1 4 4 2 1 1 16
IST314I END
′ RAAAN
IST1297I ICN/MDH CDSERVR RSN HPR
IST1298I YES YES 212 NONE
IST1223I BN NATIVE
IST1224I YES7 YES
IST1299I TRANSMISSION GROUPS ORIGINATING AT CP USIBMRA.RAA
IST1357I CPCP
IST1300I DESTINATION CP TGN STATUS TGTYPE VALUE WEIGHT
IST1301I USIBMRA.RAS 21 OPER ENDPT YES *NA*
IST1301I USIBMRA.RAS 255 OPER ENDPT VRTG YES *NA*
IST1301I USIBMRA.CP31742 21 OPER 8 INTERCLUST YES *NA*
IST1301I USIBMRA.CP05147 21 OPER INTERM YES *NA*
IST1301I USIBMRA.CP05150 21 OPER ENDPT NO *NA*
IST1301I USIBMRA.CP05137 21 OPER ENDPT YES *NA*
IST1301I USIBMRAX.CP05160 21 OPER 8 INTERCLUST YES *NA*
IST314I END

Figure 101. Topology Display with Border Node Connections
The display for the adjacent cluster list (refer to Figure 102 on page 126) now
shows both the nodes, CP31742 and CP05160, as ACTIVE 1. The STATUS field
in the display shows the result of the last search sent to this node. Because no
search requests for a resource have been sent to these nodes, the status is
correctly reflected as NOT SEARCHED 2.
Another point worth noting is the fact that the two CPs have been dynamically
added 3 to the default adjacent cluster table, and can be used for future
session routing. The dynamic addition of CPs to the adjacent cluster table is
dependent on the value of the BNDYN parameter in the VTAM start options or in
the ADJCLUST table. Since we have BNDYN=LIMITED VTAM has added the
entries for the adjacent CPs to the default table. The default table is used for
non-network-qualified requests, so all adjacent NetIDs are potentially valid
search targets for such requests.

′ RAAAN
IST1327I USIBMRA.RAA DEFINED ACTIVE *** N/A *** N/A
IST1327I USIBMRA.CP317423DYNAMIC ACTIVE NOT SEARCHED 003
IST1327I USIBMRAX.CP05160 DYNAMIC ACTIVE NOT SEARCHED 003
IST924I ---------------------------------------------------------
IST1327I USIBMRA.CP31742 DEFINED ACTIVE1 NOT SEARCHED2003
IST924I ---------------------------------------------------------
IST1327I USIBMRAX.CP05160 DEFINED ACTIVE1 NOT SEARCHED2003
IST314I END

Figure 102. ADJCLUST Display on RAA with Border Node Connections
With the links now active between subnetworks, we test the role of the adjacent
cluster list while carrying out search requests. We make use of the VTAM D
NET,APING,ID= command to initiate a search request for a remote resource. Due
to the manner in which VTAM RAA start options have been defined, it will search
both the subarea and APPN networks for an unknown resource. In this section,
we are only interested in the APPN search.
6.2.1 Search for Nonexistent Resource

We issue an APING from RAA to a resource USIBMRA.RRRRR, which we know
does not exist. Since we have specified a fully qualified resource name, VTAM
will use only the adjacent cluster table for NetID USIBMRA. Once the session
setup fails, we display the adjacent cluster table (refer to Figure 103 on
page 127). The display shows a change in the STATUS field for node CP31742,
from NOT SEARCHED to NOT FOUND 4. This implies that the node CP31742
has been searched but the resource was not found.

′ RAAAN
IST1327I USIBMRA.CP31742 DYNAMIC ACTIVE NOT SEARCHED 003
IST924I --------------------------------------------------------
IST1327I USIBMRA.CP31742 DEFINED ACTIVE NOT FOUND4 003
IST924I --------------------------------------------------------
IST1327I USIBMRAX.CP05160 DEFINED ACTIVE NOT SEARCHED 003
IST314I END

Figure 103. ADJCLUST Table Status after Test 1
6.2.2 Search for Real Resource

We issue an APING from RAA for a resource USIBMRAX.CP05221, which is not in
our topology database, but exists in subnetwork USIBMRAX. It is, in fact, the
CS/2 end node served by USIBMRAX.CP05160.
Because we have specified a fully qualified resource name, VTAM will use only
the adjacent cluster table for NetID USIBMRAX. Once the session setup
succeeds, we display the adjacent cluster table (refer to Figure 104).

′ RAAAN
IST1327I USIBMRA.CP31742 DYNAMIC ACTIVE NOT SEARCHED 003
IST924I --------------------------------------------------------
IST1327I USIBMRA.CP31742 DEFINED ACTIVE NOT FOUND 003
IST924I --------------------------------------------------------
IST1327I USIBMRAX.CP05160 DEFINED ACTIVE FOUND 5 003
IST314I END

Figure 104. ADJCLUST Table Status after Test 2
The display shows a change in the STATUS field for node CP05160, from NOT
SEARCHED to FOUND 5. This implies that the node CP05160 has been
searched and the resource was found.

6.3 Benefits and Issues on Border Node
The benefits of using APPN network borders are:
• By creating a subnetwork boundary, the two network nodes isolate their
network topology databases from one another. Therefore, you reduce the
number of TDUs flowing within the subnetwork.
• This also reduces the storage requirement for the topology database at each
network node.
• It also reduces some other network flows. For example, a broadcast search
will not cross a network boundary. In our exercise, a search for USIBMRA
was not forwarded to USIBMRAX.CP05160, nor was a search for USIBMRAX
forwarded to USIBMRA.CP31742.
However, there are some issues which must be considered as well:

• The resource registration to a central directory server cannot take place
across a subnetwork boundary. NNs use the topology database to locate the
CDS (if one exists), but the TDBs in APPN subnetworks are isolated from
each other.
• Route calculation is done separately for each subnetwork. Routes are
optimal for a subnetwork, not necessarily end to end.
• Full function borders are available only where two VTAM NNs are connected;
on the other hand the functions of a peripheral border are quite restrictive.
This is very important to remember when converting an SNI border to an
APPN border. Please see 3.1.2, “VTAM/NCP and APPN Node Roles” on
page 26 for an example of what could go wrong in this situation.
• The branch extender node function has been designed to provide most of the
function of an extended border node without the costs associated with VTAM
and System/390 processors:
− Like an EBN it isolates network topologies, reduces TDU flows and
reduces NN storage requirements.
− Unlike a PBN it allows DLUR / DLUS functions and multiple boundary
crossings on a session path.
− Unlike EBN or PBN, it forwards CDS registrations across a border, thus
reducing network searches.
However, the branch extender node function is not suitable for connecting
two enterprises and there are some restrictions even when it is used for
connecting branch locations within a single enterprise. For example, if you
use DLUR/DLUS then the DLUR function must be on the branch extender
node and not in the downstream network. Please refer to HPR and DLUR
Implementation , SG24-5204, for details of the branch extender node function.
• Border node connections cannot be defined over virtual route-based
transmission groups, since a VR cannot cross a (SNI) network boundary.

6.4 Recommendations on APPN Borders
Connecting networks with extended border node connections is quite simple, as
compared to SNI. You get an extended border node connection by starting both
VTAMs as border nodes at the connection endpoints.
The recommendation is to use extended border node connections where

possible. Use branch extender node where a border is required and the
expense of a VTAM processor cannot be justified. Branch extender node function
is available in the 2210 and 2216, which will give better value and more function
than an AS/400. CS/2 also supports the branch extender node function, and
CS/NT will do so in the near future. Peripheral border node connections should
only be considered where all other options have been exhausted.
Use the product-supplied APPN COS names as much as possible. Often the
APPNCOS=#CONNECT start option will serve you well.
If you have a large network and require a tighter control over cross-network
searching, then define an adjacent cluster table and use BNDYN=LIMITED or
even BNDYN=NONE. BNDYN=FULL is recommended only for small networks
where a search sent out to all adjacent subnets will have minimal impact.
Define the SNVC (subnet visit count) to an appropriate value, such that it covers
all the search paths you may have in your network. Do not forget to allow for
backup paths in case of a failure; such backup paths may be longer than the
primary paths.
Do not forget that an APPN end node need not have the same NetID as its NN
server. Therefore, converting an SNI-attached data host to an end node removes
a subnetwork boundary without the need to change the NetID.
Do not mix extended and peripheral borders between the same two networks.
This can result in session failures or poor route selection.
If you use peripheral borders to connect a network, have all the connections
owned by a single NN and connect them only to a single EBN in the other
network. This way you will avoid the search looping problems that lead to
session failures and undesirable routes.

Chapter 7. VR-Based TG Implementation
A virtual route-based transmission group (VR-based TG or VR-TG) connects two

APPN-capable VTAM nodes through a subarea network and allows them to act
as APPN peers. The VR-TG (whose TG number is always 255) then functions as
any other TG in an APPN network. Only one VR-TG may be defined between any
two VTAM nodes.
The VR-TG actually represents all the possible VRs between the two VTAMs and
their attached NCPs. When an APPN network node calculates a route which
includes a VR-TG between two VTAMs, the VR-TG partner acting as SSCP(PLU)
selects a subarea virtual route using the normal subarea mechanisms. This
selected VR then becomes the actual session path across the VR-TG.
Since an underlying VR is always assigned to sessions using VR-TGs, both APPN

and subarea functions must be enabled on both VTAM nodes. This means that
each partner node must be either an interchange node or a migration data host.
For a detailed description of VR-TGs, refer to the chapter “Implementing a

Combined APPN and Subarea Network” in VTAM Network Implementation Guide ,
SC31-8563.
The benefits of VR-TG are as follows:

1. The VR-TG function maps APPN topology on to a subarea network. A
network node that calculates an APPN route can therefore take account of
the whole network (subarea and APPN parts), and pick the best route across
it. Without VR-TG, the route is calculated in small pieces, being disjoint at
every APPN/subarea interchange; it is therefore much less likely that the
optimal route will be chosen.
An extra benefit is that existing multilink TGs in subarea networks can now
be used for APPN connectivity, even though they carry FID4 traffic. The
additional resilience against failure of a single link is available for APPN
traffic. Base APPN TGs are always single-link, although HPR supports
MLTGs.
2. VR-TG allows the migration of a subarea network to full APPN connectivity,
without any change to the physical network. Multilink TGs can be used
without change, and there is no need to establish parallel FID4 and FID2
connections between sites. Without VR-TG:
• FID4 connections result in disjoint topology and inefficient routing.
• FID2 connections do not allow MLTGs or SSCP takeover, and use more
NCP resources.
• Parallel FID4 and FID2 connections are wasteful and can result in session
failures.
With VR-TG:
• FID4 connections support integrated topology and optimum routing.
• FID4 connections allow MLTGs and SSCP takeover, and use less NCP
resource.
3. With VR-TG, the network topology is seen as a single entity instead of being
divided into several APPN and subarea pieces. Moreover, the route of any
session is seen correctly by its partners, instead of “disappearing” at every
interchange. Network management is made easier because there is no need

to consult several management agents to obtain session or topology
information.
Note
It is highly undesirable to maintain independent parallel APPN and subarea

connections between two nodes. If you require both FID2 and FID4
connectivity between VTAMs, you should always use VR-TG to integrate the
two types of network.
7.1 Definitions
To illustrate VR-TG, we make a small change to the network used in previous
chapters and remove the MPC connection between RAA and RAS. This
represents a typical situation where a remote data host is connected to a
backbone NCP owned by the CMC. If we require subarea access to this host (it
may be a backup CMC, for instance) then the connection between RAS and RAA
must be FID4. If we also require APPN connectivity (for DLUR/S, for example)
then VR-TG is necessary.
In our example we have migrated RAS to an MDH (it cannot be a pure end node
if VR-TG is used) and we will set up a VR-TG connection between RAA and RAS.
Figure 105 depicts the network diagram. The VR-TG between the two nodes
comprises all the VR/TP combinations between:
• Subarea 10 and subarea 28
Figure 105. VR-Based TG between RAA and RAS

7.1.1 VTAM Definitions for VR-Based TG
There are two ways to define a VR-TG between two VTAM APPN nodes:
1. Code VRTG=YES as a start option, in which case VTAM will attempt to use
VR-TG with all its CDRM partners. You also can issue the MODIFY
VTAMOPTS command to set the VRTG (and VRTGCPCP) options.
2. Code VRTG=YES on the individual CDRM definition statements for the
adjacent VTAMs. This method is recommended because it allows better
control over the VR-TG connections.
In our setup, we will use the second option (that is, code VRTG=YES on the
individual CDRM definitions). Note that two VR-TG partners must be adjacent in
the subarea sense; in other words they must have an SSCP-SSCP session. The
SSCP-SSCP session is used to exchange basic APPN connection information that
would flow on XIDs on a FID2 connection.
Figure 106 shows the CDRM definitions we code on the VTAM nodes.
***************************************************
* CDRM MAJOR NODE FOR RAA
* SUBAREA 10 AS AN ICN AND SUBAREA 28 AS AN MDH
***************************************************
VBUILD TYPE=CDRM
NETWORK NETID=USIBMRA
RAA CDRM SUBAREA=10,CDRDYN=YES,CDRSC=OPT
RAK CDRM SUBAREA=20,CDRDYN=YES,CDRSC=OPT
RAS CDRM SUBAREA=28,CDRDYN=YES,CDRSC=OPT,VRTG=YES, 1
VRTGCPCP=YES 2
***************************************************
* CDRM MAJOR NODE FOR RAS
* SUBAREA 10 AS AN ICN AND SUBAREA 28 AS AN MDH
***************************************************
VBUILD TYPE=CDRM
RAA CDRM CDRDYN=YES,CDRSC=OPT,SUBAREA=10,VRTG=YES, 1
VRTGCPCP=YES 2
RAK CDRM CDRDYN=YES,CDRSC=OPT,SUBAREA=20
RAS CDRM CDRDYN=YES,CDRSC=OPT,SUBAREA=28
Figure 106. CDRM Major Nodes with VR-Based TG parameters
Notes:
1 indicates that a VR-TG connection should be requested when the

SSCP-SSCP session is established to the adjacent VTAM. When this
parameter is coded at both VTAMs as above, then a VR-TG is activated
automatically when the SSCP session with the adjacent VTAM is
established.
Each VR-TG is reported to the APPN topology database, and therefore has
TG characteristics just as any other APPN TG. However, VTAM cannot
know the true TG characteristics for a VR-TG and so they default to
CAPACITY=8K and other values which are likely to be undesirable.
Chapter 7. VR-Based TG Implementation 133

Note
We recommend that you code the TGP keyword on your CDRM

definitions to give VTAM the correct TG values. Failure to do so will
probably result in the VR-TG being rejected for session paths unless
no alternatives exist.
2 indicates that CP-CP sessions will be supported over the VR-based
TG. If there are no CP-CP sessions active between the two VTAM nodes,
CP-CP session establishment is automatically initiated when the VR-TG is
activated. A VR-TG is treated the same way as any other APPN
connection: if CP-CP sessions are to be set up then they will use the first
connection to be activated, whether VR-TG or FID2.
7.2 Testing VR-TG

Before activating the definitions for VR-TG, we display the topology from RAA.
As you can see from the display (Figure 107), there are no active transmission
groups from RAA to RAS. The entry from previous tests is still in the topology
database but is shown as INOP 3. At this point, there is only an SSCP-SSCP
session between the two VTAMs, RAA and RAS; no CP-CP sessions exist.

′ RAAAN
IST1223I BN NATIVE
IST1224I YES YES
IST1357I CPCP
IST1301I USIBMRA.CP31742 21 OPER INTERCLUST YES *NA*
IST1301I USIBMRAX.CP05160 21 OPER INTERCLUST YES *NA*
IST1301I USIBMRA.RAS 21 3 INOP ENDPT YES *NA*
IST314I END

Figure 107. Topology Display for RAA with No VR-Based TG
For the test, we use the APING transaction program from a CM/2 network node,
CP05147, to establish LU 6.2 sessions to the VTAM host RAS. The physical
network for the two session partners is as indicated in Figure 108 on page 135.

Figure 108. Network Diagram for VR-Based TG
With no VR-TG activated, we establish the sessions between CP05147 and RAS.
The NetView Session Monitor session configuration display (refer to Figure 109)
shows that the session path goes from CP05147 1 to NCP RA5NCPX 2 and
then via ER 1 3 to its destination LU RAS 4. Figure 110 on page 136 shows
the detailed route for ER 1. This route goes from RA5NCPX (subarea 5) 5 to
RA8NCPX (subarea 8) 6 to RAS (subarea 28) 7. So the complete route taken
is as shown below:
CP05147 - RA5NCPX - RA8NCPX - RAS

NAME CP05147 SA 0005 EL 0000017C | NAME RAS SA 001C EL 00000008
--------------------------------------+---------------------------------------
DOMAIN RAAAN PCID USIBMRA.CP05147.ECC35935CE769767 DOMAIN RASAN
+-------------+ +-------------+
| | --- --- | CP/SSCP | RAS
RA5NCPX (0000) | SUBAREA PU | APPN TP 02 | SUBAREA PU | ISTPUS28(0000)
2 +------+------+ SUBA TP 00 +------+------+
| VR 01 |
+------+------+ ER 01 3 +------+------+
J0005025 | LINK | RER 02 | LU | RAS 4 (0008)
+------+------+ +-------------+
| APPNCOS #INTER
+------+------+ SUBACOS N/A
RAATRPU3(003D) | PU | LOGMODE #INTER
+------+------+ PADJ CP CP05147
| SADJ CP N/A
+------+------+
CP05147 (017C) | ILU |
1 +-------------+

Figure 109. Session Configuration with No VR-TG

NLDM.ER SPECIFIC ER CONFIGURATION PAGE 1

------------------------------------------------------------------------------
SUBAREA1 00000005 SUBAREA2 0000001C ER 01 | NODES (TOTAL/MIGRATION): 03/00
------------------------------------------------------------------------------
+-----+ NAME: RA5NCPX

| INN | SA: 00000005 5
+--+--+ SSCP: RAA
|
1) TG008
|
+--+--+ NAME: RA8NCPX
| INN | SA: 00000008 6
+--+--+ SSCP: RAA
|
2) TG001
|
+--+--+ NAME: N/A
| INN | SA: 0000001C 7
+--+--+ SSCP: N/A

Figure 110. Explicit Route Configuration with No VR-TG
Looking at the APPN route configuration display (Figure 111), we get an APPN
view of the session route. We see that the session is going via TG21 from
CP05147 to RAA 8; then from RAA it uses a subarea route to reach its
destination 9. The TG labelled “IN-TG” is an interchange TG. To the APPN
network this (always TG 254) represents a TG to an end node served by the ICN;
in fact it is a subarea route adjacent to an APPN route.

NAME CP05147 | NAME RAS | USIBMRA.CP05147.ECC35935CE769767 | RAAAN
--------------+---------------+------------------------------------+----------
+---------+
| CP |
|CP05147 |
+----+----+
TG021 | 8
+----+----+
| CP(ICN) |
|RAA |
+----+----+
IN-TG | 9
+----+----+
| SUBAREA |
| NODE(S) |
+---------+

Figure 111. APPN Route Configuration with No VR-TG
Next, we turn on the VR-TG by deactivating the respective CDRM major nodes
on RAA and RAS, and reactivating them with the new VR-TG definitions, as
shown in Figure 106 on page 133. The deactivation of CDRM major nodes is
done using the SAVESESS keyword, so that existing LU-LU sessions are not
disrupted.

When the CDRM session is established between RAA and RAS, we get
additional messages, as follows, to indicate that the VR-TG connection (TG 255)
has become active and that the CP-CP sessions have also been established:
IST093I RAS ACTIVE

IST1086I APPN CONNECTION FOR USIBMRA.RAS IS ACTIVE - TGN = 255
IST1096I CP-CP SESSIONS WITH USIBMRA.RAS ACTIVATED

Figure 112. VR-TG activation
The APPN topology as seen from RAA (refer to Figure 113) now shows an active
APPN transmission group from RAA to RAS with TGN=255 1 with a TGTYPE of
VRTG. Note that TG21 to RAS is still in the topology database with an INOP
status 2.

′ RAAAN
IST1223I BN NATIVE
IST1224I YES YES
IST1357I CPCP
IST1301I USIBMRA.CP31742 21 OPER INTERCLUST YES *NA*
IST1301I USIBMRAX.CP05160 21 OPER INTERCLUST YES *NA*
IST1301I USIBMRA.RAS 21 2 INOP ENDPT YES *NA*
IST1301I USIBMRA.RAS 255 OPER 1 ENDPT VRTG YES *NA*
IST314I END

Figure 113. Topology from RAA with VR-TG
With the VR-TG connection now active, we terminate the session between
CP05147 and RAS, and delete any dynamically created CDRSCs so we start with
a clean directory.
We then reestablish the session between CP05147 and RAS, using the CM/2
APING transaction program.
The NLDM displays for the session configuration and the ER are the same as
shown in Figure 109 on page 135 and Figure 110 on page 136, but the APPN
session route configuration has changed. As you can see from the APPN route
display (Figure 114 on page 138), the end-to-end connection from CP05147 to
RAS now appears as an APPN connection, where VR-TG 3 is being used for
the hop between RAA and RAS.
Note that, due to a bug in VTAM V4R3, RAS is shown as an ICN in the figure. It
is, of course, an MDH.


NAME CP05147 | NAME RAS | USIBMRA.CP05147.ECC35935CF769767 | RAAAN
--------------+---------------+------------------------------------+----------
+---------+
| CP |
|CP05147 |
+----+----+
TG021 |
+----+----+
| CP(ICN) |
|RAA |
+----+----+
VR-TG | 3
+----+----+
| CP(ICN) |
|RAS |
+---------+

Figure 114. APPN Session Route Configuration with VR-Based TG
So for the example discussed, the APPN route will now look like Figure 115.
Figure 115. APPN Route Diagram with VR-Based TG
The net result of setting up VR-based TG between RAA and RAS is that we have
managed to overlay an APPN route over an existing subarea FID4 route between
the two VTAMs. But, more importantly, now the two VTAMs have become part of
the same APPN network and therefore have access to all of the APPN
capabilities such as DLUS and HPR.
7.3 Hints on VR-TG

VR-TGs are very beneficial in a network that contains 3745 controllers, where
you might still have FID4 connections between VTAMs and NCPs. As shown in
this chapter, VR-TGs are very easy to implement and are recommended where
NCP connections need to be migrated to APPN.
The following is a list of some points worth remembering when planning to

implement VR-TG:
• VR-TGs are available only on interchange nodes and migration data hosts, in
other words nodes with subarea capability.
• A VR-TG cannot cross an SNI boundary since SNI splits a route into multiple
VRs.
• VR-TG connections still require path table definitions. A session utilizing a
VR-TG connection still traverses a VR and an ER in the subarea network

even though this VR is represented as an APPN TG. To eliminate path
tables you need FID2 connections, but these are not possible in cases such
as MLTG, SSCP takeover or BSC 3270.
• Every VTAM in an SNA subarea network must have an SSCP session with
every other VTAM. LU-LU session establishment will fail between domains
that are not joined by an SSCP-SSCP session. However, it is not
recommended that every VTAM have CP-CP sessions with every other
VTAM.
Remember that the term “adjacent” means very different things in subarea
and APPN networking. An adjacent CP is physically adjacent, at least in
terms of the ability to exchange XIDs. An adjacent SSCP is one with which
you are in session. An adjacent SSCP could be several hops away across
other VTAMs and NCPs; there is no way you would want CP-CP sessions
along that path since the chain of physically adjacent CPs will do the job
admirably.
• Similarly, it is not required that each pair of VTAMs in a subarea network
has a VR-TG defined. As long as a chain of VR-TGs is available between
each pair of VTAMs, a session RSCV that contains multiple adjacent VR-TG
links will be modified (“pruned”) so that a single VR-TG is substituted for the
consecutive ones. The presence of an SSCP-SSCP session is then all that is
required for the session to be established.
In a like manner, a session RSCV that contains an IC-TG adjoining a VR-TG
will be pruned so that the subarea section is a single IC-TG.
Please see the VTAM Network Implementation Guide , SC31-8563, for detailed
recommendations.
• If two VTAMs are connected via both VR-TG and FID2 links, care must be
taken when defining TG characteristics. TG 255 will be selected for an APPN
route on the same basis as any other TG, so its TG characteristics should be
correctly specified. VR-TG characteristics are defined with the usual
keywords (TGP, CAPACITY and so on) but on the CDRM statement instead of
the PU statement. VTAM does not know what the actual capacity of a VR is,
so by default a VR-TG is assigned the minimum TG CAPACITY of 8 Kbps.
This is almost certainly not what you want.
In the early stages of migration from subarea to APPN, you may wish to bring up
CP-CP sessions between two VTAMs connected by VR-TG in a controlled
fashion, rather than to allow them to be started at VTAM initialization. You can
certainly change the VRTGCPCP option dynamically, but:
• It requires both partner SSCPs to have the option set, whether by CDRM
activation or by the MODIFY VTAMOPTS command.
• It requires the CDRM major node to be recycled on the VTAM which receives
the SSCP session request.
A better way to achieve control over CP-CP session setup over a VR-TG is as
follows:
• In each VTAM partner, create a CDRSC major node with a definition for the
partner CP, but with ISTATUS=INACTIVE. Add it to ATCCONxx so that it
gets activated early in the startup cycle.
• When the VR-TG is activated the CP-CP sessions will not be established and
only subarea protocols will be used.

• When you require the CP-CP sessions, activate your new CDRSCs using V
NET,ACT,IDTYPE=CP,ID=cpname. The IDTYPE=CP is required to distinguish
between the CDRM and the CP. If the VR-TG is an endpoint TG then activate
the CDRSC on the NN before doing it on the EN.
• When you no longer wish APPN protocols to be used between the VTAMs,
inactivate both CDRSCs again using IDTYPE=CP.

Chapter 8. SSCP Takeover in a Combined Subarea and APPN
Network
To initiate SSCP takeover in an APPN environment, you need to choose a

takeover SSCP. This will probably already have been decided upon within your
subarea or pre-APPN network. Most definitions for subarea SSCP takeover will
have already been defined in your network (for example, parameters such as
OWNER=, BACKUP=YES, GWSSCP=YES, ANS=CONT). Refer to the Network
Implementation Guide , SC31-8563, for information on strategies and definition
requirements for SSCP takeover and giveback processing.
For SSCP takeover in a combined subarea and APPN network the takeover
VTAM needs to be defined as an interchange node specifying NODETYPE=NN
and HOSTSA=nn. An MDH, NN or EN cannot participate in takeover processing
because none of them can own an NCP. If you try to take over resources from
an MDH, you will receive the following message:
IST1330I resource CANNOT BE ACTIVATED FROM MDH.
In a mixed subarea/APPN environment, it is not immediately obvious that SSCP

takeover is any different from the pure subarea case. An NCP is always a
subarea node and is always happy to be taken over by another VTAM. Type 2.1
connections (link stations) are owned and taken over just as type 2.0 connections
are. Independent LU sessions can be taken over non-disruptively whether they
are LEN (in a pure subarea environment) or APPN. Independent LUs do not
have SSCP sessions so the problem of restoring such sessions using
ACTPU(ERP) and ACTLU(ERP) does not arise. The major issues arise in three
areas:
1. When a VTAM fails, its CP-CP sessions also fail and must be re-established
by the takeover VTAM without disrupting LU-LU sessions. However, the
adjacent node will see a change of CP name and must be able to handle
this.
2. When a VTAM takes over a link to an adjacent APPN node, the TG number
may also change since the TG number negotiation will begin anew. The
adjacent node must be able to cater for this as well.
3. The changes in CP name and TG number are communicated across the link
by the exchange of special XID3 frames called nonactivation XID3 . Both
connection partners must be able to send and receive these XIDs regardless
of their link station roles (primary or secondary).
Not all nodes support the receipt of nonactivation XID3s when they are acting
as primary link stations. This capability is declared in the original XID3
exchange. When takeover occurs, the physical characteristics of the
connection are already known but the new CP name and TG number
information must be exchanged.
For SSCP takeover to occur smoothly in a mixed subarea/APPN environment,

therefore, the nodes attached to the NCP which is taken over must support two
APPN options:
• Secondary Initiated Nonactivation XID, Option 1001
• Adjacent Node CP Name Change, Option 1004

Both these options are now part of the base APPN architecture, but older
products may not support one or both of them. In the SSCP takeover scenario
which follows in 8.1, “Example of APPN SSCP Takeover” on page 143, not all
devices and software support these options and thus not all sessions will be
taken over successfully.
During the first stages of APPN migration, the takeover VTAM may still be a
subarea-only VTAM. Possible configurations for takeover SSCPs are listed
below and you should take these into account when migrating:
1. The takeover SSCP is still a subarea-only VTAM. All APPN connections
being taken over from the primary SSCP will become LEN connections. No
CP-CP sessions are established until the original SSCP or an APPN-capable
SSCP regains control.
2. The takeover SSCP has implemented APPN and adjacent CPs do not support
CP name change. In this case, if the takeover SSCP is not the original
SSCP, the connections become LEN connections. The connections must be
broken and reestablished (disrupting LU-LU sessions) for the new CP-CP
sessions to start.
3. The takeover SSCP has implemented APPN and adjacent CPs are located
over subnetwork boundaries. The takeover SSCP must define the
connections in the same way as the original SSCP and it must also support
APPN multiple network connectivity (border node). Otherwise the
connections will be LEN connections.
4. The takeover SSCP that has implemented APPN is an ICN and adjacent CPs
support CP name change. This should be your objective.
NCP has the capability of initiating and accepting nonactivation XID3s whether it
assumes the primary or secondary role on a connection. Therefore, you should
ensure that NCP is the primary station. This is already almost always the case
for SDLC links. For NCP-NCP connections (where one NCP must be secondary)
it is of no concern since NCP supports nonactivation XID3 in either role. In fact,
as soon as an NCP has detected the loss of its owner it sends nonactivation
XID3s to adjacent network nodes with the TG quiescing bit turned on. This
informs them that the active link information will change. Once takeover has
been established, the new VTAM sends out topology data updates to the network
to inform it of the changes.
If you are using the Configuration Services XID exit (ISTEXCCS) or the
self-defining dependent LU support exit (ISTEXCSD), copies of these should be
active in the takeover SSCP so that resources dynamically defined using these
exits can be taken over and re-defined.
In a subarea environment, takeover is possible because, although resources

lose their SSCP owner they do not lose their connectivity to the network since
the NCP remains alive and well. In an APPN network there is one additional
class of resource which meets these criteria, namely DLUR-served dependent
LUs. Many of these can be customized to select a new DLU server without
disrupting LU-LU sessions when the primary DLUS fails. A backup VTAM can
also be set up to take over DLUR resources by initiating the DLUR/S sessions
itself. Once the DLUR/S sessions are active the normal ACTPU(ERP) and
ACTLU(ERP) flows occur over the DLUR/S pipe.

Please see Inside APPN - the Essential Guide to the Next-Generation SNA for the
latest information on IBM product support for CP name change and nonactivation
XID3.
8.1 Example of APPN SSCP Takeover

The network used for this scenario is physically similar to that used for the initial
subarea to APPN migration. Figure 116 shows the network prior to an SSCP
takeover.
Figure 116. Diagram of Network Prior to SSCP Takeover
Note:
1Subarea 10 (RAA) is the ICN/CNN which owns RA5NCPX and

RA8NCPX. It is also the network DLU server and central directory server.
2Subarea 28 (RAS) is the backup ICN with a FID4 channel connection to

RA8NCPX. It too is defined as a CDS. RAS should not have a FID2
Chapter 8. SSCP Takeover in a Combined Subarea and APPN Network 143

connection to the NCP before takeover. It cannot have a FID2 connection
with itself, which is what would result after takeover. Such a connection
would be terminated and the sessions it carried would fail unless they
could be path switched with HPR.
3The SDLC-attached 3174-11R has a CP name of CP31742. It has CP-CP

sessions with RAA. It also has a dependent LU-LU session with RASAN
(NetView) on RAS. The VTAM name for the line is L3174C1, the link
station name is P3174C1 and the LU name is RA317411.
4This PS/2 is running CM/2 V1.11 and is defined as an NN with a CP

name of CP05147. It has CP-CP sessions with RAA. The PU and LUs
associated with this node are dynamically defined in RAA using the
ISTEXCCS exit and model major node RAAMDLS. The PU name is
W05147 and the LUs are W0514702-11. W0514702 is a dependent LU in
session with RASAN on RAS.
5This PS/2 is running CM/2 V1.11 and is defined as an EN with a CP

name of CP05137. Its NN server is RAA. The PU and LUs associated with
this node are dynamically defined in RAA using the ISTEXCCS exit and
model major node RAAMDLS. The PU name is W05137 and the LUs are
W0513702-11. W0513702 is a dependent LU in session with RASAN on
RAS.
6This PS/2 is running CM/2 V1.11 and is a LEN node with a CP name of
CP05150. Of course, no CP-CP sessions exist. The PU and LUs
associated with this node are dynamically defined in RAA using the
ISTEXCCS exit and model major node RAAMDLS. The PU name is
W05150 and the LUs are W0515002-11. W0513702 is a dependent LU in
session with RASAN on RAS.
7The token-ring-attached 3174-63R has a CP name of CP31744. It has

CP-CP sessions with RAA. The PU and LUs associated with this node are
dynamically defined in RAA using the ISTEXCCS exit and MODEL major
node RAAMDLS. The PU name is U31744 and the LUs are U3174402-05.
U3174402 is a dependent LU in session with RASAN on RAS.
8This is an SDLC-attached PS/2 running Communications Server/2 V4.0

and is defined as an NN with a CP name of CP05160. It has CP-CP
sessions with RAA. The VTAM line name is LCM2A and the link station
name is RA8CM2A. This node is acting as a connection to RAA for the
downstream PS/2 EN and has no other sessions.
9This PS/2 is token-ring-attached downstream of CP05160. It is defined

as an EN with a CP name of CP05221. It has CP-CP sessions with
CP05160. It also acts as a DLUR for its own dependent LUs, with a
primary DLUS of RAA and a secondary DLUS of RAS defined. The PU
and LUs associated with this node are dynamically defined in RAA using
the ISTEXCCS exit and model major node RAAMDLS in the same way as
for other switched devices. The PU name is W15221 and the LUs are
W1522102-11. W1522102 is a dependent LU in session with RASAN on
RAS.
The difference in this scenario is that we have used dynamic definitions for all
the dependent LU definitions on the PCs and 3174s. That is, we have allowed
the configuration services XID exit ISTEXCCS to define PUs and LUs based on

the IDBLK/IDNUM of the resource. See 3.1.6, “Dynamically Defining Switched
Resources” on page 35 for information regarding this exit.
In our scenario for APPN SSCP takeover, the primary SSCP RAA remains
defined as an ICN as described in Chapter 4, “Migrating a CMC Host to ICN” on
page 61. In order for the backup SSCP to initiate the takeover of network
connections, we must change the definitions on the designated takeover SSCP.
In our case, we have used RAS, which was defined as an MDH and then as an
EN. We have redefined RAS as an ICN for it to be able to perform the takeover.
This node must be able to take over the network and have the same capabilities
as the primary SSCP. This includes defining RAS as a central directory server.
Figure 117 shows the start options we defined for RAS in the takeover
environment.
*******************************************************************
* ATCSTR28 FOR RAS *
* THIS IS SUBAREA 28 AS A BACKUP ICN FOR SSCP TAKEOVER OF RAA *
*******************************************************************
APPNCOS=#CONNECT,
CONFIG=28,
BN=YES,
CDSERVR=YES,
CONNTYPE=APPN,
CONFIG=28,
CPCP=YES,
CSALIMIT=0,
DIRSIZE=0,
DIRTIME=8D,
DYNADJCP=YES,
DYNLU=YES,
GWSSCP=YES,
HOSTPU=ISTPUS28,
HOSTSA=28,
HPR=NONE,
INITDB=ALL,
IOBUF=(100,500,5,,1,30),
MAXSUBA=255,
NETID=USIBMRA,
NODETYPE=NN,
NOTRACE,TYPE=VTAM,IOINT=0,
NUMTREES=100,
RESUSAGE=100,
ROUTERES=128,
PPOLOG=YES,
SORDER=SUBAREA,
SSCPID=10028,
SSCPNAME=RAS,
SSEARCH=YES,
SUPP=NOSUP,
TNSTAT,CNSL,
VRTG=NO,
XNETALS=YES
Figure 117. Takeover APPN SSCP Startup List

For the takeover, we set up cross-domain LU-LU sessions from dependent
devices on RAA to applications on RAS. This included dependent LU sessions
from a non-adjacent DLUR EN (CP05221), which was using RAA as its DLUS.
This therefore included a DLUR/S session pipe between RAA and CP05221. We
also had five CP-CP session pairs between APPN nodes and RAA.
We were able to view the CP-CP sessions using either the command D
NET,ID=ISTADJCP,E for dynamically defined adjacent CPs or D NET,ID=RAAADJCP,E
for a list which we had statically defined. Figure 118 shows an example.
DISPLAY NET,ID=RAAADJCP,SCOPE=ALL

IST097I DISPLAY ACCEPTED
IST075I NAME = RAAADJCP , TYPE = ADJCP MAJOR NODE
IST1100I ADJACENT CONTROL POINTS FROM MAJOR NODE RAAADJCP
IST1102I NODENAME NODETYPE CONNECTIONS CP CONNECTIONS NATIVE
IST1103I USIBMRA.CP05137 EN 2 1 *NA*
IST1103I USIBMRA.CP05147 NN 1 1 YES
IST314I END

Figure 118. Display of Adjacent CPs
We then issued the V NET,REL VTAM command for both NCPs owned by RAA,
namely RA5NCPX and RA8NCPX. The VARY REL,TYPE=GIVEBACK command
releases the NCP and its resources from VTAM′s knowledge so that another
VTAM can acquire them. Figure 119 on page 147 shows the console log after
the NCPs and their resources were released by RAA.

V NET,REL,ID=RA5NCPX,TYPE=GIVEBACK

IST097I VARY ACCEPTED
IST105I RA5PRA8 NODE NOW INACTIVE
IST1097I CP-CP SESSION WITH USIBMRA.CP31742 TERMINATED 1
IST1280I SESSION TYPE = CONLOSER - SENSE = 80030004
IST314I END
IST1280I SESSION TYPE = CONWINNER - SENSE = 80020000
IST314I END
IST1110I ACTIVATION OF CP-CP SESSION WITH USIBMRA.CP31742 FAILED
IST314I END
IST105I RA5PNPA NODE NOW INACTIVE
IST105I P3174C1 NODE NOW INACTIVE
IST590I CONNECTION TERMINATED FOR PU W05147 ON LINE J0005023
IST105I W05147 NODE NOW INACTIVE 2
IST871I RESOURCE W05147 DELETED
IST314I END
IST314I END
IST314I END
IST314I END
IST314I END
IST670I VARY REL PROCESSING FOR ID = RA5NCPX COMPLETE

Figure 119 (Part 1 of 2). Console Log after V NET,REL for RA5NCPX Prior to Takeover

V NET,REL,ID=RA8NCPX,TYPE=GIVEBACK

IST097I VARY ACCEPTED
IST105I RA8PRA5 NODE NOW INACTIVE
IST105I RA8PNPA NODE NOW INACTIVE
IST590I CONNECTION TERMINATED FOR PU U31744 ON LINE J0008027
IST105I U31744 NODE NOW INACTIVE 2
IST871I RESOURCE U31744 DELETED
IST105I RA8CM2A NODE NOW INACTIVE
IST493I HARD INOP FOR ID = CP05221 OVERRIDDEN BY HARD INOP
IST619I ID = CP05221 FAILED - RECOVERY IN PROGRESS 3
IST1414I SESSION OUTAGE - REDIAL NOT ATTEMPTED FOR W15221
IST314I END
IST314I END
IST314I END
IST670I VARY REL PROCESSING FOR ID = RA8NCPX COMPLETE

Figure 119 (Part 2 of 2). Console Log after V NET,REL for RA8NCPX Prior to Takeover
We can see in the displays that:

1All the CP-CP sessions between RAA and the adjacent nodes have been
terminated, as expected. CP05150 never had any CP-CP sessions, being a
LEN node. The fate of the sessions to CP31744 was not captured in these
displays.
2All the dynamically defined PUs and LUs are deleted from RAA′ s
resource definitions, although their LU-LU sessions may remain active. This
includes the DLUR LUs on CP05221.
3The DLUR/DLUS sessions between RAA and CP05221 are terminated, as
expected.
In fact, apart from the CP-CP session failure messages there is nothing
APPN-specific in these displays. VTAM has simply relinquished ownership of
some dependent LUs and some link stations.
Next, we took over the NCPs from RAS using the commands:
V NET,ACQ,ID=RA8NCPX,ACT,PUSUB
V NET,ACQ,ID=RA5NCPX,ACT,PUSUB
Once again the resulting displays showed nothing APPN-specific except for those
nodes which supported CP name change. In fact there were only three such
nodes in the network, since the CM/2 nodes were not capable of it. Figure 120
on page 149 shows the message we received when the 3174 CP31742
re-established its new CP-CP sessions.

The results of the takeover were as follows:
• RAS successfully took over all the connections , except for the SDLC link to
the CS/2 node CP05160. We believe this was due to a bug in CS/2 Version
4.0, which was corrected by fix pack WR20636. However, we were unable to
verify this before publication of this book. We had to reactivate the
connection manually.
• The SSCP-PU and SSCP-LU sessions for the dependent resources were all
taken over.
• All the LU-LU sessions remained active, except those using the link to
CP05160.
• Because of the CS/2 problem, only the 3174s had the capability of fully
successful takeover, including CP-CP sessions. Figure 120 shows the
display that appeared when RA5NCPX was taken over by RAS.
• None of the CM/2 nodes were able to re-establish CP-CP sessions
immediately. At the time of writing, CM/2 did not support the CP name
change APPN option. We had to terminate the connections (and the LU-LU
sessions) before new CP-CP sessions would come up.
• CS/2 supports CP name change, but because of the problem with the SDLC
link we were unable to verify this.
IST093I P3174C1 ACTIVE

IST1086I APPN CONNECTION FOR USIBMRA.CP31742 IS ACTIVE - TGN = 21
IST1096I CP-CP SESSIONS WITH USIBMRA.CP31742 ACTIVATED

Figure 120. 3174 Moves Its CP-CP Sessions
The following diagram is the view of the network after SSCP takeover by RAS.

Figure 121. Diagram of Network after SSCP Takeover by RAS
The connections and the sessions are the same as in the previous network
diagram, except that:
• RAS is now owner or DLUS for the dependent LUs.
• The dependent LU sessions are now same-domain instead of cross-domain.
• RAS has run the configuration services exit with its own copy of the MODELS
major node.

Chapter 9. Searching and Routing in a Mixed Subarea/APPN
Network
When a VTAM (such as an interchange node or an migration data host) has both
subarea and APPN functions, it has the choice of using either type of network
when called upon to set up a session. The target resource may be accessible
via either subarea or APPN, in which case the installation may wish to influence
the choice. Requirements such as HPR or DLUR will dictate an APPN path,
whereas other factors such as NCP loading, BSC 3270 support or MLTGs may
make a subarea path desirable or even essential for a particular session. The
choice of routing depends on a combination of start options, definitions and
VTAM′s knowledge (acquired dynamically or by definition) of a resource. VTAM
identifies the location of a resource in one of three ways:
• Predefinition
• Incoming search request with the resource as OLU (the resource has
requested a session with an LU on this VTAM)
• Incoming search reply with the resource as DLU (this VTAM has performed a
successful search for the resource)
Thus the installation can influence the choice of subarea or APPN routing either
by predefining resources (which is not normally desirable) or by adjusting
VTAM′s searching algorithms. Since those algorithms are completely different in
subarea and APPN networks, the combination of them in a mixed network is
quite complex. However, an understanding of that combination is essential if
trouble-free migration of a medium or large network is to be achieved.
9.1 Searching in a Subarea Network

In a subarea network, VTAM represents a remote resource by means of a
cross-domain resource (CDRSC) entry in its resource definition tables. When
asked to locate such a resource, VTAM checks the contents of the CDRSC entry
to work out where to send the search. If it does not already have a CDRSC
entry, or if the information in the CDRSC is found to be incorrect, VTAM must
search the subarea network in some pre-ordained way. Thus the installation can
influence subarea searching by two methods:
1. By predefining CDRSC entries for remote resources
2. By defining tables (adjacent SSCP tables) which VTAM will use to search the
network if a CDRSC is not available, or if the information in the CDRSC is no
longer valid
Predefinition of resources is not usually desirable, so large installations normally

code adjacent SSCP tables to direct searches for various resources in various
directions. These tables are most often found in SNI-interconnected networks,
but they can be useful in single-network environments as well. Various VTAM
start options (SSCPORD, SSCPDYN, DYNASSCP) allow VTAM to perform some
manipulation of the adjacent SSCP tables dynamically.
When a CDRSC is created, it has one or more of the following entries depending
on how it was created:

• Real Owner. This is the VTAM which is strongly believed to own the target
resource, because it has confirmed its ownership in response to a CDINIT or
DSRLST request.
• Coded Owner. This is the VTAM which has been pre-defined as being the
owner of the target resource, by means of the CDRM= keyword on the
CDRSC definition.
• A pointer to a table giving the search history for this CDRSC. This table lists
the VTAMs which have been searched for this resource, and the results of
each search. The table is used to modify, if appropriate, the search order
specified in the associated adjacent SSCP table. The adjacent SSCP table
itself is not referred to by the CDRSC. It is determined for each search
request by the information that is already known about the target resource,
namely the real NetID and/or the owning VTAM name.
If the start option SSCPORD=PRIORITY is in effect, the chosen adjacent
SSCP table is modified by the history information. Adjacent SSCPs which
last responded positively to a search are placed at the top of the table,
whereas those which last responded in the negative are moved to the
bottom. Those which have never been searched remain in the middle. Thus
the modified table should reflect the likelihood of finding the target CDRSC
via various routes. If SSCPORD=DEFINED is in effect this table modification
is not performed.
The actual “personalized” search order for a given CDRSC can be displayed
using the VTAM command D NET,ADJSSCPS,CDRSC=. This will show you the
adjacent SSCP table to be used, modified appropriately if SSCPORD is set to
PRIORITY.
The complete VTAM subarea search algorithm is shown below. VTAM sends the
CDINIT or DSRLST to each partner VTAM in turn until the resource is found. No
search is issued until a response has been received to the previous one. It is
not permitted in the subarea network to have multiple searches outstanding
concurrently for the same resource. For clarity, we show the
SSCPORD=DEFINED and SSCPORD=PRIORITY cases separately:
Subarea Search if SSCPORD=DEFINED

1. Real owner from the CDRSC, if a CDRSC exists.
2. Coded owner from the CDRSC, if a CDRSC exists.
3. Adjacent SSCP table, as coded. The table is chosen according to the
information (if any) already known from the CDRSC and/or the session
request.
Subarea Search if SSCPORD=PRIORITY

1. Real owner from the CDRSC, if a CDRSC exists
2. Coded owner from the CDRSC, if a CDRSC exists
3. Previous successful entries from the relevant adjacent SSCP table, if any
4. Unsearched entries from the adjacent SSCP table
5. Previous failed entries from the adjacent SSCP table

9.1.1 LEN and APPN Resources in a Subarea Network
LEN resources (independent LUs) in a subarea network are a special case.
Although such a resource does not have an SSCP-LU session, it is in effect
owned by the VTAM which owns the link station connecting it to the network. In
this VTAM only, a LEN resource is represented by a CDRSC with:
• This VTAM shown as the owner (real and/or coded)
• A list of adjacent link stations over which the resource can be reached
Thus a LEN resource can be easily told apart from a subarea CDRSC in the
VTAM display.
It is perfectly possible, by a combination of predefinition and successful

searching, for a resource to be known as both a LEN and a remote subarea
resource. The subarea search algorithms still apply, but they are used only if
the adjacent link station(s) have been determined to be unusable.
When VTAM is capable of both APPN and LEN, it maintains two distinct identities
to cater for the two networks. Its subarea side regards APPN resources exactly
as LEN resources, in other words as independent LUs and therefore CDRSCs. In
APPN, however, resources are not usually predefined and therefore will be
represented as dynamic CDRSCs, which last only for the duration of a session.
An APPN resource is represented in the subarea side of VTAM as a CDRSC with:
• This VTAM shown as the owner (real and/or coded).
• A dummy adjacent link station, ISTAPNPU. This tells VTAM not to try to send
a BIND across a link station, but to pass a search request to its APPN side
so that the APPN network can be searched.
So now we can see that a remote resource can be represented to VTAM as any
or all of subarea, LEN and APPN. It could have (for example) another VTAM as
real owner, this VTAM as coded owner, and a list of link stations among which is
ISTAPNPU. VTAM knows whether a LEN link is active or not because it owns the
link; thus it can ignore the LEN representation of a resource if the LEN
connection is not available. Assuming any LEN link stations are active, this is
how VTAM decides between the three possible options:
• If the choice is between LEN and subarea, LEN takes priority.
• If the choice is between LEN and APPN, APPN takes priority unless
ALSREQ=YES has been coded on the CDRSC definition. This prohibits the
dynamic addition of link stations, including ISTAPNPU, to the CDRSC.
• If the choice is between APPN and subarea, the algorithms described in 9.3,
“How VTAM Combines the Search Algorithms” on page 155 are used.
• If all three representations are known to VTAM, APPN takes priority over LEN
and subarea is suppressed, unless the search has come from the APPN
network. In this case it is too late to reroute it back to APPN (because of the
search algorithms shown in 9.3, “How VTAM Combines the Search
Algorithms” on page 155), so LEN takes priority over subarea.
Chapter 9. Searching and Routing in a Mixed Subarea/APPN Network 153

9.2 Searching in an APPN Network
In an APPN network, a VTAM NN represents a remote resource by means of an
entry in its directory database. When asked to locate such a resource, VTAM
checks the contents of the directory to work out where to send the Locate
request to verify the target. If there is no directory entry it must search the
APPN network in some pre-ordained way. Most of the APPN search algorithm is
defined by the architecture, but the installation has some control over it.
Directory entries can be predefined (this is not desirable), resource registration
can be used to pre-load APPN directories, and routing tables can be used to
influence cross-border search patterns.
An APPN directory entry contains:

• The owning CP name of the target resource. In APPN a directory entry is
regarded as a suggestion rather than a true statement, since resources are
allowed to move about. There is no distinction between real and coded
owning CPs.
• The network node server name of the target resource, if the owning CP is an
end node. A Locate search for a target must be directed to a network node,
since ENs are not in the topology database and cannot be found without the
assistance of their network node servers.
The complete APPN search algorithm is shown below. Note that:

• The broadcast searches are sent concurrently to all eligible partner nodes,
but apart from that the search steps are consecutive.
• The directed Locate used to verify the existence of a resource can be
suppressed, for APPCCMD applications only, at the behest of CP(OLU). The
start option VFYRED=YES must be operative for this to be permitted.
APPN Search
1. APPN directory. If an entry is found here a directed Locate is sent to verify
that the resource is still in its expected location. If the expected location is
an EN served by this NN, the directed Locate is sent directly to the CP. If the
expected location is elsewhere, it is sent to the NN (owner or server) which
serves the target LU.
2. APPN topology database. If the target is actually a network node CP, it will
be found here and no verification is necessary. VTAM, however, still sends a
directed Locate to verify the target.
3. Domain broadcast. The NN sends a Locate request to all its served end
nodes that have permitted themselves to be searched on a domain
broadcast. Some end nodes, VTAM included, do not permit such a search;
they register all their resources to their NNS thus eliminating unnecessary
searching overhead. There are exceptions, such as the case where a VTAM
is managing an APPN peripheral border. Here VTAM pretends to be an end
node but cannot possibly register all the resources on the far side of the
border; therefore it allows itself to be searched.
4. Full APPN network search. Exactly what this entails depends on the role the
NN is playing in the search and the presence of CDSs in the network. If
there is no CDS then the full search comprises:
a. Full network broadcast. The NN sends a Locate request to all adjacent
NNs with which it has CP-CP sessions. They in turn forward the request

until the whole network has been searched. The broadcast search
contains an indication that it is not to cross any interchange node into
the subarea network; this might violate the rules of subarea by
forwarding multiple concurrent searches into the subarea network.
Note that it is still possible for a search to be touring the subarea
network more than once in parallel. This could occur if a non-VTAM
node, which does not understand or set the “do not cross ICN” bit,
issues a broadcast. It could also occur, regardless of the presence of
APPN, if a subarea VTAM performs an IOPURGE while a DSRLST is still
outstanding.
b. Serial interchange node search. Each ICN (they are identified in the
topology database) is searched in turn in case the desired target is in a
subarea network to which it is the gateway. The ICNs receiving such a
search request use their own subarea search alogorithms to search their
attached subarea network.
If there is a CDS then the “full search” is replaced by:
a. Directed search to one CDS, selected by this NN. If this CDS returns a
negative response the search is cancelled. The CDS is responsible for
the broadcast search and the subsequent serial interchange node
search.
If this NN is a CDS then the “full search” is replaced by:
a. Directed search to each alternate CDS, in sequence. If one of these
returns a positive response this CDS verifies the target.
b. Full APPN network broadcast, forbidding subarea search.
c. Serial ICN search, indicating that subarea is to be searched.
5. Consecutive cross-border searches to each partner in turn, if this NN is also
a border node. The order of these searches is controlled by the adjacent
cluster routing tables, which may be predefined or dynamically created by
VTAM.
The above algorithm assumes that the NN is performing the search as a result of
being NNS(OLU); in other words it has originated the search. If it is searching as
a result of receiving a broadcast it does not perform the “full APPN search”
actions because some other node does that. If it is searching as a result of
being the entry border node (in other words, it has received the search from a
cross-border partner), then it goes straight into its adjacent cluster tables and
does what they tell it to do. Only if it finds its own name in the tables does it
search its own network, as if it were NNS(OLU).
9.3 How VTAM Combines the Search Algorithms

The installation can affect the VTAM search algorithms in several ways:
• Predefine remote resources. A CDRSC definition can be used to define a
subarea, LEN or APPN resource. As described above, parameters like the
VTAM owner, the adjacent link station list, the CP name and the NNS name
will tell VTAM what kind of a resource is being defined.
• Code the adjacent SSCP tables according to your requirements. With APPN
there is an extra dummy entry you can code named ISTAPNCP. This entry
tells VTAM to search the APPN network at this point, rather than asking
some other SSCP about the target resource. You can code ISTAPNCP in

various places in different tables for fine tuning of your searching. You need
to code SORDER=ADJSSCP in the start options for your choice to take
effect; if SORDER is anything else the ISTAPNCP entry will be automatically
placed by VTAM at the start (APPN or APPNFRST) or end (SUBAREA) of the
table when it is chosen for use. Note that if you do code
SORDER=ADJSSCP then you must have ISTAPNCP in your tables or there
will be no APPN search at all.
• Code the VTAM start options SORDER, SSEARCH and SSCPORD (and
BNORD if this is a border node). These all have an effect on the way in
which VTAM combines the subarea and APPN search algorithms. These
options, and their functions, are described in 3.1.19, “Specifying Search
Order Parameters for Subarea and APPN” on page 53.
When VTAM, acting as an ICN or an MDH, is called upon to search for a target
resource it uses all the above definitions, plus its dynamically acquired
knowledge of the resource, to conduct the search. The algorithms it uses are
shown below; for clarity they have been split into several distinct cases because
some options affect it more significantly than others.
Regardless of the setting of all the start options and definitions, if ADJLIST is
coded on a CDRSC definition then that list, and only that list, is used to find the
resource. The start options are ignored. ADJLIST is a good way (indeed, the
only way) of overriding SORDER=APPNFRST if a subarea path is desired to a
given resource. An ADJLIST can include ISTAPNCP if so desired.
You should also be aware that the Directory Services Management Exit can
suppress some of the search steps, but it cannot change the order of the steps.
9.3.1 Search Originating from Subarea Network or Local LU

The tables in this section are in effect if the search request has been received
from the subarea network, or from an LU in VTAM′s (subarea) domain. An MDH
can forward a search request from one of its own LUs into either the APPN or
the subarea network, so this section applies to an MDH as well as an ICN. An
MDH cannot reroute search requests within the subarea network, as the start
option NODETYPE=EN forces the option GWSSCP=NO to be set.
Search from Subarea, SSCPORD=DEFINED, SORDER=APPNFRST

1. APPN directory
2. APPN domain
3. Full APPN network search
4. Serial cross-border search
5. Real owner in CDRSC
6. Coded owner in CDRSC
7. Adjacent SSCP table
Search from Subarea, SSCPORD=DEFINED, SORDER=APPN

3. APPN directory
4. APPN domain

Search from Subarea, SSCPORD=DEFINED, SORDER=ADJSSCP

3. APPN directory for nodes in this domain only
4. Adjacent SSCP table up to the ISTAPNCP entry
5. APPN directory, for all other nodes
6. APPN domain
9. Adjacent SSCP table, after the ISTAPNCP entry
Search from Subarea, SSCPORD=DEFINED, SORDER=SUBAREA

3. APPN directory for nodes in this domain only
5. APPN directory, for all other nodes
6. APPN domain
Search from Subarea, SSCPORD=PRIORITY, SORDER=APPNFRST

1. APPN directory
2. APPN domain
7. Adjacent SSCP table entries which were last searched successfully
8. Adjacent SSCP table entries which have not been searched
9. Adjacent SSCP table entries which were last searched unsuccessfully
Search from Subarea, SSCPORD=PRIORITY, SORDER=APPN

3. APPN directory

4. Adjacent SSCP table, in priority order, until the ISTAPNCP entry is found.
ISTAPNCP is initially placed at the top of the table, but may be repositioned
if it is found in the resource′s search history.
5. APPN domain
8. Adjacent SSCP table, in priority order, after the ISTAPNCP entry.
Search from Subarea, SSCPORD=PRIORITY, SORDER=ADJSSCP

3. APPN directory
ISTAPNCP may be in the “successful search”, “never searched” or the
“unsuccessful search” part.
5. APPN domain
Search from Subarea, SSCPORD=PRIORITY, SORDER=SUBAREA

3. APPN directory
ISTAPNCP starts off at the bottom of the table but may be repositioned
depending on the search history for the resource.
5. APPN domain
Note that, if SORDER=ADJSSCP and there is no ISTAPNCP coded in the tables,

the APPN network will never be searched - not even the local directory. If
ISTAPNCP is coded and SORDER is not ADJSSCP, then the coded position of
ISTAPNCP is ignored.
9.3.2 Search Originating from APPN Network

These tables apply only to an interchange node which has received a search
from the APPN network. This could be from a served end node or from another
network node; a request from one of its own resources is considered a subarea
request and uses the algorithm described in the previous section. The phrase
“target in subarea cache” means that there is a CDRSC for the resource with the
real owner (found on a successful search) specified, or that a predefined subarea
CDRSC exists. Thus if the target resource is not in the subarea cache, neither
real nor coded owner is present.

You should also be aware that a search resulting from the DISPLAY DIRECTRY
command with SCOPE=NSEARCH is treated as originating in the APPN network.
The algorithms in this section are used.
Regardless of SSEARCH, if the target is owned by this ICN it will always be

found.
Search from APPN, target in subarea cache, SSEARCH=APPNFRST

1. APPN directory
2. APPN domain
7. Adjacent SSCP table, in defined or priority order according to SSCPORD
Search from APPN, target in subarea cache, SSEARCH=YES

1. APPN directory
5. APPN domain
Search from APPN, target in subarea cache, SSEARCH=CACHE

1. APPN directory
5. APPN domain
Search from APPN, target in subarea cache, SSEARCH=NO

1. APPN directory
2. APPN domain
Search from APPN, target not in subarea cache, SSEARCH=APPNFRST or YES

1. APPN directory
2. APPN domain

Search from APPN, target not in subarea cache, SSEARCH=CACHE or NO

1. APPN directory
2. APPN domain
9.3.3 Some Recommendations

With all these options available, there is clearly a huge range of possibilities for
the way your network searches work (or do not work, in some cases). An
understanding of the seach algorithms will help you ensure that every resource
can be found, and that searches to a perfectly good target LU do not fail because
some obscure start parameter has not been set correctly. There is then a
trade-off between performance and dynamics to be considered. Once a
resource has been located successfully, subsequent searches for it should be
fast but there is quite a lot of tuning you can do to optimize that first search. The
decision to go for dynamics or performance is yours, but CS OS/390
Development has come up with some considerations and suggestions which we
present in this section.
The major issues to consider are:

• What are your existing search patterns?
• Where are target resources located at each stage of migration - APPN or
subarea?
• Can the location of a resource be determined by its NetID?
• NCP-owned resources which are to be taken over by a backup VTAM must
have a subarea path to that VTAM.
• BSC 3270 sessions, if not converted to SNA in an external box, require a
subarea path to their application.
• Some nodes which act as Type 5 subarea nodes (for example, certain
Tandem or Unisys machines) are not capable of sending extended BINDs.
Such sessions require a subarea path to the partner LU. CS OS/390
Development is investigating the possibility of a solution to this (short of
upgrading the type 5 node), but such a solution may not be feasible.
• HPR requires an APPN path (which can include VR-TG).
• A DLUR/S connection requires an APPN path (which can include VR-TG).
• Certain sysplex functions (generic resources, multinode persistent sessions)
require APPN or HPR paths.
The best options for your network will vary according to the stage of migration
you have reached, but in general:
• Start with SORDER=ADJSSCP or SUBAREA (for the simpler networks) and
move to APPN or APPNFRST as you migrate. Use ADJSSCP when the
location of resources depends mainly on the NetID, or when the resources

are evenly distributed between APPN and subarea networks. This is likely to
be the case in the more complex migration scenarios.
• Use SSCPORD=PRIORITY unless you have a clear requirement to control
searches closely. The same principle applies to BNORD.
• Use SORDER and SSEARCH=APPNFRST when you have a requirement for
APPN if at all possible, for example if you need HPR or generic resources
function. These are also useful options when you have BSC 3270 sessions
which force a subarea path. APPNFRST will allow VTAM to ignore this
subarea path on subsequent session requests that need APPN.
Note, however, that APPNFRST will cause an APPN search for all resources,
even those which you may know are reachable only via SNI (and therefore
subarea). You can use ADJLIST to override APPNFRST for such resources.
• Use ADJLISTs if you have just a few exceptions to your general search
strategy. For example, if most of your resources are in APPN but you have
SNI connections to a few, ADJLIST is a good way of optimizing searches.
• Use one or two CDSs in each APPN network. Generally these will be the
CMC and the backup CMC.
• Use VR-TGs between VTAMs that must have a subarea path between them.
It is highly undesirable to have independent subarea and APPN paths
between the same two nodes. VR-TGs are not required between MDHs as
the VRs will be chosen dynamically. They are required where CP-CP
sessions would be needed, in other words between an MDH and its potential
NN servers, or between ICNs.
9.4 Composite Network Node Routing

Once VTAM has found a target resource, the question of whether it uses subarea
or APPN routes for the session has been decided - almost. Where an APPN path
crosses a composite network node, the CNN appears as a single node but could
in reality have multiple entry and exit points, and multiple routes through it.
Where an APPN path traverses a VR-TG, the VR-TG appears as a single link but
could in reality have multiple routes through it, and the endpoints of the VR-TG
could themselves be CNNs. Once the endpoints of a VR-TG have been
determined then straightforward subarea VR selection can be used, but first
those endpoints must be decided.
VTAM has a function called CNN routing to optimize the selection of entry and
exit TGs (meaning the PLU side and the SLU side) when an APPN route crosses
a CNN. CNN routing has the following characteristics:
• The APPN rule that forces the lowest-weight route to be chosen is inviolable.
CNN routing only comes into play if the alternative paths across a CNN have
the same weight.
• VTAM nodes propagate subarea numbers in the TG descriptors (CV46) sent
on topology updates and search requests. A CV46 describing a TG that
originates in a subarea node has the subarea number appended in subvector
80. This means that any VTAM in an APPN network can determine if there is
a zero-hop path across any CNN, provided that it has received the right
CV46s with the subarea numbers. VTAM is capable of working out that a TG
from a served end node connects to the same subarea number as the same
TG to the end node, but non-VTAM nodes do not understand such things.

Sometimes the VTAM NN calculating the route will have the right
information, sometimes it will not.
A session that has a partner LU actually within a CNN raises similar issues,
but this time there is no TG in the topology database to tell other VTAMs
which subarea number is associated with the LU. In this case CNN routing is
less likely to result in an optimum route; sometimes even when the owner of
the session partner is calculating the route it does not have all the
information necessary to get it right.
• Under some circumstances, a VTAM CNN can change the calculated path
across its own subarea domain, after it has been computed by another node.
This is known as BIND rerouting, and can only happen if:
− The TG being changed is the exit TG, not the entry TG, since by the time
the BIND reaches the CNN it is too late to change the entry TG.
− The calculated and alternative exit TGs must have the same
characteristics, not just the same weight.
The algorithm that VTAM uses for CNN routing has changed over the years, as
customers have found new configurations that the old rules did not address very
well. At the time of writing (after APAR OW26906 to VTAM V4R4), the algorithm
is as follows:
1. First, VTAM will favor HPR TGs over non-HPR TGs. However, this only
applies if the HPR-capable TG connects an RTP-capable end node to an
ANR-capable node that is not its RTP partner. In other words:
• If the PLU is on an end node and the first two hops of the path are
HPR-capable, then an HPR TG is preferred for the first hop from the PLU.
• If the SLU is on an end node and the last two hops of the path are
HPR-capable, then an HPR TG is preferred for the last hop to the SLU.
2. Next, VTAM will attempt to select entry and exit TGs that are connected to
the same subarea. If the subarea information is available (from the CV46s or
because VTAM owns the partner LU), it will try to match subarea numbers to
find a zero-hop route through the CNN. Note that VR-TGs are assigned a
subarea number of zero, so a VR-TG will never match another TG.
3. If no subarea match is found, and if the HPRNCPBF start option is set to YES,
VTAM will favor ANNC TGs over other TGs. HPRNCPBF allows VTAM to
favor an HPR path for an NCP-attached LU, even if that path would traverse
the same NCP twice (first from NCP to VTAM to reach the RTP endpoint, then
back to the NCP over an HPR connection). Favoring ANNC over NCP TGs
minimizes the risk of such a path.
HPRNCPBF was introduced by APAR OW25950.
4. Next, VTAM will look for a VR-TG if a suitable one is available.
5. If there is no suitable VR-TG, VTAM will pick any other available TG.
A recent refinement has been introduced by APAR OW29969. This extends the
subarea matching concept so that VTAM can determine that two subareas within
a CNN are “closely linked”, rather than the same. The installation must define a
subarea mapping table (VBUILD TYPE=SAMAP) to tell VTAM which subarea
pairs are considered suitable as entry and exit points for sessions. This subarea
mapping method also eliminates the situation where the chosen subarea pair is
so unsuitable that the installation has not even defined a VR between them; in
such a case the session would fail unless VTAM is told to favor a different pair of

subareas. Unfortunately the SAMAP information is not propagated across the
network, so each CNN must have the same SAMAP table defined if this
extension to CNN routing is to work efficiently.
SAMAP is used only for route calculation, not for BIND rerouting. Its main
purpose is to allow customers with remote NCPs to optimize routes across what
could be quite a complex CNN. For example, consider the network shown in
Figure 122.
┌────────┐
│ │
┌─┤ EN ├─┐
TG 21 │ │ │ │ TG 22
│ └────────┘ │
│ │
┌────────┐ ┌───┴────┐ ┌──┴─────┐ ┌────────┐
│ │ │ NCP │ │ NCP │ │ NCP │
│ VTAM ├────┤ SA 67 ├────┤ SA 55 ├────┤ SA 8 │
│ │ │ │ │ │ │ │
└────────┘ └───┬────┘ └───┬────┘ └───┬────┘
│ │ │
│ │ │
LUA ┌───┴────┐ LUC
│ NCP │
│ SA 10 │
│ │
└───┬────┘
│
│
LUB
Figure 122. SAMAP Example
In this diagram, a session from the end node to LUA will always use TG 21,
because VTAM can match LUA′s subarea (67) against the subareas which
connect the CNN to the end node (67 and 55). However, VTAM cannot match the
subareas for LUB and LUC (10 and 8 respectively) against 67 and 55. Therefore,
sessions from the EN to LUB or LUC will use TG 21 and TG22 alternately. TG 21
is clearly less desirable.
The SAMAP table allows you to associate SA55 with SA8 and SA10, so that
VTAM knows that SA55 is a closer match to SA8 and SA10 than SA67 is. Thus
sessions to LUB or LUC which have a choice between TG 21 and TG 22 will be
allocated to TG 22 (SA 55) rather than TG 21 (SA 67). A subarea mapping table
for this purpose might appear as in Figure 123 (note the prefix SA before the
subarea numbers).
VBUILD TYPE=SAMAP
SA10 MAPSTO SUBAREA=SA55
SA8 MAPSTO SUBAREA=SA55
Figure 123. Subarea Mapping Table

9.4.1 Example of CNN Routing
As an example of the way CNN routing works, consider Figure 124.
Figure 124. CNN Routing Example
The figure shows two composite network nodes, RAS and RAA, connected
together by both an ANNC TG (21) and a VR-TG. A and B are APPN end nodes
connected to the subarea network by two TGs each. Let us suppose that node B
wishes to establish a session with node A, and that all the TGs have equal
weight for the session COS. RAS, as B′s NN server, must calculate the route.
If every node in the network is RTP-capable, then RAS tries subarea matching as
follows:
1. The first intermediate node on the session path is itself, RAS. The entry
subareas are 28 (TG21) and 8 (TG22). The exit subareas are 28 (TG21) and 0
(VR-TG). Therefore, there is a match between TG21 inbound and TG21
outbound. Both TG21s are chosen.
2. Now RAS must choose the route through RAA. It should have the subarea
numbers available from the topology database and from RAA′s response to
the Locate, so it tries subarea matching again. This time it can see that the
possible exit subareas are 10 (TG21) and 5 (TG22). Only the first matches
the known entry TG (TG21, which goes to subarea 10). Therefore, the route
chosen through RAA is again TG21 - TG21.
The complete session path is thus:

Node B - TG21 - RAS - TG21 - RAA - TG21 - Node A
This may or may not be the preferred route, but it is probably better than what it
would have been before APAR OW26906. Previously, a VR-TG was associated
with the subarea numbers of its partner VTAMs. Thus subarea matching in this
example would have chosen the route:
Node B - TG21 - RAS - VR-TG - RAA - TG21 - Node A
which passes through all six nodes.

The optimum route may well be:
Node B - TG22 - RAS - VR-TG - RAA - TG22 - Node A
which does not pass through either host. The only way to force VTAM to prefer
this route is to adjust the TG weights by manipulating the TG characteristics or
the COS tables. A subarea mapping table would not help here because there is
already a valid subarea match.

Chapter 10. Logmode and COS Resolution in a Mixed Network
Once a resource has been located in a mixed subarea/APPN network, the

optimum session route must be found within each part of the network. In both
subarea and APPN networking, the session path is determined by the class of
service; in both subarea and APPN networking, the class of service is
determined from the mode. Beyond this superficial level, however, the two
architectures differ greatly.
10.1 Subarea COS Resolution

In a subarea network, the session mode is chosen at the origin, either by the
OLU or by the SSCP of the OLU. If the OLU is to be the SLU, it may specify the
mode itself (for example, logon applid(tso) logmode(d4c32785)). If no mode is
specified then SSCP(SLU) determines what mode is to be used. The SSCP
checks the DLOGMOD operand in the definition, or if this is absent it picks the
first mode entry in the applicable mode table. The mode table used is either
that specified in the MODETAB operand in the definition, or ISTINCLM if there is
no MODETAB.
If the OLU is to be the PLU, the OLU is expected to supply the mode. If it does
not do so, a mode name comprising all blanks is sent into the network, and
SSCP(SLU) must then resolve it to a named mode from the SLU definitions. If
the SLU is a dynamic CDRSC with no definitions, VTAM uses the DYNDLGMD
and DYNMODTB start options to determine the correct mode to use.
Once the mode is known, it is the responsibility of SSCP(SLU) to translate this

into a subarea class of service. The mode table entry specifies the subarea
COS, although in many networks the default (all blank) COS remains the only
one in use.
The COS chosen by SSCP(SLU) must now be transmitted to SSCP(PLU), which is

responsible for choosing a virtual route list from that COS. Finally, the VR list is
given to the subarea node at the PLU end of the session (which could be
SSCP(PLU) or an NCP it owns); this node activates and uses the first available
VR in the list.
If the subarea network includes SNI boundaries, some of this work must be done
by proxy since VRs are terminated at SNI boundaries:
• The subarea COS is translated, if necessary, at SNI boundaries as it flows in
the secondary to primary direction.
• The VR list is selected by the gateway SSCP of the PLU at each SNI
boundary.
Figure 125 on page 168 illustrates the three main cases:

• PLU-initiated session with a mode supplied by the PLU
• PLU-initiated session with no mode supplied by the PLU
• SLU-initiated session

Figure 125. Subarea COS Resolution
In the first PLU-initiated example, the PLU as OLU has supplied a mode name.
Since it is the responsibility of SSCP(SLU) to resolve the mode name to a COS,
the mode name is transmitted to VTAM2 on the CDINIT request. VTAM2 duly
resolves the COS, and sends the COS name back to VTAM1 on the CDINIT
response. VTAM 1 needs the COS name to create a VR list for route selection.
In the second example, the OLU has failed to supply a mode name so VTAM1
transmits a blank mode to VTAM2 on the CDINIT request. VTAM2 must now
choose a mode (normally from the SLU′s definitions) and immediately resolves
that mode into a COS. As before, VTAM2 sends the COS name back to VTAM1,
but this time it sends the mode name as well.
The third flow shows an SLU-initiated session. Here VTAM2, as SSCP(OLU),

chooses a mode name from the SLU′s definitions or the logon request. As
SSCP(SLU), it immediately resolves the mode name into a COS. Both mode
name and COS are sent to VTAM1 on the CDINIT request. VTAM2 needs no
further information about the session, so VTAM1 simply sends a CDINIT
response with no mode or COS values.

10.2 APPN COS Resolution
In an APPN network the mode is also chosen at the origin. The OLU is expected
to provide a mode name, but a blank entry receives no special consideration.
The mode name is then resolved to a COS also at the OLU end of the session.
Either CP(OLU) resolves the name, or if CP(OLU) is an end node the resolution
may be done by the network node server. A blank COS is not valid in APPN.
The calculation of the route is the responsibility of the network node server of
the PLU. It uses the supplied APPN class of service to assign weights to all the
possible TGs and nodes on the session path, and chooses the path with the
lowest overall weight.
Once again, at subnetwork boundaries some of the work is done by proxy

because topology knowledge does not extend across subnetwork boundaries. In
this case:
• The APPN COS is mapped, if necessary, in the OLU to DLU direction, by the
border node closest to the SLU. This may be the EBN on the SLU side, or
the managing border node on a peripheral boundary.
• Each segment of the route is calculated by the node acting as NNS(PLU) in
that subnetwork. This may be the real NNS(PLU), or a border node on the
SLU side of the boundary, or an NN on the SLU side of a peripheral border.
An exception to the “route calculated by NNS(PLU)” rule occurs if the session

path crosses between APPN and subarea (in other words, an interchange
transmission group is on the session path). In this case the APPN part of the
route is calculated by NNS(OLU) even if OLU is SLU. This is because the
subarea at which the session will enter the subarea network needs to be known
before the subarea part of the route calculation is done.
Figure 126 on page 170 shows how this works in the SLU-initiated and
PLU-initiated cases.
Chapter 10. Logmode and COS Resolution in a Mixed Network 169

Figure 126. APPN COS Resolution
The APPN example shown here is the simplest one, that of session initiation
between an end node and its network node server. Any other configuration
would be more complex, but the exchange of mode and COS names between
PLU and SLU is essentially the same.
In the PLU-initiated case, EN1 as CP(OLU) chooses both the mode and the
APPNCOS. Both pieces of information are sent on the Locate request, which in
this case never gets beyond NN2 which is both CP(SLU) and NNS(PLU). As
NNS(PLU), NN2 has all the information it needs to calculate the route, so it
responds with the session RSCV on the Locate reply. EN1 can then start the
session.
In the SLU-initiated case, NN2 is CP(OLU) as well as being NNS(PLU). Therefore

NN2 must:
• Choose the mode
• Resolve the mode to an APPNCOS
• Calculate the route
NN2 can do all these things without consulting any other node in the network, so
it sends a Locate to EN1 with the mode, the APPNCOS and the session RSCV.
EN1 can start the session at once, and the Locate reply contains a “session
started” indicator to tell NN2 that the BIND has been sent.
Note that in the PLU-initiated case EN1 and NN2 could be any APPN products,
but in the SLU-initiated case both must support session services extensions
(today, that means both must be VTAM). The “session started” flow is part of
the session services extensions APPN option. To support SLU-initiated sessions

and other enhanced APPN functions, all the node roles concerned in all the
APPN subnetworks through which the session will pass must support session
services extensions. This means CP(PLU), CP(SLU), NNS(PLU), NNS(SLU) and
any nodes acting as such at subnetwork boundaries.
10.3 COS Resolution in a Combined Network

In a mixed subarea and APPN network, it is fairly clear that each type of network
will follow its own rules within that network. The choosing of modes, the
resolution of COSs and the selection of routes are all done in the same ways at
the same places. The complexity arises because:
• The resolution of mode to COS to route is done at different stages of the
session setup flow in the two types of network.
• VTAM has more than one way of resolving COS names.
• Every VTAM, even if no HOSTSA has been coded in the start options, acts as
a subarea node internally. Therefore, the subarea COS resolution rules
apply even within pure EN or NN VTAM nodes.
10.3.1 VTAM′s Methods of COS Resolution

In a subarea network, VTAM acts as SSCP for OLU, DLU, SLU or PLU depending
on how a particular session is being established. When APPN is added, the
roles in which VTAM may need to resolve COS names are multiplied: SSCP, CP,
NNS or interchange node. VTAM has two basic methods of determining a COS
name to be used in a particular network for a particular session: from the mode,
or from another COS that has already been determined for another portion of the
network.
The traditional way for VTAM to choose a class of service for a session is by
looking up the mode entry in the mode table associated with the SLU and
reading the COS name from the entry. If the entry is not found in the SLU′ s
mode table, VTAM will look for it in the default table ISTINCLM. Today, both
subarea and APPN COS names can be specified in a mode entry, and indeed the
IBM-supplied mode table ISTINCLM includes the architected APPN COS names
in the appropriate mode entries. In today′s environment, this method is still
used:
• When the second method (COS mapping) will not work because there are no
suitable COS map definitions.
• When this VTAM is the first to see this session request, thus there is no
existing COS to map. The first COS to be resolved on a session is always a
subarea COS, and is always resolved by the mode table lookup method.
If the mode for the session is known then the matter is straightforward. If the
mode name is not recognized then there is a default mode, ISTCOSDF, that
VTAM will use to look up the COS. The use of ISTCOSDF is controlled by the
start option ISTCOSDF, which tells VTAM what kinds of resource may use the
ISTCOSDF mode. As with the “real” mode entry, if VTAM does not find
ISTCOSDF in the table associated with the SLU it will look for it in ISTINCLM.
Figure 127 on page 172 shows part of a mode table with the appropriate COS
entries for subarea (COS=) and APPN (APPNCOS=) coded. The IBM-supplied
table ISTINCLM now includes APPNCOS operands; it has never had subarea
COS names defined.

USERTAB MODETAB
... ... ... ... ... ... ... ...
TITLE ′ SNASVCMG′
**********************************************************************
* LOGMODE TABLE ENTRY FOR RESOURCES CAPABLE OF ACTING *
* AS LU 6.2 DEVICES *
**********************************************************************
SNASVCMG MODEENT LOGMODE=SNASVCMG,TYPE=0,FMPROF=X′ 1 3 ′ , TSPROF=X′ 0 7 ′ , *
PRIPROT=X′ B0′ , SECPROT=X′ B0′ , COMPROT=X′ D0B1′ , *
RUSIZES=X′9797′,ENCR=B′0000′, *
PSERVIC=X′060200000000000000002300′, *
APPNCOS=SNASVCMG,COS=SAMGT
*
TITLE ′ # BATCH′
***********************************************************************
* *
* LOGMODE TABLE FOR BATCH SESSIONS ON RESOURCES CAPABLE *
* OF ACTING AS LU 6.2 DEVICES *
* *
***********************************************************************
#BATCH MODEENT LOGMODE=#BATCH,FMPROF=X′ 1 3 ′ , TSPROF=X′ 0 7 ′ , *
ENCR=B′0000′,SSNDPAC=3,RUSIZES=X′ F7F7′ , *
SRCVPAC=3,PSNDPAC=3,APPNCOS=#BATCH,COS=SABATCH
... ... ... ... ... ... ... ...
Figure 127. Example Mode Table
The second method of COS resolution is for VTAM to translate a COS supplied
on one type of network to a different COS on the other type of network. This
involves the coding of COS mapping tables in VTAMLST and their activation.
The COS mapping method is preferred by VTAM, even if the appropriate COS
entries are in all the mode tables.
Figure 128 illustrates sample COS mapping tables from subarea to APPN
(SATOAPPN) and APPN to subarea (APPNTOSA).
TABLE1 VBUILD TYPE=SATOAPPN

SACOS MAPSTO APPNCOS=#CONNECT,DEFAULT=YES
SAMGT MAPSTO APPNCOS=#SNASVCMG
SABATCH MAPSTO APPNCOS=#BATCH
... ... ... ... ... ... ... ...
TABLE2 VBUILD TYPE=APPNTOSA
#CONNECT MAPSTO COS=SACOS,DEFAULT=YES
SNASVCMG MAPSTO COS=SAMGT
#BATCH MAPSTO COS=SABATCH
... ... ... ... ... ... ... ...
Figure 128. Example COS Mapping Tables
If you wish to specify the default subarea COS (blank) as either the origin or the
target of a COS mapping table entry, you need to install APAR OW28568. This
function was introduced after the availability of VTAM V4R4. If you do not have
OW28568 applied, you can still map the blank subarea COS to an APPN COS by
means of the DEFAULT entry, which VTAM uses if it cannot find the incoming
subarea COS in the table. Without OW28568 it is not possible to map an APPN
COS to the blank subarea COS.

If VTAM has a COS mapping table coded, it will always attempt to use it to
translate one type of COS to the other. Only if COS mapping fails (or there is no
mapping table) will VTAM attempt to resolve a COS using a mode table entry.
However, if the route being established is for an RTP connection crossing from
APPN to subarea, VTAM will never use the mode table lookup method to
determine the subarea COS. This is because a route setup (as opposed to a
BIND) may not contain a mode name. In this case VTAM will first try the
APPNTOSA mapping method, and if that fails it will choose the default ISTVTCOS
class of service in the subarea portion of the network.
10.3.2 An Example of a Mixed Network

Figure 129 illustrates how COS resolution is performed in a mixed network for
an SLU-initiated session.
Figure 129. COS Resolution, Mixed Network, O L U = S L U
In the diagram, the four nodes are all VTAM nodes. If EN or NN were not VTAM,
then an SLU-initiated session would not be possible because only VTAM today
supports session services extensions.
The first thing to realize here is that there are three subarea networks in the
diagram. Each of the stand-alone VTAMs (EN and NN) uses subarea protocols
between the session partner LU and the boundary function to the adjacent APPN
network. Because OLU=SLU, the subarea and APPN protocols fit together quite
well, as follows:
1. The SLU issues a logon (or INIT_SELF) request to its owning VTAM. As
SSCP(OLU), the VTAM network node determines the session mode to be
used. Since it is also SSCP(SLU), it immediately resolves the mode into a
subarea class of service (COS) and sends the session request on its way.

The request gets as far as the APPN boundary function, where it must be
translated into a Locate and forwarded into the APPN network. At this point
VTAM is CP(OLU), so it is responsible for both mode and class of service in
the APPN network. It already has the mode, and the APPN COS is chosen
by the COS mapping table or by looking up the same mode table as it used
for the subarea COS. The Locate request is sent into the APPN network with
the correct mode and APPN COS; the desired subarea COS is not present
since there is no space for it in the CDINIT GDS variable.
2. The Locate request reaches the interchange node which now acts as
SSCP(SLU) in the central subarea network. The ICN must forward a CDINIT
into the subarea network, and as the SSCP for both OLU and SLU it must
provide both mode and subarea COS. The subarea COS is not present in
the received Locate, so the ICN uses the normal methods to determine it. It
tries the COS mapping table, and if that fails it uses the mode table. The
SLU is probably a dynamic CDRSC in this node, and therefore does not have
a MODETAB defined. VTAM will use the default mode table ISTINCLM to
locate the mode table entry, unless the DYNMODTB start option has been
coded. VTAM replaces the supplied APPN COS with its own subarea COS
and forwards the CDINIT into the subarea network.
3. The ICN at the far end of the subarea network receives the CDINIT. It is
NNS(OLU) in the next APPN network, so it must supply mode and APPN COS
to that network. The original mode is still in the CDINIT, but only a subarea
COS is available. Once again, VTAM looks up the mapping in the COS
mapping table (if present), or falls back to choosing an APPN COS for a
dynamic CDRSC if the COS mapping fails. VTAM forwards a Locate request
into the APPN network, still with the original mode but with a
twice-translated APPN COS. This VTAM remembers the subarea COS
because it will need it to select a VR (as SSCP(PLU)) when the subarea
session is started.
4. The VTAM EN which owns the PLU receives the Locate. In APPN terms it
has no responsibilities at all, since the mode and APPN COS have been
chosen for it, and the APPN route has been calculated for it by its NN server.
It still needs a subarea COS for its internal processing, so it performs the
usual mapping or lookup from the APPN COS or the mode name. It sends
CINIT to the PLU to start the session, but it has no new information to return
to the SLU so it responds with a Locate/Found/CDINIT which says simply that
the session has started. This Locate may, in fact, flow after the BIND which
starts the session.
5. The ICN at the PLU end of the session forwards the CDINIT response as soon
as it receives the BIND or the Locate reply. If the session was not started
immediately (for example, it was queued) then the BIND will not flow at this
time.
6. When the ICN at the SLU end of the session receives the CDINIT response
saying the session can start, it exchanges CDCINIT and response with
ICN(PLU) and then forwards the BIND when it arrives. When it receives
CDSESSST it will also forward a Locate/Find/CDINIT with the Session Started
indicator.
From the above discussion, you can see that SLU-initiated sessions in a mixed
network work quite well. The mode for the whole network is chosen by the same
node (OLU=SLU), the subarea and APPN classes of service are chosen on the
same flows, and the COS mapping works as you would expect it to work.

Note that the two APPN networks have their session routes calculated
independently, and the session RSCVs never leave their own subnetworks.
Because each APPN route contains an IC-TG, the RSCVs must be precalculated
by NNS(OLU), not NNS(PLU). In this example NNS(OLU) is NNS(SLU) in the
right-hand network.
Note also that if a VR-TG is defined across the central subarea network, the
APPN Locates flow across the VR-TG and no subarea-to-APPN protocol
conversions are needed. Such a route would be calculated by NNS(PLU).
Figure 130 shows how the same network deals with a PLU-initiated session.
Figure 130. COS Resolution, Mixed Network, O L U = P L U
Once again subarea protocols are used in three networks and APPN protocols in
two networks. This time, however, they do not fit together as smoothly as in the
SLU-initiated example:
1. The PLU issues a session request (OPNDST, probably) to its owning VTAM,
with a mode specified. This VTAM EN is CP(OLU) for the session, so it
selects an APPN COS. The architecture allows it to leave COS selection to
its NNS, but VTAM always chooses the COS itself. It tries to do this from the
SLU definitions, but these probably do not exist since the SLU is out in the
APPN network and is (or will be) represented by a dynamic CDRSC. If this is
so, VTAM picks the mode table specified in the DYNMODTB start option if it
exists; otherwise, it picks ISTINCLM.
VTAM chooses an APPN COS as follows:
a. It takes the chosen mode from the chosen mode table and picks out the
subarea and APPN COS values.
b. It tries to use the SATOAPPN COS mapping table to convert the subarea
COS into an APPN COS.

c. If this fails, it takes the APPN COS entry from the mode entry.
d. If there is no APPN COS entry coded, it checks for an APPN COS with the
same name as the subarea COS.
e. If there is no valid APPN COS with the same name as the subarea COS,
it uses the APPNCOS start option. If the start option does not specify a
valid COS the session fails.
f. If the subarea COS is blank, it uses #CONNECT.
It is thus possible for the APPNCOS value coded in the mode table entry to
be ignored in favor of a value mapped from the subarea COS.
2. The Locate reaches the ICN at the start of the subarea network. This node,
which acts as SSCP(PLU) in the subarea network, will select the VR when
the time comes but cannot specify the subarea COS since that is the function
of SSCP(SLU). The ICN therefore removes all reference to a COS and
forwards into the subarea network a CDINIT which bears just a mode.
Neither the COS mapping nor the lookup method of COS resolution is used
by this node in this role.
3. The ICN at the exit of the subarea network must now propagate the search
into the right-hand APPN network. As NNS(OLU) it has to provide both a
mode and an APPN COS. The mode is available but there is no subarea
COS to be translated. Therefore it chooses an APPN COS in the same way
as CP(OLU) did earlier, in other words it tries SATOAPPN mapping first and
then table lookup. It, too, probably has to contend with the fact that the SLU
is a dynamic CDRSC. It forwards the Locate into the APPN network.
4. The VTAM NN receives the Locate request. As NNS(SLU=DLU) it has no
resolution role to play in the APPN network, but as SSCP(SLU) it is
responsible for selecting a subarea COS. This subarea COS, however, has
no practical value in this particular configuration since the subarea session
path is purely internal (if this VTAM were a CNN it would have practical
value because it would determine the path through the CNN). VTAM returns
the APPN Locate/Found to the network, carrying just the original mode. This
mode name is already known in the VTAMs on the return path, but the mode
is a mandatory field in the CDINIT GDS variable (unlike the COS) so it is
present.
5. The ICN at the SLU side of the subarea network, on receipt of the Locate,
has to select a subarea COS because it is SSCP(SLU). It still remembers the
APPN COS from the outbound Locate because it must use it to calculate the
route. It uses this APPN COS to select a subarea COS by means of the COS
mapping tables; if COS mapping fails it uses the mode name to select a
subarea COS. This ICN now forwards the CDINIT response into the subarea
network, with both the mode and the newly chosen subarea COS.
Note that this particular ICN has now translated the same session COS twice:
from subarea to APPN on the PLU-to-SLU flow and from APPN to subarea on
the SLU-to-PLU flow. It is possible for the SATOAPPN and APPNTOSA tables
to be used to map and re-map the same COS; this is only a problem if the
tables are not mirror images of each other.
6. The ICN at the PLU side of the subarea network now receives the CDINIT
response, with enough information (the subarea COS) to select a VR for the
session. It must also reply to the original Locate, so it sends a Locate/Found
back to NNS(PLU).

7. The PLU VTAM, like the ICN at the SLU side of the subarea network, is
SSCP(SLU). It now has to select a subarea COS because it must handle the
SLU-to-PLU flow. It takes its previously determined APPN COS and performs
the same actions as the SLU-side ICN did. Again the same mapping can
occur forwards and backwards using different tables. In this case the
subarea COS is meaningless, but if CP(PLU) were a CNN the COS could be
used to select a VR across the CNN.
In the PLU-initiated case the APPN and subarea classes of service are chosen
on different flows: the APPN in the PLU-to-SLU direction and the subarea in the
SLU-to-PLU direction. The COS mapping still works, but it does not work in the
obvious way. Moreover, if the PLU exercises its right not to provide a mode
name, the flows are complicated still further:
1. The VTAM EN, when choosing an APPN COS for the session, will try to
resolve it from the DLOGMOD in the SLU′s definitions, or the first entry in
the mode table if there is no DLOGMOD. However, it is likely that the SLU is
a dynamic CDRSC and therefore it will try to use:
a. DYNMODTB, then ISTINCLM, for the mode table
b. DYNDLGMD, then the first entry in the table, for the mode
Once the correct mode entry has been determined, the method of choosing
the APPN COS is the same as in the case where the PLU supplied a mode.
However, the mode name forwarded into the APPN network is still blank.
2. The ICN at the PLU side of the subarea network forwards the blank mode in
the CDINIT to the subarea network.
3. The ICN at the SLU side of the subarea network must again resolve a blank
mode to an APPN COS. As with CP(OLU), it must contend with both a blank
mode and a dynamic CDRSC for the SLU.
4. CP(SLU) receives the blank mode, and its subarea side resolves it to a real
mode. At last the real SLU is available, probably with suitable definitions,
and this VTAM finally selects the real mode required for the session. It is
this real mode name that is now sent back into the network.
5. The ICN at the SLU side now selects a subarea COS as before, but this time
there is a possible complication. It first tries to use the COS mapping
method, which is based on the APPN COS chosen from the blank mode. If
this fails, however, it will attempt the table lookup method for which it has
the real mode. Thus even if the real mode is available, the subarea COS
chosen could be the result of the blank mode.
6. The ICN at the PLU side forwards the new mode to the EN, as before.
7. CP(PLU) receives a new mode name (which of course differs from the one it
chose on the outbound flow to resolve the APPN COS). The new mode is
given to the PLU to start the session. As before, CP(PLU) performs an
APPN-to-subarea COS translation which may originate (as with ICN(SLU))
from the blank mode or the real mode depending on circumstances.
Thus it is perfectly possible to end up with a different subarea COS to the one
you started with. The translation from subarea to APPN to subarea occurs at the
same node in different directions, and may well not yield the answer you want.
Note:
The APPN routes in this example are calculated by NNS(PLU) and ICN(PLU), in
the left- and right-hand networks respectively. Again there are IC-TGs in both

session paths, and this time NNS(OLU) = NNS(PLU) in each network. Once
again, the use of VR-TG simplifies matters. However, if the central subarea
network contains an SNI boundary (a likely situation) then VR-TG is not possible.
10.4 Issues and Possible Solutions

Unexpected things can happen in a mixed network, especially for PLU-initiated
sessions, for various reasons:
• VTAM performs COS resolution from the mode using its knowledge of the
SLU, and never the PLU, for both subarea and APPN classes of service . This
is because every VTAM is a subarea node internally, and in subarea
networking the SLU′s mode table is used to resolve COS names. In a mixed
network, the SLU is often known as a dynamic CDRSC and therefore has no
definitions. A default COS based on the first entry in ISTINCLM is very likely
to be picked.
• Because the COS mapping on PLU-initiated sessions is done on different
flows for APPN and subarea, you may find that the COS you end up with is
not the COS you asked for in the first place.
• If the PLU does not provide a mode name, and if APPN-to-subarea mapping
tables are not used, the APPN and subarea COSs are chosen using different
mode names: the blank mode for the APPN COS and the SLU-resolved mode
for the subarea COS.
• Host CP resources are not dynamic CDRSCs, but are dynamic applications .
Therefore, there is no possibility of defining MODETAB or DLOGMOD for
CP-CP sessions or for any other type of session that has them as SLUs (such
as DLUR/S sessions or APING sessions). As a result, CP-CP sessions use
the default subarea COS which causes them to flow at low priority over a
subarea connection.
Several solutions are available to these issues:

1. Predefine resources as CDRSCs, with MODETAB and DLOGMOD coded as
necessary.
This option allows you to specify in great detail which session will use which
class of service in which network. However, it adds significant overhead to
the network administration task, and thus negates some of the benefits of
APPN.
2. Modify ISTINCLM with appropriate subarea COS values.
This option allows you to use a single table for all resources without the
need to predefine CDRSCs with MODETAB. However, it must be done on all
nodes in the network and must be re-done with every new release of VTAM;
another perhaps unacceptable administrative overhead.
3. Use the DYNMODTB and DYNDLGMD start options.
This option, recommended by CS OS/390 Development, allows you to specify
a given mode table and mode entry to be used for dynamic CDRSCs.
Although this is not as comprehensive a solution as (1) (all dynamic CDRSCs
must use the same table), it alleviates many of the issues and is very easy to
implement. In any case, CS OS/390 Development strongly recommends that
customers merge all their mode tables into a single table that can be used
for all resources.
4. Use COS mapping tables throughout.

This option works very well for SLU-initiated sessions, but not so well for
PLU-initiated ones. It will probably require some modifications to the COS
entries in your mode tables. Use of the APPN-to-subarea mapping table is
the only option available if you are using HPR over VR-TG and do not wish
the default ISTVTCOS subarea COS to be used in every case.
5. To change the subarea COS used by CP-CP sessions, you can apply APAR
OW26928 which adds COS=ISTVTCOS to the modes in ISTINCLM used for
CP-CP and DLUS-DLUR sessions, thus giving them high priority.
Alternatively, you can issue the F netproc,RESOURCE command against a host
CP to change the MODETAB and/or DLOGMOD values.
Other useful tips include:

• If a mode supplied to VTAM is not found in the appropriate table(s), you can
use the ISTCOSDF start option to provide one. The start option specifies
whether VTAM is to use a default mode entry called ISTCOSDF depending on
the nature of the SLU on the session request. By default, the start option
applies the technique to independent LUs only, and the ISTCOSDF mode
entry in ISTINCLM is an LU 6.2 entry pointing to APPN COS #CONNECT.
• If a subarea COS name is not recognized, VTAM will use the COS table entry
with SUBSTUT=YES coded on it.
• If an APPN COS name is not known, VTAM will use the name specified by
the APPNCOS start option.

Chapter 11. Sysplex Considerations
One of the main reasons for customers migrating to APPN is the implementation
of a sysplex. The Parallel Sysplex provides some unique advantages to the
VTAM installation, namely generic resources and multinode persistent sessions.
Generic resources allows multiple application copies on a sysplex to present a
single image to the user, resulting in better performance through load balancing
and improved availability. The multinode persistent sessions function enables
sessions to survive, without disruption, the failure of a VTAM, MVS or even a
processor in a sysplex. The redbook VTAM in a Parallel Sysplex Environment ,
SG24-2113, describes the workings of SNA in a sysplex.
The generic resources and multinode persistent sessions (MNPS) functions both
require APPN to be implemented within the sysplex; indeed, MNPS depends on
HPR for its operation. This means that all the VTAMs within the sysplex must be
able to establish CP-CP sessions with each other. For the purpose of generic
resources VR-TG connections are sufficient, but if you want MNPS to work
reliably you need FID2 connections instead (or as well).
VTAM systems within a sysplex have two primary means of communicating with
each other. They may use dedicated ESCON channel-to-channel connections, or
they may use the MVS Cross-System Coupling Facility (XCF). Both offer
high-performance APPN connectivity, but whereas a dedicated
channel-to-channel link can use base APPN or HPR, XCF requires HPR.
In the earlier sections of this redbook, we have described the basic migration
scenario as being:
1. Convert CMC(s) to APPN
2. Convert boundary links (former LEN connections) to APPN
3. Convert subarea links (between VTAMs) to APPN, node by node
This plan holds good for networks both small and large, but the installation of a
sysplex may require a somewhat different approach. Here we are adding a
whole new APPN network to what might be a pure subarea network, and we
have to integrate them.
This chapter illustrates some possible migration scenarios involving sysplex

configurations, and offers some guidelines from CS OS/390 Development on the
advantages and disadvantages of each. There are four examples:
1. APPN within sysplex only, all nodes subarea capable
2. APPN within sysplex only, no subarea within sysplex
3. APPN everywhere, no subarea within sysplex
4. APPN everywhere, all nodes subarea capable
11.1 All Nodes Subarea Capable

In this example, the APPN network is confined to the sysplex, but subarea
connections are retained both inside and outside the sysplex. Figure 131 on
page 182 illustrates this.

Figure 131. Case 1, Subarea Everywhere
The CMC and the backup CMC (BCMC) are outside the sysplex, which contains
NNs and ENs. The NNs must be ICNs because there is no APPN capability
outside the sysplex; the ENs are MDHs to retain subarea capability. All VTAMs
and NCPs are connected to each other using ESCON channels as shown; the
VTAMs in the sysplex may or may not also have XCF connections. Inside the
sysplex the CP-CP sessions are on FID2 links. All VTAMs have SSCP sessions
with each other (as they must), over subarea MPC connections. All VTAMs
inside the sysplex are connected by VR-TGs (not necessarily fully meshed), to
avoid parallel APPN and subarea paths. The CMC owns all the NCPs as its
name implies.
The advantages of this configuration are as follows:

• The existing subarea network is unchanged and existing sessions can be
established as before. The risk of disruption due to changes is therefore
minimized. The CMC and backup CMC do not have to be upgraded to
support APPN.
• HPR is available within the sysplex. Also, most of the subarea-to-sysplex
sessions can use HPR inside the sysplex (and therefore MNPS), as long as
they use the FID2 connections within the sysplex. If only FID4 connections
were available within the sysplex, sessions originating from the external
subarea network would be subarea all the way (because of RSCV pruning)
and thus could not use HPR or MNPS.

• Sessions that are entirely subarea do not have to pass through an ICN
because there is subarea connectivity between all nodes inside and outside
the sysplex.
• BSC 3270 sessions can reach all nodes within the sysplex.
The disadvantages of the configuration are:

• All the VTAMs in the network require new CDRM and PATH definitions, and
perhaps also CDRSCs and adjacent SSCP tables.
• All sessions from subarea to APPN (for example, MNPS sessions) must pass
through an ICN and may not traverse the optimum path.
• There are parallel independent APPN and subarea paths between some
nodes. Unpredictable session routes may result.
11.2 APPN Within Sysplex Only

In the second example, the APPN network is again confined within the sysplex
but this time there are no subarea links inside the sysplex. Figure 132 depicts
the example.
Figure 132. Case 2, APPN Within Sysplex
The difference here is that there are no subarea connections, or SSCP sessions,
to the end nodes within the sysplex. The physical connectivity is the same, but
Chapter 11. Sysplex Considerations 183

the connections between the ENs and the NCPs are effectively unusable. This is
because the NCPs are owned by a subarea-only node and therefore incapable of
APPN, whereas the ENs understand only APPN. These links can only be
regarded as LEN links, and only PLU-initiated LU 6.2 sessions can be established
on them.
The advantages of this configuration are:

• As in the first example, the risk due to change is minimal. The existing
network remains unaltered.
• HPR can be used by sessions within the sysplex, and most sessions between
the sysplex and the subarea network. MNPS functions are available to these
sessions.
• No additional CDRM or PATH definitions are required for the ENs in the
sysplex.
The disadvantages, on the other hand, are:

• The EN-to-NCP links are of little practical use.
• New PATH and CDRM definitions are still required because the new ICNs are
in the subarea network.
• BSC 3270 connectivity is not available to the sysplex ENs.
• As before, sessions between subarea and APPN must always traverse an
ICN.
11.3 APPN Everywhere

In our third example, the APPN network is extended to the CMCs, and therefore
to the backbone. Only the CMCs now have subarea capability, as they must
because they own (or can take over) the NCPs. The only SSCP session is
between the CMCs, which now act as the interchange nodes. Figure 133 on
page 185 shows this scenario.

Figure 133. Case 3, APPN Everywhere
Here there are CP-CP sessions over FID2 links within and outside the sysplex.
To complete the picture (and to ensure that independent parallel subarea and
APPN paths do not exist) a VR-TG is defined between the two CMCs. The whole
of the network is now APPN, with the subarea portion confined to the two CMCs
and their NCP backbone. The NNs within the sysplex are now solely NNs, not
ICNs.
This configuration has the following benefits:

• No new CDRM or PATH statements are required anywhere. This option
needs minimum definition.
• HPR is available throughout the network, with many more possibilities for
path switching after a failure. Even sessions originating in NCP-attached
dependent LUs can use HPR, provided the HPRNCPBF start option is used
correctly.
• The number of APPN-to-subarea sessions (whose routing is constrained by
the location of the ICNs/CMCs) is much smaller since all dependent LUs on
the backbone are part of the APPN network. Optimum routing is more likely
in most cases.
• All the connections between the NCPs and the sysplex nodes are available
for routing. The NCPs are now APPN-capable.
There are three possible disadvantages, however:

• The existing network undergoes a major change including upgrading to
APPN. Thus the risk to established operations is increased.
• BSC 3270 connectivity is not available to the sysplex ENs or NNs. If this is
required a BSC-to-SNA converter such as an IBM 2218 will be needed.
Alternatively, a session manager product such as NetView/Access can
convert BSC 3270 sessions to SNA sessions, thus obviating the need for a
subarea path between the session manager node and the PLU application
node.
• Conversion of NCP INN connections (subarea TGs) to APPN BF-TGs will
result in increased resource utilization on the 3745s.
11.4 APPN and Subarea Everywhere

In the fourth example, the APPN network is again extended throughout the
network, but the subarea network is also extended into the sysplex. Now both
subarea and APPN connectivity are available everywhere. Figure 134 shows the
configuration.
Figure 134. Case 4, APPN and Subarea Everywhere
Now every node has a subarea path to every other node, and all the VTAMs
have both SSCP sessions with each other, and CP-CP sessions where required.
The only FID2 connections are within the sysplex (ANNC or XCF). All NNs are

also ICNs, but the NCPs are still owned by the CMCs. VR-TGs are defined to
ensure full APPN connectivity over the subarea network.
This configuration is intended to maximize the benefits, but there is

corresponding work to be done:
• HPR is available throughout the network, with many alternate routes for path
switching. As long as the FID2 connections are in place within the sysplex
then MNPS is available to LUs both inside and outside the sysplex.
• Optimum routing can be expected throughout the network because APPN is
available throughout. In fact, because VR-TG is also present throughout the
network, this configuration allows the greatest control over session paths.
• BSC 3270 can be supported by every node in the network.
The disadvantage is simply that, because the new portion of the network is
subarea capable, a full complement of CDRM, PATH, adjacent SSCP and CDRSC
statements will be required.

Chapter 12. Management of a Combined Network
At first glance, the prospect of converting the management of a subarea network

to the management of an APPN network seems a major task. However, provided
your management products are at a reasonably current level the facts are that:
1. You lose nothing.
2. You may gain something.
This is because when you convert a VTAM-based network to APPN, the same
management information flows between the same nodes to a very large extent.
The connections may be APPN and the sessions may be LU 6.2, rather than
subarea and SSCP-PU/LU, but the flow of data is the same. Whether you use
DLUR/DLUS for your dependent LU sessions or not, you still have SSCP-PU and
SSCP-LU sessions to carry the same management data on their behalf. The
biggest change is the ability to “see” topology and session information beyond
what were once LEN connections, and start managing a wider network.
Your management processes and procedures need not change significantly

unless you want to extend the scope of your subarea management and exploit
the new functions available. For this you will probably need new tools, but the
existing tools that work in a subarea environment should allow you to operate
the same way in a mixed environment.
For further information on managing APPN networks, we recommend the

following redbooks:
• Managing Your APPN Environment Using NetView , GG24-2559
• Dynamic Subarea and APPN Management Using NetView V3R1 , SG24-4520
12.1 Principles of Network Management in APPN

In a subarea environment there are two methods of exchanging management
data between nodes:
• An application-based method using LU-LU sessions. Examples are the LU
6.2 sessions used by NetView/DM to distribute code and data updates to
remote nodes, and the LU 0 sessions used by NetView Performance Monitor
to gather NCP statistics. Products such as NetView also use LU-LU sessions
to communicate management data from one copy of a product to another
acting as a management focal point.
• An ownership-based method using SSCP-PU sessions. Activations,
deactivations and alerts flow on such sessions to the owning VTAM, which
notifies changes to NetView and accepts instructions from NetView via an
application programming interface.
The format and contents of the data flowing on SSCP-PU sessions depends on
the level of currency of the node containing the PU. The more up-to-date nodes
use network management vector transport (NMVT) request units containing
management vectors. Older nodes send RECMS and RECFMS request units.
The issue with APPN, of course, is that there are no PUs and therefore no
SSCP-PU sessions. Ownership is distributed or nonexistent, so a new structure
is needed which defines a relationship between a managing node and a

managed node. In the APPN parlance, these are known as a “focal point” and
an “entry point” respectively. There is no fixed relationship between node types,
product types, and APPN management roles. Figure 135 on page 190 shows the
APPN management structure.
Figure 135. APPN Management Structure
The principles of management in an APPN network are as follows:

• The only hierarchy of management roles is that already defined in APPN: an
end node relies on its network node server for access to the network
resources. Thus unsolicited data from an end node already has a suitable
session path, namely the CP-CP session pair, to reach the network node
server.
• The focal point itself could be anywhere in the network. Therefore, when an
NN identifies its management focal point it establishes an LU 6.2 connection
with it, using mode SNASVCMG, for the purpose of transferring unsolicited
data (alerts). Thus an end node automatically inherits the focal point of its
network node server.
• The focal point may request information directly from, or issue instructions
to, an entry point node. If it does not already have an LU 6.2 connection with
that entry point it will set one up, again using mode SNASVCMG.
• There are several categories of management information that may flow, and
each entry point may use a different focal point for each management
category. Thus an EN or NN can have several focal points concurrently. The
management categories defined in the architecture are:
− Problem Management
− Performance and Accounting Management
− Configuration Management

− Change Management
− Operations Management, which itself has two subcategories, namely
Common Operation Services and Operations Management.
The categories of greatest concern to an installation migrating from subarea
to APPN are those which depend on the SSCP-PU sessions for management
information in the subarea network; these are the Problem and Operations
categories.
• Primary and backup focal points may be defined for each category.
• Management information is carried using multiple domain support (MDS)
protocols. MDS request units contain management vectors as in NMVT RUs,
although new vectors have been defined for APPN.
MDS support has been available in NetView since Version 2 Release 2 (and is
therefore in the TME10 NetView product). Since Version 4 Release 1 VTAM has
also provided MDS support; NetView from V2R4 onwards can be configured to
use either VTAM′s or its own support. MDS is also supported by current levels
of the Communications Server suite, 3746, 2216, 2210, AS/400 and 3174.
12.2 Familiar Functions

Many of the functions familiar to the VTAM operator or network manager are
very similar in an APPN environment to what they were in the subarea network.
This is because, when a node moves from subarea to APPN operation:
• Either it is not aware of APPN, in which case:
− Either it must remain directly attached to a subarea node, in which case
SSCP-PU sessions are still available,
− Or it must utilize DLUR/S, in which case SSCP-PU sessions are still
available.
• Or it supports APPN, in which case it will support MDS for exchanging
management information.
In this section we describe how these functions are performed, and how they
appear, in an APPN network.
12.2.1 Status and Control

The fact that VTAM in a mixed subarea/APPN network has two “faces”, one for
each network, may seem confusing at first. However, its great advantage is that
many of the VTAM displays after APPN migration will look quite familiar to the
operator, even though some subtle changes will be noted.
The DISPLAY command gives a view of connectivity and status in both subarea
and APPN networks. Because the APPN support in VTAM is built on the
independent LU support introduced in V3R2, if you understand the LEN/ILU
displays you will almost certainly have no difficulty with the APPN displays.
Figure 33 on page 72 and Figure 54 on page 85 are annotated illustrations of
typical resource displays in an APPN environment.
Points to note regarding VTAM resource displays include:

• Dependent LUs (owned by this VTAM) and their PUs appear the same if they
were directly attached. Even if they are DLUR resources the displays are
almost identical to the directly attached case.
Chapter 12. Management of a Combined Network 191

• Remote LUs are represented in APPN by CDRSCs with this VTAM as owner,
just like independent LUs in VTAM V3R4.2 and previous releases. These
remote LUs include control points, since an APPN control point is just
another LU. As in the LEN environment, such displays only have meaning if
the resources in question are in session with an LU owned by this VTAM.
DLUR LUs owned by another VTAM appear to this VTAM as independent
LUs, not subarea CDRSCs.
• PUs only exist in the subarea network, in the sense of resources which
VTAM activates. In APPN, however, as in LEN, VTAM refers to an adjacent
link station as a PU. Thus directly attached APPN nodes are represented as
PUs, but VTAM will not have SSCP-PU sessions with them unless they
happen to be combined type 2 and type 2.1 nodes.
• New displays are introduced for APPN-specific aspects:
− Remote resources have APPN directory entries, as well as (perhaps)
CDRSCs.
− APPN topology may be displayed using the D NET,TOPO command.
− Other APPN-only functions such as network node server, adjacent cluster
tables, COS mapping tables, and TG profiles may be displayed using
new keywords on the DISPLAY command.
The VARY command is used in exactly the same way in APPN, except that you
have to remember that VTAM may no longer own the same resources as it did in
the subarea case. Activation and inactivation commands control only direct
connections (adjacent link stations) and DLUR resources.
12.2.2 Problem Investigation

Over and above the VTAM displays and traces, the major problem investigation
tools are provided by NetView. Since NetView now supports MDS as well as
SSCP-PU operation, very little change will be seen.
Hardware monitor alerts, events and statistics which originate within the
(subarea) domain of this VTAM will be gathered the same way (SSCP-PU
sessions), and displayed in the same way, as before. Hardware monitor data
which originates elsewhere will be displayed the same way, but transported:
• By MDS, if from an APPN-connected node
• By SSCP-PU sessions, if from a DLUR resource
• By SSCP-PU sessions, if from an adjacent type 2 / type 2.1 mixed node
• By MDS, as previously in the subarea network, if from another NetView
which gathered the data in the first place.
The NetView Session Monitor will be aware (as before) of sessions passing
through this VTAM or its owned NCPs (its subarea domain), since VTAM will still
have been involved in the session setup. If the session is wholly or partly APPN
then the Session Monitor will have additional APPN route information at its
disposal:
• The Session Configuration panel shows APPN COS and transmission priority.
• A subsequent new panel shows the APPN route in terms of CP names and
TG numbers.

• Another panel accessible from the Session Configuration panel displays
APPN flow control data on the adjacent boundary link.
Note, however, that this does not apply to HPR sessions using VTAM as an ANR
node. The HPR design ensures that ANR nodes are not aware of sessions or
RTP pipes passing through them.
Response Time Monitor (RTM) data is still available in an APPN network, since
the SSCP-PU sessions required for it are still available, albeit perhaps
encapsulated in a DLUR/S connection.
12.2.3 Remote Operation

NetView′s ability to send commands for execution at a remote node (via
RUNCMD) is not affected by APPN. It has the choice of SSCP-PU or MDS
transport, depending on the remote node′s attachment and its support for APPN.
The NetView MultiSystem Manager, which enables remote operation of a variety

of products and networks, uses NetView′s RUNCMD interface for communication
with its agents. Thus it, too, remains unaffected by APPN migration.
The 3174 Central Site Control Facility (CSCF) depends on SSCP-PU sessions;
therefore if a CSCF-controlled 3174 is separated from its owning subarea VTAM
it must utilize DLUR/S for CSCF operation. CSCF is the function that allows a
NetView operator to manage a 3174 as if from the operator panel on a directly
attached terminal.
12.2.4 Performance Monitoring

The NetView Performance Monitor (NPM) obtains its information by four distinct
methods:
1. Directly from VTAM (session data)
2. Directly from NetView (RTM data)
3. Using RUNCMD (token-ring statistics, Novell NetWare statistics)
4. Via LU-LU sessions (NCP data from an LU within the NCP)
None of these requires SSCP-PU sessions; therefore they all work the same way
in APPN as in subarea networking. In addition, NPM can collect performance
data from an LU within a 3746-9X0 NNP. This LU is dependent, so it utilizes the
DLUR support in the 3746 to establish the required session.
12.2.5 Change Management

NetView Distribution Manager uses LU 6.2 or LU 0 sessions to exchange code,
fixes, data and commands with remote nodes. All these sessions work the same
way in APPN as in the subarea network.
12.3 New Functions Available in APPN

The major new product which extends VTAM′s ability to manage a network deep
into APPN is NetView′s topology and accounting manager. This, an
enhancement to the NetView Graphic Monitor, was first made available in
NetView Version 3 and is now part of TME10 NetView. It has the following
features:
Chapter 12. Management of a Combined Network 193

• The topology manager gathers both subarea and APPN topology data and
presents it graphically on a workstation. Via the GUI the operator can
display various views of the network, and control network resources whether
by simple activation or deactivation or by running more complex command
lists.
The topology manager can use either or both of two agents:
− The VTAM SNA topology agent, introduced in VTAM V4R3, which
provides subarea and APPN topology information to NetView
− The OS/2 SNA topology agent, which runs under Communications
Manager/2 or Communications Server/2, but can provide only APPN
topology data
The information provided is exactly that available to VTAM in each type of
network; thus the APPN topology from a single NN agent will comprise all
network nodes and a subset of end nodes. Multiple agents are required for
a complete end-to-end view of the APPN topology.
• The accounting manager gathers LU 6.2 session and conversation data from
an agent that runs on Communications Manager/2 or Communications
Server/2. Conversation data and HPR session data are available only at the
endpoints of a session, but an intermediate node can provide session data
for base APPN (ISR) sessions passing through it.
The topology and accounting manager uses OSI Common Management

Information Protocol (CMIP) formats that utilize the MDS protocol over LU 6.2
sessions to transport its data.
One other product that provides new function in APPN is the NetView Remote
Operations Manager. This enables the NetView operator to issue commands to
agent programs running on remote AS/400 machines. Remote Operations
Manager uses MDS Operations Management protocols over LU 6.2 sessions to
transport the data.

Appendix A. VTAM Node Types
Table 5. VTAM/APPN Node Types and Functions

Node Type VTAM Start APPN Subarea NCP Ownership CDRM, PATH,
Options Functions Functions ADJSSCP needed
Subarea HOSTSA= none yes yes yes
Network Node (NN) NODETYPE=NN network none no (see note) no

node
Interchange Node HOSTSA= network yes yes, NCP/VTAM yes, for subarea
(ICN) NODETYPE=NN node become a CNN connections
Migration Data HOSTSA= end node data host no (see note) yes, for subarea
Host (MDH) NODETYPE=EN only connections
End Node (EN) NODETYPE=EN end node no no (see note) no
Note: A VTAM APPN-only node cannot activate or own resources in an NCP. It can establish a type 2.1 connection with the
NCP, allowing it to connect to APPN nodes via the NCP. NCP must be at Version 6 Release 2 or later to support APPN links.

Appendix B. VTAM APPN and APPN-Related Start Options
Table 6 (Page 1 of 5). VTAM APPN and APPN-Related Start Options

Start Parameter Usage Dynamic Values
ALSREQ YES is used to force a LEN connection for a N NO,

CDRSC even if an APPN connection is also YES
available. The start option provides the default
for CDRSCs without ALSREQ coded. NO is
normally recommended.
APPNCOS APPN class of service definitions to be used if a Y NONE,

requested COS cannot be found in the APPN User-defined
COS database.
AUTORTRY Controls automatic retry of pending logon Y AUTOCAP,

requests, depending on adjacent node activation. CDRM,
ALL,
NONE
AUTOTI How often automatic logon requests owned by Y 0,

this host are retried. May be needed for a time-period
controlling PLU on an EN.
BN Extended border node support. N NO,

YES
BNDYN Determines what nodes are dynamically added Y LIMITED,

to the adjacent cluster routing list. Only NONE,
meaningful if BN=YES. FULL
BNORD Defines the order in which cross-subnet Y PRIORITY,

searches are performed. Only meaningful if DEFINED
BN=YES.
CACHETI Number of minutes that procedure-correlation N 8,

identifiers (PCIDs) are cached after VTAM number of minutes
processes a network search request. Cached (0-1440)
PCIDs prevent duplicate processing.
CDRDYN Dynamic CDRSC support. CDRDYN should be Y YES,

coded YES to enable CP-CP sessions. Without NO
this support a CDRSC for each CP-CP session
partner would need to be coded. CDRDYN
overrides CDRDYN operand of host CDRM only.
CDRSCTI Specifies how long a dynamic CDRSC remains N 8M ,

after its session has ended. See the Network time
Implementation Guide for advice on how to code
this.
CDSERVR Specifies if this node acts as a central directory N NO,

server. Only meaningful if NODETYPE=NN. YES
CDSREFER Determines how many of the nearest central Y 1,

directory servers are used for searching and number of CDSs
resource registration. A low number (1 or 2) is
usually appropriate. Only meaningful if
NODETYPE=NN and CDSERVR=NO.
CONNTYPE Determines if type 2.1 connections are attempted Y APPN,

as APPN or LEN connections. Default of APPN is LEN
probably not a good idea in the early stages of
migration.
CPCDRSC Specifies whether a CDRSC is created N NO,

automatically for a dynamic adjacent LEN CP. If YES
coded NO, either a CDRSC definition is required
or the LEN CP must initiate the session.

CPCP CP-CP session support. Note the default which Y LEASED,

does not allow CP-CP sessions with adjacent SWITCHED,
switched (for example, token-ring) nodes. Can YES,
be overridden on the link station definition. NO
DIRSIZE Maximum number of dynamic APPN resources Y 0,

stored in the VTAM directory services database. number of resources
Default 0 means no limit. Beware if you have a
large network. Only meaningful if
NODETYPE=NN.
DIRTIME Amount of time an APPN resource remains in the Y 8D,

directory services database if unused. CDRSCTI time period
is the subarea equivalent. Only meaningful if
NODETYPE=NN.
DUPDEFS Specifies if VTAM should continue an APPN Y ALL,

search after an inactive resource is found, in NONE,
case there are duplicate definitions in the APPL,
network. LU
DYNADJCP Determines if adjacent CP minor nodes are N YES,

created dynamically (placed in ISTADJCP). If NO
specified as NO, an ADJCP definition must be
created for each CP-CP session partner.
DYNADJCP can be overridden at the link level.
DYNDLGMD Specifies the default mode name to be used for a Y NONE,

dynamic CDRSC when the resource is acting as mode name
the SLU and no other mode name is provided.
This situation is likely to occur in a mixed
environment; see Chapter 10, “Logmode and
COS Resolution in a Mixed Network” on
page 167.
DYNHPPFX Specifies the two-character prefix for N *BLANKS*,

dynamically defined HPR connections. A unique prefix
value is then appended to create a unique
connection name.
DYNLU Dynamically defines CDRSCs for remote N NO,

resources sending session requests over a YES
connection. YES is usually appropriate for APPN
connections. Can be overridden on the link
station definition.
DYNMODTB Defines the default mode table to be used for a Y NO,

dynamically defined CDRSC that is acting as YES
SLU, and no other mode table name is provided.
See Chapter 10, “Logmode and COS Resolution
in a Mixed Network” on page 167 for examples
of when this might occur.
DYNPUPFX Specifies the two-character prefix for N *BLANKS*,

dynamically defined connections other than HPR prefix
or connection network PUs. A unique value is
appended to create a unique connection name.
DYNVNPFX Specifies the two-character prefix for N *BLANKS*,

dynamically defined connection network PUs. A prefix
unique value is appended to create a unique
connection name.
HOSTSA Provides subarea functionality. With N 1,

NODETYPE=NN, creates ICN. With subarea number
NODETYPE=EN, creates MDH.

HPR Determines level of HPR support on VTAM and N RTP,

by default on each link. Only meaningful if (RTP,ANR),
NODETYPE is used. If NODETYPE=EN, ANR is (RTP,NONE),
not valid. ANR,
(ANR,NONE),
NONE
HPRNCPBF Specifies whether VTAM is to look for an HPR Y NO,

connection even if it means that the session will YES
traverse an NCP twice. Only meaningful on an
interchange node.
HPRPST Maximum time VTAM waits for a path switch to Y (8M,4M,2M,1M),

complete before ending an RTP connection. (low-limit,
Different time limits for transmission priority med-limit,
connections. Network priority should be much high-limit,
lower than the others if Control Flows is being network-limit)
used. Only meaningful if HPR=RTP.
INITDB Determines loading of directory and topology N ALL,

databases when VTAM is started. Only DIR,
meaningful if NODETYPE coded. TOPO,
NONE
IOPURGE Interval after which outstanding I/O requests are Y 0,

purged. This includes APPN search requests timeout value
and HPR route setup requests.
ISTCOSDF Specifies which types of resource use the default Y INDLU,

mode ISTCOSDF if the supplied mode is not ALL,
found. ISTCOSDF is an LU 6.2 mode so the APPL,
default value of INDLU (independent LUs only) is DEPLU,
reasonable. NONE
MAXLOCAT Specifies the congestion threshold after which N 5000,

VTAM will suspend search requests to an threshold
adjacent CP.
NODETYPE Determines APPN function capability. N No default,

NN,
EN
NUMTREES Limits number of routing trees in the topology Y 100,

and routing services tree cache. number of trees
PSRETRY Determines how often VTAM will attempt a path Y (0,0,0,0),

switch for RTP connections. PSRETRY is used to (low,medium,high,network)
ensure that optimum HPR routes are maintained
when the network topology is changing due to
resource failures and restorations. Only
meaningful if HPR=RTP. You may code a
different value for each tranmission priority.
RESUSAGE Determines how many times a node or TG is Y 100,

used during route selection before routing trees usage limit
are reconstructed to use alternate routes. A low
RESUSAGE allows load balancing between
equal-weight routes; a high one saves
processing power. Only meaningful if
NODETYPE=NN.
ROUTERES Route addition resistance value. Used to give Y 128,

this node a relative advantage or disadvantage resistance value
over other nodes as an intermediate router.
Referred to in the COS tables for route
calculation purposes.
SECLVLCP Session-level security specification for LU 6.2 N ADAPT,

involving a CP. Only valid if NODETYPE and LEVEL1,
VERIFYCP are coded. LEVEL2
Appendix B. VTAM APPN and APPN-Related Start Options 199

SNVC Maximum number of networks this border node Y 3,

will search for a resource. S N V C = 1 m e a n s n o subnet visit count
border will be crossed. Only meaningful if
BN=YES.
SORDER Controls the order in which networks (that is, Y APPN,

APPN, subarea, or a combination defined by APPNFRST,
ADJSSCP tables) are searched when a network ADJSSCP,
request is received from the subarea network. SUBAREA
See Chapter 9, “Searching and Routing in a
Mixed Subarea/APPN Network” on page 151 for
a description of how it works.
SRCHRED Specifies search reduction for resources found Y OFF,

unreachable. Used in conjunction with ON
SRCOUNT and SRTIMER. Affects both subarea
and APPN. Refer to ″Improving VTAM
performance Using Start Options″ in VTAM
Network Implementation Guide , SC31-8563.
SRCOUNT Specifies number of search requests to suppress Y 10,

before searching for the resource again. Only number of search requests
meaningful if SRCHRED=ON.
SRTIMER Specifies amount of time for which searches will Y 30,

be suppressed for a resource already found to number of seconds
be unreachable. Only meaningful if
SRCHRED=ON.
SSCPNAME Names the APPN control point as well as the N No default,

SSCP. CP name
SSCPORD The old subarea option, but it affects the way the N PRIORITY,
APPN/subarea search patterns work. See DEFINED
Chapter 9, “Searching and Routing in a Mixed
Subarea/APPN Network” on page 151.
SSEARCH Determines whether the subarea network is Y YES,

searched when a request is received from the APPNFRST,
APPN network. See Chapter 9, “Searching and NO,
Routing in a Mixed Subarea/APPN Network” on CACHE
page 151 for a description.
TRACE, A new VTAM internal trace option for APPN. Y RTP

TYPE=VTAM, High performance routing related additional trace
MODE= option. Allows problem analysis on many levels
INT|EXT, including the sent and received network layer
OPTION=() packets (NLPs). See VTAM Diagnosis ,
LY43-0079. for more detail. Users must be
licensed for VTAM to obtain this manual.
VERIFYCP Determines whether LU-LU session-level N NONE,

verification is performed during activation of LU OPTIONAL,
6.2 sessions involving CPs. You must coordinate REQUIRED
the activation of this parameter with the
customization of the security product (for
example, RACF) or VTAM will get an OPEN ACB
error for the CP at activation time and will start.
SECLVLCP is a related option.
VFYRED Specifies whether resource verification reduction Y YES,

is allowed for LU 6.2 applications using the NO
APPCCMD API. This means that a search
request will not be delivered to the owning CP,
but its network node server will return a positive
response on the assumption that the application
is active.
VFYREDTI Maximum time a resource′s location is not Y OFF,

verified during session setup. 0,
reduction timer

VRTG Determines whether to request a VR-TG Y NO,

connection when an SSCP-SSCP session is YES
established. Can be overridden on the CDRM
definitions. Meaningful only on an ICN or an
MDH.
VRTGCPCP Determines whether CP-CP sessions will be Y YES,

attempted over a VR-TG connection when CP-CP NO
sessions are valid. Can be overridden on the
CDRM definitions.
XNETALS Used to control the attachment of adjacent nodes N YES (APPN), NO (others),
with different NetIDs to VTAM. The default for YES/NO
APPN connections is YES, which is required for
an APPN border. Can be overridden on the PU
definition.
Note: All defaults are highlighted. Dynamic means modifiable by F proc,VTAMOPTS except in the case of the TRACE
option for which F proc,TRACE is used.
Appendix B. VTAM APPN and APPN-Related Start Options 201

Appendix C. VTAM APPN Commands
Please see VTAM Operation , SC31-8567, for a complete list of options and
syntax.
C.1 APPN Operands for VTAM Modify Commands
Table 7. VTAM Modify Command APPN Operands

Modify Command Optional Parameters
CHKPT TYPE=ALL
DIR
TOPO
DIRECTRY,ID=cdrsc|resource name, CPNAME=new cpname
FUNCTION=UPDATE (new cpname,
old cpname)
NETSRVR=
DIRECTRY,ID=cdrsc|resource name,
FUNCTION=DELETE
TRACE,ID=node,TYPE=GPT IDTYPE=RESOURCE
IO SSCP
BUF CP
TRACE,ID=node,TYPE=STATE IDTYPE=RESOURCE
SSCP
CP
OPTION=ADJCP
TRACE,TYPE=STATE, IDTYPE=RESOURCE
SSCP
CP
OPTION=ADJCP
RESOURCE,ID=resource name SRCOUNT=number searches
SRTIMER=number seconds
SRCLEAR=YES
REGISTER=CDSERVR
NETSRVR
NO
RTP,ID=rtp_PU_name
TGP,TGPNAME=,ID=cpname,TGN=
TGP,TGPNAME=,ID=adj link station
TOPO,ID=cp_name, FUNCTION=DELETE
NORMAL
QUIESCE
SCOPE=LOCAL
NETWORK
TYPE=FORCE
TOPO,ORIG=cp_name,DEST=cp_name,TGN=tg_number, FUNCTION=DELETE
NORMAL
QUIESCE
SCOPE=LOCAL
NETWORK
TYPE=FORCE
VTAMOPTS Most of the APPN start options (Table 6 on page 197).

C.2 APPN Operands for VTAM Vary Commands
Table 8. VTAM VARY Command APPN Operands V NET,

Vary Command Optional Parameters
ACT,ID=pu 2.1 CPCP=YES
ncp nonswitched line name NO
HPR=YES
NO
ACT,ID=cdrsc IDTYPE=CP
appl RESOURCE
ACT,ID=cdrmname IDTYPE=SSCP
RESOURCE
VRTGCPCP=YES
NO
HPR=YES
NO
INACT,ID=cdrsc DELETE=YES
NO
IDTYPE=CP
TYPE=FORCE
IMMED
UNCOND
INACT,ID=dlur TYPE=FORCE
IMMED
UNCOND
INACT,ID=dlurpu TYPE=FORCE
IMMED
UNCOND
GIVEBACK
REACT

C.3 APPN Operands for VTAM Display Commands
Table 9 (Page 1 of 2). VTAM Display Command APPN Operands D NET,

Display Command Optional Parameters
ADJCLUST NETID=destination
network
SCOPE=ALL | ONLY
ADJCP,ID=adjacent CP SCOPE=ALL | ONLY
APING,ID=resource name CONSEC=1|number
ECHO=YES|NO
ITER=2|number
APINGDTP
APPNTOSA
BNCOSMAP NETID=destination network
SCOPE=ALL | ONLY
DIRECTRY,ID=resource SCOPE=ALL | ONLY |
NSEARCH (note 1)
DIRECTRY,ID=*.resource MAX=number to display
DLURS
ID=resource IDTYPE=CP (note 3)
DIRECTRY
RESOURCE
NETID=cdrsc network
SCOPE= (note 4)
ID=*.resource IDTYPE=RESOURCE
DIRECTRY
SCOPE= (note 4)
MAX=number to display
ID=ISTADJCP SCOPE=ALL
ID=ISTRTPMN (RTP connection major node) SCOPE=ALL
ID=CNRnnnnn (RTP connection, default prefix) SCOPE=ALL
ID=CNVnnnnn (CN link station, default prefix) SCOPE=ALL
NETSRVR SCOPE=ALL | ONLY
RSCLIST,ID=resource IDTYPE=ADJCPS
ADJCPSEG
TRLSEG (note 3)
EXCLUDE=name or pattern
SCOPE= (note 4)
SAMAP
SATOAPPN
SRCHINFO LIST=SUMMARY
TYPE=ALL
APPN
SUBAREA
FROMCP=cp_name
TOCP=cp_name
TGPS ID=tgprofile name
TOPO ID=cpname
LIST=ADJ | ALL | BN | NN |
CDSERVR | EN | ICN
VN | SUMMARY
APPNCOS=cos name
ORIG=cpname
DEST=cpname
TGN=tg number
Appendix C. VTAM APPN Commands 205

Table 9 (Page 2 of 2). VTAM Display Command APPN Operands D NET,
Display Command Optional Parameters
TRL CONTROL=ALL
MPC
XCF
TCP
TRLE=name of TRLE
XCFCP=adjacent CP name
VTAMOPTS FORMAT=CURRENT
COMPLETE
MODIFIED
OPTION=vtam option
FUNCTION=APPNCHAR
Notes:
1. NSEARCH will cause a network search to be performed for the resource.
2. ″E″ is the abbreviation for SCOPE=ALL, N for SCOPE=ONLY. Many
commands default to SCOPE=ONLY. Specifying ″E″ will give much more
information.
3. IDTYPE covers many more areas, APPN types are the only ones listed here.
Depending on the VTAM DSPLYWLD start option, wildcard values can be
used for the resource name. An asterisk can be specified for the NETID
portion of the ID.
4. SCOPE can be used to limit the display. The options are as follows:
SCOPE=ALL|ACT|ACTONLY|CONCT|INACT|INACTONLY|ONLY|PENDING|RESET

Appendix D. VTAM Subarea Initial Definitions
We have two VTAM hosts in this initial configuration: RAA (subarea 10) and RAS
(subarea 28). Both are connected using a CTC and later an MPC in preparation
for the APPN migration.
There are two NCPs, RA5NCPX (subarea 5) and RA8NCPX (subarea 8).
RA5NCPX is channel-attached to RAA and link-attached to RA8NCPX. RA8NCPX
is channel-attached to RAS and link-attached to RA5NCPX. Both NCPs are
loaded and owned from RAA. This makes up the CMC.
Both NCPs are attached to a token-ring and have connectivity to each other
through the ring.
The peripheral devices are as follows:

3174-11L cluster controller channel-attached to RAA
3174-11R remote cluster controller SDLC-attached to RA5NCPX
3174-63R cluster controller token-ring-attached to RA5NCPX and defined in
switched major node RAASWMN1
PS/2 Model 77 with Communications Manager/2 V1.11 SDLC-attached
gateway with token-ring devices downstream
PS/2 Model 77 with Communications Manager/2 V1.11 workstation
token-ring-attached to the SDLC-attached PC which it uses as a host gateway
Three PS/2 Model 77s attached to RA5NCPX via the token-ring, and defined
in the switched major nodes RAASWMN2, RAASWMN3 and RAASWMN4

D.1 VTAM RAA Definitions
D.1.1 VTAM Start Options
ATCSTR10
*******************************************************************
* *
* ATCSTR10 FOR RAA *
* THIS IS SUBAREA 10 STAGE 1 ; SUBAREA *
* *
*******************************************************************
CONFIG=10,
CSALIMIT=0,
DYNLU=NO,
HOSTPU=ISTPUSA0,
HOSTSA=10,
IOBUF=(100,384,5,,1,30),
NETID=USIBMRA,
SSCPID=99,
SSCPNAME=RAA,
SUPP=NOSUP,
TNSTAT,CNSL,
XNETALS=YES
D.1.2 VTAM Configuration List
ATCCON10
RAAATSO, TSO APPL
RAAANETV, NETVIEW V2.4 APPL
RAAPATH, SA10 PATH TABLE
RAACDRM, CDRM
RAACDRSC, CDRSCS
RAAADJ, ADJSSCP TABLE
RAAMPC1, CTC TO SA 28 (FID4 MPC)
RAALCL1, LOCAL SNA 3174-11L
RAASWMN1, SW-TR MN FOR 3174-63R
RAASWMN2, SW-TR MN FOR CM/2 (KEN)
RAASWMN3, SW-TR MN FOR CM/2 (ANAR)
RAASWMN4, SW-TR MN FOR CM/2 (RABINDER)
RAASWMN5, SW-TR MN FOR AS/400
RA5NCPX, NCP SA 5
RA8NCPX REMOTE NCP SA8

D.1.3 Path Tables for RAA
RAAPATH
PATH DESTSA=5,
ER0=(5,1),ER3=(5,1),
VR0=0,
VRPWS00=(10,30),VRPWS01=(10,30),VRPWS02=(10,30)
PATH DESTSA=8,
ER0=(8,1),ER1=(28,1),ER2=(5,1),
ER3=(5,1),
VR0=0,
VRPWS00=(10,30),VRPWS01=(10,30),VRPWS02=(10,30),
VR1=3,
VR2=2,
VR3=1,
PATH DESTSA=20,
ER0=(20,1),ER2=(20,1),
VR0=0,
PATH DESTSA=28,
ER0=(20,1),ER1=(5,1),ER2=(5,1),
ER3=(28,1),ER4=(28,1),
VR0=0,
VR1=1,
VR2=2,
VR3=4,
Appendix D. VTAM Subarea Initial Definitions 209

D.1.4 Adjacent SSCP Table, CDRM and CDRSC Major Nodes
RAAADJ
*******************************************************************
* *
* ADJSSCP TABLE FOR RAA *
* *
* *
*******************************************************************
VBUILD TYPE=ADJSSCP
RAS ADJCDRM
RAACDRM
*******************************************************************
* *
* CDRM MAJORNODE FOR RAA *
* *
*******************************************************************
VBUILD TYPE=CDRM
RAS CDRM SUBAREA=28,CDRDYN=YES,CDRSC=OPT
RAACDRSC
VBUILD TYPE=CDRSC
RASAN CDRSC CDRM=RAS
RASANLUC CDRSC CDRM=RAS
RASAT CDRSC CDRM=RAS

D.1.5 Locally Attached 3174 Definitions
RAALCL1
*******************************************************************
* *
* LCL MAJORNODE FOR RAA FOR SNA LOCAL ATTACHED 3174-11L. *
* *
*******************************************************************
VBUILD TYPE=LOCAL
RAALCLP PU CUADDR=E40,PUTYPE=2,MAXBFRU=10, *
MODETAB=AMODETAB,DLOGMOD=M2SDLCQ,USSTAB=US327X, *
CONNTYPE=LEN,XID=YES, *
VPACING=0
RAALCL02 LU LOCADDR=2
* *
*******************************************************************
D.1.6 CTC and MPC Definitions from RAA to RAS
RAAMPC1
*******************************************************************
* *
* MPC MAJORNODE FOR RAA(10) TO RAS(28) - FOR FID4 MPC CONNECTION *
* *
*******************************************************************
RAACRAS VBUILD TYPE=CA
RAAGMP1 GROUP LNCTL=MPC,ISTATUS=ACTIVE,MAXBFRU=3
RAALMP1 LINE READ=(C12),WRITE=(C14)
RAAPMP1 PU PUTYPE=4,TGN=1

D.1.7 Switched Major Node Definitions
These definitions are for token-ring-attached devices using RA5NCPX′s TIC2
MAC address 400001050001. The PATH statements, although coded, were never
used as these devices all initiated their connections to VTAM.
The following definitions are for the token-ring-attached 3174-63R with MAC
address 400031740004 and IDBLK=017 and IDNUM=31744.
RAASWMN1
*******************************************************************
* *
* SWMN MAJORNODE FOR RAA FOR TOKEN-RING ATTACHED 3174-63R. *
* *
*******************************************************************
VBUILD TYPE=SWNET,
MAXNO=1,
MAXGRP=1
RAATRPU1 PU ADDR=C1,
IDBLK=017,
IDNUM=31744,
MAXOUT=7,
MAXPATH=1,
PASSLIM=7,
MODETAB=ISTINCLM,
PUTYPE=2
GRPNM=EG05L01

The following definition is for one of the three PS/2 Model 77 PCs running OS/2
Warp V3.0 and CM/2 V1.11. The other two are identical except for the IDNUM
and the resource names.
RAASWMN2
*******************************************************************
* *
* SWMN MAJORNODE FOR RAA FOR T-RING ATTACHED PS/2 77 CM/2 (KEN) *
* *
*******************************************************************
VBUILD TYPE=SWNET,
MAXNO=1,
MAXGRP=1
IDBLK=05D,
IDNUM=05150,
MAXOUT=7,
MAXPATH=1,
MODETAB=ISTINCLM,
PASSLIM=7,
PUTYPE=2
GRPNM=EG05L01
The following definition is for an AS/400. Note that the CPNAME parameter is
used instead of IDBLK and IDNUM. This is a better way of defining type 2.1
nodes to VTAM. IDBLK/IDNUM, however, should be used for DLUR resources
since they should not be confused with their DLUR′s CP. Note also the old way
of coding an independent LU (LOCADDR=0). This will be converted to a CDRSC
by VTAM so you might as well have the extra flexibility and code it as a CDRSC
yourself.

RAASWMN5
*******************************************************************
* *
* SWMN MAJORNODE FOR T-RING ATTACHED AS/400 *
* *
*******************************************************************
VBUILD TYPE=SWNET,
MAXNO=1,
MAXGRP=1
CPNAME=RAYAS4A,
MAXOUT=7,
MAXPATH=1,
MODETAB=MTGS3X,
DLOGMOD=QPCSUPP,
PASSLIM=7,
PUTYPE=2
GRPNM=EG05L01
RAATIU50 LU LOCADDR=0,RESSCB=4

D.1.8 NCP RA5NCPX Definitions
OPTIONS NEWDEFN=(YES,ECHO,NOSUPP),USERGEN=(FNMNDFGN)
*******************************************************************
* RA5NCP 3745-41A CCU A CA1=E28 CA2=E1F CA3=E20 *
* *
* NCP MAJORNODE FOR SA 5 *
* *
* *
*******************************************************************
* LICTYPE LINES: LICTYPE LINES: *
* 1 00 3174-63R 1 04 *
* 01 INN(19.2) 05 *
* 02 06 *
* 03 07 *
* *
* NTRI INTERFACES: *
* ================ *
* TICTYPE TR *
* 2 1088 MAC=4000 0105 0000 4MBPS *
* 2 1089 INN (TO SA 8) MAC=4000 0105 0001 4MBPS *
* *
*******************************************************************
*
PRINT NOGEN
* STATOPT=′ SA05 3745′
PCCUPE1F PCCU CUADDR=E28, SA11 WTCOS MVS/SP. VM ADDR E1F *
AUTODMP=YES, ONLY ONE AUTODMP-HOST IF TWINTAIL *
AUTOIPL=NO, ONLY ONE AUTOIPL-HOST IF TWINTAIL *
AUTOSYN=YES, USE THE ALREADY LOADED NCP IF OK *
BACKUP=YES, RESOURCE TAKEOVER PERMITTED *
CHANCON=COND, CONDITIONAL CONTACT REQ. TO NCP SENT*
DUMPDS=NCPDUMP, DUMP DATASET *
MDUMPDS=NCPDMOSS, MOSS DUMP DATASET *
CDUMPDS=NCPDCSP, SCANNER DUMP DATASET *
MAXDATA=5000, *
OWNER=RAA, *
SAVEMOD=YES, *
VFYLM=YES, VERIFY LMOD WHEN LOADING *
SUBAREA=10 HOSTSA VTAM VER 3 MVS/SP
PCCUPE20 PCCU CUADDR=E20, SA11 WTCOS MVS/SP. VM ADDR E1F *
MAXDATA=5000, *
OWNER=RAS, *
SAVEMOD=YES, *
VFYLM=YES, VERIFY LMOD WHEN LOADING *

***********************************************************************
* BUILD MACRO SPECIFICATIONS *
***********************************************************************
NCPBUILD BUILD BFRS=(240), NCP BUFFER SIZE #V52 *
AUXADDR=50, BRANCH TRACE ENTRIES *
BRANCH=500, BRANCH TRACE ENTRIES *
CATRACE=(YES,100), CHANNEL ADAPTER TRACE *
CSMHDR=27F5C711C3F0405C40C8C4D9405C, 8875 CRITSIT HEADER*
CSMHDRC=40E3C5E7E3405C5C, 3270 CRITST HEADER EXTRA TEXT *
CSMSG=C3D9C9E3E2C9E35A40E385819440F040, CRITSIT MESG *
CSMSGC=6040C1D5E240828587A4954B, CRITST MESG EXTRA TEXT *
CWALL=26, MIN. BUFFERS BEFORE SLOWDOWN *
DSABLTO=6.5, *
ENABLTO=6.5, IBM 386X REQUIRE 6.5 AS MINIMUM *
LTRACE=4, SIT FOR 4 LINES *
MAXSSCP=8, 8 SSCP′ S CAN ACTIVATE THIS NCP *
MEMSIZE=4M, 4M MEMORY #V52 *
MODEL=3745, 3745 COMMUNICATION CONTROLLER #### *
NETID=USIBMRA, REQUIRED #### *
LOADLIB=NCPLOAD, NCP LOAD LIBRARY *
COSTAB=ISTSDCOS, COS TAB *
NEWNAME=RA5NCPX, NAME OF THIS LOAD MODULE *
PUNAME=RA5NCPX, NAME OF THIS PU #### *
NPA=YES, NPA*
NUMHSAS=6, 6 HOSTS MAY COMMUNICATE CONCURRENTLY*
SUBAREA=05, SUBAREA ADDRESS = 05 *
TRACE=(YES,64), 64 ADDRESS-TRACE ENTRIES *
LOCALTO=1.5, NTRI. ACK TIMER FOR LOCAL T-R *
REMOTTO=1.5, NTRI. ACK TIMER FOR REMOTE T-R *
TYPGEN=NCP, NCP ONLY *
TYPSYS=MVS, MVS OPERATING SYSTEM #### *
TRANSFR=34, MVS OPERATING SYSTEM #### *
USGTIER=4, NCP USAGE TIER #### *
VRPOOL=32, VR POOL *
VERSION=V7R3 VR POOL
*
***********************************************************************
* SYSCNTRL MACRO SPECIFICATIONS *
***********************************************************************
NCPSYSC SYSCNTRL OPTIONS=(BHSASSC,ENDCALL,MODE,RCNTRL,RCOND,RECMD,RIMM,*
NAKLIM,SESSION,SSPAUSE,XMTLMT,STORDSP,DLRID,RDEVQ)
***********************************************************************
***********************************************************************
* HOST MACRO SPECIFICATIONS - VTAM ONLY #### *
***********************************************************************
RAA HOST INBFRS=10, NCP BUFFERS ALLOCATION *
MAXBFRU=32, UP TO 34 VTAM BUFFERS SHIPPED *
UNITSZ=384, VTAM IO BUFFERS SIZE *
BFRPAD=0, BUFFER PAD *
SUBAREA=(10) CHANNEL ATTACHED HOSTSA
RAS HOST INBFRS=10, NCP BUFFERS ALLOCATION *
MAXBFRU=32, UP TO 34 VTAM BUFFERS SHIPPED *
UNITSZ=384, VTAM IO BUFFERS SIZE *
BFRPAD=0, BUFFER PAD *

***********************************************************************
* DYNAMIC RECONFIGURATION POOL SPACE *
***********************************************************************
*
DRPOOLPU PUDRPOOL NUMBER=8 CAN ADD 8 PUS
* *
DRPOOLLU LUDRPOOL NUMTYP1=10, RESERVE 10 LUS ON PU.T1 PUS *
NUMTYP2=90, RESERVE 90 LUS ON PU.T2 PUS *
NUMILU=200 RESERVE 90 LUS ON PU.T2 PUS
***********************************************************************
* ITSC.ITSCAPPN.PATH *
***********************************************************************
PATH DESTSA=1, *
ER0=(20,1), *
VR0=0, *
PATH DESTSA=3, *
ER0=(3,1),ER1=(3,1), *
VR0=0, *
PATH DESTSA=7, *
ER0=(7,1,5000,5000,5000,20000), *
VR0=0, *
PATH DESTSA=8, *
ER0=(8,8,5000,5000,5000,20000), *
ER1=(8,9,5000,5000,5000,20000), *
ER2=(8,9),ER3=(8,8), *
VR0=0, *
VRPWS00=(10,30),VRPWS01=(10,30),VRPWS02=(10,30), *
VR1=1, *
PATH DESTSA=9, *
ER0=(9,9,5000,5000,5000,20000)
PATH DESTSA=10, *
ER0=(10,1),ER1=(10,1),ER2=(10,1), *
VR0=0, *
PATH DESTSA=11, *
ER0=(11,1), *
VR0=0, *
PATH DESTSA=18, *
ER0=(18,1),ER1=(18,1),ER2=(8,9), *
ER3=(25,1), *
VR0=0, *
VR1=3, *
PATH DESTSA=20, *
ER0=(20,1),ER1=(3,1),ER2=(10,1), *
VR0=0, *
VR1=1, *
VR2=2, *

PATH DESTSA=24, *
ER0=(25,1),ER1=(10,1), *
VR0=0, *
VR1=1, *
PATH DESTSA=25, *
ER0=(25,1),ER1=(25,1), *
VR0=0, *
PATH DESTSA=28, *
ER0=(28,1),ER1=(8,8),ER2=(8,9), *
ER3=(10,1),ER4=(10,1), *
VR0=0, *
VR1=1, *
VR2=2, *
VR3=4, *
***********************************************************************
* SDLCST STATEMENTS FOR CONFIGURABLE LINK STATIONS *
* (STATEMENT MUST PRECEDE GROUP STATEMENTS) *
***********************************************************************
SDL05PRI SDLCST MODE=PRI, *
GROUP=G05XPRI, GROUP FOR PRIMARY LINKS *
RETRIES=(7,3,5), *
MAXOUT=7, *
PASSLIM=254
*
SDL05SEC SDLCST MODE=SEC, *
GROUP=G05XSEC, GROUP FOR SECONDARY LINKS *
RETRIES=(7), *
MAXOUT=7, *
PASSLIM=254
* *
S5PRIM SDLCST GROUP=PRI5GRP,MODE=PRI
S5SECD SDLCST GROUP=SEC5GRP,MODE=SEC

***********************************************************************
* VIRTUAL GROUP FOR NPA *
***********************************************************************
RA5GNPA GROUP LNCTL=SDLC,VIRTUAL=YES,NPARSC=YES NPA
RA5LNPA LINE ISTATUS=ACTIVE,OWNER=RAA
* STATOPT=(′ NPA LINE ′ )
RA5PNPA PU
* STATOPT=(′ NPA PU′ , NOACTY)
RA5TNPA LU MAXCOLL=89 NPA
*
***********************************************************************
* GROUP MACRO SPECIFICATIONS FOR SDLC LOCAL/LOCAL LINKS *
***********************************************************************
G05XSEC GROUP MODE=SEC,LNCTL=SDLC,ACTIVTO=120,REPLYTO=NONE
*
G05XPRI GROUP MODE=PRI,LNCTL=SDLC,REPLYTO=1
*
G05XLLL GROUP LNCTL=SDLC,REPLYTO=1
*
***********************************************************************
* INN LINK TO RA8
***********************************************************************
RA5GSDL GROUP ANS=CONTINUE, *
IPL=YES, *
LNCTL=SDLC, *
NPACOLL=YES, *
SDLCST=(SDL05PRI,SDL05SEC), *
NRZI=YES, *
PAUSE=0.5
RA5LRA8 LINE ADDRESS=(001,FULL), *
SPEED=19200, *
CLOCKNG=EXT, *
DUPLEX=FULL, *
MONLINK=CONTINUOUS, *
SERVLIM=4, *
IPL=YES, *
RETRIES=(,3,5), *
NEWSYNC=NO, *
LPDATS=NO, *
HISPEED=NO, *
ISTATUS=ACTIVE
RA5PRA8 PU TGN=8, *
PUTYPE=4, *
ANS=CONT, *
IRETRY=YES, *
MAXOUT=7, *
PASSLIM=254

***********************************************************************
* GROUP MACRO SPECIFICATIONS FOR SDLC LINK *
***********************************************************************
RA5GSFL0 GROUP LNCTL=SDLC, *
DUPLEX=FULL, *
NRZI=YES, *
REPLYTO=1, *
TYPE=NCP, *
RETRIES=(7,4,5) 7 RETRY PER SECOND FOR 5 TIMES
*
***********************************************************************
* 3174 IN CC111 *
***********************************************************************
L3174C1 LINE ADDRESS=(00,FULL), *
ANS=CONTINUE, DON′ T BREAK CROSS DOMAIN SESSIONS *
OWNER=RAA, DON′ T BREAK CROSS DOMAIN SESSIONS *
NRZI=YES, NRZI=YES *
CLOCKNG=EXT, *
ISTATUS=ACTIVE, *
DUPLEX=(FULL), REQUEST TO SEND ALWAYS UP *
ETRATIO=30, DEFAULT *
MAXPU=20, ALLOW NO MORE THAN 9 PUS ON LINE *
SERVLIM=10, *
SRT=(,64)
SERVICE ORDER=(P3174C1),MAXLIST=20
P3174C1 PU ADDR=C1, POLL ADDRESS = C1 *
DATMODE=HALF, HALF DUPLEX *
MAXDATA=265, MAXIMUM AMOUNT OF DATA *
MAXOUT=7, MAX SDLC FRAMES BEFORE RESPONSE *
PACING=0, PACING SET BY BIND IMAGE *
PASSLIM=8, *
PUDR=YES, *
PUTYPE=2, *
RETRIES=(,4,5), 7 RETRY PER SECOND FOR 5 TIMES *
DISCNT=(NO), (V) VTAM *
ISTATUS=ACTIVE, (V) VTAM *
SSCPFM=USSSCS, (V) VTAM *
USSTAB=US327X, (V) VTAM *
MODETAB=AMODETAB, *
DLOGMOD=M2SDLCQ, *
XID=YES, FOR T2.1 NODE (LEN) *
DYNLU=YES, *
VPACING=0 (V) VTAM
* STATOPT=(′3174′,NOACTY)
RA317411 LU LOCADDR=2
RA317C12 LU LOCADDR=3

***********************************************************************
* PHYSICAL GROUP FOR NTRI TIC #1-CCUA *
***********************************************************************
PRI5GRP GROUP LNCTL=SDLC, *
ACTIVTO=240, *
DIAL=NO, *
MODE=PRI, *
REPLYTO=3
*
SEC5GRP GROUP LNCTL=SDLC, *
ACTIVTO=240, *
DIAL=NO, *
MODE=SEC, *
REPLYTO=3
*
***********************************************************************
* PERIPHERAL PHYSICAL GROUP NTRI TIC #1 -CCUA TIC TYPE 2 4 MBPS *
***********************************************************************
EG05P00 GROUP ECLTYPE=(PHYSICAL,ANY), *
TRSPEED=4, *
SPEED=9600, *
MAXTSL=2044
*
EL051088 LINE ADDRESS=(1088,FULL), *
ADAPTER=TIC2, MAPS LOGICAL DEF. BELOW *
PORTADD=0, MAPS LOGICAL DEF. BELOW *
LOCADD=400001050000, TIC TOKEN RING ADDR. *
RCVBUFC=4095
* STATOPT=′ NTRI TIC#1′
*
EP051088 PU
*
EU051088 LU ISTATUS=INACTIVE
***********************************************************************
* PERIPHERAL PHYSICAL GROUP NTRI TIC #2 -CCUA TIC TYPE 2 4 MBPS *
***********************************************************************
EG05P01 GROUP ECLTYPE=(PHYSICAL,ANY),TRSPEED=4,MAXTSL=2044
*
EL051089 LINE ADDRESS=(1089,FULL), *
PORTADD=1, *
LOCADD=400001050001, *
ADAPTER=TIC2, *
RCVBUFC=4095, *
MAXTSL=2044
*
EP051089 PU
*
*

***********************************************************************
* SUBAREA LOGICAL GROUP NTRI INN LINK TIC #1 -CCUA *
***********************************************************************
*
GLOG51 GROUP ECLTYPE=(LOGICAL,SUBAREA), *
PHYPORT=1, MAPS PHYSICAL GROUP DEF. ABOVE *
SDLCST=(S5PRIM,S5SECD)
*
L051089A LINE TGN=9
*
P051089A PU ADDR=04400001080001, MAPS THE OTHER NCP (SA8) TR ADDR *
PUTYPE=4
*
GLOG52 GROUP ECLTYPE=(LOGICAL,SUBAREA), *
PHYPORT=0, MAPS PHYSICAL GROUP DEF. ABOVE *
*
*
L051088B LINE TGN=1
*
P051088B PU ADDR=04400001070000, MAPS THE OTHER NCP (SA8) TR ADDR *
PUTYPE=4
*
*
***********************************************************************
*PERIPHERAL LOGICAL GROUP NTRI TIC 1 - CCUA *
***********************************************************************
EG05L00A GROUP ECLTYPE=LOGICAL, *
OWNER=RAP, *
AUTOGEN=10, *
CALL=INOUT, *
PHYPORT=0
***********************************************************************
*PERIPHERAL LOGICAL GROUP NTRI TIC 2 - CCUA *
***********************************************************************
EG05L01 GROUP ECLTYPE=LOGICAL, *
AUTOGEN=10, *
OWNER=RAA, *
CALL=INOUT, *
PHYPORT=1

*
***********************************************************************
* CHANNEL ADAPTER LINKS #### *
***********************************************************************
RA5GCA GROUP LNCTL=CA, *
ISTATUS=INACTIVE STOP VTAM ACTIVATING CHANNEL LINK
RA5H5RAB LINE ADDRESS=0, 1ST CA. PHYSICAL POSTION 5 *
CA=TYPE6-TPS, 3745 CHANNEL ADAPTOR TYPE *
CASDL=120, INTERVAL BEFORE CHANNEL SLOWDOWN *
DELAY=0.2, CHAN ATTN DELAY *
DYNADMP=NONE, NO EP SUBHANNELS TO DUMP DATA OVER *
NCPCA=ACTIVE, NATIVE SUBCHANNEL(NSC) ACTIVE *
* STATOPT=(′ CA5 LINE ′ )
RA5PCA PU PUTYPE=5, INTERMEDIATE SUBAREA FUNCTION *
TGN=1 MUST BE ONE FOR PU TYPE 5
* STATOPT=(′ CA5 PU ′ )
RA5CE28 LINE ADDRESS=8, 2ST CA. PHYSICAL POSTION 8 *
CA=TYPE6, 3745 CHANNEL ADAPTOR TYPE *
RA5PCB PU PUTYPE=5, INTERMEDIATE SUBAREA FUNCTION *
RA5CE1F LINE ADDRESS=9, 3ND CA. PHYSICAL POSITION 2 *
CA=TYPE6, 3745 CHANNEL ADAPTOR TYPE *
RA5PCC PU PUTYPE=5, INTERMEDIATE SUBAREA FUNCTION *
***********************************************************************
GENEND
END

D.1.9 NCP RA8NCPX Definitions
OPTIONS NEWDEFN=(YES,ECHO,NOSUPP),USERGEN=(FNMNDFGN)
*******************************************************************
* RA8NCP 3745-41A CCU B CA1=E20 *
* *
* NCP MAJORNODE FOR SA 8 (LINK-ATTACHED THROUGH SA 5) *
* *
* *
*******************************************************************
* LICTYPE LINES: LICTYPE LINES: *
* 1 32 1 36 *
* 33 CM/2 GW 37 *
* 34 INN (19.2) 38 *
* 35 39 *
* *
* NTRI INTERFACES: *
* ================ *
* TICTYPE TR *
* 2 1092 MAC=4000 0108 0000 4MBPS *
* 2 1093 INN (TO SA 5) MAC=4000 0108 0001 4MBPS *
* *
*******************************************************************
*
PRINT NOGEN
PCCUA010 PCCU SUBAREA=10, *
MAXDATA=5000, *
SAVEMOD=YES, *
RNAME=RA5PRA8, *
LOADSTA=RA5PRA8, *
DUMPSTA=RRA5PRA8, *
OWNER=RAA, *
VFYLM=YES
PCCUBE20 PCCU CUADDR=E20, SA11 WTCOS MVS/SP. VM ADDR E1F X
AUTODMP=YES, ONLY ONE AUTODMP-HOST IF TWINTAIL X
AUTOIPL=NO, ONLY ONE AUTOIPL-HOST IF TWINTAIL X
AUTOSYN=YES, USE THE ALREADY LOADED NCP IF OK X
BACKUP=YES, RESOURCE TAKEOVER PERMITTED X
CHANCON=COND, CONDITIONAL CONTACT REQ. TO NCP SENTX
DUMPDS=NCPDUMP, DUMP DATASET X
MDUMPDS=NCPDMOSS, MOSS DUMP DATASET X
CDUMPDS=NCPDCSP, SCANNER DUMP DATASET X
MAXDATA=5000, X
OWNER=RAS, X
VFYLM=YES, VERIFY LMOD WHEN LOADING X

***********************************************************************
* BUILD MACRO SPECIFICATIONS *
***********************************************************************
NCPBUILD BUILD BFRS=(240), NCP BUFFER SIZE #V52 X
AUXADDR=50, BRANCH TRACE ENTRIES X
BRANCH=500, BRANCH TRACE ENTRIES X
CATRACE=(YES,100), CHANNEL ADAPTER TRACE X
CSMHDR=27F5C711C3F0405C40C8C4D9405C, 8875 CRITSIT HEADERX
CSMHDRC=40E3C5E7E3405C5C, 3270 CRITST HEADER EXTRA TEXT X
CSMSG=C3D9C9E3E2C9E35A40E385819440F040, CRITSIT MESG X
CSMSGC=6040C1D5E240828587A4954B, CRITST MESG EXTRA TEXT X
CWALL=26, MIN. BUFFERS BEFORE SLOWDOWN X
DSABLTO=6.5, X
ENABLTO=6.5, IBM 386X REQUIRE 6.5 AS MINIMUM X
LTRACE=4, SIT FOR 4 LINES X
MAXSSCP=8, 8 SSCP′ S CAN ACTIVATE THIS NCP X
MEMSIZE=4M, 4M MEMORY #V52 X
MODEL=3745, 3745 COMMUNICATION CONTROLLER #### X
NETID=USIBMRA, REQUIRED #### X
LOADLIB=NCPLOAD, NCP LOAD LIBRARY X
COSTAB=ISTSDCOS, COS TAB X
NEWNAME=RA8NCPX, NAME OF THIS LOAD MODULE X
PUNAME=RA8NCPX, NAME OF THIS PU #### X
NPA=YES, NPAX
NUMHSAS=6, 6 HOSTS MAY COMMUNICATE CONCURRENTLYX
SUBAREA=08, SUBAREA ADDRESS = 05 X
TRACE=(YES,64), 64 ADDRESS-TRACE ENTRIES X
LOCALTO=1.5, NTRI. ACK TIMER FOR LOCAL T-R X
REMOTTO=1.5, NTRI. ACK TIMER FOR REMOTE T-R X
TYPGEN=NCP, NCP ONLY X
TYPSYS=MVS, MVS OPERATING SYSTEM #### X
TRANSFR=34, MVS OPERATING SYSTEM #### X
USGTIER=4, NCP USAGE TIER #### X
VRPOOL=32, VR POOL X
VERSION=V7R3 VR POOL
***********************************************************************
* SYSCNTRL MACRO SPECIFICATIONS *
***********************************************************************
NCPSYSC SYSCNTRL OPTIONS=(BHSASSC,ENDCALL,MODE,RCNTRL,RCOND,RECMD,RIMM,X
NAKLIM,SESSION,SSPAUSE,XMTLMT,STORDSP,DLRID,RDEVQ)
***********************************************************************

***********************************************************************
* HOST MACRO SPECIFICATIONS - VTAM ONLY #### *
***********************************************************************
RAS HOST INBFRS=10, NCP BUFFERS ALLOCATION X
MAXBFRU=32, UP TO 34 VTAM BUFFERS SHIPPED X
UNITSZ=384, VTAM IO BUFFERS SIZE X
BFRPAD=0, BUFFER PAD X
***********************************************************************
RAA HOST INBFRS=10, NCP BUFFERS ALLOCATION X
MAXBFRU=32, UP TO 34 VTAM BUFFERS SHIPPED X
UNITSZ=384, VTAM IO BUFFERS SIZE X
BFRPAD=0, BUFFER PAD X
***********************************************************************
* DYNAMIC RECONFIGURATION POOL SPACE *
***********************************************************************
*
DRPOOLPU PUDRPOOL NUMBER=8 CAN ADD 8 PUS
* *
DRPOOLLU LUDRPOOL NUMTYP1=10, RESERVE 10 LUS ON PU.T1 PUS X
NUMTYP2=90, RESERVE 90 LUS ON PU.T2 PUS X
NUMILU=200 RESERVE 90 LUS ON PU.T2 PUS
***********************************************************************
* ITSC.ITSCAPPN.PATH *
***********************************************************************
PATH DESTSA=1, *
ER0=(20,1), *
VR0=0, *
PATH DESTSA=3, *
ER1=(5,9,5000,5000,5000,20000), *
ER0=(3,1), *
VR0=0, *
PATH DESTSA=5, *
ER0=(5,8,5000,5000,5000,20000), *
ER1=(5,9),ER2=(5,8), *
VR0=0, *
VR1=1, *
PATH DESTSA=10, *
ER0=(10,1),ER1=(5,8),ER2=(5,9), *
ER3=(28,1), *
VR0=0, *
VR1=1, *
VR2=2, *
VR3=3, *

PATH DESTSA=11, *
ER0=(11,1), *
VR0=0, *
PATH DESTSA=16, *
ER0=(20,1), *
VR0=0, *
PATH DESTSA=17, *
ER0=(20,1),ER1=(17,1), *
VR0=0, *
VR1=1, *
PATH DESTSA=18, *
ER0=(18,1),ER2=(18,1), *
VR0=0, *
PATH DESTSA=20, *
ER0=(20,1),ER1=(28,1),ER2=(5,8), *
VR0=0, *
VR1=1, *
VR2=2, *
PATH DESTSA=24, *
ER0=(20,1),ER1=(28,1), *
VR0=0, *
VR1=1, *
PATH DESTSA=25, *
ER0=(25,1),ER1=(5,9), *
VR0=0, *
PATH DESTSA=28, *
ER0=(28,1),ER1=(28,1),ER2=(28,1), *
ER3=(5,8),ER4=(5,9), *
VR0=0, *
VR1=3, *
VR2=4, *

***********************************************************************
* SDLCST STATEMENTS FOR CONFIGURABLE LINK STATIONS *
* (STATEMENT MUST PRECEDE GROUP STATEMENTS) *
***********************************************************************
SDL08PRI SDLCST MODE=PRI, *
GROUP=G08XPRI, GROUP FOR PRIMARY LINKS *
RETRIES=(7,3,5), *
MAXOUT=7, *
PASSLIM=254
*
SDL08SEC SDLCST MODE=SEC, *
GROUP=G08XSEC, GROUP FOR SECONDARY LINKS *
RETRIES=(7), *
MAXOUT=7, *
PASSLIM=254
* *
S8PRIM SDLCST GROUP=PRI8GRP,MODE=PRI
S8SECD SDLCST GROUP=SEC8GRP,MODE=SEC
***********************************************************************
* VIRTUAL GROUP FOR NPA *
***********************************************************************
RA8GNPA GROUP LNCTL=SDLC,VIRTUAL=YES,NPARSC=YES NPA
RA8LNPA LINE ISTATUS=ACTIVE
* STATOPT=(′ NPA LINE ′ )
RA8PNPA PU
* STATOPT=(′ NPA PU′ , NOACTY)
RA8TNPA LU MAXCOLL=89 NPA
*
***********************************************************************
* GROUP MACRO SPECIFICATIONS FOR SDLC LOCAL/LOCAL LINKS *
***********************************************************************
G08XSEC GROUP MODE=SEC,LNCTL=SDLC,ACTIVTO=120,REPLYTO=NONE
*
G08XPRI GROUP MODE=PRI,LNCTL=SDLC,REPLYTO=1
*
G08XLLL GROUP LNCTL=SDLC,REPLYTO=1
*
***********************************************************************
LCM2A LINE ADDRESS=(033,HALF), TRANSMIT AND RECEIVE ADDRESSES X
NPACOLL=YES, NPAX
ANS=CONTINUE, DON′ T BREAK CROSS DOMAIN SESSIONS X
ISTATUS=ACTIVE, X
DUPLEX=(FULL), REQUEST TO SEND ALWAYS UP X
NRZI=YES, NRZI=YES X
ETRATIO=30, DEFAULT X
LPDATS=LPDA1, X
MAXPU=9, ALLOW NO MORE THAN 9 PUS ON LINE X
SERVLIM=2, X
SRT=(,64), X
SPEED=(9600) LINE SPEED IS 4800 BPS

***********************************************************************
SERVICE ORDER=(RA8CM2A), X
MAXLIST=9
***********************************************************************
RA8CM2A PU ADDR=C1, 3270 ADDRESS=′ C′ ( EBCDIC) X
MAXDATA=1033, MAXIMUM AMOUNT OF DATA (CM/2) X
MAXOUT=7, MAX SDLC FRAMES BEFORE RESPONSE X
PACING=0, PACING SET BY BIND IMAGE X
ANS=CONTINUE, KEEPS CROSS-DOMAIN RUNNING X
PASSLIM=7, X
PUTYPE=2, X
RETRIES=(,1,4), 4 RETRIES, 1 SECOND BETWEEN X
DISCNT=(NO), (V) VTAM ONLY X
ISTATUS=ACTIVE, (V) VTAM ONLY X
USSTAB=US327X, (V) VTAM ONLY X
XID=YES
**********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
* INN LINK TO RA5
***********************************************************************
RA08GSDL GROUP ANS=CONTINUE, *
IPL=YES, *
LNCTL=SDLC, *
NPACOLL=YES, *
SDLCST=(SDL08PRI,SDL08SEC), *
NRZI=YES, *
PAUSE=0.5
RA8LRA5 LINE ADDRESS=(34,FULL), *
SPEED=19200, *
CLOCKNG=DIRECT, *
DUPLEX=FULL, *
MONLINK=CONTINUOUS, *
SERVLIM=4, *
IPL=YES, *
RETRIES=(,3,5), *
NEWSYNC=NO, *
LPDATS=NO, *
HISPEED=NO, *
ISTATUS=ACTIVE
RA8PRA5 PU TGN=8, *
PUTYPE=4, *
ANS=CONT, *
IRETRY=YES, *
MAXOUT=7, *
PASSLIM=254
*

***********************************************************************
* PERIPHERAL PHYSICAL GROUP NTRI TIC #1 -CCUA TIC TYPE 2 (4MBPS) *
***********************************************************************
PRI8GRP GROUP LNCTL=SDLC, X
ACTIVTO=240, X
DIAL=NO, X
MODE=PRI, X
REPLYTO=3
*
SEC8GRP GROUP LNCTL=SDLC, X
ACTIVTO=240, X
DIAL=NO, X
MODE=SEC, X
REPLYTO=3
*
EG08P00 GROUP ECLTYPE=(PHYSICAL,ANY), X
TRSPEED=4, X
SPEED=9600, X
MAXTSL=2044
*
EL081092 LINE ADDRESS=(1092,FULL), X
ADAPTER=TIC2, MAPS LOGICAL DEF. BELOW X
PORTADD=0, MAPS LOGICAL DEF. BELOW X
LOCADD=400001080000, TIC TOKEN RING ADDR. X
RCVBUFC=4095
*
EP081092 PU
*
***********************************************************************
* PERIPHERAL PHYSICAL GROUP NTRI TIC #2 -CCUA TIC TYPE 2 (4MBPS) *
***********************************************************************
EG08P01 GROUP ECLTYPE=(PHYSICAL,ANY),TRSPEED=4,MAXTSL=2044
*
EL081093 LINE ADDRESS=(1093,FULL), X
PORTADD=1, X
LOCADD=400001080001, X
ADAPTER=TIC2, X
RCVBUFC=4095, X
MAXTSL=2044
*
EP081093 PU
*
*

***********************************************************************
* SUBAREA LOGICAL GROUP NTRI INN LINK TIC #1 -CCUA *
***********************************************************************
*
GLOG8 GROUP ECLTYPE=(LOGICAL,SUBAREA), X
PHYPORT=1, MAPS PHYSICAL GROUP DEF. ABOVE X
*
L081093A LINE TGN=9
*
P081093A PU ADDR=04400001050001, MAPS THE OTHER NCP (SA5) TR ADDR X
PUTYPE=4
*
***********************************************************************
*PERIPHERAL LOGICAL GROUP NTRI TIC#1 - CCUA *
***********************************************************************
EG08L00A GROUP ECLTYPE=LOGICAL, X
AUTOGEN=10, X
CALL=INOUT, X
PHYPORT=0
***********************************************************************
*PERIPHERAL LOGICAL GROUP NTRI TIC#2 - CCUA *
***********************************************************************
EG08L01 GROUP ECLTYPE=LOGICAL, X
AUTOGEN=10, X
CALL=INOUT, X
PHYPORT=1
*
***********************************************************************
***********************************************************************
RA8GCA GROUP LNCTL=CA, X
ISTATUS=INACTIVE STOP VTAM ACTIVATING CHANNEL LINK
CA=TYPE6-TPS, 3745 CHANNEL ADAPTOR TYPE X
RA8PCA PU PUTYPE=5, INTERMEDIATE SUBAREA FUNCTION X

CA=TYPE6, 3745 CHANNEL ADAPTOR TYPE X
RA8PCB PU PUTYPE=5, INTERMEDIATE SUBAREA FUNCTION X
RA8CE1F LINE ADDRESS=9, 3ND CA. PHYSICAL POSITION 2 X
CA=TYPE6, 3745 CHANNEL ADAPTOR TYPE X
RA8PCC PU PUTYPE=5, INTERMEDIATE SUBAREA FUNCTION X
***********************************************************************
GENEND
END

D.2 VTAM RAS Definitions
In the subarea network, RAS is a data host directly connected to RAA, the CMC,
through a multipath channel connection. It is channel attached to RA8NCPX
which is remotely attached to RAA via RA5NCPX.
D.2.1 VTAM Start Options
ATCSTR28
********************************************************
* VTAM START OPTIONS FOR RAS BEFORE MIGRATION TO APPN *
********************************************************
CONFIG=28,
MAXSUBA=255,
CSALIMIT=0,
DYNLU=YES,
DYNASSCP=YES,
GWSSCP=YES,
HOSTPU=ISTPUS28,
HOSTSA=28,
IOBUF=(100,500,5,,1,30),
NCPBUFSZ=2048,
NETID=USIBMRA,
NOTRACE,
TYPE=VTAM,
IOINT=0,
PPOLOG=YES,
SSCPID=28,
SSCPNAME=RAS,
SUPP=NOSUP,
XNETALS=YES
D.2.2 VTAM Configuration List
ATCCON28
***************************************************
* CONFIGURATION LIST FOR SA 28 FOR SA NETWORK *
* BEFORE MIGRATION TO APPN *
***************************************************
RASTSO, TSO APPL
RASNETV, NETVIEW APPL
RASLCL1, LOCAL 3270 DEFN
RASPATH, SA28 PATH TABLE
RASCDRM, CDRM TABLE
RASMPC, MPC TO SA10
RASADJ, ADJSSCP TABLE
RASCA8 CA FOR NCP8

D.2.3 Multipath Channel Connection to RAA
RASMPC
*************************************************
* DEFINITION FOR MPC LINK TO RAA (SA10) BEFORE *
* MIGRATION TO APPN NETWORK *
*************************************************
RASMPC VBUILD TYPE=CA
* MPC LINK FROM RAS TO RAA
RASMPCG GROUP LNCTL=MPC
RASMPCL LINE READ=(C14),WRITE=(C12)
RASMPCP PU PUTYPE=4,ISTATUS=ACTIVE
D.2.4 Local Non-SNA Definitions
RASLCL1
LBUILD
RAST420 LOCAL CUADDR=420,TERM=3277, X
MODETAB=AMODETAB,USSTAB=US3270, X
ISTATUS=ACTIVE,SPAN=(SPH28L),DLOGMOD=M2BSCNQ
RAST427 LOCAL CUADDR=427,TERM=3286,FEATUR2=(MODEL2), X
MODETAB=AMODETAB,ISTATUS=INACTIVE, X
SPAN=(SPH28L)

D.2.5 Channel Connection to NCP Subarea 8
RASCA8
*************************************************
* CA MAJNODE FROM RAS TO NCP8 USING ADDRESS E20*
*************************************************
RASCA8 VBUILD TYPE=CA
* CHANNEL LINK FROM 28 TO 8
RASE20G GROUP LNCTL=NCP
RASE20L LINE ADDRESS=E20
RASE20P PU ISTATUS=ACTIVE,PUTYPE=4,MAXDATA=5000
D.2.6 Adjacent SSCP Table and CDRM Major Node
RASADJ
********************************************
* ADJSSCP TABLE FOR RAS TO USIBMSC NETWORK *
* VIA SUBAREA 20 (RAK). RAA IS ANOTHER SSCP*
* IN THIS NETWORK (USIBMRA) *
********************************************
USIBMRA VBUILD TYPE=ADJSSCP
RAA ADJCDRM
USIBMSC NETWORK NETID=USIBMSC
RAA ADJCDRM
RASCDRM
**************************************************
* CDRM MAJNODE FOR RAS BEFORE MIGRATION TO APPN *
**************************************************
VBUILD TYPE=CDRM
RAA CDRM CDRDYN=YES,CDRSC=OPT,SUBAREA=10

D.2.7 Path Definitions
RASPATH
PATH DESTSA=5,
ER0=(5,1),ER1=(8,1),ER2=(8,1),
ER3=(10,1),
VR0=0,
VR1=2,
VR2=1,
VR3=3,
PATH DESTSA=8,
ER0=(8,1),ER1=(8,1),ER2=(10,1),
ER3=(10,1),
VR0=0,
VRPWS00=(10,30),VRPWS01=(10,30),VRPWS02=(10,30),,
VR1=3,
VR2=2,
PATH DESTSA=10,
ER0=(20,1),ER1=(8,1),ER2=(8,1),
ER3=(10,1),
VR0=0,
VR1=1,
VR2=2,
VR3=3,
PATH DESTSA=20,
ER0=(20,1),ER1=(20,1),ER2=(10,1),
VR0=0,
VR1=2,

Appendix E. VTAM APPN Migration Definitions
E.1.1 Transmission Group Profile Default Table IBMTGPS

The source for this table is found in SYS1.SAMPLIB(IBMTGPS). This example is
from VTAM V4R3; V4R4 added entries for XCF and ATM connections. The TG
profile table is not assembled or linked.
***********************************************************************
* *
* MEMBER NAME: IBMTGPS *
* *
* Descriptive name: IBM-Supplied TG Profiles *
* *
* STATUS: ACF/VTAM VERSION 4 RELEASE 3 *
* *
* COPYRIGHT: LICENSED MATERIALS - PROPERTY OF IBM *
* *
* 5695-117 (C) COPYRIGHT IBM CORP. 1992. *
* ALL RIGHTS RESERVED. *
* *
* U.S. GOVERNMENT USERS RESTRICTED RIGHTS - *
* USE, DUPLICATION OR DISCLOSURE RESTRICTED BY *
* GSA ADP SCHEDULE CONTRACT WITH IBM CORP. *
* *
* SEE COPYRIGHT INSTRUCTIONS. *
* $MAC(IBMTGPS),COMP(TRS),PROD(VTAM): IBM Supplied TG Profiles *
***********************************************************************
*
**********************************************************************
* Ethernet *
**********************************************************************
ETHERNET TGP COSTTIME=0,COSTBYTE=0,SECURITY=UNSECURE, *
PDELAY=NEGLIGIB,CAPACITY=10M
*
**********************************************************************
* Token Ring *
**********************************************************************
TOKNRING TGP COSTTIME=0,COSTBYTE=0,SECURITY=UNSECURE, *
*
**********************************************************************
* ISDN Non-Switched *
**********************************************************************
ISDNNSWT TGP COSTTIME=0,COSTBYTE=0,SECURITY=UNSECURE, *
PDELAY=TERRESTR,CAPACITY=64K

*
**********************************************************************
* ISDN Switched *
**********************************************************************
ISDNSWTD TGP COSTTIME=128,COSTBYTE=128,SECURITY=UNSECURE, *
*
**********************************************************************
* SDLC Non-Switched *
**********************************************************************
SDLCNSWT TGP COSTTIME=0,COSTBYTE=0,SECURITY=UNSECURE, *
*
**********************************************************************
* SDLC Switched *
**********************************************************************
SDLCSWTD TGP COSTTIME=128,COSTBYTE=128,SECURITY=UNSECURE, *
*
**********************************************************************
* X.25 *
**********************************************************************
X25 TGP COSTTIME=128,COSTBYTE=128,SECURITY=PUBLIC, *
PDELAY=PACKET,CAPACITY=10K
**********************************************************************
* 16M Token Ring *
**********************************************************************
TRING16M TGP COSTTIME=0,COSTBYTE=0,SECURITY=UNSECURE, *
*
**********************************************************************
* Channel *
**********************************************************************
CHANNEL TGP COSTTIME=0,COSTBYTE=0,SECURITY=SECURE, *
*
**********************************************************************
* ESCON Channel *
**********************************************************************
ESCON TGP COSTTIME=0,COSTBYTE=0,SECURITY=SECURE, *

E.1.2 APPN Entries in ISTINCLM IBM Default Logmode Table
The source for this table is found in SYS1.SAMPLIB(ISTINCLM). Reproduced
here are new mode entries in this table which are APPN-specific. The reader
should note that every entry (including those not shown) has been updated with
an appropriate APPNCOS entry.
This table is assembled and linked, as it always has been.
TITLE ′ SNASVCMG′ *@R495812*

**********************************************************************
* LOGMODE TABLE ENTRY FOR RESOURCES CAPABLE OF ACTING *
* AS LU 6.2 DEVICES @R495812 @KFC*
**********************************************************************
SNASVCMG MODEENT LOGMODE=SNASVCMG,TYPE=0,FMPROF=X′ 1 3 ′ , TSPROF=X′ 0 7 ′ , *
PRIPROT=X′ B0′ , SECPROT=X′ B0′ , COMPROT=X′ D0B1′ , *
RUSIZES=X′9797′,ENCR=B′0000′, *@Y1C* *
PSERVIC=X′060200000000000000002300′, *@R495812 @02C* *
APPNCOS=SNASVCMG *@KGA @T1C @03C @05M*
* SPECIFY SYNC LEVEL = CONFIRM @03A*
TITLE ′ # BATCH′ *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR BATCH SESSIONS ON RESOURCES CAPABLE *
* @KFA*
***********************************************************************
#BATCH MODEENT LOGMODE=#BATCH,FMPROF=X′ 1 3 ′ , TSPROF=X′ 0 7 ′ , *@KFA* *
ENCR=B′0000′,SSNDPAC=3,RUSIZES=X′ F7F7′ , *@KFA**@04C*
SRCVPAC=3,PSNDPAC=3,APPNCOS=#BATCH *@KFA**@KGC**@T3C*
TITLE ′ # INTER′ *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR INTERACTIVE SESSIONS ON RESOURCES *
* CAPABLE OF ACTING AS LU 6.2 DEVICES *
* @KFA*
***********************************************************************
#INTER MODEENT LOGMODE=#INTER,FMPROF=X′ 1 3 ′ , TSPROF=X′ 0 7 ′ , *@KFA* *
SRCVPAC=7,PSNDPAC=7,APPNCOS=#INTER *@KFA**@KGC**@T3C*
TITLE ′ # BATCHSC′ *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR BATCH SESSIONS REQUIRING SECURE *
* TRANSPORT ON RESOURCES CAPABLE OF ACTING AS LU 6.2 *
* DEVICES *
* @KFA*
***********************************************************************
#BATCHSC MODEENT LOGMODE=#BATCHSC,FMPROF=X′ 1 3 ′ , TSPROF=X′ 0 7 ′ , *@KFA* *
SRCVPAC=3,PSNDPAC=3,APPNCOS=#BATCHSC *@KFA**@KGC**@T3C*
TITLE ′ # INTERSC′ *@KFA*
Appendix E. VTAM APPN Migration Definitions 239

***********************************************************************
* *
* LOGMODE TABLE FOR INTERACTIVE SESSIONS REQUIRING *
* SECURE TRANSPORT ON RESOURCES CAPABLE OF ACTING AS *
* LU 6.2 DEVICES *
* @KFA*
***********************************************************************
#INTERSC MODEENT LOGMODE=#INTERSC,FMPROF=X′ 1 3 ′ , TSPROF=X′ 0 7 ′ , *@KFA* *
SRCVPAC=7,PSNDPAC=7,APPNCOS=#INTERSC *@KFA**@KGC**@T3C*
TITLE ′ CPSVCMG′ *@KFA*
***********************************************************************
* *
* LOGMODE TABLE FOR CP-CP SESSIONS ON RESOURCES CAPABLE *
* @KFA*
***********************************************************************
CPSVCMG MODEENT LOGMODE=CPSVCMG, *@KFA* *
RUSIZES=X′9797′,ENCR=B′0000′, *@KFA @T2C* *
SSNDPAC=7,SRCVPAC=7,PSNDPAC=7, *@KFA* *
APPNCOS=CPSVCMG *@KGA*
***********************************************************************
* *
* LOGMODE TABLE ENTRY THAT SUPPLIES A DEFAULT COS *
* AND USES LU 6.2 DEVICE CHARACTERISTICS *
* @KHA *
***********************************************************************
ISTCOSDF MODEENT LOGMODE=ISTCOSDF,FMPROF=X′ 1 3 ′ , *@KHA* *
TSPROF=X′ 0 7 ′ , PRIPROT=X′ B0′ , SECPROT=X′ B0′ , *
COMPROT=X′ D0B1′ , PSERVIC=X′060200000000000000000300′, *
RUSIZES=X′8989′,ENCR=B′0000′,TYPE=0, *@W1C* *
APPNCOS=#CONNECT
* @KHA *
TITLE ′ CPSVRMGR′ *@I1A*
***********************************************************************
* *
* LOGMODE TABLE FOR SESSIONS BETWEEN A DLS (DEPENDENT LU *
* SERVER) AND A DLR (DEPENDENT LU REQUESTOR). @I1A *
* *
***********************************************************************
CPSVRMGR MODEENT LOGMODE=CPSVRMGR, *@I1A* *
ENCR=B′0000′, *@I1A* *
RUSIZES=X′9797′, *@U3A* *
SSNDPAC=7,SRCVPAC=7,PSNDPAC=7, *@I1A* *
APPNCOS=SNASVCMG *@I1A*
* @T4A @06C*

E.1.3 RAAMDLS Customized MODEL Major Node
RAAMDLS is the customized model major node that we created for our test
environment using ISTMODEL as a sample.
******************************************************************
* *
* VTAM SWITCHED MAJOR NODE FOR ITSC OFFICES *
* *
* CONNTYPE=LEN, WILL ALLOW ILUS COMING IN FROM THIS X
* PU TO HAVE THE PU IN THE ALSLIST FOR THE ILU. X
* *
* CONNTYPE=APPN WILL CAUSE ISTAPNPU TO BE THE ONLY X
* ENTRY IN THE ALSLIST FOR ILUS COMING IN FROM THIS X
* PU EVEN THOUGH THE PU WILL SHOW UP AS THE X
* ADJACENT LINK STATION (BUT NOT IN THE ALSLIST) X
* *
******************************************************************
SWMODEL VBUILD TYPE=MODEL
PUMOD05D PU ADDR=13,
ANS=CONT,
DISCNT=NO,
CONNTYPE=APPN,
MAXDATA=1033,
PUTYPE=2
*
LU6205D LU LOCADDR=0,DLOGMOD=DSIL6MOD
LUMOD05D LU LOCADDR=2,
PACING=0,
DLOGMOD=D4C32XX3,
MODETAB=ISTINCLM,
USSTAB=US327X,
VPACING=0
******************************************************************
* *
* MODEL FOR IDBLK X′017′ - PC 3270 EMULATION *
* *
******************************************************************
PUMOD017 PU ADDR=C1,
ANS=CONT,
PUTYPE=2
LUMOD017 LU LOCADDR=2,
PACING=0,
DLOGMOD=D4C32XX3,
MODETAB=ISTINCLM,
USSTAB=US327X,
VPACING=0
Appendix E. VTAM APPN Migration Definitions 241

******************************************************************
* *
* MODEL FOR IDBLK X′056′ - AS/400 *
* *
******************************************************************
PUMOD056 PU ADDR=01,
ANS=CONT,
PUTYPE=2
MODETAB=ISTINCLM,
USSTAB=ISTINCDT,
PACING=7
*
******************************************************************
* *
* MODEL FOR IDBLK X′012′ - DEC *
* *
******************************************************************
MAXDATA=521,
MAXOUT=7,PASSLIM=7,
PUTYPE=2
LUMODA12 LU LOCADDR=0,DLOGMOD=SNASVCMG,MODETAB=MTAPPC
LUMODB12 LU LOCADDR=0,DLOGMOD=SNASVCMG,MODETAB=MTAPPC
LUMODC12 LU LOCADDR=2,DLOGMOD=M2SDLCQ,MODETAB=AMODETAB
******************************************************************
* *
* MODEL FOR IDBLK X′061′ - PC 3270 EMULATION *
* *
******************************************************************
ANS=CONT,
PUTYPE=2
MODETAB=ISTINCLM,
USSTAB=ISTINCDT,
PACING=1

Appendix F. VTAM Definitions with RAA as ICN
When we migrate VTAM host RAA to an interchange node, with RAS still a
subarea host, the subarea VTAM definitions on RAA are modified. To
summarize:
• On VTAM RAA:
− The start options in ATCSTR10 are changed.
− All other major nodes on RAA remain the same as in the subarea
environment. Refer to D.1, “VTAM RAA Definitions” on page 208 for
details.
• No change to any VTAM RAS major node from the subarea environment.
Refer to D.2, “VTAM RAS Definitions” on page 233 for details.
Here we list only the changed major nodes. For the list of other major nodes on
RAA and RAS, refer to Appendix D, “VTAM Subarea Initial Definitions” on
page 207.

F.1 VTAM RAA Definitions Updated for ICN
ATCSTR10
*******************************************************************
* *
* ATCSTR10 FOR RAA *
* THIS IS SUBAREA 10 STAGE 2: ICN *
* *
* MARK CHANGE *
* ---- --------------------------------------- *
* @ICN1 ADD ICN FOR NN AND CONNTYPE=LEN *
* @ICN2 CHANGED DYNLU TO YES *
*******************************************************************
APPNCOS=#CONNECT, @ICN1* X
CDSERVR=YES, @ICN1* X
CONFIG=10, X
CONNTYPE=LEN, @ICN1* X
CPCP=YES, @ICN1* X
CSALIMIT=0, X
DIRSIZE=0, DEFAULT @ICN1* X
DIRTIME=8D, DEFAULT @ICN1* X
DYNADJCP=YES, DEFAULT @ICN1* X
DYNLU=YES, @ICN2* X
HOSTPU=ISTPUSA0, X
HOSTSA=10, X
HPR=NONE, @ICN1* X
INITDB=ALL, DEFAULT @ICN1* X
IOBUF=(100,384,5,,1,30), X
NETID=USIBMRA, X
NODETYPE=NN, @ICN1* X
NOTRACE,TYPE=VTAM,IOINT= X
NUMTREES=100, DEFAULT @ICN1* X
RESUSAGE=100, DEFAULT @ICN1* X
ROUTERES=128, DEFAULT @ICN1* X
SSCPID=99, X
SSCPNAME=RAA, SSCPNAME/CPNAME X
SORDER=SUBAREA, @ICN1* X
SSEARCH=YES, DEFAULT @ICN1* X
SUPP=NOSUP, X
TNSTAT,CNSL, X
XNETALS=YES

Appendix G. VTAM Definitions with RAA as ICN and RAS as MDH
Once VTAM RAA has been migrated to an ICN, the data host RAS is migrated to
an MDH. The following is a summary of the changes required on RAA and RAS
for the implementation:
• On RAA:
− The configuration list ATCCON10 is updated.
− The CDRM major node RAACDRM is updated for VR-TG.
− New major nodes RAAAHHC and RAALCL2 are created.
− The MPC major node RAAMPC1 is no longer required.
− The following major nodes have not changed:
- ATCSTR10 (see F.1, “VTAM RAA Definitions Updated for ICN” on
page 244)
- RAAPATH, RAACDRSC, RAAADJ, all switched major nodes,
RA5NCPX and RA8NCPX (see D.2, “VTAM RAS Definitions” on
page 233)
• On RAS numerous major nodes are updated, so in the appendix here we list
all RAS′s major nodes.

G.1 VTAM RAA Definitions Updated for MDH
G.1.1 Configuration List
ATCCON10
*******************************************************************
* ATCCON10 FOR RAA *
* THIS IS SUBAREA 10 AFTER MIGRATION OF SUBAREA 10 TO AN ICN *
* AND SUBAREA 28 TO AN MDH *
* *
* MARK CHANGE *
* ---- --------------------------------------- *
* @MDH1 REPLACE MPC WITH AHHC *
*******************************************************************
RAAATSO, TSO APPL X
RAAANETV, NETVIEW V2.4 APPL X
RAAPATH, SA10 PATH TABLE X
RAACDRM, CDRM X
RAACDRSC, CDRSCS X
RAACDILU, ILUS X
RAAADJ, ADJSSCP TABLE X
RAACTCA, CTC TO SA 20 X
RAAAHHC, ADD @MDH1 AHHC TO SA 28 (FID2) X
RAALCL1, LOCAL 3270 SCREENS X
RAALCL2, ADD @MDH1 AHHC TO SA 28 (FID2) X
RAASWMN1, SW-TR MN FOR 3174 X
RAASWMN2, SW-TR MN FOR CM/2 (KEN) X
RAASWMN3, SW-TR MN FOR CM/2 (ANAR) X
RAASWMN4, SW-TR MN FOR CM/2 (RABINDER) X
RAASWMN5, SW-TR MN FOR AS/400 X
RA5NCPX, NCP SA 5 X
RA8NCPX REMOTE NCP SA8
**RAAMPC1, DEL @MDH1 CTC TO SA 28 (FID4 MPC) X

G.1.2 CDRM Definitions
RAACDRM
*******************************************************************
* CDRM MAJORNODE FOR RAA *
* SUBAREA 10 AS AN ICN AND SUBAREA 28 AS AN MDH *
* *
* MARK CHANGE *
* ---- --------------------------------------- *
* @MDH1 ADD PARAMETERS FOR VRTG LINK TO RAS *
*******************************************************************
VBUILD TYPE=CDRM
RAS CDRM SUBAREA=28,CDRDYN=YES,CDRSC=OPT, X
VRTG=YES @MDH1*
G.1.3 ANNC Definitions from RAA to RAS
RAAAHHC
****************************************************************
* WHEN RAA IS AN ICN AND RAS IS AN MDH *
****************************************************************
* APPN MPC LINK FROM RAA TO RAS
RAAAHHCT TRLE LNCTL=MPC,READ=(C12),WRITE=(C14)
RAALCL2
****************************************************************
****************************************************************
RAALCL2 VBUILD TYPE=LOCAL
RAAPUAHC PU TRLE=RAAAHHCT, *
CONNTYPE=APPN, *
CPCP=YES, *
PUTYPE=2, *
XID=YES, *
TGP=CHANNEL, *
ISTATUS=ACTIVE
Appendix G. VTAM Definitions with RAA as ICN and RAS as MDH 247
G.2 VTAM RAS Definitions Updated for MDH
G.2.1 Start Options
ATCSTR28
*******************************************************************
* THIS IS SUBAREA 28 AFTER MIGRATION TO AN MDH NODE, AND *
* SUBAREA 28 IS AN ICN *
* *
* MARK CHANGE *
* ---- --------------------------------------- *
* @MDH1 ADD MDH FOR EN AND CONNTYPE=APPN *
*******************************************************************
CONFIG=28, X
MAXSUBA=255, X
CSALIMIT=0, X
CONNTYPE=APPN, DEFAULT @MDH1* X
CPCP=YES, @MDH1* X
DYNLU=YES, X
DYNADJCP=YES, DEFAULT @MDH1* X
GWSSCP=NO, X
HOSTPU=ISTPUS28, X
HOSTSA=28, X
HPR=NONE, @MDH1* X
IOBUF=(100,500,5,,1,30), X
NCPBUFSZ=2048, X
NETID=USIBMRA, X
NODETYPE=EN, @MDH1* X
NOTRACE,TYPE=VTAM,IOINT=0, X
PPOLOG=YES, X
SORDER=SUBAREA, @MDH1* X
SSCPID=28, X
SSCPNAME=RAS, X
SUPP=NOSUP, X
VRTG=NO, DEFAULT @MDH1 X
XNETALS=YES

G.2.2 Configuration List
ATCCON28
*******************************************************************
* ATCCON28 FOR RAS *
* *
* MARK CHANGE *
* ---- --------------------------------------- *
*******************************************************************
RASTSO, TSO APPL X
RASNETV, NETVIEW APPL X
RASCTCA, CTC TO SA28 X
RASLCL1, LOCAL 3270 DEFN X
RASLCL2, ADD @MDH1 AHHC TP SA10 (FID2) X
RASPATH, SA28 PATH TABLE X
RASCDRM, CDRM TABLE X
RASAHHC, ADD @MDH1 AHHC TO SA10 (FID2) X
RASADJ, ADJSSCP TABLE X
RASCA8 CA FOR NCP8
**RASMPC1, DEL @MDH1 MPC TO SA10 (FID4)
G.2.3 CDRM Definitions
RASCDRM
*******************************************************************
* CDRM MAJORNODE FOR RAS *
* SUBAREA 10 AS AN ICN AND SUBAREA 28 AS AN MDH *
* *
* MARK CHANGE *
* ---- --------------------------------------- *
* @MDH1 ADD PARAMETERS FOR VRTG LINK TO RAA *
*******************************************************************
VBUILD TYPE=CDRM
RAA CDRM CDRDYN=YES,CDRSC=OPT,SUBAREA=10, X
VRTG=YES @MDH1*
RAK CDRM CDRDYN=YES,CDRSC=OPT,SUBAREA=20
Appendix G. VTAM Definitions with RAA as ICN and RAS as MDH 249
G.2.4 ANNC Definitions from RAS to RAA
RASAHHC
****************************************************************
****************************************************************
* APPN MPC LINK FROM RAS TO RAA
RASAHHCT TRLE LNCTL=MPC,READ=(C14),WRITE=(C12)
RASLCL2
****************************************************************
****************************************************************
RASAHHC VBUILD TYPE=LOCAL
RASPUAHC PU TRLE=RASAHHCT, *
CONNTYPE=APPN, *
CPCP=YES, *
XID=YES, *
TGP=CHANNEL, *
ISTATUS=ACTIVE

Appendix H. VTAM Definitions with RAA as ICN and RAS as EN
With the conversion of VTAM RAS from an MDH to a pure EN, the VTAM
definitions are as follows:
• On RAA:
− Only NCP RA8NCPX has changed. The changes are listed below in H.1,
“VTAM RAA Definitions Updated for Pure EN” on page 252.
− No change to the remaining major nodes for RAA. They remain the
same as in Appendix G, “VTAM Definitions with RAA as ICN and RAS as
MDH” on page 245.
• On RAS:
− Major nodes ATCSTR28, ATCCON28, RASCA8 have changed from the
MDH definitions. These major nodes are listed below in H.2, “VTAM RAS
Definitions Updated for Pure EN” on page 253.
− The remaining major nodes on RAS are the same as the ones set up for
the MDH environment (see Appendix G, “VTAM Definitions with RAA as
ICN and RAS as MDH” on page 245).

H.1 VTAM RAA Definitions Updated for Pure EN
Portion of RA8NCPX
*******************************************************************
* NCP DEFINITIONS FOR CHANNEL CONNECTION FROM RA8NCPX TO RAS *
* AFTER MIGRATION TO APPN WITH RAS AS EN (FID2 CONNECTION) *
* *
* MARK CHANGE *
* ---- --------------------------------------- *
* @EN1 CHANGE FROM FID4 TO FID2 CONNECTION *
*******************************************************************
*
***********************************************************************
***********************************************************************
RA8GCA GROUP LNCTL=CA, *
ISTATUS=INACTIVE
RA8CE20 LINE ADDRESS=0, *
CA=TYPE6-TPS, *
CASDL=120, *
CONNTYPE=APPN, ADD @EN1 *
DELAY=0.2, *
DYNADMP=NONE, *
ISTATUS=ACTIVE, ADD @EN1 *
NCPCA=ACTIVE, *
TIMEOUT=120 *
RA8PCA PU PUTYPE=2, UPD @EN1 *
XID=YES, FOR TYPE 2.1 FID2 ADD @EN1 *
TGP=CHANNEL FOR TYPE 2.1 FID2 ADD @EN1

H.2 VTAM RAS Definitions Updated for Pure EN
H.2.1 RAS Start Options
ATCSTR28
*******************************************************************
* THIS IS SUBAREA 28 AFTER MIGRATION TO AN MDH NODE, AND *
* SUBAREA 28 IS AN ICN *
* *
* MARK CHANGE *
* ---- --------------------------------------- *
* @MDH1 ADD MDH FOR EN AND CONNTYPE=APPN *
* @EN1 DEL FOR PURE END NODE *
*******************************************************************
CONFIG=28, X
MAXSUBA=255, X
CSALIMIT=0, X
CONNTYPE=APPN, DEFAULT @MDH1* X
CPCP=YES, @MDH1* X
DYNLU=YES, X
DYNADJCP=YES, DEFAULT @MDH1* X
GWSSCP=NO, X
HOSTPU=ISTPUS28, X
HPR=NONE, @MDH1* X
IOBUF=(100,500,5,,1,30), X
NCPBUFSZ=2048, X
NETID=USIBMRA, X
NODETYPE=EN, @MDH1* X
PPOLOG=YES, X
SORDER=SUBAREA, @MDH1* X
SSCPID=28, X
SSCPNAME=RAS, X
SUPP=NOSUP, X
VRTG=NO, DEFAULT @MDH1 X
XNETALS=YES
**HOSTSA=28 DEL @EN1
Appendix H. VTAM Definitions with RAA as ICN and RAS as EN 253

H.2.2 Configuration List
ATCCON28
*******************************************************************
* ATCCON28 FOR RAS *
* *
* MARK CHANGE *
* ---- --------------------------------------- *
* @EN1 ENTRIES NOT REQUIRED FOR PURE EN *
*******************************************************************
RASTSO, TSO APPL X
RASNETV, NETVIEW APPL X
RASCTCA, CTC TO SA28 X
RASLCL1, LOCAL 3270 DEFN X
RASLCL2, ADD @MDH1 AHHC TO SA10 (FID2) X
RASAHHC, ADD @MDH1 AHHC TO SA10 (FID2) X
RASADJ, ADJSSCP TABLE X
RASXCA, XCA FOR 3172 X
RASCA8 CA FOR NCP8
**RASMPC1, DEL @MDH1 MPC TO SA10 (FID4)
**RASPATH, DEL @EN1 SA28 PATH TABLE
**RASCDRM, DEL @EN1 SA28 CDRM TABLE
H.2.3 RAS to NCP Channel Connection
RASCA8
*******************************************************************
* CA MAJNODE FOR CHANNEL CONNECTION (TYPE2.1) TO RA8NCPX *
* AFTER MIGRATION TO APPN WITH RAS AS EN (FID2 CONNECTION) *
* *
* MARK CHANGE *
* ---- --------------------------------------- *
* @EN1 CHANGE FROM FID4 TO FID2 CONNECTION *
*******************************************************************
RASCA8 VBUILD TYPE=LOCAL
RASE20P PU PUTYPE=2, ADD @EN1* X
CUADDR=E20, ADD @EN1* X
XID=YES, ADD @EN1* X
CPCP=YES, ADD @EN1* X
SSCPFM=USSSCS, ADD @EN1* X
CONNTYPE=APPN ADD @EN1*
*RASE20G GROUP LNCTL=NCP DEL @EN1*
*RASE20L LINE ADDRESS=E20 DEL @EN1*
*RASE20P PU ISTATUS=ACTIVE,PUTYPE=4,MAXDATA=5000 DEL @EN1*

Appendix I. Additional Definitions for SSCP Takeover
The NCP changes for the SSCP takeover were basic, and involved simply adding
BACKUP=YES and OWNER=DUMMY to the PCCU statement. Each GROUP
also had OWNER=DUMMY defined.
I.1.1 RAS Defined for SSCP Takeover

RAS subarea 28 was defined as a backup ICN.
ATCSTR28
*******************************************************************
* THIS IS SUBAREA 28 AS A BACKUP ICN FOR SSCP TAKEOVER *
* *
* *
*******************************************************************
APPNCOS=#CONNECT,
CONFIG=28,
BN=YES,
CDSERVR=YES,
CONNTYPE=APPN,
CONFIG=28,
CPCP=YES,
CSALIMIT=0,
DIRSIZE=0,
DIRTIME=8D,
DYNADJCP=YES,
DYNLU=YES,
GWSSCP=YES,
HOSTPU=ISTPUS28,
HOSTSA=28,
HPR=NONE,
INITDB=ALL,
IOBUF=(100,500,5,,1,30),
MAXSUBA=255,
NETID=USIBMRA,
NODETYPE=NN,
NUMTREES=100,
RESUSAGE=100,
ROUTERES=128,
PPOLOG=YES,
SORDER=SUBAREA,
SSCPID=10028,
SSCPNAME=RAS,
SSEARCH=YES,
SUPP=NOSUP,
TNSTAT,CNSL,
VRTG=NO,
XNETALS=YES

I.1.2 Channel-Attached Major Node RASCA8
This CA major node provides the FID4 connectivity required for NCP activation
and ownership.
RASCA8
RASCA8 VBUILD TYPE=CA
* CHANNEL LINK FROM 28 TO 8
RASE20G GROUP LNCTL=NCP
RASE20L LINE ADDRESS=E20
RASE20P PU ISTATUS=ACTIVE,PUTYPE=4,MAXDATA=5000
I.1.3 Adjacent CP Table on RAA

This adjacent CP table is provided to show how it can be used. If you have
many CP-CP connections you may want to use the dynamic facilities
(DYNADJCP=YES) and ISTADJCP.
RAAADJCP
*******************************************************************
* *
* ADJCP TABLE FOR RAA *
* *
* *
*******************************************************************
VBUILD TYPE=ADJCP

Appendix J. Configuration Services Exit
This appendix describes the exit ISTEXCCS, supplied with VTAM to allow
dependent LUs and their PUs to be defined dynamically. If VTAM finds this exit
in your VTAMLIB data set it will be used.
J.1 Default ISTEXCCS Invocation

The default exit allows for different types of block IDs (IDBLK/IDNUM) to be
defined with different naming conventions. The naming generator is invoked by
the exit′s internal naming generation table. This uses the block ID of the
resource and the name generation table to create PU and LU names. Below is a
list of block IDs by device type and the names that would be generated by the
sample default exit in conjunction with the sample model major node ISTMODEL.
The sample model major node specifies the device characteristics such as
logmode and USS table. The naming generation table decides how many of
each are to be created. For example, in the case of a PC running CM/2 or
Communications Server, 16 LUs are created (the numbering system is
hexadecimal).
Table 10. ISTEXCCS Default Internal Name Generation

IDBLK of IDNUM of Device Model PU Name LU Names
device device name
X′000′ X′00000′ IBM PUMODxxx X00000 X0000002
reserved LUMODxxx
X′017′ X′00001′ 3174 or PUMOD017 U00001 U0000102
3270 LUMOD017 -U0000103
emulator
X′056′ X′00002′ AS/400 PUMOD056 V00002 V0000202
LUMOD056 -V0000205
X′05 D′ X′00003′ CM/2 or PUMOD05D W00003 W0000302
CS/2 LUMOD05D -W0000311
The first character is allocated using the following convention:
Character(s) Convention
A - M, @, $, # Used for customer generated names.
(IBM generated names will not begin
with these characters).
N Used for dynamic I/O generated names.
(customer seed not supplied)
O - T Reserved for IBM use.
U - Z Used to identify IBM generated names.
Figure 136. Character Convention Used by ISTEXCCS Exit
The dynamically created names are placed in ISTDSWMN. The following is a

display of the dynamically assigned names for a PC running OS/2 and CM/2.
The IDNUM is X′05150′.

C RAAAN DISPLAY NET,ID=ISTDSWMN,SCOPE=ALL

′ RAAAN
IST075I NAME = ISTDSWMN , TYPE = SW SNA MAJ NODE
IST084I NETWORK NODES:
IST089I W05150 TYPE = PU_T2.1 , ACTIV--LX-1
IST089I W0515002 TYPE = LOGICAL UNIT , ACTIV---X-
IST089I W0515003 TYPE = LOGICAL UNIT , ACT/S---X-
IST089I W051500A TYPE = LOGICAL UNIT , ACTIV---X-
IST089I W051500B TYPE = LOGICAL UNIT , ACTIV---X-
IST089I W051500C TYPE = LOGICAL UNIT , ACTIV---X-
IST089I W051500D TYPE = LOGICAL UNIT , ACTIV---X-
IST089I W051500E TYPE = LOGICAL UNIT , ACTIV---X-
IST089I W051500F TYPE = LOGICAL UNIT , ACTIV---X-
IST314I END

Figure 137. D NET,ID=ISTDSWMN,SCOPE=ALL
Note:
1 The resource status field information informs us that an independent

LU is using this PU as its adjacent link station (L) and that the resource
was dynamically created from a model definition (X). The independent LU
is, no doubt, the control point. This is not shown in the display because it
is represented as a CDRSC and resides in the ISTCDRDY major node.
J.2 Alternate ISTEXCCS Invocations

If you have pre-defined switched PUs and LUs, the exit will not be called unless
you request this. The default setting is to call the exit if a PU and its LUs are not
defined and the connection status is inactive. Once the exit is called, it can
affect the way names are built.
If you do not wish to update your exit, you can use two definition files, CPNDEF
and NIDDEF. These are 80-byte fixed record sequential data sets which are
allocated by VTAM′s start procedure. The configuration services XID exit looks
for these data sets when it is invoked.
CPNDEF is used to define nodes by CP name; NIDDEF is used to define nodes by

IDBLK and IDNUM. You can define your devices here in exactly the same way
as the exit′s internal name generation table. The format for these files can be
found in VTAM Customization , LY43-0110, in Appendix D. Users must be
licensed for VTAM to obtain this manual.
Using these files gives you control over the names you want to define in your
network. At the same time it allows you to point to the model major node entry
of your choice for a given device. If the CP name or the IDBLK/IDNUM are not
found in these data sets the exit will attempt to build a name from the name
generation table. In either case the definitions are added to ISTDSWMN. If the

name is found the exit does not invoke the name generation function and
definitions are created from the data set information.
J.3 Sample Model Major Node

Figure 138 on page 260 shows the model major node supplied with VTAM. This
defines the device characteristics for dynamically created LUs and PUs.
As seen previously in Figure 137 on page 258, definitions are added to the
dynamically defined major node ISTDSWMN, created by VTAM. You have control
over the names defined in VTAM by this method. The exit must be used in
conjunction with a model major node.
Independent LUs are not supported in this exit. Use predefined CDRSCs or
allow dynamic ILU definition.
Appendix J. Configuration Services Exit 259

***********************************************************************
* *
* Descriptive name: VTAM Sample MODEL Major Node *
* *
* Copyright: None *
* *
* Function: Defines model names that can be returned by VTAM′ s sample *
* Configuration Services XID Exit Routine - ISTEXCCS. *
* *
* $MAC(ISTMODEL),COMP(CONFGSVC),PROD(VTAM): VTAM Sample MODEL *
* Major Node *
* *
* Flag Reason Release Date Origin Flag description *
* ---- -------- ------- ------ ------ ------------------------------ *
* $V0= P097135 HVT3401 910714 086881: Sample Model Major Node *
* *
***********************************************************************
ISTMODEL VBUILD TYPE=MODEL
***********************************************************************
* *
* Model for IDBLK X′017′ - PC 3270 Emulation *
* *
***********************************************************************
PUMOD017 PU ADDR=C1, X
ANS=CONT, X
PUTYPE=2
LUMOD017 LU LOCADDR=2, X
MODETAB=ISTINCLM, X
USSTAB=ISTINCDT, X
PACING=1
***********************************************************************
* *
* Model for IDBLK X′056′ - AS/400 *
* *
***********************************************************************
PUMOD056 PU ADDR=01, X
ANS=CONT, X
PUTYPE=2
LUMOD056 LU LOCADDR=2, X
MODETAB=ISTINCLM, X
USSTAB=ISTINCDT, X
PACING=7
***********************************************************************
* *
* Model for IDBLK X′05D′ - OS/2 Communications Manager *
* *
***********************************************************************
PUMOD05D PU ADDR=01, X
ANS=CONT, X
PUTYPE=2
LUMOD05D LU LOCADDR=2, X
MODETAB=ISTINCLM, X
USSTAB=ISTINCDT, X
PACING=7
Figure 138. Default MODEL Major Node ISTMODEL

Appendix K. New Function Added by APARs
New VTAM functions are continually being added by means of APARs rather
than in new releases. This has the benefit of making customer-requested
features available earlier than they would otherwise appear. However, the
disadvantage is that there is no formal method of broadcasting the changes.
Therefore, we have listed here the most recent APPN-related functions that have
been introduced in this way. Our base is VTAM V4R4, but some of these may
have been retro-fitted to earlier releases.
Table 11. New Function APARs

APAR Description
Number
OW25288 PSRETRY start option. Allows automatic path switch attempts at intervals.
OW25514 XCF improvements. Adds model TG profile to XCF connections, as well as permitting ISR
traffic over an XCF connection.
OW25950 HPRNCPBF start option. Allows an HPR route to be chosen for NCP-attached dependent LUs
even if it doubles back on itself.
OW26193 DLUS-served resource registration. Reduces searching when a DLUR node is across a
network boundary from its DLUS.
OW26200 ANNC improvements. Permits ISR traffic across HPDT MPC (MPC + ) connection.
OW26732 HPR over XCA. Adds HPR support for XCA-attached LAN connections.
OW26906 CNN Routing improvements. Upgrades the CNN routing function to that described in 9.4,
“Composite Network Node Routing” on page 161.
OW26928 ISTVTCOS for CP-CP sessions. Gives high-priority subarea COS to sessions to VTAM′s CP.
OW28568 Blank COS in mapping tables. Allows APPN COS mapping to or from blank subarea COS.
OW29171 DISJOINT CDRM enhancement. Improves search control for same-network subarea VTAMs
connected only by APPN.
OW29969 Subarea mapping tables. Improves CNN routing for remote NCPs.
OW30001 Generic Resources improvements. Allows load balancing for locally attached generic
resource partner.
OW30194 DLRORDER start option. Determines whether CP name or IDBLK/IDNUM is used for
identifying DLUR resources.

Appendix L. Special Notices
This publication is intended to help network systems programmers and network

analysts to migrate existing subarea networks to combined subarea and
APPN/HPR networks. The information in this publication is not intended as the
specification of any programming interfaces that are used in this book. See the
PUBLICATIONS section of the IBM Programming Announcements for eNetwork
Communications Server for OS/390, ACF/NCP, Communications Server for OS/2
Warp, and 3174 LIC C6 for more information about what publications are
considered to be product documentation.
Reference to PTF numbers that have not been released through the normal
distribution process does not imply general availability. The purpose of
including these reference numbers is to alert IBM customers to specific
information relative to the implementation of the PTF when it becomes available
to each customer according to the normal IBM PTF distribution process.
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
Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood, NY 10594 USA.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact IBM Corporation, Dept.
600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and conditions,

including in some cases, payment of a fee.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The information about non-IBM
(″vendor″) products in this manual has been supplied by the vendor and IBM
assumes no responsibility for its accuracy or completeness. 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 pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of these
Web sites.
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.
Reference to PTF numbers that have not been released through the normal
distribution process does not imply general availability. The purpose of
including these reference numbers is to alert IBM customers to specific
information relative to the implementation of the PTF when it becomes available
to each customer according to the normal IBM PTF distribution process.
The following terms are trademarks of the International Business Machines

Corporation in the United States and/or other countries:
ACF/VTAM Advanced Peer-to-Peer Networking

APPN AS/400
ESCON IBM
MVS/ESA NetView
OS/2 OS/390
PS/2 System/390
VTAM
The following terms are trademarks of other companies:
C-bus is a trademark of Corollary, Inc.
Java and HotJava are trademarks of Sun Microsystems, Incorporated.
Microsoft, Windows, Windows NT, and the Windows 95 logo are trademarks
or registered trademarks of Microsoft Corporation.
PC Direct is a trademark of Ziff Communications Company and is used

by IBM Corporation under license.
Pentium, MMX, ProShare, LANDesk, and ActionMedia are trademarks or

registered trademarks of Intel Corporation in the U.S. and other
countries.
UNIX is a registered trademark in the United States and other

countries licensed exclusively through X/Open Company Limited.
Other company, product, and service names may be trademarks or

service marks of others.

REDB$BIB SCRIPT
Appendix M. Related Publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
M.1 International Technical Support Organization Publications

For information on ordering these ITSO publications see “How to Get ITSO
Redbooks” on page 267.
• VTAM V4R4 for MVS/ESA Implementation Guide , SG24-2100
• VTAM in a Parallel Sysplex Environment , SG24-2113
• Inside APPN - The Essential Guide to the Next-Generation SNA , SG24-3669-03
• VTAM APPN Handbook , SG24-4823
• Subarea to APPN Migration: HPR and DLUR Implementation , SG24-5204
(planned for publication in spring 1998)
• Managing Your APPN Environment Using NetView , GG24-2559
• Dynamic Subarea and APPN Management Using NetView V3R1 , SG24-4520
M.2 Redbooks on CD-ROMs

Redbooks are also available on CD-ROMs. Order a subscription and receive
updates 2-4 times a year at significant savings.
CD-ROM Title Subscription Collection Kit

Number Number
System/390 Redbooks Collection SBOF-7201 SK2T-2177
Networking and Systems Management Redbooks Collection SBOF-7370 SK2T-6022
Transaction Processing and Data Management Redbook SBOF-7240 SK2T-8038
Lotus Redbooks Collection SBOF-6899 SK2T-8039
Tivoli Redbooks Collection SBOF-6898 SK2T-8044
AS/400 Redbooks Collection SBOF-7270 SK2T-2849
RS/6000 Redbooks Collection (HTML, BkMgr) SBOF-7230 SK2T-8040
RS/6000 Redbooks Collection (PostScript) SBOF-7205 SK2T-8041
RS/6000 Redbooks Collection (PDF Format) SBOF-8700 SK2T-8043
Application Development Redbooks Collection SBOF-7290 SK2T-8037
M.3 Other Publications

These publications are also relevant as further information sources:
• SNA Formats , GA27-3136-16
• eNetwork Communications Server for OS/390 SNA Network Implementation
Guide , SC31-8563
• eNetwork Communications Server for OS/390 SNA Resource Definition
Reference , SC31-8565
• eNetwork Communications Server for OS/390 SNA Resource Definition
Samples , SC31-8566
• eNetwork Communications Server for OS/390 SNA Operation , SC31-8567
• eNetwork Communications Server for OS/390 SNA Planning and Migration
Guide , SC31-8622

REDB$BIB SCRIPT
• eNetwork Communications Server for OS/390 SNA Diagnosis , LY43-0079

(available to IBM-licensed customers only)
• eNetwork Communications Server for OS/390 SNA Customization , LY43-0110
(available to IBM-licensed customers only)
The latest online information on eNetwork Communications Server for OS/390

may be found on the Web at the following address:
http://www.software.ibm.com/enetwork/commserver/about/csos390.html

How to Get ITSO Redbooks
This section explains how both customers and IBM employees can find out about ITSO redbooks, CD-ROMs,
workshops, and residencies. A form for ordering books and CD-ROMs is also provided.
This information was current at the time of publication, but is continually subject to change. The latest
information may be found at http://www.redbooks.ibm.com/.
How IBM Employees Can Get ITSO Redbooks

Employees may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and information about
redbooks, workshops, and residencies in the following ways:
• PUBORDER — to order hardcopies in United States
• GOPHER link to the Internet - type GOPHER.WTSCPOK.ITSO.IBM.COM
• Tools disks
To get LIST3820s of redbooks, type one of the following commands:
TOOLS SENDTO EHONE4 TOOLS2 REDPRINT GET SG24xxxx PACKAGE
TOOLS SENDTO CANVM2 TOOLS REDPRINT GET SG24xxxx PACKAGE (Canadian users only)
To get BookManager BOOKs of redbooks, type the following command:
TOOLCAT REDBOOKS
To get lists of redbooks, type the following command:
TOOLS SENDTO USDIST MKTTOOLS MKTTOOLS GET ITSOCAT TXT
To register for information on workshops, residencies, and redbooks, type the following command:
TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ITSOREGI 1998
For a list of product area specialists in the ITSO: type the following command:
TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ORGCARD PACKAGE
• Redbooks Web Site on the World Wide Web
http://w3.itso.ibm.com/redbooks/
• IBM Direct Publications Catalog on the World Wide Web
http://www.elink.ibmlink.ibm.com/pbl/pbl
IBM employees may obtain LIST3820s of redbooks from this page.
• REDBOOKS category on INEWS
• Online — send orders to: USIB6FPL at IBMMAIL or DKIBMBSH at IBMMAIL
• Internet Listserver
With an Internet e-mail address, anyone can subscribe to an IBM Announcement Listserver. To initiate the
service, send an e-mail note to announce@webster.ibmlink.ibm.com with the keyword subscribe in the body of
the note (leave the subject line blank). A category form and detailed instructions will be sent to you.
Redpieces
For information so current it is still in the process of being written, look at ″Redpieces″ on the Redbooks Web
Site ( http://www.redbooks.ibm.com/redpieces.html). Redpieces are redbooks in progress; not all redbooks
become redpieces, and sometimes just a few chapters will be published this way. The intent is to get the
information out much quicker than the formal publishing process allows.

How Customers Can Get ITSO Redbooks
Customers may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and information about
redbooks, workshops, and residencies in the following ways:
• Online Orders — send orders to:
IBMMAIL Internet
In United States: usib6fpl at ibmmail usib6fpl@ibmmail.com
In Canada: caibmbkz at ibmmail lmannix@vnet.ibm.com
Outside North America: dkibmbsh at ibmmail bookshop@dk.ibm.com
• Telephone orders
United States (toll free) 1-800-879-2755

Canada (toll free) 1-800-IBM-4YOU
Outside North America (long distance charges apply)

(+45) 4810-1320 - Danish (+45) 4810-1020 - German
(+45) 4810-1420 - Dutch (+45) 4810-1620 - Italian
(+45) 4810-1540 - English (+45) 4810-1270 - Norwegian
(+45) 4810-1670 - Finnish (+45) 4810-1120 - Spanish
(+45) 4810-1220 - French (+45) 4810-1170 - Swedish
• Mail Orders — send orders to:
I B M Publications I B M Publications IBM Direct Services

Publications Customer Support 144-4th Avenue, S.W. Sortemosevej 21
P.O. Box 29570 Calgary, Alberta T2P 3N5 DK-3450 Allerød
Raleigh, NC 27626-0570 Canada Denmark
USA
• Fax — send orders to:
United States (toll free) 1-800-445-9269

Canada 1-403-267-4455
Outside North America (+45) 48 14 2207 (long distance charge)
• 1-800-IBM-4FAX (United States) or (+1)001-408-256-5422 (Outside USA) — ask for:

Index # 4421 Abstracts of new redbooks
Index # 4422 IBM redbooks
Index # 4420 Redbooks for last six months
• Direct Services - send note to softwareshop@vnet.ibm.com
• On the World Wide Web
Redbooks Web Site http://www.redbooks.ibm.com/
IBM Direct Publications Catalog http://www.elink.ibmlink.ibm.com/pbl/pbl
• Internet Listserver
With an Internet e-mail address, anyone can subscribe to an IBM Announcement Listserver. To initiate the
service, send an e-mail note to announce@webster.ibmlink.ibm.com with the keyword subscribe in the body of
the note (leave the subject line blank).
Redpieces
For information so current it is still in the process of being written, look at ″Redpieces″ on the Redbooks Web
Site ( http://www.redbooks.ibm.com/redpieces.html). Redpieces are redbooks in progress; not all redbooks
become redpieces, and sometimes just a few chapters will be published this way. The intent is to get the
information out much quicker than the formal publishing process allows.

IBM Redbook Order Form
Please send me the following:
Title Order Number Quantity
First name Last name
Company
Address
City Postal code Country
Telephone number Telefax number VAT number
• Invoice to customer number
• Credit card number
Credit card expiration date Card issued to Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.
How to Get ITSO Redbooks 269

List of Abbreviations
ACF/VTAM Advanced Communication FQPCID Fully Qualified Procedure
Function / Virtual Correlated IDentifier
Telecommunications Access
GDS Generalized Data Stream
Method
HPDT High Peformance Data
ACF/NCP Advanced Communication
Transfer
Function / Network Control
Program HPR High-Performance Routing
ANNC APPN Node to Node IBM International Business

Connection Machines Corporation
ANR Automatic Network Routing IC-TG InterChange Transmission

Group
APAR Authorized Programming
Analysis Report ICN InterChange Node
APPC Advanced Program to INN Intermediate Network Node

Program Communication ISR Intermediate Session Routing
APPN Advanced Peer to Peer ITSO International Technical
Networking Support Organization
ARB Adaptive Rate-Based LAN Local Area Network
ATM Asynchronous Transfer Mode LEN Low Entry Networking
BF-TG Boundary Function LFSID Local-Form Session IDentifier
Transmission Group
LU Logical Unit
BXN Branch Extender Node
MAC Media Access Control
CDRM Cross Domain Resource
Manager MDH Migration Data Host
CDS Central Directory Server MLTG MultiLink Transmission Group
CMC Communications MNPS MultiNode Persistent

Management Configuration Sessions
CM/2 Communications Manager/2 MPC MultiPath Channel
CNN Composite Network Node MVS Multiple Virtual Storage
COS Class Of Service MVS/ESA Multiple Virtual Storage /

Enterprise Systems
CP Control Point Architecture
CS/2 Communications Server/2 NCP Network Control Program
CS OS/390 eNetwork Communications NCE Network Connection Endpoint
Server for OS/390
NHDR Network layer HeaDeR
CTC Channel To Channel
NetID Network Identifier
CV Control Vector
NLP Network Layer Packet
DLC Data Link Control
NN Network Node
DLU Destination Logical Unit
NNS Network Node Server
DLUR/S Dependent LU Requester /
Server NTRI NCP Token-Ring Interface
EBN Extended Border Node OLU Origin Logical Unit
EN End Node OS/2 Operating System / 2
ESCON Enterprise Systems OS/390 Operating System / 390

CONnection OSA Open Systems Adapter
FID Format IDentifier PBN Peripheral Border Node
FMH Function Management Header PC Personal Computer

PIU Path Information Unit TH Transmission Header
PLU Primary Logical Unit THDR Transport layer HeaDeR
PS/2 Personal System/2 TIC Token-ring Interface Coupler
PU Physical Unit TP Transmission Priority
RSCV Route Selection Control TRL Transport Resource List
Vector
TRLE Transport Resource List
RTP Rapid Transport Protocol Element
SATF Shared Access Transport TRS Topology and Routing
Facility Services
SDLC Synchronous Data Link TSO Time Sharing Option
Control
VM/ESA Virtual Machine / Enterprise
SLU Secondary Logical Unit Systems Architecture
SNA Systems Network VN Virtual Node
Architecture
VR Virtual Route
SNI SNA Network Interconnection
VR-TG Virtual Route-based
SSCP System Services Control Transmission Group
Point
VTAM Virtual Telecommunications
TDB Topology DataBase Access Method
TDU Topology Database Update XCA External Communications
Adapter
TCID Transport Connection
IDentifier XCF Cross-system Coupling
Facility
TG Transmission Group
XID EXchange IDentifier

Index
Advanced Peer-to-Peer Networking (continued)
Numerics topology 13, 121, 128
2210 29, 52, 129 topology database 33
2216 29, 42, 52, 63, 129 transmission group 7
3174 21, 29, 30, 69, 116, 144, 193 transmission priority 15
3746-9X0 28, 34 ANNC 16, 40, 96, 113
APPN
See Advanced Peer-to-Peer Networking
A APPN multiple network connectivity
adaptive rate-based flow and congestion control 11
and class of service 121
adjacent cluster tables 51, 119
and connection network 53, 118
adjacent node CP name change 29, 141, 148
and HPR 118
adjacent SSCP table 54, 55, 155
and resource registration 128
ADJLIST 56, 156
and route calculation 121
Advanced Peer-to-Peer Networking
and VR-TG 128
and SSCP takeover 141
benefits and disadvantages 128
auto-active switched connections 45
compared with branch extender node 128, 129
BF-TG 7
conversion from SNI 50
central directory server 12, 27, 46, 128, 154, 161
COS mapping 169
class of service 14, 15, 36, 121, 169
COS mapping table 121
class of service selection 38
description 49, 115
connection network 52
extended border 50, 116
control point 8
extended border node 6, 29, 115
conversion of multipath channel 96
implementation example 116
CP names 30
node types and border types 49, 115
CP-CP sessions 8
overview 6
defining adjacent CPs 44
peripheral border 49, 116
definition reduction 25, 112
peripheral border node 6, 27, 28, 115
dependent LU support 9
same-NetID boundary 51, 116
directory 12, 46
searching 155
directory entry 154
subnetting 50
domain 7
APPNCOS parameter on mode entry 38
end node 5
APPNTOSA COS mapping table 172
entry point 190
APPNTOSA VTAMLST member 38
focal point 190
AS/400 21
mode to COS resolution 169
automatic network routing 4, 10
multipath channel 40, 96
multiple domain support 191
network design 26, 29, 139 B
network management 189 bibliography 265
network node 5 BIND rerouting 162
network node server 15 border node
node roles 26, 43 See APPN multiple network connectivity
node to node connection 16, 40, 96, 113 boundary function TG 7
overview 3 branch extender node 7, 52, 128
resource registration 12, 47, 99 BSC 3270 28, 108, 160, 183, 186
route calculation 14, 121, 161
search algorithm 154
search algorithm in combined APPN/subarea C
network 155 central directory server 12, 27, 46, 128, 154, 161
searching 12, 53, 56, 106, 120, 154 class of service 15, 171
session establishment 17 See also Advanced Peer-to-Peer Networking class
TG characteristics 14, 133, 139 of service
TG numbers 107 See also subarea class of service
TG profiles 37

CM/2 configuration 76, 81, 83 generalized data stream 17
CMC 5, 20, 26, 61, 182 generic resources 181
communications management configuration 5, 20,
26, 61, 182
Communications Manager/2 21, 68, 75, 80, 83, 144, H
194 high-performance data transfer 42, 63
Communications Server/2 21, 52, 86, 92, 117, 129, high-performance routing
144, 194 across an APPN border 118
Communications Server/NT 129 adaptive rate-based flow and congestion
composite network node 5, 6, 22, 26 control 11
composite network node routing 161 automatic network routing 10
configuration services exit 34, 35, 142, 145, 257 network layer packet 11
connection network 52 overview 4
control point 8 path switch 10
COSAPPN VTAMLST member 64 rapid transport protocol 10
CP-CP sessions 8 resource utilization 114
Cross-System Coupling Facility 63, 181 route setup 18
CS OS/390 1, 19 RTP connection 16
CS/2 configuration 87, 92 HPDT 42, 63
HPR
See high-performance routing
D
data host 5, 20, 26
definitions I
See VTAM definitions IBMTGPS VTAMLST member 37, 64
dependent LU 8, 9 IC-TG 8, 169, 175
dependent LU requester / server ICN 6
and APPN borders 50, 115, 117 independent LU 8, 9
and SSCP takeover 142 interchange node 6, 22, 26, 53, 61, 182
overview 9 interchange transmission group 8, 169, 175
subarea COS used 178 ISTADJCP major node 44
directory database ISTAPNCP 54, 155
See Advanced Peer-to-Peer Networking directory ISTAPNPU 153
displays ISTINCLM 167, 171, 174, 177, 178
See VTAM displays ISTTRL major node 41
DLUR/S
See dependent LU requester / server
domain 7
L
LEN
dynamic definition of switched resources 35
See low entry networking
DYNPU keyword 35
LFSID 3, 16
local format session identifier 3, 16
E low entry networking
end node 5 checking switched connections 34
eNetwork Communications Server for OS/390 1, 19 conversion to APPN 43
extended BIND 160 overview 4
extended border node 6 resource definition requirement 47
restrictions 9
F
FID2 11 M
FID4 11 MDH 5
FID5 11 migration data host 5, 22, 26, 53, 95, 182
FQPCID 16 mode table entry 38
mode to COS resolution 167, 171, 178
multilink TGs 7
G multinode persistent sessions 181
GDS 17 multipath channel 39, 40

multiple domain support 191 subarea networking
adjacent SSCP table 152
and independent LUs 8
N blank COS 172
naming conventions 30 CDRSC definitions 151
NCE 16 class of service 167
NCP definitions for FID2 channel connection 110 control sessions 8
NCP FID2 channel connection 109 domain 7
NCP resource utilization 43, 114 LEN and APPN resource representation 153
NetView display of CP-CP sessions 73 mode to COS resolution 167
NetView display of dependent LU session across multipath channel 39, 96
APPN 107 overview 3
NetView displays for session with VR-TG 138 requirement for VR-TG 133
NetView displays for session without VR-TG 135 routing decision, subarea versus LEN 153
NetView Graphic Monitor 193 search algorithm 152
NetView in an APPN network 192 search algorithm in combined APPN/subarea
NetView Performance Monitor 193 network 155
network connection endpoint 16 searching 53, 56, 106, 151
network layer packet 10, 11 transmission group 7
network management vector transport 189 type 4 node 3
network node 5 type 5 node 3
network node server 15 sysplex 181
NMVT 189 system services control point 3, 8
nonactivation XID3 29, 141, 142
T
P TCID 16
Parallel Sysplex 181 TG numbers 107
parallel TGs 7 topology
peripheral border node 6 See Advanced Peer-to-Peer Networking topology
topology database 13, 33
transmission group 7, 14
R transmission group characteristics
rapid transport protocol 4, 10, 16
See Advanced Peer-to-Peer Networking TG
REGISTER keyword 99
characteristics
route selection control vector 17
transport connection identifier 16
route setup 18
transport resource list 40
RSCV 17
TRL major node 40
RSCV pruning 139
type 2 node 8
type 2.1 node 3, 4, 7, 8, 43
type 4 node 3
S type 5 node 3
SAMAP VTAMLST member 163
SATOAPPN COS mapping table 172
SATOAPPN VTAMLST member 38
searching
V
virtual route-based transmission group 8, 96, 114,
See Advanced Peer-to-Peer Networking searching
128, 131, 139
See subarea searching
VTAM
self-defining dependent LU exit 142
APPN connection to NCP 109
session services extensions 16, 28, 48, 99, 117, 171,
APPN COS table 64
173
APPN-related commands 203
SNI 50, 128, 138
COS mapping tables 38, 172, 179
SSCP 3, 8
CP-CP session priority 65
SSCP takeover 29, 141, 160
data sets 64
SSCP-SSCP sessions 8
node types in a mixed APPN/subarea network 195
start options
resource represntation 153
See VTAM start options
routing in mixed APPN/subarea networks 161
subarea matching 162
subarea COS for CP-CP sessions 178
subarea/APPN routing decision 151
Index 275
VTAM (continued) VTAM displays (continued)
TG profiles 64, 134 APPN topology 67, 68, 79, 82, 84, 134
topology agent 193 APPN topology with VR-TG 137
topology and directory checkpointing 64 APPN-related start options 66, 102
using DISPLAY commands in APPN networks 191 BN-related start options 123
VARY command in APPN networks 192 CP name invalid 31
VTAM definitions dynamic CDRSC definition failure 45
adjacent cluster table 52, 120 dynamic CDRSC major node 91
adjacent CP major node 45, 256 EN initialization 110
adjacent SSCP table 54, 235 LEN link station 68, 69, 83
adjacent SSCP tables 210 MDH initialization 101
ANNC link station 98, 247, 250 NN servers for EN 105
APPN channel link station to NCP 254 subarea routes 101, 104
APPN link station for network border 122 topology for border node 123, 125
APPN link station for same=NetID border 122 TSO as remote APPN LU 106
CA major node for APPN connection 109 VARY REL for SSCP takeover 147
CDRM major node 210, 235, 247, 249 VR-TG activation 137
CDRM major node with VR-TG 133 VTAM end node from itself 111
CDRSC major node 210 VTAM start options
configuration list 208, 233, 246, 249, 254 APPN-related options 197
COS mapping tables 172 APPNCOS 36, 63, 179
local non-SNA 3174 234 BN 50, 119
local SNA 3174 211 BNDYN 51, 119, 129
mode table 239 BNORD 51, 119, 161
mode table with APPN COS entries 172 CDRSCTI 55
model major node for configuration services CDSERVR 46, 62
exit 241 CDSREFER 46
multipath channel connections 40 CONNTYPE 43, 62, 65, 69, 95
NCP 215, 224, 252 converting CMC to ICN 62
network node server list 48, 99 converting data host to MDH 95
path tables 209, 236 CPCP 43, 63, 96
SDLC-attached 3174 71 DIRSIZE 46, 63
SDLC-attached CS/2 gateway 87 DIRTIME 46
start options 208, 233, 244, 248, 253, 255 DYNADJCP 44, 63, 96
subarea channel link to NCP 256 DYNDLGMD 167, 177, 178
subarea connection to NCP 235 DYNLU 44
subarea mapping table 163 DYNMODTB 167, 177, 178
subarea MPC connection 211, 234 for SSCP takeover 145
switched APPN connection 76, 83 HOSTSA 63, 96, 109
switched LEN connection 81 HPR 63, 96
switched major node for 3174 212 HPRNCPBF 162, 185
switched major node for AS/400 214 INITDB 46, 64
switched major node for CM/2 213 ISTCOSDF 36, 171, 179
TG profiles 37 NETID 51
transmission group profiles 237 NODETYPE 63, 96
transport resource list 40, 98 SNVC 51, 119, 129
transport resource list for ANNC 250 SORDER 54, 63, 96, 113, 156, 160
transport resource list for MPC 247 SRCHRED 56
VTAM displays SRCOUNT 56
active MPC TRLE 103 SRTIMER 56
adjacent APPN CP 72, 80, 85 SSCPNAME 63
adjacent APPN NN 91 SSCPORD 55, 152, 156, 161
adjacent cluster table 124, 126, 127 SSEARCH 55, 156, 159, 161
adjacent SSCP 100 summary of APPN-related options 56
adjacent SSCP table 54 VFYRED 154
adjacent VTAM CP and SSCP 103 VRTG 96, 133
ANNC activation 102 VRTGCPCP 133, 139
APPN link station 32, 45, 73, 90 XNETALS 51, 122

ITSO Redbook Evaluation
Subarea to APPN Migration: VTAM and APPN Implementation
SG24-4656-01
Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this
questionnaire and return it using one of the following methods:
• Use the online evaluation form found at http://www.redbooks.ibm.com
• Fax this form to: USA International Access Code + 1 914 432 8264
• Send your comments in an Internet note to redbook@us.ibm.com
Which of the following best describes you?

• Customer • Business Partner • Independent Software Vendor • IBM employee
• None of the above
Please rate your overall satisfaction with this book using the scale:
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction ____________
Please answer the following questions:
Was this redbook published in time for your needs? Yes____ No____
If no, please explain:

_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
What other redbooks would you like to see published?

_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
Comments/Suggestions: ( THANK YOU FOR YOUR FEEDBACK! )

_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________

Subarea to APPN Migration: VTAM and APPN Implementation SG24-4656-01
Printed in the U.S.A.
IBML
SG24-4656-01

Sg244656 VTAM Subarea To APPN

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sg244656 VTAM Subarea To APPN

Uploaded by

Copyright:

Available Formats

IBML

Subarea to APPN Migration:

International Technical Support Organization

Subarea to APPN Migration:

Second Edition (May 1998)

This edition applies to OS/390 Version 2, Release 5, Program Number 5647-A01.

Comments may be addressed to:

Chapter 2. Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 3. Planning for Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Chapter 4. Migrating a CMC Host to ICN . . . . . . . . . . . . . . . . . . . . . . 61

 Copyright IBM Corp. 1996 1998 iii

Chapter 5. Migrating a Data Host to an MDH or a Pure EN . . . . . . . . . . . 95

Chapter 6. Border Node Support . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Chapter 7. VR-Based TG Implementation . . . . . . . . . . . . . . . . . . . . . 131

Chapter 8. SSCP Takeover in a Combined Subarea and APPN Network . . . 141

Chapter 9. Searching and Routing in a Mixed Subarea/APPN Network . . . 151

iv Subarea to APPN Migration: VTAM and APPN Implementation

Chapter 10. Logmode and COS Resolution in a Mixed Network . . . . . . . 167

Chapter 11. Sysplex Considerations . . . . . . . . . . . . . . . . . . . . . . . . 181

Chapter 12. Management of a Combined Network . . . . . . . . . . . . . . . . 189

Appendix A. VTAM Node Types . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Appendix B. VTAM APPN and APPN-Related Start Options . . . . . . . . . . 197

Appendix C. VTAM APPN Commands . . . . . . . . . . . . . . . . . . . . . . . 203

Appendix D. VTAM Subarea Initial Definitions . . . . . . . . . . . . . . . . . . 207

Appendix F. VTAM Definitions with RAA as ICN . . . . . . . . . . . . . . . . . 243

Appendix H. VTAM Definitions with RAA as ICN and RAS as EN . . . . . . . 251

Appendix I. Additional Definitions for SSCP Takeover . . . . . . . . . . . . . 255

Appendix J. Configuration Services Exit . . . . . . . . . . . . . . . . . . . . . 257

Appendix K. New Function Added by APARs . . . . . . . . . . . . . . . . . . 261

Appendix L. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Appendix M. Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . 265

How to Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

ITSO Redbook Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

vi Subarea to APPN Migration: VTAM and APPN Implementation

The Team That Wrote This Redbook

Chapter 9, Chapter 10, and Chapter 11 are based on presentations developed

Chapter 12 is based on a presentation created by:

The authors of the first edition of the redbook were:

 Copyright IBM Corp. 1996 1998 vii

We want our redbooks to be as helpful as possible. Please send us your

viii Subarea to APPN Migration: VTAM and APPN Implementation

HPR improves reliability by switching sessions to alternate paths, if they are

1.1 Scope and Objectives

 Copyright IBM Corp. 1996 1998 1

Some connections in a subarea network may never become APPN-capable;

1.2 APPN Terminology and Functionality

1.2.1 Types of SNA Network

2 Subarea to APPN Migration: VTAM and APPN Implementation

A subarea node is an ACF/VTAM or ACF/NCP node acting as a traditional SNA

Subarea networking uses an addressing scheme that consists of a subarea

A subarea network may be divided into independent subnetworks which are

1.2.1.2 APPN Networking

Some of the benefits of APPN include:

APPN nodes use local-form session identifiers (LFSIDs) instead of subarea

1.2.1.3 Low Entry Networking

1.2.1.4 High-Performance Routing

1.2.2 Types of SNA Node

4 Subarea to APPN Migration: VTAM and APPN Implementation

1.2.2.2 Data Host

1.2.2.3 Network Node

1.2.2.4 End Node

The EN may have active connections to multiple adjacent network nodes;