WASD Hypertext Services - Technical Overview

This document provides an technical overview of the WASD VMS HTTP server. It is primarily written for use internal to WASD and assumes that perpsective without apology. Any additional usage is subordinate to its role within WASD. The software has been written expressly for supporting an intra-organisational hypertext environment on a VMS platform. It too, is unreservedly tailored to this purpose and the requirements of WASD. All programs were designed only to specifically comply with the requirements of Compaq C, within a Compaq TCP/IP Services for VMS environment.

The document assumes a basic understanding of the hypertext 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 (these are often best consulted online, on the Internet WWW).

Also see WASD Scripting Environment for information on using CGI, ISAPI, OSU, etc. scripting, and WASD Hypertext Environment for information on using the WASD VMS hypertext facilities.

Objectives

The primary impetus for an internal Web environment was a 1993 decision by Division management to make as much information as possible, both administrative and research, available online (to use the current term ... an intranet). Early experimentation with a Gopher implementation soon made way for the obvious advantages of the emerging Web technology.

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 a Local HTTPd

Reasons for developing a local HTTP server are few but compelling:

• The WASD (then HFRD) Web implementation began mid-1994 (October 1997 note).

• It was prefered to support the hypertext environment on a VMS platform. This is currently (1995) the most widely used and accessable environment within WASD.

• Existing servers (and there are quite a few variations) are largely Unix based, although it is being supported (to a greater or lesses extent) across a wide range of platforms. Ports to VMS, if they exist, are 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 is not multi-threaded under VMS (i.e. cannot support concurrent clients). For example, a lengthy search may delay other clients for unacceptable periods.

  • Its 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 (DECthreads) server was evaluated via documentation mid-1994. (now in 1998 ... I am reticent to make further comment on now such a widely deployed package :^)

• HyperText Transport Protocol, in its current form, is relatively simple to implement to the level required to support intra-Divisional requirements.

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

• As of June 1997 the server and its 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.

• As of 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.

• As of July 2002 it continues to be refined and extended. A greater emphasis on "commercial" functionality has occured over the past couple of years.