Posts
389
Comments
117
Trackbacks
40
Classic ASP and steam driven web apps

Kevin's recent post about the pain of ASP reminded me to post about a recent system rebuild I had to do recently. I had to get a line of business application up and running, with data backup only and a new clean hard disk.

The application concerned is part of company history where I work, was created many many years ago by the founding director and the small team of developers that made up the company at the time. Well, history is history and he and the original devs are distant memories for those of us still around.

The application could be described as a special stock control system, not for car parts but for a section of a financial service that has to be strictly controlled. At the time it was conceived, the architecture was designed with the latest Microsoft Web technologies, bundled together under the excellent name of the NT 4.0 Option Pack. This included Microsoft Transaction Server and IIS 4.0. (The download page cracked me up - remember when Microsoft Servers supported intel and alpha?)

The application itself in total uses NT 4.0 Server, IIS 4.0 (Active Server Pages), Microsoft Transaction Server to look after the VB5.0 middle tier component, SQL 6.5 looking after the data side of things and a service written in C++, listening on a named pipe for print commands.

The application has "history" everywhere you look. For one thing, it comes with a support contract that has held since the application went in to production. This provides challenges when naturally the developers these days are all C#, ASP.NET, all gearing up for 2.0 of course and would probably start a wee headache having to work with VBScript. I'm just glad off the back of that that the two compiled parts of the application have remained intact, I'd hate to have to recompile with those tools.

For those of you who haven't had to deal with these things, this means that you have to fix an application written by someone else in a technology you haven't used for 5 years. That is if you were working 5 years ago!

Another part of the history is that the system is now only single user. We have a classic web application; IIS, Middle Component, and DB  all sitting on one server, the same machine that the user now sits down to. And to call it a server is going a bit far, it runs on an old Compaq desktop with a tape drive. A machine so old that getting parts is a nightmare, and the new RAM it recently got was cannibalised from other old machines failing. Although the architecture is over-engineered for a single user, it was an excellent opportunity at the time to explore the technology, and the original plans involved several users accessing the web application over the network. The web setup also gave opportunity for the customers of the company involved to access the application directly, giving an element of self service. Unfortunately the great plans didn't come together, and quite terminally. I'm not sure of the exact reasons, but the application isn't even allowed on the network, so it now sits on its own chugging away.

The rebuild was interesting. For one thing it was a hunt in the office to track down the base CDs, NT4.0 Server, NT 4.0 Option Pack, and SQL 6.5. You tend to hit daft stuff like boot problems etc when working with the combination of an old machine and old o/s. I ended up building the three boot floppies for NT, and working from there. I found the cd-writer on my laptop was a godsend, moving the various service packs and application parts on to that was excellent. I found to my disappointment that there was only a token-ring card in the machine, so no use in these days of Gigabit ethernet!

Thank goodness I had taken copies of the application files a few years ago when the disk had been flaky, these could be recopied back on to the machine and the rest was configuration and dependencies. I found the two and half days getting it back was a mix of triumph and disappointment, but I got it done. It developed into a three hour cycle of problem discovery and fix. It was a good opportunity to ponder the improvement in Microsoft software over the years. The installation of the NT Option pack wouldn't complete properly and it was the old technique of applying the latest service pack that got it working. I'd forgotten how challenging NT4 could be straight out of the box, it wasn't just all those install / deinstall cycles that fragged things.

The rest was ok when you knew the idiosyncrasies of the various bits. There was an old setup wizard package with the dependent rdo files packaged with the component, so that was the only way of getting the VB component on and working. Then I deregistered that and put a newer version on. Adding a service is harder than it looks, in the end I found that the registration routine was part of the executable itself. Otherwise, you are relying on the NT4.0 resource kit to give you the "add a service" command line util. Then a small tweak to make sure the service account was correct.

So, got the app together in the end, restored the tape backup and then bang - the application onsite hit an update problem. Cue some major head scratching. I couldn't get onsite due to other committments, so cue a session in front of my laptop with the source code out of sourcesafe, mobile phone on and bluetooth headset stuck in my left ear.

We were getting a javascript error on an update. That happened after hitting a button above a blank screen. Quick look at the code, put in some rubbish to kick the validation in to check the code was running, and the right error message came up, so it wasn't that. The blank screen is a clue of course, so do a "view source" in IE 4.0 to see if the page really is blank. There was the error, not coming through to the browser because it wasn't valid html. This indicated a syntax problem in an ADO update. The update involved a table with a date column - incorrectly formatted date. Check the locale - US English - drat! The date formatting in VBScript is pretty rudimentary, coming down to either long or short, and wholly dependent on the context. You can get really twisted up working from ASP through the layers trying to establish the locale, and in the old days used to try to write my own functions to get round any internationalisation issues. Thank goodness this is taken on properly in .NET and is also considered appropriately in the development process. So the fix on the box was to change the system locale to UK English, but doing that needs the system CD - on the other side of Scotland.

Hats off to the chap who was onsite and on the other end of the phone who made arrangements to get the CD, but another reminder from him, copy the system CABs on to the machine concerned, for daft stuff like that, and also recent service packs. The recent OSs are a lot better, but system guys are a lot better at remembering the field practice like that.

So, application running again, support contract still going, but I now know how to rebuild the thing. Phew, time for a rest.

posted on Saturday, September 10, 2005 11:06 PM Print
Comments
No comments posted yet.

Post Comment

Title *
Name *
Email
Url
Comment *  
Please add 6 and 2 and type the answer here: