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.
File and Print Sharing Configurations
If you run PATHWORKS clients for only file and print sharing, you're better off migrating your clients to NT Workstation or Win95 and connecting them to your servers using TCP/IP, rather than the DECnet and Local Area Transports (LATs) you probably use now for client/server connections. If you have the hardware and server software that the Windows OSs require, migrating your clients will give you the same file and print capabilities you had with PATHWORKS real mode network clients, plus increased stability and performance. If you can't migrate your system to TCP/IP, you might be interested in Digital's latest client software, PATHWORKS 32, which provides classic PATHWORKS transports for connecting your PCs to your network.
Don't waste time trying to run NT Workstation, Win95, or WFW with a PATHWORKS 4.x server. You can run these Windows products with 4.x servers, but they will work sporadically. Your users will end up cursing you and PATHWORKS. The PATHWORKS 4.x server software worked well for my clients for more than 6 years, but now that it's more than 10 years old, it's not very compatible with new Windows products. To make the PATHWORKS server software compatible with more advanced Windows clients, Digital had to reinvent it: version 5.0 began this process, and version 6.0 further advances it. Table 1 provides general recommendations for your client configuration.
Move the file shares. The advances Microsoft has made in its network clients simplifies the client configuration decision, but deciding whether to move your file shares to NT is more complex. If your clients use these file shares only to exchange data between PCs, you might want to move that data to NT servers.
You'll probably want to move your file shares to NT if you already have NT Server and Windows client access licenses, if the system you run PATHWORKS on is overloaded, and if the version of NT Server you have access licenses for offers the same printer access and high availability features as your existing PATHWORKS system. Migrating to NT servers doesn't make sense if your firm has a right-to-update contract for PATHWORKS and runs a PATHWORKS configuration that supports a few hundred users. It makes even less sense if you run PATHWORKS Server on an underused Alpha system with RAID 5 and Error-Correcting Code (ECC) memory and you plan to run NT Server on anything less than a server-class PC. In this case, you're better off upgrading your server to PATHWORKS 6.x and moving your clients to NT. You can still use a PC for Primary Domain Controller (PDC), Windows Internet Naming Service (WINS), and Dynamic Host Configuration Protocol (DHCP) duty. This solution lets you run NT but keeps your system manageable and your additional licensure expenditures low.
Does your company need to make the output from your OpenVMS programs accessible to clients via file shares? This question presents another issue you must consider before deciding to migrate your file shares to NT servers For example, your users might need to generate files in OpenVMS applications and parse those files in PC-based programs to include them in reports. If your PATHWORKS server runs an FTP server, you might be able to move your file shares to NT and rely on graphical FTP utilities to meet your OpenVMS file access requirements. However, if you need to access OpenVMS files through file sharing and if FTP utilities won't meet your needs, you can't move all your file shares to NT. You need to run both NT and PATHWORKS servers.
Finally, you must consider how important high availability is to your organization. If your PATHWORKS servers run on OpenVMS Clusters, then moving your file shares to one NT server will result in reduced availability. NT might be able to meet your clustering needs, but you're probably better off leaving critical file shares on a PATHWORKS server. To implement NT clustering, you have to purchase NT Server, Enterprise Edition (NTS/E) or another shared storage-based clustering solution. NT clustering products support only shared nothing clusters, which means that only one node at a time can access a disk device. In addition, LifeKeeper is the only NT clustering product that can support more than two nodes in a cluster. In contrast, PATHWORKS's OpenVMS servers support Digital's cluster file system and distributed lock manager, which lets the servers operate in a shared disk mode. Shared disk clustering lets any node in the cluster access any disk device. NT's clustering limitations might not last long. Digital is working on bringing its cluster file system, distributed lock manager, and enterprise storage expertise to NT.
Print sharing. Printer access also becomes an issue when you consider migrating to NT. You have to sort out how your PATHWORKS servers access your printers. If your printers connect to older Digital or third-party terminal and print servers, the servers probably access the printers via Digital's LAT protocol. To migrate your environment to NT servers, you have to add the LAT protocol to your NT server or upgrade your print servers to support TCP/IP and printing via a Line Print Daemon (LPD). You might think the LATs in PATHWORKS 32 7.0 would fill your need for LAT on NT. Unfortunately, Digital doesn't support printing over its version of LAT for NT; the transports only support terminal emulation. For print support you have to turn to Meridian Technology's SuperLAT. (For information about SuperLAT, see http://www.meridiantc.com.)
If you decide to keep PATHWORKS on your file and print servers and want to run the latest Microsoft software on your clients, you need to upgrade to the latest version of PATHWORKS server that you can run on your network: version 6.0 if you have OpenVMS 7.1, or version 5.0f if you have an OpenVMS version between 5.5-2 and 7.1. If you can configure your servers to support TCP/IP connections, this upgrade will provide smooth communications between your servers and clients. If you're stuck using a pre-5.5-2 version of VMS because of an application limitation on your system, you want to upgrade your server to PATHWORKS 4.2-1 eco 9, which fixes some of previous PATHWORKS versions' problems. You won't have the best interoperability with Windows clients, and Digital stopped supporting PATHWORKS 4.x in December 1996, but at least you'll solve some of your server problems.
Terminal Emulation
The other use of PATHWORKS is for terminal emulation. Many companies use SETHOST or VT320, the terminal emulators that Digital includes with PATHWORKS client software, to run character-based applications on OpenVMS systems. If you use PATHWORKS client software for terminal emulation and you decide to migrate your clients to NT or Win95, you need to either add a third-party terminal emulator to your client configuration or upgrade your clients to the PATHWORKS 32 7.0 client. This latest version of PATHWORKS includes an updated version of VT320 and Ericom's PowerTerm 525, a third-party 32-bit terminal emulator. PATHWORKS 32 7.0 also includes Digital's eXcursion, an X-terminal package, and the PATHWORKS product costs less than many third-party emulators.
Making Your Decision
You must take these factors into consideration as you decide whether to stick with PATHWORKS, integrate your PATHWORKS environment with NT, or migrate your PATHWORKS clients and servers to NT. Using these guidelines to decide whether to add NT to your PATHWORKS network or migrate your clients and servers completely to Windows products doesn't make the decision simple. You still have to overcome problems. Keep in mind that PATHWORKS is complex, so don't get disenchanted if you feel overwhelmed. The path to a powerful, efficient OS is rarely straight.
