Back to tackling the recalcitrant VM/386 system for me. I went back into the warzone with a primary plan and three backup plans. In that I was still unsure of the health of the dumb terminals and the complete lack of response to anything plugged into the Digiboard, I decided I needed to cover my bases. My plan was as follows.
- Update VMINTS and retry my connectivity tests
- Install free upgrade to VM/386 to see if problem clears itself up
- Reconfigure VM/386 to use serial ports and retest with PC
- If successful, put a terminal on the cable and troubleshoot terminal settings
- Otherwise, call IGC (VM/386 guys) and pay for some support
- Retry working terminal on Digiboard
All in all, I figured I had enough choices to get something going presuming the cables I used previously were still intact and functional.
My tools:
- VM/386 5.01 to 5.02 upgrade diskette
- an inline DB25 diagnostic plug with 25 LEDs to show me what’s happening on the wire
- an inline DB25 null modem adapter
- a DB25 loopback plug
- my laptop with PCTerm (freebie DOS terminal emulator from IGC) preloaded
- various gender benders and DB9-DB25 adapters
All in all, I felt well armed for success. For starters, I booted the server from the upgrade disk and updated the VMINTS file. Naturally, even this step had its difficulties. The front panel of the server has a bezel that doesn’t mate well with the eject lever for the floppy drive, so the diskette was stuck. I went into the CMOS and removed the floppy from the boot sequence. After numerous reboots, I finally cracked open the case and loosened the floppy drive retaining screws so I could force it to eject diskettes as needed.
Anyway, I rebooted VM/386 and verified the VMINTS file had been updated. It had a current date/time stamp, so I figure it did. Having had the foresight to backup the existing VMINTS file, I decided to run FC VMINTS VMINTS.OLD. Byte for byte, they were identical :/ . So much for that perceived obstacle. I went ahead and retested the terminal connections just for grins and they quite predictably remained broken.
Following my plan, I confirmed the backup of the \VM386 directory and root of C were still intact and then rebooted the upgrade diskette to commence upgrading the server software. Imagine my lack of surprise when the upgrade started copying the necessary zip files from the floppy to a temp directory and up pops a disk read error. I decided that if the file was indeed corrupted, the zip file wouldn’t extract anyway and I could restore my backup, I valiantly retried. After the third retry, the files finished copying and the upgrade proceeded without any further errors.
I popped the diskette out and rebooted the server. Being a 32 bit operating system, VM/386 works by launching a group of predefined virtual machines on startup. The first VM is the management console and another one starts for application access on the main computer (in this setup anyway). Upon restart, the management console came up successfully but the local application VM was totally corrupted on screen. The menu was visually trashed. I rebooted the application VM and got a normal looking menu. Switching to the management console, however, locked the computer up deader than a bug on a windshield. I couldn’t even toggle the numlock LED. After a few reboots with similar results, I decided to restore the backup and get the system back to a known working (I use that term somewhat loosely at this point) state.
Once I had the system stabilized and back to how I found it, I shut down VM/386 and fired up VMSYSDEF to reconfigure the serial devices. I added boards for both COM1 and COM2. On one, I told it I was connecting a WYSE 60 terminal, on the other, I told it I was running a PC with PCTerm.
I restarted VM/386, created profiles for my new settings, and then created two new VMs for testing. Since I was limited to five users, I had to shutdown some unused VMs. I connected my laptop via the serial cable and and put the diagnostic plug and loopback plug on the far end of the cable. I was able to get jibberish on the screen when typing and figured my baud rate was set incorrectly, but everywhere I checked, I had it set to 19,200 which matched the config in VM/386. I decided to guts it out and plugged the serial cable into the COM port on the back of the server. BOOM! Suddenly, I’m looking at the menu in VM3 on my laptop. It was the most beautiful thing I’d seen all morning. My customer was looking over my shoulder and started grinning from ear to ear.
Now that I knew I had a working connection, I decided to reconfigure the same port to accept a Wyse 60 terminal and try it AS IS with the dumb terminal to see if I could get one of those working. First, I tried the same loopback test on the terminal and was able to echo text back to the screen. I then put the terminal on the system and…. nothing.
I knew something simple was interfering. My connection was good and the serial port was working on the terminal. I could also see the dataline blinking on my diagnostic plug as I typed, so I knew the characters were going somewhere. I went into setup mode on the terminal (shift-Select on the keyboard) and checked the settings. I confirmed they matched the original settings (which presumably worked). I began wondering if I had problems with handshaking on either the transmit or receive lines. The transmit was set to XSP (I still don’t know what that is) and the receive was set to XON/XOFF. I tried a couple of different choices but still had no luck. On a lark, I changed the terminal emulation from Wyse-60 to PCTerm and… BOOM again! I was looking at the menu. I navigated around and started some programs to verify it was indeed working and must say, I was pleased.
Since I had two dumb terminals to reinstall, I quickly unplugged the current one and connected the second. I reset everything to match and gave it a go. Nothing. Furthermore, I wasn’t getting any blinky goodness on my diagnostic plug nor was I able to loopback the serial port. I decided this terminal was quite dead. On my previous visits, I had little success with either terminal, but I used this particular one more than the other and that may account for my previous lack of success. Nothing like multiple failures to frustrate troubleshooting.
I decided to see if I could get the working terminal up on the Digiboard. To make a long story short, it didn’t work. Diagnostics I downloaded from Digi International told me the replacement board was good, but I still couldn’t get anything to happen with it on any of several nodes. I now believe that the octopus cable was damaged along with the other Digiboard, but I didn’t have a spare to test with.
I realized I hadn’t tested printing yet. I brought the system back up with two working COM ports and reattached the working terminal. Par for the course, nothing came out of the printer from the application, a print screen, or by hitting Ctrl-P. I jumped back into the terminal setup and discovered the printer port was disabled. Clearly, this terminal lost its brains at some point and must have reset to factory settings or someone else had tinkered. After enabling the parallel port, everything printed as expected.
I conducted one more test using the RS-232 surge protectors the customer had on hand (even though they obviously didn’t provide protection) and then tested again with only the hardware I would use in the final connection just to be sure all the parts worked, I then headed downstairs to redeploy the terminal where it belongs. The cabling in the walls was unlabelled (of course), but I only had two to choose from, so I figured 50/50 odds weren’t too bad. Again, par for the course, I guessed wrong. To ensure I didn’t have other cabling issues, I plugged my diagnostic plug into the other cable to confirm I was getting a signal from the terminal downstairs and happily saw appropriate LEDs light. Making the connection with the correct cable, I had the most critical terminal back online!
It took about 15 minutes of searching to find the other serial cable I needed. The second connection was in the same office and the cable was installed by running it around the room along the baseboard. When they repainted and recarpeted the previous week, the contractors took the cable out and stashed it somewhere. I found the cable, installed Winterm on the computer at the other desk and ran the cable back around the room.
Pulling the computer out to connect the cable, I realize I’m short a connector. I used my DB9F-DB25F adapter at the server to plug into COM1. Oh, and of course, it wouldn’t physically fit with both serial ports stacked vertically at the back of the server, so I had to remove the power supply and move the 9 pin port to another spot on the back of the case. Regardless, I was short one adapter. I had to MacGuyver the existing adapter because Radioshack decide the 9 pin side needs those little hexagonal screw retainers which won’t mate with identical retainers on the port at the PC. To make it work, I used pliers and physically ripped the retainers from the adapter (no, they were not screwed on, they were welded to the ground plate). It was ugly, but it worked.
I ran to RadioShack and bought two adapters. To avoid the problem, I bought an adapter with a male 9 pin and then purchased a 9 pin F-F gender bender to provide some spacing at the PC connection. Back onsite, I got it all connected and pretty easily got a terminal session going in a window under Windows XP.
Printing proved to be a bit of a challenge. This PC has a parallel connected inkjet but their old application needs to print to this monstrous DataProducts 8820 wide-carriage dot matrix printer. I successfully printed a small report to the inkjet, but I knew it wouldn’t work for some of those 160 column reports. I checked the inkjet and realized it supported USB, so we robbed a USB cable from a computer down the hall and I reconfigured the printer to use USB. I then used the parallel port to connect the dot matrix. Windows didn’t have an appropriate print driver and I couldn’t find one through google, so I installed the printer as a generic text printer and let Windows send a test print job. So far so good.
I fired up the application and tried to send the same report to the dot matrix. Winterm gives me something like Unable to print to LPT1. retry/discard output. I give up. Opening a dos window, I’m able to copy a text file to the printer without errors. I suspect the problem is buried in how the application addresses LPT1, but I’m pretty confused since I printed succesfully to the inkjet earlier.
I clean up the windows printer list a bit by removing about six unused printer configs and reboot to confirm the problem didn’t clear up. Sadly, it didn’t. I mentioned before I used to program heavily in Clarion For DOS and I know it pretty well and have dealt with many of its foibles running under various versions of Windows. I figured I could eventually get it working, but I decided to recommend a product I’ve used sucessfully before. I told my customer what the circumstances were and recommended they drop $25 on DOSPrinter, a very useful program that can either grab text files and properly send them to any windows printer or intercept LPT1 and send it to any windows printer. Basically, $25 is less than they’d be paying me for additional labor to troubleshoot, so they agreed to try the software.
I reconfigured Winterm to send all printer output to c:\winterm\print.me and installed DOSPrinter. After a really brief configuration, DOSprinter grabbed the output and printed it to the correct printer. Success! Before I finished, I decided to edit the LPT port in device manager and changed it to LPT2. I didn’t want any future tinkering with DOSPrinter to break anything, so I wanted it safely away from LPT1 and potential capturing/redirecting activity.
All in all, the customer was VERY happy to have their system up and running again. The final casualty list was one dumb terminal, one Digiboard Com/8i, probably one Digiboard DB25 8 port octopus cable, and some minor bruising to my ego for not leaving the hardware side technically perfect. Life goes on.