.LM 7 .RM 72 .FL BOLD .C;VMS and Software Product Integration .BL .C;by .BL .C;Martin Brunecky .C;Auto-trol Technology Corporation .C;12500 North Washington Street .C;Denver, Colorado 80233 .C;(303) 252-2499 .BL 2 .C;Draft White Paper submitted to: .BL .C;The VAX SIG System Management Working Group .BL 2 .FL SUBSTITUTE .c;$$date .NOFL SUBSTITUTE .BL .HL 1 ^*Background and Philosophical Overview\* The key to the success of VMS beyond the technical marketplace is the availability of a wide range of application software, using VMS as an underlying operating environment. Today, almost every VMS installation uses not only Digital software products (frequently referred to as Layered Software), but also a wide variety of software products coming from many different vendors. Should the VMS proliferation continue, this product variety will grow even more. .BL Unfortunately, everyone who has ever faced VMS system management discovered that there is absolutely no consistency in how the individual products fit into the VMS environment - starting with product installation, component placement or startup. Most products lack any tools for removal from the system, not talking about tools for product distribution in VAX Clusters or VMS system parameter adjustments. Resulting inconsistency turns VMS management into an extremely difficult task, no matter how sophisticated system management tools are provided by the VMS development. Even the VMS Management Architecture will not change that as long as the current lack of policies continues, and only a very small portion of managed software complies with the Management Architecture assumptions. .BL From the very beginning, one of the strengths of VMS has been a very thorough architectural approach. DEC provided policies, guidelines and conventions for VMS compliant software development. An excellent example is the VAX/VMS Modular Programming Standard contained in the Guide to Creating Modular Procedures on VAX/VMS. Unfortunately, there has never been any standard nor guidelines for VMS Product Integration. The VAX/VMS Developer's Guide to VMSINSTAL focuses primarily on VMSINSTAL functionality. Even worse, the VMSINSTAL which has been designed for VMS system components installation and updates, actually encourages several practicies which are not optimal for application software. .BL To advocate the need for the VMS Product Integration Guide, in this document I present several key issues related to product integration. The document is based on my experience with VMS system management both at the high end - large VAX Clusters - as well as at the low end - a standalone, single user workstation in the hands of a novice user. The Guide should become a part of a standard VMS documentation set, so that anybody preparing an application for VMS has immediate access to it. .HL 1 ^*Product Integration Guidelines\* The following paragraphs address several issues related to product integration, primarily from the VMS management standpoint. The list is far from being complete, since this document is meant as an open-ended proposal. .HL 2 ^*Product Installation\* Every product installation should be kept as simple as possible. Typically, the product should contain the "DEFAULT" installation, eliminating any configuration questions. Should the user choose "TAILORED" installation, all the queries must be asked up front, leaving the rest of installation unattended. No product installation should assume the user reads or understands the installation guide. .BL Using a single installation tool, such as VMSINSTAL, is the basic pre-requisite for consistency. However, VMSINSTAL needs some enhancements to be eqally useful both for VMS system components and for integrated applications. .BL Currently, VMSINSTAL is expected to perform every single step required to use a given product on a node executing the installation. This approach does not work well for a VAX Cluster, where a single installation may enable product use on many nodes (of very different classes). Some of those nodes may not even be present at installation time. Therefore, some of the current VMSINSTAL functions must be offloaded into other procedures, executed from other nodes after the installation is completed - such as product startup or configuration procedures. The operations required to use a product on other nodes should be limited to registering product startup, SW license and eventual verification procedure execution. .HL 2 ^*Product Placement\* Currently, most of the VMS layered products as well as some third party vendors use VMSINSTAL (or other tools) to load their product files onto the VMS system tree. The results are obvious: .BL .LIST 0 "-" .LE;VMS system tree cluttered with many, many files of unknown origin and purpose .LE;Many products must be re-installed when VMS updates it's tree .LE;Large [SYSEXE] directory slows down image activations .LE;VMS rolling upgrades are slow and complicated since they try to preserve files which VMS has no knowledge of. .ELS In my opinion, except for very tightly coupled VMS system components, any other software product(s) should be ^*prohibited\* from using the VMS system tree. There is actually NO reason to use the VMS tree: .LIST 0 "-" .BL .LE;Shareable images may be placed anywhere (using logical names) .LE;Executable images may execute from anywhere .LE;Device drivers may be loaded from anywhere .LE;Help libraries may be located using logical names .ELS Hence, each product tree should start with the product ^*main\* directory, locate on the user-selected (rooted) device (which may be the system disk, but NOT the VMS directory tree). As a pre-requisite, VMS must support rooted devices nesting (lack of which I consider a bug, not a feature). .HL 2 ^*VMS Product Registrar\* VMS Product Registrar service has been put in place beginning with VMS 4.4 by the VMS System Quality Group to prevent naming conflicts between different software products. Known only to the users of the Developer's Guide to VMSINSTAL (not in standard document set), VMS product Registrar coordinates naming conventions for: .LIST 1 "o" .LE;Product names (for VMSINSTAL save set identification) .LE;Facility Names (to be used as a prefix for global symbols, entry points, rights identifiers, data structure definitions and file names). .LE;Logical Names (prefix to be identical to facility name, if possible) .LE;System wide process names .LE;System wide mailbox names .LE;Shareable image names .ELS Unfortunately, most software product developers are not aware of this service. Obviously, registrar needs further enhancements. To be efficient, this service should be provided as a dial-in interactive facility not requiring extensive paperwork. .HL 2 ^*Cross Product Modifications\* Software product installation should ^*never\* modify parts of any other products. Very frequent violation is the modification of VMS DCL tables by product installation. When VMS upgrade replaces DCL tables, any such product ceases to run and must be re-installed. Very simple solution is to bind DCL tables with product images, and leave DCLTABLES.EXE to VMS. .BL Naturally, DCLTABLES.EXE is only one example of undesired product interaction. Many others may be solved using VMS logical names to communicate information about product presence, versions and similar data. .HL 2 ^*Product Control\* I definitly feel an urgent need to standardize on product control under VMS. So far, the only agreement is that ^*most\* products use some form of product STARTUP. In my opinion, standardization should extend beyond that: .LIST 1 "o" .LE;STARTUP - product startup, containing system parameter verification, system logical names creation, image installation, driver load and others. One of the logical names must point to the product main directory, to locate the remaining product control procedure. Strict naming convention must apply to system wide logical names, use of which should be kept under control. .LE;SETUP - user (process) set-up for product use. Separation of startup and setup allows replacement of the system-wide setup by process (job/group) setup, allowing use of multiple versions of the same product on one system. Using the SETUP also allows replacement of many system wide logical names by process or job names, reducing logical name translation overhead for other system users. .LE;STOP - product de-activation, preparing for another STARTUP. .LE;VERIFY - basic verification of product environment, files availability, checksums and eventually quick functionality tests. .LE;CONFIG - product configuration, tuning, tailoring and distribution (of product components) to other nodes for performance or availability. .LE;DELETE - complete product de-installation (deleting all the product files) .ELS Contrary to the VMS development, I believe that product control files are an essential part of the ^*product\*, and should be kept in the product main directory (accessible by any VAX Cluster member). This approach solves any naming convention questions by always using the same name (STARTUP.COM) for the same functionality - the product main directory name is sufficient for product identification. .HL 2 ^*Product Usage Authorization\* With the advent of VMS software licensing, products will be much more frequently enabled (and temporarily disabled) on a per node basis. The entire System Management Architecture should centralize and standardize this task for any software product. To enable product use on a given node, the three following steps must be performed. It is desirable that they are tied together - performed in a single operation: .LIST 1 "o" .LE;Register product SW license .LE;Register product STARTUP and other control procedures .LE;Register product system requirements in AUTOGEN files .ELS .HL 2 ^*Product System Requirement Assurance\* As mentioned above, product installation can ^*not\* guarantee that product requirements will be met by other cluster members. In my opinion, both the product installation and startup must be almost automatic - reliance on system manager editing MODPARAMS.DAT (for example), is not acceptable. .BL .tp 15 Given the requirements, not the ^*installation\*, but the product authorization along with the product STARTUP has to make sure that the product will function on a given node. Therefore, aside of setting up logical names, installing images and other, the product startup must: .LIST 1 "o" .LE;Assure that product requirements are present in AUTOGEN file(s) .LE;Verify that system parameters meet product minimal requirements .LE;If the product requirements are not met request AUTOGEN. .ELS .TP 8 To achieve the objectives above, a new interface to AUTOGEN is necessary. Most likely, such an interface will be similar to an undocumented AGN utility used by the Workstation Software installation. Obviously, any product requirements entered by a registered product must be visible to the system manager - hence the additional requirement for the SYSMAN functionality. .HL 2 ^*Product Distribution in a VAX Cluster\* Even though some sites may prefer centralized software installation, many others will find significant benefits in distributing (critical) product components to multiple locations or local disks. Even though the majority of the product files is shared and present in a single copy, significant performance may be gained by placing I/O intensive files on local disks. Such distribution can NOT be performed by the installation (not all the nodes are present), and repeating (even a partial) product installation is not a viable solution. .BL Therefore, products should provide a CONFIGURATION procedure, which performs the product TAILORING and controlled DISTRIBUTION. The procedure should keep track of any tailoring or distributions, increasing the importance of product main directory created by the installation. Using the list of product distributions, the product startup on any node can automatically pick up components distributed to other disks. Similarly, product removal (delete) can trace all the distributed files and delete them all. .HL 1 ^*Product Integration Tools\* An essential pre-requisite for consistency and success of product integration is the availability of several product integration tools. Only several such tools are mentioned here, with a feeling that the toolset should be limited in the number of components, yet efficient enough to encourage its use, resulting in desired commonality among different software products. .HL 2 ^*Product Requirements Evaluation\* Currently, very few products come up with a clear knowledge of their system impact and minimum system requirements. One of the reasons is the lack of a specialized utility that would assist in determining such requirements on a per product basis. All the existing tools, such as the MONITOR, are targeted towards overall system performance monitoring. Simple SHOW PROCESS command is not sufficient. Clearly, there is a need for a specialized utility targeted to product system impact evaluation and profiling. Such a utility must also provide information currently not directly available (such as process section count or dynamic memory allocation usage). .HL 2 ^*Installation Support\* The VMSINSTAL.COM provides sufficient installation support and there is no need to change it. However, since VMSINSTAL has been designed for VMS system components, it lacks functionality in several areas. To mention just the major ones: .LIST 1 "o" .LE;Installations ^*outside\* of the VMS system tree (other disks). For example, the installation which loads files on some other disk should not use (and expose) the VMS system disk at all. .LE;Preserving directory structures. Large SW products need to load entire directory trees without a need to re-generate such a structure during installation with all the associated overhead. .LE;More sophisticated control over product prototype account creation, modification and checking. .ELS VMS examples should contain a template for a typical KITINSTAL.COM. The template should serve as a guide to implement installation with a DEFAULT and TAILORED paths. .HL 2 ^*Product Control Support\* Offloading some functions from VMSINSTAL to other procedures (such as STARTUP) along with centralized support for product AUTHORIZATION requires a set of new support procedures. .BL Such procedures may be implemented by any software vendor, but the result will again be complete inconsistency. Therefore, both the product control procedures templates as well as standard supporting code (procedure) should be provided with VMS.