There is a large problem looming with Moneky Patches. The problem is that monkey patches are so Highlander. "There can be Only One". For example, there are at least five or six products that monkey patch manage_main. Each simply replaces whatever manage_main exists at the time of instantation, and blows away any previous monkey patch. Some coordinated way of dealing with this problem needs to be arrived at. Proposal: for concreteness sake, suppose manage_main is being patched. A monkey patch author does the following: 1) checks to see if the file being patched is in $(INSTANCE_HOME)/tmp A) If not, he proceeds directly with the patch B) If so, he makes whatever checks he can to determine if he can update the file in $(INSTANCE_HOME)/tmp. i) If he cannot, it is his decision whether to follow current practice and simply blow away the current monkey patch (Boo! Hiss!) or, ii) fail (sigh, curse!). 2) If the monkey patch is installed, then the installed file is written in $(INSTANCE_HOME)/tmp. I.e., the new manage_main.py is written to $(INSTANCE_HOME)/tmp. This assumes that z2.py is modified so that it clears out $(INSTANCE_HOME)/tmp on each start. It might be also be a good idea to keep a section of comments at the top of the monkeypatch file showing the history of monkeypatch application. Comments? Jim Penny