ZMailer 2.99.12 out, long-awaited scheduler fix!

[Matti Aarnio <mea@utu.fi>]

Hello,

	The location is:

ftp://ftp.funet.fi/pub/unix/mail/zmailer/zmailer-2.99.12-950207.tar.gz

	... and I hope soon also its mirror sites.


	I was finally able to determinem in what manner all the
	versions of the ZMailer scheduler up until this version
	have been broken.   (This includes the original Toronto
	versions..  Edwin, if you want to know the fix, pull a
	diff in between my 2.99.11 and 2.99.12 :) Apply by hand.. )

	Now it should no longer report "cannot open ..." from
	the transport channel programs -- because the scheduler
	should no longer feed wrong filenames to the transporters.

	Short way:

	Pick the sources, see   README.UPGRADING,  pick/edit proper
	"*Config"s, make, and then "make install-bin"

	Longer way:

	Pick the sources, follow INSTALL -file :-)


	Now that the biggest crasher-bugs, that I know of, are gone,
	and the beast is moving towards 3.0,  lets now give it a good
	shake-out so that I can disappear for a while after the 3.0 is
	out.  (I have a big project coming up right after these "fun jobs"
	are out.)

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

	PS: Somebody asked what Alpha/Beta-quality classifications
	    could be used on these ?

	    I would say the programs are beta/release quality,
	    documents are (mostly) (pre-)historical, man-pages
	    are almoast up to date, and the sample configurations
	    are, eh, ...  not very good at various esoteria,
	    however on the most common cases they are serviceable.

	PS2: Lately I have felt like Linus Torvalds with his release
	     numbers, but that should not be news ;-)


	From  ChangeLog:

	----------------------------------------------------------------

	* scheduler/scheduler.h, scheduler/scheduler.c, scheduler/agenda.c,
	  scheduler/transport.c:
	    Actual long-standing (ever since 1.0 ?) problem was the usage
	    of wrong filepath in the transport.c:tscan(), but without
	    some external help, the right one was not available..
	    (Scrambled especially the "-s" option!)

	    For fixing it was necessary to realize, that
		1) Each file is scheduled only once for each thread
		2) thus can be created a pointer into CTLFILE-block
		   which points to the CURRENT thread-vertex
		   (a companion for "mark" used for tscan() )
		3) the current vertex pointer can now contain an entry
		   to the path where the file is linked to
	    With these pointers in places,  transport.c:tscan()  and
	    after it, the client scheduling, can finally be done reliably.


	* scheduler/scheduler.c, scheduler/transport.c:
	    Once more, re-wamped the SIGCHLD processing, as
	    2.99.11 generated scheduler zombies on SunOS 4.1.x

	----------------------------------------------------------------