The VMS-MicroVMS Merge

Why The MICROVMS Product Was Developed And Why It's Being Merged Into VMS

(Taken from: DEC_Professional_V07_N05_198805.pdf, page 76ff)

The introduction of MICROVAX hardware opened new markets for VAX/VMS. A VAX/VMS system cost less than $20,000 and required no more than standard office environmental conditions. It was affordable by single users such as scientists, researchers, lawyers, dentists, accountants, etc. These new users rarely had much computer expertise, never had a computer room with a system manager and operator, and rarely knew anyone experienced in VAX/VMS to whom they could turn for advice.

The VMS Development Group realized that this system would revolutionize the world of VAX/VMS. Until the advent of MICROVAX systems, documentation consisting of 20 three ring binders was considered acceptable; now, the documentation set was larger than the machine itself. Previously, VAX/VMS systems were installed, managed and maintained by system managers and operators; now, the user would have to be his own system manager, operator and maintainer.

VMS Development also faced technical problems caused by the type of peripherals available at the introduction of MICROVAX I. The system disk was too small to hold the VMS system files, let alone provide room for user files. The only distribution medium available was the RX50, a 400-KB floppy disk, a substantial change from the usual VMS distribution medium, consisting of nine-track magtape. With a single disk system configuration, the VMS tailoring procedures (ones that allow movement of some VMS system files off the system disk) broke, as the tailoring design depended on the availability of two disks. Software pricing computed in part according to CPU capacity also was affected, now that a system approximately the speed of a VAX 11/780 cost one-sixth the price. How could the value of software to the user be measured in order to set a price? CPU capacity became only a small part of the measure of the usefulness of a system. Backplane limitations, number of disks, terminals, etc., became important factors in determining the value of a system.

MICROVMS Versus VMS

The engineering effort used to create MICROVMS began by tackling the technical problems one by one. First, what would fit on a 10-MB system disk? If you assumed that the system would be used by a single user or a small project team, only a subset of the large variety of VMS utilities would be needed. What were those utilities? Given the size and cost of the MICROVAX, turnkey systems (systems dedicated to running a single application) probably would be common. Could half the available disk space be left for user files? That seemed a reasonable goal.

The first step was to determine which files would be required for a turnkey system. Because much of the application development for MICROVAX systems would be done on larger VAX systems, programs linked under full VMS had to run under MICROVMS. Therefore, MICROVMS would have to stay synchronized with VMS releases so that inconsistencies between shareable images (i.e., the run-time libraries) wouldn't occur. Thus, VMS maintenance releases would have to be installable on MICROVMS systems.

Other basic system maintenance, such as backups and file and directory manipulation, also would be required. This set of capabilities became the BASE MICROVMS kit. We didn't assume that utilities required by timesharing systems (such as account management, disk quotas, etc.) were necessary. Nor did we assume that every system would be in a network, used for program development or need the VMS HELP library.

After the BASE MICROVMS files were identified, the rest of the VMS files were categorized. Files that were required for DECNET became one class. General-purpose utilities (i.e., MAIL and DIFFERENCES) for use by different types of users were grouped into a second category called COMMON UTILITIES. The help library was subsetted, and its text was rewritten and targeted at users with less computer expertise. It was expected that some systems would want to set up individual user accounts and monitor such things as disk or CPU use. These utilities were classed as the SECURE USER ENVIRONMENT option.

The MICROVAX system also was affordable by small software vendors. The challenge was to fit programming support onto the 10-MB Winchester disk. First, programming was broken into two types: user programming and system programming. System programming requires intimate knowledge of VMS data structures (i.e., drivers or performance monitoring tools) or execution in kernel mode, while user programming uses standard VAX language features and run-time library routines and executes in user mode (application programs).

System programmers were assumed to be VMS experts who would be able to tailor their system disk with ease, because the 10-MB disk couldn't hold both the system programming and user programming files. However, there still was insufficient room on the system disk to hold all the user programming utilities and leave space for user files. To solve this problem, the VMS object library, STARLET.OLB, was stripped of all object modules that are linked into run-time shareable images (*RTL.EXE or *SHR.EXE) for a savings of 2,200 blocks.

