I
International Technical Support Centers
Ah inTroaucTion to Advanced Progrom-to-Program Communication (APPC)
GG24>i584-01 AN INTRODUCTION TO ADVANCED PROG RAM-TO-PROG RAM COMMUNICATION (APPC)
Document Number GG24-1584-1
November 1986
International Technical Support Center Raleigh, North Carolina, USA SECOND EDITION (NOVEMBER 1986) This edition, 6G24-1584-1, is a major revision of the previous edition, 6G24-15^-0, and obsoletes that edition. 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 program product in this document'is not intended to state or imply that only IBM's program product may be used. Any functionally equivalent program may be used instead. A form for readers' comments is provided at the back of this publication. If the form has been removed, comments may be addressed to IBM Corpo ration, International Technical Support Center - Raleigh, Dept. 985C, B622-3, P. 0. Box 12195, Research Triangle Park, NC 27709. IBM may use or distribute whatever information you supply in any way it believes appropriate without incurring any obligation to you.
(C) Copyright International Business Machines Corporation 1986
Introduction to APPC ABSTRACT
This document provides an introduction to APPC, IBM's architecture for distributed transaction processing. The document looks at the requirements for APPC, provides an overview of the underlying logical unit (LU 6.2), and describes the LU 6.2 protocol boundary whereby transaction programs invoke APPC functions. Some references to product implementations are provided, to illustrate the architectural concepts. There is also an overview of the Type 2.1 node, which allows SNA networking of small systems sup porting APPC. The document is intended for the general reader with an interest in communications and a working knowledge of SNA. References are provided for further reading on the subjects covered. MISC (90 pages)
Abstract iii ACKNOWLEDGMENTS
Author:
Gerard Joseph, IBM Australia Project Advisors: Peter Russell (1st edition). International Technical Support Center - Raleigh Manuel Ibarguchi (2nd edition). International Technical Support Center - Raleigh Acknowledgments are due to the staff of the International Technical Support Center, Raleigh, and also to several SNA architects, including Jim Gray, Mark Pozefsky, Bill Bergman, Booth Kalmbach, John Wilder, Gary Schultz, Marsha Ferree, Bob Sundstrom, and Jim Baker, for their assistance and cooperation. Assistance in producing the second edition was provided by Jack Sanders, Mike Murphy, Lee Rafalow, and John Wilder, and is gratefully acknowledged.
Acknowledgments PREFACE
PURPOSE
This document is intended for personnel with communications interests. It provides an introduction to Advanced Program-to-Program Communication (APPC), a set of interprogram communication services provided by LU 6.2 to support distributed transaction processing. This document should equip the reader with the necessary architectural knowledge to become familiar with the program-to-program facilities of products implementing APPC. As such, it is not a guide to any particular product implementations of APPC. The reader is referred to the appropriate product documentation for such guidance. At the time of writing, the following announced IBM products make use of APPC:
CICS/VS IBM System/38 IBM System/36 IBM Personal Computer (APPC/PC) IBM Series/1 (RPS V7.1) IBM Scanmaster I IBM Displaywriter System (Electronic Document Distribution) IBM 5520 (5611-SS2 R3) IBM 8100 (DPPX/SP R3) IBM 3820 Page Printer IBM Local Area Network (LAN) PrintManager Program IBM System/88 The above list is limited to products implementing LU 6.2. There are many additional programs that run in conjunction with one or the other of the above products and use the architected interface provided by the underlying product, in some cases implementing, in turn, higher-level SNA architec tures. An example is DISOSS/370, which uses the LU 6.2 interface provided by CICS/VS, and in turn, implements the DIA and SNADS architectures. Similar examples are the Personal Services products on the System/36 and System/38.
Product references in this document are for illustrative purposes, to expand on the descriptions of the APPC architecture that form the basis of this book. This document, as well as the other related SNA publications, contain ideas and concepts intended to be used to understand, develop, or adapt products and programs for attachment to SNA networks.
It is assumed that the reader is familiar with the basic concepts of SNA as presented, for example, in Systems Network Architecture Concepts and Products (GC30-3072).
HOW THIS BULLETIN IS ORGANIZED
• Chapter 1, "Background and Rationale", establishes the requirement for APPC in the distributed processing context, and gives a brief overview of its main functions.
Preface vii Chapter 2, "APPC Functions and LU 6.2", describes APPC in somewhat greater depth, along with some details of LU 6,2. Chapter 3, "LU 6.2 Protocol Boundary", describes the generic pro gramming interface provided by LU 6.2. Chapter 4, "LU 6.2 Session Protocols and Flows", introduces the session protocols and flows associated with APPC. "Appendix A. T2.1 Node Overview", describes the SNA path control support for APPC in networks of small systems. "Appendix B. Summary of APPC Products", summarizes the APPC facil ities implemented by various products.
PREREQUISITE PUBLICATION
Systems Network Architecture Concepts and Products (GC30-3072)
RELATED PUBLICATIONS
SNA PUBLICATIONS
Systems Network Architecture Transaction Programmer's Reference Manual for LU Type 6.2 (GC30-3084) Short title: SNA Transaction Programmer's Reference Manual
Systems Network Architecture Format and Protocol Reference Manual: Architecture Logic for LU Type 6.2 (SC30-3269) Short title: PAP Manual: LU 6.2
Systems Network Architecture Format and Protocol Reference Manual: Distribution Services (SC30-3098) Short title: FAP Manual: Distribution Services
Systems Network Architecture Technical Overview (GC30-3073)
Systems Network Architecture Reference Summary (GA27-3136) Short title: SNA Reference Summary
IBM SDLC General Information (GA27-3093)
SNA Format and Protocol Reference Manual: Architecture Logic for Type 2.1 Nodes (SC30-3422)
OTHER PUBLICATIONS ON APPC ARCHITECTURE
Advanced Program-to-Program Communication in SNA (IBM Systems Journal, Vol. 22, No. 4, 1983, 298-318; Reprint Order No. G321-5197) viii Introduction to APPC SNA Distribution Services (IBM Systems Journal, Vol. 22, No. 4, 1983, 319-343; Reprint Order No. G321-5198)
Advanced Architectures APPC, SNADS, DIA and DCA (GG22-9105) The Office Information Architectures: Concepts (GC23-0765)
Document Interchange Architecture: Concepts and Structures (SC23-0759)
PRODUCT PUBLICATIONS
Some references to IBM product publications are given in "Appendix B. Summary of APPC Products". Complete information on such publications is provided in the formal product announcements.
TECHNICAL BULLETINS
A number of books on specific APPC products are published from time to time by various IBM Technical Support Centers and, in some cases, may be shipped automatically to customers with appropriate System Library Subscription Service (SLSS) profiles. Consult your IBM representative for further information.
TERMINOLOGY
Because of the prevalence of the term "transaction program" in the APPC context, the abbreviation TP is often used, rather than with the perhaps more familiar meaning of "teleprocessing".
The nomenclature TYPE X, or TX, is used to denote the various SNA node types (x = 1, 2.0, 2.1, 4, 5) rather than the older expressions (PU Type X, PU_Tx, and so on). A distinction between ARCHITECTURE (an abstract design) and IMPLE MENTATION (a product conforming to the architecture) is assumed throughout this document.
Preface ix TABLE OF CONTENTS
1.0 BACKGROUND AND RATIONALE 1 1.1 Distributed Processing and Connectivity 1 1.1.1 Connectivity Under SNA 1 1.1.2 Logical Units 2 1.1.3 LU Types 3 1.2 LU 6.1: Intersystem Communication 4 1.3 LU 6.2: Concepts of APPC 5 1.3.1 Conversations 5 1.3.2 The LU 6.2 Protocol Boundary 6 1.3.3 Multiple and Parallel Sessions 7 1.3.4 Peer Communication 8 1.3.5 Resource Synchronization 8 1.3.6 SNA-Defined Transaction Programs 8 1.3.7 LU 6.2 as a Subsystem 9 1.4 Path Control Support: The T2.1 Node 9 1.5 Implementation of APPC 10 1.5.1 Function Sets 10 1.5.2 Layered Design 11 1.5.3 Performance Aspects 11 1.5.4 Implementation Uniformity 12 1.5.5 Documentation Requirements 12 1.5.6 Migration 12 1.6 Summary 12
2.0 APPC FUNCTIONS AND LU 6.2 15 2.1 Structure of LU 6.2 15 2.1.1 Presentation Services 15 2.1.2 Half-Session Layer 16 2.1.3 LU Services Manager 16 2.2 Distributed Transactions 18 2.2.1 Distributed Transaction Components 18 2.2.2 Data Structures 19 2.2.3 Base-Level Conversation Functions 21 2.2.4 Conversation Allocation 21 2.2.5 Conversation Types 22 2.2.6 Message Units 23 2.2.7 Transaction Program Types 24 2.3 Error Recovery 26 2.4 Parallel Sessions and CNOS 28 2.5 Synchronization Processing 30 2.5.1 Confirm 30 2.5.2 Syncpoint 30 2.5.3 Comparison of LU 6.2 Synchronization Levels 34 2.6 Other' Optional APPC Functions 35 2.6.1 Security 35 2.6.2 Mapped Conversation Options 37 2.6.3 PIP (Program Initialization Parameter) Data 38 2.6.4 Performance Options 38 2.7 System Programming 38
3.0 LU 6.2 PROTOCOL BOUNDARY 39 3.1 Introduction 39 3.2 Transaction Program Structure 39 3.3 Transaction Program Verb Execution 41 3.4 General Protocol Boundary Considerations 42 3.5 Conversation Verbs 44
Table of Contents xi 3.5.1 Basic Conversation Verbs 44 3.5.2 Type-1ndependent Conversation Verbs 46 3.5.3 Mapped Conversation Verbs 47 3.6 Control-Operator Verbs 48 3.6.1 CMOS Verbs 48 3.6.2 Session Control Verbs 49 3.6.3 LU Definition Verbs 50 3.7 Product Support Subsetting 51 3.7.1 Functions Sets Approach 51 3.7.2 Summary of the Base and Option Sets 51 3.7.2.1 Base Functions 51 3.7.2.2 Optional Functions 52 3.7.3 Remark on Connectivity 52 3.8 Sample Conversational Flows 53 3.8.1 One-Way Conversation without Confirmation 54 3.8.2 One-Way Conversation with Confirmation 55 3.8.3 Two-Way Conversation with Confirmation 56 3.8.4 Confirmation Processing 58 3.8.5 REQUEST_TO_SEND 59 3.8.6 Syncpoint Processing 60
4.0 LU 6.2 SESSION PROTOCOLS AND FLOWS 63 4.1 Session Protocols 63 4.1.1 Presentation Services Layer 63 4.1.1.1 General Data Stream (CDS) 63 4.1.1.2 Presentation Services Headers 63 4.1.2 Function Management Profile 64 4.1.3 Transmission Services Profile 65 4.1.4 Chain Usage 66 4.2 Sample Session Flows 66 4.2.1 One-Way Conversation without Confirmation 67 4.2.2 One-Way Conversation with Confirmation 68 4.2.3 Two-Way Conversation with Confirmation 69 4.2.4 Confirmation Processing 70 4.2.5 REQUEST_TO_SEND 71 4.2.6 Syncpoint Processing 72
APPENDIX A. T2.1 NODE OVERVIEW 73 A.I Link-Level Connectivity 73 A. 1.1 Data Link Controls 73 A. 1.2 DLC Activation 74 A. 1.3 Multiple Attachments 76 A.2 LU-LU Session Support 78 A.2.1 Session Capabilities 78 A.2.2 Transmission Header Usage 78 A.2.3 Addressing Mechanism 80 A.3 T2.1 Node Components 80
APPENDIX B. SUMMARY OF APPC PRODUCTS 83 B.I Open Implementations 83 B.1.1 CICS/VS 83 B.I.2 IBM System/38 84 B.I.3 IBM System/36 85 B.I.4 IBM Personal Computer 86 B.I.5 IBM Series/1 86 B.I.6 IBM System/88 86 B.2 Closed Implementations 87
ACRONYMS AND ABBREVIATIONS 89
xii Introduction to APPC LIST OF ILLUSTRATIONS
gure 1. Layering of SNA 2 gure 2. Logical View of an SNA Network 3 gure 3. Sessions and Conversations 6 gure 4. LU 6.2 Protocol Boundary gure 5. Concept of LU 6.2 Function Sets \ \ gure 6. Layering of LU 6.2 16 gure 7. Components of LU 6.2 . 17 gure 8. Distributed Inquiry Transaction 19 gure 9. Possible Distributed Transaction Structure 20 gure 10. LU 6.2 Conversation Protocol Boundary 23 gure 11. Conversation between Application Transaction Programs . 26 igure 12. Conversation between Application Transaction Program and Device 26 igure 13. Conversation between Service Transaction Programs ... 27 igure 14. Single and Parallel Sessions 29 igure 15. Syncpoint Exchanges 33 igure 16. Committed and Backout (Cascaded) Examples 34 igure 17. Committed and Backout (Non-Cascaded) Examples .... 35 igure 18. Components of the Syncpoint Option Set 36 igure 19. Comparison of Confirm and Syncpoint 36 igure 20. Example of Mapping between Product API and LU 6.2 Protocol Boundary 40 igure 21. General structure of a Transaction Program 40 Igure 22. Verb Execution 42 igure 23. Send and Receive Buffers 43 igure 24. One-Way Conversation without Confirmation 54 igure 25. One-Way Conversation with Confirmation 55 igure 26. Two-Way Conversation with Confirmation 56 igure 27. Confirmation Processing 58 igure 28. REQUEST_TO_SEND 59 igure 29. Syncpoint Processing :* 60 igure 30. Session Flow for One-Way Conversation without Confirmation 67 igure 31. Session Flow for One-Way Conversation with Confirmation 68 igure 32. Session Flow for Two-Way Conversation with Confirmation 69 igure 33. Session Flow for Confirmation Processing 70 igure 34. Session Flow for REQUEST_TO_SEND 71 igure 35. Session Flow for Syncpoint Processing 72 igure 36. Peer Attachment of T2.1 Nodes ••• 73 igure 37. SDLC Activation Sequence for a T2.1-T2.1 Connection 75 igure 38. Role Negotiation 76 igure 39. Example of SDLC Role Negotiation 76 igure 40. A Multiple-Link T2.1 Node 77 igure 41. Multipoint Configuration of T2.1 Nodes 77 igure 42. LU-LU Sessions Between T2.1 Nodes 78 igure 43. Session Activation and Deactivation Sequence ..... 79 igure 44. Conceptual Addressing Mechanism for T2.1-T2.1 Sessions 81
List of Illustrations XIII 1.0 BACKGROUND AND RATIONALE
This chapter explores the background to APPC, describes the requirements for APPC in the distributed processing context, and gives a brief overview of APPC's main functions.
1.1 DISTRIBUTED PROCESSING AND CONNECTIVITY
Advanced Program-to-Program Communication (APPC) has been designed to provide enhanced Systems Network Architecture (SNA) support for distrib uted processing. The latter term is used with a spectrum of meanings, but in the present context we define it as that of two or more processors com municating in the execution of a unit of processing. Such a unit is generally referred to as a TRANSACTION, so that the term COOPERATIVE (or DIS TRIBUTED) TRANSACTION PROCESSING describes the environment ad dressed by APPC.
Specifically, APPC describes the protocols used by programs in separate processors to communicate with each other in the execution of a (single) distributed transaction. Current growth trends, in particular the prolifer ation of intelligent workstations and small processors dependent on server functions provided by other (and different types of) processors, impose a requirement for distributed applications. Such applications, on the other hand, are more difficult to develop than "standalone" applications. The goal of APPC is to facilitate the development of distributed applications by pro viding a set of architecturally defined primitives that serve as a foundation for program-to-program communication, independent of the types of processors in which those programs run. In this sense, APPC assists in providing CONNECTIVITY among a wide va riety of devices and processors, and therefore, we can consider its place in the evolution of SNA.
1.1.1 CONNECTIVITY UNDER SNA
SNA has been IBM's strategic networking architecture since its announcement in 1974. Its evolution since then has served to increase the connectivity of conforming products. The announcement of multi-host support in 1976, including the ability of any terminal to access any host, is one well-known landmark ih that evolution. Connectivity, in general, implies the presence of compatible communication protocols. It also has a subjective element, referring to the ease of estab lishing useful connections. The layer model of SNA (see Figure 1) enables us to qualify the notion of connectivity by specifying a particular layer. For example, we might speak of "link-level connectivity" or "session-level connectivity". The ultimate connectivity goal is often expressed as "any-to-any" connectivity. A reasonable interpretation of this notion follows from the layer model: the existence of connectivity at each ascending layer through presentation services.
Background and Rationale 1 Appl1catIon Presentation Services (PS)
A Data Flow Control (DFC) - LU Half-Session Layer | V Transmission Control (TC) Path Control (PC) Data Link Control (DLC)
Physical
Figure 1. Layering of SNA: The [half-]sess1on layer comprises TC and DFC. LUs span the TC, DFC, and PS layers.
A logical view of SNA (refer to Figure 2) will further illustrate connectivity
1.1.2 LOGICAL UNITS
A LOGICAL UNIT (LU) is the end user's interface to an SNA network. LUs are attached to the path control network, which is responsible for addressing and routing data packets. Two LUs communicate over a SESSION, a logical connection established when one LU sends another an SNA request known as the BIND, which specifies the protocols that both partners agree to abide by for the duration of the session. The BIND sender and receiver are known respectively as the PRIMARY LU (FLU) and SECONDARY LU (SLU). LUs are housed in NODES (not pictured in Figure 2), which in traditional SNA networks are categorized as either: SUBAREA nodes, corresponding to hosts (TYPE 5 (T5) nodes) and 37x5 controllers (T4), which can route packets from one node to another; or PERIPHERAL nodes, corresponding to small processors, cluster controllers, and terminal devices (T2, sometimes T1), which depend on attachment to a subarea node providing BOUNDARY FUNCTION for all communication with other nodes. The path control network is implemented by the physical network of interconnected nodes and links. The layerihg of SNA enables changes to be made at different layers inde pendently. In practice, connectivity enhancements are generally classified as belonging to either the path control layer or the session layer. The multi-host support mentioned above is an example of a connectivity en hancement at the path control layer. Our discussion of APPC primarily concerns the session layer and the presentation services layer, though there is an associated path control element which we discuss in a later section of this chapter.
Introduction to APPC User
LU
User User
• Path Control • Network
1 LU SNA Network 1
LEGEND: •••• Session User
Figure 2. Logical View of an SNA Network
1.1.3 LU TYPES
To accommodate various often used sets of protocols, a number of LU SES SION TYPES (or LU TYPES) were developed. These LU types specify the session parameters within certain profiles, and fall into several categories: • Host-to-terminal LU types can be regarded as defining "generic de vices", so that the peculiarities of individual products are invisible at the session layer, thus reducing the cost of developing host applications for different terminal implementations. They include LU 1 (generic printer device with local resources such as keyboards and diskettes), LU 2 (3270 displays), LU 3 (3270 printers), LU 4 (similar to LU 1, but also supporting terminal-to-terminal communication), and LU 7 (5250 displays). Terminal LU types generally incorporate restrictive assumptions that reflect the asymmetry of host-to-terminal communication. For example, LU 2 assumes the host is always responsible for error recovery. • LU 0 allows products to implement session protocols that are not defined by SNA. Several IBM products, including NCCF (Network Communi cation Control Facility) and FTP (File Transfer Program), have used LU 0 to implement their own program-to-prog ram protocols.
• LU 6 is a program-to-program LU type, providing SNA-defined protocols for peer communication between programs.
Background and Rationale NOTE: A product can support several LU types, as exemplified by CICS/VS, which supports all except LU 7. In order for two LUs to BIND a session, both must support a common LU type, since the BIND request establishes the LU type for the session. Accordingly, any convergence of LU types increases session-level connectivity. In fact, LU 6.2 is now the base on which SNA support for distributed processing is evolving.
1.2 LU 6.1: INTERSYSTEM COMMUNICATION
LU 6.1 was implemented by CICS/VS and IMS/VS through a facility known as INTERSYSTEM COMMUNICATION (ISC). It succeeded LU 6.0, which was implemented only by CICS/VS, although a (non-compatible) version of it was implemented by the System/34 and later the System/36. ISC introduced several functions to support distributed transaction processing, including: •A transaction program interface by which a program requests services from the LU, such as: - initiating and terminating a connection to a remote transaction pro gram
- sending and receiving data - changing the direction of flow between the two programs • Use of parallel sessions between two LUs to support multithreading of transactions • Error notification and recovery • Commitment control: a special component of the LU assumed the re sponsibility of keeping protected resources (such as data bases) in synchronization across a distributed transaction, by committing changes to those resources (CICS Syncpoint) or backing out those changes (CICS Rollback). Resource synchronization is a critical factor in distributed application design. • Architected processes: on top of the LU 6.1 session protocols, ISC provided various distributed services for application programs. For example, the Scheduler Model allows a program in one LU to issue a request that initiates execution of a program in another LU. Other models provide transparent access to files, data bases, and queues. The concept of architecturally defined distributed services has been enhanced in LU 6.2, as described below under "SNA-Defined Transaction Programs" on page 8. • Peer communication between LUs and between transaction programs, that avoids the limitations and inflexibility of terminal LU types Since ISC was only implemented by CICS/VS and IMS/VS, its functions were limited to a host-to-host environment. Moreover, certain incompatibilities between the two implementations reduced the functionality of CICS-to-IMS communication as compared with communication between like systems. In particular, of the architected processes, only the Scheduler Model was available between CICS/VS and IMS/VS. Each of these limitations served
4 Introduction to APPC to mitigate connectivity. Each limitation was resolved in LU 6.2 architec ture, of which the first implementation was CICS/VS Version 1.6.
1.3 LU 6.2: CONCEPTS OF APPC
In this section we introduce LU 6.2, and describe in basic terms how it supports distributed transaction processing through APPC.
1.3.1 CONVERSATIONS
In its simplest terms, LU 6.2 provides for synchronous program-to-program attachment and conversational flows for as short or long a period of time as desired by the programs. (The term SYNCHRONOUS here refers to concurrent execution of the partner programs.)
In LU 6.2 parlance, two transaction programs communicate over a CON VERSATION, initiated when the invoking program requests the ALLOCATION of a conversation with a target program, that will be set in execution at a remote LU. The conversation will be allocated to an LU-LU session, though the trans action programs do not refer to a session in particular. The allocation re quest specifies a group of sessions defined by a MODE NAME, which is the program's view of the level of communication service it requires. A mode has a session-level component, mapping to certain parameter settings, and a path control component, mapping to a particular set of routing charac teristics, such as an SNA class of service (COS).
Conversations use a session serially (each conversation maps to an SNA bracket). This time-slicing of the session avoids the overhead of initiating a new session for each transaction. A conversation is DEALLOCATED by either partner, which then, frees the session for use by a new conversation. The contrast between sessions and conversations is shown in Figure 3. A conversation is typically a short-term connection, while a session is typically long-term, though this is not a design restriction.
Conversations couple transaction programs into distributed transactions. In the simplest case, this is a single conversation linking a pair of programs. In general, any (instances of) programs that are directly or indirectly linked by conversations are part of the same distributed transaction.
Conversations are classified as either MAPPED or BASIC. Mapped conver sations are intended for use by application transaction programs written in high-level languages, while basic conversations are used by service trans action programs that provide services to end users or to application trans action programs. Mapped conversations hide from the programmer the details of the underlying data stream used by LU 6.2, and may provide a DATA MAPPING, or formatting, service to increase the degree of data independence of the programs.
Background and Rationale Session
TP TP
LU LU Session
TP TP
LEGEND: •••• Conversation TP Transaction Program
Figure 3. Sessions and Conversations
1.3.2 THE LU 6.2 PROTOCOL BOUNDARY
Transaction programs interact with LU 6.2 via its PROTOCOL BOUNDARY, as illustrated in Figure 4. This protocol boundary is part of the SNA de finition of LU 6.2, and is specified by a set of VERBS that are documented in the SNA Transaction Programmer's Reference Manual. A verb corresponds to some LU 6.2 service requested by a transaction program. Examples are: ALLOCATE (a conversation), SEND_DATA, RECEIVE_AND_WAIT, REQUEST_TO_SEND, CONFIRM, and DEALLOCATE. The verbs define a complete set of primitives for interprogram communication that allows dis tributed transactions of arbitrary design and function to be written for LU 6.2.
The verbs are divided into categories according to the type of conversation they support (basic or mapped). A third category, the CONTROL-OPERATOR VERBS, is defined for use by suitably privileged programs that provide LU control functions. Other categories may be pro vided by SNA service transaction programs that provide functions for other transaction programs. An example of such a class of service transaction programs is SNADS (refer to "SNA-Defined Transaction Programs" on page 8). The verbs constitute a generic application program interface (API). They are a means of documenting LU 6.2 support of transaction programs, for the benefit of both distributed transaction programmers and LU 6.2 implemen tations. The manner in which the protocol boundary is implemented will vary from product to product. Products that expose an API equivalent to the protocol boundary do so in their programming languages. In CICS, for example, this is the command-level (EXEC) interface.
The protocol boundary distinguishes LU 6.2 from other LU types. For programmers, the verbs provide a common language for coding distributed transactions that involve disparate products (supporting, for example, dif-
ntroduction to APPC Transaction Program
Protocol Boundary
LU 6.2
Figure 4. LU 6.2 Protocol Boundary: The downward arrow indicates a verb issued by the transaction program, while the upward ar row indicates the resulting service provided by the LU. ferent programming languages). Programmers are thus relieved of the ne cessity of a detailed understanding of all the products involved in a distributed transaction. Each product that exposes an LU 6.2 API explains how the verbs map, or correspond, to its API, so that a distributed transaction coded using LU 6.2 verbs can be easily translated into the ap propriate API (s).
1.3.3 MULTIPLE AND PARALLEL SESSIONS
When the users of an SNA network are programs served by a transaction processing system, many pairs of programs may need to be connected si multaneously. LU 6.2 products that expose the conversation protocol boundary to user-written programs use multiple and parallel sessions to support multithreading of conversations between them. MULTIPLE sessions support refers to the ability to have multiple sessions with the same or different partner LU(s) concurrently. Those with the same partner LU are termed PARALLEL sessions; an example is pictured in Figure 3. Each session can carry one conversation at one time. The use of parallel sessions has a number of advantages over other multi threading approaches that have been used. By comparison with the Multiple LU (MLU) approach that was used by some products, parallel sessions are simpler to define and easier to manage. Where the path control network does not support parallel sessions (for example, between a peripheral node and a subarea nojde), the product may allow the definition of multiple LUs to achieve concurrency of transaction processing. This is done in the System/38 and IBM Personal Computer, for example.
Background and Rationale Parallel sessions support implies the presence of an architected mechanism for regulating the number of sessions between the partner LUs for each mode name. This is known as CNOS (Change Number Of Sessions), and is pro vided by a set of control-operator verbs of that name.
1.3.4 PEER COMMUNICATION
LU 6.2 assumes a peer relationship between session partners and between partners. This was the case with the earlier releases of lU 6, and with the terminal-to-terminal implementations of LU 4, but not with the host-to-terminal LU types. In particular, this implies that (with minor exceptions) LU 6.2 products can function as either primary LU (BIND sender) or secondary LU (BIND receiver). A similar symmetry applies to allocating conversations. Error recovery is always a shared responsibility.
1.3.5 RESOURCE SYNCHRONIZATION
LU 6.2 defines two levels of resource synchronization that help insure con sistency within a distributed transaction. CONFIRM enables the partner programs to synchronize their processing ac tivities. The LU's only involvement is to communicate the confirmation re quest and reply between the programs, any recovery action being a program-level responsibility. The higher level, SYNCPOINT, enables the programs to declare certain re sources as PROTECTED. In this case, the LU undertakes the responsibility of jnsuring the consistency of those resources across a distributed trans action, in response to syncpoint requests issued by the programs. In syncpoint processing the LU will either COMMIT (make permanent) or BACKOUT (reverse) changes to protected resources. When a failure occurs during syncpointing itself, resulting in some doubt as to the states of pro tected resources, a RESYNCHRONIZATION capability allows the partner LUs to subsequently exchange information on resource states and resolve the doubtful situation. Syncpoint is an optional APPC function (supported by CICS/VS, for exam ple), while Confirm is supported by all implementations.
1.3.6 SNA-DEFINED TRANSACTION PROGRAMS
An important eletrient of the connectivity picture is the provision of dis tributed SNA services. Such services increase uniformity and facilitate the development of distributed applications. The approach taken with LU 6.2 is to define such services separately from the LU itself, so they can be implemented on different products independ ently of one another. This differs from the LU 6.1 approach, where the architected models (File Model, DL/I Model, and so forth) were part of the definition of LU 6.1. With LU 6.2, distributed SNA services are provided
8 Introduction to APPC in the form of SNA-defined service transaction programs, that interface to LU 6.2 via the basic conversation level of the protocol boundary. A range of SNA-defined services that use LU 6.2 is already available. They include the following architectures: DOCUMENT INTERCHANGE ARCHITEC TURE (DIA), providing office-oriented functions relating to document interchange, SNA DISTRIBUTION SERVICES (SNADS), providing a general-purpose store-and-forward facility, and DISTRIBUTED DATA MAN AGEMENT (DDM), providing transparent access to remote data. A number of product-oriented service transaction programs perform appropriate func tions for the System/36, System/38, and the 3820 printer. Certain SNA-defined transaction programs perform internal LU control functions. For example, the CNOS transaction program interfaces to the LU control operator to regulate the number of sessions between two LUs, while the RESYNC transaction program performs Syncpoint resynchronization functions. Products have made provision for the LU 6.1 models to run on LU 6.2 in migration mode.
1.3.7 LU 6.2 AS A SUBSYSTEM
Prominent among the functions performed by LU 6.2 is that of resource management. LU 6.2 coordinates the access of transaction programs to various resources, including resources that are local to the LU, such as files, databases, and queues, and shared resources, such as the LU-LU session, to which access is provided through a conversation. In this sense, LU 6.2 fulfills the role of a subsystem, or logical "processor", providing an execution environment for transaction programs. Readers familiar with CICS/VS will appreciate this role of LU 6.2. The traditional view of an LU as a "port" into the SNA network is one aspect of the "subsystem" view. This latter view in turn leads to that of SNA itself as a "distributed operating system" for its loosely-coupled "processors" (LUs). Readers interested in this perspective are referred to the IBM Systems Journal paper Advanced program-to-program communication in SNA, listed in the preface under "Related Publications" on page viii. We can add to these remarks by observing that the protocol boundary con fers on LU 6.2 a uniqueness that characterizes it as an LU, not just an access to session protocols. LU 6.2 is thus qualitatively different than earlier LU types.
1.4 PATH CONTROL SUPPORT: THE T2.1 NODE
SNA subarea node products (such as VTAM and NOP) have for some years provided the requisite support for peer host-to-host communication between applications, including parallel sessions between two host LUs (such as GIGS and IMS). For small systems, however, peer communication has typically been provided through a variety of product-specific approaches, using subsets of SNA appropriate to their purposes. These implementations, which included the System/34, 8100, and 6670, tended to use incompatible path control subsets (in the form of different transmission header formats) or
Background and Rationale 9 incompatible subset of session protocols (for example, LU 4 and LU 6) so that communication was restricted to couplings of like products. With APPC, the need arose to network small systems on a uniform SNA foundation, without requiring the presence of a host. Otherwise expressed, the requirement was to provide small systems with a subset of the path control connectivity enjoyed by subarea networks. Small systems typically attach to subarea networks (via a boundary function node) as TYPE 2 (T2) peripheral nodes. Such nodes have limited commu nication capabilities (for example, an LU in a peripheral node is limited to a single session at one time, and the partner LU must reside in a host), and depend on the boundary function node for all message routing. How ever, this architecture has been enhanced to provide a common path control base for supporting APPC in small systems, resulting in the TYPE 2.1 (T2.1) node. The nature of this enhancement provides an easy migration path for existing T2 nodes. The T2.1 node, which is described in "Appendix A. T2.1 Node Overview", is designed for peer attachment, as illustrated in Figure 36 on page 73 and in Figure 42 on page 78. Accordingly, T2.1 nodes can act as either primary or secondary SDLC station. The T2.1 node is also intended to take ad vantage of various switched connection methods, such as X.25 and local area networks. The T2.1 node continues to use the 6-byte (FID2) transmission header used by the older T2 (T2.0) node, with some differences that enable it to support LU 6.2 session capabilities. (When attached to a subarea network, via a boundary function node, a T2.1 node functions as its T2.0 predecessor, so that parallel sessions and session partner symmetry are not available in this situation.)
1.5 IMPLEMENTATION OF APPC
The following sections describe some facets of APPC that relate to its im plementations, implicitly citing a number of requirements answered by APPC,
1.5.1 FUNCTION SETS
The rich ensemble of LU 6.2 functions is not implemented by all products. Compatible subsets of functions have been defined for implementation pur poses, which facilitate connectivity while reducing development costs for limited-function products. The various LU 6.2 functions are grouped into a BASE SET (implemented by all products) and various OPTION SETS. Product developers may choose to implement the option sets, but only whole option sets should be imple mented. Various prerequisite relationships exist among the option sets, as illustrated in Figure 5. The function sets are defined in terms of the protocol boundary, and are accordingly documented in the SNA Transaction Programmer's Reference Manual.
10 Introduction to APPC OPTION G F SET (2nd level)
OPTION A B C D E SET (1st level)
BASE
Figure 5. Concept of LU 6.2 Function Sets: In this hypothetical structure, option sets A and D have no dependent option sets. Option set E Is a prerequisite for F, and both B and C are prerequisites for G. NOTE: The Indicated partitioning of the base set Is merely conceptual, relating optional functions to those base func tions logically "extended".
The function sets approach assists connectivity in two ways: first, by n- suring that any two products implement a compatible set of base functions, and that any option sets they implement in common are compatible; second, by allowing a single architecture to be implemented on large and small sys tems alike, without requiring unneeded functions on smaller systems. In this way, ambiguities of product support that typically vitiate connectivity in earlier LU types, including LU 6.1, are excluded from the architecture.
1.5.2 LAYERED DESIGN
The principle of layering has been applied in SNA since its inception. In the LU 6.2 context, this principle implies that transaction programs should not need to be aware of how the APPC functions are implemented. The protocol boundary provides this insulation. Certain layering anomalies that were present in LU 6.1 have been removed in LU 6.2.' For example, the sequence number carried in the transmission header is not accessible above the data flow control layer, and function management headers are not accessible to transaction programs. Further, programs are not exposed to the size of the underlying SNA message units or indeed to any aspects of the LU-LU session.
1.5.3 PERFORMANCE ASPECTS
Improved performance with APPC is made possible by allowing sending LUs to "package" several functions into one RU, and in general to delay session
Background and Rationale 11 transmissions until an explicit requirement arises. For example, the first RU sent on a newly allocated conversation can attach the partner program (that is, start the conversation, supplying all the parameters to be used), send data, ask for confirmation of transmission, and give the partner pro gram permission to send. Certain protocol boundary options allow trans action programs to indicate to the LU that some optimization of the conversation flow is to occur.
1.5.4 IMPLEMENTATION UNIFORMITY
LU 6.2 repjaces both LU 6.1 and LU 4, of which there should be no new implementations. LU 6.2 is IBM's preferred vehicle for program-to-program communication. The T2.1 node will be preferred over both the T1 and T2.0 nodes (see "Appendix A. T2.1 Node Overview" on page 73).
1.5.5 DOCUMENTATION REQUIREMENTS
Each LU 6.2 product that supports user-written programs conforming to the conversation protocol boundary documents in its reference library how the conversation verbs map to its API. This approach allows programmers to use the SNA Transaction Programmer's Reference Manual to design compatible transaction programs for distributed transactions that involve different products, without requiring of such programmers a familiarity with each product's particular functional interface. However, individual product im plementations of the LU 6.2 interface may not be syntactically equivalent. Further, LU 6.2 simplifies the documentation that a product needs to provide to describe its correspondence with other LU 6.2 products. For example, CICS definition requirements for partner LU 6.2 systems apply regardless of the particular partner system. The SNA Transaction Programmer's Reference Manual contains several ex amples that illustrate the use of the conversation verbs.
1.5.6 MIGRATION
Most LU 6.0 and LU 6.1 programs continue to run unchanged on the CICS/VS LU 6.2 implementation. This capability is provided through certain optional APPC functions for mapped conversations.
1.6 SUMMARY
APPC, representing the transaction program's view of LU 6.2, provides a single, converged solution to the communications requirements of a diversity of products. LU 6.2 provides the functions required for all types of com munications that can be reduced to binary data, including program to pro gram, program to device and device to device communications. Via its concisely documented protocol boundary, LU 6.2 provides a single, generic
12 Introduction to APPC interface for transaction programs, that will facilitate the task of designing distributed transactions involving different product types. The function sets approach means that required and optional^^ facilities are precisely defined, assisting the task of achieving "any-to-any" connectivity among products adhering to the converged LU 6.2 architecture. LU 6.2 also enhances connectivity by providing a foundation on which distributed ser vices can be architecturally defined, and implemented compatibly on a variety of products. The supporting T2.1 node architecture enables a range of APPC systems to be pairwise connected in peer fashion, while still permitting communication with traditional host-based subarea networks.
Background and Rationale 13 2.0 APPC FUNCTIONS AND LU 6.2
This chapter describes the various APPC functions, along with some underlying aspects of LU 6.2 (such as LU components and session protocols) that are not visible to transaction programs. Readers interested in a de tailed account of the topics in this chapter should refer to PAP Manual: LU 6.2. NOTE: Reference is made to several verbs and other elements of the protocol boundary to facilitate the discussion. While the verbs are not described till the next chapter, it is sufficient in the present context to recall that a verb is a generic request of LU 6.2 for some APPC service.
2.1 STRUCTURE OF LU 6.2
Figure 6 shows the layering of LU 6.2, and its relationship both to trans action programs and to the underlying path control network. Note that the protocol boundary is between transaction programs and the presentation services layer: verbs issued by transaction programs are executed by presentation services. Note also that in addition to service definitions (between the application and presentation services layers), the protocol boundary implicitly defines peer-layer protocols for communication between transaction programs. The LU, taken as a whole, provides an interface between transaction pro grams and the path control network, so that programs need not be aware of any physical details of the underlying network. The protocol boundary extends this insulation to the session protocols used by the LU, so that programs need only be concerned with conversation-level protocols. Figure 7 illustrates some of the components of LU 6.2. Of these, service transaction programs are described in "Transaction Program Types" on page 24. Brief descriptions of the other components follow.
2.1.1 PRESENTATION SERVICES
Presentation services (PS) interacts with transaction programs to provide those functions related to interprogram communication, independently of the underlying network. These include program identification and execution, maintaining the conversation protocol state of the transaction program (for example, send/receive state), buffering of transaction program data, data stream handling on behalf of mapped conversation programs, distributed error handling, and operator control. PS interfaces with the LU services manager and the session components to complete the functions requested by the transaction programs.
APPC Functions and LU 6.2 15 2.1.2 HALF-SESSION LAYER
This layer controls session-level communication between LUs. Its responsi bilities include building RHs; enforcing correct RH parameter settings; and enforcing protocols relating to:
chaining and brackets
relevant FM (function management) and TS (transmission services) profiles
session-level pacing
sequence numbering session-level cryptography
2.1.3 LU SERVICES MANAGER
The LU services manager manages the internal allocation of LU resources, and invokes other functions of the node on behalf of end users, for example, to initiate new sessions. Resource management includes such functions as allocating and freeing ses sions for conversations between transaction programs, and managing incom ing and outgoing transaction program initiation requests (known as ATTACH
Conversation Transaction Program ••••••••••••••••••
Protocol A Boundary
V
Presentation Services
Data Flow Control Session
Transmission Control
Half-Session Layer
V Path Control Network
Figure 6. Layering of LU 6.2
16 Introduction to APPC Application Control-Operator Transaction Transaction ->Control Program Program Operator
SNADS •
DIA J
Resync
CNOS Service Transaction Programs
V
Presentation Services
LU Half-Session Layer PU<- Services Manager Data Flow Control
Transmission Control
LU 6.2
V Path Control Network
LEGEND: CNOS Change Number Of Sessions Resync • Syncpoint Resynchronization DIA Document Interchange Architecture SNADS SNA Distribution Services
Figure 7. Components of LU 6.2 requests). These two functions constitute the process of initiating a con versation between two transaction programs. The services manager also interacts with the physical unit (PU) or the node control point in connection with session activation and deactivation.
APPC Functions and LU 6.2 17 2.2 DISTRIBUTED TRANSACTIONS
We define a distributed transaction as the cooperative execution of multiple programs at multiple locations to achieve some user-requested processing function. The programs operate on their own local resources (such as terminals, data bases, and queues) and cooperate in exchanging data and coordinating their states. LU 6.2 provides the functional capability to couple two or more transaction programs at one or more LUs into a single distributed transaction. This capability includes three main components: • Communications: LU 6.2 provides the capability for an attached trans action program to communicate with other transaction programs via the SNA network. • Distributed error recovery: LU 6.2 supports distributed error recovery environments for the transaction. The protocols provide for information integrity across a multi-resource scope, and provide recovery in the event of a communications failure. • Resource management: LU 6.2 coordinates control program services to provide and manage resources for the distributed transaction. A simple example of a distributed transaction is that of a terminal operator issuing a query against a data base on a remote system. The transaction is complete when the terminal operator has the response to the query. Both systems must perform some processing: the local system may simply route the query to the remote system, which performs some data base processing and then routes the response back to the local system. This example is pictured in Figure 8 on page 19. Other, more specialized examples are given in the section "Transaction Program Types" on page 24.
2.2.1 DISTRIBUTED TRANSACTION COMPONENTS
A distributed transaction has the following components: • Transaction program code (logic): The several programs that constitute the distributed transaction must interact in a complementary way to perform the desired distributed processing function.
• Transaction program instance: An execution instance of a transaction program for a particular transaction at a particular LU. Depending on reentrancy and transaction design, there may be several execution in stances of the same code as part of the same transaction at one or se veral nodes, or as part of one or several transactions at the same node.
• Conversation resource: A resource by which one transaction program invokes (attaches) another, and by which the two programs exchange messages and state information (for example, which program is in send state and which is in receive state at a given time). A conversation is ALLOCATED when one of the partner programs requests that the other be attached at the appropriate remote LU.
Conversations couple (instances of) transaction programs into a single distributed transaction. A conversation is a pairwise connection. How-
18 Introduction to APPC Local System Remote System
T TP TP DB
TP - Transaction Program DB - Data Base T- Terminal
Figure 8. Distributed Inquiry Transaction
ever, any programs that are directly or indirectly linked by conversa tions are part of the same distributed transaction (refer to Figure 9). A conversation contrasts with a session: a conversation couples trans action programs, a session couples LUs (see Figure 3 on page 6).
Session: This is the resource which enables one LU to communicate with another LU via the SNA path control network. It is initiated by the BIND request, which specifies the session parameters, such as maximum RU sizes and pacing counts, and various identifiers, such as the primary LU name, secondary LU name, and several others in the User Data field, including the mode name (see below) and session instance identifier.
Conversations use a session serially, each mapping to a time-slice of the session known as a BRACKET. The initiation of a bracket (and hence of a conversation) is termed BIDDING, and is governed by roles es tablished in the BIND. The CONTENTION WINNER (or FIRST SPEAKER) is assured of bidding successfully, whereas a bid by the CONTENTION LOSER is subject to rejection by the contention winner, which may later advise when the bid can be re-attempted.
Local resources: Resources used by a transaction program which are created locally (by the product, and independently of SNA). These include local files, data bases, queues, logs, and terminals.
PROTECTED local resources have an interface to the SNA LU for error recovery and synchronization purposes, as described in the section "Syncpoint" on page 30.
2.2.2 DATA STRUCTURES
The LU manages the primary resources required for a distributed trans action, including transaction programs and LU-LU sessions. Each LU con tains data structures that contain information describing the following resources:
Local LU
APPC Functions and LU 6.2 19 Allocation
TPb TPd
TPa TPe
TPc
TPf
Figure 9. Possible Distributed Transaction Structure: The general LU 6.2 distributed transaction Is a tree structure, with In dividual transaction programs as nodes and conversations as branches.
This structure contains information that describes the local LU, includ ing its "system" name by which it is known to other LUs and to trans action programs (possibly by some locally-defined alias) located at other LUs.
Transaction program
This structure contains information that identifies and specifies the availability status of every (local) transaction program known to the LU. Each program has a TRANSACTION PROGRAM NAME (TPN). A trans action program specifies the TPN (or possibly some alias) of the target transaction program when it wishes to allocate a conversation.
Control point
This structure contains information that describes the control point of the node (for example, an SSCP in a host node), including certain session-related capabilities.
Partner LU
This structure contains information that describes a remote (potential partner) LU, including its names and such optional capabilities as par allel sessions.
Mode
20 Introduction to APPC This structure contains information that names and describes a MODE, or group of sessions with a particular partner LU. The mode name is an identifier used by the transaction program and the LU to specify the characteristics of the desired session. As viewed by the transaction program, it selects the level or quality of transmission service that the allocated conversation will receive. The mode name is interpreted by the node's control point at session activation, and is carried in the User Data field of the BIND.
In most implementations, mode names are exposed to system definition personnel and control operators.
2.2.3 BASE-LEVEL CONVERSATION FUNCTIONS
The conversation functions for which all implementations that expose the LU 6.2 API provide as a minimum, at receive support, are as follows:
Allocate a conversation and attach a remote program
Send data to a transaction program
Receive data from a transaction program
Send error information to a transaction program
Request control of the flow between two programs
Yield control of the flow between two programs
Confirmation of processing activities
Processing of local program errors
Detection of remote program errors
Deallocate a conversation
Subsequent sections of this chapter describe these functions.
2.2.4 CONVERSATION ALLOCATION
The process of initiating a conversation has two logical steps:
1. Allocating a session for the conversation 2. Attaching (setting in execution) the target program The ALLOCATE verb identifies the desired type of session by specifying a mode name, and identifies the target program by specifying its name and the name of the remote LU at which the target program is located (thus LU names serve as "addresses" of transaction programs).
When a conversation allocation request is received, the local LU tries to al locate a contention winner session; if there is no free session of this type
APPC Functions and LU 6.2 21 (where "free" denotes in between-brackets state, that is, not currently occupied by a conversation), but there is a free contention loser session, the LU selects and bids for such a session. If no sessions are free, and session limits have not been reached, the LU activates a new session. If no sessions are free, and session limits have been reached, the LU queues the request awaiting a session to become free. When a session has been allocated, the (local) LU sends an FMH5, known as an ATTACH HEADER, to the appropriate remote LU. It carries a number of parameters supplied by the transaction program on the ALLOCATE verb, including the target TPN, the type of conversation, and the synchronization level for the conversation. Other parameters include the logical unit-cf-work identifier (LUWID), which is created at the time the distributed transaction is initiated, and the conversation correlator. The attach header may also carry access security information, and may be followed by Program Initial ization Parameters (PIP), depending on whether these were specified by the local program. (These last facilities are described under "Other Optional APPC Functions" on page 35.) Depending on the LU, the attach header may be followed by application data in the same RU. Note that the names of the (remote) LU, target program, and mode supplied by the local program may differ from those transmitted outside the local LU. The latter names conform to various SNA constraints, but the local LU may choose to make available certain locally-defined names that shield local pro grams from name changes elsewhere in the network.
2.2.5 CONVERSATION TYPES
LU 6.2 defines two types of conversation, corresponding to two levels of the protocol boundary. The conversation type is specified by the allocating transaction program. • The BASIC CONVERSATION protocol boundary provides a low-level interface suitable for service transaction programs, or application transaction programs that require the more privileged functions available on basic conversations. For example, basic conversation transaction programs are required to manage the details of the data stream ex changed on the conversation, and are responsible for more of their own error recovery. Where exposed to user-written programs, the basic conversation protocol boundary is typically implemented in an assembler-level language. • The MAPPED CONVERSATION protocol boundary is intended for appli cation transaction programs, and allows the programs to exchange data records of arbitrary format, irrespective of the data streams used by the underlying products. Products that support mapped conversations typically do so in one or more high-level languages. Each level of the conversation protocol boundary is defined by a corre sponding set of verbs. Figure 10 compares the basic and mapped levels of the conversation protocol boundary.
22 Introduction to APPC Application Transaction Program Mapped Conversation A Protocol Boundary
Service Transaction Program Basic Conversation A Protocol Boundary V
LU 6.2
Figure 10. LU 6.2 Conversation Protocol Boundary
2.2.6 MESSAGE UNITS
Different message formats are used at the various layers of a distributed transaction, depending on the considerations that are significant at each layer. At the highest layer, for example, a transaction program on a mapped con versation sends one data record with each MC_SEND_DATA verb. On the actual LU-LU session, data is sent as BlU chains (where a BlU, or basic information unit, consists of an RH and an RU). Between these stages, various intermediate transformations of the data occur.
LU 6.2 defines a data stream known as the GENERAL DATA STREAM (CDS), that assists connectivity among programs written for different processors by insuring uniform interpretation of records exchanged between them. Each CDS VARIABLE is prefixed by a 2-byte LL (length field) and a 2-byte ID describing the GDS-defined data format, that immediately follows the LLID header.
While SNA service transaction programs use GDS variables having SNA-defin6d formats, the basic conversation protocol boundary requires only the LL prefix, not the full GDS LLID. (The unit of information consisting of an LL and the appropriate amount of data is known as a LOGICAL RECORD.) All data on mapped conversations is sent as GDS variables. The transformation from data records to GDS variables is performed by the mapped conversation component of the LU, after first performing any program-specified mapping of the data record. (Data mapping is described under "Mapped Conversation Options" on page 37.)
APPC Functions and LU 6.2 23 2.2.7 TRANSACTION PROGRAM TYPES
Several types of transaction program can be identified within the LU 6.2 framework. Refer to Figure 7 on page 17 for the relation between the various transaction program types and LU 6.2.
• APPLICATION TRANSACTION PROGRAMS These are transaction programs that perform end user processing, and are written using an end user protocol boundary with the LU. This is generally the mapped conversation protocol boundary or the protocol boundary provided by an SNA service transaction program.
• SERVICE TRANSACTION PROGRAMS These are programs that provide a system or generic service for other transaction programs. Such programs generally use the basic conver sation protocol boundary. A service transaction program may perform an architected function. In this case, it is considered part of the LU and is known as an SNA SERVICE TRANSACTION PROGRAM. SNA service transaction programs have assigned names (TPNs), whose first character is less than X'40'. Conversations involving such pro grams use certain SNA-defined CDS variables specific to their functions. These TPNs and CDS IDs are listed in SNA Reference Summary. The TPNs are also listed in SNA Transaction Programmer's Reference Manual.
Examples of SNA service transaction programs are:
- DOCUMENT INTERCHANGE ARCHITECTURE (DIA) describes formats and protocols for document library and distribution services. It is implemented by such office-related products as Displaywriter, Scanmaster, DISOSS/370, and 5520, as well as the System/36 and System/38. DIA is described in the publication Document Interchange Architec ture: Concepts and Structures. - SNA DISTRIBUTION SERVICES (SNADS) provides a general-purpose store-and-forward capability in SNA, for asynchronous transfer of data (that is, without the origin and destination transaction pro grams necessarily active at the same time). The service is provided by a network of DISTRIBUTION SERVICE UNITS (DSUs), inter connected by conversations and sessions. For individual hops be tween adjacent nodes, SNADS uses the normal synchronous communication facilities of LU 6.2. SNADS can thus be used, where appropriate, to take advantage of the availability of lower-cost transmission facilities or to compensate for time-zone differences. The protocol boundary provided by SNADS for application trans action programs (or service transaction programs such as DIA) is modeled by a number of verbs, including DISTRIBUTE_DATA, DISTRIBUTE_STATUS, and RECEIVE.DISTRIBUTION. SNADS is implemented by DISOSS/370, 5520, 8100, System/36, and System/38, and is described in FAP Manual: Distribution Services. A good introduction is the IBM Systems Journal ^aper SNA Dis tribution Services (see under "Related Publications" on page viii).
24 Introduction to APPC - DISTRIBUTED DATA MANAGEMENT (DDM) provides transparent access to distributed data bases. Programs can reside and execute on one system (Source DDM) and have access to data files residing on other system (Target DDM), acting as a file server. The System/36 and System/38 provide both Source and Target support. A transaction program for CICS/VS provides the Target DDM func tion. The detailed description of DDM architecture is contained in IBM Distributed Data Management Architecture: Reference (SC21-9526).
- The LU 6.1 models (Scheduler, Queue, and DL/1 Models) continue to run on LU 6.2 in migration mode.
-A number of service transaction programs provide product-oriented services such as 5250 passthrough on the System/36 and System/38, object distribution on the System/38, and various 3820 printer ser vices.
- LU SERVICE TRANSACTION PROGRAMS perform architected LU functions that require communication between the services managers in partner LUs. They include:
CNOS (Change Number of Sessions): This program performs control functions relating to parallel sessions. It is invoked by the control-operator transaction program (see below) to change limits on the number of sessions in effect between two LUs. CNOS is described under "Parallel Sessions and CNOS" on page 28. RESYNC: This program performs resynchronization functions where errors occurred during syncpoint processing. Resyn chronization is described further under "Syncpoint" on page 30.
Figure 11, Figure 12, and Figure 13 illustrate various kinds of distributed transactions involving application and service transaction programs.
• CONTROL-OPERATOR TRANSACTION PROGRAM
This is a non-architected program that represents the LU control operator's interface to the LU. It interacts with the LU on behalf of, or in lieu of, a human operator. Its "top" interface is product-specified (for example, an operator console) while its "bottom" interface is defined by the CONTROL-OPERATOR PROTOCOL BOUNDARY (which is associ ated with its own set of verbs), along with the basic conversation pro tocol boundary. The control-operator program performs such functions as defining the LU and its resources, and determining when sessions will be activated and deactivated. For an LU that supports parallel sessions, the control-operator program communicates with the (architected) CNOS program in the partner LU to negotiate limits on the number of parallel sessions between them.
APPC Functions and LU 6.2 25 Local System Remote System I 1 I
Session u ATP Ml LU ATP DB
Conversation
LEGEND: ATP - Application Transaction Program DB - Data Base U- User
Figure 11. Conversation between Application Transaction Programs: A user is executing an application program on the local sys tem. The program is in turn holding a conversation with an application program on a remote system. The remote program is accessing its data base for needed data.
2.3 ERROR RECOVERY
Errors in an LU 6.2 transaction may be of several kinds, including:
Local System Remote System
Session II ATP LU LU STP
Conversation
LEGEND: ATP - Application Transaction Program STP - Service Transaction Program P- Printer U- User
Figure 12. Conversation between Application Transaction Program and Device: A local application is using a remote printer via a conversation with the built-in printer transaction pro gram.
26 Introduction to APPC Local System Remote System
Session u ATP STP LU LU STP DB
Conversation
LEGEND: ATP - Application Transaction Program STP - Service Transaction Program DB - Data Base U- User
Figure 13. Conversation between Service Transaction Programs: An ap plication transaction program is using service transaction programs to access a data base. Data management requests issued by the local transaction program are sent by the lo cal service transaction program to its counterpart at the remote system (via a conversation started transparently to the application transaction program). At the remote sys tem, the service transaction program executes the request and sends back the results.
• Application errors The transaction programs are responsible for recovery from this type of error. Both mapped and basic conversation verbs provide error notification support in this situation. In general, the LU vyill truncate data (if sending) or purge data to end of chain (if receiving) when a transaction program reports an error. Mapping errors (for example, requests for unsupported functions) on mapped conversations are not communicated to the partner program. The receiving LU that detects the error sends an ERROR DATA GDS variable to the sending LU, which then informs the sending transaction program via an appropriate return code.
• Local resource failure
These are failures in non-SNA resources, such as data bases, resources are not protected resources, recovery is the responsibility of the transaction program or of some product-dependent support. If the resource is a protected resource, the transaction programs can use the LU 6.2 syncpoint function to assist in recovery. • Program failures
These are errors that cause abnormal termination of a transaction pro gram. The LU recovers from such errors by deallocating any active conversations for the transaction program that were not deallocated by the failed program, thus freeing the sessions for use by other programs.
APPC Functions and LU 6.2 27 • Session failure This is reported to the LUs by session outage notification (SON). If a conversation is active on the session at the time of failure, this failure appears to the transaction programs as a conversation failure (see be low). Reactivation of failed sessions is an LU responsibility. In many cases, an LU failure will appear to a remote (non-failing) LU as a session failure, and session recovery will then apply; syncpoint services may also be involved in other aspects of the recovery.
• Conversation failures These are caused by unrecoverable failure of the underlying session. Recovery is an operator or transaction program responsibility. It may involve allocating another conversation to a new instance of the same target program. LU 6.2 conveys session- or conversation-related error information (for ex ample, an invalid TPN in an incoming attach header) via an RU containing a Function Management Header, FMH7, known as an ERROR DESCRIPTION FM HEADER. The FMH7 contains an SNA sense code, and may be followed by product-specific error information in the form of a CDS ERROR LOG variable. Such error information is supplied with the basic conversation SEND_ERROR verb, and is recorded in the system error logs of the partner LUs. The FMH7 itself is preceded by a negative SNA response indicating a forthcoming FMH7 to explain the error.
2.4 PARALLEL SESSIONS AND CNOS
LU 6.2 implementations that provide an API equivalent to the conversation protocol boundary support multiple and parallel sessions. Parallel sessions increase the bandwidth between two LUs, enabling multiple transaction threads to proceed concurrently between the two systems. Sessions are represented to transaction programs by the APPC concept of a mode. A mode corresponds to a single session connection or a group of parallel sessions having similar session-level parameters and path control characteristics (refer to Figure 14). Within a given LU, a mode has meaning only in relation to a given partner LU. In that context, it then maps to a BIND image and some specilFication of the session routing. In subarea net works, the latter requirement is met by mapping the mode to a particular class of service (COS), reflecting such routing parameters as throughput, reliability, security, and priority. A mode thus serves to designate the quality of service that a transaction program receives from the SNA network. A transaction program specifies a mode name when it requests the LU to allocate a session for a conversation with another program. The BIND specifies whether the session being initiated is a single session or a parallel session. Products that do not support multiple sessions may have at most one session at one time, though the partner LU may support multiple sessions. The BIND also specifies the mode name for the session, and which of the session partners is to be the contention winner (assured of bidding successfully when both LUs are contending for the session). Note, however, that the BIND sender has first use of the session and may
28 Introduction to APPC Mode 1 LU A LU C Mode 3
Mode 2
LEGEND: •••••• Session
Figure 14. Single and Parallel Sessions: In this example, LU A and LU C have parallel sessions capability, while LU B supports only a single session. Sessions within a mode may be bound by either partner. immediately initiate a conversation, irrespective of which LU is the contention winner. LU 6.2 products that support parallel sessions do so through a facility known as CMOS (Change Number Of Sessions). GNOS is a service trans action program, part of the LU control-operator transaction program, that allows the regulation of:
• the number of sessions ("bandwidth")
• the contention winner polarities of those sessions This regulation occurs on an (LU,MODE) basis, that is, for a given partner LU and mode, and is invoked through a class of control-operator verbs known as CMOS VERBS. The SNA-defined GNOS transaction program exe cutes GNOS functions interacting with the GNOS transaction program in the partner LU.
GNOS can be used to maintain a sufficient number of parallel sessions to cater for the required level of transaction concurrency, and within that bandwidth 'a balance of contention winner sessions to satisfy the conversation allocation requests of transactions originating at either end of the session. The control-operator transaction program defines the maximum number of concurrent sessions for each (LU,mode) pair. GNOS then dynamically reg ulates the operating session limits beneath this giobaj maximum. The control-operator program also defines the number of sessions that may be activated automatically, independently of requests for conversations. To insure the ability to execute GNOS functions, a special mode name, SNASVGMG, is reserved for the use of the GNOS program. This mode name is supported by all LUs with parallel sessions capability. If an SNASVGMG
APPG Functions and LU 6.2 29 session is not active for some reason, the CNOS conversation may be allo cated on another active session.
2.5 SYNCHRONIZATION PROCESSING
The programs in a distributed transaction may periodically need to syn chronize their activities. LU 6.2 defines two levels of synchronization ca pability, a base level known as CONFIRM, and an optional (higher) level known as SYNCPOINT. The highest synchronization level that a particular LU 6.2 session can support is carried in the BIND. A transaction program initiating a con versation over that session (via a requested mode name that maps to that session) specifies on the ALLOCATE verb the level of synchronization it desires, which cannot exceed the level agreed on the BIND. The subsequent attach header carries this synchronization level to the transaction program partner. A conversation may be allocated with a synchronization level of NONE, in dicating that the transaction programs will not perform any synchronization processing. This is often appropriate for a simple inquiry transaction, and results in reduced session flows.
2.5.1 CONFIRM
This function allows a transaction program to solicit acknowledgment of a message from the partner program. The significance of such acknowledgment is entirely application-dependent, and thus hidden from the LUs. Further, any recovery action necessitated by a negative acknowledgment is the re sponsibility of the partner programs. Confirmation requests (CONFIRM verb) and replies (CONFIRMED and SEND_ERROR verbs) are issued by and reported to the transaction pro grams. The DR2 indicator in the RH is used to map the Confirm protocol on the data flow control (DFC) protocol. Some sample Confirm flows are given in "Sample Conversational Flows" on page 53.
2.5.2 SYNCPOINT
The syncpoint facility allows the various programs in a distributed trans action to synchronize their changes to protected resources. This might entail, for example, insuring that an account is debited on one system if and only if a corresponding account is credited on another. Syncpoint re quires that any changes to protected resources be logged on non-volatile storage so that they can be reversed if the transaction detects an error. Protected resources include conversations allocated with the Syncpoint level of synchronization, and product- or installation-defined resources such as data bases.
30 Introduction to APPC A point in a distributed transaction at which resource changes are syn chronized is called a SYNCHRONIZATION POINT, or syncpoint. The span of a distributed transaction delimited by syncpoints or by the start of the transaction is called a LOGICAL UNIT OF WORK (LUW). An LUW represents an indivisible unit of processing; any failure in an LUW invalidates the entire LUW. The LUW is identified by an LUWID, created by the LU at which the distributed transaction is initiated, consisting of the network-qualified LU name, an LUW instance number, and an LUW sequence number. The LUWID is sent on the attach header of each conversation in the distributed trans action. The sequence number is incremented by one for each successful syncpoint. A syncpoint is generally initiated when an application-designated transaction program issues the SYNCPT verb. Beyond that, the actual synchronization processing is performed by the various LUs, which communicate the results of that processing to their respective transaction programs, which respond with appropriate actions. The messages exchanged by the LUs during syncpoint processing are transparent to the programs. Of course, the transaction design must coordinate the actions of the various transaction programs during syncpoint processing. When a program issues a syncpoint verb (SYNCPT or BACKOUT), it applies to all conversations that have been allocated by that program with a synchronization level of Syncpoint. Specifically, Syncpoint provides the following capabilities: • COMMIT: the process whereby two or more transaction programs in a distributed transaction agree to make permanent all changes to their protected resources that have occurred during the current LUW. Commit signals that change records will be erased and locks removed from protected resources. A successful commit implies that syncpoint proc essing completed without errors. Where errors do occur during syncpointing, recovery may be effected through one or other of the following mechanisms: • BACKOUT: the process of reverting protected resources to their state at the commencement of the current LUW, because of an error at some point in the distributed transaction, Backout takes precedence over commit in the sense that if one partner in a distributed transaction deems it necessary to backout its changes for any reason, then all partners must do the same.
• RESYNCHRONIZATION: the process of restoring protected resources to a consistent state following failure of an LU, session, or conversation during syncpoint processing. This is done by the architected Resync transaction program. If and when an appropriate session is available, the Resync program in one LU attaches its counterpart in the other. The partner LUs then communicate on the resulting conversation to validate the integrity of their logs and determine the syncpoint status at the time of failure. This information is then used to complete the syncpoint protocol. Resynchronization does not provide the capability of automatically restarting the original (failed) transaction. The syncpoint protocols are handled by a component of presentation services known as the SYNCPOINT MANAGER. The LU at which the initial SYNCPT verb is issued is known as the syncpoint INITIATOR with respect to the LUs on the other ends of any conversations. An LU receiving syncpoint requests from an initiator is known as a syncpoint AGENT. In a general distributed transaction (such as the kind pictured in Figure 9 on page 20), an LU may perform both roles (with respect to different partners), so
APPC Functions and LU 6.2 31 that an initiator may have CASCADED AGENTS beyond its (adjacent) agents. Note, however, that depending on the transaction design, the syncpoint initiator need not be the LU at which the distributed transaction was initi ated. The following commands are used during syncpoint processing: • PREPARE solicits Request Commit and tells the agent to place its pro tected resources in a state allowing their changes during this LUW to be either committed or backed out. • REQUEST COMMIT solicits Committed, and says that the issuer has prepared all its protected resources. • COMMITTED informs the soliciting LU that all resources attached through this conversation are committed. • FORGET informs the LU that sent Committed that its log record for this LUW can be erased. It also tells the initiator that the syncpoint is complete. • HEURISTIC MIXED tells the initiator that two or more cascaded agents have been put into mutually inconsistent states as a result of a session outage. The agent reporting Heuristic Mixed learned of this situation through resynchronization processing.
• BACKED OUT informs the receiver that the sender has backed out the LUW. The first five of the above commands are encoded using PRESENTATION SERVICES HEADERS, while the last is encoded by an FMH7 carrying a sense code of X*0824'. PS headers are inserted and recognized by the presentation services layer. Their presence is indicated by a special GDS LL value, not by any RH indicator (since they are not significant at the session layer of the LU). They are described in SNA Reference Summary. The SYNCPT verb can be issued either as an initiating request by a transaction program or triggered by a Prepare or Request Commit command received from an initiating LU. In the latter case, the transaction program is informed of the requirement to take a syncpoint through the TAKE_SYNCPT indicator, which can be returned on any verb that receives data. At this point the only acceptable action on the part of the transaction program is to issue one of the verbs SYNCPT, BACKOUT, or SEND_ERROR.
Syncpoint processing in general uses an exchange of four commands, as il lustrated in Figure 15. The syncpoint managers log various local states of the LUW progressively during the exchange, beginning with Reset and cul minating with Committed, to assist in resynchronization processing in the event of a failure during syncpointing. The syncpoint flows may be opti mized in two situations:
1. Where no resources have been changed during the current LUW, the syncpoint agent replies to Prepare with Forget.
2. The initiator can pick one agent, known as a LAST resource, to receive Request Commit rather than Prepare. The Request Commit can only be sent after all other agents have replied with Request Commit. In this case, the Forget flow from the initiator to the agent is implied. An example of this optimization is given in the section "Sample Conversa tional Flows" on page 53.
32 Introduction to APPC TP Initiator Agent TP
SYNCPT Prepare TAKE_SYNCPT > SYNCPT Request Commit
Committed
Forget OK
Figure 15. Syncpoint Exchanges: The flow pictured here generalizes the case of an arbitrary syncpoint tree, where the Prepare and Committed start at the Initiator and flow down the tree, and the Request Commit and Forget flow up the tree to the Initiator.
Syncpoint allows consistency to be maintained in the presence of certain kinds of errors:
• BACKED_OUT return code This is received when the remote transaction program issues BACKOUT. In this case, the issuing program expects the LUW to be backed out, and the programs receiving BACKED_OUT should propagate it to all other resources by issuing the BACKOUT verb. BACKOUT may sjso be issued at other times, for example when a TAKE_SYNCPT indication has been received, or when the LU detects that a remote program has abended. In the latter case, the local resources of the amending pro gram will be backed out, so that this condition is treated by the local program as a BACKED_OUT return code. Figure 16 and Figure 17 illustrate typical backout flows. • Conversation failure (RESOURCE_FAILURE return code) "Phe vehicle for recovery here is the Resync transaction program, which attempts recovery by attaching its counterpart in the partner LU and exchanging the following commands (in SNA-defined CDS variables). EXCHANGE LOG NAME This command is used to validate the integrity of the LU pair logs. It carries the log name and the log status (Cold or Warm).
COMPARE STATES This command carries the state of the sending LU (In Doubt, Committed, and so on), the logical unit-of-work identifier (LUWID) applying at the time of failure, the conversation correlator of the original
APPC Functions and LU 6.2 33 Comniitted Sequence Backed Out Sequence 1 Backed Out Sequence 2
1. A -> B Prepare 1. A -> B Prepare 1. -> Prepare 2. B -> C Prepare 2. B -> C Prepare 2. -> Prepare 3. B -> D Prepare 3. B -> D Prepare 3. -> Prepare 4. C -> B Req Commit 4. C -> B Req Commit 4. -> Req Commit 5. D -> B Req Commit 5. D -> B Backed Out 5. -> Req Commit 6. B -> A Req Commit 6. B -> C Backed Out 6. -> Req Commit 7. A -> B Committed 7. B -> A Backed Out 7. -> Backed Out 8. B -> C Committed 8. B -> C Backed Out 9. B -> D Committed 9. B -> D Backed Out STATUS: Committed STATUS: Backed Out STATUS: Backed Out Figure 16. Committed and Backout (Cascaded) Examples
conversation, and the session instance identifier of the original session. If a new session is not immediately available for resynchronization pur poses, the LU may make a heuristic decision to commit or backout, possibly guided by the LU control operator, so that locks on protected resources can be freed. This decision is reported to the LU control operator, and saved for comparison during subsequent resynchronization processing. The LU responsible for resynchronization continues re synchronization attempts until completion, at which point the LUW's log entries are erased. When a session outage affects conversations involving two or more cas caded agents, it is possible that one of the LUs may heuristically commit and the other heuristically backout. The agent that is their initiator then logs this state as Heuristic Mixed during resynchronization, and reports it as such to its initiator. Figure 18 on page 36 summarizes the components of the syncpoint option set.
2.5.3 COMPARISON OF LU 6.2 SYNCHRONIZATION LEVELS
Figure 19 on page 36 compares Confirm and Syncpoint from various points of view. Note that the LU's role in Confirm is merely a passive one, com municating requests and replies between the transaction programs, whereas
34 Introduction to APPC Committed Sequence Backed Out Sequence 1 Backed Out Sequence 2
1. A -> B Prepare 1. A -> B Prepare 1. A -> B Prepare 2. A -> C Prepare 2. A -> C Prepare 2. A -> C Prepare 3. B -> A Req Commit 3. B -> A Req Commit 3. B -> A Req Commit 4. C -> A Req Commit 4. C -> A Backed Out 4. C -> A Req Commit 5. A -> D Req Commit 5. A -> B Backed Out 5. A -> D Req Commit 6. D -> A Committed 6. A -> D Backed Out 6. D -> A Backed Out 7. A -> B Committed 7. A -> B Backed Out 8. A -> C Committed 8. A -> C Backed Out
STATUS: Committed STATUS: Backed Out STATUS: Backed Out
Figure 17. Committed and Backout (Non-Cascaded) Examples in Syncpoint the LU performs functions on behalf of the transaction pro grams.
2.6 OTHER OPTIONAL APPC FUNCTIONS
2.6.1 SECURITY
LU 6.2 provides both session- and conversation-^level security functions. The following are brief descriptions of these functions. • Partner LU verification is a session-level protocol. It is accomplished through an exchange between the two LUs at session activation. The basis for this protocol is a set of LU-LU passwords, one for each pair of LUs, defined at system definition but not in any SNA-prescribed manner. The passwords as such are never transmitted. Rather, they
APPC Functions and LU 6.2 35 Commit Backout Resynchron i zati on
SYNCPT verb BACKOUT verb Resync TP
PS headers: FMH7(0824) CDS IDs: - Req Commit - Compare States - Committed - Exchange Log - Prepare Name - Forget - Heuristic Mixed ALLOCATE SYNC_LEVEL(SYNCPT) Syncpoint Manager
Figure 18. Components of the Syncpoint Option Set
serve as keys for enciphering (according to the Data Encryption Standard algorithm) random data sent from each partner to the other. The primary LU supplies random data in the actual BIND. The sec ondary enciphers this and returns the result in the BIND response, along with its own randomly generated data. The primary compares the enciphered data with its own enciphered copy. If this is successful, the primary has verified the identity of the secondary, and the other half of the verification proceeds similarly, except that the primary sends its enciphered version of the secondary's random data in an FMH12, known as a SECURITY HEADER. End-user verification is a conversation-level protocol. It is used to verify the identity of the partner end user when it requests access to a transaction program in the form of a conversation allocation request. The requesting program (perhaps representing an end user) must sup-
Confirm Syncpoint
Level Program LU (Syncpoint Mgr)
Scope Single conversation Distributed trans action
Verbs CONFIRM, CONFIRMED SYNCPT, BACKOUT
Session encoding DR2 indicator PS/FM headers
WHAT_RECEIVED= CONFIRM TAKE_SYNCPT
Recovery Program-level Backout and Resync
Figure 19. Comparison of Confirm and Syncpoint
36 Introduction to APPC ply adequate security information, such as a user ID and password, which is verified by the receiving LU. An optional additional facility is defined that controls access to a specific transaction program. This allows the requesting program to supply a PROFILE, which is used by the receiving LU to determine the access rights to the target program from some predefined authorization list maintained by the LU. Session cryptography is a means of protecting data in transit from in terpretation or modification. All user data is enciphered at the sending LU and deciphered at the receiving LU. The encryption algorithm uses a cryptographic key supplied by the control point of the node, and a session seed generated by one of the LUs at session activation. SNA CRV (Cryptography Verification) request is used to establish this function, following the BIND and its response.
2.6.2 MAPPED CONVERSATION OPTIONS
Mapped conversations provide several optional functions not available at the basic conversation protocol boundary, including: • FMH data: This function is provided for the benefit of products mi grating from earlier releases of LU 6. The ISC facility of CICS/VS and IMS/VS allowed transaction programs to send and receive various FM headers for purposes specific to the transaction. LU 6.2, on the other hand, does not allow programs access to FMHs, since they are a session- level protocol. The FMH data option encapsulates the old FMHs used by transaction programs within a CDS USER CONTROL DATA variable, which has no significance beneath the services layer of the LU. • Data mapping: The data that flows on a mapped conversation may be transformed, or MAPPED, according to maps supplied by the programs. Only the access to the mapping function is defined by SNA, not the maps themselves, which may specify arbitrary data transformations. The mapping function is performed by a presentation services component called the MAPPER. Based on the map name supplied by the sending transaction program, the mapper performs the send mapping of the data supplied by the program. This map name points in turn to a globally-known map name, which is transferred on the conversation in a MAP NAME GDS variable. At the receiving LU, the mapper performs the appropriate mapping be fore passing the data to the receiving program. This globally-known map name in turn points to a third map name, of significance to the receiving program, which then applies it in a program-defined way to the received data. The mapper at each LU retains the most recently sent and most recently received globally-known map names, which are valid until explicitly changed by another GDS map name variable. In the simplest case, the three map names are identical.
APPC Functions and LU 6.2 37 2.6.3 PIP (PROGRAM INITIALIZATION PARAMETER) DATA
Programs may optionally pass data, such as initial parameters or environment setup information, at conversation initiation. Such data is supplied by the allocating program, and sent as PIP SUBFIELD CDS variables within a PIP DATA CDS variable following the attach (FMH5) header. The target program receives the PIP data in fields specified on its initialization statement.
2.6.4 PERFORMANCE OPTIONS
LU 6.2 data flow is designed to optimize the use of the communication facility between two LUs. In general, a session flow only occurs when forced by the transaction context, for example, when sufficient data has been accu mulated at the sending LU. Several protocol boundary options are defined that overlap processing with certain conversation functions, or eliminate or accelerate certain acknowl edgments. For example, the transaction program may choose to flush the LU s send buffer to cause accumulated data to be sent immediately to the receiving program, and thus initiate needed processing at the other end. The long locks option enables a sending program to flush the LU's send buffer, request confirmation, enter receive state, and resume processing when a reply is received from the remote program; receipt of subsequent data is then interpreted as implying the confirmation reply.
2.7 SYSTEM PROGRAMMING
The system programmer's exposure to APPC is limited to those aspects that relate to insuring proper interconnection of LU 6.2 systems. Accordingly, he will be concerned with such parameters as: the maximum number of parallel sessions supported between two systems, and their accompanying mode definitions the correct RU sizes to contain maximum length records the optional LU 6.2 function sets supported by the product the service transaction programs supported the LU names for each product the names and locations of remote transaction programs and other re sources
38 Introduction to APPC 3.0 LU 6.2 PROTOCOL BOUNDARY
The APPC functions provided by LU 6.2 for transaction programs are re presented by the PROTOCOL BOUNDARY (see Figure 6 on page 16). In this chapter we survey the formal description of the protocol boundary, essentially glancing through the SNA Transaction Programmer's Reference Manual. Our aim is to convey a feeling both for the syntax used to specify the protocol boundary, and for the resulting view of LU 6.2 as seen from a transaction program. The reader is referred to the above publication for detailed descriptions of the topics introduced in this chapter.
3.1 INTRODUCTION
The protocol boundary provides a semantic (functional) definition of the way in which transaction programs interact with LU 6.2. The definition uses a programming language-like syntax, consisting of VERBS, PARAMETERS, and conversation STATES, to facilitate its description. A product that exposes the conversation protocol boundary to user-written transaction programs (an "open" LU 6.2 implementation) provides that sup port in its programming languages. However, IBM products may, or may not, implement the syntax of this generic API. CICS, for example, has implemented the protocol boundary in its command language (EXEC) inter face. Other implementers may verify that their API's match the generic API semantically, but may not copy its words, symbols, or syntax. Application designers and programmers use the protocol boundary to design their distributed transactions in a manner that is independent of the par ticipating product(s), subject only to the constraint that any optional APPC functions invoked by the distributed transaction are implemented by those products. Thus the protocol boundary provides a precise language for communication among personnel involved in the development of distributed transactions. When a distributed transaction has been accurately specified using the protocol boundary, it can then be coded in the API(s) of the underlying product(s) in a straightforward fashion. Note that, beyond their individual programming expertise, distributed transaction programmers need only be familiar with the protocol boundary, as described in SNA Transaction Programmer's Reference Manual, not with the internal details of LU 6.2, as described in the (much larger) FAR Manual: LU 6.2. Figure 20 on page 40 shows a distributed transaction involving two different product APIs.
3.2 TRANSACTION PROGRAM STRUCTURE
All transaction programs have the general structure shown in Figure 21 on page 40, where: name is the name of the transaction program. This is the name supplied by a partner transaction program in its allocation request for a con versation with this program. On receipt of the request, the LU creates a new instance of the program in a product-defined manner.
LU 6.2 Protocol Boundary 39 Product A PS layer MS layer MS layer PS layer Product B API API
PUT-THEN- >SEND RECEIVE—> READ GET
<—RECEIVE SEND<- WR TE
SYSTEM A SYSTEM B
Figure 20. Example of Mapping between Product API and LU 6.2 Protocol Boundary: "SEND" and "RECEIVE" Indicate protocol boundary verbs performing those functions (for example, SEND_DATA, RECEIVE_AND_WAIT).
PROCEDURE begins the main procedure of the transaction program. resource-id is the name of the variable in which the LU places the re source ID of the conversation on which the allocation request was re ceived. The resource ID is necessary for subsequent communication by this program with the LU. pipl,... ^pipn are the names of the variables in which the LU places program initialization parameters (PIPs) 1 through n, supplied by the allocating program. PIP is an optional facility for communicating program-level information at conversation allocation. The information is disregarded by the LU. RETURN ends execution of the program by returning control to the LU. This signals the LU to deallocate any conversations not already deallo-
name: PROCEDURE ( resource-Id [,p1pl [,... [,p1pn] ]] );
verbs and other program statements
RETURN; END name;
Figure 21. General structure of a Transaction Program: The combina tion of verbs and other programming language statements make up the transaction-processing portion of the program.
40 Introduction to APPC cated by the program, and to perform other product-dependent func tions. END name identifies the physical end of the program. The structure pictured in Figure 21 on page 40 is merely schematic, implying no syntactic agreement on the part of implementing products. However, the functions implied are matched by LU 6.2 products. NOTE: Where the program Instance is the first in a distributed transaction, program initiation occurs in some product-defined manner.
3.3 TRANSACTION PROGRAM VERB EXECUTION
As we have already mentioned, the LU is the logical "processor on which transaction programs execute. Verbs issued by transaction programs are executed by the presentation services layer of the LU (refer to Figure 6 on page 16). As illustrated in Figure 22, verbs are issued serially by the transaction program. While a verb is being executed by the LU, the program s proc essing is suspended; processing resumes when the LU returns control to the program, at which point the program may issue another verb. Some verbs have parameters that determine the scope of execution. For example, the verbs to allocate a conversation have a RETURN_CONTROL parameter that specifies a condition relating to the availability of a session. Parameters may either supply values to the LU, return values from the LU (at completion of verb execution), or both supply and return values. A typical example of a returned parameter is RETURN_CODE; another is the data parameter on verbs that receive data. The LENGTH parameter on the same class of verbs is an example of a supplied-and-returned parameter. Transaction programs converse using a send-receiye relationship. At con versation allocation, one program commences sending data while the other commences receiving data. This relationship continues until the sending program transfers send control to the other program. The protocol boundary assumes the existence of a SEND BUFFER and a RECEIVE BUFFER at the LU. The LU transfers conversation data between these buffers and areas nominated by the transaction program in accordance with verbs issued by the program. As the program issues verbs that send data, that data is accumulated by the LU in its send buffer. The LU will actually transmit the data on the session when an amount equivalent to the maximum RU size for the session has been accumulated, or when the program issues a verb that explicitly causes the LU to FLUSH its send buffer (for example, a verb that receives data from the LU). Similarly, incoming data is accumulated in the receive buffer until the program issues a verb that receives data. These buffers are also used for transferring information other than data, for example confirmation requests. Verbs that send such information cause the LU to flush its send buffer before accumulating that information at the front of the buffer. Figure 23 illustrates the operation of the send and receive buffers in relation to verbs issued by a transaction program.
LU 6.2 Protocol Boundary 41 VERB
suspended execution
Figure 22. Verb Execution: Dashed arrow indicates return of control and returned-pararaeter values to the transaction program.
3.4 GENERAL PROTOCOL BOUNDARY CONSIDERATIONS
The transaction programmer needs to be aware of certain conditions gov erning the use of the protocol boundary verbs.
• Symbol strings: Various architected names used by transaction pro grams, such as those of transaction programs, modes, and PIP subfields, must conform to certain constraints imposed by SNA. The allowable symbol-string types are described in an appendix of the SNA Trans action Programmer's Reference Manual. Mode names, for example, must conform to the standard Assembler-oriented format, known as Type A.
• Conversation states: With respect to a particular transaction program, a conversation will be in one of several defined STATES. The state of the conversation determines the verbs that a program is allowed to issue. In turn, the state is affected by the completion of a conversation verb (at either end of the conversation) or by network errors. Conversation states include SEND state, in which the program can send data or re quest resource synchronization, RECEIVE state, in which the program can receive data, CONFIRM state, in which the program can reply to a confirmation request, and various other states. The conversation verbs chapter of the SNA Transaction Programmer's Referehce Manual has a section describing the possible conversation states, along with a matrix correlating the states to the permissible verbs. The descriptions of the individual verbs indicate the possible state changes resulting from their execution.
• Return codes: Some verbs have a parameter called RETURN_CODE in which a return code is passed back to the transaction program at the completion of the LU's execution of the verb, indicating the result of verb execution, including any state changes to the conversation. Some return codes have subcodes which further define the type of error or event. Since the same return code can appear on different verbs, the SNA Transaction Programmer's Reference Manual gives a centralized description of the possible return codes at the end of the verb de-
42 Introduction to APPC Transaction Program (send) ptr buffer (send) ptr
(send) ptr
(receive) I ptr Receive buffer (receive) I ptr
Figure 23. Send and Receive Buffers: In this simple example, the pro gram Issues three consecutive verbs that send data. Each carries a pointer (Indicated by "ptr") to the data being sent, which Is then transferred to the LU's send buffer. The program then Issues a verb that receives data, which first causes the data accumulated In the send buffer to be transmitted on the session. Data subsequently received from the partner program Is then transferred from the LU's re ceive buffer.
scriptions, along with a matrix correlating the return codes to the verbs on which they can appear; the description of each individual verb specifies the return codes applicable to that verb.
Another returned parameter is WHAT_RECEIVED, which is used to inform a receiving program of the nature of the incoming data or information, for example, that there is more data to be received from the LU, that the partner program has issued a confirmation request, or that the re ceiving program is now in send state.
ABEND conditions: Certain errors related to the execution of the verbs can cause an ABEND of the transaction program. If this occurs, the LU deallocates the program's active conversations, and notifies the conversation partners via a DEALLOCATE return code. However, pro ducts are allowed some latitude in the way they handle such conditions.
LU 6.2 Protocol Boundary 43 so that abnormal termination of the program may not actually occur. The ABEND conditions are:
PARAMETER CHECK, which occurs when the program issues a verb not supported by its LU, or issues a verb with a parameter whose specification is invalid for one of several reasons. STATE CHECK, which occurs when the program issues a verb which is not permitted in the current conversation state.
The individual verb descriptions list the applicable ABEND conditions.
3.5 CONVERSATION VERBS
In the following (complete) lists of verbs, some parameters are included in order to illustrate better the functions of the verbs. Consult the SNA Transaction Programmer's Reference Manual for a complete enumeration of the parameters for each verb.
3.5.1 BASIC CONVERSATION VERBS
The basic conversation verbs are intended for use by service transaction programs. Such programs may perform end user services (for example, the 3820 printer transaction programs), or may provide a protocol boundary for use by application transaction programs (for example, the component of the LU that executes mapped conversation verbs, or the SNADS transaction programs).
ALLOCATE allocates a conversation with a remote transaction program over some session. This verb must be issued prior to any other verbs that refer to the conversation. Some of the parameters on this verb are:
LU_NAME, supplying the name of the remote LU at which the target transaction program is located. A value of OWN specifies a con versation between programs located at the same LU.
TPN, the name of the target transaction program.
MODE_NAME, the mode name designating the network properties for the session to be allocated for the conversation.
Note that the above three parameters may specify locally-defined names that the LU translates to their SNA-defined equivalents, as known to the SNA network.
SYNC_LEVEL, the highest synchronization level applicable to the conversation (NONE, CONFIRM, or SYNCPT).
TYPE, specifying whether the conversation is to be basic or mapped.
SECURITY, specifying a user ID, password, and profile that the remote LU uses to verify the identity of the end user and validate access to the remote program and its resources.
44 Introduction to APPC PIP, specifying program initialization parameter data to be passed to the target program.
RETURN_CONTROL; this parameter gives the program some dis cretion in relating the completion of the verb to the availability of a session for the conversation. The program may choose to relin quish control until a session is allocated, to regain control before a session is allocated, or to "gamble" on immediate availability of a session, regaining control with the session successfully or unsuc cessfully allocated.
RESOURCE, in which the LU returns the conversation identifier. The resource ID must be supplied on all future verbs relating to the conversation.
CONFIRM sends a confirmation request to a remote transaction program and waits for a reply, in order for the two programs to synchronize their processing.
CONFIRMED sends a confirmation reply to the remote transaction pro gram that issued CONFIRM.
DEALLOCATE deallocates a basic or mapped conversation. A FLUSH or CONFIRM may be indicated on the TYPE parameter; TYPE(SYNC_LEVEL) indicates that synchronization processing is first to be performed, at the level at which the conversation was allocated.
FLUSH directs the LU to transmit the data in its send buffer.
GET_ATTRIBUTES returns information pertaining to a conversation. Information that may be requested includes mode name, partner LU name, and synchronization level.
POST_ON_RECEIPT requests posting of the specified conversation when information is available to receive.
PREPARE_TO_RECEIVE changes the conversation from send state to re ceive state in preparation to receive data. The TYPE parameter enables the function of the FLUSH or CONFIRM verb to be included, or synchronization-level processing to be performed. The LOCKS parame ter (possible values SHORT and LONG) relates the completion of the verb to the CONFIRM or synchronization processing. RECEIVE_AND_WAIT places the transaction program in receive state (if necessary), waits for information to arrive on the conversation, and then receives the information.
RECEIVE_IMMEDIATE receives any information that is available on the specified conversation, but does not wait for information to arrive.
REQUEST_TO_SEND informs the remote transaction program that per mission to enter send state is requested. Permission is received in the form of a WHAT.RECEIVED indication of SEND.
SEND_DATA sends data (logical record format) to the remote transaction program. SEND_DATA completes when the data is buffered at the local LU.
SEND_ERROR informs the remote transaction program that a program error has been encountered. The transaction program issuing the
LU 6.2 Protocol Boundary 45 SEND_ERROR is placed in send state and the remote program in receive state. This verb can be used to respond negatively to a confirmation request, and may specify product-unique error information.
TEST tests the conversation to see whether it has been posted as a result of a preceding POST_ON_RECEI PT, or whether a REQUEST_TO_SEND notification has been received.
3.5.2 TYPE-INDEPENDENT CONVERSATION VERBS
These verbs are intended for use with both basic and mapped conversations, since their functions do not reflect the type of conversation on which they are issued.
BACKOUT restores all protected resources throughout a distributed transaction to their status as of the last syncpoint, or start of the transaction if no syncpoint has yet occurred. (Protected resources are those conversations allocated with a synchronization level of SVNGPT.) Other programs connected in the distributed transaction by protected conversations are informed of the backout operation by a BACKED_OUT return code, which requires the recipient to issue BACKOUT. Initiation of the backout operation may be in response to a syncpoint request, or at other, unrelated times, when the need is perceived. GET_TYPE returns the type of resource, BASIC_CONVERSATION or MAPPED_CONVERSATION. It is issued by programs that may be proc essed at either the basic conversation protocol boundary or mapped conversation protocol boundary. SYNCPT advances all protected resources throughout a distributed transaction to the next synchronization point. Remote programs receive the syncpoint request through one of several TAKE_SYNCPT indications returned on the WHAT_RECEIVED parameter, depending on the state of the local program. In a distributed transaction, one program is usually designated as the syncpoint initiator. The other programs cooperate in propagating the request throughout the transaction. When issuing SYNCPT, all protected resources must be in send state; this can be achieved if necessary by issuing REQUEST_TO_SEND on each conver sation and waiting for the right to send. In normal operation, the return code will be either OK, indicating that the syncpoint completed successfully, or BACKED_OUT, indicating that all protected resources are to be restored as described above under the BACKOUT verb. Where an error occurs during syncpoint processing, a return code of HEURISTIC_MIXED may be received, indicating that some protected resources have been advanced and others restored, re sulting in a possibly inconsistent state of those resources. This situ ation must be addressed through "heuristic" means. WAIT waits for posting to occur on any of a list of conversations for which [MC_]POSir_ON_RECEIPT has previously been issued. The return code indicates whether posting has occurred, and if so, why. The use of these verbs allows a program to receive data or other information synchronously from multiple conversations.
46 Introduction to APPC 3.5.3 MAPPED CONVERSATION VERBS
Mapped conversations shield the transaction programmer from certain com plexities of the basic conversation protocol boundary, in particular from the structure (CDS LLs and IDs) of the underlying data stream, and are in tended for use by high-level language transaction programs. Mapped con versations include optional support for data mapping. The mapped conversation verbs closely parallel the basic conversation verbs, as indicated in the following list. In some cases, the accompanying parameters are the same, and differences in operation from the corresponding basic conversation verbs are only apparent in the possible return codes or what-received in dications that may be received. Some significant differences are mentioned below.
MC_ALLOCATE allocates a mapped conversation (only).
MC.CONFIRM
MC_CON FIRMED
MC_DEALLOCATE deallocates a mapped conversation (only)
MC.FLUSH
MC_GET_ATTRIBUTES
MC_POST_ON_RECEI PT
MC_PREPARE_TO_RECEIVE
MC_RECEIVE_AND_WAIT functions like its basic counterpart, but re ceives data records rather than logical (LL) records. The LLID fields are removed by the mapping layer.
MC_RECEIVE_IMMEDIATE
MC_REQUEST_TO_SEND
MC_SEND_DATA sends one data record; the LLID fields are inserted by presentation services. The following parameters specify functions defined only for mapped conversations:
MAP_NAME specifies the name of a user-defined map that identifies the format of the data record and how that record is to be trans formed (mapped) before being sent. FMH_DATA specifies whether the data record contains "program-level* function management headers. If FMH_DATA(YES) is specified, presentation services attaches the GDS User Control Data ID prior to sending the data record. This parameter supports transaction programs written for LU 6.1 that used FM headers no longer supported by LU 6.2. MC_SEND_ERROR cannot specify product-unique error information.
MC_TEST
LU 6.2 Protocol Boundary 47 3.6 CONTROL-OPERATOR VERBS
The control-operator verbs define the protocol boundary for a control-operator transaction program, which performs control functions for the LU, possibly in concert with a human operator. These verbs are de scribed in a separate chapter of the SNA Transaction Programmer's Refer ence Manual.
Two characteristics of LU-LU sessions are relevant to the control-operator verbs:
* Whether the LUs are connected by a single session or parallel sessions Products that expose the conversation protocol boundary to user pro grams normally support parallel sessions. If at least one of the partner LUs does not support parallel sessions, then only single-session con nections are possible between them.
• The contention winner polarities of those sessions The contention winner LU is assured of bidding successfully for the session, whereas a bid from the contention loser may be rejected by the contention winner in the event that the latter is also contending for the session. The polarity of each session is decided at BIND time. On a single-session connection it may be the subject of negotiation between the LUs. On a parallel sessions connection, the polarity specified in the BIND is always accepted, but is determined by the sending LU in accordance with the CNOS protocols.
There are three subcategories of control-operator verbs:
1. CNOS verbs
2. Session control verbs
3. LU definition verbs
3.6.1 CNOS VERBS
There are four CNOS, or change number of sessions, verbs. Their function is to change the (LU,mode) session limit, which controls the number of sessions per mode name that are available between two LUs for allocation to conversations. Thus each of the CNOS verbs carries an LU_NAME parameter and a MODE_NAME parameter to specify the partner LU and mode to which the CNOS function applies. Along with the session limit (LU_MODE_SESSION_LIMIT parameter), the CNOS verbs change related op erating parameters of the two LUs, including the allocation of contention winner polarities (MIN_CONWINNERS_SOURCE and MIN_CONWINNERS_TARGET parameters), responsibility for selecting and deactivating sessions where required by the CNOS action (RESPONSIBLE parameter), and draining of conversation allocation requests where required (DRAIN_SOURCE and DRAIN_TARGET parameters).
The execution of a CNOS verb may be able to complete locally (as in the case of single or SNASVCMG sessions), or may require cooperation between the two LUs in the form of a CNOS request and CNOS reply (as in the case
48 Introduction to APPC of parallel sessions). The CMOS request is issued by the control-operator transaction program at the local LU, which causes the partner LU to attach the SNA-defined CMOS transaction program. The latter program processes the CMOS request and sends back a CMOS reply. This occurs on a basic conversation, which is normally allocated on an SNASVCMG session if such a session is available. The LU that sends the CMOS request is known as the SOURCE LU; the LU that receives the CMOS request is known as the TARGET LU. These roles last for the duration of the CMOS transaction.
The CMOS verbs that a control-operator transaction program may issue (provided it is so authorized via the DEFINE_TP verb) are: CHANGE_SESSION_LIMIT changes the (LU,mode) session limit from one nonzero value to another, as well as the contention winner polarities. This verb applies only to parallel sessions, and cannot specify the SNASVCMG mode name. Execution of this verb may result in activation or deactivation of LU-LU sessions of the specified mode, to conform with the new limit and polarities.
INITIALIZE_SESSION_LIMIT changes the (LU,mode) session limit for single or parallel sessions from 0 to some nonzero value, and establishes the contention winner polarities for parallel sessions. Execution of this verb may result in one or more LU-LU sessions of the specified mode being activated. For parallel sessions, the SNASVCMG mode name may be specified.
RESET_SESSION_LIMIT changes the (LU,mode) session limit from a nonzero value back to 0 for single and parallel sessions, as well as the contention winner polarities for parallel sessions.
MODE_NAME can be specified as ALL (excluding SNASVCMG), or as a particular mode name, including SNASVCMG. Execution of this verb results in deactivation of all active sessions of the specified mode, or all modes.
The CNOS verb that the CNOS service transaction program issues is:
PROCESS_SESSION_LIMIT causes the target LU to process the CNOS request and send back a CNOS reply to the source LU. The session limit, contention winner polarities, and related CNOS parameters re ceived from the source LU are processed and, if necessary, negotiated to values acceptable to the target LU. The SNA Transaction Programmer's Reference Manual, in the notes to the CNOS verb descriptions, gives detailed information on the usage of the CNOS verbs and of the actions resulting from their execution.
3.6.2 SESSION CONTROL VERBS
There are two control-operator verbs in this subcategory. A program must be defined to have session-control privilege to issue these verbs.
ACTIVATE_SESSION activates a session of the specified mode name with the target LU. Either the source or target LU may be the contention winner. The SNA-defined mode name SNASVCMG may be specified when parallel sessions are supported.
LU 6.2 Protocol Boundary 49 DEACTIVATE_SESSION deactivates the specified session, in either normal or cleanup fashion.
3.6.3 LU DEFINITION VERBS
This subcategory of control-operator verbs is used to define, modify, ex amine, or delete the local LU's operating parameters. Execution of these verbs involves only the local LU; no information is sent to any remote LU.
These verbs are as follows:
DEFINE_LOCAL_LU defines the network-qualified LU name (netid. luname), the total LU-LU session limit for this LU, conversation-level security information pertaining to all incoming allo cation requests for transaction programs at this LU, and map names for support of local mapping.
DEFINE_REMOTE_LU initializes or changes local LU operating parameters that relate to a remote LU. These parameters include the remote LU's network-qualified name, its locally-known name as specified on allocation requests from local transaction programs, whether parallel sessions are supported, the LU-LU password to be used during session activation, and the extent to which incoming conversation-level security information will be accepted.
DEFINE_MODE initializes or changes parameters relating to a given ses sion mode between the local and a given remote LU. These parameters include pacing counts, maximum RU sizes, highest synchronization level, and whether session-level cryptography is supported.
DEFINE_TP initializes or changes parameters relating to a transaction program at this LU, including the type(s) of conversations supported when this program is the target of an allocation request, the synchro nization level(s) supported, conversation-level security information, whether PIP data is required, whether data mapping support is re quired, whether FMH data support is required, and which control-operator verb privileges apply to this program (such as CNOS or session-control), as well as the privilege of being allowed to allocate a conversation with an SNA service transaction program.
DISPLAY_LOCAI LU returns current values of parameters that control the operation of the local LU, as established by the DEFINE_LOCAI LU, DEFINE_REMOTE_LU, and DEFINE.TP verbs.
DISPLAY_REMOTE_LU returns current values of parameters that control the operation of the local LU in conjunction with a remote LU, as es tablished by the DEFINE_REMOTE_LU and DEFINE_MODE verbs. DISPLAY_MODE returns current values of parameters pertaining to the specified (LU,mode) pair, as established by the DEFINE_MODE and CNOS verbs.
DISPLAY_TP returns current values of parameters that pertain to the specified local transaction program, as established by the DEFINE_TP verb.
50 Introduction to APPC DELETE deletes parameter values established by means of the DEFINE verbs.
3.7 PRODUCT SUPPORT SUBSETTING
In this section we look briefly at how the protocol boundary caters for the various optional LU 6.2 functions.
3.7.1 FUNCTIONS SETS APPROACH
LU 6.2 products that provide a programming interface equivalent to the conversation verbs all implement a common BASE SET of functions. Func tions that are not part of the base set are grouped into various OPTION SETS. A product may support any number of option sets, or none. Any option set supported should be supported in its entirety. Thus option sets form indivisible groups of functions for implementation purposes. There are various prerequisite relationships among the option sets.
The base and option sets are defined in terms of the protocol boundary, specifically in terms of verbs, parameters, return codes, and what-received indications (values of the WHAT_RECEIVED parameter).
Support is further divided into LOCAL SUPPORT (that seen by local transaction programs) and REMOTE SUPPORT (that seen by transaction programs at partner LUs). The distinction arises since certain verbs and parameters invoke processing at the remote end of the conversation, while others are processed entirely at the local end. Remote support is then applicable only to the former class of verbs and parameters, and accordingly does not apply to return codes or what-received indications.
3.7.2 SUMMARY OF THE BASE AND OPTION SETS
We summarize here the functions comprising the base set, and some of the option sets. Our treatment is necessarily sketchy. We refer to verbs and parameters in describing the function sets, but not return codes or what-received indications. Readers are referred to the appropriate appendix of the SNA Transaction Programmer's Reference Manual IFor the detailed de finitions of the base and option sets.
3.7.2.1 BASE FUNCTIONS
All open implementation products (see "Open Implementations" on page 83) provide transaction programs the ability to allocate and deallocate conver sations ([MC_] ALLOCATE, [MC_] DEALLOCATE), to issue and respond to confirmation requests ([MC_]CONFIRM, [MC_]CONFIRMED), to send and receive data ([MC_]SEND_DATA, [MC_] RECEIVE_AND_WAIT), to request permission to send ([MC_] REQUEST_TO_SEND), and to send an error no tification to the partner program ([MC_] SEND_ERROR). These functions
LU 6.2 Protocol Boundary 51 are available to basic and mapped conversation programs alike. In addition, all basic conversation programs can obtain the conversation attributes (GET_ATTRIBUTES). Of the control-operator verbs, only the CMOS verbs (with the exception of CHANGE_SESSION_LIMIT) belong to the base set.
3.7.2.2 OPTIONAL FUNCTIONS
Option sets that do not depend on requisite remote support include delayed and immediate allocation of a session (appropriate values of the RETURN_CONTROL parameter on [MC_]ALLOCATE), and verbs to flush the LU's send buffer ([MC_] FLUSH), obtain mapped conversation attributes (MC_GET_ATTRIBUTES), determine the type, basic or mapped, of a given conversation (GET_TYPE), change the conversation from send state to re ceive state ([MC_] PREPARE_TO_RECEIVE), receive whatever information is available on a conversation without having to request posting ([MC_] RECEIVE_IMMEDI ATE), request posting of multiple conversations and then suspend processing until information is available on any one of the conversations (WAIT and [MC_] POST_ON_RECEI PT), and request posting of a conversation and then to test the conversation to determine whether information is available ([MC_]TEST). Option sets that do depend on requisite remote support include or pertain to syncpoint services (SYNCPT and BACKOUT verbs), conversation-level security (SECURITY parameter on [MC_]ALLOCATE), PIP data (PIP param eter on [MC_] ALLOCATE), data mapping (MAP_NAME parameter on MC_SEND_DATA, MC_RECEIVE_AND_WAIT, and MC_RECEIVE_IMMEDIATE), and FMH data (FMH_DATA parameter on MC_SEND_DATA).
Option sets for the control-operator verbs include the CHANGE_SESSION_LIMIT verb to vary session limits for an (LU,mode) pair, the ACTiyATE_SESSION verb, the DEACTIVATE_SESSION verb, the set of LU definition verbs, and session-level security (LU_LU_PASSWORD parame ter on DEFINE_REMOTE_LU). In most cases, remote support for the control-operator verb option sets is either in the base set or not applicable.
3.7.3 REMARK ON CONNECTIVITY
While great flexibility is prevalent in the local support a product may choose to provide, in most cases remote support for the various option sets is either mandatory (that is, part of the base set) or not applicable. Only for a small number of option sets need the program be concerned with the presence of remote support. These are summarized above (syncpoint services and so on) and are listed in the SNA Transaction Programmer's Reference Manual. What these remarks imply is that despite the large number of option sets defined for the protocol boundary, only a relatively small number have effect on the connectivity of transaction programs in a network that comprises disparate LU 6.2 products supporting possibly different option sets.
52 Introduction to APPC 3.8 SAMPLE CONVERSATIONAL FLOWS
In this section we shall look at some simple transaction program sequences illustrating the use of some of the basic conversation verbs. These se quences and many others appear in the SNA Transaction Programmer's Reference Manual, where they are accompanied by copious descriptions of the conversation protocols. In the examples, the two transaction programs in conversation are labeled TP(a) and TP(b). SNA flows are indicated using arrows between the two programs, with dashed lines indicating responses; (the actual SNA RUs for these examples are given in the section "Sample Session Flows" on page 66). A vertical line under a verb indicates the suspension of program processing. Where parameters are indicated, supplied values are enclosed within parentheses, and returned^ values follow an equals (=) sign.
LU 6.2 Protocol Boundary 53 TP(a) TP(b)
[TP(a) running]
ALLOCATE TPN('b') SYNC_LEVEL(NONE) RETURN_CODE=OK
SEND_DATA RETURN_CODE=OK
DEALLOCATE TYPE(SYNC_LEVEL) RETURN_CODE=OK > [start TP(b)] [end conversation] RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED= DAT/LCOMPLETE
RECEIVE_AND_WAIT RETURN_CODE= DEALLOCATE_NORMAL
DEALLOCATE TYPE(LOCAL) RETURN_CODE=OK [end conversation] Figure 24. One-Way Conversation without Confirmation
3.8.1 ONE-WAY CONVERSATION WITHOUT CONFIRMATION
Figure 24 shows a simple conversation with data sent in one direction only. The allocation verb specifies that no confirmation processing is to occur. The LU at' TP(a) successively buffers the allocation request and the data^ since neither the ALLOCATE nor SEND_DATA explicitly causes anything to be sent. The DEALLOCATE request causes the LU to send the data that has accumulated. Because of SyNC_LEVEL(NONE), TP(a) is then immediately disconnected from the conversation, resulting in a type of asynchronous communication between the two programs. On receipt of the allocation request, the target LU starts TP(b), for whom the conversation is initially in receive state. The first RECEIVE_AND_WAIT receives the data, while the second receives the DEALLOCATE_NORMAL indication, which prompts it to issue DEALLO CATE TYPE(LOCAL), causing its LU to clean up the conversation.
54 Introduction to APPC TP(a) TP(b)
[TP(a) running]
ALLOCATE TPN('b') SYNC_LEVEL(CONFIRM) RETURN_CODE=OK
SEND_DATA RETURN_CODE=OK
DEALLOCATE "YPE(SYNC_LEVEL) - [start TP(b)]
RECEIVE_AND_WAIT WHAT_RECEIVED= DAT/LCOMPLETE RETURN_CODE=OK
RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED= CONFIRM_DEALLOCATE
RETURN_CODE=OK CONFIRMED
[end conversation] DEALLOCATE TYPE(LOCAL) RETURN_CODE=OK [end conversation]
Figure 25. One-Way Conversation with Confirmation
3.8.2 ONE-WAY CONVERSATION WITH CONFIRMATION
The conversation pictured in Figure 25 is similar to the preceding one, with the exception of the implied confirmation request on the DEALLOCATE TYPE(SYNC_LEVEL), because of the SYNC_LEVEL(CONFIRM) specified on ALLOCATE. In this case, TP(a) is suspended until a reply (aflFirmative or negative) is received to the confirmation request. The second RECEIVE_AND_WAIT by TP(b) picks up the CONFIRM.DEALLOCATE indi cation, which prompts it to reply (in this case) affirmatively with CON FIRMED, prior to issuing DEALLOCATE. If TP(b) replied negatively, with SEND_ERROR, the conversation would remain allocated.
LU 6.2 Protocol Boundary 55 TP(a) TP(b)
[TP(a) running and [TP(b) running and in conversation] in conversation]
SEND_DATA RECEIVE_AND_WAIT RETURN_CODE=OK
RECEIVE_AND_WAIT -> RETURN_CODE=OK WHAT_RECEIVED= DATA^COMPLETE
RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED=SEND
SEND_DATA RETURN_CODE=OK
DEALLOCATE RETURN_CODE=OK "YPE(SYNC_LEVEL) WHAT_RECEIVED= DAT/LCOMPLETE
RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED= CONFIRM_DEALLOCATE
CONFIRMED RETURN_CODE=OK
DEALLOCATE [end conversation] TYPE(LOCAL) RETURN_CODE=OK [end conversation] Figure 26. Two-Way Conversation with Confirmation
3.8.3 TWO-WAY CONVERSATION WITH CONFIRMATION
Figure 26 illustrates the operation of the RECEIVE_AND_WA!T verb. Assume that the conversation has already been allocated by TP(a) with SYNC_LEVEL(CONFIRM), and that it is now in send state for TP(a) and receive state for TP(b).
The first RECEIVE_AND_WAIT by TP(b) causes the LU to suspend its processing until something is received. When TP(a) issues RECEIVE_AND_WAIT, its processing is suspended, and the data previously
56 Introduction to APPC buffered by SEND_DATA is transmitted to TP(b), along with the SEND in dication to reverse the conversation states. TP(b) receives the data and regains control; its next RECEIVE_AND_WAIT picks up the SEND indication. TP(b) then sends some data, and deallocates the conversation with an implied confirmation request. This causes the LU to transmit the data to TP(a) along with a CONFIRM_DEALLOCATE indication. In the meantime, TP(b) is suspended, pending a reply to the confirmation request.
Control then returns to TP(a) as its first RECEIVE_AND_WAIT completes. A second RECEIVE_AND_WAIT invocation receives the CONFIRM_DEALLOCATE indication. TP(a) then responds affirmatively by issuing CONFIRMED, causing the LU to send a positive response on the session. The LU at TP(b) then returns control to TP(b) with an affirmative response and successful completion of the DEALLOCATE. TP(a) then issues DEALLOCATE, causing its LU to clean up the conversation at its end.
LU 6.2 Protocol Boundary 57 TP(a) TP(b)
[TP(a) running and [TP(b) running and In conversation] In conversation]
SEND_DATA RECEIVE_AND_WAIT RETURN_CODE=OK
CONFIRM -> RETURN_CODE=OK WHAT_RECEIVED= DATA_COMPLETE
RECEIVE_AND_WAIT RETURN_CODE=GK WHAT_RECEIVED= CONFIRM
RETURN_CODE=OK < - CONFIRMED
SEND_DATA RECEIVE_AND_WAIT
Figure 27. Confirmation Processing
3.8.4 CONFIRMATION PROCESSING
Figure 27 illustrates the operation of the CONFIRM verb in the middle of a conversation, rather than as part of DEALLOCATE processing (as in the preceding two examples). The CONFIRM verb by TP(a) causes the LU to send the data previously buffered together with the CONFIRM request. TP(a)'s processing is sus pended until a response, affirmative or negative, is received. The first RECEIVE_AND_WAIT by TP(b) completes on receipt of the logical record from TP(a); the second elicits the CONFIRM indication, prompting TP(b) to issue CONFIRMED. The conversation for TP(b) remains in receive state, so TP(b) issues another RECEIVE_AND_WAIT. TP(a) regains control with an affirmative response to the CONFIRM. An other SEND_DATA follows, as the conversation for TP(a) is still in send state.
58 Introduction to APPC TP(a) TP(b)
[TP(a) running and [TP(b) running and in conversation] in conversation]
REQUEST_TO_SEND SEND_DATA RETURN_CODE=OK REQUEST_TO_SEND_ RECEIVED=YES RE EIVE_AND_WAIT SEND_DATA RETURN_CODE=OK
RECEIVE_AND_WAIT -> RETURN_CODE=OK WHAT_RECEIVED= DAT/LCOMPLETE
RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED= SEND
SEND_DATA
Figure 28. REQUEST_TO_SEND
3.8.5 REQUEST^TO_SEND
Figure 28 illustrates the operation of the REQUEST_TO_SEND verb.
Assume that the conversation is in send state for TP(a) and receive state for TP(b). TP(b) issues REQUEST_TO_SEND, causing the LU to send the appropriate indication to the partner LU. At this point TP(b) issues RECEIVE_AND_WAIT and is suspended. The conversation remains in receive state for TP(b) until TP(b) receives the SEND indication. TP(a) is notified of the turnaround request on completion of the first SEND_DATA verb. This and the following SEND_DATA verb do not accu mulate enough data for transmission, so the data remains buffered until TP(a) issues RECEIVE_AND_WAIT, causing the LU to send both the contents of its buffer and the SEND indication. Successive RECEIVE_AND_WAIT verbs by TP(b) receive the logical records sent by TP(a) and finally the SEND indication. The conversation is now in send state for TP(b), so TP(b) issues SEND_DATA.
LU 6.2 Protocol Boundary 59 TP(a) TP(b)
[TP(a) running and [TP(b) running and In conversation] in conversation]
SEND_DATA RECEIVE_AND_WAIT RETURN_CODE=OK
SYNCPT Req Commlt- -> RETURN_CODE=OK WHAT_RECEIVED= DATA^COMPLETE
RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED= TAKE_SYNCPT
SYNCPT
RETURN_CODE=OK < -Comniitted RETURN_CODE=OK
SEND_DATA RECEIVE_AND_WAIT Figure 29. Syncpoint Processing
3.8.6 SYNCPOINT PROCESSING
Figure 29 illustrates the operation of the SYNCPT verb.
Assume that TP(a) has allocated the conversation with SYNC_LEVEL(SYNCPT), and that the conversation is now in send state for TP(a) and receive state for TP(b). TP(b) may also have allocated one or more conversations with SYNC_LEVEL(SYNCPT) to other partner programs. TP(a) issues SYNCPT to advance all protected resources throughout the distributed transaction to the next syncpoint. TP(a)'s processing is sus pended until syncpoint processing completes. This processing involves session-level exchanges that are not apparent to the transaction programs. The LU sends the buffered data along with the initial syncpoint request, which is communicated to TP(b) as a TAKE_SYNCPT indication on the second RECEiVE_AND_WAIT verb.
TP(b) then issues SYNCPT, once it has finished processing any protected local resources and insured that any conversations it has itself allocated are in send state. On such conversations, the LU then sends any buffered data as appropriate, along with the syncpoint request. TP(b)'s processing is suspended until syncpoint replies are received on all these conversations (if any). Then, or if there are no such conversations, the LU sends a
60 Introduction to APPC syncpoint reply on the conversation on which it received the initial syncpoint request (that is, the one with TP(a)). The LU returns control to TP(b) indicating successful completion of the SYNCPT for all protected resources allocated to TP(b), and all protected "downstream" conversations allocated by TP(b). The conversation remains in receive state for TP(b). On receipt of the final syncpoint reply, the LU returns control to TP(a) indicating successful completion of the SYNCPT for all protected resources throughout the distributed transaction. Note that any syncpoint exchanges downstream from TP(b) are transparent to TP(a). The conversation remains in send state for TP(a). NOTE: The flow depicted here is the optimal flow for a last resource (refer to "Syncpoint" on page 30); the Prepare is omitted, and the Forget is im plied.
LU 6.2 Protocol Boundary 61 4.0 LU 6.2 SESSION PROTOCOLS AND FLOWS
In the chapter "LU 6.2 Protocol Boundary", we looked at the interactions between a transaction program and the LU, which can be regarded as de fining peer communication between two transaction programs. In this chapter, we look at the session characteristics of the LU, and in particular at how conversation protocols map to flows on the underlying LU-LU session.
We emphasize that these session-level protocols are not visible for the transaction programs. The layering of LU 6.2 purposely insulates trans action programs from the operation of the underlying session (except to the extent that the session path Introduces delays on the conversation). From a program's point of view, only the conversation is visible. The program's ability to select an underlying session at allocation time is limited to the specification of a mode name, identifying a group of sessions having similar session parameters and path control characteristics.
The reader is referred to SNA Reference Summary for complete information on LU 6.2 formats. The detailed session encodings of the protocol boundary verbs are described in FAR Manual: LU 6.2.
4.1 SESSION PROTOCOLS
LU 6.2 session traffic is defined by the characteristics of its presentation services (PS), data flow control (DFC), and transmission control (TC) lay ers.
4.1.1 PRESENTATION SERVICES LAYER
4.1.1.1 GENERAL DATA STREAM (CDS)
The data stream used by LU 6.2 is either the GENERAL DATA STREAM (GDS) or a user-defined data stream. GDS consists of variable-length re cords. Each record, or GDS VARIABLE, is prefixed by a 2-byte LL (length field) and a 2-byte ID describing the type of data following. The LL is at least X'0002' as it includes its own length. Values less than this are re served for use by LU 6.2. All data on mapped conversations is transformed by PS into GDS variables. On basic conversations, programs are only required to supply the LL fields. However, SNA service transaction programs such as CMOS, Resync, and SNADS use specific GDS IDs.
4.1.1.2 PRESENTATION SERVICES HEADERS
LU 6.2 uses PRESENTATION SERVICES HEADERS for certain Syncpoint functions. PS headers are inserted and recognized by PS, and are not
LU 6.2 Session Protocols and Flows 63 visible at the DFC layer. They are indicated in the data stream by the (reserved) LL value of X'0001*.
4.1.2 FUNCTION MANAGEMENT PROFILE
The FM profile defines the characteristics of the DFC layer. On LU-LU sessions, LU 6.2 uses FM profile 19, whereas LU 6.1 used FM profile 18. A major difference between the two is that profile 18 allows many options to be set in the FM Usage field of the BIND. Profile 19 retains only the contention winner/loser as such an option; for each of the other options, a fixed value is stipulated by profile 19.
Fewer DFC requests are supported: SIGNAL is an expedited request used to change the direction of trans mission on a half-duplex session. It is generated in response to the [MC_]REQUEST_TO_SEND verb. LUSTAT (Logical Unit Status) is used by^ LU 6.2 whenever a null RU would otherwise have been generated ("no-op" type, identified by a status value of X'0006'). It is used in a variety of situations, for ex ample with BB (Begin Bracket) and RQD1 (Request for Definite-response 1) to bid without any data (replacing the BID request), or with CEB (Conditional End Bracket) and RQE1 (Request for Exception-response 1) to terminate a bracket on a newly established session prior to allo cating a conversation. BIS (Bracket Initiation Stopped) is used to inform the partner LU that the sender will not send any further BB requests. RTR (Ready To Receive) is used to inform a contention loser partner, who has previously had a bid rejected (with sense code X'0814') that the session is now available. The CANCEL, CHASE, BID, and SBI (Stop Bracket Initiation) requests are not supported. The function of SBI, for example, is included within the CNOS protocols, and BID is replaced by LUSTAT. The FM Usage settings include the following: • Half-duplex flip-flop transmission. This essentially mirrors the send/receive relationship between conversing programs, with the CD (Change Direction) bit of the RH effecting conversation turnaround. • Bracket termination is conditional, and employs the CEB indicator, in stead of the EB (End Bracket) indicator. CEB differs from EB in that when a negative response is received to the combination of CEB and RQD* (any request for definite response), the bracket remains open. Either end may send CEB, which is essentially the encoding of the [MC_]DEALLOCATE verb. • Either primary or secondary LU may be contention winner (First Speaker) with respect to beginning brackets. For a single session LU 6.2 product, this value may be negotiated by the BIND receiver. • After Rsp(BIND), the primary LU is initially in send state vis-a-vis half-duplex flip-flop protocol, and the secondary LU in receive state.
64 Introduction to APPC • After Rsp(BIND), the session is in in-brackets state. This implies that the first conversation may be initiated (by the primary LU) without an explicit BB. • Symmetric recovery responsibility
• No compression FM profile 19 legislates a fixed set of allowable combinations of the ER (Exception Response), CEB, CD, and either of the DR (Definite Response) indicators. The allowable combinations reflect the semantics of interprogram communication. For example, since CEB terminates a conversation, it is never accompanied by CD. The DR2 indicator is the encoding of Confirm protocol (see below under "Chain Usage"). The DR1 indicator may optionally be set as well, so that RQD2 and RQE2 are equivalent to RQD3 and RQE3, respectively.
Profile 19 specifies three FM headers: FMH5 the ATTACH header, used at conversation allocation to attach a target transaction program. It is usually accompanied by BC and BB (unless the bracket were started with LUSTAT), and may be followed by conversation data. FMH7 the ERROR DESCRIPTION FM HEADER, conveys error information relating to a session or conversation, following a negative response with sense code X'0846* (ERP Message Forthcoming). The FMH7 contains a 4-byte SNA sense code (for example, X'08240000*, meaning Backed Out) and may be followed by a CDS error log variable. FMH7 is unrelated to the chain state, and may flow at the front of any RU in a chain. However, it does result in truncation of data. LU 6.2, additionally, uses FMH12 (the SECURITY header) following the BIND response to exchange session-level security information where this is im plemented. On an SSCP-LU session, an LU in a host (T5) node uses FM profile 6, and an LU in a peripheral node uses FM profile 0.
4.1.3 TRANSMISSION SERVICES PROFILE
The TS profile defines the characteristics of the TC layer. On LU-LU sessions, LU 6.2 uses TS profile 7, whereas LU 6.1 used profile 4. An essential difference is that the SNA requests SDT (Start Data Traffic), CLEAR, RQR (Request Recovery), and STSN (Set and Test Se quence Numbers) are not used. The functions of CLEAR are handled by BIND/UNBIND sequences, and those of RQR and STSN by the LU 6.2 syncpointing protocols, which occur at the services layer rather than the TC layer. LU 6.2 always uses Negotiable BIND (type X'OO'). The TS Usage field specifies pacing counts (optional) and maximum RU sizes for the session. The BIND sender either sends CEB to go into contention for bracket initi ation (since the session begins in-brackets) or sends an attach header on behalf of a transaction program that has requested a conversation. CRV
LU 6.2 Session Protocols and Flows 65 (Cryptography Verification) is supported if cryptography is specified in the BIND, and will flow after the BIND response, prior to any user data.
On SSCP-LU sessions, LU 6.2 uses TS profile 1.
4.1.4 CHAIN USAGE
A chain in SNA terms carries the significance of a complete message. LU 6.2 creates chains only as a result of transaction program actions that are understood to mean "end of message". This means that on every RU carrying the EC indicator, either CD (give partner permission to send), RQD2 or RQE2 (Confirm), or CEB (Deallocate) occurs. Chains function as units of purging during error recovery, and as the maximum units of buf fering at the DFC layer.
4.2 SAMPLE SESSION FLOWS
In this section we will discuss how the sample verb flows considered in "Sample Conversational Flows" on page 53 (Figure 24 through Figure 29) map to SNA flows on the LU-LU session path. In the following diagrams, SNA flows are depicted using arrows between the two programs; RH indi cators appear above the arrows> and the RU contents, if any, below.
66 Introduction to APPC TP(a) TP(b)
[TP(a) running]
ALLOCATE TPN('b') SYNC_LEVEL(NONE) RETURN_CODE=OK
SEND_DATA RETURN_CODE=OK
DEALLOCATE TYPE(SYNC_LEVEL) RQE1,EC,BC,CEB,BB RETURN_CODE=OK -> [start TP(b)] Data,FMH5 [end conversation] RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED= DATA_COMPLETE
RECEIVE_AND_WAIT RETURN_CODE= DEALLOCATE_NORMAL
DEALLOCATE TYPE(LOCAL) RETURN_CODE=OK [end conversation] Figure 30. Session Flow for One-Way Conversation without Confirmation
4.2.1 ONE-WAY CONVERSATION WITHOUT CONFIRMATION
In Figure 30, the DEALLOCATE request causes the LU to send the data that has accumulated, the RH indicators for start and end of conversation (BB and CEB); the FMH5 to attach the remote transaction program, and the exception response indicator, corresponding to SYNC_LEVELIN0NE) . The RQE1 indicator causes CEB to take immediate effect. Contrast this with the following example in which the synchronization level is CONFIRM. NOTE: Products may choose to buffer the allocation request (as in this and the following example), or they may send the FMH5 separately, before sending any conversation data.
LU 6.2 Session Protocols and Flows 67 TP(a) TP(b)
[TP(a) running]
ALLOCATE TPN('b') SYNC_LEVEL(CONFIRM) RETURN_CGDE=OK
SEND_DATA RETURN_CQDE=OK
DEALLOCATE RQD2,EC,BC,CEB,BB "YPE(SYNC_LEVEL) -> [start TP(b)] Data,FMH5 RECEIVE_AND_WAIT WHAT_RECEIVED= DAT/LCOMPLETE RETURN_CODE=OK
RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED= CONFIRM_DEALLOCATE +DR2 RETURN_CODE=OK CONFIRMED
[end conversation] DEALLOCATE TYPE(LOCAL) RETURN_CODE=OK [end conversation] Figure 31. Session Flow for One-Way Conversation with Confirmation
4.2.2 ONE-WAY CONVERSATION WITH CONFIRMATION
In Figure 31, Instead of an exception response indicator, the DR2 indicator is turned on, fulfilling the CONFIRM implied in the DEALLOCATE verb. The CEB does not take effect until TP(b) issues CONFIRMED, causing a positive DR2 response to flow on the session.
68 Introduction to APPC TP(a) TP(b)
[TP(a) running and [TP(b) running and In conversation] in conversation]
SEND_DATA RECEIVE_AND_WAIT RETURN_CODE=OK
RQE1,CD,EC RECEIVE_AND_WAIT > RETURN_CODE=OK Data WHAT_RECEIVED= DATA_COMPLETE
RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED=SEND
SEND.DATA RETURN_CODE=OK
CEB,BC,EC,RQD2 DEALLOCATE RETURN_CODE=OK "YPE(SYNC_LEVEL) WHAT_RECEIVED= Data DAT/LCOMPLETE
RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED= CONFIRM_DEALLOCATE +DR2 CONFIRMED RETURN_CODE=OK
DEALLOCATE [end conversation] TYPE(LOCAL) RETURN_CODE=OK [end conversation] Figure 32. Session Flow for Two-Way Conversation with Confirmation
4.2.3 TWO-WAY CONVERSATION WITH CONFIRMATION
In Figure 32, the first RECEIVE_AND_WAIT issued by TP(a) causes the LU to flush its send buffer, and to append the EC and CD indicators, yielding send control to TP(b). The DEALLOCATE issued by TP(b), with the implied CONFIRM, causes the previously buffered data, along with the CEB and RQD2 indicators, to be sent as an only-in-chain request. TP(a) responds with CONFIRMED, causing a positive (DR2) response to be sent on the session.
LU 6.2 Session Protocols and Flows 69 TP(a) TP(b)
[TP(a) running and [TP(b) running and in conversation] in conversation]
SEND_DATA RECEIVE_AND_WAIT RETURN_CODE=OK RQD2,EC CONFIRM RETURN_CODE=OK Data WHAT_RECEIVED= DATA_COMPLETE
RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED= CONFIRM +DR2 RETURN_CGDE=OK CONFIRMED
SEND_DATA RECEIVE_AND_WAIT
Figure 33. Session Flow for Confirmation Processing
4.2.4 CONFIRMATION PROCESSING
Figure 33 Illustrates the flows associated with the CONFIRM verb. Apart from the setting of the DR2 indicator, note the use of EC to signify the end of a complete message implied by CONFIRM.
70 Introduction to APPC TP(a) TP(b)
[TP(a) running and [TP(b) running and in conversation] In conversation]
REQUEST_TO_SEND SEND_DATA SIGNAL RETURN_CODE=OK REQUEST_TO_SEND_ RECEIVED=YES RECEIVE_AND_WAIT SEND_DATA RETURN_CODE=OK CD, EC RE :eive_and_wait -> RETURN_CODE=OK Data WHAT_RECEIVED= DATA_COMPLETE
RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED= SEND
SEND_DATA
Figure 34. Session Flow for REQUEST_TO_SEND
4.2.5 REQUEST_TO_SEND
Figure 34 illustrates the flows associated with the REQUEST_TO_SEND verb. As an expedited SNA request, SIGNAL flows independently of the half-duplex flip-flop protocol that governs communication between partner LUs. The conversation state turnaround takes effect with the CD indicator set on the last element of the current chain.
Note that the receiver of a REQUEST_TO_SEND_RECEIVED indication is not constrained by LU 6.2 in how or when it acts on such an indication. The appropriate response is purely a function of the design of the particular distributed transaction in which the programs are participating.
LU 6.2 Session Protocols and Flows 71 TP(a) TP(b)
[TP(a) running and [TP(b) running and In conversation] in conversation]
SEND_DATA RECEIVE_AND_WAIT RETURN_CODE=OK RQE1,CD,EC SYNCPT Req Commit- RETURN_CODE=OK Data,PSH10 WHAT_RECEIVED= DATA_COMPLETE
RECEIVE_AND_WAIT RETURN_CODE=OK WHAT_RECEIVED= TAKE_SYNCPT
SYNCPT
BC^EC,CD,RQE1 RETURN_CODE=OK < Commi tted RETURN_CODE=OK PSHIO SEND_DATA RECEIVE_AND_WAIT Figure 35. Session Flow for Syncpoint Processing
4.2.6 SYNCPOINT PROCESSING
Figure 35 illustrates the flow associated with the SYNCPT verb. In this case, the flow is the optimal flow corresponding to a last resource, so that the Prepare and Forget flows are omitted. The Request Commit header carries a Modifier value that affects the RH settings for the last PS header in the syncpoint sequence. In this case, the effect is to elicit the CD indicator on the Committed reply.
72 Introduction to APPC APPENDIX A. T2.1 NODE OVERVIEW
The TYPE 2.1 (abbreviated T2.1) node is a peer architecture for connecting small systems. IBM has announced SNA Low Entry Networking Architecture as an extension of the SNA T2.0 node that supports peer-to-peer communi cations. The architecture embodies the appropriate physical and session-level connectivity for support of LU 6.2. The T2.1 node will be a preferred implementation over the the old T2.0 node, as well as the T1 node.
A.I LINK-LEVEL CONNECTIVITY
The architecture of the T2.1 node is designed for peer attachment, as il lustrated in Figure 36. (Note that the use of the term "peer" here refers to the communication protocols, not to the underlying product types.)
Figure 36. Peer Attachment of T2.1 Nodes
NOTE: A product that implements a T2.1 node may also support attachment to subarea networks via boundary function nodes. In that case, the product appears as a T2.0 node as far as its boundary function attachment is con cerned.
A. 1.1 DATA LINK CONTROLS
Two peer-coupled T2.1 nodes can be directly connected using a variety of supported DLCs, depending on particular product implementations. Sup ported DLCs include SDLC, IBM Token-Ring and X.25. The System/38, for example, supports SDLC and X.25, while the IBM Personal Computer and S/36 support SDLC and IBM Token-Ring. Initial link-level contact between a T2.1 node and a node of an unknown type uses the Null XID (i.e., XID without an l-field), to initiate the exchange of information on partner node characteristics.
Between T2.1 nodes, the FORMAT 3 XID, or XID-3 (that is, XID with a Format 3 l-field), is used to exchange information on partner character istics. This exchange occurs for both switched and non-switched con nections. The XID-3 command format is defined in the SNA Reference Summary.
Appendix A. T2.1 Node Overview 73 A. 1.2 DLC ACTIVATION
With minor exceptions, T2.1 nodes that support SDLC can function as either primary or secondary stations. Some products, such as the Personal Com puter and Displaywriter, support a ROLE NEGOTIATION protocol that allows certain aspects of their communication to be negotiated at initial link-level contact. This facility increases the flexibility of connecting T2.1 nodes. Figure 37 shows the overall activation flow for an SDLC connection (switched or non-switched) with a T2.1 as XID initiator. Role negotiation is transacted using the I-field of the XID-3, with normal DLC protocols. The XID-3 contains information on the sender's character istics, including link station capability (Primary, Secondary, or Negotiable), node type, FID type supported, message size capability, and modulo (SDLC receive window) count. The receiver then transmits its characteristics in an XID response of similar format, according to certain negotiation rules discussed below. There are two phases to the initial link-level contact procedure used by T2.1 nodes: 1. Contact phase, culminating in an initial successful XID exchange. During the contact phase it is possible for XID collisions to occur. This situation appears to the transmitting station as a timeout, and is handled by introducing a random delay before transmission of the XID. A new random value is created as long as timeouts recur, until eventually a successful exchange occurs. 2. Negotiation phase, resulting in the assignment of link station roles. a. First-order negotiation proceeds on the basis of the exchanged link-level protocol flags in the XID-3. It is successful unless both stations have specified the same value. The outcome is pictured in Figure 38. b. When both parties specify Negotiable roles, second-order negotiation proceeds by comparing a pair of ROLE NEGOTIATION VALUES. The field used for this purpose is the Node ID field of the XID-3. An iterative XID exchange is performed until the exchanged values of this field are unequal. At this point the node with the logically greater Node ID field (unsigned binary comparison) becomes the primary station. If both parties initially supply a unique Node ID, the first XID exchange will be conclusive. However, some nodes do not supply a unique Node ID. In that case, two Node ID subfields, BLOCK NUMBER (12 bits) and ID NUMBER (20 bits), are used to complete the negotiation. A value of either X'OGO' or X'FFF' in the block number subfield indicates that the Node ID does not contain a unique node-specific identifier, and that unique role negotiation values may be generated by storing random numbers in the ID number subfield. The node then generates new role negotiation values until the value sent does not equal the value received in the XID exchange. At that point, the value is "frozen" for the duration of the negotiation process. No more than two additional XID exchanges occur for the resolution of BLOCK NUMBER collisions, after that the XID fails.
74 Introduction to APPC T2.1 T2.1
Dial operation < >
Null XID
XID-3
Initial XID-3 exchange
-or- XID-3
XID-3
Negotiation if required •
SNRM
UA
RR >
Figure 37. SDLC Activation Sequence for a T2.1-T2.1 Connection
0. A final XID exchange takes place, with the role of XID sender set to the appropriate non-Negotiable value. This final exchange en sures that both nodes are in synchronism. The original (non-randomized) Node ID values may be sent on this occasion. NOTE: The outcome of the role negotiation also determines the ODAI setting (see below under "Transmission Header Usage" on page 78.) A possible negotiation sequence is pictured in Figure 39.
Appendix A. T2.1 Node Overview 75 SDLC SDLC link station role received link station role sent Primary Secondary Negotiable
Primary Error (*) PRIMARY PRIMARY
System Secondary SECONDARY definition SECONDARY error
Second-order Negotiable SECONDARY PRIMARY negotiation follows
(*) A further XID is sent containing Control Vector X'22' (XID Negotiation Error)
Figure 38. Role Negotiation: First-order negotiation is attempted us ing link-station roles. The off-diagonal entries indicate the role assumed by the sending station.
A. 1.3 MULTIPLE ATTACHMENTS
T2.1 nodes may support multiple link attachments concurrently. One way of providing this support is illustrated in Figure 40, showing the case of a
12.1 T2.1
XID-3 (Negotiable) Initial exchange XID-3 (Negotiable)
Second-order negotiation exchanges
XID-3 (Primary) Final exchange XID-3 (Secondary)
Figure 39. Example of SDLC Role Negotiation
76 Introduction to APPC T2.1 node with two link connections. The System/36 and System/38 are examples of T2.1 nodes supporting multiple links.
DIG DLC B A C
Figure 40. A Multiple-Link T2.1 Node: In this example, node A has two link connections, allowing It to communicate In peer fash- Ion with both B and C concurrently. (See the note at the end of this appendix.)
NOTE: Multiple links between two T2.1 nodes (parallel links) do not function like transmission groups in subarea networks, where the traffic for a given session may be split across different links. Rather, at session activation, the T2.1 node assigns the session to a specific link based on the combination of partner LU and mode name. This link, of course, may multiplex a number of sessions. Another way of providing multiple attachments is through a multipoint SDLC link, as illustrated in Figure 41. The System/36 and System/38 both provide primary multipoint support.
Pri Sec
T2.1 T2.1
Sec
T2.1
Figure 41. Multipoint Configuration of T2.1 Nodes: In this example, node A Is the primary station on a multipoint link, allow ing It to communicate In peer fashion with both B and C concurrently.
Appendix A. T2.1 Node Overview 77 A.2 LU-LU SESSION SUPPORT
This section describes the support provided for LU-LU sessions by the path-control layer of the T2.1 node.
A.2.1 SESSION CAPABILITIES
The T2.1 node supports the following session capabilities: • Primary LU (BIND sender) and Secondary LU (BIND receiver)
• Multiple and parallel sessions as illustrated in Figure 42.
T2.1 T2.1
BIND >
< BIND LU
LU
BIND > LU LEGEND •••• Session
Figure 42. LU-LU Sessions Between T2.1 Nodes: In this example, the LU on the left has three concurrent sessions, two of which are parallel sessions with one of the partner LUs. As suggested by the labeling of the sessions, which LU Is the primary (BIND sender) can vary from one session to another.
The only Session protocols "seen" by the T2.1 node are the BIND and UN BIND. The target LU for an incoming BIND is identified by the SLU Name field. The basic session flow is shown in Figure 43.
A.2.2 TRANSMISSION HEADER USAGE
Like the T2.0 node, the T2.1 node uses the 6-byte FID2 transmission header, though with some differences:
78 Introduction to APPC T2.1 T2.1
(PLU) (SLU) BIND
+Rsp
Session RUs
UNBIND < >
Figure 43. Session Activation and Deactivation Sequence: The BIND can flow after the initial link-level contact procedures are complete. The UNBIND may flow in either direction between the primary and secondary LUs.
• The 9^^. DAP' fields do not have individual significance, but function jointly to identify the particular session on which the associated RU is flowing. Bit 6 of byte 0, the OAF'/DAF' ASSIGNOR INDICATOR (ODAI), indicates the end of the link at which the OAF' and DAF' were assigned at session initiation: ODAI=0 Used by the assigning node having the greater role negotiation value Ccarried in the XID-3, as described above under "DLC Activation" on page 74) 0DAI=1 Used by the other node
For a given link, the combination of OAF'/DAF' fields and the ODAI bit is known as the LOCAL FORM SESSION IDENTIFIER (LFSID). The manner in which it is assigned is described below under "Addressing Mechanism". Although the DAP' and OAF' fields are interchanged as the direction of transmission flips, the ODAI value retains its original value for the duration of the session.
NOTE: Contrast the above use of the FID2 with the situation on a link be tween a T2.0 node and a boundary function node, where one of the address fields (which one depending on the direction of transmission) contains the local (intra-node) address of the LU within the T2.0 node, while the other, the session index, merely identifies whether the session is an SSCP-LU or an LU-LU session, being set to 0 or non-zero respectively. (VTAM and NCR require an LU-LU session limit of 1 for each LU in a T2.0 node.)
Appendix A. T2.1 Node Overview 79 A.2.3 ADDRESSING MECHANISM
The LFSID (Local Form Session Identifier) identifies a particular session on a given link, and is comprised of: 1. A one-byte SESSION IDENTIFIER HIGH (SIDH) 2. A one-byte SESSION IDENTIFIER LOW (SIDL)
3. The ODAI for that session (see above under "Transmission Header Us age") . The LFSID is specified by setting (SIDH,SIDL) to X'OIOV for the first session. It is subsequently incremented by 1 for each new session, with the provision that values released by deactivated sessions are reused, the lowest unused value being chosen each time. The algorithm is performed by the control point whenever a new session is needed. The concept is il lustrated in Figure 44. In that figure, each descending chain of boxes represents a chain of session activations, in which the LU in the uppermost box is the primary LU, and those in the successive boxes the partner LUs, the number in each box being the hex value of the (SIDH,SIDL) part of the LFSID for that session. Node X is assumed to have the greater role nego tiation value for the common underlying link and, therefore, ODAI of 0.
A.3 T2.1 NODE COMPONENTS
The T2.1 node contains a CONTROL POINT (CP) and one or more LUs. The purpose of the CP is to coordinate the node resources. It performs link-level functions such as link activation and deactiyation, initiating dial operations, and contacting and discontacting adjacent link stations. The CP may also provide a DIRECTORY of LU names, similar to that provided by an SSCP in a host (T5) node, to assist in session activation, and an interface to the node operator.
Additional information on T2.1 nodes can be found in SNA Format and Pro tocol Reference Manual: Architecture Logic for Type 2.1 Nodes (SC30-3422), available in December, 1986. NOTE: IBM has announced the Advanced Peer-to-Peer Networking (APPN) feature of the System Support Program (SSP) Release 5 for System/36, al lowing users to communicate across a network of interconnected System/36s on a logicdl, point to point basis, without the need to configure the path to the remote system or without the need for a subarea SNA host. Inter connected System/36s with the APPN feature act as NETWORK NODES that dynamically create and maintain tables that describe the path to reach the destination locations. Regular T2.1 nodes can participate in this type of networks as originating/destination nodes not concerned with the routing throughout the interconnected NETWORK NODES (see "IBM System/36" on page 85).
80 Introduction to APPC Node X Node Y T2.1 LU A LU C T2.1
LU B LU D
Address Tables Bind Flows OAF' ODAI = 1 ODAI = 0 DAP' 1 r ODAI SECONDARY C D A B PRIMARY -
VV 1 1 1 1 VV V BIND A-C 0 01 01 > <— +Rsp 0 01 01 A A C C BIND A-C 0 02 01 > 0101 0103 0101 0103 <— +Rsp 0 01 02 BIND B-C 0 03 01 > <— +Rsp 1 0 01 03 H H BIND B-C 0 04 01 > B A c c <— +Rsp 0 01 04 0102 0104 0102 0104 - UNBIND A-C 0 02 01 > <— +Rsp 0 01 02 BIND A-D 0 02 01 > <— +Rsp 0 01 02 B D 0105 0102 <— BIND C-A 1 01 01 +Rsp 1 01 01 > <— BIND C-B 1 02 01 +Rsp 1 01 02 > <— BIND D-A 1 03 01 +Rsp 1 01 03 > <— BIND D-A 1 04 01 +Rsp 1 01 04 > <— BIND C-B 1 05 01 +Rsp 1 01 05 >
Figure 44. Conceptual Addressing Mechanism for T2.1-T2.1 Sessions
Appendix A. T2.1 Node Overview 81 APPENDIX B. SUMMARY OF APPC PRODUCTS
This appendix provides a brief description of each of the IBM products im plementing LU 6.2, from the point of view of the APPC functions they support. The products and release levels covered are those that had been announced at the time of writing.
B.l OPEN IMPLEMENTATIONS
'Open" implementations of LU 6.2 provide an API for user-written trans action programs that conforms to the conversation protocol boundary. Such products support basic and mapped conversations, as well as multiple and parallel sessions, with appropriate CNOS support (including the CNOS ser vice transaction program to process CNOS requests from a partner LU). The base set and one or more option sets, as described in SNA Transaction Programmer's Reference Manual, are supported. For each product, we have cited the primary APPC reference, that is, the one that defines the corre spondence between the protocol boundary and the product API.
B.1.1 CICS/VS
CICS/VS Version 1 Release 6 was the first product to implement LU 6.2. CICS/VS, along with IMS/VS, had supported LU 6.1, the precursor to LU 6.2, and that support is still available. In addition, transaction pro grams that were written to run on CICS-CICS connections using LU 6.1 can run unchanged on LU 6.2 using certain mapped conversation options sup ported by CICS/VS. The conversation support is provided through the GIGS command-level (EXEG GIGS) programming interface, in which it blends naturally with other types of GIGS transaction program support. Mapped conversations are supported for Assembler, GOBOL, and PL/1 programs. Basic conversation support is for Assembler only, and is provided through the EXEG GIGS CDS commands, which basically parallel the EXEG GIGS commands for mapped conversations. Definitions for parallel sessions are set up in the TGT (TyPE=MODESET macro), and point to TYPE^SYSTEM macros defining other LU 6.2 systems. During operation, parallel sessions are controlled through the GEMT trans action, which invokes the appropriate GNOS functions. Optional functions supported by GIGS/VS include FMH data on mapped conversations (this is how GICS/VS allows LU 6.1 programs to run on LU 6.2), PIP data, conversation-level security, partner LU verification, and syncpoint services (via the SYNGPOINT command, the ROLLBAGK option providing the backout function). The licensed program DISOSS/370, which runs on GIGS/VS and uses its basic conversation interface, implements the SNA-defined architectures DIA (Document Interchange Architecture) and SNAPS (SNA Distribution Ser vices) .
Appendix B. Summary of APPG Products 83 The primary APPC reference (for CICS/OS/VS Version 1.7) is Intercommu nication Facilities Guide (SC33-0230). The following technical bulletins were written with Version 1.6 in mind, and do not include some APPC functions introduced in Version 1.7. However, both are useful references: Customer Information Control System Advanced Program to Program Communication Support (G320-0579) SNA Advanced Program-to-Program Communication in a Peer CICS/VS Environment (GG24-1656)
B.1.2 IBM SYSTEM/38
The System/38 supports APPC through its Control Program Facility (CPF)- In Release 8 of CPF additional functions are provided, like Distributed Data Management, discussed below. Mapped conversation support is provided for RPG III and COBOL. The System/38 supports data mapping on mapped conversations, as defined by the MAP_NAME parameter on the mapped con versation verbs. The CMOS protocols are controlled through the Control Language CHGSSNMAX command. Mode names are defined through PEER device descriptions. Other options supported include PIP data, conversation-level security, and partner LU verification. The highest synchronization level supported is Confirm. Multiple LUs may be defined to support multiple concurrent transactions on host connections. The System/38 implements a number of higher-level architectures, including DIA (Personal Services/38), SNADS (used by Personal Services/38 and Ob ject Distribution Facility), and several product-oriented SNA service trans action programs that provide such functions as object distribution, 525U passthrough, and virtual disk and printer support for attached PCs. A licensed program for the System/38 provides Source and Target support for Distributed Data Management (DDM), as defined in Level 1.0 tributed Data Management Architecture, giving the System/38 the ability to process a file in another (Target) System/38, System/36 or CICS/VS and to process file request from other (Source) System/38 or System/36. As a T2.1 node, the System/38 supports multiple links, which may be either SDLC (including primary multipoint support) or X.25. A primary SDLC station can communicate with a mix of secondary stations, including APPC systems and non-APPC stations normally supported by the System/38. The physical link and type of connection are described in line descriptions and PEER control unit descriptions. The System/38 can participate as an originating/destination node in a net work of System/36s with the Advance Peer-to-Peer Network (APPN) feature. In this type of network the originating node is unaware of the route required to reach the destination node (see "IBM System/36 on page 85). The primary System/38 APPC references are IBM System/38 of Communications Architectures (SC21-8033) and IBM System/38 APPC/DIA Administrator's Guide (SC21-8035). SNADS support is described in the
84 Introduction to APPC appropriate PS/38 manuals, and in the technical bulletin System/38 in a SNADS Network (GG24-1731).
B.I.3 IBM SYSTEM/36
The System/36 provides basic LU 6.2 conversation support through its System Support Program (SSP) and Base Communications feature. A session group is the implementation of an APPC mode. Session groups are controlled through the STRTGRP and STOPGRP procedures. Mapped conversation support is provided by the Interactive Communications Feature (ICR), and supports RPG II, COBOL, Basic, and Assembler programs. Partner LU verification and conversation-level security are supported. The Communi cations and Systems Management (C&SM) feature uses the session manage ment of APPC for its alert support, though the alerts themselves do not flow on an LU 6.2 session. SNA service transaction programs implemented by the System/36 include DIA (Personal Services/36), SNADS (used by Personal Services/36), and several product-oriented programs, including 5250 passthrough, and virtual disk and printer support for attached PCs. The Distributed Data Management (DDM) feature of SSP has been upgraded in Release 5 to support Level 1.0 of Distributed Data Management Architec ture, providing data connectivity for record-oriented files between the System/36, System 38 and a Target DDM on CICS/VS. A new feature of the System Support Program (SSP) called Advanced Peer-to-Peer Networking (APPN), allows users to communicate across a network of interconnected System/36s (Network Nodes) on a logical, point-to-point basis, without the need to configure the path to the remote system or without the need for a central SNA host. APPN makes use of LU 6.2 sessions over a a variety of connection media, including SDLC leased lines, X.25 networks, and the IBM Token-Ring Network. The primary System/36 APPC reference is Interactive Communication Fea ture: Reference (SC21-7910). Other APPC-related references are: Interactive Communication Feature: Guide and Examples (SC21-7911) Using Communications (SC21-9082) Communications and Systems Management Guide (SC21-8010) Distributed Data Management Guide (SC21-8011) Advanced Peer-to-Peer Networking (APPN) Guide (SC21-9471) System/36 Advanced Program-to-Program Communications (technical bulletin, GG24-1693) SNADS operation is described in the appropriate Personal Services/36 man uals and in the following technical bulletins: Personal Services/36 in a SNADS Network (GG24-1722) System/36 in a SNADS Network (GG24-1730)
Appendix B. Summary of APPC Products 85 B.1.4 IBM PERSONAL COMPUTER
The licensed program APPC/PC enables a PC to communicate with PCs and other APPC systems over SDLC connections or the IBM Token-Ring Network. On a PC equipped with both Token-Ring and SDLC adapters, APPC/PC can use both adapters concurrently, though the product does not provide a "gateway" function between the Token-Ring and a subarea network.
APPC/PC runs as a resident extension of DOS. Calls to APPC/PC are made via the 'int 68h' instruction, pointing to control blocks that conform to prescribed assembler record formats. APPC/PC and its transaction programs run under control of an application subsystem written by the system pro grammer using the control verbs provided by APPC/PC. The application subsystem defines partner LUs, modes, and CNOS options. APPC/PC enables multiple LUs to be defined. Partner LU verification and conversation-level security are supported, as is PIP data. The supported synchronization level is Confirm. As a T2.1 node, APPC/PC supports both SDLC and IBM Token-Ring data link controls. Depending on the adapter(s) installed, there may be one connection of each type. Primary SDLC operation is point-to-point only. SDLC role negotiation is supportea; the appropriate role (Primary, Second ary, or Negotiable) is specified on a configuration menu. The APPC/PC transaction programmer's reference is the APPC/PC Program ming Guide (SX27-3757). An introduction to the subject is provided in the technical bulletin An In troduction to Programming for APPC/PC (GG24-3034).
B.I.5 IBM SERIES/1
Series/1 APPC support has been introduced with version 7.1 of the Real Time Programming System (RPS). Basic and mapped conversation to the IBM personal computer APPC/PC, CICS/VS, System/36 and System/38 are sup ported. Series/1 APPC supports multiple sessions as well as multiple logical units within the same peripheral node. A series/1 with APPC can be configured with multiple data links. The Series/1 node can be simultaneously connected to several subarea nodes and peripheral nodes. The primary APPC reference is the RPS V7.1 APPC Programming Guide (SC34-0608).
B.I.6 IBM SYSTEM/88
System/88 announced support of APPC in April, 1986, providing program-to-program communication over SDLC links.
86 Introduction to APPC As a T2.1 node, the System/88 communicates peer-to-peer with other T2.1 nodes. When attached to a System/370 host the System/88 appears as a T2.0 node. The open implementation of LU 6.2 supports many options sets in addition to the base functions. Parallel sessions are supported. Security support allows security verification at both the session and transaction levels. Information for APPC for System/88 is found in the publications IBM System/88 Advanced Program-to-Program Communications Planning and Op erations Guide (SC34-0760) and IBM System/88 Advanced Program-to-Program Communications Programming Guide and Reference (SC34-0759).
B.2 CLOSED IMPLEMENTATIONS
"Closed" implementations of LU 6.2 do not provide an API for user-written programs equivalent to the conversation protocol boundary. Rather, they generally support fixed APPC functions corresponding to one or more SNA service transaction programs. Implementations such as printers may support only a secondary LU role, and only a secondary SDLC role. Each of the following products implements a single LU with single-session capability, and, apart from the 8100, a T2.1 node having a single SDLC connection.
• IBM Displaywriter System Through the Electronic Document Distribution licensed program, Displaywriter provides support for DIA. On peer links, SDLC role negotiation is supported.
• IBM Scanmaster I
Scanmaster, an image processing device, is a hard-wired implementation of DIA. It is described in IBM Scanmaster I Description (GA18-2094).
IBM 8100 With pPPX/SP Release 3, the 8100 provides support for SNADS and DIA. Physically, the 8100 can attach to another 8100 or a host, but via the host can use SNADS to communicate with other SNADS nodes such as System/36 and System/38. Further information is available in DPP)^SP Communications Support (SC23-0607), and in the technical bulletin DPPX/SP in a SNADS Network (GG24-1732).
IBM 5520 With Release 3 of the Administrative Processing Program (5611-SS2), the 5520 supports DIA and SNADS. • IBM 3820 Page Printer The 3820 Page Printer and the host program Print Services Facility support certain product-oriented 3820 printer transaction programs, which are listed in the SNA Transaction Programmer's Reference
Appendix B. Summary of APPC Products 87 Manual. These transaction programs are also used by the IBM Local Area Network (LAN) PrintManager Program.
88 Introduction to APPC ACRONYMS AND ABBREVIATIONS
API Application Program ERP Error Recovery Process Interface ing
APPC Advanced Fl Format Indicator (in RH) Program-to-Prog ram Com munication FID2 Format Identifier 2 (TH format) BB Begin Bracket (RH indi cator) FM Function Management
BC Begin Chain (RH indica FMH Function Management tor) Header
BF Boundary Function CDS General Data Stream
BID Basic Information Unit HS Half-Session
CEB Conditional End Bracket l-FIELD Information field (of the (RH indicator) DLC XID command)
CNOS Change Number Of Ses LU Logical Unit sions LUW Logical Unit of Work COS Class Of Service LUWID Logical Unit-of-Work CP Control Point (in SNA Identifier node) MLU Multiple LU DAF' Destination Address Field (in FID2 TH) NCP Network Control Program
DDM Distributed Data Manage OAF' Origin Address Field (in ment FID2 TH)
DFC Data Flow Control ODAI OAF'/DAF' Assignor Indi cator (in FID2 TH) DIA Document Interchange Architecture PC Path Control; Personal Computer , DLC Data Link Control PIP Program Initialization Pa DR1I Definite Response 1 Indi rameter cator (RH) PLU Primary LU DR2I Definite Response 2 Indi cator (RH) PS Presentation Services
EB End Bracket (RH indica PU Physical Unit tor) RESYNC Resynchronization EC End Chain (RH indicator) (Syncpoint function)
ERI Exception Response Indi RH Request/Response Header cator (in RH) RQD1 DR1I=1,DR2I=0,ERI=0
Acronyms and Abbreviations 89 RQD2 DR1I=0,DR2I=1,ERI=0 SLU Secondary LU
RQD3 DR1I=1,DR2I=1,ERI=0 SON Session Outage Notifica tion RQD* Either RQD1 or RQD2 or RQD3 SNADS SNA Distribution Services
RQEl DR1I=1,DR2I=0,ERI=1 SSCP System Services Control Point RQE2 DRli=0,DR2l=1,ERi=1 TC Transmission Control RQE3 DR1I=1,DR2I=1,ERI=1 TH Transmission Header RQE* Either RQEl or RQE2 or RQE3 TPN Transaction Program Name
RSP SNA Response Unit TS Transmission Services
RU Request/Response Unit VTAM Virtual Telecommuni cations Access Method SDLC Synchronous Data Link Control XID-3 XID with Format 3 l-field
90 Introduction to APPC AN INTRODUCTION TO ADVANCED PROGRAM-TO-PROGRAM COMMUNICATION READER'S (APPC) COMMENT 0024-1584-1 FORM
You may use this form to communicate your comments about this publication, itsorganization, or subject matter, with the understanding that IBM may use ordistribute whatever information you supply inany way it believes appropriate without incurring any obligation to you. Your comments will be sent tothe author's department for whatever review and action, ifany, are deemed appropriate. Note: Copies ofIBM publications arenotstocked at thelocation to which this form isaddressed. Please direct any requests forcopies ofpublications, orforassistance in using yourIBM system, to yourIBM representative or to theIBM branch office serving your locality. Possible topics for comment are: Clarity Accuracy Completeness Organization Coding Retrieval Legibility If you wish a reply, give yourname, company, mailing address, anddate:
What is your occupation?
Number of latest Newsletter associated with this publication:
Thank you for your cooperation. No postage stamp necessary ifmailed in the U.S.A. (Elsewhere, an IBM office or representative will be happy to forward your comments or you may mail directly tothe address in the Edition Noticeon the back of the title page.) Reader's Comment Form
Fold and tape Please Do Not Staple Fold and tape
NO POSTAGE NECESSARY IF MAILED IN THE UNITED STATES
BUSINESS REPLY MAIL
FIRST CLASS PERMIT NO 40 ARMONK. N Y
POSTAGE WILL BE PAID BY ADDRESSEE; IBM International Technical Support Center Department 985A, Building 657 P.O. Box 12195 Research Triangle Park Raleigh, North Carolina 27709 U.S.A.
Fold and tape Fold and tape Please Do Not Staple AN INTRODUCTION TO ADVANCED PROGRAM-TO-PROGRAM COMMUNICATION (APPC) READER'S GG24-1584-1 COMMENT FORM
You may use this form to communicate your comments about this publication, its organization, or subjectmatter, with the understanding that IBM mayuse or distribute whatever informationyou supply in any way it believes appropriate without incurringany obligationto you. Your conunents will be sent to the author's department for whatever review and action,if any, are deemed appropriate. Note: Copies ofIBMpublicationsare not stockedat the location to whichthisform isaddressed. Pleasedirect any requestsfor copiesofpublications, or for assistance in using your IBMsystem,to yourIBM representative or to the IBM branch office servingyour locality. Possible topics for comment are: Clarity Accuracy Completeness Organization Coding Retrieval Legibility If you wish a reply, give your name, company, mailingaddress,and date:
What is your occupation?
Number oflatest Newsletter associated with this publication:
Thank you for yourcooperation. Nopostage stamp necessary if mailed in the U.S.A. (Elsewhere, an IBM office or representative will be happy to forward yourcomments or you maymail directly to the address in the Edition Notice on the back of the title page.) Reader's Comment Form
Fold and tape Pleose Do Not Stcpto Fold and tape
NO POSTAGE NECESSARY IF MAILED IN THE UNITED STATES
BUSINESS REPLY MAIL
FIRST CLASS PERMIT NO. 40 ARMONK. N.Y.
POSTAGE WILL BE PAID BY ADDRESSEE: IBM International Technical Support Center Department 985A, Building 657 P.O. Box 12195 Research Triangle Park Raleigh, North Carolina 27709 U.S.A.
Fold and tape Fold and tape Ptease Do Not Staple I lUIN lU AUVAINL.kU L»U2q-15l PROGRAM-TO-PROCRAM COMMUNICATION (APPC)