releasing version 2.99.24 ...

[Matti Aarnio <mea@nic.funet.fi>]

.. at the usual place (ftp://ftp.funet.fi/pub/unix/mail/zmailer/),
and mirrors thereof..

The scheduler got fairly extensive changes to support ``overfeed''
in addition to the ``in sync'' processing of this new scheduler.
That feature became obviously necessary, as we installed, and
tuned  vger.rutgers.edu  to run its Linux lists..  With ``in sync''
control of scheduler vs. transporters, it did feed messages out
very sluggishly, however now all transporters are fed as much as
they can eat, and the scheduler comes back to check on them latter,
when it has some time.   (There are performance problems at router
DNS lookup, but that is another story.. It really needs routeing
cache-server of its own..)

The machine is an old  sun4/380  with CPU-power of approx 486DX-25
(the "utu.fi" was similar, and my 486DX-33 UNIX-machine was a bit
 faster..) there are also Xylogics SMD-disks, and the machine has
64 MB RAM.  It can humm out something like 200 000 recipients in
a day.  (Machine load-average soars somewhere 15-30:es, though..)


I also got a report of mailbox becoming truncated, when storing
a message to a full disk -- yes, it was real thing, now fixed.

The ``mailq'' output has changed a bit, you must edit  scheduler/qprint.c
to get the old output back, new one is visible when you give ``Q''-
option to the ``mailq'' -- give ``-QQ'', and you get abridged report.
It tells about threads, and their scheduling status, not necessarily
what happened to the message.

My intention is to write an interactive management interface to the
scheduler.  I believe it can be done with reasonable interactivity
responce.

Have fun, report problems!

	/Matti Aarnio <mea@nic.funet.fi>