WASD Install and Update

For version 12.2 release of WASD VMS Web Services.

Published January 2024

Document generated using wasDOC version 2.0.0

Abstract

This document provides detailed installation and update instructions for the WASD Web Services package.

For WASD configuration see WASD Web Services - Configuration

For the more significant features and facilities available with the WASD Web Services package see WASD Web Services - Features

For information on CGI, CGIplus, ISAPI, OSU, etc., scripting, see WASD Web Services - Scripting

And for a description of WASD Web document, SSI and directory listing behaviours and options, WASD Web Services - Environment

Online Search

WASD VMS Web Services – Copyright © 1996-2024 Mark G. Daniel

Apache License, Version 2.0

License

Licensed under the Apache License, Version 2.0 (the "License");

[email protected]
A pox on the houses of all spamers. Make that two poxes.

All copyright and trademarks within this document belong to their rightful owners. See 7. Attribution and Acknowledgement.

This is a static (file), single document.
Alternative multi-part static and dynamic documents.
Links followed by ⤤ open in a new page.

Table of Content

1.New to WASD? Start Here!

Welcome!

WASD is outlined in the Introduction and Package Overview sections of the WASD Features document.

There are a number of approaches to installing and updating a WASD package.
The vanilla recipes are 2. Installation and 3. Update but there are 5. Other Ways to Deploy.

This section provides a quick guide to getting your WASD package installed, configured and serving.

1. Unzip Package

   Install the files following the guidelines in 2. Installation.
   Note that more than one archive may be needed (‘Source Archive, Object Module Archives’ in 2.1 Package UNZIP).

   Building an SSL-capable version of the server is a common requirement.

   As described in VSI OpenSSL SSL111-V0101-1S and SSL3-V0300-7 it is now possible to install VSI OpenSSL releases on pre-V8.4 VMS. This is the recommended approach to providing and maintaining OpenSSL for WASD.

   WASD SSL is discussed in detail in Transport Layer Security of WASD Features and Facilities.

2. INSTALL Package

   Server installation is performed using the INSTALL.COM procedure (2.9 INSTALL.COM Procedure).

   • Build Package – Compile and link, or just link supplied object files to produce VMS executables for the system's version of VMS.
   • Check Package – Check basic operation of the package (2.10 Quick-Check).
   • Create Server and Scripting Accounts – Create two independent accounts, one for executing the server, the other for executing scripts (4.1 VMS Server Account). If quotas are enabled on the target disk provides an ambit allocation for these accounts. Review this at some stage.
   • Set Package Security – This sections traverses the newly installed tree and sets all package directories and files to required levels of access (Maintaining Package Security in WASD Configuration).
   • Copy Support and Configuration Files – Copy the example server support and configuration files (4.3 Account Support Files).
   • Install Scripts – Selectively copy groups of scripts from package build directories into the scripting directories.
3. Configure Package

   Following the execution of the INSTALL.COM procedure the package should require only minor, further configuration.

   Initially two files may require alteration.

   1. The startup file, possibly to set the local WASD_CONFIG_GMT logical (for systems not supporting DTSS (e.g. DECnet-Plus)). Consider using the STARTUP_LOCAL.COM file for other site-specific requirements (4.3 Account Support Files).
   2. The only configuration that should require immediate attention will be the mapping rules (Request Processing Configuration in WASD Configuration).

   More generally server runtime configuration involves the considerations discussed in Site Organisation of WASD Configuration along with the following aspects:

   • Configuring the HTTP server run-time characteristics (Configuration Considerations in WASD Configuration).
   • Mapping request paths to the VMS file system, and to other things such as scripts (Request Processing Configuration in WASD Configuration).
   • Customizing some or all messages (Message Configuration in WASD Configuration).
   • Establishing an authentication and authorization environment (Authorization Configuration (Basics) in WASD Configuration).
4. Start Server

   Execute the startup procedure (‘STARTUP.COM’ in 4.3 Account Support Files). Get your browser and connect!

5. Find Out What's Wrong  

   Of course something will not be right! This can happen with the initial configuration and sometimes when changing configuration. The server provides information messages in the run-time log, look in the WASD_ROOT:[LOG_SERVER] directory.

   Remember, the basic installation's integrity can always be checked as described in 2.10 Quick-Check). This uses the configuration files from the [EXAMPLE] directory, so provided these have not been altered the server should execute in demonstration mode correctly.

   Can't resolve it? See 2.12 Reporting Problems.

1.1Using IA64-hosted X86 Cross-Complier?

