[lutusp]

> Maybe I'm off the mark, but whenever I see a long runon procedure full of if-then-else, I think "This is a job for a state machine!"

I'm a big fan of state machines, but systems like this are often multitasking and (for all practical purposes) stateless. OTOH it might be more accurate to say their state is formally unpredictable.

A system like the one being described would be more like a multi-threaded critical-path flowchart, where multiple processes are active at a given time. And at any time a high-level linear programming result might mandate a change of strategy based on available resources, even though individual processes continued to follow the tactical flowchart.

So even though a state machine approach looks attractive (as it always does), it's a matter of deciding how many states and how many levels. Because of the nature of the original problem and the number of connections with everyday reality, the fact that it was a state machine might escape the attention of even a careful observer.