Microsoft TV Commercial: "Computers are great for kids because they have infinite patience . . . That's a good thing."

In the Trenches with LAROKE

Konsultant's Log, Cyberdate 09.21.1998 (Rube Goldberg work-arounds and other Windows misadventures)

SITREP: This log entry tells the story of my first confrontations with the Windows NT operating system. In the last Trenches log entry, I mentioned we had added another new CAD workstation to the network at the architectural office where I spend my days.

This machine, "Cygnus" (named after a binary star system), is our first Windows NT PC (Windows NT Workstation v4.0 with the Service Pack 3). It is a Dell Workstation 410 with dual 400MHz Pentium IIs. We connected Cygnus to the "Deep Space 9" Ethernet 10BaseT network hub which in turn connects to our main Ethernet 10Base-2 thin coax network segment I call the "Stilwell Burma Road" because of its low-bandwidth and serpentine routing through the office. I let Cygnus' operator, Cormac, do the initial setup. Everything went well. Windows NT v4.0 was installed without incident as well as AutoCad r14. After that, the wheels fell off.

First, I discovered that my network operating system, Invisible LAN, would not work with Windows NT. The next major kick in the head came when AutoCAD began to malfunction in a major way. Then I had problems figuring out how to get Cygnus to synchronize his clock with that of "Johnny Mnemonic", the time server for the network. Bringing up the rear is a Rube Goldberg solution allowing Cygnus to send CAD plot files to the CalComp Plotter connected to an old AST 286/12MHz MS-DOS PC, "Kenny A".

TACAMO:

Problem 1: First, we have to agree on protocols

When I discovered Invisible LAN could not be installed on Cygnus, the Microsoft Networking components were installed. The Windows NT network installation procedures are completely different from the Windows 95 procedures (why doesn't this surprise me, anymore?) and since we were under the gun to get this system up and running on the network, I didn't document the process in the Cygnus log at the time. I know I will be punished for this act of omission at some later date. It's just the way things work in the Wintel world.

After the MS Networking components were installed and configured, Cygnus could see the other two PC's on the LAN that had MS Networking and they could see him. It was about this time a nasty network glitch began to manifest.

A little background is in order here. Some time back, Brian Livingston's column at InfoWorld explained how to create a "Send To" over the network to another User's Windows 95 Desktop. What is a "Send To"? When you Right-click a file (or folder) in Windows 95, one of the Context-sensitive Menu choices is "Send To". Some of the default "Send To" Submenu selections are the floppy drive and the Windows 95 Briefcase. If a user right-clicks a file and exercises the "Send To" floppy drive option, that file is copied to the floppy drive (providing a diskette is in the drive). At the architectural office we find it useful to send CAD drawing files to each other when several people are working on the same project. Using Brian's article, we setup "Send To" line items for each CAD station on the network. This little feature was working splendidly and became very popular. End of background history.

As I said, we had a new glitch and, boy, was it ugly. All of a sudden when someone tried to send a file across the network to another user's Desktop, the sending computer's screen would lockup, while the receiving computer would get an even more severe "blue screen of death" requiring a reboot. This malfunction did not affect every machine but it upset the apple cart with most of them. Through some diddling around I found that If the "Send To" mapping used the Invisible LAN protocol, the glitch would occur while a mapping using the MS Networking protocol would be unaffected. I reasoned the new Windows NT system was causing this malady and that changing to the MS Networking components on all the Windows 95 machines would put things right again. I was wrong on the first premise and right on the second. I would discover several weeks later that QuarterDeck's ViruSweep Extra Strength which I had installed on several of the Windows 95 machines about the same time Cygnus arrived was the real culprit that was causing fits with the Invisible LAN NOS.

At any rate, the arrival of Cygnus has signaled the gradual phasing out of Invisible LAN at this office. I am sad to see it go. We have been using it since the late eighties when its main competitor was Lantastic and Microsoft didn't even offer a peer-to-peer NOS. I proceeded with the tiresome task of installing and configuring MS networking components on all the Windows 95 PC's on the network that didn't already have them installed. Unfortunately, we do not have MS Networking components for the MS-DOS and Windows 3.x machines still in operation. Legend has it that they are available at the Microsoft site, but I haven't had any luck finding them. Therefore Invisible LAN is still on all the machines that will run it for communication with the MS-DOS and Windows 3.x PCs.

After the MS Networking components were installed, a network of thirteen PC's resulted in which the ten Windows 95 machines could communicate with every other PC on the LAN, The Windows NT machine could communicate with all machines except the Windows 3.x PC and the MS-DOS PC, and those two PC's could talk to everyone but the Windows NT machine. The above situation is workable except that Cygnus produces plotter files which are normally sent to the Calcomp plotter connected to Kenny A, the old 286/12MHz MS-DOS PC. The convoluted, and I hope temporary, solution to the plotter problem is explained at the end of this log entry.

Problem 2: AutoCAD Challenged

Cygnus is a leased machine built specifically to run the Bentley MicroStation TriForma architectural CAD system. Currently, nobody in the office has any familiarity with the Bentley system. Cormac is well-versed in AutoCAD and due to the press of work must continue to work with that software until he is up and running with Bentley. I let Cormac install AutoCAD r14 and transfer his AutoCAD settings from his previous workstation, "Shamrock I". All was well for a few days.

KURRENT KONUNDRUM #3

Then one morning AutoCAD displayed a "FATAL ERROR" message and closed AutoCAD. From that point on When AutoCAD was opened, all but two menu items were missing, along with all the toolbars and Cormac's custom configuration settings. Not knowing anything at all about Windows NT as of yet, we were reduced to uninstalling AutoCAD and re-installing/reconfiguring it. The fatal error event occurred once that day. The next day it happened several times. Cormac became pretty proficient at installing AutoCAD. Eventually, Cormac discovered how to backup his settings, toolbars, and menus so that only they needed to be restored in lieu of re-installing the entire AutoCAD application. A few days later the fatal error bug disappeared as mysteriously as it appeared. We still haven't a clue as to what causes it, and Cygnus can go for weeks without problems when, out of the blue, the bug puts in another appearance. I have the feeling we'll be scratching our heads over this until Cormac is on the Bentley software exclusively. If any of you AutoCAD r14 on Windows NT experts out there have run into this problem, and have solved it, I'd appreciate your help.

REPLY TO THIS S.O.S.? email address (required) Name (optional) Enter your comments below

Problem 3: Does anybody know what time it is?

Once you connect two computers together, you have a network and you are, by extension, a network administrator. network administrators usually prefer to have the computers on their network agree on the date and time. In the movies, commandos always synchronize their watches. This is good for computer networks also. Most network operating systems have utilities to synchronize the computers.

In the network Cygnus is connected to, Johnny Mnemonic is the "time server". Johnny is on a UPS and runs 24/7 (twenty-four hours a day seven days a week).

Two machines on the network, "Merlin" and "Kenny A" use an Invisible LAN DOS utility to synchronize their RTC (Real Time Clock) with Johnny's every time they boot up in a network configuration. This is a accomplished with the following line in the AUTOEXEC.BAT file (System 21 is Johnny's Invisible LAN designation):

