Pathworks
PATHWORKS (it was usually written in all caps) was the trade name used by Digital Equipment Corporation of Maynard, Massachusetts for a series of programs that eased the interoperation of Digital's minicomputers with personal computers. It was available for both PC and Mac systems, with support for MS-DOS, OS/2 and Microsoft Windows on the PC.[1]
The server part of Pathworks ran on VAX/VMS or Ultrix and enabled a DEC VAX or VAXcluster to act as a file and print server for client IBM PC compatible and Macintosh workstations. A version of Pathworks server for OS/2 was also available, allowing a PC to act as a server instead of a VAX.[2] Pathworks server was derived from LanMan/X, the portable version of OS/2 LAN Manager.[3]
PATHWORKS was one of DEC's most successful products ever. It was probably the only DEC software product to sell over one million licenses. Since each license was priced at $495, that was $0.5B USD just in license revenue. Analysis of sales showed that on average, each PATHWORKS license dragged at least $3,000 USD in server revenue (server HW, SW, storage, printers, networking, and services), so it was a major driver for DEC's revenue in the mid and late 1980s. Before it was named PATHWORKS, it was known as PCSA (Personal Computing Systems Architecture).
Later versions of PATHWORKS were known as Advanced Server for OpenVMS. Advanced Server was replaced by Samba at the time of the porting of OpenVMS to Itanium due to the amount of effort required to keep Advanced Server up to date with new versions of Windows and the Server Message Block (SMB) protocol.[3]
Features
Once installed onto the PCs, the Pathworks client provided the following features:
- DECnet, and later TCP/IP, end-node connectivity with the host and client systems
- PowerTerm 525 Terminal emulation software from Ericom
- File-transfer software. This was a DECnet-DOS file transfer utility, although it was somewhat superfluous because the PATHWORKS server software presented VMS or UNIX files to the PC clients as if they were PC files being served by a Windows server.
The PATHWORKS server software provided access to server file storage and print services using the native Microsoft protocols. Later versions of PATHWORKS servers on VMS supported NetWare and Macintosh clients, but they never achieved the volumes of the Microsoft clients. For clients running a GUI such as Windows 3.x, additional components available included an X window system server, allowing clients to access graphical apps running on VMS or UNIX hosts, and clients for DEC's ALL-IN-1 email and groupware system. Although primitive by modern standards, PATHWORKS was very sophisticated for its time; far more than just a file and print server, it made client microcomputers into terminals and workstations on a DEC network.
Implementation
LanMan normally ran across Microsoft's basic, non-routable NetBIOS/NetBEUI NBF protocol, but Pathworks included a DECnet stack, including layers like the LAT transport used for terminal sessions. The complexity of DECnet by 1980s PC standards meant that the Pathworks client was a huge software stack to have resident in MS-DOS; configuring the Pathworks client was a complex task, made more so by the need to preserve enough conventional memory for DOS applications to run. To keep a reasonable amount of base memory free mandated the use of QEMM or a similar memory manager. This problem went away once 386-based PCs became prevalent and MS Windows provided built-in support for large amounts of memory.
History
[I apologize if this section is a bit long-winded, but I wanted provide a first-person account to convey some feeling of how the company thought and operated as well as the dry product details. Bob Nusbaum, PATHWORKS product manager, 1985-1992] In the mid-1980s, DEC was riding high. They were the second-largest computer company in the world and nipping at IBM's heels for the top spot. There was a strong belief within the company that we were the best engineering company on the planet, and many people on the outside concurred. That engineering ego led the company to try to put its own unique "value-added" differentiating stamp on every product they built.
I used to say in the 1980s that DEC's unofficial motto was "Anything worth doing is worth doing three times" because they tended to launch parallel sets of projects in threes. The company's ill-fated trifecta of entries into the PC market in 1982 had all failed: the Rainbow, like other systems in the early 1980s, was not hardware-compatible with the IBM PC, and thus got key applications late, if ever. The WPS-8 system was too limited (word processing only, with an under-powered CP/M add-in card); the Professional 350 was too expensive and slow as a result of a fatal decision to try to fit 50 pounds of RSX-11M+ operating system into a desktop system, and had no ready library of ISV applications.So for round 2, the company decided to design a PC around its strengths: networking and high-powered minicomputers that could be used as servers. The PC was called the "VAXmate", and the original version did not even have a hard disk or an exposed bus into which option cards could be added. It booted over the network, from a VAX/VMS server running software with the catchy name of "VAX/VMS Services for MS-DOS". For expansion capability, the VAXmate could be placed on top of an expansion chassis with a 10MB hard disk drive (standard at that time) and two IBM PC-compatible expansion slots. The original model was monochrome only; a color version was added about a year later as color became popular in PCs.The VAXmate and its software environment were introduced at the DECville user conference in Cannes, France in September, 1986. At a time when 10MB on a PC was a lot of storage, attendees were amazed and delighted to see mapped drives with 456MB free, which was the capacity of the hard drives used on VAXes in that era.However, the unofficial motto reared its head. At the same time, the company also introduced two internally competing products: DECnet-DOS (developed by the DECnet group) and a product called PC ALL-IN-1, developed by the company's Office Information Systems group that had productized the VMS-based ALL-IN-1 office automation system. DECnet-DOS never caught on because it did not integrate transparently into the PC environment like PATHWORKS did; PC ALL-IN-1 just didn't work well; three of the first five customers were so upset that they sued DEC.
By the spring of 1987, it was clear that the VAXmate was going to be a complete failure due to its hardware limitations. The base VAXmate unit did not have a fan, which led to thermal problems and the nickname "VAXmelt". However, customers loved the software environment transparently integrating PCs and VAXes. The PC group had a quarterly review with the VP of Low End Systems, to whom we reported. Somehow, both the Director of the PC group and the head of product management managed to be out of town on that day, so my manager, Linda Gross (now Linda Wilson) and I had to deliver the update to the VP. Our message was that the VAXmate hardware business was doomed, but there was money to be made hooking up other vendors PCs to VAX servers, creating demand for VAX CPU cycles and DEC storage, printers, networks, and professional services. And so the PC integration was born.For about two years, internal political rivalries prevented the product from getting any type of reasonable branding. By about 1989, the internal rivals had fallen by the wayside, and it became clear that the company needed to actively market and champion "PCSA". The first attempt at branding, "DEC LANworks", had to be hastily withdrawn when it turned out that the Canadian company already marketing a product called "LANworks" was not willing to license that name to DEC. The second choice for the product name was "PATHWORKS", and as they say, the rest is history.
References
- Alan Abrahams; David A. Low (1992). "An Overview of the PATHWORKS Product Family" (PDF). Digital Technical Journal. 4 (1).
- "PATHWORKS for DOS Overview" (PDF). bitsavers.org. August 1991. Retrieved 2021-01-01.
- Andy Goldstein (2005). "Samba and OpenVMS" (PDF). de.openvms.org. Retrieved 2021-01-01.
Lawrence W. White - Pathworks Product Manager
Bob Nusbaum - PATHWORKS Product Manager