THREE FOR THE ROAD

by Wayne M. Krakau - Chicago Computer Guide, January 1994

SFT III UPDATE

Finally -- it actually works! My first Novell Netware SFT III has been running for ten days as I write this. The two servers are talking to each other like reunited twins who were separated at birth. As advertised, either server can be downed (the "DOWN" command is used to shut down a Netware server so this verb is commonly used) without hurting the network. The users don't even know that it's happening. They only notice when the downed machine is restarted because the network slows while the restarted computer is updated.

While this is convenient for maintenance and upgrades, the real value is protecting the network from server crashes. As I suggested to the client, you could take an ax to one of the servers, and the LAN would keep on ticking. Try that with your Timex!

There was a downside to this project. It took an incredible number of non-billable hours of research and experimentation to get the system working, but I sold the system, and I told the client it would work, so I had to make good on my promises. (Having ethics can be quite expensive!) Working in conjunction with the vendors, we went through two pairs of motherboards, three pairs of MSL (Mirrored Server Link) network cards, five separate sets of MSL cabling, and enough driver software versions (for talking to various hardware items) to fill a CD-ROM. That's all in addition to hundreds of dollars in Compuserve bills for tech support and software downloads.

The implied question is whether I would suggest SFT III for others. Yes, I would. As I have debugged this installation, others, as observed on Compuserve, have been successfully debugging other SFT III systems around the world. The technology isn't perfect, but it has become reasonably stable.

THE NAME GAME

During a recent LAN upgrade (new Netware, new server, new workstations), I noticed that the workstation that was doing network backups to an internal tape drive was hung up with an error message indicating that it had encountered an error accessing COM3. I restarted the backup and let it run while we configured the new server and workstations.

When I returned to that machine, it had again hung up with the same message. A reboot gave a message warning of major motherboard problems. Oh well, the computer was being replaced on that day, so I just chalked the error up to the final screw-up of a dying computer and went back to the new systems.

We left another computer running overnight to transfer data from the old server to the new server with the NCOPY command. NCOPY was used since it is a miniature client/server implementation of a COPY command. It lets the servers do the work, leaving the workstation to just display the results.

The next morning, we found the NCOPYing computer stuck, but not hung up, with a message about an error reading from COM3! We couldn't believe that two machines could fail with the same obscure error. This time, however, we could see the information on the last few files copied that remained on the screen. The last file name in progress was called -- you guessed it -- COM3! A simple response of "I" for "Ignore" was all that was needed to allow NCOPY to finish.

The reason for the errors was that someone had inadvertently named the third correspondence for a particular project COM3. That is one of the "magic" words that DOS reserves for its own use. Netware doesn't care about it, so it allows that file name to be written. It is only when some internal DOS process tries to access this reserved name that errors occur.

Because of this incident, I thought I'd pass along a warning. DOS reserves the following names for its own use: AUX, for the auxiliary port; COM1, for communications port number one; COM2, for communications port number two; COM3, for communications port number three; COM4, for communications port number four; CON, for the main console, that being the screen and keyboard; PRN, a synonym for printer port number one; LPT1, for printer port number one; LPT2, for printer port number two; and LPT3, for printer port number three. These names should not be used for the first name of a file. Using a last name with them won't help. DOS still recognizes the first name and ignores the last.

An interesting trick to solve problems encountered with Microsoft Windows when using print spooler software (programs that rapidly save printouts to disk or in memory and feed it to the printer only as fast as it can accept it) takes advantage of these reserved names. You can disable printing directly to hardware and then redirect the printout within Windows to a file name like LPT1.DOS. DOS will ignore the last name and feed the output to the logical printer port. Since most print spooler software works by intercepting data sent to the logical printer port via standard DOS services, this allows Windows to cooperate with this type of program.

EXTRA!, READ ALL ABOUT IT

Attachmate Corporation (800-426-6283), makers of mainframe and minicomputer terminal emulation software for IBM environments, and inheritors of Novell's own products in that arena, have just released the beginnings of a series of products designed to make life much easier for people trying to automate IBM mainframe and MINI shops.

Attachmate makes the EXTRA! series of Windows-based emulators. Now they have created products that allow selected other programs to tap directly into their emulators and manipulate them as needed to automate tasks. One is for Microsoft Office. Office includes Microsoft's Word, Excel, Powerpoint, Access, and Mail products for Windows. Attachmate's EXTRA! Tools for Microsoft Office contains programs to allow easy, automatable transfer of data to and from these products and their Extra! emulators.

A product with even more interesting possibilities is Attachmate's EXTRA! Tools for Visual Basic. Microsoft's Visual Basic already contains features that make it one of the top tools for integrating and automating multiple products within the Windows environment. These Tools add the ability to tap right into all of the abilities of EXTRA! and tying them into almost any other Windows application. This is an amazing breakthrough for systems integration. This product can potentially eliminate many thousands of hours of manual programming for those trying to improve productivity and ease of use in IBM minicomputer and mainframe installations.