Browse Prior Art Database

Using SNA Logical Unit 6.2 for Efficient Message Transport

IP.com Disclosure Number: IPCOM000109061D
Original Publication Date: 1992-Jul-01
Included in the Prior Art Database: 2005-Mar-23
Document File: 4 page(s) / 158K

Publishing Venue

IBM

Related People

Housel, BC: AUTHOR [+2]

Abstract

In order to have an effective distributed messaging system for on-line transaction processing, it must be possible to have a very efficient means for transporting a stream of messages from one node to another. This article describes how efficient message transport can be realized by using an optimized subset of Logical Unit (LU) 6.2 (LU6.2) that employs unidirectional conversations and a message blocking technique based on LU6.2 logical records. A basic understanding of SNA and LU6.2 is assumed.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 49% of the total text.

Using SNA Logical Unit 6.2 for Efficient Message Transport

       In order to have an effective distributed messaging
system for on-line transaction processing, it must be possible to
have a very efficient means for transporting a stream of messages
from one node to another.  This article describes how efficient
message transport can be realized by using an optimized subset of
Logical Unit (LU) 6.2 (LU6.2) that employs unidirectional
conversations and a message blocking technique based on LU6.2 logical
records.  A basic understanding of SNA and LU6.2 is assumed.

      There are two models for implementing services conversations:
Fig. 1 shows the message send and receive processes as being standard
LU6.2 transaction programs that employ the LU6.2 Advanced
Program-to-Program Communication (APPC) verbs.  Fig. 2 shows the
message send and receive processes as part of the LU that implements
the LU6.2 services.  This type of implementation does not offer an
open APPC application program interface (API) and is referred to as a
closed LU6.2 implementation.  Closed LU6.2 implementations may be
restricted and/or optimized for a certain purpose.  Specifically,
movement of data can be minimized and task scheduling functions can
be tailored to the specific server functions.  Both models conform to
valid LU6.2 protocols and servers written in accordance to Fig. 1 may
converse with servers implemented according to Fig. 2.  This article
facilitates efficient message transport through the use of message
blocking, elimination of conversational responses flows, and reducing
scheduling overhead.

      The following terms are used.  A block buffer is a buffer used
by the message send/receive processes to send/receive message data.
For closed implementations, the blocking buffer may be the same as
the SNA Request Unit (RU) buffer.  A blocking record (BR) is an LU6.2
logical record that contains an integral number of encoded messages;
the acronym LBBR denotes an IBM Generalized Data Stream (GDS)
introducer where LL is a two-byte length filed and BR is a two-byte
registered code-point that identifies this LU6.2 record as a blocking
record.  A message is a self-describing unit of data that is sent
from a PUT process and asynchronously delivered to a GET process (see
Figs. 1 and 2).

      Message Sending Rules:  These rules are captured by pseudo code
below.  Parenthesized text (i.e.,(...)) denotes a logical expression
that determines control flow.  Bracketed test (i.e. [...]) denotes
action to be performed.  Text in braces (i.e., {...}) is explanatory
comments.
SO1. Get a blocking buffer and initialize it by assigning the first 4
bytes as LLBR where the "LL" value is yet to be determined.
SO2. WHILE(input queue is not empty)
     [
SO3. READ the next message from the input queue.
SO4. SELECT
     [
SO5. WHEN(there is room in the blocking buffer for the message)
      [Move the message to the blocking buffer.]
SO6. WHEN...