LSV$PROF has now  been replaced by a  set of SYSVARS files  which define the
various LISTSERV system variables. I got tired of the old system which had two
main drawbacks:
 
1) I  had to  resend LSVPROF  which each new  release or  sub-release, because
   that's where the 'release' variable is defined. LSVPROF was quite large.
 
2) 50%  of people  used to forget  to update the  GLOBALV SELECT  LISTSERV PUT
   statement in LSV$PROF after adding a  few more assignments, and I got tired
   with explaining this.
 
3) I also got  tired of adding more and more IFs in  LSVPROF to supply default
   values  for missing  variables in  case the  postmaster has  "forgotten" to
   update his LSV$PROF.
 
  So you have a SYSVARS FILE which  list the various data files that are being
inspected,  and one  or more  xxxx  SYSVARS files  containing assignments  and
control statements.  At present I have  defined SYSTEM SYSVARS, common  to all
LISTSERVs, BITEARN SYSVARS,  common to all BITNET/EARN  servers, LOCAL SYSVARS
which   obsoletes  LSV$PROF,   and  BITEARN2   SYSVARS  which   performs  some
verifications on  what LOCAL  might have  forgotten to  do. LSV$PROF  is still
called if it was found to be  present, so it should be compatible, except that
only  those variables  that  existed in  the STANDARD  1.5j  LSV$PROF will  be
fetched  from LSV$PROF.  If you  had locally-defined  variables, they  will be
ignored and  you'll have to  migrate them to LOCAL  SYSVARS. I will  provide a
SAMPLE SYSVARS file to be used as a template for your LOCAL SYSVARS.
 
  Another advantage is that whenever  new variables are defined, the migration
exec will send  a SYSVARS template to  the postmaster and tell  him that these
variables have  been defaulted but ought  to be merged into  the LOCAL SYSVARS
file if you want to override their settings. This should get rid of the boring
"File LSV$PROF NEWEXEC must be inspected and merged into LSV$PROF EXEC".
 
  Another new feature  is a new module, LSVIUCV, which  replaces and obsoletes
WAKEUP MODULE.  I got *really* fed  up of inquiries  as to whether this  was a
licensed module or not.  We have IPF here and we DO have  a WAKEUP MODULE, but
it's  labelled release  3  and  doesn't accept  the  IUCVMSG  option. The  one
LISTSERV presently uses is release  5.35, which bears no copyright indication.
Rumour  has it  that this  is  an IBM  internal  use only  improvement to  the
official IBM program.  Another rumour is that  it has been written  by some VM
hack  who kept  only the  IBM  program's syntax.  Anyway LSVIUCV  is 100%  IBM
copyright free and this solves the problem completely.
 
  LSVIUCV  only  handles a  subset  of  WAKEUP's functionality,  and  contains
additional functions which specific to  LISTSERV. Notably, it will perform all
the message/file  pre-parsing work  and directly return  a userid@node  to the
caller. It  will also perform the  list userid reader file  stealing operation
itself, and ONLY when  this is required (ie just before  deciding that it must
enter  wait state).  This has  given impressing  results: it  took 21/29  secs
(VCPU/TCPU) to  LISTSERV to  process 50  'nop' commands  to LISTSERV  with the
WAKEUP-based routine. The new LSVIUCV-based LSVPROF takes only 14/15, ie about
50% savings.
 
  LSVIUCV also allows LISTSERV to save all pending commands/messages in a file
before  logging   off  when   a  STOP  command   is  being   processed.  These
messages/commands are placed in a "Warm  start data file" and are subsequently
reloaded when LISTSERV is restarted.  When restarted from a physical terminal,
LISTSERV will  ask you whether  you want  to perform a  WARM or COLD  start if
these  data  are present.  You  can  also ask  to  VIEW  them, POSTPONE  their
reloading  until  the  next  startup, or  SHUTDOWN  immediately.  POSTPONE  is
probably the best choice when you have  just installed a new release and don't
know how long it will survive :-)  The reply is automatically WARM if LISTSERV
is started in disconnected mode. I expect to see problems on those nodes where
the format of the 'CP Q U'  command output has been modified as LISTSERV might
then think that it is not disconnected, so you should be aware of that read if
your site has that kind of CP mods.
 
  To ward off  the heavy rain of  requests that fell upon me  when I announced
RELIUCV  a long  time ago,  I am  not going  to make  LSVIUCV a  public domain
program, least of all  spend time modifying it so that  other programs can use
it. It is too specific to LISTSERV  to be usable by other applications, and it
was already too much *boring* work  to write it without getting inundated with
RFMWs (Request For More Work), "if you  just added an option to (...) it would
be so  useful to my Super-Talk  program", "with just  a very small mod  to the
startup code you could (...)" No. I  just don't have time, period, don't waste
yours in asking :-)
 
  Eric