If the workstation will not be connecting from an end node to a network node server, you need to define an SNA connection.
Personal Communications provides Advanced Peer-to-Peer Networking (APPN) end node support for workstations, allowing them to communicate more flexibly with other systems in the network.
Personal Communications provides advanced program-to-program communications (APPC) to support communications between distributed processing programs, called transaction programs (TPs). APPN extends this capability to a networking environment. The TPs can be located at any node in the network that provides APPC.
Advanced Program-to-Program Communication (APPC), also known as LU 6.2, is software that enables high-speed communications between programs on different computers, from portables and workstations to midrange and host computers. APPC software is available for many different IBM and non-IBM operating systems, either as part of the operating system or as a separate software package.
APPC serves as an interface between application programs and the network. When the communications application on your workstation passes information to the APPC software, APPC takes the information and sends it on to a network interface, such as a token ring adapter card. The information travels across the network to another computer, where the APPC software receives the information from the network interface. APPC puts the information back into its original format and passes it to the corresponding communications application.
APPC provides a consistent set of functions for program-to-program communications across different platforms. But, the architecture did not specify a common application programming interface (API) for implementing these functions. As a result, each operating system that supports APPC developed its own API, a set of verbs that closely resemble the operating system itself. These differences do not pose a problem if you are writing programs for two computers that use the same operating system. Most client/server applications run on different types of computers, however, to take advantage of the strengths of each computer. So, if you are designing programs for different operating systems, you must learn how to use two or more different sets of verbs.
The Common Programming Interface for Communications (CPI-C) eliminates this problem. CPI-C provides one standard set of verbs, known as CPI-C calls, for all systems that support CPI-C. As a result, you learn only one set of calls to write client/server applications for different systems.
The part of the communications application that initiates or responds to APPC communications is called a transaction program. A transaction program is not an entire, stand-alone program. Instead, it is the part of the program that handles transactions (exchanges of data) with another program.
When people talk with each other, we say that they are having a conversation. Likewise, the communication between two transaction programs is called a conversation.
A conversation between two programs is similar to a conversation between two people. When you have a conversation with another person, you follow unwritten rules that govern how you begin and end the conversation, take turns speaking, and exchange information. Similarly, APPC is called a protocol because it provides the rules that govern how conversations between transaction programs start and stop, which program "speaks" first, and how data is exchanged. Computers need complete and rigid rules for conversations between programs. For that reason, APPC consists of a set of well-defined and thorough rules to cover all possible communications situations.
An APPC program may have several conversations active at one time, with the same transaction program or with different transaction programs.
Every transaction program needs a partner to communicate with. Thus, transaction programs are developed in pairs called partner transaction programs.
People use different parts of speech to communicate with each other. Transaction programs are more limited in their communications; they use only verbs to communicate with each other. The verbs are the programming language you use to start, stop, and control conversations.
A transaction program consists of APPC and CPI-C verbs such as:
The APPC verbs make up the application programming interface (API) for APPC and CPI-C. In other words, these verbs represent the interface between the transaction program and the APPC software.
APPC is a communications protocol that enables programs on different computers to "talk to" each other. APPC provides the interface between the programs and the networking hardware and software and defines the rules that programs use to exchange information.
Advanced Peer-to-Peer Networking (APPN) is the underlying networking protocol that routes APPC traffic through intermediate nodes in the network. For instance, when Program A uses APPC to talk to Program B, APPN finds the node where Program B is located and directs the APPC traffic through the network.
APPN includes several features that help reduce the amount of configuration required to set up and maintain a network. These features automate many tasks that are time-consuming, complicated, and error-prone. For example, if you're installing a new workstation that uses APPN, you don't have to set up configuration information for every workstation you want to communicate with. You simply provide the name of the computer and the address of the intermediate node that handles your traffic. APPN takes care of the rest of the information needed to route APPC traffic to and from your workstation.
If you connect to an APPN network, you simplify your own configuration and make it easier for other computers in the network to find you.
Before starting a conversation with a partner program, a CPI-C program requires the following information:
If the CPI-C partner program uses a blank symbolic destination name, a side information definition is not necessary.
The advanced features of APPC help speed the development of robust client/server applications and keep development costs low.
Client/server applications often prove to be especially challenging to the programmer. It is not enough to understand the details about the computer and operating system that your application uses. If you're designing client/server applications, you have to deal with computers used by both sides of the application, as well as the intervening network. For instance, implementing effective security measures is more important and more complicated, since you must ensure security throughout the network. In addition, synchronization and error reporting are often problematic in a distributed environment, because both sides of the application must coordinate their work.
One reason that APPC has become so widely used in client/server applications is that it furnishes a complete set of useful functions like security, synchronization, and error reporting. If you use other protocols, you must build these functions in every application you write. For example, if you use NetBIOS, you must design and implement a strategy for security for each application. Not only does this approach require additional work, it may result in a number of incompatible security systems in your network. By contrast, APPC includes a common set of security services that are consistent across all APPC platforms.
Similarly, most protocols do not include synchronization functions. Synchronization is required by any program that cannot continue processing data until the data sent to the partner program has been received and processed. Rather than writing your own synchronization routine, APPC provides a Confirm call that you can use to handle synchronization between two programs.
Because many client/server applications are distributed between mainframe systems and workstations, host programmers and workstation programmers must work together to develop partner applications. CPI-C bridges the gap between these programmers by providing a common language for designing the communications part of the applications. CPI-C also enables you to write the communications portion of an application without knowing the details of the operating system. After you write a CPI-C application, you can easily move the programs from one operating system to another with few changes. So, by using the CPI-C interface, you can port both your applications and your programming skills from one system to another, quickly and cost-effectively.
Every TP gains access to an SNA network through a logical unit (LU). An LU is SNA software that accepts verbs from your programs and acts on those verbs. A TP issues APPC verbs to its LU. These verbs cause commands and data to flow across the network to a partner LU. An LU also acts as an intermediary between the TPs and the network to manage the exchange of data between TPs. A single LU can provide services for multiple TPs. Multiple LUs can be active in the node simultaneously.
Personal Communications supports LU types 0, 1, 2, 3, and 6.2. LU types 0, 1, 2, and 3 support communication between host application programs and different kinds of devices, such as terminals and printers.
LU 6.2 supports communications between two programs located at type 5 subarea nodes, type 2.1 peripheral nodes, or both, and between programs and devices. APPC is an implementation of the LU 6.2 architecture.
Communication occurs only between LUs of the same LU type. For example, an LU 2 communicates with another LU 2; it does not communicate with an LU 3.
When Personal Communications is configured, your local and partner LUs are defined once for each machine. When you design programs, you must understand the capabilities supported by the LU in the particular machines you plan to use.
A dependent LU depends on a system services control point (SSCP) to activate a session. A dependent LU needs an active SSCP-LU session, which the dependent LU uses to start an LU-LU session with an LU in a subarea node. A dependent LU can have only one session at a time with the subarea LU. For communications with a TP at a subarea node, each dependent LU can have only one conversation at a time, and each dependent LU can support communications for only one TP at a time.
An independent LU does not depend on an SSCP to activate a session. An independent LU supports multiple concurrent sessions with other LUs in a subarea node, so you can have multiple conversations and support multiple TPs for communications with subarea TPs. LUs between peripheral nodes also use this support.
The distinction between a dependent LU and an independent LU is meaningful only when discussing a session between an LU in a peripheral node and an LU in a subarea node. Otherwise, dependent and independent LUs both support multiple concurrent sessions and conversations when communicating between type 2.1 peripheral nodes, for example, between two Windows workstations. A Personal Communications LU can support a single session with a dependent LU or multiple sessions with an independent LU.
Before TPs can communicate with each other their LUs must be connected in a mutual relationship called a session. A session connects two LUs, so it is called an LU-LU session. Figure 3 illustrates this communication relationship. Multiple, concurrent sessions between the same two LUs are called parallel LU-LU sessions.
Sessions act as conduits that manage the movement of data between a pair of LUs in an SNA network. Specifically, sessions deal with things such as the quantity of data transmitted, data security, network routing, and traffic congestion.
Sessions are maintained by their LUs. Normally, your TPs do not deal with session characteristics. You define session characteristics when you:
The communication between TPs is called a conversation. Conversations occur across LU-LU sessions. A conversation starts when a TP issues an APPC verb or CPI-C call that allocates a conversation. The conversation style associated with the conversation indicates the style of data transfer to be used, two-way alternate or two-way simultaneous. A conversation that specifies a two-way alternate style of data transfer is also known as a half-duplex conversation. A conversation that specifies a two-way simultaneous style of data transfer is referred to as a full-duplex conversation.
When a half-duplex conversation is allocated to a session, a send-receive relationship is established between the TPs connected to the conversation, and a two-way alternate data transfer occurs where information is transferred in both directions, one direction at a time. Like a telephone conversation, one TP calls the other, and they "converse", one TP talking at a time, until a TP ends the conversation. One TP issues verbs to send data, and the other TP issues verbs to receive data. When it finishes sending data, the sending TP can transfer send control of the conversation to the receiving TP. One TP decides when to end the conversation and informs the other when it has ended.
When a full-duplex conversation is allocated to a session, both TPs connected to the conversation are started in send-and-receive state, and a two-way simultaneous data transfer occurs where information is transferred in both directions at the same time. Both TPs may issue verbs to send and receive data simultaneously with no transfer of send control required. The conversation ends when both TPs indicate they are ready to stop sending data, and each TP has received the data sent by the partner. If an error condition occurs, one TP may decide to end both sides of the conversation abruptly.
Conversations can exchange control information and data. The TP should select the conversation style best suited for its application.
Figure 4 shows a conversation between two TPs as it occurs over a session.
A session can support only one conversation at a time, but one session can support many conversations in sequence. Because multiple conversations can reuse sessions, a session is a long-lived connection compared to a conversation. When a program allocates a conversation and all applicable sessions are in use, the LU puts the incoming Attach (allocation request) on a queue. It completes the allocation when a session becomes available.
Two LUs can also establish parallel sessions with each other to support multiple concurrent conversations. A parallel session occurs when either TP allocates a conversation, and a session exists but is being used by a conversation. The LU can request a new session to satisfy the allocation.
Figure 5 shows three parallel sessions between two LUs; each session carries a conversation.
Personal Communications supports Systems Network Architecture (SNA) type 2.1 nodes (including SNA type 2.0 and SNA type 2.1 support for LUs other than SNA LU 6.2). This support lets you write programs to communicate with many other IBM SNA products.
You can write programs without knowing the details of the underlying network. All you need to know is the name of the partner LU; you do not need to know its location. SNA determines the partner LU location and the best path for routing data. A change to the underlying network, such as a physical address change, the addition of a new adapter, or the relocation of a machine, does not affect APPC programs. A program might, however, need to establish link connections over switched SDLC connections.
When Personal Communications starts, it establishes local LU and logical link definitions, which are stored in a configuration file. The system management application programming interface (API) provides functions that control configuration definition and adapter and link activation.
With SNA Node Operations, either a user or system administrator can display information or take action on node resources that are known to the active node.
The following tasks are supported:
For more information about SNA node operations, see SNA Node Operations or refer to the online help.