Some files, such as MASSBUS or CI drivers (500 blocks), were discarded entirely as they weren't useful on MICROVAX systems. Others that would be used by less than one percent of all customers also were removed, such as BLISS libraries (3,200 blocks) and the User Environmental Test Package (11,000 blocks).

Cookbook-Style Documentation

Meanwhile, the VMS writers were designing a documentation set that would be sufficient for installing and using a turnkey system. Cookbook installation instructions had to be written. System management duties had to be condensed and documented with specific examples tailored to single-user or small time-sharing environments. Pictures of how to open the floppy drive, the way to insert a diskette and warnings not to remove the black jacket from the floppy are examples of documentation created for MICROVMS manuals.

The manuals were structured into two guides, the MICROVMS User's Guide and the MICROVMS Primer. The Primer included information for someone who needed to create files and send mail. The User's Guide included installation, system management and more thorough utility information.

The manuals were made more approachable and friendly by reducing the binder size. Logical names were set up in MICROVMS startup procedures for all peripherals, which were more descriptive than the physical device names (such as $TAPE1: instead of MUA0:). The MICROVMS manuals used these logical names when describing how to use various peripherals for backups, layered product installations, etc.

The MICROVMS User's Pocket Reference contained a summary of all commands for several commonly used utilities as well as DCL. One of the nicest features was that it included keypad layouts for the utilities, at a time when keypads were becoming standard as utility interfaces.

Last, sample FORTRAN programming guides were written as examples of how to simplify language manuals. These were expected to be prototypes for future editions of other VMS language manuals. A MICROVMS Programming Pocket Reference also was produced.

Simplifying System Management

Many system management duties are repetitive, such as incremental backups or adding user accounts. Frequently, VMS system managers write their own DCL command procedures to handle these tasks. Why shouldn't MICROVMS provide such command procedures? Thus, ADDUSER.COM (add a user account with appropriate Access Control List Identifiers and a user disk directory), BACKUSER.COM (backup user files), RESTUSER.COM (restore user files), etc., came into existence. Later, a manager menu command file was added to point to the various system management command procedures, as customers indicated that they didn't realize these procedures existed.

Other system management tasks are performed once by the system manager, often by adding new commands to site-specific procedures. MICROVMS easily could provide sample site-specific files showing the system manager how to set up different options. A site-specific startup file, SYSTARTUP.COM, was created that included commands to do such things as start print or batch queues, provide a system welcome message, start DECNET, install privileged utilities, etc.

These sample commands were commented out, because many systems wouldn't want these features; for example, batch queues. Other template files created were SYLOGIN.COM (systemwide login command file), LOGIN.COM (system manager's login command file), EDTINI.EDT (editor initialization file for system manager). For example, the system manager's LOGIN.COM contained symbols for invoking the system shutdown procedures or rebooting the system (SHUTDOWN, REBOOT), meaning the user didn't have to answer 20 questions asked by the shutdown procedure when he turned the system off for the night.

Another feature aimed at simplifying system management was the concept of tied terminals for open systems. This feature enabled the terminals to log into user accounts automatically when they were powered on. MICROVMS was set up so that all terminals, except the console terminal, automatically were logged into a sample account called USER.

Turnkey systems probably would use tied terminals to avoid teaching customers about accounts and login procedures. Each terminal would be dedicated to a particular menu, running only the programs needed by the particular user. A secretary's terminal would have one menu, while a manager's terminal would have another. This is termed an open system, as nothing prevents the secretary from accessing the manager's terminal and thus his menu.

Sample accounts were other features in MICROVMS aimed at simplifying system management. USER was a non-privileged account, which could be copied to create other such accounts.

RX50 Distribution Medium

Use of floppy diskettes as a distribution medium and the restrictive size of the system disk were the major constraints molding the design of the installation and tailoring mechanisms. Although the simplest installation procedure would have been to install one BACKUP saveset containing a bootable system disk, this would have meant inserting more than 35 floppies - both a time-consuming and an impossible process, as the system disk had insufficient space to hold all the VMS files. The MICROVMS installation procedure had to be a tailor-on mechanism that would allow users to choose only the files that they needed.

