So, release 1.5d is out as three SHIPMNTx files. I forgot to say that the
first time you start your 1.5d server, it will send mail to Harold, Jose Maria
and me about the release change so that I can immediately update the tables. I
was getting a little tired of the number of nodes whose release was uncertain.
:-)
A very brief description of the specifics of the file server functions, for
which the memos have not been written yet... For a general description of FACs
and suchlike you can still read the Netserv docs since it's more or less simi-
lar.
Each non-comment entry in the filelist defines a file. Generic fileids are
not (yet?) supported. You can additionally define "flags" for the file by
inserting them before the actual filelist entry, enclosed between / signs.
Example:
LISTSERV FILELIST V 95 ....
/abcdef/ LISTSERV FILELIST V 95 ....
a is the first flag byte, b the second, etc. Flags which are omitted take on
the default value. Note that flags will not appear in the filelist as sent to
users -- filelists are reformatted before being sent to users. A blank or
period will ALWAYS be accepted and means "default value".
Flag 1: F -- indicated a "true" filelist, ie one which defines other files.
The filetype of such a file MUST be "FILELIST". Files with a
filetype of FILELIST which come from other servers, eg SILMARIL
FILELIST, should NOT have this flag set.
P -- Indicate the file is kept in packed format (it is unpacked befo-
re being sent out). Not a good choice if you plan on linking to
the disk...
. -- default: none of the above.
Flag 2: N -- No AFD should ever take place for the file.
D -- AFD should be delayed until LSVXAFD is called from WAKEUP.
This is the default if byte 1 = F (filelists are supposed to be
updated quite often)
I -- Immediate AFD. Default for all other files.
. -- means D if flag1 = F, I otherwise.
Flag 3: N -- No FUI should ever take place.
D -- Delated FUI, default for all files.
I -- Immediate FUI, not recommended.
. -- Same as D
Flag 4: L -- Local file. Should not be redistributed to the servers defined
in Peers=.
. -- Global file, to be redistributed when PUT
Defining a FAC: FACs which are not hardcoded are defined in the filelist
header in the "*+" lines which appear in the first bunch of comments. For
efficiency reasons the search is ceased as soon as a blank line is encountered.
Format is:
*+ fac= userid@node comment
*+ fac= (listname) comment
*+ fac= Owner(listname) comment
*+ fac= * comment
"fac" is the 3-letters FAC (File Access Code) name, eg "LCB". As many "*+"
entries as required may appear, and they can be of any of the 4 forms above.
The first form is obvious. The second means "people subscribed to list xxx".
The third refers to the owners of a list, while the fourth is just a comment
to be displayed in the FAC definition portion of the edited filelist sent to
the user when a GET is done. It doesn't define anything. A password may be
associated with the fac:
*+ fac= PW=password
This password is the one to be used on a PUT operation for the file. If blank,
it defaults to the user's LISTSERV password, if any. Note that this form is
required for peer-filelists since the file owner might not have a password at
all the peer servers. It ensures that a common password is defined for the cor-
responding file at all the servers. Note that different passwords would mean
that some of the servers would reject the command....
The peer servers are defined with the following keyword:
*+ Peers= node1,node2,node3,....
Several occurences of the keyword just mean more peers. "*+ Peers= All" refers
to all the servers listed in PEERS NAMES. "Peers" must appear as I typed it, ie
it IS case sensitive due to the stupidity of the EXECIO interface which cannot
be told to CASE U when a DISKR is being done (I used DISKR & FIND /*+ Peers=/).
The peers keyword does not appear on the filelist as obtained by a GET command.
Do you think it should? I'm open to suggestions.
People interested in running a Netserv-cache system whereby their local users
would gain access to (some) Netserv files via a LINK to a public disk main-
tained automatically by LISTSERV should contact me -- I am starting to slowly
write such an interface to LISTSERV... A sample exit which does most of the
job is provided in "bypassed" form (ie preceded with an EXIT instruction) in
LSV$PUT EXEC. This would not work for NICSERVE of course since it doesn't
have an automatic file distribution concept -- everything is done manually,
file storing as well as INDEX updating...
You've seen it, there's a LISTSERV LISTS file defined in INFO FILELIST. We'll
eventually have a complete list of lists on which I'll try to list ALL the
known lists. I'll take the LISTSERV GROUPS from NICSERVE of course but since it
doesn't even list all the lists running on their LISTSERV (TECH-L is missing
for example) I'll need info from all of you to complete the file. If you are
main 'owner' of a list which is NOT listed in LISTSERV GROUPS from NICSERVE,
please send me a description of the list similar to the ones found on NICSERVE
-- please send the names of all the peers, I will not truncate them as per
the REXX Word(userids,1) instruction...
Eric
PS: I'll be quite busy next week cause I will *eventually* have a room on the
FRECP11 dorms ( :-) :-) :-) ) and I'll have to bring stuff there... :-(
I'll be able to program even more and still sleep more than now since I
won't have 1h30 of train+metro+walk to get back home... :-) Of course I'd
be able to program outrageously more than now and sleep even less but I'll
try not to choose that option too often ;-)
|
