Pathworks and NT

Many people wish they had bet on Microsoft 10 years ago; that bet would sure be paying off now. Some of us inadvertently made that lucky wager by installing Digital Equipment's PATHWORKS for OpenVMS (known in 1987 as VMS services for MS-DOS) on our servers and PCs. PATHWORKS has long been aligned with Microsoft networking, so it is a perfect environment for integrating with or migrating to Windows NT. I didn't decide to add PATHWORKS to my clients' networks because of foresight, though. PATHWORKS made sense at the time. Only years after I installed the system did I realize I had bet on Microsoft networking. Now my clients and I get to reap the rewards.

If you run PATHWORKS, you're probably trying to decide whether to stick with PATHWORKS, integrate NT into your current system, or migrate to a strictly NT environment. Deciding what to do with your system is complex. You need to examine why your company began using PATHWORKS, what your company uses the software for today, and which solution will work best for your organization. If you run PATHWORKS for OpenVMS, this article will help you examine these issues and decide whether to move to an NT environment.

What Is PATHWORKS?
In working with clients around the world, I've found that few people understand what PATHWORKS is, or why and how their company uses it. PATHWORKS began as a product that provided Microsoft-oriented network connectivity between Digital VAX computers running VMS and DOS-based PCs. Over the years, PATHWORKS expanded into a suite of server and client products that provided NetWare 3.x-like network connectivity for DOS PCs and Macintosh Apple file and print systems. A PATHWORKS offshoot supported Santa Cruz Operations (SCO) UNIX. (For more information about the history of PATHWORKS, see John Enck, "The Digital Connection, Part 2," April 1996.)

During the past few years, the PATHWORKS product line has shrunk. PATHWORKS still provides connectivity between PCs and host-based computers, but Digital has recently made major enhancements to only the server-side OpenVMS and UNIX products. Digital still offers the PATHWORKS 32 client, but it is little more than a collection of Digital transports and terminal emulation packages.

Today Digital sells four PATHWORKS products: PATHWORKS 6.0 for OpenVMS (Advanced Server), PATHWORKS 5.0 for OpenVMS (LAN Manager), PATHWORKS 6.0A for DOS and Windows, and PATHWORKS 32 7.0. Digital sells only two PATHWORKS licenses: the PATHWORKS for OpenVMS (Advanced Server) Client Access license, which gives clients the right to access a PATHWORKS server, and the PATHWORKS 32 7.0 System license, which gives you the right to run PATHWORKS client code on your NT, Windows 95, Windows for Workgroups (WFW), and DOS clients. The latest upgrade to PATHWORKS for Digital UNIX is called Advanced Server for Digital UNIX. It ships as part of the base Digital UNIX release.

It Made Sense in 1987
I began using PATHWORKS in 1987 while working at a site that ran VMS systems on VAX machines. The company needed to add a few PCs to the network, and we had two options: We could augment the company's existing infrastructure with NetWare servers and clients and retrain the network support staff. Or, we could install PATHWORKS on the existing VMS system, buy a few licenses, and add network cards and software to the PCs.

We chose the second option. By installing PATHWORKS server and client software, we incurred a low initial cost, and we set up the PCs to use the company's existing print queues, storage space, user accounts, and security. In addition, PATHWORKS included a VT220 terminal emulation program and transports that let users work on the VAX and PDP-11 minicomputers from their PCs. These built-in features eliminated the PC users' need for terminals. PATHWORKS was an easy solution for a company that had a few PC users in a primarily host-and-terminal environment.

Still a Good Solution in the Early '90s
Soon, networks that used PATHWORKS to introduce PCs to terminal-based organizations began to change. From the couple of PCs my client had in 1987, the site quickly grew to a couple thousand PC users running many PC-based applications. The PC file and print services started to place an unacceptably heavy load on the system, which still needed to support host-based computing. Nevertheless, we were reluctant to migrate the entire system to OS/2 or NetWare. We had PATHWORKS in place, we had already learned the software's ins and outs, and the hardware OS/2 and NetWare ran on could not support the thousands of active client connections we needed.

Fortunately, Digital released PATHWORKS 5.0 in 1994 and aligned the software with Microsoft networking. Instead of continuing to write its own file server for VMS to a Microsoft specification, Digital based the PATHWORKS 5.0 Server software on LAN Manager for UNIX. Digital also added Microsoft's LAN Manager client code to the PATHWORKS client kit. These changes brought PATHWORKS servers and clients in line with Microsoft's Server Message Block (SMB) 2.x protocol. The changes coincided with Microsoft's introduction of protected-mode TCP/IP-based clients with file-level caching and NT Server 3.5x, which supported the SMB 3.x protocol.

The PATHWORKS server software was not as advanced as NT 3.5. However, PATHWORKS and NT were similar enough that my client could continue to use PATHWORKS and take advantage of Microsoft's enhancements to NT server and client software. The emergence of more powerful NT hardware and updated client transports from both Microsoft and Digital let me develop an integrated, cost-effective solution that met my client's enterprisewide needs.

My client has continued to migrate its operating system (OS) from PATHWORKS to NT since the early 1990s. As of March 1997, the site had 10 NT servers but only 3 PATHWORKS servers, and only 12 percent of its clients ran PATHWORKS. Migration to NT made sense for this particular PATHWORKS site, but many of my other clients have limited NT to a few servers.

What's Your Situation?
To integrate server and client products from Digital and Microsoft into a functional, cost-effective solution for your business, you must use each product for what it does best. Before you decide which parts of PATHWORKS you want to keep and which parts you want to supplement or replace with NT or Win95, you have to figure out how each product can best serve your company. First, you have to thoroughly understand your company's situation--its financial status, employee expertise, politics, and limitations. You must be painfully honest.

Begin your assessment with a political analysis. Do your users dislike PATHWORKS? Do they want to run NT and Win95? Because people usually prefer products they don't have (and thus don't have problems with), you probably answered yes to both questions. Fighting users' preferences achieves nothing. If your users prefer Win95's peer-to-peer networking, you will never convince them that server-centered networks' increased manageability works better for your company. If you must, let employees have a peer-to-peer network; just make sure they can also connect to enterprise-ready servers.

After you analyze the emotions and politics surrounding your company's network choice, you can begin a technical assessment of your firm's current system. Find out which versions of PATHWORKS server and client software you're running and which transports you rely on. Most PATHWORKS servers today run either version 4.2-1 or version 5.0. A few sites have moved to PATHWORKS 6.0 Advanced Server, which is similar to NT. Most sites run one of the following PATHWORKS versions on their clients: 4.1, 5.x, 6.x, or 7.x. Many sites run more than one version of PATHWORKS.

Don't worry if you find old versions of PATHWORKS on your system. The software's Microsoft networking roots simplifies connecting a PATHWORKS client from the 1980s to an NT 4.0 server. Such an integration is not as seamless as running an NT or Win95 client with an NT server, but it works as a temporary solution.

After you determine which versions of PATHWORKS your company uses, you must figure out what you're licensed to use PATHWORKS for. The financial impact of licensing PATHWORKS is a major reason why many companies are migrating their PATHWORKS servers to NT. Upgrading PATHWORKS client access licenses often costs more than buying new NT access licenses, even for as many as 500 clients.

Finally, you must determine what your company uses PATHWORKS for. Most PATHWORKS systems perform one or more of three functions: file sharing, print sharing, and terminal emulation.