While native X86 C compiler releases mean compiling on the target system is possible, the IA64 cross-compiler is still a viable option.

1. cross-compile on an IA64 system
2. link resulting object file(s) on the X86 system

When building using the cross-compiler tools the procedures recognise the XCC$COMPILER environment and adjust to create and use [.OBJ_X86_64] object code directories.

For example; to build WASD package:

1. On IA64 ensure @SYS$MANAGER:X86_XTOOLS$SYLOGIN.COM and then select "3. Compile only" and complete the compilation.
   • For clustered IA64/X86 with an MSCP-mounted volume containing a shared [WASD_ROOT] the appropriate object files are now available to the X86 system.

     Proceed with the second phase.

   • For non-clustered build environments the same WASD kit must be installed on both IA64 and X86 systems. After compilation the resulting [.OBJ_X86_64] directories must be ZIPed into an archive, transferred to the X86 system and restored into the corresponding [WASD_ROOT].

     For example:

     IA64$ SET DEFAULT device:[WASD_ROOT] IA64$ ZIP "-V" location:X86_1210_OBJ.ZIP [...OBJ_X86_64]*.OBJ
     X86$ SET DEFAULT device:[WASD_ROOT] X86$ UNZIP location:X86_1210_OBJ.ZIP

     Proceed with the second phase.

2. On X86 perform the corresponding "2. linking (separate package) object modules", and continue the rest of the installation.

1.2Troubleshooting?

When initially installing or configuring WASD, and sometimes later where something breaks spectacularly, it is most useful to be able to gain insight into what the server is up to.

The go-to tool is  WATCH  (yes, all capitals, and for no other reason than it makes it stand out).

WATCH is described in detail in WATCH Facility of the WASD Features and Facilities document.

For most circumstances WATCH can be made available for troubleshooting even if the configuration is significantly broken. This is done by using a skeleton-key to authorise special access into the server.

The skeleton-key is described in detail in Skeleton-Key Authentication of the WASD Features and Facilities document.

TL;DR

Enable at the command-line with the username anything beginning with an underscore and at least 8 characters, same for the password length.

Then using a browser access any available service, entering the above username (including underscore) and password when prompted.

The service administration facilities (of which WATCH is one) are also available and useful.

2.Installation

The WASD package is distributed as ZIP archives.

It generally pays to use the latest version of VMS UNZIP available. Archives will contain a comment about the minimum version required, check that as described in the next paragraph. To show the version of the current UNZIP utility, use

The ZIP archive will contain brief installation instructions. Use the following command to read this and any other information provided.

It is recommended to check the integrity of, then list the contents of, the archive before UNZIPing.

The archive will have the structure:

2.1Package UNZIP

While an elementary installation involves a simple UNZIP into a parent directory, take a moment to consider the future and later update versions. Keep server and site resources independent. This will make updates much simpler. Also consider ‘Multiple Installations’ in 5.1.3 Considerations.

The archive contains the complete directory tree. Hence it is necessary to SET DEFAULT into the top-level directory of the volume the package is to be installed on.

Source Archive, Object Module Archives

The complete package, source code, documentation, examples, etc., is provided in a single main archive. Installation and other build procedures allow the entire package to be compiled and linked from this if prefered. This requires a later version of DEC C (preferably v6.n or greater).

In addition, for those unable or not wishing to fully build the distribution, three other platform-specific archives are available, AXP (Alpha) IA64 (Itanium) and X86, containing a complete set of object modules, allowing the package to be built via a link operation only.

If a complete build is planned then only the main archive is required. If a link-only build then an additional archive for each site architecture must be UNZIPed as described above. This applies to both full installations and subsequent updates. The archives will be clearly identified with the architecture type, as illustrated in this example.

WASD OpenSSL

Building an SSL-capable version of the server is a common requirement.

As described in VSI OpenSSL SSL111-V0101-1S and SSL3-V0300-7 it is now possible to install VSI OpenSSL releases on pre-V8.4 VMS. This is the recommended approach to providing and maintaining OpenSSL for WASD.

WASD SSL is discussed in detail in Transport Layer Security of WASD Features and Facilities.

2.2Package Directory Structure

The package directories and content are organised as follows. Note that only some of these can be accessed by the server account (and therefore seen in server-generated directory listings) due to directory and file protections (see Recommended Package Security in WASD Configuration).

Package Directory Structure

2.3ODS-5 Volume

