Stephen, Yes, I believe this model is used in large tax systems as it is to process large "queueing" systems. We used it because it is flexible and we used to call it "Dynamic Jump-pad" programming used when memory is at a premium and the coding you start off with in a process isn't necessarily the coding you end up with because the code in te State responses actually can modify an existing set of response code.
At the time this really opened my eyes on two fronts. a. The strength and versatility of assembler coding b. The ability of a "program" to effectively "learn" by modifying itself. This was necessary because we only had 8K of core in those days and so to operate efficiently we didn't want to overlay code from disk back into memory so we dynamically altered code whilst it was in memory. The project was to write an operating system that supported Point of Sale Tills as external nodes, each of which was firing transactions back to a mainframe at any time so the mainframe had to be able to queue the events/transactions effectively. Using conventional if...else topdown technology would never have worked and would have become too large anyway. We ended up streaming 4 FSM program models together in parallel in order to process the transactions which effectively did away with the conventional "polling technique" that most people would have used to create a solution. Funnily enough, OOP was only a glimmer in the sky at that stage but to all intents and purposes we were using all the OOP techniques in creating a solution to the problem. It must have worked as it was only decommissioned 5 years ago after 25 years of operation on the same hardware!!! Dave -----Original Message----- From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Stephen Russell Sent: 19 December 2013 16:17 To: ProFox Email List Subject: Re: Finite State Machine On Thu, Dec 19, 2013 at 4:09 AM, Dave Crozier <da...@flexipol.co.uk> wrote: > > The biggest difficulty in writing software this way is not the > programming, it is actually defining the finite number of events, > states and combinations of the two that will generate a state change > that may or may not affect the actual state of the thread that is > currently processing the change. > > ----------------- I see Taxation at Sales following this methodology. Rigid rules for physical locations all over and you have to charge different rates depending on your customer because you do drop ships for them. -- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN 901.246-0159 cell --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/18725b8cd2d5d247873a2baf401d4ab22a477...@ex2010-a-fpl.fpl.LOCAL ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
