Harold, Jose Maria posted a solution to your problem to this list some time ago. Since he did it so well, I'll just include it here. The "'trivial' user exit" he refers to should be simply: /* */ Arg ExecParm Request, Origin FileList FN FT FM '*' , FileListLine, PutCommandParms; If Origin = 'HAROLD@UGA' & Request = 'PUT1' then Return FN FT FM; Else Return 0; And before you ask, no I haven't tried this myself. This is stricly from Jose Maria, and from reading the code in LSVXPUT, and LSVFILID EXECs. Good Luck, Ross ------------------ Start of included file JOSEM MAIL ----------------- Received: by RUTVM1 (Mailer X1.23b) id 1609; Tue, 25 Nov 86 20:12:48 EST Date: Wed, 26 Nov 1986 01:33:50 HOE Reply-To: The Revised LISTSERV distribution list <LSTSRV-L@RUTVM1> Zender: The Revised LISTSERV distribution list <LSTSRV-L@RUTVM1> From: Jose Maria Blasco Comellas <ZCCBJBC@EB0UB011> Subject: Maintaining public disks with LISTSERV To: Ross Patterson <A024012@RUTVM1> There is still another interesting (and somewhat unexpected) application for LISTSERV: you can maintain your public disks via LISTSERV filelists. There are some tricks to apply, namely: * Give LISTSERV read/write access to the disk you intend to maintain. * Write a (trivial) user exit that stores each file under its 'true' name on the specified disk. You'll have to set up a dummy 'filelistname FILEID' for that purpose at the beginning, containing two lines: the first should read '1', and the second '*DEFAULT* fm your_user_exit_name', where 'fm' is the filemode under which LISTSERV accesses the minidisk (I found it better if the filemode was the same for LISTSERV and for users). I.e, if you attempt to store 'INFO DATA' on the PUBLIC filelist, where PUBLIC is the filelist for your user's public M disk, then make your exit to store it as INFO DATA M, not 0000000n PUBLIC A. * To avoid people (and Batch machines) getting confused or into errors, rename the old copy, if any, to a convenient name with filemode 0. This way users that were already connected will access the old copy and users that get connected after the update will access the new copy. Filemode 0 is to avoid users seeing garbage files. All that must be done by the user exit, of course. Here I'm using the following trivial algorithm for renaming: Do i = 1 by 1 until rc = 28 'STATE' fn 'ERASE'i fm End 'RENAME' ft ft fm fn 'ERASE'i Substr(fm,1,1)'0' but any other similar algorithm would work. * Then simply create and define the filelist, assign PUT FAC codes to people charged to maintain each file, and set GET=N/A for security reasons (unless you plan to set some file to GET=some other thing for any reason). Anyway, access to the files will be done via normal CP/CMS LINK+ACCESS, not via LISTSERV... * Now inform your users that they can become automatically informed of software changes just by AFDing to the FILELIST ... you've got an automatic local NEWS system :-); or you could even * AFD LISTSERV for this FILELIST and declare the FILELIST as a 'non-true' filelist into itself. Note that this cannot be currently done, since 1) LISTSERV cannot send files to itself, and 2) LISTSERV cannot accept files from itself. There are other minor points, like implementing a WAKEUP-called exec to clean the 'ERASE'n files. The period of time to maintain such a file depends on the maximum time that a BATCH machine (or a user) can be running the same program; probably 1 week will suffice in most cases. One can also have a disk 'shared' with LISTSERV: i.e., in the case of the HELP disk it may be convenient to document and associate each local helpfile with its corresponding product, but having to handle all the IBM-supplied helps via FILELISTs would be a real mess (apart from beeing useless and boring). Here we are using a local command that makes listserv to access the HELP disk in R/O or R/W mode. When we have to modify a 'documented' helpfile, we use LSVPUT; when we have to install other files (as the *huge* NAG helps) that we don't want to be controlled by LISTSERV we kindly ask LISTSERV to relink the HELP disk in R/O mode, access the disk in R/W, do the move, and tell LISTSERV to reaccess in R/W. I'm interested in your opinions about that. Is anyone else using this or a similar method? What are your experiences? Personally, I find this use of LISTSERV so interesting that I tend to suggest that some 'official' support could be added to avoid each one writting its own copy of the code. Any idea/ comment? Jose Maria ------------------ End of included file JOSEM MAIL -----------------