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
|
