Some of the main topics in this chapter are
Windows NT has a complex parentage that includes Windows, DOS, OS/2, and Microsoft's previous network operating system, LAN Manager. LAN Manager has at least one other child, which is PATHWORKS, the network operating system (NOS) provided by Digital Equipment Corporation.
Along with the rest of the computer industry, Digital recognized in the early 1980s that PCs were going to be very significant to customers and that Digital's products must be able to work with them. Digital's engineers tried a few options and then realized the job was going to be quite substantial. So they acquired the source code for LAN Manager from Microsoft and built a great solution on top of that. Over the years, Digital and Microsoft evolved their respective LAN solutions but always worked closely together. Today, PATHWORKS enables Digital customers to use their Digital computers alongside computers using Microsoft products such as Windows NT. In fact, PATHWORKS and Windows NT can be tightly integrated.
Digital Equipment Corporation has offered some of the most powerful, easiest-to-use computer solutions for 20 years. At one time, Digital was the second largest vendor in the computer industry. That success was based on well-engineered products that addressed the middle ground of problems that computers can solve, which is actually where a lot of customers find themselves. Today, Digital supposedly has 450,000 OpenVMS systems out there with 10 million users, and a comparable number of Digital Unix systems and users. These numbers are still growing at 5 percent annually for OpenVMS and around 80 percent for Digital Unix.
A large mainframe is certainly overkill for most organizations and is too expensive for all but the largest and most critical applications. PCs of any sort are often too small and unreliable for other corporate applications. Digital provided solutions for customers who found themselves with problems in this middle ground. These solutions originally included PDP, then VAX, and now Alpha computers. These computers ran obscure operating systems such as RSX or RSTS and then the powerful, easy-to-manage VMS (later OpenVMS) and the ever-popular Unix. Digital might not be the industry leader it once was, but, as indicated, a large number of customers still rely on their products. As a computer professional, it's reasonable to expect to find yourself working at such a site, especially because these sites are so numerous and often have the experience and background to know that they need professionally developed and integrated systems.
Digital has embraced the new world of computers, including Windows NT. Often, customer sites will have Digital computers at many sites for all the traditional reasons, and will also have Windows NT-based computers. Rather than spend money on large computers for both applications and file and print sharing, why not just have one set of computers (VAXs or Alphas), run the applications on them, and use PATHWORKS for file and print sharing? Or, if the demand for file and print sharing is large enough and/or critical enough, why not use a large, powerful, and highly reliable system based on OpenVMS or Unix?
Digital sites can also use Windows NT for users' workstations. In that case, they might need those PCs to use printers or disks attached to the VAX or Alpha systems, or they might want to connect to those systems to run applications.
PATHWORKS is actually a family of products. Not only are there solutions for connecting "Wintel" PCs to OpenVMS or Unix minicomputers but also to connect Macintoshes and Novell-oriented PCs. This chapter concentrates on the PATHWORKS for OpenVMS solution, with the appropriate clients. The chapter focuses enough on the other PATHWORKS products enough, however, to allow you to work with them. The PATHWORKS for Unix product is much like the PATHWORKS for OpenVMS product.
For more details on the full PATHWORKS family of products, including some technical details, you can refer to
http://www.digital.com/pathworks/
PATHWORKS provides a variety of general solutions:
The version of PATHWORKS being used can be important to the work you do with it. This section details the version issues, and they are summarized in Table 50.1. Currently, Digital only supports versions 5 and 6 of PATHWORKS for OpenVMS or PATHWORKS for Unix. Version 4 might be installed in some shops, just because users haven't had the time or money to upgrade. Because version 4 is not supported, however, this can be a dangerous situation (if these shops run into a problem, they might not be able to get it fixed). Version 4 is similar to LAN Manager (in one of its earliest forms), and thus does not include domain integration and so on. Version 5 is fairly similar to Windows NT, as explained later. Version 6 is very similar to Windows NT, but at the time of this writing, it's only available on the server side on Digital Unix computers. It will be available for OpenVMS by the time you read this, but many shops will migrate to it slowly, given the seriousness with which they take their PATHWORKS environments (they'll want to do their own testing and planning to ensure a smooth transition).
On the client side, version 4 is also not supported, but some sites will be using it for the same reasons they might use version 4 on the servers or because version 4 has some features they might like (such as the capability to connect to a server by using several different accounts). To aid in the transition to version 5 on the server side, Digital has a "compatibility mode" for the version 5 server, which enables most of the version 4 clients to continue to connect to a version 5 server without any changes. Version 5 clients are easier to set up than version 4 clients and can be much more dynamic (components can be loaded and unloaded, as required). Version 6 clients are very similar to version 5 clients. Associated with version 5 and especially version 6 clients are PATHWORKS for Windows 95 and PATHWORKS for Windows for Workgroup clients. These take advantage of virtual devices (VxDs) in Windows and offer additional features that make them strongly preferred for these types of clients.
For Windows NT, Digital has had a v4.1b product for several years, but this has only provided DECnet and licensing support. Its other features are very limited. Recently Digital made PATHWORKS 32 available for Windows NT and Windows 95 clients. This is strongly recommended for Windows NT clients and has some improvements for Windows 95 clients. For most reasonably sophisticated sites, PCs will be a mix of Windows NT and Windows 95, so having one good solution for both is attractive.
The other PATHWORKS products have evolved much more slowly and are only important in relation to the restricted functionality and environments they serve (Mac and NetWare clients). Therefore, any version should work, but the latest versions are still strongly recommended for support reasons and to ensure that all subtle features are also fully functional.
| Version | Client Features | Server Features | Notes |
| 4.0 | Digital innovations | Similar to NT, but no domains | Legacy sites, no licenses |
| 5.0 | Dynamically configurable | Can be a BDC to NT PDC | Only 256 groups |
| 6.0 | Better still | Can be a PDC | No restrictions |
| 4.1b | NT only, DECnet only | n/a | Very basic |
| 95 | Sophisticated client | n/a | Also for WFW |
| 32 | Full NT and Win95 client | n/a | Available since Spring 1997 |
It's easy to think of PATHWORKS as just another file and print serving solution. This part of PATHWORKS is important, but sites that have Digital-based systems also need to use the other PATHWORKS features, so it's important that you understand the possibilities.
On Digital Unix or OpenVMS servers, the customer can have incredible amounts of valuable data that must be accessible by their PC users. There's no reason that the printers the UNIX or OpenVMS users use cannot also be used by the PC users. However, security is still important, and it would certainly complicate things to have a separate security system for the Windows NT-based servers and the PATHWORKS-based servers. In addition, users of the OpenVMS or Unix systems should be able to use PC users' printers, just as they can use their own. PATHWORKS makes this possible.
File and Print Sharing. Disks and printers that PATHWORKS shares can be accessed by any PC that has either the TCP/IP, AppleTalk, or DECnet network protocol installed. With the use of the PATHWORKS for NetWare or PATHWORKS for Macintosh product, computers with IPX/SPX or AppleTalk can also connect to these shares. End users see these shares in the same way that they would be seen if they were offered by a Windows NT server. The shares are offered by tools that are very similar to those offered by LAN Manager, including NET commands.
NOTE: DECnet is similar to TCP/IP in that it works well in both LAN and WAN environments. DECnet is used by a variety of applications to provide file transfer, terminal emulation, and client/server connectivity. Most customers are switching to the now-preferred TCP/IP, however, because it has all of these facilities and the associated protocols that make the Internet and intranets possible.
Any of the modern Microsoft operating systems (post-DOS and Windows 3.1) include sufficient networking software to access a PATHWORKS server. However, unless you use concurrent use, server-side licenses, the operating systems have to obtain PATHWORKS client licenses before they can access the server. This is done with some simple software that must be installed on each client. This is discussed in detail in the following section, "Setting Up and Configuring PATHWORKS Servers."
Files that are put on shares by a PC can be accessed from a user logged on to the OpenVMS or Digital Unix server directly, as long as the security allows it. The OpenVMS or UNIX file systems are different from FAT and NTFS, however, so some special accommodations have to be made. The most dramatic issue is that FAT and NTFS files can use some characters in their filenames that OpenVMS does not allow. PATHWORKS handles this by translating these to special character sequences. When the file is shown to the PC user, the sequences are translated back to the normal characters, and thus the PC user is not aware of this issue. A user logged directly into the system, however, sees the special sequences in the character name. The file is still useful to such a user, but he has to be aware of this to be confident that he's found the right file. For full details, see the release notes that come with PATHWORKS (when you're logged on to an OpenVMS system, this is at SYS$HELP:PWRKV*.RELEASE_NOTES, where * is the version of PATHWORKS the customer is using).
Other issues include the fact that filenames can be no more than 70 characters (including the extension) and shouldn't be put in directory trees greater than seven levels deep (because the OpenVMS backup facility has troubles with directory trees greater than seven levels deep, and thus the files might not get backed up). See the release notes for details on these, as well.
Domain Security. One of the most important features of PATHWORKS for Windows NT specialists who are trying to integrate the two environments is the capability of PATHWORKS servers to participate as domain controllers in a Windows NT domain. By using this feature, the shares offered from a PATHWORKS server can be set up with the same characteristics that might be used on a Windows NT share, and they can be offered to the same users and groups. From the users' points of view, they can continue to have a single logon. After they're on the domain, they don't have to care whether they're connecting to a PATHWORKS or Windows NT server--they can access whatever files and printers they're authorized for.
There are a couple of significant issues that must be noted in relation to using PATHWORKS domain controllers with Windows NT domain controllers. Both of these restrictions are limited with version 6, but, as discussed earlier, most sites are still using version 5. The primary restriction is that PATHWORKS servers participating in a domain must always be backup domain controllers. They cannot be the primary domain controller or even be promoted to the primary domain controller, unless the Windows NT controllers are being permanently removed. The reason for this restriction is that PATHWORKS is based upon LAN Manager 2.3, whereas Windows NT is more like LAN Manager 3.0 (if there were such a product)--it has some significant additions. Therefore, PATHWORKS domain controllers can work with the Windows NT PDC and can validate any kind of user logon. If a PATHWORKS domain controller were the PDC, however, it would not have all the information about users and so on that a Windows NT domain controller might require or be able to use.
The other significant restriction with PATHWORKS v5 domain controllers is that they can only work with 256 domain groups. If more than 256 domain groups are added, from either a Windows NT or PATHWORKS domain controller, the PATHWORKS domain controllers lose synchronization with the Windows NT-based domain. They are unable to be brought back into synchronization without reducing the number of groups below 256 and resetting much of the PATHWORKS security. A related restriction is that PATHWORKS v5 domain controllers don't distinguish between global and local groups.
NOTE: Losing synchronization means that the PATHWORKS servers cannot communicate with the Windows NT PDC, and thus their list of valid users and their passwords become out of date. Changes to passwords are not reflected at the PATHWORKS servers, and thus the users are prompted for their old domain password. Changes to the domain security or share security are impossible from the PATHWORKS servers. New users are not recognized at all.
In addition to domain security, PATHWORKS offers share-level security (passwords for each share), much like Windows for Workgroups and Windows 95 can do. PATHWORKS must also consider how to deal with users who might access files while logged on interactively to the minicomputer. For this reason, it will normally put security on files both for PATHWORKS and the operating system (what it calls "host" security). This imposes some overhead and some complications in terms of resolving security issues, so if you are never going to have anyone other than administrators log directly on to the server, it is best to set up the PATHWORKS server to use "LanMan" security only. If you will have people logging on to the server and you want to protect their files from being accessed by the PC users, then you will need at least "LanMan + Creator" security. This means that you should use LanMan security only if the file is created from a PC (via PATHWORKS), but otherwise put host security on the file, as well.
Using Printers Attached to PCs from Minicomputers. These days it's very common to include a network card in printers so they can be used from any computer, even over the WAN. Failing this, attaching printers directly to a print server of some sort will usually serve much the same purpose. There might be times, however, when the cost of a printer network card or even a simple print server is too expensive. This is especially true of printers in isolated locations (such as a user's home). By using this feature of PATHWORKS 32, you can print to such printers from a UNIX or OpenVMS machine, using the user's PC as the print server. This can be especially useful for users who use minicomputer-based applications from isolated sites, yet still need printouts.
From their PCs, your users want to connect to OpenVMS or UNIX computers to access files or printers or to run applications (including management tools). PATHWORKS makes this easy.
File and Print Sharing. For Windows for Workgroups, Windows 95, Windows NT, Macintosh, or NetWare computers, networking is built in and therefore accessing a file and print server of the appropriate type is not difficult. However, DOS and Windows 3.x never included such functionality, and so vendors had to provide solutions. Digital provides PATHWORKS components for such machines. These will load up a device driver for a networking card, a redirector to handle I/O on a network connection, TSRs to support the protocols that work with the two, and a "scheduler" to provide a crude kind of multitasking. Using NDIS-compliant components, multiple protocols can be supported concurrently and the less popular networking cards can be used. Fortunately, we rarely have to deal with such details any more.
Beyond the simple mechanics of connecting to file and print shares, Digital also insists on enforcing licensing. Unfortunately, this became necessary with PATHWORKS version 5, because users of previous versions had not been honorable about paying for all the clients they were using. Digital provides several options to suit the needs of its different customers. Concurrent-use licensing can be loaded on the server so that the server can be used by as many clients as have been paid for. If additional clients try to connect, they're rejected. The difficulty with this kind of licensing is that all users are treated equally (there's no provision for the "importance" of particular users within the organization), and users who were working successfully yesterday might not be able to connect today.
Alternatively, there are per-seat licenses, but then licenses must be loaded onto each client. This is automatic, but requires some setup by a technical specialist. The per-seat licenses can either enable just file and print access, just client/server access, or both. Client/server access is important for people using client/server applications, including PATHWORKS management tools.
In addition to regular file shares, PATHWORKS also makes it possible to offer "volumes" as shares. These volumes are a single file from the OpenVMS or UNIX point of view, and can be managed more easily as such. From the client point of view, however, they look identical to regular file shares or disks. The other advantage of volumes is that they can be significantly faster to access, if that's a significant concern.
DECnet and LAT. DECnet and LAT are networking protocols that have been used in the DEC world for many years. DECnet is an efficient, robust protocol that serves both LAN and WAN environments. It was developed long before TCP/IP was mature and has been successfully used in many sites for all kinds of purposes for many years. TCP/IP has now matured nicely, however, and has been used by developers of applications that provide Internet and intranet facilities (such as the World Wide Web or newsgroups). Therefore, TCP/IP is preferred these days, but transitioning to it is a big job for any large organization. Besides, TCP/IP solutions for OpenVMS have been expensive until recently.
LAT is a protocol intended to make terminals easy to use. Because OpenVMS and Digital UNIX minicomputers were traditionally used by logging on to the computer itself, terminals (with no significant intelligence of their own) were important. They were used to enter the commands and data needed by the applications, and the results were displayed on them. The connection was made with a cable connected directly to the minicomputer. Later, it was possible to have two cables, one to each of two computers, and to use a hot key to switch between them.
As it became more common to have multiple minicomputers, a means was required to make it easy to attach the terminal to any computer. Networking cables were used for this, with terminals attached to "terminal servers" and terminal servers and computers connected to the network. LAT was the protocol that took care of the mechanics of connecting to the computers. In addition, LAT features advertising of computers, so that users could use a simple command to list all the computers and what applications they made available. The user could then choose to connect to any computer they were authorized for. The same LAT "service" can even be offered by multiple minicomputers, and thus the user can connect to the service on the computer that is the least loaded, providing an effective means of fault tolerance and load balancing. Up to four connections could be made at a time, and the user could connect to different computers at one time. LAT has always been essentially free, but it only works on LANs (unless it is "tunneled" over the WAN).
For those sites that have not converted away from DECnet, having DECnet on the client PCs enables them to connect to the minicomputers. For any of your customer sites that have Digital minicomputers, LAT can still be used and is still attractive for terminal emulation.
Terminal Emulation. Despite the advances that came with the evolution of minicomputers, terminals, and the protocols that connected them (such as LAT), when PCs came along, they soon proved to be a requirement for everyone, even those with a terminal. Having two devices on users' desktops was not very practical, so programs were developed to run on the PC and let the PC pretend to be a terminal. These are called terminal emulators, such as that shown in Figure 50.1. Various third parties make a good living by producing sophisticated terminal emulators, but PATHWORKS includes a terminal emulator that is quite functional for most users.
This is the PATHWORKS 32 PowerTerm 525 terminal emulator.
The trickiest issue with terminal emulators is usually keyboards. It used to be quite normal for each vendor to do its own thing in terms of keyboards, and this was true of Digital as much as anyone else. Applications developed for Digital minicomputers often depended on special keys that could be found on keyboards that came with all terminals intended to be used with Digital computers. When PCs came along, they also had a special keyboard. It was similar to Digital's, but it didn't include many important keys. Digital addressed this by providing the LK250, which did provide these keys and yet still worked quite readily with PC applications. This was later replaced with the LK450. Digital found, however, that maintaining keyboard drivers for all the different operating systems, and all their versions, for these special keyboards was quite a job in itself. Therefore, Digital now encourages all OpenVMS and Digital UNIX application developers to develop for standard PC keyboards. LK450-style keyboards and their drivers are becoming increasingly difficult to acquire, although this still can be done.
The terminal emulators available for Digital environments all support regular serial cables and the LAT protocol (as discussed previously), but they will also work with Telnet (the TCP/IP terminal emulation protocol) and CTERM (DECnet's equivalent).
X-Terminal Emulation When UNIX computers were first developed, terminals were simple, character-based devices. As graphical user environments were developed, it became obvious that UNIX should also have a GUI, preferably one that was based on industry-wide standards. Thus, X Windows was born, and Digital soon used it on both OpenVMS and its UNIX implementations. X Windows could be used on the minicomputer itself, if it had the appropriate resources, or dedicated devices could be used, called X Windows Terminals or simply X Terminals. As with regular terminals, emulators were created so that PCs could be used as X Terminals. PATHWORKS includes such an emulator, as shown in Figure 50.2.
This is the PATHWORKS 32 eXcursion X-Terminal emulator.
NOTE: One important point to remember about X Windows is that the device that displays the GUI is called a "server" (in the sense that it serves the I/O to the user). The components that sit on the minicomputer are called the "client."
Setting up a PATHWORKS server can be very simple, very complex, or somewhere in-between, depending on the environment. This section attempts to address the significant issues, but for a full treatment of this subject, you must refer to the manuals and/or attend an appropriate course. There's also a section later in this chapter, "Integrating PATHWORKS with Windows NT," which details issues related to that particularly important topic. Finally, the troubleshooting section at the end of the chapter deals with some common problems related to PATHWORKS and Windows NT.
To keep this chapter a reasonable size, we'll presume that you've got the Alpha (or VAX) computer physically set up, complete with peripherals and networking, and that OpenVMS is installed. If not, then that's a complicated enough subject that you might want to call an expert, such as Digital. You'll need the PATHWORKS server media kit and enough client licenses. If all else fails, you can order that from Digital at 1-800-Digital, but it's a good idea to check out their Web site (http://www.digital.com) for part numbers and related details. Be sure to get the latest version with the latest bug fixes for that version (ECOs, in Digital parlance). Note that both the base release and the ECOs are included in the single set of savesets--you don't have to install the software and also the ECOs.
At this point, you need to log directly on to the system and access the PATHWORKS media. You should do this with the SYSTEM account. The password for this and how to access the media are details that the person who set up the system can tell you. Finally, you're ready to start the installation by executing @SYS$UPDATE:VMSINSTAL. You'll receive a couple of cautionary prompts and then be asked for the location of the distribution volumes where the media is located (on a CD in a particular directory, on a tape drive, or on a disk somewhere). The product is something like PWRKV50D_E03 (the PATHWORKS saveset name except for the last 3 characters). Finally, it's probably a good idea to print the release notes if you're new to PATHWORKS or just to be sure that this particular version doesn't have issues that relate to this environment. The release notes are large, so it might be better to just extract them from the first saveset!
NOTE: For those of you new to OpenVMS, a saveset is like a ZIP file, in that it's one file containing many files, possibly in a directory tree. For most OpenVMS installations, the files that will be installed come in multiple savesets, all with the same name but ending in extensions such as .A, .B, .C, and so on. .A is the first and contains the release notes, among other things.
If you continue, at this point you'll be prompted as to whether it's the LAN Manager or NetWare server you want (we'll presume the former), whether you want to run an Installation Verification Procedure (IVP) afterward (always a good idea), whether you want to purge the replaced files (I always do), and what group number you want for the default accounts (the default is fine, unless you're told otherwise). From there, the installation should proceed uneventfully. As the instructions for the next stages are given, read them carefully and follow them.
Among the important post-installation steps is ADMIN /CONFIG, which enables you to specify how many clients this server needs to support and how they will be supported. This information is used to determine what system resources are required, and then appropriate system parameters are adjusted accordingly, if you want. The server can even be automatically restarted, if you like.
Another post-installation step is to set up licenses for the clients. This is done in two parts. First, clients must be registered with OpenVMS itself. This is done by executing @SYS$UPDATE:VMSLICENSE and then taking menu option 1. It prompts for details about the licenses (which you must have in paper form first), and then loads them, if you like. The next step is to make them available to the PATHWORKS server-side licensing components. This is done by executing MCR PWRK$LICENSE_MANAGER, as shown in Figure 50.3. This is an awkward quasi-GUI utility that takes some getting used to. The main thing is to enter the Products dialog box (by pressing Enter while the Products menu item is selected), selecting any current product licenses, and then selecting the New command. The product is whatever is indicated on the paper licenses, and the version is something like 6.0. You then select OK and press Enter to back out of the dialog boxes, and select Exit to get out of the utility. The migration through the dialog boxes can be inconsistent and counter-intuitive, but with judicious use of the arrow, tab, and Enter keys, you'll figure it out.
The final step you (or the system administrator) should do is to include the PATHWORKS startup procedure in the system startup procedure. This is done by including @SYS$STARTUP:PWRK$STARTUP in the SYS$MANAGER:SYSTARTUP_VMS.COM procedure, after DECnet and/or TCP/IP are started. There are other locations this might be placed, but in a basic installation, this is a reasonable location for the PATHWORKS startup. If you really want to be cautious, you can also include the PATHWORKS shutdown procedure in the system shutdown procedure. This is done by placing @SYS$STARTUP:PWRK$SHUTDOWN in SYS$MANAGER:SYSHUTDWN.COM.
With the server set up, you and the users now need clients to access the resources they provide. This might require no more than ensuring that the appropriate licenses are available. Many users will also want terminal emulation, however, and some will require additional network protocols.
This is the server-side license management utility.
In all cases, you need a copy of the software. If you don't already have this, Digital sells software as part of a "media and documentation kit." If you check out Digital's Web site (http://www.digital.com), you should be able to find the appropriate part numbers. You can call 1-800-Digital and order the appropriate pieces--they'll also help you with part numbers and technical details if need be, but it's often easier to check the Web site.
Windows 95 is becoming the most popular PC operating system, so Digital has provided some good solutions for it. The best solution is PATHWORKS 32, but for those sites that haven't sprung for this, you might still be using PATHWORKS for Windows 95. Some customers do not need any of the special PATHWORKS client features, so they might just require that the machines have the licenses that PATHWORKS servers expect.
Licensing Only. This only requires a simple client component. If you happen to have a Web browsing machine that has a DNS name registered, then you can browse over to http://www.services.digital.com and get FPA013.*.
PATHWORKS for Windows 95. This has been the most popular PATHWORKS solution for Windows 95 for the last year or so. To install it, simply run the SETUP.EXE program that is at the top of the CD (or wherever the software has been copied). This invokes a wizard-like series of dialog boxes, the first of which is shown in Figure 50.4.
A couple of pointers about setting up Windows 95 clients:
This is PATHWORKS for Windows 95 Setup Wizard.
When you complete the setup, you'll find a few new entries in the Network Control Panel and a new Program group named PATHWORKS. Among the items, there will be DECnet File Transfer Utility, if you've chosen to install DECnet. This is much like FTP. The event logger will be discussed in the troubleshooting section later in this chapter.
PATHWORKS 32. The PATHWORKS 32 installation is much like the PATHWORKS for Windows 95 installation. The process is started as soon as the CD is inserted or by running AUTOPLAY.EXE off the top directory of the CD (or wherever the software has been copied). PATHWORKS 32 also has a setup wizard, shown in Figure 50.5, but in its case you have a separate option for a better terminal emulator (PowerTerm 525) and a new option for X Terminal emulation (eXcursion). The older VT320 terminal emulator is available via the Network Connectivity option. You'll also find options to enable remote access and print services when you install Network Connectivity. Remote access enables a home computer or laptop to boot normally, dial in to a network, and then get a license to enable PATHWORKS server access. Printing Services enable the use of printers attached to the PC from minicomputers.
Digital has long recognized the importance of Windows NT, and this is reflected in its strategic directions. Digital took quite a while, however, to produce a good PATHWORKS solution for Windows NT. For some time, there was only PATHWORKS for Windows NT v4.1b, but this really only provided DECnet support and some crude terminal emulation and other utilities. PATHWORKS 32 is a far superior solution for Windows NT, so we won't discuss v4.1b any further. For those who only want file and print connectivity to a PATHWORKS server, the licensing-only option might be sufficient.
Licensing Only. This only requires a simple client component. If you happen to have a Web browsing machine that has a DNS name registered, then you can browse over to http://www.services.digital.com and get FPA013.*.
Tis is the PATHWORKS 32 Setup Wizard.
PATHWORKS 32. The PATHWORKS 32 setup on Windows NT is identical to that on Windows 95.
When you complete the setup, you'll find a few new entries in the Network Control Panel (see Figure 50.6) and a new Program group named PATHWORKS, much as with the Windows 95 setup.
This is Windows NT Network Control Panel after adding PATHWORKS 32.
Just as legacy applications and mainframe computers will be with us for a long time to come, DOS, Windows 3.x, and Windows for Workgroups clients will be around for quite a while. Such clients can be set up as PATHWORKS clients, as well. This can be a very complex topic, so we'll just cover the basics here.
The legacy PATHWORKS clients can actually be set up to enable multiple configurations (trading functionality against memory requirements) and those configurations can even be based on centrally located, shared configurations that can be changed anywhere. This can be very attractive but requires a good understanding of PATHWORKS client options, for which a course or extensive reading of the manuals is appropriate.
For basic usage, it's sufficient for you to run the PWSETUP.EXE program from the PATHWORKS client CD's PCAPP directory (or wherever else the software has been placed). This program steps you through the various setup options, providing you an opportunity to set up the client PC based on various templates, which you can vary from if required. Each template includes one or more protocols, plus additional features to provide terminal emulation, administrative tools, tutorials, and so on. Some adjustments can be made for memory management and other issues, although the defaults should be fine.
After all this work to set up PATHWORKS servers and clients, you'll be glad to know that using the clients is very straightforward. The users browse to PATHWORKS servers by using Network Neighborhood, map drives, set up printers, use files, and so forth very much as they would with a Windows NT server.
The terminal emulator is readily accessed via the Start, Programs, PATHWORKS (or PATHWORKS 32 or PATHWORKS PowerTerm 525) program groups just like any other program. In the terminal emulator, there are options dialog boxes much like any other Windows program, and the settings are relatively intuitive.
PATHWORKS servers can work independently of Windows NT servers, but it's much easier for the users if they work together. This is readily accomplished by merging the security databases of both environments and moving the PATHWORKS servers into the Windows NT domain. There might be times when the PATHWORKS servers need to be manually synchronized with the Windows NT servers, but that's fairly straightforward once you understand it.
It would be easy enough to create a computer account in the domain for the PATHWORKS server and then change its domain to be the same one that the Windows NT servers are using (by editing the LANMAN.INI file, for instance). However, if the PATHWORKS server has been used by itself (as they usually are), then some effort should be made to preserve the PATHWORKS security database. This way you don't have to go to the effort of manually creating accounts for users who haven't already got domain accounts. Considering that the number of such users can be substantial (hundreds or thousands), Digital has provided a procedure for just this purpose:
2. Log on to the PATHWORKS server with a privileged account.
3. Invoke the merge procedure by executing the following:
$ @SYS$UPDATE:PWRK$UPGRADE
4. You're asked if you're upgrading a server in a currently existing domain. This ambiguous question is really asking if the PATHWORKS server will be upgraded so that it will join a currently existing domain. Respond yes, and specify the common protocol, domain, PDC, and administrator account details. This enables the upgrade procedure to get information about the domain's current security database.
5. Choose Additional Upgrade Utilities, UAS Merge, Standalone UAS Merge Report. This produces a report of users and groups in the PATHWORKS security database and the domain database. You should comment out (with an exclamation mark) any accounts or groups that you don't want added, and uncomment any that you do.
6. Choose Standalone UAS Merge. This processes the report file and actually adds the accounts, groups, and finally the server to the domain.
When moving a PATHWORKS server into the Windows NT domain, its security databases should automatically be fully synchronized with the domain security database. If this doesn't occur, or if the synchronization is lost (circumstances in which synchronization might be lost are discussed in the troubleshooting section later in this chapter), the following steps should bring it back into sync:
$ NET ACCOUNTS /ROLE:STANDALONE
2. Ensure you're not working on the domain security database by entering:
$ NET LOGOFF
3. Ensure the local copy of the guest account has no password by entering:
$ NET USER GUEST "" /PASSWORDREQ:NO
4. Set the computer account password to any random value by entering:
$ NET USER servername "whatever"
5. Set the computer account password in the domain to the same random value by using User Manager for Domains on another computer.
6. Ensure the password on the local copy of the Admin account is set to the proper value by entering:
$ NET USER ADMIN "whatever_it_should_be"
7. Get privileges on the domain by entering:
$ NET LOGON ADMIN "whatever_it_should_be"
This also confirms that the password is what you think it is.
8. Get rid of the old error messages by entering:
$ NET ERROR /DELETE
9. Rejoin the domain by entering:
$ NET ACCOUNTS /ROLE:MEMBER
10. Verify everything has succeeded by entering:
$ NET ERROR /REVERSE /COUNT:5
You should repeat this for up to half an hour to be sure that everything is okay.
Chances are that you'll want to at least see Windows NT Servers from PATHWORKS Servers when you pull up a list of domain servers (in the ADMIN /PATHWORKS utility, for instance). For this to occur, you must set the Windows NT servers to make browser broadcasts to LAN Manager 2.x clients. This is readily done by changing the appropriate property in the Server Service in the Windows NT Network Control Panel.
PATHWORKS has a variety of tools that enable it to be managed very effectively. Most of these are based on PATHWORKS' Lan Manager heritage, but there are also adaptations for Digital's OpenVMS and UNIX operating systems. PATHWORKS servers can be managed from the host system, from PCs in a client/server fashion, or via traditional terminals or X Terminals. Most of these tools can also be used with Windows NT servers, at least to the extent of changing some domain account details, such as passwords.
One important consideration to keep in mind is the role of the PATHWORKS server. As with Windows NT Servers, PATHWORKS servers can be PDCs or BDCs, member servers, or standalone servers (in their own domain or a workgroup). If the server is in standalone mode, then any account or security changes are based on the PATHWORKS security database local to that particular machine.
ADMIN /PATHWORKS is the primary tool used for PATHWORKS server management. It supports all important functions and is somewhat GUI-oriented, so it's easy to find a way to do all functions. ADMIN /PATHWORKS is run on an OpenVMS system itself, so you need to establish a terminal session on the server and enter ADMIN /PATHWORKS at the command prompt (usually a $ sign). (Alternatively, it might be available as a menu command, if the system administrator has set up a menu system.)
You're then prompted for a username, password, and domain name. The username should be for an administrator account on the domain that the server is on. However, if you're logged on to a sufficiently privileged host account (such as System), you have complete privileges even if you don't have the correct password or account name.
As shown in Figure 50.7, once you are logged on properly, ADMIN /PATHWORKS displays an interface that's very windows-oriented and that can be traversed through a windows-based menu system. There are hot keys that can be used to expedite the use of dialog boxes. If the terminal emulation session where ADMIN /PATHWORKS is entered is run on an X Terminal or via an X Terminal emulator, the mouse can be used with the interface.
ADMIN /PATHWORKS has menu options for sharing resources, setting security on those shares, checking the server's state, manipulating account and group details, and setting server configuration details.
This is the ADMIN /PATHWORKS utility's main window.
NOTE: While using the ADMIN/PATHWORKS utility, you should be able to select from all the available PATHWORKS and Windows NT servers. If you select a Windows NT server, the functions you can perform are limited. These include domain-oriented functions, managing shares, and checking server statistics.
ADMIN /PATHWORKS is a good interface for casual PATHWORKS server management, but for quick tasks, big jobs, or routine tasks, it's entirely inappropriate. For these kinds of tasks it's much more appropriate to use NET commands from the host prompt (or in a batch job), such as the commonly used ones listed in Table 50.2. NET commands are available on other Microsoft networking clients, such as Windows for Workgroups, Windows 95, and Windows NT. On them, the most common NET command is NET USE. However, there are other commands (especially on Window NT or Lan Manager servers) to add or adjust user accounts or groups, create shares, adjust their security, and so on. On PATHWORKS servers, it's even possible to change the role of the server at will.
PATHWORKS and Windows NT have a lot in common when it comes to NET commands. Often the exact same syntax can be used on both, so batch jobs developed on one can be used on the other. Also, if both are in the same domain, then the domain-oriented commands done on either one will affect both. Keep in mind that if you execute the script on the OpenVMS or UNIX PATHWORKS server, you might not yet be logged on to the domain. Therefore, a NET LOGON command might be required at the beginning of a batch job. When run from an NT server, the batch job probably won't require a NET LOGON command, because you'll have logged on to the domain as you logged on to the server.
| Command | Use |
| NET USER | See details about any user account, or adjust it |
| NET GROUP | See details about any group, or adjust it |
| NET ACCESS | Check the security on a "resource," or to change it |
| NET SHARE | See the shares offered, or to add or change them |
| NET SESSION | See who is accessing the server, or to disconnect them |
| NET START | See which services are functioning |
| NET ACCOUNTS | See the state of the server |
| NET ACCOUNTS /ROLE: | Change the mode of the server (PDC, BDC, member, standalone) |
| NET ERROR /REVERSE /COUNT:10 | See the 10 most recent PATHWORKS errors |
| NET LOGON | Log on to the domain with appropriate privileges |
| NET LOGOFF | Disconnect from the domain (and thus work locally) |
| NET HELP | Get help with the NET commands |
PATHWORKS comes with a few additional tools that will probably prove useful sooner or later. Several of these are provided when you execute @SYS$MANAGER:PWRK$DEFINE_COMMANDS.COM when logged on to a PATHWORKS server. You can type that procedure to get the full list of commands available, but the most useful is PWSHOW, which shows all (and only) the PATHWORKS processes (much the same as services in the Windows NT world). A couple more useful commands are PWSTOP and PWSTART, to shut down the PATHWORKS server processes and then restart them.
TIP: If you like the NET commands but want to do them from a PATHWORKS v5 or v6 client, try entering NET ADMIN \\servername /COMMAND.
Finally, under the \LMDOS\NETPROG directory of your v5 client CD you'll find a program named NETADMIN. This is very much like the ADMIN /PATHWORKS utility, except that it's a true Microsoft Windows program that works on a client/server basis to manage PATHWORKS servers.
Now that you've got the PATHWORKS server working successfully and everything functioning properly, there's always the remote possibility that users won't be entirely satisfied with performance (well, maybe the possibilities aren't that remote). The area of performance is a complex set of issues and problems, but by now you should be familiar with what the possibilities are. The important question for the moment is: How can you tell how the PATHWORKS server is performing?
There are three possibilities for monitoring a PATHWORKS server. The simplest is to use the host performance monitoring tools, such as MONITOR /SYSTEM or MONITOR /CLUSTER. The only problem with this approach is that you're looking at the whole system, so you might have difficulty finding details related to PATHWORKS. The most useful tool is a Windows-based monitor tool named CMT.EXE. It can be found on the PWUTIL share of any PATHWORKS server. It works well with any Windows clients based on PATHWORKS v5 or v6 clients, but it can be tricky to get running on Windows 95 or Windows NT clients. Once set up, it's fairly intuitive to use.
The final option for monitoring a PATHWORKS server is PWMON, another facility provided by PWRK$DEFINE_COMMANDS (discussed in the previous section). You have to switch the terminal (or terminal emulator) to 132-character width first. Then you can see a variety of low-level details about the PATHWORKS server. The only problem is that many of these values are not very intuitive, so you have to figure out this utility for yourself. Besides the default, PWMON supports /ACTIVE, /CLIENTS, /COUNTERS, /EXCLUDE:, /OVER, /PASS, /QUEUE, /RESET, /TIME, and /VALUES switches.
Windows NT management utilities can be used with PATHWORKS servers, to some degree. For instance, Server Manager or Domain Monitor can see all the PATHWORKS servers but are unable to make changes to them. Print shares can be used and managed as usual, but new ones cannot be created. User Manager for Domains sees all the domain accounts and groups, of course, but there are a few minor fields that PATHWORKS uses for special purposes that User Manager for Domains doesn't handle properly. In particular, it can't see the Comment, User Comment, Logon Domain, User Storage Limit, and VMS Hostname fields; however, most likely these are not important in your environment.
Another way that Windows NT machines can be used to manage PATHWORKS servers is by changing directory or file security on any shares. This can be done by using Explorer on Windows NT to find the files or directories and then changing the security as is done for any local files or directories. Event Viewer can be used with PATHWORKS servers, but only to see the System or Security (audit) logs, and the details provided are minimal. Performance Monitor doesn't work with PATHWORKS servers at all.
Looking at things from the other direction (PATHWORKS tools managing NT Servers), some cross-management can be done that way, as well. For instance, ADMIN /PATHWORKS can be used to offer new shares on an NT Server. PATHWORKS version 5 also doesn't distinguish between local and global groups, so ADMIN /PATHWORKS cannot see local groups at all, although the NET commands can see them but cannot create a new local group.
As with any system, PATHWORKS occasionally has problems, and as the expert on site, you'll be expected to solve them, even if your primary expertise is Windows NT.
As discussed earlier, it's important that the PATHWORKS domain security keeps synchronized with the Windows NT security. They get out of sync if the PATHWORKS server is off the network for too long, if inappropriate changes are made on the PATHWORKS server or on the domain, or if a mysterious problem occurs.
Synchronization problems will become evident when users log on to the domain successfully but then try to access a PATHWORKS server that is out of sync. The user is prompted for a password, which of course shouldn't happen (domains are supposed to be a single point for logon). Often, entering the previous value of the user's password on the domain gives them access to the resource. The other common symptom for domain synchronization problems is to do a NET ERROR /REVERSE /COUNT:5 and notice recent errors to the effect that the primary domain controller could not be accessed or errors that say LMU6086: Failed to synchronize/update local UAS database.
Sometimes doing a NET ACCOUNTS /SYNC is sufficient to fix the problem. If the symptoms persist after 20 minutes, however, refer to the suggestions in the section "Integrating PATHWORKS with Windows NT," earlier in this chapter.
When Digital first introduced license enforcement to the world of PATHWORKS, customers were assured that licensing would be a transparent, behind-the-scenes function that would require no effort. Despite these good intentions, license problems are very common, and so it's good to be familiar with the symptoms and how the problems can be solved.
License problems become evident when a user logs on to the domain and can access network facilities without difficulties, but when he goes to access a file or print share on a PATHWORKS server, he gets an error message back to the effect that "the network has responded incorrectly." Under some circumstances, the error message isn't so clear, but trying to view the shares on the server will eventually produce this or a similar message. Viewing shares can take many forms, such as NET VIEW Error! Reference source not found., NET USE Error! Reference source not found., DIR Error! Reference source not found., or the equivalent operations via the Network Neighborhood. If none of these commands works, despite the fact that everything else works, and especially if the indicated error message is displayed, then you probably have a licensing problem. Correcting licensing problems can be done by various means:
For the more serious server-side problems, anything is possible, and therefore solutions can be varied. Symptoms of server-side problems are basically that most or all users cannot access the shares offered from a PATHWORKS server, or the server is actually crashing. Sometimes they relate to security issues or file corruption, but generally those problems are due to operator error or problems beyond the scope of PATHWORKS itself.
Generally speaking, shutting down the PATHWORKS processes and then starting them up again will solve many mysterious, non-recurring problems. This can be done with @SYS$STARTUP:PWRK$SHUTDOWN and @SYS$STARTUP:PWRK$STARTUP, respectively. In desperate cases, restarting the system as a whole (@SYS$SYSTEM:SHUTDOWN) has been known to help. Adjusting system parameters is sometimes advisable, and ADMIN /CONFIGURE does this if needed.
Otherwise, troubleshooting server-side problems requires detailed knowledge of PATHWORKS. Checking for the state of the PATHWORKS processes with PWSHOW is certainly advisable. Also checking the PATHWORKS logs sometimes helps. This can be done by finding them with DIR PWRK$LOGS or by doing a SET DEFAULT PWRK$LANMAN and then a DIR [LOGS]. These files can then be typed out with TYPE /PAGE PWRK$LOGS:PWRK$CONFIG_INFO_servername.LOG, for instance.
NET ERROR /REVERSE /COUNT:10 can also be useful, as discussed earlier. Similarly, NET AUDIT might help, and ADMIN /ANALYZE includes switches to make it more useful. These include: /AFTER, /BEFORE, /CLASS, /COUNT, /EXCLUDE, /NODE (in other words, server), /OUTPUT, /PID (in other words, process ID), and /PURGE, where /CLASS can have values of: ACCOUNTING, AUDIT, ERROR, TRACE, and WARNING.
Client problems can take many forms, but because they effect only one user and can be fixed by reinstallation, they generally aren't as serious as server-side problems.
One handy tool available to diagnose client problems is the PATHWORKS Event Log Viewer. This little program is started when a client PC first starts up, and then when it's invoked again, it displays a long list of events that have occurred to PATHWORKS. Most of these are informational messages, but any error messages can provide strong clues for diagnosing problems. You can find the Event Log Viewer in the PATHWORKS (or PATHWORK32) program group.
If the usual diagnosis and troubleshooting techniques fail to solve a client-side problem, a simple solution is to remove the PATHWORKS components and reinstall them. This might not be an elegant solution, but it often works and is certainly more expedient than trying to trace the problem down to the offending DLL or registry entry. This can be done by removing the appropriate entries from the Network Control Panel, but sometimes it helps to remove the C:\PW (or C:\PW32) directory tree, or even to erase all the DEC*.* files in the C:\Windows (or C:\WINNT) directory tree.
The future of PATHWORKS is a subject of much speculation. In the short term, we know that Digital will improve version 6 on the server side and PATHWORKS 32 on the client side, with some support and minor improvement of the other versions. It seems likely that Digital will continue to support its customers with PATHWORKS solutions as long as customers require them. It wouldn't be surprising, however, to see Digital subcontract the actual work to a third party someday.
Digital will likely push PATHWORKS as an integration and migration tool, enabling minicomputer-based solutions to work with Microsoft-oriented sites (which seem to be most sites these days). As long as customers have data, applications, and resources on minicomputers that they want their users to be able to access, PATHWORKS will be available to make that access easier and affordable.
Inevitably, PATHWORKS will become more PC-oriented, in the sense of becoming more client/server and GUI-based, using NT tools as much as possible and relying on PC standards, such as keyboards, wherever possible.
© Copyright, Macmillan Computer Publishing. All rights reserved.