C:\NET30W\NETCLOCK.EXE \\SYSTEM_21\

All the other PCs (except Cygnus) on the network synchronize their clocks with Johnny on startup using a Windows 95 Invisible LAN Utility. A Windows 95 Shortcut is placed in the Startup Folders of the Default User and the Primary User. The Shortcut uses a command line parameter to set the time every time Windows 95 is started by the Primary User or any User who does not logon:

C:\WINDOWS\NCLOCK95.EXE -quiet \\SYSTEM_21

Other Windows 95 machines that run 24/7 and are not often re-booted use scheduling software run the same command and set the time daily.

I couldn't synchronize the clock on Cygnus using the above methods since I couldn't install the Invisible LAN protocols on him. A few weeks after Cygnus' initial setup. I was clued to a solution by one of the postings on one of the mailing lists I belong to. WinGate, I think. I learned of certain DOS commands that are available when MS Networking is installed. (If you have MS Networking installed, open a DOS Window and issue the command "NET | MORE" at the prompt. You'll see a screen and a half of "NET" commands that can be issued at the prompt and, more importantly, be used in batch files or scripts). The particular command I was interested in is the "NET TIME" command.

After twidling around with it for a bit, I came up with a batch file "TIMESET.BAT" with the single line "NET TIME \\mnemonic /SET /Y" in it. When run, it gets the date and time from the computer with the MS Networking name "mnemonic", then sets the clock in Cygnus without asking the user for confirmation. So that this batch file would run every time Cygnus was started, I put it in Cygnus' "C:\WINNT\Profiles\All Users\Start Menu\Programs\Startup" Folder.

This solution worked great except for one thing . . . after TIMESET.BAT ran, Cygnus' time would be exactly three hours early. This bug had me baffled for the better part of a day. When I got the answer, it was one of those "kick yourself" revelations. I went to the Microsoft site and it was one of those all too rare occasions when I actually found what I was looking for. I guess I'm not the only member of this particular kick yourself club.

"NET TIME" checks for more than just the date and time of the machine it is querying . . . It also checks Time Zones which makes the utility useful in a WAN environment. The time server PC, Johnny Mnemonic, was correctly set for his location, The East Coast of the USA. Cygnus thought he was on the West Coast. (Redmond, WA is the center of the World as far as Microsoft is concerned). Cygnus was chopping three hours off the time he got from Johnny because he thought he was a continent away instead of twenty feet! Once I got Cygnus properly zoned in, everything was hunky-dory.

