informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/apple/DOCUMENTATION/listserv.txt

781 lines
40 KiB
Plaintext
Raw Permalink Blame History

Ok several people have requested that I post the help documentation on
LISTSERV servers, so here it is:
Revised List Processor (LISTSERV@FRECP11), Release 1.5d
----------------------------------------------------
(c) Eric Thomas 1986 Ecole Centrale de Paris
You can skip the introduction and go to the commands description by
instructing your text editor to locate the string "GENCOM" (eg "/GENCOM"
under XEDIT).
***********************************************
* What is LISTSERV? What is Revised LISTSERV? *
***********************************************
LISTSERV stands for "list server"... but what does that mean? Origi-
nally, LISTSERV was a mailing-list server which was designed to make
group communication easier. The first version of LISTSERV, written by
EDUCOM and installed at BITNIC under the userid of LISTSERV, offered
basic "mail-exploding" capabilities. People with a common interest (eg
network protocols, issues related to handicapped people in education,
system administration problems) were grouped in a list which was then
stored on LISTSERV. They could then communicate with each other by sen-
ding mail to a special network address (eg UG-L@BITNIC). Any piece of
mail sent to these special user-ids would then be automatically distri-
buted by the list server to each and every person on the list. You did
not have to know all the names and network addresses of the people sub-
scribed to the list. The usual messages sent by the mailing systems
when mail has been successfully delivered were sent to LISTSERV -- a
big relief for the sender... People could join a list by asking the
"list coordinator" (actually the person who maintains the list server)
to be added to the list and it was a very convenient way to meet people
and participate in interesting discussions/forums.
As LISTSERV became popular and the number of lists grew, it started
to show some weaknesses and limitations. Even though LISTSERV was ins-
talled at a central site, it generated a very important traffic because
there was an important number of people from distant nodes in the net-
work. If there were ten persons of the same node on a given list, it
sent ten copies of each piece of mail to the node. List maintenance be-
came a problem because of the evergrowing number of requests for sub-
scription. Mail headers became bigger and bigger, and 30 lines was not
an uncommon size. Some non-VM users had troubles accessing the server,
could not send commands nor mail to it and received files in a format
their system was not able to read. Non-mail files could not be sent to
a list. The server was often caught looping on a rejection mail from a
network mailer. No help or command description was available, and
unknown commands were ignored. Sending a "HELP" command did not
produce any kind of answer from the server.
Revised LISTSERV is a brand new list processor which was developped
at the Ecole Centrale de Paris in France to overcome the restrictions
and lack of functionnality of the first version of LISTSERV. It retains
the basics of the old LISTSERV and provides good ascending compatibili-
ty, while offering more sophisticated functions, helpfiles and more
user-friendliness. Revised LISTSERVs can be linked together to create
peer lists for better network efficiency in a way that is nearly trans-
parent for the user. Users can send a command to the server to subscri-
be to a list. For more information about the differences between the
BITNIC-type LISTSERV and Revised LISTSERV, send the following command
to the nearest Revised LISTSERV: Info FEATures (or just: I FEAT)
! Additionally, Revised LISTSERV provides powerful file-server func-
! tions which allow list moderators to make pertinent datafiles and/or
! programs available to the subscribers of their lists. For more informa-
! tion on this new feature, issue the following command to the nearest
! Revised LISTSERV: Info FILE
********************************************************************
* Terminology and general information about LISTSERV documentation *
********************************************************************
All the information guides available from LISTSERV follow the IBM
convention that changes since last release are indicated by a vertical
bar in column one. These vertical bars are "reset" when the release
number is incremented. Post-releases (indicated by a lowercase letter
following the release number, eg "1.3c") will have exclamation marks in
column one to indicate the changes from the base release (1.3 in our
example) and to differentiate them from the vertical bars that must be
reset when the next version (1.4 in our example) is released. Temporary
restrictions/warnings will be indicated by a ">" sign in column one and
will stay until the restriction is removed or the warning is no longer
applicable.
Backwards compatibility of all documented features will be kept
across release changes unless technically impossible (eg a feature
which is discovered to be incompatible with system security). Applica-
tions programmers should be careful not to use any feature or command
which is not documented since these are subject to change without noti-
ce.
All throughout the LISTSERV documentation, several terms will be used
to refer to distribution lists, mailing systems, etc. Here is a short
definition for some of them:
"Distribution list", "LISTSERV list", "list": this is a list of per-
sons to be used by LISTSERV to distribute mail and/or program files.
It can be reviewed by sending a "REView" (qqv) command to the server
"List title": this is the "title" of the list, eg "IBM 7171 protocol
converter list". It appears in the "Sender:" field of every piece of
mail distributed to the list.
"List name": this is the 1-8 characters name by which a distribution
list is identified to the server. It will often end in "-L", eg
"CHAT-L", "UG-L", etc.
"List userid": this is the network address/userid@node/mailbox to
which mail and files must be sent in order to be redistributed to
the list. The first part ("userid") will always be the list name
(see above), while the second part ("node") is the node name of the
LISTSERV server. Examples: CHAT-L@DEARN, UG-L@BITNIC. The domain
name (if required by your mailing system) is always ".BITNET"
"LISTSERV userid": this is the network address of the LISTSERV ser-
ver, eg LISTSERV@FRECP11. The userid will usually be LISTSERV, but
could be something else due to accounting conventions or suchlike.
This is the network address you must send commands to.
"List owner": the person(s) who maintain the list and who have autho-
rity to perform list-maintenance functions. You will sometimes get a
message saying that "Your request has been forwarded to the list
owner".
"List editor": the person, if any, who reviews material sent by users
to the list before allowing the server to distribute them. If the
list you send mail to is controlled by an editor, you will get a mes
sage saying that "Your mail has been forwarded to the list editor".
Most distribution lists do NOT have an editor and mail received by
the server is distributed "as is".
"File format": the "format" in which a computer file is transmitted
across the network. There are several formats which all have limita-
tions or flaws, and are not necessarily supported by all operating
systems. LISTSERV can send files in five different formats: Punch,
Disk Dump, Card Dump, Netdata and Listserv-Punch (issue an "Info
LPunch" command for more information on the latter). It accepts only
three formats as input: Punch, Disk Dump and Netdata.
> Card Dump format will be accepted as input in a future version.
> There is no need to support Listserv-Punch format as input.
*******************************************************************
* Who should I contact if I have a problem with Revised LISTSERV? *
*******************************************************************
In much the same way as hierarchy does not exist in Revised LISTSERV
lists (all the servers are peers), there is no hierarchy in the LIST-
SERV "management", but three complementary categories of persons:
- The list owners: each list will have one or more owners, who are
authorized to add or remove people from the list, change the list
attributes, etc. They will have this authority on all the peer LIST-
SERVs serving their list, and can be considered as "list managers".
They are the persons to contact if you have a problem which is speci
fic to a particular list, eg your name being misspelled in the mail
header ("To:"), your not being able to send mail to the list, etc.
Their name and network address appear in the header of the list
definition file (which you can obtain by sending a "REView" command
to the server -- see below) under the keyword "Owner=".
- The "postmasters": each LISTSERV will have one or more postmasters
(send a "RELEASE" command to get their names and network addresses).
Postmasters are usually systems programmers and are the people who
maintain the list servers and make sure they operate properly. They
create and delete lists on their servers but do not maintain them --
that's what list owners are for. They have full authority over their
own server and all of its lists, but this authority does not usual
ly extend to other LISTSERVs. This means that even though they can
modify the copy of any list on their server, they will not be able
to affect peer lists on other servers (if any). They do not qualify
for list maintenance, unless the list has no peer.
Being system administrators, postmasters are usually pretty busy and
it will probably take them longer to answer a question than list
owners. It is therefore your interest to make sure that you do not
send them complaints that ought to be directed to list owners, and
they will be thankful for the time you are saving them. Typical
questions that should be sent to postmasters are: "LISTSERV is not
logged on, is it normal?", "Here is a copy of a piece of mail I sent
to LISTSERV and it said it was not valid, why?", etc.
- The LISTSERV coordinators: their names, network addresses and task
are defined in LISTCOOR MEMO (send an "INFO COORD" to obtain it).
Basically, they (try to) provide technical help information to the
postmasters, assist new LISTSERV owners in installing the code,
coordinate the placement of the servers and distributed lists on the
network and correct bugs in the software. They have no special autho
rity or privilege on the LISTSERVs or their host systems and there-
fore do not qualify for list or server maintenance. They should be
contacted mainly by postmasters, and only for reporting bugs, sugges
ting improvements to the software and for questions that the owners/
postmasters were not able to answer. They should of course be con-
tacted for obtaining a copy of the LISTSERV code.
The following 3 sections are designed to help non-BITNET or non-VM/SP
users in sending commands to LISTSERV and mail to distribution lists. If
you are on a BITNET VM system and you are familiar with this concepts,
just do a "/GENCOM" command to skip to the commands description.
****************************************
* How can I send commands to LISTSERV? *
****************************************
Commands can be sent to LISTSERV in three basic ways: interactive
messages, mail, and non-mail files. The distinction between mail files
and non-mail files is very important on some systems and inexistant on
others; some systems provide only mail files, and some will only have
normal files. In the following discussion it will be assumed that you
want to send an "Info GENintro" command to LISTSERV at FRECP11 (or
LISTSERV@FRECP11.BITNET in RFC822 terms).
A) Interactive messages
Interactive messages is a facility that is not available to all sys
tems; besides, only computers which are directly connected to BITNET
can send interactive messages. However, this is the fastest and most
convenient way of sending commands to LISTSERV: all you have to do is
send it a message with the command text as message text. Example:
"*message* Info GENintro", where "*message*" is the command that must
be used on your system to send an interactive message to LISTSERV at
FRECP11.
- On VM/SP systems, this command is "TELL LISTSERV AT FRECP11", ie
what you must do is "TELL LISTSERV AT FRECP11 Info GENintro". You
could also use CP SMSG rscs MSG FRECP11 LISTSERV Info GENintro,
where "rscs" is the name of the RSCS virtual machine at your site.
- On MVS systems with TSO/E, this command would be TRANSMIT or XMIT:
"TRANSMIT FRECP11.LISTSERV NOPROLOG"
When the message text screen is displayed, enter "Info GENintro"
as first text line and press PF3 to send it.
- On some JES2 systems, the command could be TO, VMSG or XMSG, depen
ding on the local implementation:
"TO LISTSERV@FRECP11 Info GENintro"
- On VAX systems the command would be "SEND" or "SEND/MSG":
"SEND LISTSERV@FRECP11 Info GENintro"
- Other systems might, or might as well not, have a command for
sending interactive messages. Please send any appropriate informa-
tion to the author for inclusion in this help file, other users
will be thankful for the hint.
B) Mail files
Those systems which do not have interactive messaging capabilities
will usually have a mailing system (although this is not necessarily
the case). "Command jobs" can be submitted to LISTSERV via RFC822,
PROFS, or IBM NOTE formatted mail. Systems which are not capable of
sending mail in any of these standards must resort to the third
method (see below). Command jobs can also be used by people on sys-
tems which do have interactive messaging capabilities for the usual
reliability reasons (messages can be lost in a line glitch while
files are *much* safer), and also because command jobs allow several
commands to be submitted at once and give better control on their
output. They are ideal for commands generated by programs or servers,
as opposed to commands sent by human persons.
| You can obtain a detailed description of the commands-job feature
| by sending an "INFO JOB" command to LISTSERV.
To send a command to LISTSERV via mail, all you have to do is send
mail to the LISTSERV mailbox and type in the command text as first
line in the mail body or note or whatever it is called in your sys-
tem. You can enter additional commands if required, as long as you
type each command on a separate line. You will get a reply via RFC822
mail, regardless of the mail agent you used to submit the command.
- All VM systems can send IBM NOTEs by issuing a "NOTE LISTSERV AT
FRECP11" command. Issue a "HELP NOTE" command for more information
on the IBM NOTE command format.
- VM systems equipped with a Crosswell mailer can send RFC822 mail
by issuing a "MAIL LISTSERV@FRECP11" command. The subject field is
ignored and needs not be specified.
- PROFS users will have no problem finding out how to send PROFS
mail to LISTSERV; however, the piece of mail must be sent as
MAIL and not as a DOCUMENT. Documents cannot be sent to LISTSERV
because LISTSERV is not a PROFS user.
- Note: Netdata files in NOTE format generated by MVS systems are
not considered as "mail" files unless they contain an IBM NOTE
formatted header, which is usually not the case. You should there-
fore expect them to be processed as non-mail files when sent to
the LISTSERV userid.
- There are other commands on other systems of which the author is
not aware of. Any information would be appreciated.
C) Non-mail files
Those systems which do not have interactive messaging capabilities
nor mailing facility will be able to transmit normal files, otherwise
! they would not be on a network... To submit a command job to LIST-
! SERV via non-mail file, all you have to do is to prepare a file (or
! dataset) containing the required commands, one command at a line, and
!> send it to the LISTSERV userid using the appropriate command. The
!> "//" trick which was mandatory with the previous releases of LISTSERV
!> is no longer required to identify the file as a command job; it will
!> of course still be accepted (and may even speed up command processing
!> under certain conditions).
- On VM systems the command is "SENDFILE filename filetype TO
LISTSERV AT FRECP11". There are a lot of other specialized com-
mands depending on the format you wish to use, but SENDFILE will
work. Please note that CARD format is not accepted as INPUT to
LISTSERV, although it does know how to generate it if specifically
requested (see "F=" keyword description).
- On MVS systems the command will usually be:
"TRANSMIT FRECP11.LISTSERV DATASET(dsname)", where dsname is the
! name of the dataset containing the command lines.
Most MVS systems will also accept the following job:
// EXEC PGM=IEBGENER
//SYSUT2 DD SYSOUT=A,DEST=(FRECP11,LISTSERV)
- On Multics systems the command is "sdm" and you must specify a
destination of LISTSERV at node FRECP11 when prompted to enter it.
! You must then enter "Info GENintro" as mail contents.
******************************************
* How do I send mail to a LISTSERV list? *
******************************************
To send mail to a LISTSERV distribution list, you will have to know
the network address of this list. In the following discussion we will
assume that you want to send mail to "SAMPLE-L@FRECP11.BITNET" (or, in
IBM terms, SAMPLE-L at FRECP11). Mail can be sent to a distribution
list in either of the two following ways:
A) Using a mailing system
If your system is equipped with a mailing facility, all you have to
do is send mail to the network address mentioned above. Refer to the
information in the previous section for a description of the command
to be used on your system.
Note: MVS NOTEs in Netdata format fall in this category, even though
they do not have a valid IBM NOTE formatted header. LISTSERV will ge-
nerate a standard header and insert it on top of the note.
B) Without any mailing system
If your system is not equipped with a mailing facility, you will
have to resort to files. Note that LISTSERV distributed mailing is
primarily designed to work on systems who DO have a mailing facility;
| sending mail as a normal file is always possible (see below) but can
| be quite tedious.
| Mail can always be sent to a distribution list by means of the
| DISTRIBUTE MAIL command. To do so, you must prepare a distribution
| job as indicated in LISTDIST MEMO (you can obtain this memo by sen-
| ding an "INFO DIST" command to LISTSERV) with the list userid as one
| and only destination, and a valid RFC822 mail (header + text) as
| "data". This method should be used only if the network interface in
| your system is so poor that no other method can be used.
To send mail to SAMPLE-L@FRECP11, you will have to prepare a file
named "anything NOTE", "anything.NOTE", etc, as dictated by your
system's file naming conventions. The file name can be anything while
the file type/extension/whatever must be "NOTE" (all caps please).
This file must contain the text to be distributed to the list, and
nothing else. It must be sent "as is" to SAMPLE-L@FRECP11.BITNET,
using the appropriate method. LISTSERV will generate a header and
add it on top of the file.
*******************************************************
* How do I send files to LISTSERV for redistribution? *
*******************************************************
To send a file to LISTSERV for redistribution, all you have to do is
to send the desired file "as is" to the list userid. No header should
be inserted, and no particular name is to be used. The only restriction
on the file name is that the filetype/file-extension/whatever it is
! called on your system must not be "MAIL" nor "NOTE". The only restric-
! tion on the contents of the file is that it must not be a Netdata NOTE
! NOTE file nor a PROFS-mail formatted file (otherwise it would be
classified as a mail file).
In some instances where the list owner suspects that files might in-
voluntarily be sent to the list userid although they are not destined
for being redistributed, he will have enabled an additional test to be
performed on the files before redistributing them. In that case the
server will expect files destined for actual redistribution to have a
"FORM" value of "REDIST" (or "QUREDIST" if you want to trigger the
"Quiet file transfer" feature installed at some RSCS sites). This is
indicated by a "Formcheck= Yes" keyword in the list header (send an
"Info KEYwords" for more information on list control keywords). Not all
systems allow the user to control the FORM value of network files. On a
VM system you would have to issue a "CP SPOOL PUNCH FORM REDIST" before
issuing the SENDFILE command. On a MVS system you would have to expand
the SYSOUT= parameter of the IEBGENER dataset: SYSOUT=(A,,REDIST)
***********************************************
* Commands description (non-privileged users) * ---> GENCOM <---
***********************************************
A description of command-keywords format (eg "F=") can be found at
the end of this section. Please refer to it for more information on
how, where and when to specify these keywords.
Info <? | topic> <F=fformat>
Sends you an information file like this one. Use "Info ?" for a list of
topics. Please note that some of the documents available through the
INFO command are restricted to certain categories of users.
Help
Sends you a brief description of the most useful commands, along with
the names and network addresses of the server's postmasters.
List <Detailed | Long | Short> <F=fformat>
Get a description of all lists. The default option is "Short", and will
send you a brief description of each list (via messages). The "Long"
and "Detailed" options are synonyms and will send you the "header" por-
tion of each list (via file).
Query listname
Displays your list distribution options for the corresponding list.
Refer to the SET command description for more details on the meaning of
these options.
SUBscribe listname <your_full_name>
SIGNUP
Use this command to subcribe to a list. You will be automatically added
to it unless the list owner has disabled this option, in which case he
will be sent a request-for-addition note. If you have misspelled your
name when issuing this command in the first place, you will be able to
correct it by re-issuing it without having to sign off from the list
first. In that case no notification is sent to the list owner. Note
that it is not necessary to supply your full name if you have already
signed up to another list of the same server. The name you provided on
your first signup command will automatically be used for the new
subscription. Also note that you will always be able to issue a signup
command to correct your name, regardless of the list being open for au-
tomatic subscription or not: as long as you are already on the list,
the SUBSCRIBE command is not disabled (unless the list is set to
"Validate= All commands" to protect you from UREP hackers and suchlike
who might issue a SUBSCRIBE command "from" you and change your name to
something you would not want to see in front of your userid; in that
case, your request will be forwarded to the list owner).
| In the case that the list has one or more peers and that the server you
| are sending your SUBscribe request to is not the nearest to your node,
| it will automatically determine the nearest host server for the list
| you are subscribing to and forward your request to it. This applies
| only if you are not yet subscribed to the list, of course.
SIGNOFF listname
UNSubscribe
This is the counterpart of the SUBSCRIBE command. Note that you can
remove yourself from any list you have been added to, unless it is
specially protected by a "Validate= All commands" keyword. Whether you
have subscribed to the list yourself or you have been added to it by
the list owner is irrelevant.
SET listname options
Mail/NOMail
Files/NOFiles
ACK/NOACK/MSGAck
Changes your distribution options for the specified list. You can spe-
cify more than one option if desired. The previous settings will be
retained unless specifically changed, ie if you want to change only one
of the options you do not have to specify the settings of the options
you do not want to change if they differ from the standard ones.
If the list is protected by a "Validate= All commands" keyword, your
command will not be executed but it will be forwarded to the list
owner.
Mail/Nomail indicate whether you want to receive mail from this list or
not. The default value is "Mail", of course.
Files/NOFiles indicate whether you want to receive non-mail files from
the list or not. The default is "Files", but it is recommended that no
more than one person per node has this option active on any given list,
for obvious network efficiency reasons.
ACK/NOACK/MSGAck define the mode in which acknowledgements for mailing
or file distribution are to be sent to you. ACK is the default and in-
dicates that you want a file acknowledgement (short mail file which in-
cludes some statistics on the mailing). NOACK directs the server not to
send out any acknowledgement; a single message will be sent to you when
the file has been processed, but nothing else. MSGAck indicates that
you are interested in the statistics report contained in the acknowled-
gement but want it sent to you as messages rather than mail. It is pro-
bably the best alternative for local lists (ie lists comprised of users
from your local node only).
REView listname <(options> <F=fformat>
LOCal
Msg
Countries
Short
NOHeader
Sends you the (formatted) contents of a list. Private lists cannot be
! reviewed by users who do not appear on it. However, the header of the
! list (without any information about the subscribers) will still be sent
! to you even if you are not authorized to review the list, as long as
! you would qualify to obtain this header by means of a "List Detailed"
! (qqv) command.
The command will be automatically propagated to all the linked servers,
if any, so that you get the complete list of all the persons who are
subcribed to the list, not just the local subcription. For a descrip-
tion of the keywords defined in the list header, please issue an "Info
KEYwords" command to LISTSERV.
! If the list is a "centralized" one, ie a list without any peer, the
! output of the REVIEW command will have a fileid of "listname LIST". If
! the list is found to have one or more peers, the file will be sent as
! "listname nodeid" so that a different fileid is generated for each peer
! list. This will make it easier to keep a copy of the list on your disk.
The "LOCal" option indicates that you want only the list of subscribers
served by the local LISTSERV and that the command should therefore not
be propagated to the peer servers.
The "Msg" option causes the command output to be sent to you via inter-
active messages, unless it is larger than 30 lines.
The "Countries" option indicates that you want a summary of the number
of subscribers in each country, sorted by country name.
The "Short" options causes the list of subscribers not to be sent to
you: only the list header and possible country summary is sent out.
"NOHeader" is the counterpart of "Short" and suppresses the list header
but not the country summary nor the list of subscribers. Specifying
both "NOHeader" and "Short" is valid and will display only the number
of persons subscribed to the list, and possibly the country summary.
STats listname <(LOCal> <F=fformat>
Sends you the statistics report for the desired list. Note that statis-
tics may have been disabled for the list, or may not be available to
everybody. The report will indicate the total number of mailing opera-
tions, the number on (non-local) outbound mail files, the number of
(non-local) outbound 80-lines records and possibly the resulting net-
work load in "link.kbytes". A link.kbyte corresponds to one kbyte of
data being transferred across one link, 512 bytes of data being sent
over two links, etc. When this measurement is enabled, the server will
compute the distance between itself and all the recipients of the mai-
ling operation and compute the exact "link.kbyte" amount. Since this
operation takes a relatively important amount of CPU time and requires
relatively large data files, it may have been disabled by the postmas-
ter in some cases.
The "LOCal" option indicates that the command is not to be forwarded to
the peer servers linked to the list. The default is to propagate the
command to all the servers housing a peer copy of the list.
GET fn ft <filelist_name> <F=fformat>
SENDME
!
! Sends you the requested file provided you are authorized to retrieve
! it. A more detailed description of this command, including information
! about the optional "filelist_name" operand and the general structure of
! the FILELISTs can be found in LISTFILE MEMO (send an "Info FILE" com-
! mand to obtain it).
!
! Synonyms have been defined for the GETND, GETDD, GETPP and GET80 com-
! mands of Netserv. "GETND xxxx" is translated to "GET xxxx F=Netdata",
! etc. Note that in this implementation, GETPP and GET80 are strictly
! equivalents and will cause the file to be sent in Listserv-Punch format
! if its logical record length is greater than 80. Send an "Info LPUNch"
! command to LISTSERV for more information about Listserv-Punch format.
!
!>Note that the Netserv "prologtext" feature is NOT yet supported on the
!>GET command.
INDex <filelist_name> <F=fformat>
!
! Sends you the specified filelist (defaults to LISTSERV FILELIST). This
! command is strictly equivalent to "GET filelist_name FILELIST" and has
! been made available for compatibility with other file servers on the
! network.
PW ADD new_password
! CHange old_password new_password
! DELete old_password
!
! This command allows you to define yourself a password for use with LIST
! SERV, change that password, or delete it if you no longer need it. Note
! that the PW ADD function may have been disabled or restricted to a cer-
! tain category of people by the local LISTSERV management. Please con-
! tact the local LISTSERV management, not the author, if you find youself
! unable to use the PW ADD and think you ought to be able to use it.
!
! A more detailed description of this command and the use of passwords in
! LISTSERV can be found in LISTAFD MEMO (which you can obtain by means of
! an "Info AFD" command).
AFD ADD filename filetype <filelist_name> PW=password
FUI DELete filename filetype <filelist_name> PW=password
! GET filename filetype <filelist_name>
! List
! Query
!
! This command allows you to subscribe to a file or package which you are
! normally authorized to retrieve from the server by means of a GET com-
! mand (qqv). AFD/FUI DELete will remove your subscription to one or more
! files/packages (wildcard characters are accepted), while AFD/FUI List
! or Query will list the files/packages to which you have subscribed. The
! GET option allows file owners to request a list of people who have sub-
! scribed to their files.
!
! AFD refers to "Automatic File Distribution", ie automatic shipment of
! the updated file, while FUI refers to "File Update Information", that
! is notification of the update without the new file being automatically
! shipped to you. There are two different commands, FUI and AFD, with a
! (nearly) identical syntax, and two independent lists, one for FUI and
! one for AFD.
!
! A more detailed description of this command and the use of passwords in
! LISTSERV can be found in LISTAFD MEMO (which you can obtain by means of
! an "Info AFD" command).
!
! Note that the Netserv "prologtext" feature is supported on the AFD
! command. See LISTAFD MEMO for more information.
PUT filename <filetype <filelist_name <NODIST>>>
! <PW=password> <LRECL=nnn> <RECFM=V|F> <"parameters">
!
! This command allows file owners to store a file in the server. The
! default filetype is "LIST" and causes a normal list-storing operation
! to be performed (this can be useful for list owners whose networking
! system does not allow them to send the file with a spool filetype of
! "LIST"). Note that the spool fileid is completely ignored by the PUT
! command. "NODIST" indicates the file should not be distributed to the
! other servers (in case the file is not a local one). The optional para-
! meters may be required for files which receive special handling -- con-
! tact the local LISTSERV operation staff if you have any doubt on this.
!
! A more detailed description of this command can be found in LISTFILE
! MEMO, which you can obtain by means of an "Info FILE" command.
RELEASE
Sends you information messages containing the release number of the
server and the names and network addresses of the server's postmasters.
This is the same information that you obtain from a HELP command, but
without the help information itself.
> Servers which have not yet installed version 1.4 or better of LISTSERV
> will not understand that command.
SERVE userid@node
|
| Returns service to a disabled user. To prevent loops and 'message wars'
| to occur, LISTSERV will automatically "disable" a user after receiving
| 10 invalid commands from him. Further commands will be completely igno-
| red without any error message being sent back, until service is resto-
| red from another userid/account by means of the SERVE command.
DISTribute < <MAIL> <DD=ddname> <FROM=userid@node | FROM=DD=ddname>
| <ACK=NOne | MAIL | MSG> <TO DD=ddname | u@n1 <u@n2...>> >
! <PRIOR=* | nn> <INFORM=MSG | MAIL>
|
| A complete description of the DISTRIBUTE command can be found in LIST
| DIST MEMO, which can be obtained from LISTSERV by sending it an "INFO
| DIST" command.
**********************************************************
* Command keywords: why, when, and where to specify them *
**********************************************************
Command keywords provide a means whereby some command-independent
information can be passed to the LISTSERV "supervisor" in a standard
way. Command keywords will be accepted on ANY LISTSERV command and they
will always be processed the same way; however, there will be commands
for which some or all of the accepted control keywords are irrelevant.
Only relevant keywords are listed in the commands description (see
above).
All command keywords can be specified anywhere in the command-text,
AFTER the command name itself. They can appear at the end, in the mid-
dle of the arguments of before the command arguments. A command keyword
is an expression of the form: " keywordname=keywordvalue " (the double-
quotes are not part of the keyword expression). The blank before the
keyword name is mandatory, while there must be NO blank between the
keyword name and the equal sign. There can be one or more blanks
between the equal sign and the keyword value. The reason for these res-
trictions is to avoid "finding keywords where none was intended".
Valid examples:
"REV F=Netdata CHAT-L (Countries"
"REV CHAT-L F= Netdata (Countries"
"REV CHAT-L (Countries F= Netdata"
Examples of improperly specified keywords:
"F=Netdata REV CHAT-L" (keyword must appear after command name)
"REV CHAT-L F = Netdata" (blank between "F" and the equal sign)
"REV CHAT-LF=Netdata" (missing blank before keyword name)
*********************************************
* Description of available command keywords *
*********************************************
Unrecognized keywords will be left unhampered in the command line, ie
you can use equal signs in command arguments without problem. Since key
words are processed before the command itself is analyzed, specifying
an improper value for a keyword will cause the command to be terminated
immediately without any further checking.
F= Netdata | Disk | Card | Punch | *
This keyword controls the "format" in which files will (possibly) be
sent to you. The default value, ie the value taken if the keyword is
omitted, is "*", which instructs LISTSERV to use the default file for-
mat defined by your system administrator in the BITEARN NODES database.
This format will (hopefully) be the most efficient format that your
operating system is able to handle. However, if this default format is
incorrect or if for some other reason you want files to be sent to you
in another format, you can specify a "F=" keyword to override the
default specification. Only the first letter of the format needs be
given. "Punch" format is automatically changed to "Listserv-Punch" if
the file being sent to you is larger than a card image (80 characters).
PW= password
This keyword provides a means whereby a "password" can be specified on
a LISTSERV command. The password to be given will be different depen-
ding on the category of command (list-maintenance, server-operation,
server-maintenance) and will be processed accordingly. Generally spea-
king, the command will be rejected or only partially honored if the
password is incorrect. General user commands will never require any
password, and thus the "PW=" keyword is irrelevant for general users.
Reference in New Issue View Git Blame Copy Permalink