There were other important considerations: installation time and simplicity. Restoring a BACKUP saveset would be the fastest way to install the files that all users would need; i.e., the BASE kit. After this bootable, run-time environment was installed, the system could be booted, allowing MICROVMS options to be installed using the standard VMS procedure VMSINSTAL.COM, which installs VMS maintenance updates or Digital layered products, such as COBOL or FORTRAN.

Because the available system disk space might not be sufficient for an entire option such as PROGRAMMING, the installation procedures would have to be a form of tailoring, thereby allowing the user to install pieces of the option instead of the entire option. Thus, the MICROVMS options were organized into numerous savesets, each containing one tailorable unit. Each option (USER, UTIL, NET, PROG, SYSP) would start on a new floppy, so a user wouldn't have to insert all the floppies in the MICROVMS kit to install the last tailorable unit.

A tailor-off utility also was provided, so that you could remove an option or tailorable unit from the system disk if it was no longer needed.

MICROVMS Licensing

MICROVMS licensing diverged from the standard VMS licensing scheme. A new measurement of software value was defined, consisting of the number of users on the system. Thus, a MICROVMS system being used as a workstation could be licensed as a single user system, while a time-sharing system could be licensed in incremental numbers of users (eight, 16, etc.). An unlimited use license was also available.

This scheme quickly led to the obvious question: What's a user? It was easy to describe this concept in human terms: "A user is a person accessing the system through a terminal." However, it was a bit more difficult to interpret this into programmable terms. Such questions as, "Is a user a batch job? a network job? a remote terminal (SET HOST)? a LAT terminal? a workstation window?" had to be answered.

The answers all went back to the definition of a person accessing the system. If one person was doing multiple things, for example, workstation windows, batch jobs or network jobs, those would be counted as one user. If multiple people were being represented, each would count as a separate user; e.g., LAT terminals or hard-wired terminals. If there was any doubt about the answer, we would assume multiple people; e.g., remote terminals (SET HOST).

MICROVMS didn't contain all the files that were on the VMS kit. The installation procedures were different, providing a tailor-on capability. MICROVMS was distributed on floppies, while VMS was distributed on magtape. The documentation was styled in cookbook format and greatly reduced. System management was aided by the addition of sample procedures and user accounts. Licensing was done by user instead of by CPU capacity.

MICROVMS has its pros and cons. Having separate products introduced some problems, while solving those unique to MICROVAX systems.

Having separate products caused duplication of effort in a number of areas. Two different installation and tailoring procedures meant customers and field support personnel had to learn two methods. Maintenance of two sets of tailoring and installation procedures proved costly.

Two documentation sets seemed like a good idea, but who should get which set? Experienced MICROVMS customers often needed the full VMS documentation. VMS customers wanted to purchase the simplified MICROVMS manuals for some of their users, such as university students. Now two sets of manuals had to be updated at every new release.

VMS customers frequently would purchase MICROVAX systems and want files that weren't included on the MICROVMS kit, such as example files. In each release, the classification of files in and their location in a MICROVMS option was changing.

Each new VMS release added more functionality to VMS. This meant an ever-increasing number of RX50 floppies, almost doubling the number in the original MICROVMS V1.0 kit. Installation time was taking longer. More system disk space was required just to hold the BASE kit. Managing the interactions between components (MAIL and editors, for example), to determine what had to be in which kit and what constituted a tailorable entity, was increasingly difficult.

As systems got faster and larger, deciding which VMS product to offer on each new system became more complicated. A single CPU could be used in multiple systems: VAXSTATION 3200, MICROVAX 3600 or VAXSERVER 3602. While the VAXSTATION 3200 is a singleuser system, the MICROVAX 3600 is three times faster than the first VAX, the 11/780.

Larger system disks and expanded physical memory (which had arrived with the MICROVAX II) were doubling in size every year. New distribution media (TK50, TK70) was available instead of floppy diskettes. Even floppies had grown with the introduction of the 1.2-MB RX33.

Another new VMS product had emerged, Local Area VAXCLUSTERS. VMS now provided the ability to boot a workstation system over the Ethernet off a cluster boot node (time-sharing system). That meant that VMS, instead of MICROVMS, would be running on many of the single-user systems. It was no longer necessary to have a backup device (tape) or a system disk available on every system. Files could be stored and backed up on the boot node.