Problem 4: Can we talk?

As I mentioned above, Cygnus (a CAD workstation) cannot communicate with Kenny A, the plotter server. I understand there are MS Networking components for MS-DOS that should let these two machines work together, but I do not have them. I also understand that they are provided on the Windows NT Server CD, but we do not need to setup a Windows NT server in this office yet and I can't justify the expense. Also as I stated above it's rumored they are available on the Microsoft site, but I have not come across them in my searches through that labyrinth.

For the initial weeks of Cygnus' operation we overcame the problem with the following procedure. Cormac would send a CalComp formatted plot file to a temporary directory on his old workstation "Shamrock I". Then he would walk over to Shamrock and ask Luis, Shamrock's new user, to take a break for a minute. Cormac would open a MS-DOS Window in the temporary directory and issue the following command at the prompt:

COPY filename.plt LPT2

In DOS, any file copied to another file called LPT#, will send the file to the printer connected to the LPT# port. In the case of Shamrock, there are no printers connected, but all output to LPT2 is "captured" by the operating system and sent to the plotter on Kenny A using the Invisible LAN protocols.

MS-DOS then reports to Cormac that "1 File has been copied" and, if the office is quiet enough, he can hear the CalComp start up in the plotter room. Cormac closes the MS-DOS window, thanks Luis for the brief use of Shamrock and returns to Cygnus.

All that is a pain in the butt for both Cormac and Luis. We needed a method whereby Cormac could manipulate Shamrock (or another Windows 95 computer that could communicate with Kenny A) from Cygnus' DeskTop. Once again someone's posting in the WinGate mailing list pointed me in the right direction. Someone had requested information about Telnet servers for Windows 95 and somebody else suggested "Fictional Telnet Daemon" available at www.fictional.net (Telnet is a program that lets you control a computer remotely over a TCP/IP network).

I downloaded and set up FTD (Fictional Telnet Daemon) on Shamrock I for Initial testing. After successful sea trials, I installed FTD on the server "Johnny Mnemonic" so that Luis would not be distracted by a DOS Window opening on his workstation whenever Cormac had to send a file to the plotter.

Now the procedure Cormac follows is slightly less exhausting and there isn't any walking involved until the plotting is finished. The steps he completes now are as follows: He first plots a file from Cygnus directly to a temporary directory on Johnny Mnemonic (using the MS Network protocols). Then he starts a Telnet session by double-clicking a Telnet shortcut Icon on his Windows NT Desktop (using the TCP/IP protocols). I set up this shortcut to connect to the Fictional Telnet Server on Johnny using the Telnet client that comes with Windows. After logging in with his user name and password, Cormac issues the following command at the Telnet prompt:

CMD COPY filename.plt LPT2

This is the same as the command he used to walk over to Shamrock to issue with the exception of the "CMD" prefix. The prefix tells the Fictional Telnet Daemon that the command is a DOS command, not a Telnet command. MS-DOS reports to Cormac (through the Telnet interface) that 1 File has been copied (sent using the Invisible LAN protocols) and that's all there is to it thanx to Patrick van Venetiën at FTD who wrote Fictional Telenet Daemon in Visual Basic 5.0.

MISREP: Whew! All that work just to get one Microsoft Operating System (Windows NT Workstation) to work with another Microsoft Operating System (MS-DOS 6.2) through a third Microsoft Operating System (Windows 95). Ain't the Wintel world wonderful?

Microsoft would probably tell me I would not have these difficulties if I upgraded all my hardware and software instead of clinging to my legacy systems. That's like trying to keep an infant in shoes . . . You have to do it every six months. And excuse me if I don't fully trust Microsoft any more . . . I've been in bed with Microsoft products since the late seventies (Applesoft Basic for the Apple II) and the glow wore off for me a long time ago. It's been my sad experience you just trade an old set of problems for a new set of problems every time you upgrade. Forgive my cynicism but during the years of my relationship with Microsoft, Bill has been getting rich and I've been just getting old. To Quote Nicholas Petreley of InfoWorld: "Why are we working so hard? Because we've got products that hardly work."

OK then. I feel better. Time to get down off my soapbox and kick it back into its corner of the Krash Lab until next time.

LAROKE Microcomputer Consultants
155 East Boca Raton Road
Boca Raton, Florida 33432
(561)368-0659 (Tel & Fax)

Issued Monday September 21, 1998

copyright © 1996-1998 LAROKE Microcomputer Consultants all rights reserved

Search www.laroke.com the Web for