The WASD package can be installed on and used from ODS-5 (extended file specification) volumes. Note that the installation procedures and file system organisation of the package tree has been designed for ODS-2 compliance. (Of course the issue of installing WASD on an ODS-5 volume is completely separate from the ability to serve the contents of an ODS-5 volume!)

2.4Accessible Volume

Unlikely as it might be to install the package on a private or otherwise protected volume, the server and scripting accounts being unprivileged in themselves, require access sufficient to read, write and delete files from the volume (disk). The following illustrates how to check this and what the protections should look like. Generally any device that an unprivileged user can use the server accounts can use.

2.5Disk Quota

Should WASD_ROOT be located on a volume with disk quota enabled then suitable entries must exist for the server account (default HTTP$SERVER), SYSTEM account, and any scripting account(s) (default HTTP$NOBODY). The server account requires quota for the server process log, SYSTEM (due to SYSPRV use) for access log(s), and scripting account(s) requiring default temporary storage ([SCRATCH]) during processing.

2.6VMS 6.n

As of WASD v10.1 the minimum supported version for build and operation is VMS V7.0. Had to drag ourselves into the mid-1990s at some stage!

2.7SYSUAF and RIGHTSLIST

2.8TCP/IP Infrastructure

The WASD installation assumes that the system's TCP/IP infrastructure is correctly installed and configured, and is operating normally. For example, it is not unknown for a freshly built system to experience host name resolution problems preventing its own host name from being resolved and making even elementary server startup impossible.

DCL procedure INSTALL.COM

2.9INSTALL.COM Procedure

The INSTALL.COM procedure assists with the first installation of WASD. It provides a vanilla setup, using the standard directories and account environment described in this document. All sections prompt before performing any action and generally default to "no". Read the information and questions carefully!

After UNZIPing the package do the following:

It performs the following tasks:

1. Build Executables – Either compile sources and link, or just link package object code to produce images for the local version of VMS. If the system has a suitable SSL toolkit the installer is requested whether an SSL enabled version be built.
2. Check Package – Executes a procedure that runs up the HTTPd in demonstration mode. Allows the server build to be verified.
3. Create Server and Scripting Accounts – Create two, independent accounts, one for executing the server, the other for executing scripts (4.1 VMS Server Account). If quotas are enabled on the target disk provides an ambit allocation for these accounts. Review this at some stage.
4. Set Package Security – This section traverses the newly installed tree and sets all package directories and files to required levels of access. For directory settings see Maintaining Package Security in WASD Configuration.
5. Copy Support and Configuration Files – Copy the example server support and configuration files (4.3 Account Support Files).
6. Install Scripts – Selectively copy groups of scripts from package build directories into the scripting directories.

Support files to consider when customizing startup, etc. (4.3 Account Support Files):

• STARTUP.COM
• STARTUP_LOCAL.COM
• STARTUP_SERVER.COM

2.10Quick-Check

Once installed or updated it is possible to check the basic package at any time using the [INSTALL]DEMO.COM procedure. This invokes the server image using the /DEMO qualifier allowing some behaviours not possible under general use. Follow the displayed instructions. Basically, the server should start and become reachable via port number 7080. So, to test availability, using your prefered browser enter the URL listed on line starting with "%HTTPD-I-SERVICE" and the WASD welcome page should be displayed.

If a TLS (SSL) -enabled server has been built the demonstration server will also provide a TLS port number 7443 for access (this also can be explicitly activated using @[INSTALL]DEMO.COM SSL). WASD will dynamically generate a X509 certificate for use by the service. In modern browsers there are security constraints associated with self-signed certificates — lots! Interestingly, Incognito/[In]Private instances of a browser are often more relaxed about accepting certificates with security deficiencies (at least at the time of writing), so perhaps try those with the demonstration server. Also see Server Certificate in WASD Features.

When http://the.host.name:7080 is accessed the browser should display the package home page

2.11Local Setup Suggestions

Package updates will never contain anything in these directories:

• WASD_ROOT:[HTTP$NOBODY]
• WASD_ROOT:[HTTP$SERVER]
• WASD_ROOT:[LOCAL]
• WASD_ROOT:[STARTUP]

To prevent the overwriting of local configuration files it is suggested these be placed in the WASD_ROOT:[LOCAL] directory. Local authentication databases could also be placed in the [LOCAL] directory. Startup files can be placed where the local site manages system startup. These could be placed in the WASD_ROOT:[STARTUP] directory.

2.12Reporting Problems

