New Paper Basket? Regen System

On an IBM mainframe (at leats when I used to work at GTE Laboratories), making even tiny changes can be quite complicated. The system doesn't have any built-in flexibility for using new hardware. When you install something new, you need to regenerate (regen) the operating system to let it know about the changes. Windows is usually better: you only need to install new device drivers and reboot. PDAs are better still: you just plug in the new hardware or software and the system is ready to go, usually without shutting down or rebooting.

Making hardware changes to MicroVAXes like the ones we used is relatively easy (assuming you know what interrupts and memory addresses to use). It's similar to the procedure for installing a device on a Windows PC.

Once while we were installing a new printer basket to catch printouts on one of our MicroVAXes (this was about as hard as replacing a mouse pad and didn't require shutting down), I joked to my boss that we should notify the Computer Center so they could regen the mainframe. He laughed and, after a little thought, pointed out that you might actually need to regen the mainframe to change a printer basket. Some mainframe printer devices ring a bell and wait for operator intervention when the printer basket is full. The operator removes the printouts and presses a key to let the computer know it's okay to continue printing. If you changed the size of the basket, you might need to regen to tell the system how many pages it can print before needing assistance.

Later my boss did call the Computer Center to tell them we had changed printer baskets. They were not amused.

Shutdown Normally Next Time, Idiot

This is a typical story about trying to fix a simple problem with Windows. I logged in, checked my email, tried to shutdown, and Windows 98 hung. It seems to do that more often when I don't disconnect from my DSL modem first (what if turning off your car with the radio running made the engine fall out).

Naturally when I rebooted the system gave me its insulting message "Shutdown Normally Next Time, Idiot" although it was the system that had forced the bad shutdown. While checking the hard disk, the system discovered that one of the system files was corrupted so it replaced it with a previous version. Very gracious of it considering it had corrupted the file in the first place.

Everything seemed fine for a day and then suddenly Windows Explorer stopped displaying folders in the TreeView display in the left pane. When I double clicked on a folder in the right pane, it launched a new folder display to show it with big icons. No amount of configuration could make the left pane display anything useful, make Windows Explorer show the new folder in the same window, or make the new folder default to a display other than icons.

After a couple hours of fruitless searching Microsoft's Web site and the Web, I couldn't find anything about this problem. Eventually I guessed that the file that had been corrupted might be mscomctl.ocx, the file containing the TreeView control. I decided to download a new version so I wasted another half hour searching Microsoft's Web site for that file. Considering it's a freely distributable OCX you would think it would be a little easier to find. I found lots of copies on the Web but none were at Web sites I considered completely safe and I wasn't sure what versions they were or what version I needed.

Finally, in an act of desperation, I went to Microsoft's Web site, installed Internet Explorer 6.0, and voila! Internet Explorer 6.0 seems to have updated mscomctl.ocx (or whatever the problem was if it wasn't that) and Windows Explorer now works once again.

Don't Stare At The Sun

When I started programming professionally, some operating systems were more reliable than others.

• A typical PC could run for several days without crashing.
• The Unix systems at GTE Laboratories where I worked could run for a couple weeks without crashing. I think most of the time they were brought down it was because the system managers were messing with them. The Unix system manager mentality was pretty much, "If you want to play with the system, go ahead."
• Sun specifically recommended that its customers reboot their systems at least once per day to clean up memory leaks.
• We were running VMS on MicroVAXes. Our machines ran for years at a time without rebooting! They literally never went down except for power failures (before we got our UPS) and when we needed to bring them down to install new hardware.
• These days, my Windows operating system typically shows me the Blue Screen of Death at least once per day.

Appalling Apollo

Not all that long ago, Apollo was one of Sun's main competitors in the high-end workstation market. They later got eaten by Hewlett Packard.

In those days, there were two main focus models: click and real-estate. In the click focus model, you click on a window, it pops to the top, and it gets focus. This is the way Windows works and at this point I think most people are using it. In some versions of XWindows and Motif, you could Control-Click a window to give it focus but keep it in the background. This was useful if you wanted to copy information off of another form, but I guess Microsoft didn't see the point.

In the real-estate focus model, the window with the focus is the one under the mouse. If you moved the mouse over a window, it automatically pops to the top and gets the focus. No click required!

One annoying feature of the real-estate model is if you are happily typing away and you bump the mouse, focus may switch to another window and your typing gets dropped there. If you are lucky, that window does not accept the text and you lose your typing. If you are unlucky, your key strokes send the other application into apoplectic fits!

Despite its "obvious" drawbacks, lots of programmers (particularly those using Suns and some other Unix-based workstations) got used to the real-estate model and would defend it to the bitter end.

To make a bad story worse, for a while Apollo workstations used single cursor for both text and the mouse. If you moved the mouse, the text insertion position moved.

Imagine yourself typing happily away when you bump the mouse. First the characters you are typing get scattered across the window in which you are typing. Then the mouse leaves that window and you drop characters in random parts of other applications. Best of all, if the mouse wandered over the desktop so there was no application to catch the keystrokes, the system crashed.

To solve this problem, a lot of developers would carefully position the mouse where they wanted to type. Then they lifted the mouse up, turned it upside-down, and placed it on top of the compuuter's monitor. That way the mouse wouldn't move even if the bumped the table.

What a wonderful system!

Confused R Us

By Colin Day.

I bought a VB add-in that includes a library of useful code snippets and routines. It is implemented with a tree control to navigate to the category you're interested in and select the routine that you want to see. Mine would never work. The code was all sitting there in the database but I couldn't see the routines in the tree control.

Suspecting database problems, emails went back and forth between myself and the developers suggesting reinstalling ADO and MDAC and that sort of thing. Nothing helped.

Eventually, unable to recreate my problems and with thousands of working sites worldwide, they sent me the source code to have a look for myself.

The code snippets are held in the database with numeric keys, but of course that won't work with a tree control, so the developers prefix the keys with a letter before adding them to the control, "C" for categories and "R" for routines. This was failing, but not being trapped.

It was failing because ... wait for it ... our currency symbol here in South Africa is "R" for Rand and values like "R1" are considered by VB to be numeric! Now, who'd have thought of that! I changed the prefix for routines and ... Hey Presto!

Lessons Learned: Don't suppress error messages with On Error Resume Next (if it can never happen ... then it's sure to!) and watch out for internationalisation, it's all around you quietly doing it's stuff.

[Developers often ask, "Why should I use 'On Error GoTo 0' to disable error handling when I'm done catching a specific error?" Here's a good example. See also my book Bug Proofing Visual Basic. -- Rod]

If you would like to contribute a story, email me.