With the installation, update and detailed configuration of the WASD Web
Services package provided in
WASD Web Services - Install and Config
why have an introduction in this subsequent document? After getting the basics
up and running (often the first thing we want to do) it's time to stop and
consider the tool and what we're trying to accomplish with it. So this section
provides an overview of the package's design philosophy, history and
significant features and capabilities by topic.
The document assumes a basic understanding of Web technologies and uses
terms without explaining them (e.g. HTTP, HTML, URL, CGI, SSI, etc.) The
reader is refered to documents specifically on these topics.
Objectives
WASD Web Services originated from a 1993 decision by Wide Area Surveillance
Division (WASD) management (then High Frequency Radar Division, HFRD) to make
as much information as possible, both administrative and research, available
online to a burgeoning personal desktop workstation and PC environment (to use
the current term … an intranet) using the then emerging Web
technologies.
It then became the objective of this author to make all of our systems'
VMS-related resources available via HTTP and HTML, regardless of the underlying
data or storage format. An examination of the WASD package will show that this
objective is substantially achieved.
Reasons For Yet Another Web Package
Reasons for developing (remember; back in 1994!) a local HTTP server were
few but compelling:
It was prefered to support this environment on a VMS platform;
at the time the most widely used and accessible environment within WASD.
At that time servers (and even then there were quite a few variations)
were largely Unix based, although it was being supported (to a greater or
lesses extent) across a wide range of platforms. Ports to VMS, if they
existed, were often in-progress or half-baked, employing Unixisms that
don't translate elegantly to the VMS environment.
The VMS version of the CERN server (3.0-6) was evaluated during
mid-1994:
It was (still is) not multi-threaded under VMS (i.e. cannot support
concurrent clients). For example, a lengthy search may delay other clients
for unacceptable periods.
The performance was good with document transfers, but became poor when
running a script.
It is acknowleged in the release notes that it cannot handle a client
cancelling a data transfer (a not-uncommon action). This was confirmed
experimentally.
An early version of the OSU server was evaluated via documentation
mid-1994. The author considered that the DECthreads of the time to have
limitations (including frequent, show-stopping bugs) and OSU had a number of
implementation idiosyncracies (e.g. DECnet based scripting).
HTTP, in the then standard implementation (HTTP/1.0, RFC1945), was
relatively simple to implement to the level required to support
intra-Divisional requirements.
Since that time …
As of December 1995 the server has worked extremely well and has a
number of facilities tailored for the VMS environment. It can continue to be
utilized until there are overwhelming reasons for implementing something else.
June 1997 the server and associated software continues to evolve and
provide a stable and effective VMS Web environment, even with the advent of a
small number of commercial VMS Web products.
October 1999 the package is beginning to mature as an HTTP/1.0
solution, providing not only a fast and stable server but an increasingly
extensive collection of applications and tools.
July 2002 it continues to be refined and extended. A greater
emphasis on "commercial" functionality has occured over the past couple of
years.
December 2004 it now complies with the HTTP/1.1 specification
(RFC2616) and provides a very respectable range of functionality and the
fastest and most efficient serving environment for VMS.
A decade on (2014) it continues to be adopted by sites wanting fast,
efficient, capable and often philosophically VMS infrastructure. WASD continues
to be enhanced and bug-fixed two decades after its initial, tentative steps
into the World-Wide information Web.
May 2016 brings HTTP/2 (RFC 7540, RFC 7541) to WASD. A replacement
for how HTTP is expressed "on the wire", it is not a ground-up rewrite of the
protocol; HTTP methods, status codes and semantics are the same. The focus of
the protocol is on performance; specifically, end-user perceived latency,
network and server resource usage.
June 2019 occasions WASD's twenty-fifth anniversary!
For a quarter-century and more – the only web environment implemented
expressly for VMS.
Late 2021 ta-da! WASD on x86-64
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).
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.