This document is subdivided into the following topics:
SNA Distribution Services (SNADS) is a formally defined, application-level protocol for asynchronous distribution of objects (e.g. memos, documents and status notifications) in a SNA network.
Con-nect SNADS can run in one of the following environments:
Com-plete and EntireX Broker Services (LU6.2 API)
batch mode and EntireX Broker Services (LU6.2 API)
CICS
Con-nect SNADS is a full implementation of the SNADS architecture allowing Con-nect to participate in a SNADS network according to the specifications given in the IBM manuals Systems Network Architecture Format and Protocol Reference Manual: Distribution Services (SC30-3098) and Document Interchange Architecture: Transaction Programmer's Guide (SC23-0763).
Documents and memos can be exchanged between Con-nect and any other system providing a SNADS interface. Typically, these are other office systems (such as DISOSS), which provide SNADS services for their users.
A Con-nect system can originate and receive status notifications that refer to SNADS distribution objects previously received or sent.
A Con-nect system can act as an intermediary between SNADS systems and relay SNADS distribution objects from one SNADS system to another.
The functionality of Con-nect SNADS is available to the end-user through the following Con-nect functions:
Send
Inbasket
Outbasket
The end-user can work in Com-plete or some other TP monitor (e.g. CICS or TSO), provided that there is a Con-nect SNADS system in a one of the environments mentioned above which has access to the same Con-nect system file and spool file as the end user's Con-nect .
Con-nect SNADS follows the IBM terminology. The following are the most important IBM abbreviations:
- DSU
Distribution Service Unit - a node within a SNADS network.
- DSUN
Distribution Service Unit Name - the node name, which must be unique within the network. It identifies a specific location within the network. A DSUN consists of two parts: RGN and REN.
- RGN
Routing Group Name - the first part of the DSUN (optional).
- REN
Routing Element Name - the second part of the DSUN (mandatory).
Note:
SNADS allows a node in the network to assume the role of more
than one DSU; i.e. each node can have more than one DSUN.
- DIU
Distribution Interchange Unit - an interchange unit used to convey objects between DSUs when the distribution function is performed. Distribution objects are messages and documents which are enveloped by control information to make up DIUs.
- DU
Distribution User - the originator and recipient of the DIUs. Each DU is located at a specific node (DSU) within the SNADS network. Individuals, departments and applications are possible DUs.
- DUN
Distribution User Name - each DU has a two-part name that is unique within the network. The DUN consists of a DGN and a DEN.
- DGN
Distribution Group Name - the first part of the DUN (mandatory).
- DEN
Distribution Element Name - the second part of the DUN (mandatory).
Note:
A SNADS address consists of a DSUN and a DUN.
SNADS employs a "store-and-forward" technique for the distribution of DIUs. DIUs are distributed using LU6.2 sessions over an underlying SNA network.
SNADS does not require each node within the network to be adjacent to every other node. (Adjacent means that a direct communication link is established between two nodes of a network in order to convey a DIU.)
A DIU that is to be communicated from a SNADS node to a non-adjacent node can travel via a number of intermediate nodes (relay nodes) to the recipient's node.
Upon receipt, each relay node stores the DIU in a local data repository and then determines to which SNADS node the DIU is to be passed. Each SNADS node only needs to determine to which of its neighbors a specific DIU should be forwarded to bring it closer to its destination.
SNADS allows for multi-destination distributions. Each DIU can be sent to more than one recipient.
Since the SNADS distribution mechanism does not use a global directory, a recipient's DUN alone does not provide enough information to pass a distribution to the proper destination; hence both the recipient's DUN and his location's DSUN must be available to the basic SNADS procedures. Con-nect SNADS does this via the general Con-nect functions for defining external mail nodes and via routing table entries, which must be defined by the administrator.
To help clarify the above mentioned terms and abbreviations, consider the following description of a sample SNADS network, consisting of five nodes.
NEW.YORK is the DSUN (Distribution Service Unit Name) of the SNADS node in the upper left corner of the diagram. It consists of two parts: the RGN (Routing Group Name) NEW and the REN (Routing Element Name) YORK.
ESHBERRY.JOHN is the DUN (Distribution User Name) of one of the DUs (Distribution Users) who are located at this node. The DUN consists of two parts: the DGN (Distribution Group Name) ESHBERRY and the DEN (Distribution Element Name) JOHN.
The SNADS address for this user consists of the DSUN and DUN.
A Con-nect user can act as a SNADS DU. A DUN can be assigned to him either explicitly (requiring a specific DUN assignment for that user) or implicitly (by use of a default assumption without requiring a specific DUN assignment).
A Con-nect system can act as a SNADS node (with one or more DSUNs assigned to it). A Con-nect node is identified by a spool file and one or more Con-nect system files. One Con-nect spool file can service several Con-nect system files. Each DSUN that is assigned to a Con-nect system is linked to only one Con-nect system file. A Con-nect system file can, however, have more than one DSUN linked to it.
If you send a Con-form document, the text is formatted in the Txt format when sent. However, if you suppress this feature (either by pressing the PF-key which is assigned to the FORMAT command or by changing the send defaults with the DEFAULT command), the document is sent in its original Cnf format.
The Con-nect SNADS Send feature handles documents of the following formats:
Txt (will be converted to FFT-DCA)
Cnf (will be converted to FFT-DCA)
FFT
RFT
Bin (will be marked as "PC Data File")
Note:
The "Cnf-to-FFT-DCA" conversion does not imply formatting in the
sense of Con-form. The conversion to FFT-DCA format for Cnf-and Txt-type
documents is very basic. The conversion to FFT-DCA format and the preparation
of the subject line performs a character translation for the IBM-defined Code
Page with Global ID 256 and the Graphic Character Set with Global ID 337
according to the "Local Language" specified in the Con-nect SNADS control
record and according to the setup of the CONDTR1 module.
When a message or document, which is intended for a local Con-nect user, is received from a SNADS distribution, Con-nect SNADS passes the object on to the recipient's Inbasket. The documents received must be in one of the following formats:
FFT-DCA (will be converted to Txt or Cnf)
RFT-DCA (received unchanged as RFT)
PC Data File (will be marked as Bin)
Note:
The remark concerning the conversion feature of the Con-nect SNADS
Send function is also valid for the Receive function.