This section is divided into five parts. The first three correspond to those commands available for use by the general user, list owners and file owners, and the LISTSERV maintainer. The last two describe how to send commands to LISTSERV and how to register LISTSERV passwords. Non-privileged users can send commands by mail or by interactive commands. (Note that interactive commands can only be sent if a two-way NJE or MSGD connection exists.) Privileged users can send commands by mail, interactive commands (subject to the same restriction previously noted) or via the console (VM) or the LCMD utility (non-VM).
Unless otherwise noted, commands are listed in alphabetical order, with the minimum acceptable abbreviation in capital letters. Angle brackets are used to indicate optional parameters. All commands which return a file accept an optional '
F=fformat' keyword (without the quotes) that lets you select the format in which you want the file sent; the default format is normally appropriate in all cases. Some esoteric, historical or seldom-used commands and options have been omitted.
Note: Some commands are not available on all platforms; these commands are marked appropriately.
Continuation cards (see the Advanced Topics Manual for LISTSERV regarding LISTSERV’s Command Jobs Language) can be used to split long commands (for instance, ADD commands for users with long X.500 addresses) into two or more 80-character cards. In that case you must insert "// " (two slashes followed by a space) before the command text and a comma at the end of each line of the command so that CJLI considers it as a control card and performs the required concatenation. For instance,
// GETPOST MYLIST 10769-10770 10772 11079 11086 11095 11099-11100 11104 ,
The SUBscribe command is LISTSERV's basic command, issued by users to join mailing lists. This command can also be used to change one's "full_name" field in LISTSERV's SIGNUP database (simply reissue the command with the changed name). Note that the full_name is not required if the user has previously signed up to lists on the same LISTSERV server, or if the user has previously registered in LISTSERV's SIGNUP database by using the REGISTER (q.q.v.) command.
indicates that the user wishes to join the list anonymously, that is, without specifying a name. The CONCEAL subscription option is automatically set, granting the subscriber the maximal level of protection available.
allows you to "preset" subscription options at subscribe time. For instance, you might want to subscribe to MYLIST-L in order to be able to search its archives, but don't want to receive postings. You would use the command
Or you might want to receive individual postings with the SUBJecthdr option and receive copies of your own postings instead of the standard acknowledgement that your message was distributed to the list:
Confirming:> SUBSCRIBE MYLIST-L Joe User
You have been added to the MYLIST-L list.
JOIN is a synonym for SUBscribe.
The SIGNOFF command allows the user to cancel his or her subscription to lists.
SIGNOFF requires a qualifying parameter, as follows:
listname Sign off of the specified list
* Sign off of all lists on that server
* (NETWIDE Sign off of all lists in the LISTSERV network
The "* (NETWIDE" parameter causes the LISTSERV server to forward a copy of the signoff request to all other registered LISTSERV servers. This is a good option for a user who is changing service providers or otherwise losing a specific address that will not be forwarded. Please note that this parameter will not remove the user from non-LISTSERV lists or from LISTSERV lists running on non-registered sites. It will also not work if the server to which you issue it is running in STANDALONE runmode.
LISTSERV will attempt to sign off the address it finds in the RFC822 "From:" line and will not "fuzzy match" for "similar" addresses. The single exception is when the hostname part of the address is aliased to another hostname in LISTSERV's centrally-maintained ALIASES NAMES file.
This form of the CHANGE command can be used by any subscriber. It must be sent from the currently-subscribed address and results in an OK confirmation request being sent back to that address. This cookie then MUST be confirmed by the currently-subscribed address, exactly as it was entered, or the command will fail. This is the only case where a LISTSERV cookie must be confirmed by a specific address. Note that this assumes that the user still has login access to both addresses, or at least the ability to send mail from the old address.
|
•
|
ACK – A mail message acknowledging the receipt and distribution of the user's posting is sent back to the user.
|
|
•
|
NOACK – No posting acknowledgement is sent. In general, this setting should only be used if the user has also set himself to REPRO, as it is desirable in most cases that some indication of whether or not the posting was received by LISTSERV be sent.
|
|
•
|
MSGack – (Obsolete) An interactive message is sent to acknowledge receipt and distribution. Note that this works only if both the machine running LISTSERV and the user's machine have NJE connectivity (e.g., BITNET). If NJE connectivity is not available on both ends, this option is effectively the same as NOACK.
|
|
•
|
CONCEAL – Allows the user to be concealed from the REVIEW command. Note that the list owner or LISTSERV maintainer can always get the complete list of subscribers, regardless of this setting.
|
|
•
|
Files/NOFiles – (Obsolete) These options toggle the receipt of non-mail files from the list. Note that this is NJE-specific, and thus obsolete for systems without NJE connectivity, but retained for compatibility.
|
|
•
|
Mail/NOMail – These options toggle the receipt of mail from the list. Users who will be away from their mail for an extended period of time may prefer to simply turn the mail off rather than to unsubscribe, particularly if subscription to the list is restricted in some way.
|
Note: For backward compatibility, the command SET listname MAIL sent by a user who is set to DIGEST but not also set to NOMAIL will cause the user to be set to NODIGEST (the behavior is identical for users set to INDEX but not to NOMAIL). SET listname MAIL sent by users set to DIGEST/NOMAIL or INDEX/NOMAIL will simply remove the NOMAIL setting and leave the user set to DIGEST or INDEX as the case may be.
|
•
|
DIGests/INDex/NODIGests/NOINDex – These options change the format in which list mail is received by the subscriber. DIGEST turns on digest mode, in which the subscriber receives a digest of postings at set times dependent on how the "Digest=" keyword of the list is set. INDEX turns on index mode, in which the subscriber receives a daily listing of subjects posted to the list, from which he or she may order postings of interest. NODIGEST and NOINDEX toggle the mode back to individual postings sent as received by LISTSERV. Note that these options are interrelated; setting one will negate another.
|
|
•
|
REPro/NOREPro – Causes LISTSERV to send you a copy of your own postings as they are distributed. Some users may prefer this behavior to the ACK option (see above).
|
|
•
|
MIME/NOMIME – Toggles MIME options on and off. Currently only digests are available in MIME format. If DIGEST mode is set, the user will receive a MIME digest instead of the regular plain-text digest. Note that you must have a mail client that supports MIME digests (Pegasus is one that does) or this setting will do you little good. This option is automatically set at subscribe time for users who send their subscription command using a MIME-compliant agent, unless "Default-Options= NOMIME" is specified for the list.
|
|
•
|
HTML/NOHTML – Toggle the HTML function for digests and indexes on and off.
|
|
•
|
TOPICS: ALL | [+/-]topicname – For lists with topics enabled (see the Topics= list header keyword), subscribe or unsubscribe to topics. For instance, if a list has topics SUPPORT and CHAT, a user could subscribe to CHAT by sending SET TOPICS +CHAT. Or the user could unsubscribe to SUPPORT by sending SET TOPICS -SUPPORT. Finally, the user can subscribe to all available topics by sending SET TOPICS ALL.
|
|
•
|
FULLhdr – "Full" mail headers, (default) containing all of the routing information.
|
|
•
|
SHORThdr – (Obsolete) Short headers (only basic information about the message - Date, From, Subject, To -- is preserved). Setting SHORThdr will break MIME-encoded messages, so it should be used only on lists where MIME and HTML messages are not allowed.
|
|
•
|
DUALhdr – Dual short headers, useful with older mail programs which do not preserve the RFC822 return email address. Same caveat as with SHORThdr.
|
|
•
|
SUBJecthdr – "Full" mail headers (like the default) except that setting this option tells LISTSERV to add the list's default subject tag to the subject line of mail coming from the list. (See the listing in the List Keyword Reference document for "Subject-Tag=" for more information.) Note that if the user is set to SHORThdr (or any other header option other than FULLhdr), LISTSERV will automatically switch the user to FULLhdr, as subject tags require full headers. A subject tag is generated (for subscribers with the SUBJecthdr option set) even if the original message had no "Subject:" header. To turn the subject tagging off, the user simply sends a new SET command with any of the other header options (e.g., SET listname FULLhdr) and the SUBJecthdr option is reset.
|
|
•
|
FULL822 – Essentially the same as "full" mail headers, but with the important difference that the recipient's email address is specified in the "To:" line rather than the address of the list. " FULL822" headers should be used with extreme caution, as they cause LISTSERV to create a separate mail envelope with a single RFC821 RCPT TO: for each address so set. This behavior can significantly affect the performance of both LISTSERV and of your external mail system.
|
|
•
|
SHORT822 – Essentially the same as "short" mail headers, with the same caveats as noted for FULL822.
|
Note: FULL822 and
SHORT822 headers should only be used if a specific problem indicates that they might solve the problem. One possible use would be to determine which subscriber from a specific site is causing the site to throw back delivery errors if that site does not specify which RCPT TO: is generating the error. These headers should never be used by default.
Documented Restriction: The use of the
SHORTHDR or
DUALHDR options will break messages that depend on MIME encoding, because these options strip the RFC822 headers that identify the message as a MIME message.
SHORTHDR and
DUALHDR were designed for the non-MIME mail clients which prevailed in LISTSERV's early history. As most mail clients today support MIME, the use of these options is now deprecated.
The CONFIRM command should be issued when LISTSERV requests it. A request for
CONFIRM should not be confused with a "command confirmation request" which requires an "OK" response. The
CONFIRM command is used in two cases:
The INDEX command sent to LISTSERV without further qualification sends back the contents of the "root" level archive filelist on VM systems (LISTSERV FILELIST) or archive catalog on non-VM systems (SITE.CATALOG plus the contents of SYSTEM.CATALOG).
If the INDEX command is sent with the name of a list (e.g.,
INDEX MYLIST) or the name of a special filelist or catalog file (e.g.,
INDEX TOOLS, if TOOLS FILELIST on VM or TOOLS.CATALOG on non-VM exists), LISTSERV sends back the contents of the specified filelist or catalog. Several possibilities exist:
|
•
|
rec -fm – Indicates whether the file is in a fixed or variable record format.
|
|
•
|
lrecl – Logical record length. For a file with fixed record format (F), this is the length of each record. For a file with variable record format (V), this is the maximum record length.
|
|
•
|
nrecs – Number of records (lines) in the file.
|
|
•
|
Detailed – All local lists, complete with full header information.
|
|
•
|
Global xyz – Only those whose name or title contains 'xyz'.
|
|
•
|
SUMmary [host] – Membership summary for all lists on specified host, or the host to which the command is sent if no host is specified.
|
|
•
|
SUMmary ALL – Membership summary for all hosts (long output, send request via mail).
|
"Lists Global" without a search string, which returns the entire list of lists, may no longer be issued by general users. General users should use the "Lists Global /xyz" format to search the list of lists, or (preferably) use L-Soft's CataList service at
http://www.lsoft.com/catalist.html.
"Lists SUMmary", when issued to an unregistered host or to a host running in STANDALONE mode will generate the response "No information available yet - please try again later." because the file required for this function does not exist.
Query your subscription options for a particular list (use the SET command to change them). Using the "*" wildcard in place of the name of a single list queries subscription options on all lists on the server.
Register's the user's full name field in LISTSERV's SIGNUP files, or changes the current value of that field. When a user's name is registered, he or she can omit the full name field from subsequent SUBscribe requests to that server. Sending "REGISTER OFF" to LISTSERV deletes the user's entry from the SIGNUP file.
Get information about a list, assuming the list header keyword "Review=" is set appropriately. For general users,
REVIEW does not return address information about subscribers who are set to
CONCEAL. The options are:
|
•
|
BY sort_field – Sort list in a certain order:
|
|
•
|
Country – Sorts by country of origin (ISO country codes).
|
|
•
|
Date – Sorts by subscription date (newest to oldest).
|
|
•
|
Name – Sorts by user name (last, then first).
|
|
•
|
NODEid – Sorts by hostname/nodeid
|
|
•
|
BY (sort_field1 sort_field2) – You can specify more than one sort field if enclosed in parentheses. For instance, BY (NODE NAME).
|
|
•
|
Topics – Adds a breakdown of subscribers per topic (if Topics= is defined in the list header) at the end of the subscriber list. If you just want the breakdown, use REVIEW listname SHORT TOPICS. This does not show topics by individual subscribers (see the QUERY command instead). If Topics= is not enabled for a given list then this option is ignored.
|
|
•
|
LOCal – Don't forward request to peers. This is only useful if the list is peered; normally it should not be necessary to issue this option.
|
|
•
|
Msg – Send reply via interactive messages ( BITNET users only).
|
|
•
|
NOHeader – Don't send list header, just send the subscriber list.
|
|
•
|
Short – Don't list subscribers, just send the header and the membership summary for the list.
|
Note: You can get a quick read of the number of subscribers on the list by sending the command
REVIEW listname SHORT NOHEADER.
|
•
|
ALL – List concealed members (who will show up with "[concealed]" next to their entry) as well as non-concealed members. (NOT available to general users even if Review= Public.)
|
Scan a list's membership for a name or address. Helpful if a user attempts to send a SET command or an UNSUB command and is informed that their address is not subscribed to the list. At the non-privileged level, this command will show all non-concealed entries that match the search text, assuming that the list is set to "Review= Public".
Obtain a list of commonly-used LISTSERV commands. Also explains how to get the comprehensive reference card and tells who the (non-hidden) server manager(s) are.
Order a LISTSERV manual, or get a list of available ones (if no topic was specified); or get information about a list. For Info listname, the text in the INFO template form of listname.MAILTPL is used; however, if listname.MAILTPL does not exist or does not contain an INFO template form, the INFO template form of DEFAULT.MAILTPL is used.
|
•
|
Flags – Get additional technical data (useful when reporting problems to experts).
|
|
•
|
HARDWare or HW – Hardware information; what kind of machine is LISTSERV running on?
|
|
•
|
LICense – License/capacity information and software build date.
|
|
•
|
LINKs [node1 [node2 [...]] – Network links at the BITNET node(s) in question.
|
|
•
|
NADs [node1 [node2 [...]] – Addresses LISTSERV recognizes as node administrators for the specified site(s).
|
|
•
|
NODEntry [node1 [node2 [...]] – BITEARN NODES entry for the specified node(s).
|
|
•
|
NODEntry node1 /abc*/xyz – Just the ' :xyz.' tag and all tags whose name starts with ' abc'.
|
|
•
|
POINTs [ALL | list1 [list2...]] – Graduated (LISTSERV Classic) license point information. This information can help you plan orderly expansion of your site if you are running with a graduated LISTSERV Classic license. Under Lite this command shows Classic point usage.
|
|
•
|
STATs – Usage statistics for the server (this is the default option).
|
|
•
|
VERSion – Same output as RELEASE command.
|
|
•
|
BITEARN – Statistics about the BITEARN NODES file.
|
|
•
|
DPATHs host1 [host2 [...]] – DISTRIBUTE path from that server to specified host(s).
|
|
•
|
FIXes – List of fixes installed on the server (non-VM see SHOW LICENSE).
|
|
•
|
NETwork – Statistics about the NJE network.
|
|
•
|
PATHs snode node1 [node2 [...]] – BITNET path between 'snode' and the specified node(s).
|
To control the format in which LISTSERV returns the file(s) to you, you can specify the
F=fformat parameter. Supported formats are
Netdata, Card, Disk, Punch, LPunch, UUencode, XXencode, VMSdump, MIME/text, MIME/Appl, Mail.
To split very large files into manageable chunks, you can specify the SPLIT=integer parameter. The integer value is the size you want the chunks to be generated, in kilobytes. For instance if you were ordering a 2MB notebook log and wanted to break it into 100KB chunks, you would specify
SPLIT=100. This is handy for people whose mail systems place a limit on the size of an individual mail message that may be received by a given user.
Sends a file stored in a LISTSERV file archive to someone else. For instance, you may want to send LISTSERV REFCARD to a new user. Rather than retrieving LISTSERV REFCARD and then forwarding it to the user, you simply issue a GIVE command to tell LISTSERV to send it directly. Note that the token "TO" is optional.
|
•
|
ADD firstpw – Define a password for the first time, or after a PW RESET. Requires confirmation via the "OK" confirmation method.
|
|
•
|
CHange newpw [PW=oldpw] – Change your existing password. If you do not include your old password for authentication, LISTSERV will require confirmation via the "OK" confirmation method.
|
|
•
|
REP password – Starting with 1.8d, this function is a hybrid of " ADD" and " CHange". If a password does not exist for the user, one will be added. If a password does exist for the user, it will be changed (with confirmation required via the "OK" confirmation method). " REP" was added primarily for use by the web archive and administration interface but can be used in e-mailed PW commands as well.
|
|
•
|
RESET – Reset (delete) your password. This function always requires confirmation via the "OK" confirmation method.
|
|
•
|
FOR user ADD/DEL/LIST etc – Perform requested function on behalf of a user you have control over (wildcards are supported for DEL and LIST).
|
Note: Starting with 1.8d, the ability to send DISTRIBUTE jobs is limited to LISTSERV Maintainers by default, and requires a password. This section is retained for compatibility with 1.8c and earlier, and for 1.8d and later servers which have the DISTRIBUTE security feature turned off.
|
•
|
MAIL – Data is a mail message, and recipients are defined by '<dest>'.
|
|
•
|
FILE – Data is not mail, recipients are defined by '<dest>'.
|
|
•
|
RFC822 – Data is mail and recipients are defined by the RFC822 'To:'/'cc:' fields.
|
|
•
|
DD=ddname – Name of DD holding the data to distribute (default: 'DD=DATA').
|
|
•
|
<TO> DD=ddname – Use a DD called ddname for the destination addresses, one recipient per line.
|
|
•
|
CANON=YES – 'TO' list in 'canonical' form (uid1 host1 uid2 host2...).
|
|
•
|
DEBUG=YES – Do not actually perform the distribution; returns debug path information.
|
|
•
|
INFORM=MAIL – Send file delivery message to recipients via mail.
|
|
•
|
TRACE=YES – Same as DEBUG=YES, but file is actually distributed.
|
GETPost is used after receiving the output of a SEARch command to retrieve the postings you want from the SEARch output. For instance, if you want postings numbered 1730, 1731, 1732, and 1840 from the MYLIST list, send the command
In previous versions, the GETPost command returned messages that contained MIME attachments in their "raw" form, which could not be extracted automatically by MIME-aware mail clients. Customers who wished to use list notebooks to archive word-processing documents (for instance) found this to be a problem. From LISTSERV 1.8e, attachments returned in messages by way of the GETPost command will now display as inline clickable links in the individual messages.
Users of certain email clients (specifically Pine, which handles attachments in a secondary viewing area) may find the new format difficult to use. If preferred, the pre-1.8e behavior may be reverted to by specifying "NOMIME" as the last parameter of the GETPost command.
The Search command syntax is similar to that of the SEARCH/SELECT commands in the "old" database functions. A very basic Search command for list MYLIST would look like this:
Search search_string IN MYLIST
Search search_string IN MYLIST SINCE 96/01/01
Search search_string IN MYLIST WHERE SENDER CONTAINS ERIC
Note: The "new" Search command does not require a CJLI job framework to operate; simply send the Search command in the body of an email message to the appropriate server. LISTSERV will respond with an index of the postings matching your criteria and instructions on how to use the GETPost command to retrieve the posts you want.
Restore service to a user whose access to LISTSERV has been disabled. This generally occurs when a user has sent 51 incorrect commands in a row to LISTSERV, which LISTSERV interprets as a possible mail loop. (Note also that certain mail packages that send "Read:/Not Read:" notifications back to LISTSERV will trigger this scenario after 51 iterations. The best solution would be for the user to disable receipt notifications.) The user in question cannot restore his or her own service; this command must be issued from another userid. Note that if the user has been manually served out by privileged user (a LISTSERV maintainer), the
SERVE command must be issued by a similarly-privileged user (who must also be a LISTSERV maintainer, although naturally the same user who issued the
SERVE OFF command can issue the
SERVE command).
Note: The
THANKs command will not reset the serve-off counter (so vacation messages or auto-replies that contain a sentence starting with something like "Thanks for writing" will not defeat the system and users sending them will eventually be served off instead of continuing to loop ad infinitum).
|
•
|
Search DD=ddname <ECHO=NO> – Perform database search (see the VM version of LISTDB MEMO for more information on this)
|
|
•
|
List – Get a list of databases available from that server
|
|
•
|
REFRESH dbname – Refresh database index, if suitably privileged
|
PUT fn ft <filelist <NODIST>>
|
•
|
<PW=password> – Supply your password for command authentication.
|
|
•
|
<CKDATE=NO> – Accept request even if the current version of the file is more recent than the version you sent
|
|
•
|
<DATE=yymmddhhmmss> – Set file date/time.
|
|
•
|
<RECFM=F <LRECL=nnn>> – Select fixed-format file (not to be used for text files).
|
|
•
|
<REPLY-VIA=MSG> – Request reply via interactive messages, not mail (Requires NJE connectivity).
|
|
•
|
<"parameters"> – Special parameters passed to FAVE routine, if any.
|
|
•
|
TITLE=file title – Change file "title" in filelist entry.
|
|
•
|
GET fn ft <filelist> – Get a list of people subscribed to a file you own.
|
GET fn FILELIST <(options>
|
•
|
CTL – Return filelist in a format suitable for editing and storing back.
|
|
•
|
NOLock – Don't lock filelist (use in conjunction with CTL).
|
REFRESH filelist <(options>
|
•
|
NOFLAG – Don't flag files which have changed since last time as updated (for AFD/FUI).
|
ADD(*) listname user [
full_name]
ADD(*) listname DD=
ddname [IMPORT [PRELOAD]]
The first syntax is used to add an individual user to one of your lists, or update his name field. Note that you can substitute an asterisk ("*") for
full_name and LISTSERV will substitute "<No name available>" in the list.
The second syntax is used for bulk ADD operations where a dataset (DD=ddname) is used add multiple users, one address/name pair per line. For bulk operations you may also use the
IMPORT option, which implies a
QUIET ADD (in other words you do not need to specify
QUIET if you use
IMPORT) and otherwise vastly speeds up the
ADD process by loosening syntax checking and omitting success messages. The
IMPORT PRELOAD option is used to direct LISTSERV to preload the existing e-mail keys in memory before starting the transaction, which speeds the operation up considerably. This option is used primarily with DBMS lists to speed up bulk adds.
PRELOAD is not necessary for traditional LISTSERV lists and does not normally lead to a significant performance improvement. However, when importing a new list (no existing subscribers), it does reduce CPU usage somewhat.
For a bulk ADD operation, the users are defined in a separate dataset beginning on the line following the
ADD command. For instance,
ADD listname DD=ddname IMPORT
//ddname DD *
userid@host.com User Name
userid2@host.com User2 Name
... more address/name pairs, one per line ...
/*
Same as ADD, but means "add the user on this peer, do not forward this request to a (possibly) closer peer". For non-peered lists, is functionally identical to
ADD.
The first form can be used by any subscriber and results in a cookie being sent to the new address. This cookie MUST be confirmed by the new address, exactly as it was entered, or the command will fail. This is the only case where a LISTSERV cookie must be confirmed by a specific address.
The list owner form does not use cookies but simply applies the standard "Validate=" rules (as for a DELETE command). You can specify a wildcard pattern for the old address and *@newhost for the new address to rename certain addresses to a new hostname. The CHANGE1 template is sent unless you specify QUIET.
|
•
|
Global – Forward request to all peers
|
|
•
|
LOCal – Don't try to forward request to closest peer if not found locally
|
|
•
|
TEST – Do not actually perform any deletion (useful to test wildcard patterns)
|
|
•
|
BRIEF – Good for deleting wildcard patterns (such as *@*) when you don't want a "userid@host has been deleted from list xxxx" for each user deleted. Returns instead only a count of the users that were deleted.
|
|
•
|
BESTpeers n – Suggest the N best possible peers to add.
|
|
•
|
FOR node – Perform analysis as though local node were 'node'.
|
|
•
|
PREFer node – Preferred peer in case of tie (equidistant peers).
|
|
•
|
SERVice – Check to see that service areas are respected.
|
|
•
|
With(node1 <node2 <...>>>) – Perform analysis as though specified nodes ran a peer.
|
|
•
|
WITHOut(node1 <node2 <...>>>) – Opposite effect.
|
|
•
|
Global – Forward request to all peers.
|
Get a copy of a list in a form suitable for editing and storing the list and lock it so that other list owners can't modify it until you store it back (or until you or they issue an
UNLOCK command). The options are:
|
•
|
Global – Forward request to all peers.
|
|
•
|
HEADer – Send just the header; on the way back, only the header will be updated. This is the recommended way to modify your list header.
|
|
•
|
NOLock – Do not lock the list.
|
|
•
|
OLD – Recover the "old" copy of the list (before the last PUT).
|
|
•
|
Global – Forward request to all peers
|
|
•
|
OWNed – Returns a list of local lists owned by the invoker.
|
|
•
|
MODerated – Returns a list of local lists that are moderated by the invoker.
|
Move a subscriber to another peer. Do NOT use this command to move users from one list host site to another during migration. It is strictly for moving subscribers from one peer to another peer.
|
•
|
listname DD=ddname – Move several subscribers to various peers
|
Use of the PUT command to store a list header with new subscriber data at the bottom (e.g., an attempt to add subscribers "on the fly") will result in only the header of the list being stored, and in the generation of the following warning:
Warning: New subscriber data was found in the replacement list you sent, possibly due to the use of a signature file with an unusual separator line. If you really meant to update the subscriber data, please resend your request with the word "PUT" replaced with "PUTALL". For now, only the list header will be updated.
Documented Restriction: PUTALL does not work with DBMS lists; only the header information is replaced. Subscriber information in the DBMS table is not changed. For DBMS lists where the subscriber information needs to be replaced
in toto, either the DBMS should be manipulated with your regular DBMS tools or you should use
ADD IMPORT.
Documented Restriction: Because it is resource-intensive, the REINDEX command is considered a "maintenance" command as opposed to an "everyday" command, and should not be issued in production environments outside of regularly-scheduled maintenance windows.
The REINDEX maintenance command rebuilds the WWW indexes (default), database indexes, or both for one or more lists. This command requires list owner privileges.
The wildcard * or the literal ALL is supported to mean "all lists". List owners will be able to rebuild indexes only for their own lists. LISTSERV maintainers may rebuild indexes for all lists on the server.
Notes: By default, web indexes will be rebuilt in the background on LISTSERV Classic HPO unless you specify the IMMEDIATE option. In additions, there is no background reindexing support for LISTSERV Classic non-HPO.
The main reason to use REINDEX is to retroactively add RSS abstracts to an existing list. It may also be useful if an archive file is edited by accident or if there is a corrupt file or the like. LISTSERV Classic non-HPO sites with one or more very large and active list(s) may also wish to run this command when upgrading to HPO.
On non-VM systems where there are no web indexes, normally there is no reason at all to rebuild your database indexes, other than in cases of disk corruption or in an upgrade to HPO coupled with the presence of a list with very large archives.
When rebuilding web indexes, BOTH the HTML files AND the INDxxxx files are reindexed. While there may be legitimate reasons for wanting to rebuild the HTML files (template changes, etc), it is NOT recommended to use the REINDEX command to accomplish that, as the overhead involved in rebuilding the INDxxxx files is prohibitive if they do not actually need rebuilding.
With LISTSERV Classic there is no background support, so REINDEX * should be scheduled for "quiet" periods if there are many lists and/or lists with large archives.
While a particular list has its indexes rebuilt, WA browsing accesses will generally fail and/or LISTSERV will throw "listname.html" not found errors. There is no good way to avoid that since the goal is to recreate the entire index structure from scratch, and during that process files will be deleted and not be available until they are rebuilt.
By default, database indexes are reset and will be rebuilt the next time they are needed; this is a fast operation. Under HPO, the IMMEDIATE option may be used to cause an immediate rebuild of all database indexes if absolutely necessary, but remember that the immediate rebuild will block the server from doing anything else until it completes. However, this can be a useful command when migrating an entire server or perhaps just a single list during off hours and it is desired to pre-index everything so that the server is snappy when traffic increases in the morning.
|
•
|
REView/NOREView – Postings from user go to list owner or moderator even if user is otherwise allowed to post.
|
Unlock a list after a GET, if you decide not to update it after all, or unlock a list if it has been locked by another list owner or by the LISTSERV maintainer. Note that if you are not the person who originally locked the list, it is considered good practice to ask the person who originally locked the list whether or not they are done with the list before you unlock it.
All LISTSERV maintainer commands require a password for validation when issued by email. Commands issued by TELL or SEND from the local host or via the LCMD utility do not require password validation. (Commands issued by LCMDX do require password validation. LCMDX, the LISTSERV TCPGUI demonstration program, is not the same as the LCMD utility shipped with LISTSERV.)
where 'flag' can be either the name of a debug flag or its corresponding hex value. A plus sign turns on the flag, minus turns it off, no sign sets the specified flag and clears all others. The command updates the session debug flags as requested, then displays a summary:
* Debug flags for this session: 00000022
*
* 00000001 TRACE_DIST [Trace DISTRIBUTE processing - OFF]
* 00000002 TRACE_MIME Trace MIME parser
* 00000004 TRACE_LISTS [Trace (a few) list-related functions - OFF]
* 00000008 TRACE_SPAM [Trace spam filter calls - OFF]
* 00000010 TRACE_EMM [Trace Embedded Mail-Merge processor - OFF]
* 00000020 TRACE_DEV Temporary ad hoc tracing for development use
* 00000040 TRACE_FSAV [Trace FSAV calls - OFF]
* 00000080 TRACE_LDAP_CALLS [Trace LDAP library calls - OFF]
* 00000100 TRACE_LDAP_DATA [Trace data obtained from LDAP - OFF]
* 08000000 HOLD_DISTBG [Do not process background DISTRIBUTE jobs - OFF]
* 10000000 HOLD_XB64 [Hold X-B64 jobs instead of processing them - OFF]
* 20000000 KEEP_JOBFILES [Keep successfully processed job files - OFF]
* 40000000 TRACE_TCPGUI [Additional TCPGUI tracing - OFF]
Flags that have not yet been assigned a function will display as RESERVED in the summary and do nothing. The TRACE_DEV flag is used by L-Soft Development to trace various aspects of whatever is being worked on at the time. While TRACE_DEV may be enabled by site maintainers (and in certain cases the support department may request that TRACE_DEV be enabled for debugging purposes), the results will vary depending on the build (and will not be publicly documented for that reason).
Any changes made using the DEBUG FLAGS command are for the current session only (they will be reset when LISTSERV is restarted). For certain purposes it can make sense to have some flags permanently turned on, and the DEBUG_FLAGS site configuration variable remains available for those special cases.
Execute a command on behalf of another user (LISTSERV maintainers only). Note that this command is provided for debugging purposes only -- it provides a method for a LISTSERV maintainer to send commands "from" the specified user. It is not recommended to use this command syntax in production, for instance to issue SET or SUBSCRIBE or UNSUBSCRIBE commands on a user's behalf. For instance, the LISTSERV maintainer should use, respectively, the "SET listname options FOR userid@host", "ADD
listname userid@host", or "DELete
listname userid@host" syntaxes in preference to the "FOR
userid@host command" syntax.
|
•
|
Global – All known lists, one line per list, sent as a (large!) file. Only LISTSERV maintainers may request this list, as it has become a favorite pastime of Internet mailbombers to issue LIST GLOBAL commands on behalf of users whose mailboxes they wish to bomb. You should direct users who request "the whole list of lists" to L-Soft's CataList service at http://www.lsoft.com/catalist.html.
|
|
•
|
OWNED BY internet_address – Returns a list of local lists owned by the userid@host specified. Wildcards are acceptable.
|
|
•
|
MODerated BY internet_address – Returns a list of local lists moderated by the userid@host specified. Wildcards are acceptable.
|
Regenerate all LISTSERV network tables, or just compile the links weight file (debugging command). This happens automatically when LISTSERV is rebooted if a new BITEARN NODES file is found. Otherwise you should issue a NODESGEN whenever you update BITEARN NODES.
Create a new list. Requires the CREATEPW for validation when issued from a remote node. You may specify initial subscribers, one per line, following the list header when creating a list. See also the PUTALL command in Section 14.2.2
List Management Functions.
|
•
|
Query user – Query the password of the specified user.
|
SERVE user OFF [DROP] | LIST
SERVE user OFF permanently suspends access from an abusive user or gateway (restore service with
SERVE user).
Adding "DROP" (for example, SERVE user OFF DROP) to the command is identical to
SERVE user OFF except that the postmaster will not receive any notification messages from LISTSERV when/if the user continues to try to post.
Stop the server, and (optionally) restart it immediately (by specifying either REBOOT or
REIPL -- the two options are synonymous). This is available on all platforms.
|
•
|
DISAble – Disable interactive database access, without shutting down existing sessions
|
|
•
|
ENAble – Re-enable interactive access
|
|
•
|
SHUTDOWN – Shut down all interactive database sessions, and disable interactive access
|
|
•
|
CLEANUP BEFORE dd mmm yy – Remove all shipments installed before that date
|
|
•
|
PASSWORD shipment PW=instpw – Confirm installation of a shipment, when requested by LISTSERV
|
|
•
|
RELOAD shipment – Attempt to reload a shipment which failed due to a disk full condition
|
|
•
|
STATus – Get a list of installed "shipments"
|
Update a CMS file on one of LISTSERV's R/W mini-disks; note that this is similar to SENDFILE + RECEIVE or LINK + COPYFILE and should NOT be used to update file-server files
In addition to the standard SHOW functions available on other servers, VM servers support the following functions:
|
•
|
EXECLoad – Statistics about EXECLOADed REXX files.
|
|
•
|
LSVFILER – Statistics about LSVFILER file cache.
|
|
•
|
PREXX – Statistics about PREXX functions usage.
|
|
•
|
STORage – Information about available disk space and virtual storage.
|
Note: Some debugging commands and options have been omitted.
You will see numerous references to "sending commands to LISTSERV" in this and other L-Soft manuals. All LISTSERV commands are sent to the server either by email or via the web administration interface described in Section 6
Introduction to the Web Interface. For mailed commands, this means that you must create a new mail message using whatever command this requires for your mail client (click on "New message" or its equivalent for most mail clients) addressed to the LISTSERV address. Let’s say for the sake of argument that the list you are managing is running on a server called
LISTSERV.MYCORP.COM. In order to send a command to that server, you would create a new message and address it to
LISTSERV@LISTSERV.MYCORP.COM, and place the command(s) in the body (not the subject) of the message.
The passwords recognized by LISTSERV for various operations (assuming that the NOPW parameter is not used with the "Validate=" keyword) are of two distinct types:
|
•
|
Personal Passwords – LISTSERV can store a personal password in its signup files corresponding to your userid. This password not only can be used for list maintenance operations, but also protects your FUI (file update information) and AFD (automatic file distribution) subscriptions (if available on your server) and must be used to store your archive files, if any, on the server.
|
|
•
|
List Passwords – List passwords are technically obsolete except in one particular case (peered lists, which require each peer to have the same password). We mention them here only because users upgrading from earlier versions will be aware of their existence. You should define and use a personal password for all protected operations.
|
If you do not include the old password in the command (e.g., you’ve forgotten it), LISTSERV will request an "OK" confirmation. Otherwise, it will act on the command without need for further confirmation (unless, of course, the
oldpassword provided is incorrect).
