SHOW, AND TELL

by Wayne M. Krakau - Chicago Computer Guide, December 1992

At last, the final trade show of the major Chicago trade show season - PC Expo! This show wasn't as focused as in previous years, there being no central pressing issue driving the industry (at the moment), and providing a theme.

In hardware, the NEC Silentwriter Models 95 and 97 caught my eye (NEC Technologies, Inc., Boxborough, Massachusetts). They are six and ten page per minute laser printers with an extra trick. They are upgradeable to include both send and receive faxing. They also can be purchased with the fax feature preinstalled as the 95FX and 97FX.

If the printer is busy, incoming faxes are held in memory and then interspersed with regular print jobs. Outgoing faxes are generated with the supplied DOS and Windows compatible software. The software even works over a network, providing a shared fax/printing solution.

I'm a big proponent of computerized fax, especially on LANs. The print quality of received faxes is as high as the most expensive plain-paper faxes. In addition, the computer generated outgoing faxes skip the scanning step that is the weakest link in the process. This means that no matter what the eventual output device (fax paper or plain paper), the documents look great. It also eliminates waiting first for your printout, and then for the fax machine.

These fax printers have an extra feature that activates when two of them fax to each other. The output is a full 300x300DPI (dots per inch), standard laser resolution (at least until the HP Laserjet IV was released) as opposed to fax resolution, 200x200DPI in the fine mode.

On top of all of this, the printers are very functional "normal" printers, too. They have Adobe Postscript and HPCL5 (the Laserjet III language) emulation with automatic language and port switching. They have a 250-sheet feeder standard (a second is optional) and a 10-sheet envelope feeder.

The 95FX (6PPM - page per minute) is a good choice for single users or for small workgroup LANs while the 97FX (10PPM) has the speed for larger LANs.

