Maintaining public disks with LISTSERV

[Fuente]

Date:         Wed, 26 Nov 1986 01:33:50 HOE
Reply-To:     The Revised LISTSERV Distribution List <LSTSRV-L@EB0UB011>
From:         Jose Maria Blasco Comellas <ZCCBJBC@EB0UB011>
Subject:      Maintaining public disks with LISTSERV

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