The "host.tcl" design is part of a fairly elaborate plug-and-play driver design, where plugging something in (or turning a remote node on) would locate and launch the appropriate host.tcl to start up things. See http://jeelabs.org/2010/03/01/node-discovery/ and http://jeelabs.org/2010/10/12/jeemon-device-discovery/ for details.
It's powerful, but too complex.
If all you want is launch a JeeMon process to open a serial connection, read what's coming in, and do something with it, that's fairly easy. See the demos at http://code.jeelabs.org/jeemon/demos/. You can try them out by launching JeeMon as is and clicking on "Run web-based demo".
I'm aiming a bit higher with a project based on JeeMon which is currently in progress, called "JeeBus". It's not ready for prime time (too many major changes at the core level still), but the basic idea is a small "state server" with a collection of named states representing "current values" for all sorts of devices (sensors, actuators, displays), attached locally of remotely, serial, wireless, ethernet, anything. With webserver(s) and database(s) and rule engine(s) hooked up as pluggable sub-systems. So that adding a new data source, collecting data for it, and showing it as a graph can be done without altering (or even re-starting) JeeMon / JeeBus itself.
This is quite different from a more traditional approach, where you'd have a production system feeding a database, and a (staged) development copy for tinkering and developing new features and changes to the system. I'm exploring this path because I want a far more dynamic system, where even the choice of database (relational or other) or front-end (web-based or GUI) can be altered. I don't want early choices to force me to stick with what's already there because it's too hard to switch to a new approach. Because the best ideas always come later.
Apologies for going off on a tangent to what you were asking :)