Battle of the Clones


In a Galaxy far away there is a place for clones to do the job over and over again.  But alas they are flawed without a heart and soul they can not grow up they cannot evolve into the next generation of fighting machines..   At least not like the original that is delivered from the factory.   When the upgrade is announced it is difficult to find the wretched clone because they can have any name the master of the day gave them.  So they are lost for ever to be many releases behind their coworkers inefficient and possibly totally forgotten

In the real world reuse is accomplished by augmentation and adaptation and not by cloning the delivered code. What the creator of ChangeMan ZMF has done in the latest releases is make it possible for you to almost never change a delivered skeleton except for ones that are set up specifically for that purpose.   The most common cloned skeletons are the compilers -- the least required custom skeletons now are the compilers -- you can set the variables externally.  If you need to include a custom pre or post processor add the code to selectively include the preprocessor -- code like )If &PREPRO EQ Y THEN )IM PREPRO or something similar -- it does not have to be complicated.

I recently had a customer that had ten COBOL procedure skeletons all basically doing the same thing.  The historical reason was they had been different versions at one point.  So I didn't want to retrofit 10 skeletons when I could just do one (naturally lazy) I simply retrofitted one and had the other 9 imbed that skeleton.  If there were differences and there were in a couple I just checked the &PROC variable to insert the difference.   The less I have to code the less I have to test, the more functionality I get from my system.

Lets look to the future where clones are heartless wonders from the past











ChangeMan ZMF
How To-Best Practice
Comment List