The  LISTSERV mail  forwarding  package has  been improved  in  an attempt  to
support this  brain-damaged operating system sold  by IBM and known  under the
name of VM/ISF. The following changes have been introduced:
 
- A  new  configuration  variable,  FWD_FM,  has  been  provided  to  let  the
  installation choose  the filemode of the  disk where FORWARD FILE  (the file
  containing all  the mail forwarding settings)  is kept. If this  points to a
  R/O disk, it  will be automatically reaccessed before any  reference is made
  to  the file  (well  LSVFILER would  do  it  anyway, if  you  have a  recent
  version), and LISTSERV  will reject any /FORWARD command  which would result
  in a write to the  file, pointing you to the disk owner (as  per a CP Q LINK
  command).  The default  filemode is  'A1', in  which case  the program  acts
  exactly as before as far as the user is concerned.
 
- Statistics are now gathered in a private file, FWDSUM FILE A1, regardless of
  the  filemode of  the  disk  housing FORWARD  FILE.  This  has also  another
  advantage: if  a user  cancels his  forwarding and sets  it back,  the stats
  about the number of files he got forwarded are not lost.
 
NOTE: if  you migrate from the  old FORWARD package  to the new one,  you will
have to create this  FWDSUM FILE from your old FORWARD FILE  if you don't want
to reset  your statistics (to  do this,  just copy any  non-blank, non-comment
line in  FORWARD FILE  into FWDSUM  FILE, removing  the second  word as  per a
"Parse var input a . b; Queue a  b"). If you install the package from scratch,
you need not be concerned as the file will be created automatically.
 
If you have  a VM/ISF system, you  can set up one shadow  LISTSERV machine per
additional CPU  in the complex,  with the  FORWARD FILE on  a R/O link  to the
master machine's 191. This will allow mail to be forwarded correctly, whatever
the CPU  where the  spool file  was created.  This is  what IBM  calls "Single
Image" - if you want to know the list  of the reader files of user X, you have
to successively logon  to each of the CPUs, do  a Q R ALL X there,  and sum up
the results. Note  that Q F X  will return the value of  some internal counter
(number of spool files physically on the CPU, be them copied elsewhere or not,
+ number of spool  files on another CPU  for which we happen to  have a shadow
copy of the SFBLOK). This number has no  actual meaning at all, so that if you
sum up  the Q F X  counters you will  get a number  between 1 and N  times the
actual number of files owned by the  user, where N is the number of processors
in the complex. I wish the IBM operating system developers would plug in their
brains before they start working. I  thought the CMS5 windowing system was the
most appallingly rotten rattle-brained thing IBM had ever dared to produce. It
looks neat when  compared to VM/ISF. The worst being  that the VM/ISF syndrome
does not affect only the VM/ISF customers. It affects everybody as code has to
be put in standard products (like VM/HPO  or LISTSERV) to support it. Oh well,
I should probably go to bed before I get too much worked up :-)
 
  Eric