On the software side, PC DOCS Open (PC DOCS, Inc., Tallahassee, Florida) has just been released. This is a complete rewrite of this prominent document manager. Instead of just supporting WordPerfect in a DOS environment like its predecessor, it now supports multiple word processors in your choice of DOS or Windows (though the DOS version obviously isn't as flexible).

It now uses Sybase's SQL Server as its profile database (as opposed to its full text index), boosting its speed over a network. This is a very practical application of client-server technology. This strategy splits a database into two parts. The workstation part handles initial editing, help, typing, and translating requests into a common language (SQL - Structured Query Language). The server portion actually finds the data and sends only the results of the query back to the workstation. An additional advantage to this splitting of functions is that (within limits) you can mix and match back ends (the server portion) and front ends (the workstation portion). PC DOCS, for instance, is capable of using Microsoft SQL Server, Gupta, Netware SQL, or Oracle as alternatives to Sybase SQL Server. More client-server applications are sure to follow.

The Windows version of PC DOCS is particularly attractive in that almost every part of the screen is modifiable with a tool called DOCS Designer. Since document management is such a horizontal (non-industry specific) application, the ability to customize this powerful product is vital.

SHELL GAME

The standard way to access Netware from a workstation (commonly called the shell) has changed. For some time, there have been two coexisting standard types of shell. The old version had to be generated using a utility called WSGEN (or the older SHGEN), which combined information from the Novell-supplied IPX.OBJ file (IPX.OBJ contains IPX, the Internetwork Packet Exchange program and SPX, the Sequenced Packet Exchange program) with information in a driver file (a driver is used to allow two or more items of hardware and software to talk to each other) supplied by the vendor of the Network Interface Card (NIC - pronounced "Nick" - Buzzword Alert: It is considered uncouth to say "NIC card"; the proper expression is "NIC"). The resulting file, IPX.COM, is executed in tandem with NETX.COM. A parameter file called SHELL.CFG was used to alter characteristics of the shell.

Note that NETX is not the same as NETx. NETx is an older program where the small "x" was replaced with a number indicating the major DOS version number. If your workstation ran DOS 3.1 or DOS 3.31, for example, you used NET3. For DOS 4.XX you used NET4, and for DOS 5.XX, NET5. These NETx's have not been fully supported since the NETX was written. NETX automatically adapts itself to any DOS version from 3.00 on up. Unfortunately, Novell chose to name these two separate programs in a confusing manner so that they are both pronounced as the two word combination "NET X". NETx was generated by WSGEN (or SHGEN), the while NETX is obtained from Novell, usually via Netwire.

Sometime late last year, Novell stopped testing the WSGEN-based IPX programs. At that time, without any announcement that I've seen, they started giving full support only to the newer way of doing things. I found this out the hard way while trying to fix a problem that two clients were having with remote printing.

The new (actually it's been around for quite a while, but wasn't mandatory) shell is called the ODI (Open Datalink Interface) shell. Where WSGEN was used to tell the software the NIC hardware settings, the new NET.CFG file takes over. It is a replacement for the SHELL.CFG file. It accepts all of the old SHELL.CFG parameters plus some new ones. The most important new commands involve the NIC hardware settings. The lack of a separate generation process such as WSGEN will make maintenance much easier. It also lifts the burden from the NIC manufacturers of rewriting huge complicated driver files every time Novell makes the slightest change in the shell. Now, their drivers change only when they redesign their NICs.

One warning about the NET.CFG file (and its predecessor, SHELL.CFG) is in order. It must exist in the directory where its associated files (IPX, IPXODI, LSL, NETX, the NIC drive file) exist and you must physically be in that directory. This makes the proper procedure - probably in a batch file such as AUTOEXEC.BAT - to first, go to the subdirectory where all of the shell-related programs reside, and second, to execute the appropriate combination of these programs. Then you can switch back to your "regular" directory.

Since it is often impractical to change all of your workstation shells at once, a multistep strategy may be used. The initial procedure would be to upgrade any critical or special-purpose machines. This would include file servers, fax servers, communications servers, print servers, gateways, and workstations that handle remote printing (via RPRINTER.EXE or a third party equivalent).

After that, upgrade the shell only of those machines that are being accessed by the system administrator for troubleshooting, other upgrading, or installation. If the user is helped or trained on a particular workstation, that could also provide an opportunity for a shell upgrade. Eventually the whole network will run under ODI.

Writing about the need to have up-to-date software in order to get full vendor support reminded me of a recent conversation I had with a systems administrator who I was training. His company had just signed a contract to get Netware 2.2 installed on dozens of networks at their offices nationwide.

After demonstrating how complicated it is to install and maintain Netware 2.2 (and worse for earlier versions), we discussed his company's plans for the future of their LANs. Most of the things they wanted to do were either available only on 3.11 networks or could be done on 2.2 LANs only with serious compromises in speed, reliability, features, and administration overhead.

This discussion elicited a few choice words from him (which I can't print in this publication) regarding his company's strategy and the ethics of the vendors involved. Notice that "vendors" is plural. He informed me that there were separate contracts for the software, the hardware, the associated communications systems, the installation and support, and finally, the training. (Actually, other than this person and one of his colleagues being trained as troubleshooters by me, no other training was scheduled.)

After he reverted to repeatable English, we jokingly formulated a litmus test for choosing a reseller, but ended up with a potentially useful rule to follow. If, through advertising or personal contact, a reseller has proposed to sell Netware 2.2 (or worse, an earlier version) within the last "X" number of months, one of the following is true:

A. The reseller is so out of touch with the real world that he or she doesn't even realize that Netware 2.2 is a complete dead end, long relegated to second class status by software and hardware manufacturers, and more recently by Novell. Therefore, why should you deal with them?

B. The reseller knows the above information, but wants to get rid of the leftover stock of Netware 2.2, and has no ethical problems with tricking a client into buying an inappropriate product. Therefore, why should you deal with them?

C. The reseller knows the above information, but wants to make a lot of extra money in installation, troubleshooting, training, maintenance, and upgrading fees by selling a more primitive product with high cost requirements in all of these areas. This reseller must have no ethical problems with withholding the fact that the cost difference between 2.2 and 3.11 can be justified by its lower costs in these areas. Therefore, why should you deal with them?

The only point of disagreement was the number of months to fill in the "X". He was thinking of the eighteen to twenty-four month range, while I was more inclined towards the twenty-four to thirty month range (to cover the tail end of the Netware 2.15 era), both being based on December, 1992 as the starting period for the calculation. He did mention, however, that his company's LAN contract was issued in the first quarter of 1992. Hmmmmmmmmm?