Marty,
> 1. You get a copy of LISTSERV FILELIST from the LISTSERV 191 mdisk.
> Do this with a LINK or on LISTSERV. (Get the REAL file).
Although I myself prefer to work directly on LISTSERV, you can also do that
with the SF command, i.e. TELL LISTSERV SF LISTSERV FILELIST PW=storepw.
> By the way - I haven't figured out what the /F/ does but I left it in
> since the other entries had it... ;-(
/F/ means that this file is a 'true' filelist. LISTSERV allows storing files
with a filetype of FILELIST that are normal files, i.e. they are not part
of the LISTSERV file system. So, you must mark explicitly your FILELISTs with
a /F/ flag if you want them to treated as LISTSERV FILELISTs.
Please note that 'normal' files, i.e., files without /F/ or other possible
flags, should be shifted three columns to the left to make them coincide
with the header columns. That's to say, for normal files the /F/ flag must
be *deleted*, not *blanked*. I've seen other filelists where /F/ was blanked
and that seems to work, but a) it's ugly, and b) it makes some automatic
FILELIST-browsing programs to crash.
> I used some of the other FILELIST files as models but I deleted
> the *+ lines which seem to be special definitions. You add the files
> you know about to the FILELIST.
The '*+' lines define the File Authorization Codes (FACs) that will be used
later to state who can access or update each file. To simplify, you can code
*+ fac= userid@node full name
and then set 'fac' (three chars always) on the GET or PUT columns. You don't
need to create any FAC if the standard ones (i.e., ALL and OWN) are sufficient
for you. You can associate a FAC to more than one user, for example
*+ ABC= USER1@NODE1 User1
*+ ABC= USER2@NODE2 User2
Then if you code 'ABC' in the PUT column, only user1@node1 and user2@node2
will be able to modify the file.
You can also associate an entire list with a FAC:
*+ ABC= (NAIVE-L)
should create a FAC code satisfied only by members of NAIVE-L. If you change
'(NAIVE-L)' by 'Owner(NAIVE-L)', you are meaning the owners of NAIVE-L.
You can code comments into a FAC definition section:
*+ ABC= * This is the FAC code for the ABC group
*+ ABC= u1@N1 user1
*+ ABC= (NAIVE-L) Subscribers to list NAIVE-L
Those comments will be nicely reformatted when sending out the FILELIST as
requested by an INDEX command.
Finally, to store files into the filelist you'll need a password. You can
use either a) the storepw; b) a personal password defined by the PWC command
(see LISTMAST MEMO); or c) define a local password for use with this filelist
only, via
*+ ABC= PW=password
The password should apply to all 'members' of the FAC.
> 6. Next you (or actually the NAIVE-L list owner probably) can use LSVPUT
> with the PUT command to store the files for the list. Eg.
> LSVPUT BROOKLYN BRIDGE NAIVE-L (PUT
> LISTSERV seems to respond with messages and/or mail as an ack.
You, or the owner of NAIVE-L, or whatever person you have defined in the
PUT FACs.
> 8. Now I get way out into left field and am pretty sure I am missing
> something. What if you want to add another file? I was told there
> is a way to put a 'generic' entry in the filelist but I haven't
> figured it out. I have had to get a current copy of the FILELIST,
> edit it, and store it, before I could add a file.
I can be wrong, but I think there is no 'generic' fileid capability on LISTSERV
right now. Anyway, you can update your installation-customizable LSV$PUT
EXEC. This exec gets control every time a (LSV)PUT request is received for
an undeclared file; you can make a slight mod to the NETINFO exit written
by Eric to make LISTSERV automatically add an entry to the FILELIST file
each time you'll receive a put request for an undefined file. Anyway, you'll
have to reformat and/or comment the file from time to time.
Please note than the current version of LSVPUT ignores the filelist parameter
(i.e., the third one), so that by using LSVPUT you cannot expect that
your Netinfo exit copy be able to recognize the filelist onto which you want
to put the undeclared file --> you'll probably have to ressort to put all the
undefined files on the same filelist.
I've written a command to maintain *local* filelists which can be called via
different synonyms to specify the destination filelist (it can also be
separately specified). I have not finished the docs, but I can send
it if you want (and to anybody interested, by the way).
> WARNING: Whenever you "GET" a copy of a LISTSERV FILELIST file
> with the GET command, you should DELETE the "HARDFAC FILE" info
> (lines between and including the * :::::: ... lines). It seems
You should *never* use GET to get a FILELIST for storing it back later.
You can use SF or modify directly from LISTSERV. Note that part of the
file *is* important (i.e., the FAC section), and it gets reformatted when
it is sent out as a result of GET, so that you'll loose all the attributes
and cause probable 'internal errors' later.
> won't have that problem. But I generally never shut LISTSERV down.
Note that you don't have to shut down LISTSERV to update files from it,
you can use the Xedit and CMS commands.
> You do NOT have to update FILEID if you want LISTSERV to generate
> a "true file name" for you. LISTSERV will automatically add the
> entry. Eg. If you add FREE LUNCHES to the NAIVE-L FILELIST,
> put the FILELIST file back, then LSVPUT FREE LUNCHES NAIVE-L (PUT
> then LISTSERV will file it as "00000001 NAIVE-L L1" and add an
> entry to FILEID. Because Eric made this automatic I figure he
> may have easier ways to update NAIVE-L FILELIST too...
You can also force LISTSERV to assign 'true filenames', as you call them,
identical to the name of the file as it was sent, by modifying your NAIVE-L
FILEID file in the second line:
*DEFAULT* L1 MYEXEC
where MYEXEC is an exec which will be automatically called each time the
file is GET, PUT, AFDed, etc. Your exec will receive control with a parmlist
you can parse with the following instruction:
Parse arg ,reqtype origin filelist xfn xft xfm '*'dataline
where reqtype can be GET1, GET2, PUT1, PUT2 and others, depending on the
command beeing processed (there are two versions of almost each command because
your exit will be called twice, before and after the file has been stored/
sent/whatever). Your exec will be called after the FACs are validated,
so that you don't have to worry about security problems. An important use of
this feature is to write a simple exit that contains only an 'Exit 0'
statement: this will force LISTSERV to store each file under the filename
it had when it was sent, thus allowing a direct LINK to your L disk :-)
Jose Maria
|