This package, as is generally the case with freeware, is mainly developed and supported outside of the author's main occupation and working hours. Reports of problems and bugs (while not necessarily welcome :-), as well as general queries, are responded to as soon as practicable. If the documentation is inaccurate or could benefit from clarification in some area please advise of this also (the better the documentation the less queries you have to field personally … or so the theory goes).

With all reports please include the version of the server or script, and the hardware platform, operating system and TCP/IP package and version in use.

If a server error message is being generated please examine the HTML source of the error page. The "<META...>" information contains version information as well as valuable source code module and line information. Include this with the report.

If the server is exiting with a server-generated error message this information also contains module and line information. Please include this with the report.

The WATCH facility is often a powerful tool for problem investigation. It is also very useful when supplying details during problem resolution. When supplying WATCH output as part of a problem report please ZIP the file and include it an an e-mail attachment. Mailers often mangle the report format making it difficult to interpret.

Image crash dumps may also be generated, although these are of less value than the case of the previous two.

Reports may be e-mailed to [email protected] or if a suscriber, to [email protected].

3.Update

Before Updating

• Review the original installation instructions to refresh the various considerations involved.
• Some insurance on the directory tree is recommended in case the update should fail or otherwise be unusable or problematic (of course, this is good advice whenever about to make major changes to anything!) This may be in the format of a regular site backup, special pre-update backup, or special pre-update ZIP archive of the directory tree. The latter two could be accomplished using commands similar to the following:
  $ BACKUP WASD_ROOT:[000000...] location:WASDROOT.BCK/SAVE/VERIFY $ ZIP "-V" location:WASDROOT.ZIP device:[WASD_ROOT...]*.* $ ZIP "-T" location:WASDROOT.ZIP

  If using ZIP then ensure that a previous version of the target ZIP file does not already exist. If it does then that version is updated, a new version is not created.

