WASD Install and Update

1.New to WASD? Start Here!


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).

    VAX requires an extra step (‘VAX Expat Archive’ in 2.1 Package UNZIP).

    If Transport Layer Security (TLS - a.k.a. Secure Sockets Layer - SSL) is to be used and a TLS/SSL server image to be built the WASD [Open]SSL product must be installed at this stage (see TLS/SSL Functionality Sources of WASD Features and Facilities). An existing VSI SSL111 for OpenVMS product (all based on OpenSSL 1.0.2 and earlier obsolete) requires no additional step. If the WASD [Open]SSL package it must UNZIPed into the [.WASD_ROOT] tree at this stage.

    $ UNZIP -d [.WASD_ROOT] device:[dir]OPENSSLWASDnnn-arch.ZIP

    Note the use of the "-d" switch.

  2. INSTALL Package

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

  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:

  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.


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.


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

$ HTTPD /DO=AUTH=SKELKEY=_username:password

Then using a browser access any available service, entering the above username (including underscore) and password when prompted. /httpd/-/admin/report/WATCH

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