20. Nov (Monday).  Changed telnet port on e250 from 23 to 10007, in the hope that we can open up access to it from the outside world.  (Changed the port # so as it make it harder for any undesireables to get in.)  Edited /etc/services, changed the port number, and sent a "kill -1" to the inetd process.  Investigating installing tcpd wrappers on e250 so that we can control precisely what hosts may use what services.

    Whatever was done to the DB2 database for websphere on Sat 11/18 appears to have corrupted the DEV database instance -- the data can not be accessed, and the websphere "DEV" instance cannot be started.  Steve and I deleted the websphere DEV instance (different but pointing to the DB2 DEV instance), and created a new one, that in turn created a new DB2 "DEV2" instance.  This allowed us to start the websphere instance and access the database -- but now it is empty and has to be repopulated (publishing a store again, and then adding data by hand).

    Deleting and recreating the websphere instance also appears to have rewritten the main web server (port 80) configuration file at /opt/IBMHTTPD/conf/httpd.conf.  So some changes to that file have been lost -- fortunately most of them are recorded in my logs and can be recreated easily.

21. Nov (Tuesday).  Re-made changes to httpd.conf file.  Stored a backup copy of the file here for future reference.

    Spent a terribly frustrating day with the Sun.  After an indeterminate number of reboots, the websphere instance (in our case, "DEV") decides that it will not start (literally, the configuration manager on port 4444 freezes up, which translates to the program "webconfig" hanging).  The only solution so far has been to delete the instance and recreate it, with a new, empty, database.  Tried to talk to IBM tech support to resolve it, but now they've decided that we're on "hourly" support at $210/hour, and I don't even know who that gets billed to.  Trying to figure out (again) if we can do IBM tech support through SFC.

    Succeeded in dialing in to our local network (734 632 1821), although I had to authenticate as administrator.  From there I can reach e250 (but can't go outside the local network, which seemed strange).

22. Nov (Wednesday).  Reset the e250 telnet port back to 23, since there doesn't seem to be a need now to open that port up via the router.

    Received word back from IBM tech support about a patch/upgrade to Net.Data 6.1.1.1 that supports %macro_function parameters and recursion.  After several failures, managed to install the upgrade, with my changes to the installation procedure as noted in the WebSphere Links page (bugs and fixes).  Posted the information in the "Macro Language" section of the Net.Data forums.

    In the meantime, every couple of reboots seems to continue to cause some corruption of the DB2 database, such that the WebSphere configuration manager cannot start the websphere instance.  We're up to DEV7 and counting.  More needs to be known about what the heck is happening with DB2.  Main clue so far: seems to happen less often if we explicitly stop DB2 (with db2inst1 program db2stop) just before a shutdown.

    Note that, even with 6.1.1.1, when writing recursive functions, the only way to get truly "local" variables in a function is to have them passed in as type "IN" variables!  Thus to have a loop counter inside a recursive function, one must have it "passed in" as a do-nothing parameter.  Yeesh!