DesignBais v3.3 Startup problem
There is an issue with DesignBais v3.3 and mv.NET v2.1.4 where starting DesignBais from the startDB.asp web page consistently fails with "cannot connect"-type messages that don’t lead to any specific problem. If you have not seen this then you don’t need the solution presented here, but for some of us the problem seems chronic.
I’ve been told other sites never see this problem and I suspect the most stable servers are those that stay up all the time where DB is never reset. I’m also hoping this may go away with v4, but I sort of doubt it will unless the cause for the problem is diagnosed. Until then I’m presenting here a description of the problem and a temporary fix.
The problem always seems to be resolved when the program MVNET.HOUSEKEEPALL gets run from TCL in an account that is failing to initialize. This program deletes all of the MVNET.TMP_ files created by mv.NET. These files are used to manage connections on different ports. mv.NET includes a housekeeping function which can be executed at timed intervals, but that only runs when we are using pooled mv.NET sessions. DesignBais manages its own connections through a non-pooled mv.NET session, so housekeeping is never run automatically.
You can’t always tell which account is the source of the problem – I have at least 8 accounts with DB and mv.NET installed, for development, testing, demos, etc.. So when I first encountered this problem I tried the housekeeping option, but it didn’t always work, so I didn’t understand the real nature of the problem. I only use two mv.NET licenses for DB work. I always set one license for a dedicated connection to an account where I’m doing most of my work. I have another license for switching connections. When DB starts it initializes the dedicated connection if it can, logs into DBILOGIN for its own purposes, then logs into the first account that my current user (designbais) is authorized to log into according to the DB Users settings. So (I believe) that limits the scope to three possible accounts where failure can occur.
I experience the problem after I shutdown for the night and then restart the next day, or when I stop DB so that I can adjust my dedication connection allocation, and then I restart. Strangely, existing sessions don’t exhibit a problem if I’m changing accounts after DB is started, the problem is that I can’t start DB after it’s been shutdown.
Rather than going to each account and running housekeeping manually, hoping that I cleared the problem, my solution is to run housekeeping on all accounts, get rid of any old junk and start from scratch. To do this, I wrote a program that checks every account on the system to see if it has MVNET.TMP_ files, and then the files get deleted. The original version of this code used a LOGTO to get into each account and then run housekeeping, but that won’t work in a production environment where there are logon procs, application authentication, account passwords, etc. So I decided to use STEAL-FILE to pull the files into the current account, then housekeep the files locally. (I could have just deleted the files, doesn’t matter.)
To use this code, put it in some primary account with DB and MV.NET enabled. compile and catalog it as MVNET.HOUSEKEEPALL.ACCOUNTS. Then, right before you use the startDB.asp page, run this program. It will delete the temp files from all accounts so that you’re starting with a clean slate every time. I was going to suggest that this could happen automatically, by overloading the MVNET.START program or putting this into a logon proc that only gets executed when you do your first-time init, but I’d rather not get too cute about this. It’s a temporary fix to an occasional problem, and I don’t think it should be built into the environment. That said, there’s nothing wrong with putting it in your user-coldstart like this:
TO DBI.DEMO
MVNET.HOUSEKEEPALL.ACCOUNTS
Just make sure it’s catalogued in that account of course.
Please let me know if this doesn’t do the intended job or if you have other suggestions. Code is on next page.