🚀 go-pugleaf

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