This chapter has been excerpted from the book "Flow-Based Programming: A New Approach to Application Development" (van Nostrand Reinhold, 1994), by J.Paul Morrison. A second edition (2010) is now available from CreateSpace eStore and Amazon.com. The 2nd edition is also available in e-book format from Kindle (Kindle format) and Lulu (epub format). To find out more about FBP, click on FBP.
For definitions of FBP terms, see Glossary.
|
[This article harks back to a technology (unit record machines or EAM) so inconceivably ancient that many of my readers were probably not born then - yet this was the only form of business automation many companies used in those days!]
Material from book starts here:
The following was sent to me by a colleague named Art Huber a few years ago - you can get some idea of his amusing way of expressing himself from what follows. It is reprinted with his permission.
Subject: DFDM thoughts
Last night, when I couldn't sleep because of a cold, I thought about DFDM. Why not?
I thought about the analogies we use as an aid to understanding it. None will be completely satisfactory, but I have been working on one that I have not heard previously. I think it is most useful for old farts such as me. Less experienced programmers and analysts, whose synapses are not already connected hierarchically don't need this one.
Once upon a time there were no computers. There were, however, unit record machines. There were collators, sorters, keypunches, printing accounting machines, calculating summary punches, etc.
I think a DFDM network is very similar to a job in a unit record shop.
Batches of records move from machine to machine.
Each machine performs a single operation on the data.
Each machine is a general purpose machine that is programmed to customize it for the required task. Note that by "general purpose", I do not mean that it can perform any task; I mean that it is not tied to a particular record format or job.
There are some significant differences, of course, between DFDM and a unit record shop.
The DFDM "machines" run at electronic speed rather than mechanical speed.
They are cheaper to build. If you need a new special function machine, you can create it in software. Consequently, there is no economic advantage to creating multi-purpose machines as there would be with real unit record machines.
DFDM machines can be replicated as needed. The new copies don't cost anything to operate and don't take up floor space or use additional electricity.
DFDM machines are not restricted to 80 character records.
The records will not fall on the floor between steps.
Parameters that tailor DFDM machines can be much simpler than unit record plugboards. For example, in DFDM, a field can be defined by specifying its starting position and length. Unit record machines require a character by character definition.
Because setup is so much cheaper (since the DFDM machines are virtual), it is viable to process batches of one record with DFDM.
DFDM machines need not be limited in the number of accumulators they contain, since they are implemented in software.
Jobs do not have to be scheduled based on machine availability, since DFDM machines are virtual. Of course, they are implemented on real machines (computers) and are constrained by availability of computer resources.
Isn't this fun?
I offer this for your consideration. It does point out that the job of "programming" in DFDM is very different from what we think of traditionally. We may even have an opportunity for old unit record analysts.