The VMS writers had reorganized the VMS documentation set into a series of reference manuals (large three-ring binders) and guides (smaller, MICROVMS-size books). A VMS User's Manual had been written, analogous to the MICROVMS User's Manual.

Customers liked the sample system management files in MICROVMS and were asking that they be included in VMS. A tailoring survey had shown that most customers used the tailor-off procedure included in MICROVMS and few were using the tailor-on capabilities.

What Merging Means

Hardware, software, documentation and customer input seemed to indicate that MICROVMS packaging has outlived its usefulness. Was MICROVMS a mistake? Absolutely not. Without MICROVMS, there would have been no way to ship the MICROVAX I and early MICROVAX II systems. MICROVMS was a new method for packaging, pricing and documentation that was targeted at new markets for VAX and VMS.

What does the VMS/MICROVMS merge mean? In simple terms, it means resolving the differences between VMS and MICROVMS so that there's only one product, VMS. Some features in MICROVMS were acclaimed by all VMS users; these will be added to VMS. Other features were not liked and will be discarded. Some things will be rewritten, such as new tailoring procedures, taking the best features from both VMS and MICROVMS.

Features Moving Into VMS

The sample system management files will become VMS template files. For example, VMS will include a SYSTARTUP.COM file, which serves as a starting point for site-specific setup for a new system manager. A duplicate copy of this file, SYSTARTUP.TEMPLATE, also will be included, so a working version will exist on the system.

Other template files include SYLOGICALS.COM (device logical name definitions from UVSTARTUP.COM), SYLOGIN.COM (system-wide login command file), LOGIN.COM (system manager's login command file), etc. The other MICROVMS procedures will be moved to the examples directory, with a pointer to MGRMENU.COM left in the system manager's LOGIN.COM.

The VMS documentation will include a VMS User's Manual, which can be ordered separately from the entire documentation set. It contains more information on DCL and utilities than the MICROVMS User's Guide, but less information on system management.

The tailoring and installation procedures have been rewritten. With the discontinuation of RX50 distribution media and the new larger system disks, the tailoring design is now to tailor files off rather than tailor on. With this design, installation time can be improved by using only three savesets (the format of the VMS binary kit). The first saveset is analogous to the MICROVMS BASE kit, a run-time environment that can be installed on small disk systems. For small disk systems, tailor-on is still possible; it just doesn't perform as quickly as tailor-off procedures.

The other two savesets are similar to the old VMS LIBRARY and OPTIONAL savesets. The LIBRARY saveset contains the utilities and libraries needed for program development, as well as those utilities not contained in the first saveset. The OPTIONAL saveset contains system programming tools, sample drivers, BLISS libraries, etc., files needed by a small percentage of VMS users.

The revamp of the installation and tailoring procedures also has allowed long-needed performance improvements, such as converting the data file that drives the procedures (VMSKITBLD.DAT) into an ISAM file.

The tailoring mechanism is now a program, instead of DCL procedures, that improves the performance of tailoring. The tailoring classes and subclasses are similar to those in MICROVMS. It has been enhanced with more prompting, disk free space checking and other niceties.

Best of all, all VAX and MICROVAX systems now will use the same procedures for installation and tailoring. All files will be shipped for all VAX and MICROVAX systems. For ex-MICROVMS users, the ability to tailoron still exists and the MICROVMS-specific files are still there, so a MICROVMS-like environment can be created.

The sample user accounts have been removed, as no one used them. The ability to create tied terminals still exists, with a command file showing how to set them up. However, VMS will not automatically tie any terminal to a particular account as MICROVMS did.

Licensing of VMS software by number of users will be made available on VMS to MICROVAX users.

The VMS documentation has been subsetted, so fewer manuals are shipped with MICROVAX systems than with VAX systems. However, all manuals are aimed at users of either system, rather than being targeted at only MICROVAX systems.

MICROVMS was born out of limitations of system disk size and distribution media. The tailoring tools, template files and documentation developed for MICROVAX systems have proved useful for all VMS users. Licensing policies have evolved, as chip technology has brought the computer power to the user's desktop. As MICROVMS merges back into the VMS product, it will pass into the annals of history, but the best features still remain, integrated into the VMS product.

Kathleen D. Morse is a consulting software engineer for Digital Equipment Corporation, Nashua, New Hampshire.