Some of the main topics in this chapter are
The computer world has produced many operating systems, but the successful ones can generally be divided into four broad categories: IBM operating systems, UNIX, personal computer operating systems, and OpenVMS. OpenVMS has been a big part of the history of Digital Equipment Corporation, once the world's second largest computer company. Today, OpenVMS runs on 450,000 systems, with 10 million users, which grew by five percent in 1996. Digital now strongly embraces UNIX and Windows NT solutions, as well, but with a huge installed base such as this, OpenVMS was 40 percent of Digital's market share in 1996. Even as a Windows NT professional, it's probable that you'll work at sites with OpenVMS. Understanding how OpenVMS relates to Windows NT will prepare you well for such assignments.
OpenVMS and Windows NT actually share a lot of common ground. David Cutler was the primary architect and project leader for both operating systems during their most important formative periods. Seemingly as a result of this common heritage, both Windows NT and OpenVMS have many architectural similarities, as you'll see later in this chapter, enabling programmers from either system to become familiar very quickly with the other. In addition, both are central products to two companies in one of the strongest corporate alliances in the computer industry, the Microsoft-Digital Alliance.
Digital had some difficult transition years as the personal computer and UNIX revolutionized the computer industry. Digital emerged from this period with various resolutions, among them the strong support of PCs, the embracing of Windows NT and UNIX, and a broadening of its focus to include services.
Digital is now one of the largest vendors of personal computers, and its PATHWORKS products, discussed in detail in Chapter 50, provide strong interoperability between Digital minicomputers and all varieties of personal computers.
In its embrace of Windows NT, Digital has committed to thoroughly supporting Windows NT in all ways, including:
Digital has worked with Microsoft in the past to extend Windows NT in terms of Plug and Play and cluster support. With the next generation of Windows NT, Alpha-based systems will be the first to support 64-bit memory addressing for Windows NT.
At the service level, Digital provides some of the industry's best programs for helping customers migrate to Windows NT, to maintain computers using Windows NT, and to support users using Windows NT.
OpenVMS computers are often relatively large, expensive systems, providing production services to many users. As such, they are usually managed by trained, seasoned professionals. If you happen to be called to work in a small shop or if you have access to an OpenVMS computer intended for test purposes, however, then you might have to get into the system and work on it yourself.
Accessing OpenVMS systems is almost always done by using a terminal or a terminal emulation program on a PC. This enables you to log on to the OpenVMS system and access the command prompt, where most operations are initiated. You will need a username and password to log on to the system. These usernames and passwords are not necessarily coordinated with domain accounts, so you'll have to get a username and password from the person who set up the system or managed it prior to you. The most privileged OpenVMS account is the SYSTEM account, and it's usually recommended that you use this account if you're going to install software. Once logged on, the operating system prompt is a dollar sign ($). The person who set up the system might have modified this by prefixing it with the computer name.
Once logged on, you'll want to know more about your system. You can find out a lot by using the SHOW command, with various parameters. SHOW SYSTEM shows you all the currently running processes (and the computer name and how long it has been up); SHOW USER shows you all the users currently logged on interactively; and SHOW DEVICE shows you all the devices (and SHOW DEVICE D shows you all the disks). OpenVMS has a complete and easy-to-use help system, invoked by entering the command HELP. It explains all commands and options. By entering HELP SHOW, you can find out all the options for the SHOW command. As a final note: Since version 6 of OpenVMS, most commands that display output enable a /PAGE parameter so that you can keep the display from scrolling away too quickly.
Now that you're oriented, you want to move around the disks to find files. Disks are dealt with individually, and have directory trees, rather like the one shown, as follows. Directories are usually referred to with square brackets ([ and ]) and separated with periods. The top level directory on any disk is [000000], but if you don't need to go there in particular, then it's sufficient to refer to the directories contained in that directory. Given the following sample directory tree, it's reasonable to refer to the PTHOMSEN directory in the DATA directory as [DATA.PTHOMSEN]. [000000.DATA.PTHOMSEN] is exactly equivalent, but is more verbose than is required.
[000000]
[DATA]
[PTHOMSEN]
[JTHOMSEN]
[DOCUMENTS]
[KTHOMSEN]
[PROCEDURES]
From the SHOW DEVICE D command you might see a display in which several disks are listed, such as:
Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt $0$DIA0: Online 0 Disk1 2307740 1 1 $1$DIA0: Online 0 Disk2 506040 1 1 $1$DIA1: Mounted 0 Disk3 926576 1 1
If you don't know what's on each disk, you can use the SET DEFAULT command to set the current default disk and directory and then use the DIR command to list the contents of each directory. SET DEFAULT is much like entering a drive letter with the colon at a Windows NT command prompt and then entering the CD command. Thus, you might enter SET DEFAULT $0$DIA0:[000000]. This gets you to the top-level directory of the first disk. When you use DIR, any entries that end with .DIR are subdirectories, and you can enter SET DEFAULT [directory_name] to move down to that level. The default disk does not change in this case--just the directory.
After you move beyond the top level of the disk, however, you have to enter either the full directory path or the directory name prefixed with a period to make it a relative move. For example, if you've previously entered SET DEFAULT [DATA], you can enter SET DEFAULT [DATA.JTHOMSEN], or SET DEFAULT [.JTHOMSEN]. If you want to move back up the directory tree, you can enter the full directory path again or enter SET DEFAULT [-] to move up one level (SET DEFAULT [--] to move up two levels).
As you find files, notice that they all have extensions, much like Windows NT. There are .EXE and .DAT files. However, command procedures, the OpenVMS equivalent to .BAT files, are .COM files, which are simple text files. Another thing to note about OpenVMS files is that they have a semicolon and a number appended to them. This is a version number. Files that are changed have new copies created with a version number that's one higher than the previous version. OpenVMS software always refers to the file with the highest version number. That way, if you find that a file is changed incorrectly, you can simply delete the one with the highest version number and revert to the original.
As you've probably found with other systems, moving files around from disk to disk can cause many problems and yet is required on occasion due to lack of disk space, failed hardware, and so on. The software was set up with the expectation that files would be found at certain locations, and now that the files are moved, the software won't be able to find the files and won't operate correctly.
OpenVMS deals with this problem by providing logicals. Software is defined to use logicals when looking for files (and for other purposes). Thus, if files are moved from one disk to another, the logicals need only be redefined to point to the new location(s), and the software will be able to find them. For the operating system itself, there are a variety of logicals to point to its files. Most start with SYS and can be shown with SHOW LOGICAL SYS*. Using such logicals also helps you find all the important files on an OpenVMS system, no matter who set it up and no matter what approach the person took. The most important system logicals are shown in Table 49.1.
| Logical | Directory Contents |
| SYS$SYSTEM | Operating system main files |
| SYS$MANAGER | Management files, including the initial system startup files |
| SYS$STARTUP | Startup files for all the products that sit on the operating system |
| SYS$HELP | Release notes and other files |
| SYS$UPDATE | Installation, upgrade, and often configuration files |
When installing software on an OpenVMS system, it's best to follow the provided documentation exactly. Digital produces complete installation manuals for all its software, and most third parties follow that example.
OpenVMS provides various utilities to accomplish particular functions. Each has its own help facility, so as soon as you're using the utility, you can learn more about it by typing the command HELP. To create user accounts or to modify them, you use a program named AUTHORIZE. It can be invoked with the command MCR AUTHORIZE. If a logical to the account database file (SYS$SYSTEM:SYSUAF.DAT) has not been defined, then you are told that a security database can't be found and asked whether you would like to create one. In that case, you should say No and then enter the command SET DEFAULT SYS$SYSTEM prior to entering MCR AUTHORIZE. Once in the AUTHORIZE utility, you can SHOW accounts, ADD them, MODIFY them, REMOVE them, and so forth. You can set privilege levels, resource quotas, logon constraints, passwords, and various other details.
Another useful utility is MONITOR, which shows you how the system is performing at the moment. It provides a dynamically updated character display that can list a wide variety of details about the OpenVMS system. The help system tells you about a wide variety of MONITOR options, but the most useful is usually MONITOR SYSTEM, as shown in Figure 49.1. This shows you how much CPU activity is occurring, how the memory is being used, how much disk and I/O activity is occurring, and so on. It certainly helps to have a strong knowledge about how OpenVMS systems behave, but many of the values displayed should be fairly intuitive. Other useful MONITOR options are MONITOR DISK and MONITOR STATES.
A typical MONITOR SYSTEM display--note that all the major performance parameters are included.
If you have reason to think that performance could be improved by tuning the system (or if a program requires more resources), then resource allocation can be controlled by a utility SYSGEN, invoked with the command SYSGEN. Occasionally it might be appropriate to use SYSGEN to make system changes, but mostly it's a good tool to see what the current resource allocations are.
For changes to resource allocations, it's more appropriate to use the AUTOGEN facility. AUTOGEN uses SYSGEN to make the changes but makes the changes while considering related changes that should also be made. AUTOGEN takes into account the historical requirements of the system, the requirements of other software (which you specify in the SYS$SYSTEM:MODPARAMS.DAT file), and various rules of thumb. You can run AUTOGEN as simply @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT, in which it will consider all inputs, make the appropriate changes, and reboot the system to make the changes take effect.
Of course, you might not want to reboot the system right away (for instance, if users are logged on), so you might want to substitute SETPARAMS for the REBOOT parameter, and reboot later by using the command @SYS$SYSTEM:SHUTDOWN. Effectively tuning an OpenVMS system beyond the automatic tuning of AUTOGEN requires considerable knowledge about OpenVMS. If you don't have that level of knowledge already, find someone who does.
NOTE: If you shut down an OpenVMS system and don't answer the shutdown prompt to restart with a Yes (or if it's starting after a power failure), then the system might stop at a boot prompt. This is three chevrons (>>>) and usually all you have to do is enter B. The actual options at this prompt might vary, depending on which model of Alpha or VAX you have and how it's configured. Usually, you can enter HELP at the prompt; otherwise, there should be a manual for your model that explains the options.
One of the most important parts of any operating system is the backup facility. Planning for problems is prudent. OpenVMS provides a BACKUP command that is easy to use and comes with a complete description in the HELP facility. For basic operation, it's only necessary to enter:
The ellipsis indicates that all directories below the directory specified should be included. The destination can be another directory (or directory tree) and/or another disk, or can be a tape drive, which can be MUA0:, MTA0:, or something similar. Tapes might need to be initialized with the INITIALIZE command. You might also want to consider the possible variations on the BACKUP command that enable full backups, incremental backups (changes only), and so forth. When backing up to tape, and sometimes to disk, you can save all the files in one large file, called a saveset. Savesets make it easy to manipulate a backup as a whole.
As with its other subsystems, OpenVMS provides a variety of options for security. One of the most fundamental options is file ownership and protection. If you use the DIRECTORY /SECURITY command on any file, you get results similar to these:
The middle parameter is the file ownership. The first part of the ownership is the group that the owner is part of, and the second part is the member number. The actual numbers used are arbitrary, with no values having any particular meaning other than group numbers below 10 (which have extra privileges). Member numbers should be unique within a group, but they don't have to be.
The third parameter is the protection that is enforced on various users. The first part of the protection applies to users with system privileges, the second part to the owner of the file, the third part to the group that owner is in, and the fourth part to the world. R means read, W means write, E means execute, and D means delete. In the example given, the system can read, write, execute, or delete the file; the owner can execute or delete the file; anyone in the owner's group (1) can execute the file; and everyone (the world) cannot do anything with the file.
The ownership value for any user account can be determined or changed by using the AUTHORIZE utility. The ownership for a file can be changed with SET FILE /OWNER = [x,y] filename. The protection for a file can be changed with SET SECURITY /PROTECTION=(level:code) filename where level is S for system, O for owner, G for group, or W for world; and code is any combination of R, W, E, and D.
NOTE: When viewing ownership, it's common to see nonnumeric values. These are identifiers, set up using AUTHORIZE, that give descriptive names to the numbers. They equate to numbers, but because the actual numeric values are arbitrary, it's unimportant what the numbers are. The important thing is that they either match between the account and the file or they don't. If the group identifier matches but not the member identifier, then group access is given; if both match, then owner access is given; and if neither matches, then world access is given (unless the user has system privileges, in which case system access is given).
The next level of OpenVMS security uses Access Control Lists, similar to ACLs within Windows NT. When using the DIRECTORY /SECURITY command, you might see a list of Access Control Entries, specifying different levels of access for different users (or groups). ACLs are powerful in that they can be as extensive and varied as required. ACLs for a file can be changed by entering EDIT /ACL filename.
One area in which OpenVMS excels compared with Windows NT is the area of queues. OpenVMS associates printers with print queues, and users submit print jobs to print queues for printing. When submitting print jobs, a wide variety of options can be specified, including when the print job should be printed.
Queues are also used in a similar manner for batch jobs. Batch jobs are submitted to batch queues for execution behind the scenes. Various options can be specified as to when the job should be executed, under which account, and so forth. Windows NT has a similar facility in the Scheduler server and the AT command, but there's only one "queue" per machine, and the variety of options that can be specified when submitting the job are limited compared to OpenVMS.
OpenVMS queues can be displayed by entering SHOW QUEUE, or SHOW QUEUE /BATCH for batch queues and SHOW QUEUE /DEVICE for print queues. To see jobs submitted by someone other than yourself, you must include /ALL in the SHOW QUEUE command. Individual queues can be stopped with STOP /QUEUE queuename and started with START /QUEUE queuename. Characteristics on queues can be shown by adding /FULL to the SHOW QUEUE command, and they can be changed with the SET QUEUE command. Characteristics on submitted print or batch jobs can be shown with SHOW ENTRY /FULL entry_number (from the SHOW QUEUE command).
Print jobs are submitted from the command line by entering PRINT /QUEUE=queuename filename. Batch jobs are submitted with SUBMIT /QUEUE=queuename command_procedure_file_name.COM.
As with any other computer system, OpenVMS can fail to function correctly. The usual troubleshooting techniques apply, but a few details might be particularly useful.
Many parts of the system output error messages to the operator log, SYS$MANAGER:OPERATOR.LOG. You might want to enter this command to see the latest entries:
TYPE SYS$MANAGER:OPERATOR.LOG /TAIL:n_lines /PAGE
To check for disk problems, you can use ANALYZE /DISK disk_name. For security problems, you can use ANALYZE /AUDIT to check the security audit log. For detailed hardware errors, you can use ANALYZE /ERROR_LOG.
Otherwise, using the commands and utilities already described enables you to investigate various aspects of the system to find things that aren't quite right and possibly put them back to normal.
OpenVMS and Windows NT are different in many ways, not the least of which is that OpenVMS is ultimately command-line and logon-oriented, whereas Windows NT is GUI- and client/server-oriented. Windows NT is usually used on smaller machines and in less critical environments and lacks a powerful queuing system (for batch and print jobs).
OpenVMS and Windows NT also have many similarities, however, which soon become apparent to any specialist moving from one environment to the other. It's not obvious whether this is because Microsoft and Digital are close allies or because some of the engineers are the same or because operating system principles are universal. Nonetheless, the similarities are striking.
Some similarities are obvious to the user of either system. Both have disk device names that end in colons, and disks are always distinguished at the operating system level (as opposed to UNIX, where it's not obvious to the user which disk he's using). They both have hierarchical directories . Commands are fairly English-like. One has environment variables, and the other has symbols, both serving much the same purpose. Both have text-oriented batch file capabilities (unlike the Mac OS). Files tend to have three-letter extensions to identify their use. User accounts are the basis of security; accounts can be in groups; and ACLs are available to control access.
Most similarities are obvious at the level of the system programmer. However, senior technical specialists usually want to understand an operating system at the same level as the system programmer because that often helps them to understand the operating system better and be better able to tune it, troubleshoot it, and so on.
At the lowest system levels, OpenVMS and Windows NT are similar in that they both have threads, mutexes, events (or event flags), mailslots, processes, child (or sub) processes, memory pages, page faults, priorities, priority boosts, quantum, real-time mode, kernel mode, an idle state, a boundary between system and user memory, virtual memory, stacks, thread local storage, images, and software interrupts.
Mind you, at the system level there are still significant differences, with Windows NT having most of the advantages; but then again, Windows NT is the newer system and is obviously going to build on the heritage of previous operating systems. OpenVMS has system services, rather than APIs, isn't as reliant on handles as Windows NT is, and has resource quotas. Windows NT has fibers, memory mapped files, critical sections, messages, heaps, modules, graphical devices, windows, and UNICODE.
OpenVMS and Windows NT can interoperate at various levels. At a basic level, you'll want to transfer files, potentially in either direction. Sometimes these will be routine, well-anticipated transfers. Occasionally, they'll be random events when you least expect them. Depending on the environment, you might or might not have a choice of networking protocols. Similar to this functionality, you'll certainly want to print, and it might make sense to share the same printers between your OpenVMS and Windows NT servers.
At a higher level, you might want to have OpenVMS and Windows NT systems coordinate their e-mail or passwords. (Talk to your users, and you'll soon want the latter option.) At a still higher level, you might want applications to have integrated components across platforms; this is discussed in the later section, "OpenVMS and Windows NT Integration."
As a rule, it's generally much better to copy files from a Windows NT machine to an OpenVMS machine. This is simply because the Windows NT machine is GUI-based, and you probably work on Windows NT much more often. To copy files from Windows NT to OpenVMS, you can either set up things so that you can map a disk share from the OpenVMS machine, or you can set up a connection to the OpenVMS machine and then copy the files. The advantage of the former technique is that the share looks like just another disk, and therefore all the usual file copying techniques can be used. The advantage of the latter technique is that it's easy to provide and generally less expensive. For share-like copying, there are two options, PATHWORKS and NFS. For connection-style copying, there are also two options, FTP and NFT.
PATHWORKS. PATHWORKS is Digital's solution for connecting OpenVMS to the rest of the world. It's a family of products that include solutions that can sit on OpenVMS, Windows NT, and many other platforms. By using those solutions, users, techies, and programmers can get a large variety of computers to work together at whatever level is required.
Chapter 50, "PATHWORKS," discusses the PATHWORKS options in detail, but for now the important thing to know is that PATHWORKS enables OpenVMS computers to offer directories (and printers) in much the same way that a Windows NT or Windows 95 machine would. Thus, Windows NT, Windows 95, and other Microsoft networking-compliant machines can connect to those shares and transfer files to and from the OpenVMS machine with ease.
PATHWORKS is a great solution for those sites at which OpenVMS machines are already installed and it's reasonable to expect that users might want to regularly use the disks or printers connected to those machines. It's also a good solution where the workload is expected to be huge and the customer isn't certain that a Windows NT solution is large enough or reliable enough. When the amount of file transfers to the OpenVMS machine is not expected to be large, it might be more appropriate to use a more awkward, but much less expensive, solution, as follows.
NFS. NFS (Network File Service) is a UNIX equivalent to Windows NT or PATHWORKS file shares. When everything is configured properly, the user will use it in the same way as a Windows NT or PATHWORKS share. To get NFS working, however, the OpenVMS machine must have TCP/IP installed with the NFS components enabled, and the client Windows NT machine must also have NFS components installed. In both cases, these two tasks can be a little tricky and expensive (at least the first time), and this configuration only provides file-share facilities. However, if you need TCP/IP on the OpenVMS system anyway and if you can find a reasonably priced NFS client, then this option might be reasonable. Otherwise, the PATHWORKS solution is preferred because it offers many more features.
FTP. These days, FTP (File Transfer Protocol) is one of the most universally available network-based file copying solutions. As long as you have TCP/IP on both the Windows NT and OpenVMS computers, you're all set to go. Windows NT comes with a simple FTP program, or you can use any of the shareware or commercial alternatives.
As always with TCP/IP, you have to have the address of the OpenVMS computer. This should have been manually defined in the WINS or DNS databases when the OpenVMS computer was being set up, but failing that, you can put it in your local hosts file or simply use the numeric TCP/IP address.
NFT. NFT (Network File Transfer) is very much like FTP, except that it uses DECnet as its networking protocol, and thus DECnet must be installed on both the OpenVMS and Windows NT machines. DECnet comes with OpenVMS; so as long as DECnet has been enabled, NFT will be available on that side. For Windows NT, DECnet is only available as one of the PATHWORKS client solutions, which are discussed in detail in Chapter 50. When DECnet is available on both sides, it's a simple matter to invoke NFT from the PATHWORKS Programs group. As shown in Figure 49.2, NFT looks and works much like any of the GUI-oriented shareware FTP programs. A connection is established with the appropriate computer, files are selected on the Windows NT computer, a destination is selected on the OpenVMS computer, and the transfer is initiated. And like FTP, if the files aren't simple text files, be sure to specify that they're binary.
To connect to the OpenVMS machine, you need to know its DECnet address. Generally, this is referred to with a name, called a nodename, which can be up to six characters long. The nodename has an equivalent numeric DECnet address, which is what's actually used by DECnet when routing network packets. You should be able to obtain the nodename for your OpenVMS system from a technical specialist or user familiar with the system. Otherwise, if you log onto the OpenVMS machine, you can determine the name with a variety of commands, including SHOW LOGICAL SYS$NODE, SHOW SYSTEM (the nodename is on the second line), or MCR NCP SHOW EXECUTOR.
NFT in operation--notice the similarities with most GUI FTP programs.
NOTE: DECnet addresses are two-part addresses, each of the parts separated by a period and in the range of 1 to 1024. The first part is the area, and the second part is the node number. Generally, each site has an area, and thus you can readily have at least 1,000 sites with 1,000 nodes. There are solutions for larger sites and larger organizations, but discussion of that topic is beyond the scope of this book. The important thing is that each computer must have a DECnet address that has the right area value for that site and a node number that is unique at that site. DECnet addresses look like 1.32, 315.8, or 48.685 and have equivalent nodenames such as GEORGE, SLEEPY, or TR612.
DECnet does not have a service such as DNS or WINS to translate computer names to network addresses. Therefore, it's normal to define useful DECnet addresses on your DECnet clients, much as you might record TCP/IP addresses in hosts files. You can use the DECnet address itself wherever you would use a nodename, but generally nodenames are preferable because they are easier to remember. On Windows NT, DECnet nodenames are recorded by using the Network Control Panel. The Properties sheet of the DECnet protocol includes a tab for computer names, as shown in Figure 49.3. The addresses for a nodename can also be copied from another DECnet computer that already has the node defined, as long as you know the DECnet address of that other computer or have its nodename already defined.
Defining a DECnet nodename on Windows NT.
Occasionally, you might be logged on to an OpenVMS system and need to get files off a Windows NT Workstation or Server. It might not be convenient to go to the Windows NT machine and "push" the files to the OpenVMS machine and therefore might be more appropriate to "pull" the files. You have a couple of options in this situation, depending on the circumstances. If you have TCP/IP on both sides and the NT box has the FTP service installed, then you can simply use FTP. If you have DECnet on both sides and have the NT box configured correctly, then you can use the File Access Listener.
FTP. FTP from an OpenVMS computer to a Windows NT computer is much like FTP in any other circumstance. However, the OpenVMS computer won't have the benefit of your WINS system, so the Windows NT computer's TCP/IP address will have to be defined in DNS or the hosts file of the OpenVMS computer. If the OpenVMS computer is using Digital's TCP/IP solution, then you can define the hosts entry by logging on to the OpenVMS machine and entering UCX SET HOST name /ADDRESS=address. Another important requirement for using FTP under these circumstances is that the FTP service must be installed and started on the Windows NT server.
File Access Listener (FAL). FAL is a standard service of DECnet and is initiated when the listening components of DECnet hear a request to the current node for files. If the security checks pass, then FAL is called on to provide the actual data.
To configure FAL, the Windows NT computer must be configured as a PATHWORKS client with DECnet. PATHWORKS 32 is the recommended PATHWORKS client for Windows NT. Chapter 50 provides further details about PATHWORKS. To configure FAL, you must go to a command prompt and execute the NCP (Network Control Program) program. There you must enter DEFINE OBJECT FAL NUMBER 17 FILE C:\PW32\FAL32.EXE. Then you must provide access to it by entering DEFINE ACCESS USER username PASSWORD password type, where type is NONE, READ, WRITE, or ALL. With this done, a user at an OpenVMS command prompt can then enter the command DIR nodename"username password":: and get a list of available files. If the user is interested in a particular directory, she can enter DIR nodename"username password"::[directory_name], and if the user wants a file, she can enter COPY nodename"username password"::[directory_name]filename. In all these cases, nodename is the name you gave the computer when installing DECnet (as part of the PATHWORKS 32 installation), and username and password are the same ones you used when entering the DEFINE ACCESS command.
NOTE: A discussion of DECnet addresses and nodenames is provided in the "NFT" section, earlier in this chapter.
The most significant restriction with FAL between OpenVMS and Windows NT machines is that the transfer might not completely preserve the integrity of binary files. To work around this problem, OpenVMS has a utility called Exchange, which copies files but ensures that all binary information is retained. In our case, we would enter:
EXCHANGE /NETWORK /TRANSFER_MODE=BLOCK nodename"username password"::[directory_name]filename
At most OpenVMS sites, the OpenVMS machines are large and have been around for many years. As such, a variety of printers are attached to them by several possible means. The Windows NT computers (even servers) are likely smaller and less numerous. The Windows NT servers may also not be set up for robust, production-quality service. Therefore, it's reasonable to think that Windows NT machines, even servers, should direct their print jobs to printers connected to OpenVMS computers.
Print jobs can be sent to OpenVMS print queues via two means. The first is PATHWORKS, which can offer print queues as print shares. In this way, the OpenVMS printers can be used in much the same way as they would if they were connected to another Windows NT Server. Again, PATHWORKS is discussed in detail in Chapter 50; however, it's important to note that this solution can use NetBEUI, TCP/IP, or DECnet protocols, in any combination, and security can be used to control who prints to or operates each printer.
The other alternative for printing from OpenVMS is to use TCP/IP's LPD daemon and LPR client.
In some situations, OpenVMS users might want to use printers attached to Windows NT printers. This will certainly be the case in which the Windows NT servers are the primary servers and the OpenVMS machines are few in number or lack capacity to print serve. This might also occur if Windows NT servers are used in smaller, isolated sites, whereas the main applications are provided by large OpenVMS servers in central sites.
In any case, printing from OpenVMS servers to Windows NT servers can be accomplished in two ways. The first is the TCP/IP LPD/LPR solution. The other possibility is that PATHWORKS 32 (discussed in detail in Chapter 50, "PATHWORKS") can be used on the Windows NT servers.
For large Microsoft environments, Microsoft's Systems Management Server (SMS) is a popular and effective option for managing systems. Normally, this includes Windows NT workstations and servers, Windows and Windows 95 clients, Macintoshes, and even DOS computers. However, Computer Associates has a set of significant extensions to SMS, called AssetWorks, that extend the SMS functionality to OpenVMS (as well as UNIX) machines. Digital originally developed AssetWorks but it was sold to Computer Associates so that Digital could concentrate on its core businesses.
By using AssetWorks, details about the OpenVMS machines can be collected. This information can be useful for troubleshooting, preventative maintenance, and management reports. AssetWorks can also automatically upgrade OpenVMS software. For more information on these and other AssetWorks features, refer to the Web site of one of the AssetWorks distributors, Computing Edge, at http://www.computingedge.com.
Digital also has a product, OpenVMS Management Tools for Windows NT, that does what its name says (how refreshing!). It provides user, printer, backup, performance, event, and asset management components. See Digital's Web site, http://www. digital.com, for more details.
Digital has had an enterprise scale e-mail solution for its OpenVMS customers for many years. That solution is ALL-IN-1. ALL-IN-1 has proven reliable, full-featured, and scalable, and therefore most OpenVMS sites have it. As you introduce Windows NT into your organization, you might be inclined to use Microsoft Exchange. Digital recognizes that this is appropriate for many customers and, therefore, provides several solutions.
Over the last few years, Digital has had a client/server interface to ALL-IN-1, called Teamlinks. With version 3.0 of Teamlinks, which will be available by the time you read this, Teamlinks can interface to Exchange servers as easily as it can to ALL-IN-1 servers. This enables you to have both kinds of servers available to your users, without forcing your users to use two kinds of clients (which can be confusing to some users). It also makes it easier for your users to move messages between the two systems. The only problem with this solution is that Teamlinks does not have all the advanced functionality that Microsoft Outlook has. On the other hand, Teamlinks has strong conversion options, so it can work with messages and files from many different sources.
Digital's ALL-IN-1 server-side components are being migrated to its close cousin, Digital's Message Server. With version 3.0 of this product available in early 1998, Outlook will be able to access it much the same way it would an Exchange server.
Digital, Microsoft, and third parties are also working on ALL-IN-1 to Exchange conversion utilities so that you can migrate all e-mail to Exchange. This can be important because many users have information of great value to them in their old messages. This is a huge job, however, in that an ALL-IN-1 system can easily have millions of messages, which can be in various formats. The state of the conversion utilities is evolving rapidly, so check with the vendors or trade magazines for current details.
As long as you have both OpenVMS and Windows NT systems around, one issue that will keep coming up is passwords. Users are often easily confused--as you've probably observed over the years--about when to use which password. Some users also have trouble remembering their current passwords. The simplest way to deal with this problem is to have just one password value and to keep this value the same for all security databases.
PATHWORKS helps with this problem as well, by providing password synchronization. By using this option, which is the default, when a domain password changes, PATHWORKS changes the appropriate OpenVMS password to the same value. That way, the user can use the Windows 95 Password control panel, for instance, to change not only the domain and Windows 95 passwords but also the OpenVMS password. All will have the same value, even though the user only makes one change. When the user next goes to log on interactively to the OpenVMS system, the password is the new value.
When it comes to running Windows NT and OpenVMS systems, you might not care too much about programming issues. However, there will be times when troubleshooting tricky problems is much easier if you know how things are accomplished. In addition, you might require tools to make your job easier, tools that you can't find. With a little programming skill and some knowledge of the possibilities, you might be able to produce those tools yourself. Programming-level solutions (middleware, for instance), might also make it possible to more tightly integrate Windows NT and OpenVMS.
Digital has an entire product program, named Affinity, that addresses the issue of OpenVMS and Windows NT integration. Affinity is an important component of Digital's strategy to address the realities of a world dominated by Windows NT. Affinity helps to migrate to or from Windows NT and enables solutions to be built that include Windows NT, OpenVMS, and various kinds of clients. Several of the Affinity components were developed by Digital and sold to third parties for further development and support (Digital still markets them). Others have always been either third-party or Digital solutions. Among Affinity's middleware solutions are:
Digital has information available about the Affinity program at its Web site, http://www.digital.com.
Despite the strengths of OpenVMS, many customers find Windows NT to be an even better long-term solution. Certainly Windows NT is necessary for many of the latest and greatest solutions, and having a mix of both platforms does complicate life. Therefore, customers might want to consider migrating from OpenVMS to Windows NT.
Migrating from OpenVMS to Windows NT involves various technical issues, including providing sufficient resources, networking changes, moving applications, moving shared printers and data, and moving users and related security. Other important issues involved in such a project are planning, training, communications, testing, and so forth, but we will leave such topics to other books.
Ideally, you'll have both OpenVMS and Windows NT servers available concurrently throughout the migration. That way, you don't have to move everything and everyone all at once. It also leaves you the opportunity to fall back to the old solution if the new Windows NT solution doesn't work satisfactorily.
Gauging capacity can be tricky, considering that Alpha or VAX computers running OpenVMS are dramatically different from Intel computers with Windows NT. Providing a simple equivalence in terms of memory, MIPS, or even disk space might not work out correctly. A further complication is that Alpha computers are RISC machines, meaning that they execute much simpler instructions, but many more of them. Therefore Alphas generally have twice the memory and disk space requirements (for programs) than VAXs do. You should keep this in mind if you are moving both Alphas and VAXs--any rules of thumb that you apply for one kind of machine will not work quite the same for the other.
NOTE: OpenVMS records disk space in terms of blocks, which are 512 bytes each. Therefore, if you need to move a 10,000-block file over, you need 5M of disk space. The easiest way to do this in your head is to multiply by 1,000 and divide by 2. Or change thousands to megs and divide by 2.
Similarly, memory is in pages, which are 512 bytes on VAXs, and 1024 bytes on Alphas.
One possibility to keep in mind during the migration from OpenVMS to Windows NT is that Alphas run either operating system. This might help reduce your migration costs if you own the right models of Alphas with the right options. You might be able to dual boot the Alphas, enabling you to migrate the files from OpenVMS disks to Windows NT disks and then just reboot to see whether or not everything is ready to go. If not, you simply reboot back to OpenVMS. This option also helps to minimize the question of getting the right size of CPU; you aren't trying to find the equivalent size of Intel-based server to replace your Alpha server. The hardware manuals that come with your Alpha should tell you whether or not the dual booting option is possible, and if so, how. Your Alpha salesman can also help you choose models that provide this option.
Generally, you should scale your servers based on how they'll be used. Figure out which OpenVMS applications are going to which Windows NT servers and then gauge the NT servers accordingly. If you have a 300-user, Oracle-based payroll system on the OpenVMS system, work with Oracle to determine what size of Windows NT system running Oracle will serve 300 users. Whether it's more or less memory than the old OpenVMS system is academic. Remember that these days hardware is relatively inexpensive, especially for Windows NT. In fact, that might be one of the reasons you're going that route. Therefore, make a reasonable estimate and then throw in a generous fudge factor.
An important issue to remember when migrating from OpenVMS is that OpenVMS is a mature operating system and has usually been used in an organization for some time. Therefore, OpenVMS rarely crashes, has many features available to maximize reliability, and has generally been managed and operated professionally. The users expect that any system they migrate to will provide at least equivalent service. Therefore, you must insist on providing a system with not only sufficient capacity but also sufficient reliability built in. Many options are available for Windows NT, and each situation requires a different combination of these. The important point is that you must think in those terms. Not only must your solution work well on day one, but it also must run without interruption (other than for scheduled maintenance) for months. There must be sufficient backups and similar options to recover from any fault. This might include arranging with your vendor to be able to obtain a fully equivalent system at short notice.
Networking has been standardized across platforms for quite some time now, so you should have relatively few concerns in relation to networking issues. However, many OpenVMS sites will have used DECnet throughout their computing history. They might see the migration to Windows NT as a good opportunity to eliminate DECnet. This might mean that you have to introduce TCP/IP to the organization and support both protocols for a time.
Introducing TCP/IP can involve establishing an Internet link, training technical staff, training users, establishing subnets, configuring routers, acquiring or installing software, and so forth. All these topics are well covered in other books.
Supporting both TCP/IP and DECnet might complicate things for a while. If you can configure all client machines to have both DECnet and TCP/IP, then you don't have to worry about which OpenVMS and Windows NT machines run which protocol. The users will use whatever is appropriate to connect to whichever machine they need. With Windows 95 and Windows NT workstations, using multiple protocols is not difficult; the users in such a site probably already have DECnet, and TCP/IP is free and easy to install. However, supporting both DECnet and TCP/IP can be relatively tricky on DOS, Windows, or Windows for Workgroups. PATHWORKS does provide such options, but you might not want to invest in such a solution for a short-term migration period.
You could consider synchronizing your changes on the server side with changes on the client side. Therefore, users with DECnet connecting to an OpenVMS machine today could connect to a Windows NT machine with TCP/IP tomorrow. However, this complicates your migration because you're doing two large tasks at once (changing both clients and servers at the same time). And this solution might not be sufficient if only some applications are being moved from the OpenVMS machine to the Windows NT server at any given time. In that case, it's likely that some users will need to access both machines for different applications.
Another alternative is to provide TCP/IP on both your OpenVMS and Windows NT servers and then change all clients to use TCP/IP only. This could be done prior to the migration of applications. However, TCP/IP on OpenVMS can be expensive.
Migrating applications from Windows NT to OpenVMS can be the most complicated aspect of a migration. Not only are there significant technical issues to solve, but even getting fully organized can be a large job. Identifying which applications are running on a large OpenVMS system is not trivial. You must also identify who is using the applications and how they use them. After you identify the applications, you can start to look at how you can provide Windows NT equivalents. You can also look at what resources the applications are using, and thus how much might be required.
Identifying Applications. OpenVMS systems are often very large, with many disks and complex startup procedures. Generally, OpenVMS applications require logicals to be defined, images to be installed, and other tasks to be done to be ready to serve user requests. You need to analyze the startup procedures in detail to try to find where these applications operate. Generally this means reading SYS$MANAGER:SYSTARTUP_VMS.COM (or SYS$MANAGER:SYSTARTUP_V5.COM, if it's still a version 5 machine) to find any clues. Often you need to read .COM files that it invokes or submits, and occasionally .COM or similar files that they in turn invoke. There's also a utility, SYSMAN, which is the preferred (but newer) method of starting applications on startup. SYSMAN is a little more complicated to use than SYSTARTUP files but is more intelligent in dealing with clusters. There's always the possibility that applications don't require special startup procedures, and therefore scanning the disks can also help to find applications. But often applications use multiple directories, or share directories, so where one application stops and another starts might not be clear.
You should also talk to the users to see what applications they use. Unfortunately, this method can be error-prone because users might forget obscure applications that they use only once a year or might think that several applications are actually one and therefore only identify that one. While talking to users, you should review how they use the systems--do they require 24-hour-a-day service, are there peak periods, and so on?
If you're really lucky, there will be technical professionals and system documentation to identify specifically what applications are on the system and how they're set up. This should be an obvious source of such information, but it's not uncommon for senior staff to leave with all this important knowledge or for manuals to be hopelessly out of date.
Finally, you can observe actual usage. You can use SHOW USERS to see which users log on and when. You can use SHOW SYSTEM to see what processes are running and which programs they're executing. You can use MONITOR SYSTEM to see how the workload changes over time.
Finding Equivalent Applications on Windows NT. After you've identified the applications being offered by the OpenVMS machines, you must find equivalent applications for Windows NT. The applications fall into three broad categories: those bought from someone else, those developed internally, and those that are a service of the operating system.
For applications bought from someone else, your best bet is to go back to that source and inquire about their Windows NT plans. Many vendors have been reading the writing on the wall for a few years, and therefore have some Windows NT plans, if at all possible. Failing this, you can look to their competition. The Web is an excellent source of information on alternatives, so you should be able to readily search for them. However, you need to do a thorough analysis and planning of any new solution--migrating applications is serious business.
For internally developed applications, you can go to the developer or his coworkers for a discussion of the possibilities. Because they have the source code and, you hope, documentation, they have a wide variety of options available. However, they might be constrained by lack of manpower, higher priorities, or lack of Windows NT development expertise. Consultants can help with many of these issues but at a price and with the complications that consultants can introduce.
The ease of migrating internally developed applications depends to a large degree on how the application was developed in the first place. Applications written in fairly standard languages, such as C, that don't have many dependencies on the operating system itself can be fairly easy to port. Similarly, applications developed for relational databases or similar environments can be easy to port, as long as the vendor of that database system or environment has a Windows NT solution. Digital's Affinity program, discussed earlier, has features that make it relatively easy for programs to be developed on one platform and moved to the other or to coexist on both.
One significant complication with migrating from OpenVMS to Windows NT can be that OpenVMS has historically been used mostly by logging on to the machine. Windows NT is almost exclusively a client/server environment. Therefore, the interface to the application will likely have to be significantly revamped. This can work to your advantage to some degree in that the application migration can be divided into two parts--the client side and the server side. Thus the new interface can be developed, and the migration to it can occur without making any changes on the server side, other than providing a communications interface. After the client side of the migration is complete, the server side can be migrated, and because the interface doesn't change, the users might not even be aware that it has occurred.
Computer applications that are essentially part of the operating system are usually readily provided by other operating systems. Examples of such applications are print and file sharing, FTP, backups, and gateway service to other environments. Often the user will not even be aware that you've switched servers. For those situations in which equivalent services are unavailable with Windows NT (or an add-on product such as the BackOffice suite), you can try third-party vendors.
In some cases, finding equivalent applications will prove impossible, and for this reason at least one OpenVMS computer might have to be retained. In other cases, the move to Windows NT might be an opportunity to revamp how the end-user of the application is served, so a new application that partially matches the old application but that otherwise is better might be appropriate.
The Migration Process. After you've identified the applications and have come up with alternatives that will work on Windows NT, you must begin the process of actually moving the applications. This is a significant task, and therefore full project management is appropriate. The applications are why your organization invests in computers in the first place, so they have to work properly during and after the move.
Project management is a complex subject, well covered in other books, to which you should refer if need be. However, the important things, in no particular order, are as follows:
When migrating applications, an often effective strategy is to run both systems in parallel. This means having both systems completely ready to go and then running them normally with the same data. This requires duplication of work, in the sense of entering the data twice and reviewing the results twice. In fact, the results have to be reviewed quite thoroughly, and inconsistencies have to be reconciled. The run might even have to be repeated, with appropriate changes. It might be appropriate to hire some temporary staff, for data-entry and similar tasks, and care should be taken to ensure that everything is well organized, so that it's clear what has come from or gone into each system.
Another big job when migrating applications is the migration of existing data. Basic reference data, such as account numbers, customers lists, and so on will have to be moved for obvious reasons. Other data might also have to be moved, such as year-to-date information, patient history, and so on. This might be minimized by timing the migration with the end of the year so that all old information is kept in the old system, and all new information goes into the new system. This might not be possible in all cases, however, which means you might have to hold onto the OpenVMS systems for a while longer.
The actual technical considerations (such as data types and file formats) of moving data can also be significant. The vendor or your own internal development staff should be able to devise solutions. The pervasiveness of networks enables the data to get from one machine to another, but conversion tools usually need to be run on one end or another. Often these can be relatively simple programs written especially for the purpose. OpenVMS comes with some options for data conversion, particularly in the form of the CONVERT and EXCHANGE utilities, and ANALYZE /RMS. These are complex tools, so you should refer to their manuals for details.
Moving Users and Security. After you've dealt with the issues of getting applications and their associated data over to Windows NT, the final significant migration task is migrating security. The users must be able to get access to the system, after all, yet you want to ensure that unauthorized people don't have access.
OpenVMS and Windows NT work significantly differently in terms of user interface and file-level security, so automatically migrating file-level security is probably inappropriate. You usually don't have to worry about users logging onto your Windows NT server, after all.
Making user accounts available on Windows NT can be a big job, especially if you don't already have the users using Windows NT domains. Using PATHWORKS on OpenVMS can help with this problem because PATHWORKS provides a migration tool that will read in all the OpenVMS accounts and create domain accounts for them. Chapter 50, "PATHWORKS," discusses this option in detail.
© Copyright, Macmillan Computer Publishing. All rights reserved.