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