On Mon,  13 Sep  1993 08:06:21  PDT Dave  Gomberg <[log in to unmask]>
said:
 
>Gee, is that your entire gripe list?
 
No, just the most obvious things.
 
I run a  number of lists for  Swedish professors. When setting  up one of
them, I deleted the line  with the "Default-Options=" keyword by mistake.
The owner pointed  this problem out to  me and I updated  the list header
and issued the usual QUIET SET ...  FOR *@*. After 30 seconds the command
had still  not completed, so  I logged on to  LISTSERV and typed  TS (I'm
beta-testing 1.8a  as you know).  It didn't look like  it was in  a loop.
Strange. I  checked LISTSERV 191 from  another account, and saw  the list
had almost a thousand subscribers (since  I had created it 2 days before,
I had assumed it would be almost  empty). Ah well, SET EXECTRAC OFF and I
waited.  After 5  minutes  it  still had  not  completed,  so I  rebooted
LISTSERV and decided I'd just have to do this at 3am, or better yet, wait
until the weekend  when I normally update the production  system with new
code, since SET has been rewritten to PASCAL recently.
 
The PASCAL version ate  3 seconds of CPU time for  the same thing, mostly
because it sent me 941 messages (I stupidly asked for interactive reply).
Now, obviously compiled  PASCAL code is faster than REXX,  and SEARN is a
very slow  machine, but that doesn't  explain the difference. There  is a
lot of I/O to  be done, and system calls that will take  the same time no
matter the  language. In addition,  all the  parsing work was  already in
PASCAL (ie  the interpreter  didn't have to  run through  50-lines SELECT
statements with  ABBREV calls for  each subscriber). The problem  is that
the REXX code  generally has to use o(n2) algorithms  because there is no
pointer, no way to explore a stem after setting it, and so on.
 
The mistake is  to use REXX for  a large application. It  is an excellent
language  for  self-contained  applications,   and  the  best  procedural
("shell" in  unix terms)  language I  know. But it  just isn't  suited to
anything  that spans  more than  a handful  of source  files, or  that is
longer than a few thousand lines.
 
>BTW, the passing of  stems is now addressed in the  draft standard, so I
>expect there will be little to fear on that subject.
 
As usual, this is too little, too  late. By the time the standard passes,
the generally adopted procedural language  will be BASIC, because that is
what Microsoft  is pushing and  IBM is doing its  best to make  sure REXX
gets as little exposure as possible, and nobody will care. Let's face it,
most people,  at least on BITNET  for which I have  statistics, are still
using CMS  release 5 (5.x  comes second and 8  is third). CMS  10 finally
introduces support for  stream I/O, but without RECFM F  files, heck, why
should we  support RECFM F  files? We  will have to  wait for CMS  11 for
this.  By the  time all  that stuff  comes out,  LISTSERV will  have been
entirely rewritten in  PASCAL and I won't  have to explain that  I am not
going to use the new REXX features because 95% of the installed base does
not support it - it will all have become irrelevant. The world is the way
it is, and there are mistakes it just doesn't tolerate; this is a perfect
example.
 
  Eric