WASD Configuration

1.Introduction

Welcome!

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

Installation and update of the package is covered by WASD Installation.

This document provides detailed configuration instructions of the WASD Web Services package.

Following installation the package should require only minor further configuration for basic serving.

WASD configuration is performed using the contents of five files located using logical names

along with server CLI parameters commonly provide by startup DCL procedures.

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 (Account Support Files in WASD Installation).
2. The only configuration that should require immediate attention will be the mapping rules (10. Request Processing Configuration).

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

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

Keep site-specific resources and server installation separate and distinct.

1.1Troubleshooting?

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.