Using a List Processor to Send Files

A list processor is a special service link that processes files with distribution lists. Suppose you need to send a file to five people. Normally, you would use the CMS SENDFILE command to send one copy of the file to each of the five people:

SENDFILE STATUS REPORT TO AJ LEE MARTIN MATT OLIVER

This means there are five copies of STATUS REPORT in the network:

SMSG RSCS QUERY QUEUES
Ready;
 Pos   Loc      Origin         Destination     Link
 in Q   ID Node     Userid   Node     Userid   Queue    Status
    0 1003 NEWYORK  KATHYB   NYDEVSYS ACITELLI BB3      sending
    1 1010 NEWYORK  KATHYB   NYDEVSYS OHARE    BB3      waiting
    2 1016 NEWYORK  KATHYB   LONDON   TASKER   BB3      waiting
    3 1021 NEWYORK  KATHYB   NYDEVSYS MCKRELL  BB3      waiting
    4 1025 NEWYORK  KATHYB   BOSTON   TAVAKOLI BB3      waiting
 5 files found

If you wanted to ask one or two people to review a specific section of the report, you would have to send one (or more) notes, thus increasing the number of files in the network. When many people throughout your network send files in this manner, your network file queues can fill up rather quickly.

The list processor handles file traffic more efficiently. Instead of sending one file to each person, you send one file (containing a distribution list) to the list processor. The easiest way to send such a file is using one of the sample programs shipped on the RSCS base tape: SENDLIST or PROFLIST. For example:

SENDLIST STATUS REPORT TO AJ LEE MARTIN MATT OLIVER (FORCE

The FORCE option tells RSCS to send the file to the list processor. If you do not specify the name of the list processor, SENDLIST assumes the name is *LIST. In this document, *LIST is used as the node ID and link ID of the list processor. If your list processor has a different name, you can use the LISTNODE option to specify the name of your list processor. (For more information about the SENDLIST sample program, see the associated Help file, SENDLIST HELPCMS.)

When the list processor receives your file, it looks at the distribution list and decides the optimum number of copies of the file to send to the next destination in the network. For example, suppose you were at node NEWYORK which has a list processor called *LIST and your network looked like this:

Skip over ASCII art.


   +---------+           +----------+
   |         +---------->| NYDEVSYS |
   |         |           +----------+
   | NEWYORK |
   |         |           +--------+           +--------+
   |         +---------->| BOSTON +---------->| LONDON |
   +---------+           +--------+           +--------+

The figure shows a network in which NEWYORK is linked to NYDEVSYS and BOSTON, and BOSTON is linked to LONDON.

If you used the preceding SENDLIST command, the list processor would split your file into two files:

Destination Location	Destination User	Number of Data Set Headers	Distribution List
NYDEVSYS	MULTI	3	ACITELLI at NYDEVSYS OHARE at NYDEVSYS MCKRELL at NYDEVSYS
BOSTON	MULTI	2	TASKER at LONDON TAVAKOLI at BOSTON

If the file contains data set headers for more than one node, the destination location is the link ID over which RSCS is sending the file and the destination user is *MULTI*, which means the file has a distribution list (multiple data set headers). If the file contains data set headers destined for the same node, the destination location is the target node ID and the destination user is *MULTI*. If there is only one data set header in the file, the destination location is the target node ID and the destination user is the target user ID.

Once the NYDEVSYS *MULTI* file reaches node NYDEVSYS, RSCS splits it into three files, one for each user at NYDEVSYS. Once the BOSTON *MULTI* file reaches node BOSTON, the list processor splits it into two files, one for TAVAKOLI at node BOSTON and one for TASKER at node LONDON. Because the file destined for LONDON is only destined to one person, it is not a *MULTI* file. Here is your network with the files being sent:

Skip over ASCII art.


               NYDEVSYS
   +---------+ *MULTI*   +----------+
   |         +---------->| NYDEVSYS |
   |         |           +----------+
   | NEWYORK | BOSTON                LONDON
   |         | *MULTI*   +--------+  TASKER   +--------+
   |         +---------->| BOSTON +---------->| LONDON |
   +---------+           +--------+           +--------+

The figure shows the NYDEVSYS *MULTI* file being transmitted from NEWYORK to NYDEVSYS, the BOSTON *MULTI* file being transmitted from NEWYORK to BOSTON, and the LONDON TASKER file being transmitted from BOSTON to LONDON.

Therefore, instead of sending five individual files throughout the network, you sent three: one to NYDEVSYS, one to BOSTON, and one from BOSTON to LONDON. The longer your distribution list, the more you save using the list processor.