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