• For existing files a new version is created (the first time this is about to occur the UNZIPper requests permission – either "A" for all, or "y" or "n" or a per-file basis).
• It is possible to selectively extract portions of a tree if something has become damaged. This would be accomplished by specifying what needs to be extracted from the archive (instead of the default all), as illustrated by the following example where only the Alpha object modules are extracted.
  $ SET DEFAULT device:[000000] $ UNZIP device:[dir]archive-AXP.ZIP ht_root/src/httpd/obj_axp/*.*

3.1Package UNZIP

Updating a package follows a similar process to installation.

The ZIP archive will contain brief installation instructions. Use the following command to read this and any other information provided.

It is recommended to check the integrity of, then list the contents of, the archive before UNZIPing.

The archive contains the complete directory tree. Hence it is necessary to SET DEFAULT into the parent directory of the WASD_ROOT logical name, as with the following example.

Source Archive, Object Module Archives

If a complete build is planned then only the main archive is required. If a link-only build then an additional archive for each site architecture must be UNZIPed.

WASD OpenSSL

Building an SSL-capable version of the server is a common requirement.

As described in VSI OpenSSL SSL111-V0101-1S and SSL3-V0300-7 it is now possible to install VSI OpenSSL releases on pre-V8.4 VMS. This is the recommended approach to providing and maintaining OpenSSL for WASD.

WASD SSL is discussed in detail in Transport Layer Security of WASD Features and Facilities.

DCL Procedure UPDATE.COM

3.2UPDATE.COM Procedure

The UPDATE.COM procedure assists with subsequent updates of WASD. It assumes a vanilla setup, using the standard directories and account environment described in this document. All sections prompt before performing any action and generally default to "no". Read the questions carefully!

Of course it is best (read mandatory) for the server to be shut down during an update!

After UNZIPing the updated package do the following:

It provides the following functions:

1. Build Executables – Either compile sources and link, or just link package object code to produce images for the local version of VMS. If the system has a suitable SSL toolkit the installer is requested whether an SSL enabled version be built.
2. Server Quick-Check – Executes a procedure that runs up the HTTPd in demonstration mode. Allows evaluation/checking of the basic package (2.10 Quick-Check).
3. Server Support/Configuration Files – Copies changed example HTTP server configuration and support files from the [EXAMPLE] directory to the [HTTP$SERVER], [LOCAL] and [STARTUP] directories.
4. Update Scripts – Selectively copy groups of scripts from package build directories into the scripting directories.
5. Reapply Package Security – This section traverses the updated tree and sets all package directories and files to required levels of access. For directory settings see Recommended Package Security in WASD Configuration.
6. Post-Update Cleanup – Prompts for permission to execute the post-update procedure described below.
7. Purge Files – Prompts for permission to purge the entire WASD_ROOT:[000000...] tree.

If declined during the update procedure the post-update steps 6 and 7 can be performed at any subsequent time using

3.3Re-Linking

After a major update to the operating system the package may refuse to start, reporting the message

This implies the executables require re-linking for your particular version of VMS. This can be accomplished quite simply, perform the linking section only of the UPDATE.COM Procedure.

3.4Building using MMS

The Module Management System (MMS)

VSI DECset for OpenVMS Guide to the Module Management System   [PDF]

may be used to build WASD when installed on an ODS-5 volume (MMS is case-sensitive).

The basic MMS build without a VSI (HP/DEC) C compiler requires the respective WASD object file kit installed. Without object files the package will (attempt to) be compiled then linked. Below are some examples for building against the various SSL kits.

To cross-compile from IA64 to X86.

Relevant X86 shareable images (e.g. SSL111$LIBSSL_SHR32.EXE) must be copied to X86_XTOOLS$ROOT:[SYSLIB] to complete the build.

The MMS build comprises two elements, a small configuration module located in the [src] directory and the main build configurations in [src.mms].

/wasd_root/src/descrip.mms
/wasd_root/src/mms/

The MMS WASD build is courtesy of Mark Berryman.
Any non-trivial questions are best addressed to Mark.
He is contactable via the info-WASD mailing list.

4.Server Account and Environment

The HTTP server account should be a standard account, preferably in a group of its own (definitely at least a non-system, non-user group), with sufficient quotas to handle the expected traffic.

Symptoms of insufficient process quotas include:

• Textual pages OK, but pages with a significant number of images having some or all "broken".
• Scripts failing mysteriously, particularly when multiple in use concurrently.
• Server and associated scripts all apparently waiting MWAIT or RWAST states.

A general rule is more is better, after all, it will only use as much as it needs! To assist with setting a reasonable BYTLM quota the WATCH report (see WATCH Facility of WASD Features and Facilities) provides some feedback on server BYTLM usage.

4.1VMS Server Account

The following provides a guide to the account.

4.2VMS Scripting Account

The following provides a guide to the account.

4.3Account Support Files

HTTPd Executables

Two server executables can be built by the package.

• HTTPD.EXE – basic server
• HTTPD_SSL.EXE – TLS/SSL-enabled server

Privileged Image

As the HTTP$SERVER account should be completely unprivileged, and the HTTPd image requires ALTPRI, CMKRNL, DETACH, NETMBX, TMPMBX, OPER, PRMGBL, PRMMBX, PSWAPM, SECURITY, SYSGBL, SYSLCK, SYSNAM, SYSPRV and WORLD privileges (see the WASD_ROOT:[SRC.HTTPD]READMORE.TXT) document for a description of how and why the server uses these privileges).

It is installed using a command similar to the following:

DCL Procedure STARTUP.COM

STARTUP.COM

Putting all this together the HTTP server startup procedure becomes something similar to the supplied example. It should be called from SYSTARTUP_VMS.COM or the site's equivalent.

This procedure will support simple and quite complex sites. It works closely with STARTUP_SERVER.COM (see below). It is designed to accept parameters from the command-line or as pre-assigned symbols. Operating this way requires no modifications to the procedure itself. Startup characteristics are essentially determined by DCL symbol values. Some symbols are booleans, switching functionality off and on, others require string values. When relevant startup values are not assigned a reasonable default will be applied. See the following examples.

Startup characteristics can be determined by supplying symbol assignment values as command-line parameters when calling the procedure.

Startup characteristics can also be determined by assigning the symbol values before calling the procedure itself.

Check the procedure itself for detail on symbol names and functionality. See WASD_ROOT:[EXAMPLE]STARTUP.COM

Also see 5.1.2 Formal Environments for further customisation examples.

DCL Procedure STARTUP_LOCAL.COM

STARTUP_LOCAL.COM

This file is automatically executed by the STARTUP.COM procedure immediately before the server is actually started. It is provided to supply all the local site's additional startup requirements. For example, a STARTUP.COM defined logical name could be modified here before the server proper is actually started. See WASD_ROOT:[EXAMPLE]STARTUP_LOCAL.COM

DCL Procedure STARTUP_SERVER.COM

STARTUP_SERVER.COM

This procedure serves two purposes.

1. The procedure becomes SYS$COMMAND for a detached process created directly during the execution of STARTUP.COM.
2. The procedure then controls the activation of the HTTPd executable image during server restarts and exits.

It is recommended to pass server startup command-line parameters using the WASD_SERVER_STARTUP logical name that this procedure checks for and uses if present. If this is defined the contents are applied to the server image when executed. It can be explicitly defined before WASD startup.

The value can also be passed to the main startup procedure in a symbol. The startup procedure then defines a system logical name with that value (note that any quotes used must be escaped).

It can also be manually redefined at any time and the server restarted to apply different startup parameters to the running server.

4.4Global Pages/Sections

Various accounting, cache and other shared data used by the server is provided by shared global memory. These requires one permananet global section (SYSGEN parameter GBLSECTIONS) and a number of permanent global pages (SYSGEN parameter GBLPAGES) per item. The number of items varies depending on configuration.

Global Sections

If there are insufficient global sections or pages the server will fail to start for all requirements except the activity statistics, this will just be disabled. Server process log startup messages advise on current usage.

As permanent, system-accessible global sections are deployed it may be necessary to explicitly delete them after ad hoc server experimentation, etc. (4.6 Server Startup). The startup qualifier /GBLSEC=NOPERM disables the creation of permanent global sections eliminating this requirement.

4.5Logical Names

WASD uses an independent logical name table (see 4.5.1 WASD Name Table below). Versions prior to 10 used the SYSTEM table and a substantially different naming schema.

The following logical names are used in the operation of the package. These are usually created by STARTUP.COM during server startup.

Package Logical Names

4.5.1WASD Name Table

In an effort to localise WASD-related logical names and avoid polluting the SYSTEM logical name table WASD version 10 creates it's own world-readable, system-writable name table, and adds it to LNM$SYSTEM_DIRECTORY.

WASD logical names are then defined in that table leaving the SYSTEM table with just a few essential names.

As can be seen the number of LNM$SYSTEM_TABLE names is small, five in this example (though it can vary). Logical name WASD_FILE_DEV locates a procedure to insert the WASD_TABLE into a process' LNM$FILE_DEV to make the table names available. Until that is done they are not visible without an explicit /TABLE=WASD_TABLE. The server automatically uses the procedure for itself and scripting processes. Site admins can simply

The WASD_ROOT logical provides a convenient, global logical location for the primary (default) WASD environment. HT_ROOT is used to provide pre-v10 backward-compatibility with existing sites. (If yours does not need the name you can deassign it during server startup.)

The WASD_DECNET_CGI_OBJECT and WASD_DECNET_OSU_OBJECT names provide global locations for the two DECnet scripting environments. These logicals are defined when a site uses the [STARTUP]STARTUP_DECNET.COM procedure. It is necessary to provide a global location for these with multiple WASD environments because DECnet objects are global entities. The one object must provide an infrastructure for potentially multiple WASD environments.

Other SYSTEM logical names, WASD_TABLE+n name tables, and WASD_FILE_DEVn logical names are used for non-primary WASD environments (see Instances and Environments of WASD Features and Facilities).

4.6Server Startup

When starting up the server several characteristics of the server may be specified using qualifiers on the command line. If not specified appropriate defaults are employed. For recommended methods of passing parameters to the executable at server startup see ‘STARTUP_SERVER.COM’ in 4.3 Account Support Files. For clarity some esoteric and legacy qualifiers and parameters are not listed in this table.

Server Image Command-Line Parameters

5.Other Ways to Deploy

While vanilla installations provide a straight-forward and complete WASD package there a number of other approaches to the installation and maintenance of a site or sites.

5.1Server Environments

WASD server environments allow multiple, distinctly configured environments to execute on a single system. Generally, WASD's unlimited virtual servers and multiple account scripting eliminates the need for multiple execution environments to kludge these requirements. However there may be circumstances that make this desirable; regression and forward-compatibility testing comes to mind.

First some general comments on the design of WASD.

• WASD creates and populates it's own logical name table (see 4.5 Logical Names).

  It also adds the WASD_FILE_DEV[n] and WASD_ROOT[n] logical names to the SYSTEM logical name table.

• WASD creates and uses rights identifiers.

  Installation creates and associates specific rights identifiers with separate accounts for server and script execution. Some specifically named identifiers have functional meaning to the server. Server startup can create and associate rights identifers used to manage the server run-time environment.

  All executing server images are aware of all other executing server images on the same system and within the same cluster. This performs all manner of coordination (e.g. instance recovery, instantiated services) and data exchange (e.g. $HTTPD/DO=MAP/ALL) activities.

• WASD uses global sections to accumulate data and for communication between WASD instances.

  Some of these are by default permanent and remain on a system unless explicitly removed.

• WASD uses detached scripting processes.

  As it's possible to $STOP a server process (and thereby prevent it's run-down handlers from cleaning up those detached processes). It therefore needs to be able to recognise as its 'own' and clean any such 'orphaned' processes up next time it starts. It does this by having a rights identifier associated with the server process name (e.g. WASD:80 grants its scripting processes WASD_PRC_WASD_80, a second instance WASD2:80, WASD_PRC_WASD2_80, etc.)

All of these mechanisms support multiple, independent environments on a single system. Due to design and implementation considerations there are fifteen such environments available per system. The primary (default) is one. Environments two to fifteen are available for site usage. (Demonstration mode, /DEMO uses environment zero.) Server instances (Server Instances section in WASD Features document) share a single environment.

There are two approaches to provisioning such multiple, independent environments.

5.1.1Ad Hoc Server Wrapper

Has been obsoleted by support added to STARTUP.COM.

5.1.2Formal Environments

The [EXAMPLE]STARTUP.COM procedure (copied into [STARTUP] during installation/update) uses locally assigned DCL symbols for customisation. It easily can be wrapped by another procedure to tailor a site or multiple enviroment startup. Check the startup options described in the procedure prologue.

This is a real-world example used to instantiate a second server enviroment statically linked with OpenSSL 1.1.1n. Note that only the configuration files requiring customisation are wrapped, with WASD_CONFIG_GLOBAL and WASD_CONFIG_MSG using the default files.

5.1.3Considerations

WASD environments each fully support all WASD features and facilities (including multiple server instances) with the exception of DECnet scripting where because of DECnet objects' global (per-system) definition only the one must be shared between environments.

Per-environment configuration must be done in its own WASD_ROOT part of the file-system and logical names must be defined in the environment's associated logical name table. The site administrator must keep track of which environment requires to be accessed from the command-line and set the process logical name search list using the appropriate

It is not possible to have multiple environments bind their services to the same IP address and port (for fundamental networking reasons). Unless the network interface is specifically multi-homed for the purpose, services provided by separate environments must be configured to use unique IP ports.

Non-primary environments (2…15) prefix the environment as a (hex) digit before the "WASD" in the process name. The above example when executing, each with a single scripting process, would appear in the system as (second environment providing a service on port 2280):

Cleaning Up

As described earlier each environment creates and maintains logical name table(s) and system-level name(s), detached scripting processes, lock resources and permananent global sections. Lock resources disappear with the server processes. Logical names, global sections, rights identifiers and occasionally detached scripting processes may require some cleaning up when a non-primary environment's use is concluded.

Concurrent Versions

Concurrent Versions

5.2Concurrent Installations

It is possible, and often useful, to build another WASD on a system with an existing and/or running installation. One purpose might be to maintain the previous version as a fallback in case of unexpected problems when migrating to a more recent version. Another, to maintain multiple releases for regression testing.

The general process is as follows:

• A clash with any existing [WASD_ROOT] directory must be avoided.
  Using the "-d" switch, UNZIP into a working directory using any unique name (WORKING in this example).
  $ SET DEFAULT device:[000000] $ UNZIP -d [.WORKING] device:[dir]archive.ZIP
  Do the same with object module archive(s) if required.
• Rename the WASD root directory into the current directory using a representative name (appending the version number is suggested) and then delete the working directory.
  $ RENAME [.WORKING]WASD_ROOT.DIR []WASD_ROOT_1210.DIR $ DELETE WORKING.DIR;*
• Move into the just renamed directory and build using the parameter INSTALL.
  The build is (always) performed using locally defined logical names.
  $ SET DEFAULT [WASD_ROOT_1210] $ @INSTALL INSTALL

  The INSTALL parameter overrides the install check and advisory message otherwise generated:

  ***************************************** * "WASD_ROOT" LOGICAL NAME DETECTED. * * THIS DOES NOT LOOK LIKE AN INSTALL! * *****************************************
• As appropriate, copy configuration and other files from the current WASD installation to the new.
  Check release notes for any variants.
  $ COPY WASD_ROOT:[LOCAL]*.* [WASD_ROOT_1210.LOCAL]

  Other site-specific localisations similarly may need to be copied or otherwise reproduced.
  For example, server or scripting account LOGIN.COM, custom STARTUP procedures, scripts, etc.

To move the running WASD environment from one installation to another:

• Shut down the currently running server.
  $ HTTPD/DO=EXIT=NOW
• Start the desired version of WASD from its file-system location.
  $ @device:[WASD_ROOT_1210.STARTUP]STARTUP.COM

  WASD logical names and environment will reflect the particular WASD root directory.
  Site-specific elements in the startup might need to be similarly flexible.
  Previous server process logs and access logs may no longer be immediately available.

Various schemas have been proposed and implemented for incorporating multiple version management including the use of hard-links, to the redefinition of WASD logicals to include search lists, to modification of system startup procedures. Whichever is selected being able to move between WASD versions has definite advantages, particularly for production environments.

Moving Between Minor Versions

Once multiple versions are established moving between versions should be a simple as stopping the executing server and then (re-)starting the desired version of WASD from its file-system location.

Moving Between Major Versions

Incompatibilties in global sections may complicate any attempt to jump between major versions (sometimes even between minor versions but that is rare). It is recommended when major versions are moved between to delete associated global sections. This zeroes accounting, etc.

DCL Procedure SELECT.COM

5.3SELECT.COM Procedure

The WASD_ROOT:[INSTALL]SELECT.COM procedure allows a selective update to the most recent version from an earlier version, usually but not exclusively the previous version. Where there is some advantage in only updating part of the package this procedure can be used.

When extracted, the content can then be built using @[.WASD_ROOT.INSTALL]UPDATE.COM as described in 3.2 UPDATE.COM Procedure. It may or may not require a full update build. The procedure will advise if a specific portion can be more quickly built and deployed.

5.40̷BTAIN.COM Procedure

0BTAIN.COM Procedure

0BTAIN.COM Procedure

DCL Procedure 0̷BTAIN.COM

Yes — that's a ZERO!

The WASD_ROOT:[INSTALL]0̷BTAIN.COM procedure assists in installing and updating selected portions of a WASD package allowing a "bare-bones" site to be created.

An example use of the procedure looks something like:

When extracted, the content of the new [.WASD_ROOT] directory can then be built using @[.WASD_ROOT.INSTALL]INSTALL.COM as described in 2.9 INSTALL.COM Procedure, or @[.WASD_ROOT.INSTALL]UPDATE.COM as described in 3.2 UPDATE.COM Procedure, as appropriate. When using these procedures individual sections building non-extracted elements must be declined. Alternatively, the build procedures associated with individual elements may be directly used.

The latest version of the procedure is automatically extracted from the specified package, or it manually can be extracted from the target package archive using

When manually extracted as above, the final stage of the procedure will report

Alternatively, if the latest package has been extracted to a local location, or a previous installation included [INSTALL]0BTAIN.COM, then that version can be used to start the whole thing off, extracting the relevant 0BTAIN.COM from the specified archive and then executing it.

0BTAIN.COM Procedure

5.5CLONE.COM Procedure

The WASD_ROOT:[INSTALL]CLONE.COM procedure assists in creating a ZIP archive of an existing WASD installation suitable for recreating the server on another system without the necessity of a full installation. This could be used to populate a series of systems with pre-configured servers.

An example use of the procedure looks something like:

6.Index

7.Attribution and Acknowledgement

WASD VMS Web Services – Copyright © 1996-2024 Mark G. Daniel

Licensed under the Apache License, Version 2.0

None of the following licensing appears incompatible with the Apache License

Clark Cooper, et.al.

This package uses the Expat XML parsing toolkit.

Bjöern Höehrmann

This package uses essential algorithm and code from Flexible and Economical UTF-8 Decoder.

Free Software Foundation

This package contains software made available by the Free Software Foundation under the GNU General Public License.

Ohio State University

This package contains software provided with the OSU (DECthreads) HTTP server package, authored by David Jones:

OpenSSL Project

This product can include software developed by the OpenSSL Project for use in the OpenSSL Toolkit (https://www.openssl.org/).

Paul E. Jones

This package uses SHA-1 hash code.

RSA Data Security

This software contains code derived in part from RSA Data Security, Inc:

Stuart Langridge

SortTable version 2
Stuart Langridge, http://www.kryogenix.org/code/browser/sorttable/

Tatsuhiro Tsujikawa

nghttp2 - HTTP/2 C Library
Tatsuhiro Tsujikawa, https://github.com/tatsuhiro-t

VSI OpenVMS, VSI TCP/IP Services for OpenVMS, VSI C
are registered trademarks of VMS Software Inc.

OpenVMS, HP TCP/IP Services for OpenVMS, HP C, Alpha, Itanium and VAX
are registered trademarks of Hewlett Packard Enterprise

MultiNet and TCPware are registered trademarks of Process Software Corporation