More info on GOTO question

[Jeffery A. Cavallaro]

Thanks to all for the informative (and kind) responses to my "goto" style
query.  A few people wanted a little more info on the application, and it is
sort of interesting, so I will share it with the net, as well as the solution
I chose.  If you are not interested, might as well abort here...

I am implementing a relay channel between MMDF-II (a pre-release version), and
various commercial mail networks (e.g. TELEMAIL, MCIMAIL, etc.).  Submitting
(or receiving) mail to (from) MMDF is a multi-step process that draws upon an
"instruction set".  The submit sequence is basically as follows:

	1.  Init.
	2.  Fork submit job to be communicated with via pipes.
	3.  Init for next message.
	4.  Submit addresses.
	5.  Submit text.
	6.  Indicate message end, and loop to (3) if more messages.
	7.  Release fork.

Each step involves complicated "handshaking" between the commercial mail system
channel and MMDF.  If any of the above steps fails, cleanup and a possible
return-to-sender operation will occur.

The solution involved developing a software FSM which is composed of a
state/event matrix, an event generator, and a dispatcher.  The matrix is
used to address an action routine, according to the current state/event pair,
and the next state information depending upon the success or failure of the
action routine.  This solution is a more complicated version of the while-loop
solution proposed by many people.  The cleanup process can now be moved from
the inline code to a different state/event pair.

This solution is VERY flexible.  By adding state change and event occurrance
debug calls, debugging large SM's is greatly facilitated.  I have used this
solution before on other projects, with great success.  The only reason why I
hesitated using it for this project is that "events" become too complicated to
isolate due to the seemingly non-deterministic nature of the commercial mail
system human interfaces.  This is solved by allowing the action routines
corresponding to the state/event pairs to determine the next event.

If anyone is interested, I would be glad to send or post a synopsis of the
technique.  The FSM development tools consist of an include file, the
dispatcher code, and some man pages.  The event handler and matrix contents
are up to the developer.

Thanx,
Jeff