Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!uwmcsd1!ig!agate!ucbvax!BITNIC.BITNET!POSTMASTER From: POSTMASTER@BITNIC.BITNET (Undetermined origin c/o Postmaster) Newsgroups: comp.protocols.ibm Subject: (none) Message-ID: <8807272016.AA21492@jade.berkeley.edu> Date: 27 Jul 88 16:42:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Undetermined origin c/o Postmaster Organization: The Internet Lines: 144 There are a number of pretty good IBM publications that cover LU-6.2. In order of increasing detail, they are: "Advanced Program-to-Program Communication in SNA" by Jim Gray, et al, in the IBM Systems Journal, 22:4 (1983). "SNA Concepts and Products" [GC30-3072]. This is mostly SNA background material, which is good for people who are not familiar with SNA (which doesn't map one-to-one onto OSI). "SNA Technical Overview" [GC30-3073]. Again, this is an overview of all of SNA rather than being limited to just LU-6.2 sessions, at the next level of detail from GC30-3072. "SNA Transaction Programmer's Reference Manual for LU Type 6.2" [GC30-3084]. This is the official architecture specification of the interface between LU-6.2 and the Application Layer. It describes enough about the LU-6.2 flows to give you a view of what is actually going on. The manual is bit on the large size (about 150 pages). "Systems Application Architecture: Common Programming Interface: Communications Reference" [SC26-4399]. The SAA version of GC30-3084. Somewhat easier to understand. I don't know if this has hit the streets yet -- if not, it will be out very soon. "SNA Format and Protocol Reference Manual: Architecture Logic for LU Type 6.2" [SC30-3269]. The Bible. As much detail as you could possibly want. Easily half of this (huge) manual is pseudo-code that outlines a full-blown implementation of LU-6.2. There is also lots of prose and network flow diagrams. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - In a nutshell, LU-6.2 spans the Session and Presentation layers (in SNA, the Session layer consists of the Data Flow Control and the Transmission Control sub-layers). The Session part of LU-6.2 is a half-duplex, flip-flop data pipe that transmits arbitrary-length bursts of data in a totally transparent fashion. It can also transmit "side-band" data records, called Function Management Headers, which flow synchronously with the rest of the data -- these FMHs are used by the two ends of the Presentation Services layer to send information to each other. Other functions of the Session Layer are: - the ability to send a "request to send" signal upstream against the (half-duplex) flow of data (like banging on the "attention" key); - the ability to send an "error" indicator, which will purge in-flight data and force the data flow to flop the error-sender into send-state; - pacing, so that the sender doesn't overrun the receiver; and - (optional) cryptography support, including secure verification of keys. Presentation Services comes in two flavors: Basic Conversations, and Mapped Conversations (which are implemented on top of the Basic ones). The data records sent on Basic Conversations (which are mapped onto sessions) consist of a two-byte length field, followed by that many bytes of data. Mapped Conversations permit the user to send records of arbitrary length -- the Mapper breaks the user's record up (if necessary) into 32K chunks, preceeds each one with the two-byte length field, and sends them; on the other end, the Mapper reads in these chunks, reassembles them, and presents its user with the original record. In addition, Presentation Services contains a transaction model. The very first thing that is sent on a newly-allocated Conversation is a Function Management Header (FMH-5, to be exact) that tells the Presentation Services instance on the other end the name of a program that is to be invoked to handle this conversation. Also, it provides security information (e.g., the sender's user-ID and password) and recovery parameters (e.g., are we using one-phase or two-phase commit protocols). The two PS instances will handle all of the commit stuff, and are supposed to be able to clean up "in-doubt" conversations that failed during a sync-point operations. A communicating pair of LU-6.2 instances will bring up some number of idle sessions "at the beginning of time", just in case they will be needed -- a so-called "hot pool" of sessions. When an application program requests a new Conversation, the local LU-6.2 will select one of these idle sessions from its "hot pool" and assign it to the new Conversation. When the Conversation is deallocated, its session goes back into the hot pool. There are rules and protocols to try to avoid collisions when both LU-6.2 instances go to get a session out of the hot pool, and to resolve such collisions when they happen. So, a Conversation involves "borrowing" the use of a session for some duration of time. Since, in SNA networks, initiating sessions tends to be a bit on the expensive side, this is a technique for amortizing the cost of a session across many Conversations. If you are familiar with SNA, then LU-6.2 can be viewed as the successor to the SLU-P protocols used by the financial industry for doing one-in, one-out transactions, and to the LU-6.0 and LU-6.1 protocols used by IMS and CICS for transaction-like work. In my humble opinion, LU-6.2 is a Very Good design: for simple one-in, one-out transactions it is very efficient; for emulating datagrams (one-in, zero-out), it is as efficient as you could want; for "conversational" transactions where the applications at the two ends chit-chat back and forth forever, it also is very efficient. (I will not comment on the various IBM *implementations* of LU-6.2 -- only on the *architecture* itself.) A very stylized example, from the point of view of a program that is invoking a remote FTP server to retrieve a file (using the SAA calls): . . . conv_ID = initialize_conversation("Target.Host.Nickname"); set_TP_name(conv_ID, "FTP"); allocate(conv_ID); send_data("GET MOBY.FILE"); /* for instance */ status, length = receive(&buffer, sizeof(buffer)); while (status == DATA_RECEIVED) { /* write the buffer into our local file */ status, length = receive(&buffer, sizeof(buffer)); } if (status == DEALLOCATE_NORMAL) deallocate(conv_ID); else { ...error handling... } . . . Note that the allocate() call will start the process of acquiring an appropriate session from the hot pool. The receive() call will flop the send/receive state of the conversation, putting me into receive state and the other program into send state. I'm assuming here that the FTP server deallocates the conversation after sending the file; actually, it probably puts up a receive() to see if I want to do anything else, in which case I would get a 'status' of YOUR_TURN_TO_SEND when I hit the end of the transmitted file. If I have nothing else to do, then I would deallocate() the conversation, which would propagate a DEALLOCATE_NORMAL status indicator over to FTP, which would presumably then terminate. I hope that this has been useful for the readers of this list... John Pershing IBM Research, Yorktown Heights