NOTE: SOME FUNCTIONALITY EMPLOYS JAVASCRIPT

WASD Install and Update

For version 12.0 release of WASD VMS Web Services.

Published November 2021

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-2021 Mark G. Daniel

Apache License, Version 2.0
License

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

you may not use this software except in compliance with the License. You may obtain a copy of the License at

https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Mark.Daniel@wasd.vsm.com.au
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!
1.1…………………Using IA64-hosted X86 Cross-Complier?
1.2…………………Troubleshooting?
2.…………………Installation
2.1…………………Package UNZIP
2.2…………………Package Directory Structure
2.3…………………ODS-5 Volume
2.4…………………Accessible Volume
2.5…………………Disk Quota
2.6…………………VMS 6.n
2.7…………………SYSUAF and RIGHTSLIST
2.8…………………TCP/IP Infrastructure
2.9…………………INSTALL.COM Procedure
2.10…………………Quick-Check
2.11…………………Local Setup Suggestions
2.12…………………Reporting Problems
3.…………………Update
3.1…………………Package UNZIP
3.2…………………UPDATE.COM Procedure
3.3…………………Re-Linking
4.…………………Server Account and Environment
4.1…………………VMS Server Account
4.2…………………VMS Scripting Account
4.3…………………Account Support Files
4.4…………………Global Pages/Sections
4.5…………………Logical Names
4.5.1…………………WASD Name Table
4.6…………………Server Startup
5.…………………Other Ways to Deploy
5.1…………………Server Environments
5.1.1…………………Ad Hoc Server Wrapper
5.1.2…………………Formal Environments
5.1.3…………………Considerations
5.2…………………Multiple Installations
5.3…………………SELECT.COM Procedure
5.4…………………0̷BTAIN.COM Procedure
5.5…………………CLONE.COM Procedure
6.…………………Index
7.…………………Attribution and Acknowledgement


1.New to WASD? Start Here!

1.1Using IA64-hosted X86 Cross-Complier?
1.2Troubleshooting?
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).

    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.

1.1Using IA64-hosted X86 Cross-Complier?

Until a native X86 C compiler becomes available all WASD package and additional application builds must be done in two phases.

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

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

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

https://the.host.name:port /httpd/-/admin/report/WATCH

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

https://the.host.name:port /httpd/-/admin/

2.Installation

2.1Package UNZIP
2.2Package Directory Structure
2.3ODS-5 Volume
2.4Accessible Volume
2.5Disk Quota
2.6VMS 6.n
2.7SYSUAF and RIGHTSLIST
2.8TCP/IP Infrastructure
2.9INSTALL.COM Procedure
2.10Quick-Check
2.11Local Setup Suggestions
2.12Reporting Problems

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

$ UNZIP -v

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

$ UNZIP -z device:[dir]archive.ZIP

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

$ UNZIP -t device:[dir]archive.ZIP $ UNZIP -l device:[dir]archive.ZIP

The archive will have the structure:

KLAATU$ unzip -l dka100:[WASD]wasd1200.zip;1 Archive: DKA100:[WASD]wasd1200.zip;1 Copyright (C) 1996-2021 Mark G.Daniel Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. * FULL RELEASE of v12.0.0 (1 November 2021) ************************************************** *** CONTAINS SOURCE FILES, DOCUMENTATION, ETC. *** ************************************************** Package must be built using INSTALL or UPDATE as described below. * To install files: $ SET DEFAULT device:[000000] $ UNZIP device:[dir]WASD1200.ZIP * To build/link images use the appropriate one of: $ @device:[WASD_ROOT]INSTALL $ @WASD_ROOT:[000000]UPDATE * Contains build refinements to ease cross-compiling for x86-64 VMS. VMS file attributes saved ... use UnZip 5.2+ on OpenVMS Archive created 1-NOV-2021 Length Date Time Name -------- ---- ---- ---- 0 10-24-21 09:04 wasd_root/axp-bin/ 0 10-24-21 09:04 wasd_root/axp/ 0 10-24-21 09:04 wasd_root/cgi-bin/ 0 10-24-21 09:04 wasd_root/doc/ 0 10-24-21 09:04 wasd_root/example/ 0 10-24-21 09:04 wasd_root/exercise/ 2734 03-06-03 17:20 wasd_root/favicon.ico 8< snip 8< 40221 10-04-21 21:37 wasd_root/wasdoc/scripting/scripting012.html 18156 10-04-21 21:37 wasd_root/wasdoc/scripting/scripting013.html 442 09-21-20 12:13 wasd_root/x86_64-bin/readme.html 464 09-20-20 10:10 wasd_root/x86_64/readme.html -------- ------- 23868969 1009 files

2.1Package UNZIP

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.

$ SET DEFAULT device:[000000] $ UNZIP device:[dir]archive.ZIP
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 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.

$ UNZIP device:[dir]archive-AXP.ZIP $ UNZIP device:[dir]archive-IA64.ZIP $ UNZIP device:[dir]archive-X86.ZIP
Note

The WASD distribution and package organisation fully supports mixed-architecture clusters (AXP, Itanium and/or x86-64 in the one cluster) as one integrated installation.
WASD OpenSSL Archive

Building an SSL-capable version of the server is a common requirement. WASD SSL is discussed in detail in Transport Layer Security of WASD Features and Facilities. and if using the WASD SSL package it is also possible to install (or update) that package after UNZIPing the primary archive and optional object module(s). As noted in the above SSL section, the server can also be built against an existing VMS SSL product and an existing OpenSSL installation.

Note

The WASD OpenSSL kit is designed as an update to an existing WASD installation and so expects to be UNZIPed under the root directory. Note the use of the "-d" switch in the following example.

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

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

Directory Description
[AXP-BIN] Alpha executable script files
[AXP] Alpha build and utility area
[CGI-BIN] architecture-neutral script files
[EXAMPLE] package examples
[EXERCISE] package test files
[HTTP$NOBODY] scripting account default home area
[HTTP$SERVER] server account default home area
[IA64-BIN] Itanium executable script files
[IA64] Itanium build and utility area
[INSTALL] installation, update and security procedures
[LOCAL] site configuration files
[LOG] site access logs
[LOG_SERVER] server process (SYS$OUTPUT) logs
[RUNTIME] graphics, help files, etc.
[SCRATCH] working file space for scripts
[SCRIPT] example architecture-neutral scripts
[SRC] package source files
[STARTUP] package startup procedures
[WASDOC] package documentation
[X86_64-BIN] x86-86 executable script files
[X86_64] x86-64 build and utility area

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.

$ SHOW SECURITY /CLASS=VOLUME DKA100: ALPHASYS object of class VOLUME Owner: [1,1] Protection: (System: RWCD, Owner: RWCD, Group: RWCD, World: RWCD) Access Control List: <empty>

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

WARNING!

The WASD installation procedure does, and to a lesser degree the update procedure can, make additions and/or modifications to SYSUAF.DAT and RIGHTLIST.DAT, for default server and scripting accounts and to facilitate their access to the package directory tree.

Also, when the server image begins execution it may add an identifier, required for script process management, to RIGHTSLIST.DAT.

These behaviours must be considered in site environments where such changes are prohibited or closely controlled.


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:

$ SET DEFAULT device:[WASD_ROOT] $ @INSTALL

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

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.

X86VMS$ @wasd_root:[install]demo Copyright (C) 1996-2021 Mark G.Daniel ------------------------------------- Licensed under the Apache License, Version 2.0 (the "License"); you may not use this software except in compliance with the License. Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. http://www.apache.org/licenses/LICENSE-2.0 ******************************* * WASD PACKAGE DEMONSTRATOR * ******************************* When finished using demonstrator abort server execution using control-Y (a subprocess will be spawned to preserve current process environment) Use a browser to access either of the "%HTTPD-I-SERVICE"s when the server starts. (There will be one for a standard service and another for SSL.) The server will be running in promiscuous mode! Any username with the password specified below can be used for authentication. Enter a string to use as a password when later prompted by your browser. Password (for demo authentication)? []: testing %DCL-S-SPAWNED, process SYSTEM_32419 spawned %DCL-S-ATTACHED, terminal now attached to process SYSTEM_32419 %HTTPD-I-SOFTWAREID, HTTPd-WASD/12.0.0 OpenVMS/X86 SSL WASD VMS Web Services, Copyright (C) 1996-2021 Mark G.Daniel. Licensed under the Apache License, Version 2.0 (the "License"). Software under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See http://www.apache.org/licenses/LICENSE-2.0 %HTTPD-I-IMAGE, HTTPD_SSL 12.0.0 31-OCT-2021 07:38:27.62 DKA100:[wasd_root.][x86_64]HTTPD_SSL.EXE;1 %HTTPD-I-STARTUP, 01-NOV-2021 11:47:05 %HTTPD-I-ALIGN, start collecting alignment faults (64kB,128,0xFFFFFFFF) %HTTPD-I-WASD_ROOT, DKA100:[WASD_ROOT] %HTTPD-I-ENVIRONMENT, 0 %HTTPD-I-SYSTEM, innotek GmbH VirtualBox VMS V9.1-A %HTTPD-W-SYSPRV, operating with implicit SYSPRV (UIC group 1) %HTTPD-I-TCPIP, HP TCPIP$IPC_SHR X6.0-12 (31-AUG-2021 20:01:12.49) %HTTPD-I-MODE, INTERACTIVE %HTTPD-I-ODS5, supported by x86-64 VMS V9.1-A %HTTPD-I-ODS, directory parser enabled %HTTPD-I-GMT, +10:30 %HTTPD-I-INSTANCE, supervisor %HTTPD-W-GZIP, shareable image not found %HTTPD-I-INSTANCE, 1 process %HTTPD-I-SSL, OpenSSL 1.1.1k 25 Mar 2021 (0x101010BF) -SSL-I-PROTOCOL, TLSv1,TLSv1.1,TLSv1.2,TLSv1.3 -SSL-I-OPTIONS, 0x80410854 -SSL-I-SNI, Server Name Indication enabled -SSL-W-DH, no ephemeral DH param %HTTPD-I-HTTP2, enabled %HTTPD-W-HTTP2, network read buffer size increased to 16384 bytes %HTTPD-I-VM, HTTP/2 zone initialised %HTTPD-I-INSTANCE, process name WASD:7080 %HTTPD-I-WEBDAV, disabled %HTTPD-W-AUTH, 1 informational, 1 warning, 0 errors at load 1.w PROMISCUOUS authenticating any username with specified password! 2.i Cache for 32 records of 768 bytes in local storage of 49 page(let)s %HTTPD-W-MAP, 1 informational, 0 warning, 0 errors at load 1.i ODS-5 processing enabled %HTTPD-I-PROXYVERIFY, for 32 records in local storage of 14 page(let)s %HTTPD-I-SCRIPTING, as HTTP$NOBODY %HTTPD-I-VM, request zone initialised %HTTPD-I-DCL, subprocess scripting %HTTPD-I-DCL, with HTTP/2 enabled SYS$OUTPUT mailbox might be more efficient at 16375 bytes %HTTPD-I-VM, cache zone initialised %HTTPD-I-ACTIVITY, created global section of 1312 page(let)s %HTTPD-I-SERVICE, http://x86vms.lan:7080 %HTTPD-I-SERVICE, https://x86vms.lan:7443 %HTTPD-I-SSL, x86vms.lan:7443 Generate x86vms.lan 2048 bit private key: ...........................................+++++ ...........................................+++++ %HTTPD-I-DEMO, demonstration mode 1.i subprocess scripting 2.i promiscuous authentication 3.i directory access control files ignored 4.i [DirAccess] enabled 5.i [DirMetaInfo] enabled 6.i [DirWildcard] enabled 7.i [Logging] disabled 8.i [ReportBasicOnly] disabled 9.i [ReportMetaInfo] enabled %HTTPD-I-BEGIN, 01-NOV-2021 11:47:09, WASD:7080 accepting requests

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

Note

The WASD server which is started by the [INSTALL]DEMO.COM procedure does not have the full environment setup at that time. It is deliberately limited to the single process context. For instance, do not try to execute the command-line directives described in this document.

2.11Local Setup Suggestions

Package updates will never contain anything in these directories:

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 Mark.Daniel@wasd.vsm.com.au or if a suscriber, to info-WASD@vsm.com.au.


3.Update

3.1Package UNZIP
3.2UPDATE.COM Procedure
3.3Re-Linking
Before Updating

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.

$ UNZIP -z device:[dir]archive.ZIP

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

$ UNZIP -t device:[dir]archive.ZIP $ UNZIP -l device:[dir]archive.ZIP

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.

$ SHOW LOGICAL WASD_ROOT "WASD_ROOT" = "DKA100:[WASD_ROOT.]" (LNM$SYSTEM_TABLE) $ SET DEFAULT DKA100:[000000] $ UNZIP device:[dir]archive.ZIP
Updating From v9.3 or Earlier

Before UNZIPing the v11 package and when updating an existing v9.3 or earlier installation the root directory must be renamed from HT_ROOT.DIR to WASD_ROOT.DIR. The v10 and later packages use [WASD_ROOT] as the top-level directory in line with other naming schema changes employing "WASD". Remember to modify local startup procedures in-line with this new top-level directory name. Also note that the v11 package is not suitable for updating from existing v8.0 or earlier installation.
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 architecture must be UNZIPed.

WASD OpenSSL Archive

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

Note

The WASD OpenSSL kit is designed as an update to an existing WASD installation and so expects to be UNZIPed under the root directory. Note the use of the "-d" switch in the following example.
$ UNZIP -d [.WASD_ROOT] device:[dir]OPENSSLWASDnnn-arch.ZIP
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!

$ HTTPD/DO=EXIT/ALL

After UNZIPing the updated package do the following:

$ SET DEFAULT WASD_ROOT:[000000] $ @UPDATE

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

$ SET DEFAULT WASD_ROOT:[000000] $ @UPDATE CLEANUP $ PURGE [...]

3.3Re-Linking

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

%DCL-W-ACTIMAGE, error activating image WHATEVER -CLI-E-IMGNAME, image file DKA0:[SYS0.SYSCOMMON.][SYSLIB]WHATEVER_SHR.EXE -SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

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.


4.Server Account and Environment

4.1VMS Server Account
4.2VMS Scripting Account
4.3Account Support Files
4.4Global Pages/Sections
4.5Logical Names
4.5.1WASD Name Table
4.6Server Startup

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.

Process Quotas!

Server process quotas must be sufficient to support the expected traffic load. BYTLM in particular, and then BIOLM, DIOL, FILLM and PGFLQUO, are all considerations.

Symptoms of insufficient process quotas include:

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.

TCP/IP Agent Resources!

On an associated topic; some TCP/IP agents require particular internal resources to be adjusted against given loads (e.g. buffer space allocations). Symptoms of resource starvation may be TCP/IP services, including WASD, "pausing" for significant periods or associated processes entering miscellaneous wait states, etc., during processing. Please ensure such TCP/IP agents are appropriately dimensioned for expected loads.

Later versions of TCP/IP Services for OpenVMS seem to have large default values for socket send and receive buffers. MultiNet and TCPware are reported to improve transfer of large responses by increasing low default values for send buffer size. The WASD global configuration directives [SocketSizeRcvBuf] and [SocketSizeSndBuf] allow default values to be adjusted. WATCH can be used to report network connection buffer values.


4.1VMS Server Account

The following provides a guide to the account.

Username: HTTP$SERVER Owner: WASD Server Account: HTTPD UIC: [077,001] ([HTTP$SERVER]) CLI: DCL Tables: DCLTABLES Default: WASD_ROOT:[HTTP$SERVER] LGICMD: LOGIN Flags: Restricted DisNewMail Primary days: Mon Tue Wed Thu Fri Secondary days: Sat Sun Primary 000000000011111111112222 Secondary 000000000011111111112222 Day Hours 012345678901234567890123 Day Hours 012345678901234567890123 Network: ##### Full access ###### ##### Full access ###### Batch: ##### Full access ###### ##### Full access ###### Local: ----- No access ------ ----- No access ------ Dialup: ----- No access ------ ----- No access ------ Remote: ----- No access ------ ----- No access ------ Expiration: (none) Pwdminimum: 6 Login Fails: 0 Pwdlifetime: 90 00:00 Pwdchange: (pre-expired) Last Login: (none) (interactive), 11-MAY-1995 08:44 (non-interactive) Maxjobs: 0 Fillm: 300 Bytlm: 5000000 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 2048 JTquota: 1024 Prclm: 100 DIOlm: 1024 WSdef: 1000 Prio: 4 ASTlm: 2000 WSquo: 5000 Queprio: 0 TQElm: 100 WSextent: 20000 CPU: (none) Enqlm: 256 Pgflquo: 500000 Authorized Privileges: NETMBX TMPMBX Default Privileges: NETMBX TMPMBX

4.2VMS Scripting Account

The following provides a guide to the account.

Username: HTTP$NOBODY Owner: WASD Scripting Account: HTTPD UIC: [076,001] ([HTTP$NOBODY]) CLI: DCL Tables: DCLTABLES Default: WASD_ROOT:[HTTP$NOBODY] LGICMD: LOGIN Flags: Restricted DisNewMail Primary days: Mon Tue Wed Thu Fri Secondary days: Sat Sun Primary 000000000011111111112222 Secondary 000000000011111111112222 Day Hours 012345678901234567890123 Day Hours 012345678901234567890123 Network: ##### Full access ###### ##### Full access ###### Batch: ##### Full access ###### ##### Full access ###### Local: ----- No access ------ ----- No access ------ Dialup: ----- No access ------ ----- No access ------ Remote: ----- No access ------ ----- No access ------ Expiration: (none) Pwdminimum: 6 Login Fails: 0 Pwdlifetime: 90 00:00 Pwdchange: (pre-expired) Last Login: (none) (interactive), 11-MAY-1995 08:44 (non-interactive) Maxjobs: 0 Fillm: 300 Bytlm: 500000 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 2048 JTquota: 1024 Prclm: 100 DIOlm: 1024 WSdef: 1000 Prio: 4 ASTlm: 2000 WSquo: 5000 Queprio: 0 TQElm: 100 WSextent: 20000 CPU: (none) Enqlm: 256 Pgflquo: 500000 Authorized Privileges: NETMBX TMPMBX Default Privileges: NETMBX TMPMBX

4.3Account Support Files

Note

Support procedures often change between versions. It is always advisable to check the versions documentation before installing or updating. Examples may be found in WASD_ROOT:[EXAMPLE]
HTTPd Executables

Two server executables can be built by the package.

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:

$ INSTALL = "$SYS$SYSTEM:INSTALL/COMMAND_MODE" $ INSTALL ADD WASD_EXE:HTTPD.EXE - /PRIVILEGE=(ALTPRI,CMKRNL,DETACH,OPER,PRMGBL,PRMMBX,PSWAPM,- SECURITY,SYSGBL,SYSLCK,SYSNAM,SYSPRV,WORLD)
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.

$ @DKA0:[WASD_ROOT.STARTUP]STARTUP WASD_DECNET=1 WASD_SSL=1 - WASD_SSL_CERTIFICATE="WASD_ROOT:[LOCAL]ALPHA.PEM"

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

$ WASD_DECNET = 1 $ WASD_SSL = 1 $ WASD_SSL_CERTIFICATE = "WASD_ROOT:[LOCAL]ALPHA.PEM" $ @DKA0:[WASD_ROOT.STARTUP]STARTUP
$ @DKA0:[WASD_ROOT.STARTUP]STARTUP WASD_DECNET=1 WASD_BATCH_QUEUE=THIS$BATCH

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

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.
WASD_ROOT:[EXAMPLE]STARTUP_SERVER.COM

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.

$ DEFINE /SYSTEM /EXECUTIVE WASD_STARTUP_SERVER "/SYSUAF=ID" $ @DKA0:[WASD_ROOT.STARTUP]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).

$ WASD_DECNET = 1 $ WASD_SSL = 1 $ WASD_SSL_CERTIFICATE = "WASD_ROOT:[LOCAL]ALPHA.PEM" $ WASD_STARTUP = "/SYSUAF=ID" $ @DKA0:[WASD_ROOT.STARTUP]STARTUP

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

$ DEFINE /SYSTEM /EXECUTIVE WASD_STARTUP_SERVER "/SYSUAF=(SSL,ID)" $ HTTPD /DO=RESTART=NOW

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
Item Description Usage
Accounting Accumulates various data provided to the Server Administration Statistics report and the HTTPMON utility required
Activity Provides data to the Server Administration Activity Report graph required
Authentication When multiple WASD Instances are configured provides a shared authentication cache optional
Proxy Verification When multiple WASD Instances are configured provides an shared proxy verification cache optional
SSL Session Cache When SSL is used and multiple WASD Instances are configured provides a shared SSL session cache optional

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
Logical Name Table Description
CGI-BIN WASD (Hyphen) System logical defining a search list with the architecture-specific executable directory first, local script directory second, then the common script directory, as a concealed device.
CGI_BIN WASD (Underscore) Directory containing architecture-neutral script files.
CGI_EXE WASD Directory containing architecture-specific script executables.
HT_EXE WASD Pre-v10.0 backward compatibility for WASD_EXE.
HT_LOGS WASD Pre-v10.0 backward compatibility for WASD_LOG.
HT_ROOT SYSTEM Pre-v10.0 backward compatibility for WASD_ROOT.
HT_SCRATCH WASD Pre-v10.0 backward compatibility for WASD_SCRATCH.
WASD_AXP WASD Directory containing Alpha executable images (WASD_ROOT:[AXP]).
WASD_AUTH WASD Directory containing authentication/authorization databases (files, (WASD_ROOT:[LOCAL])).
WASD_CGI_AXP WASD Directory containing Alpha script executables (WASD_ROOT:[AXP-BIN]).
WASD_CGI_IA64 WASD Directory containing Itanium script executables (WASD_ROOT:[IA64-BIN]).
WASD_CGI_X86_64 WASD Directory containing x86-64 script executables (WASD_ROOT:[X86_64-BIN]).
WASD_CONFIG WASD Location of the configuration files. Can be defined as a search list.
WASD_CONFIG_AUTH WASD Location of the authentication/authorization configuration file.
WASD_CONFIG_GLOBAL WASD Location of the configuration file.
WASD_CONFIG_MAP WASD Location of the mapping rule file.
WASD_CONFIG_MSG WASD Location of the message file.
WASD_CONFIG_SERVICE WASD Location of the optional service (virtual host) configuration file.
WASD_DECNET_CGI_OBJECT SYSTEM Locates the supporting DCL procedure. DECnet objects are system-global.
WASD_DECNET_OSU_OBJECT SYSTEM Locates the supporting DCL procedure. DECnet objects are system-global.
WASD_EXE WASD Directory containing the executable images.
WASD_FILE_DEV[n] SYSTEM Locates the DCL procedure that will integrate the specified environment's logical name table into the processes' LNM$FILE_DEV (see above).
WASD_GMT WASD Offset from GMT (e.g. "+10:30", "-01:15") For systems supporting DTSS (e.g. DECnet-Plus) this logical may be left undefined, with server time being calculated using the SYS$TIMEZONE_DIFFERENTIAL logical.
WASD_IA64 WASD Directory containing Itanium executable images.
WASD_LOG WASD If logging is enabled and no log file name specified on the command line, this logical must be defined to locate the file. When a logging period is in use this logical need only contain the directory used to store the logs.
WASD_LOGS WASD Optional definition, for convenient log file specification.
WASD_ROOT SYSTEM Location of WASD Web Services directory tree, as a concealed device.
WASD_SCRATCH WASD Location of an optional directory that scripts can use for temporary storage. Must be read+write+delete accessible to the server account. The WASD_CONFIG_GLOBAL [DclCleanupScratchMinutesMax] directive controls whether automatic cleanup scans of this area delete any files that are older than [DclCleanupScratchMinutesOld].
WASD_SITELOG WASD Location of the optional plain-text site log file.
WASD_SSL_CAFILE WASD When using the SSL executable this logical locates the optional Certificate Authority list file.
WASD_SSL_CERT WASD When using the SSL executable this logical locates the default certificate.
WASD_SERVER_LOGS WASD Location of the server process logs.
WASD_STARTUP_SERVER WASD Used to pass parameters to the server image startup command line.
WASD_X86_64 WASD Directory containing x86-64 executable images.
Pre-v10 Logical Names

The pre-v10.0.0 logical names (e.g. HTTPD$MAP) are deprecated and will be obsoleted in a future version. The server process log issues warnings such as HTTPD-W-DEPRECATED, change HTTPD$MAP to WASD_CONFIG_MAP (soon!) for any it finds during startup.

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.

$ SHOW LOGICAL WASD_TABLE/TABLE=LNM$SYSTEM_DIRECTORY "WASD_TABLE" [table] = "" (LNM$SYSTEM_DIRECTORY)

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

$ SHOW LOGICAL CGI*,HT*,WASD*,WWW* (LNM$PROCESS_TABLE) (LNM$JOB_81E3D580) (WASD_TABLE) "CGI-BIN" = "DKA0:[WASD_ROOT.CGI-BIN.]" = "DKA0:[WASD_ROOT.AXP-BIN.]" "CGI_BIN" = "WASD_ROOT:[CGI-BIN]" "CGI_EXE" = "WASD_ROOT:[AXP-BIN]" "HTBIN" = "CGI-BIN:[000000]" "HT_CACHE_ROOT" = "DKA0:[HT_CACHE.]" "HT_EXE" = "WASD_ROOT:[AXP]" "HT_LOGS" = "WASD_ROOT:[LOG]" "HT_SCRATCH" = "WASD_ROOT:[SCRATCH]" "WASD_AUTH" = "WASD_ROOT:[LOCAL]" "WASD_AXP" = "WASD_ROOT:[AXP]" "WASD_CACHE_ROOT" = "DKA0:[HT_CACHE.]" "WASD_CGILIBSHR32" = "CGI_EXE:CGILIBSHR32.EXE" "WASD_CGI_AXP" = "WASD_ROOT:[AXP-BIN]" "WASD_CGI_BIN" = "WASD_ROOT:[CGI-BIN]" "WASD_CGI_EXE" = "WASD_ROOT:[AXP-BIN]" "WASD_CGI_IA64" = "WASD_ROOT:[IA64-BIN]" "WASD_CGI_X86_64" = "WASD_ROOT:[X86_64-BIN]" "WASD_CONFIG" = "WASD_ROOT:[LOCAL]" "WASD_CONFIG_AUTH" = "WASD_CONFIG:HTTPD$AUTH.CONF" "WASD_CONFIG_GLOBAL" = "WASD_CONFIG:HTTPD$CONFIG.CONF" "WASD_CONFIG_MAP" = "WASD_CONFIG:HTTPD$MAP.CONF" "WASD_CONFIG_MSG" = "WASD_CONFIG:HTTPD$MSG.CONF" "WASD_CONFIG_SERVICE" = "WASD_CONFIG:HTTPD$SERVICE.CONF" "WASD_EXE" = "WASD_ROOT:[AXP]" "WASD_HTTPD_EXE" = "WASD_EXE:HTTPD_SSL.EXE" "WASD_IA64" = "WASD_ROOT:[IA64]" "WASD_JAVA" = "WASD_ROOT:[JAVA]" "WASD_LOCAL" = "WASD_ROOT:[LOCAL]" "WASD_LOGS" = "WASD_ROOT:[LOG]" "WASD_SCRATCH" = "WASD_ROOT:[SCRATCH]" "WASD_SCRIPT" = "WASD_ROOT:[SCRIPT]" "WASD_SCRIPT_LOCAL" = "WASD_ROOT:[SCRIPT_LOCAL]" "WASD_SERVER_LOGS" = "WASD_ROOT:[LOG_SERVER]" "WASD_SSL_CAFILE" = "WASD_CONFIG:CA-BUNDLE_CRT.TXT" "WASD_SSL_CERT" = "WASD_CONFIG:HTTPD.PEM" "WASD_STARTUP" = "WASD_ROOT:[STARTUP]" "WASD_STARTUP_SERVER" = "/SYSUAF=(ID,SSL)/PERSONA=RELAXED/PROFILE" "WASD_X86_64" = "WASD_ROOT:[X86_64]" "WWW_ROOT" = "DKA0:[WASD_ROOT.SRC.OSU]" "WWW_SCRIPT_MAX_REUSE" = "999" (LNM$GROUP_000001) (LNM$SYSTEM_TABLE) "HT_ROOT" = "DKA0:[WASD_ROOT.]" "WASD_DECNET_CGI_OBJECT" = "DKA0:[WASD_ROOT.CGI-BIN]CGIWASD.COM" "WASD_DECNET_OSU_OBJECT" = "DKA0:[WASD_ROOT.CGI-BIN]WWWEXEC.COM" "WASD_FILE_DEV" = "DKA0:[WASD_ROOT]WASD_FILE_DEV.COM" "WASD_ROOT" = "DKA0:[WASD_ROOT.]" (LNM$SYSCLUSTER_TABLE) (DECW$LOGICAL_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

$ @WASD_FILE_DEV
at the command-line or in their LOGIN.COM to have it done for their interactive session(s). This procedure location is variable within the file-system and needs to be located and accessed without initially knowing that location.

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
Parameter/Qualifier Description
/ALL[=integer] Has two roles. When starting a server up assigns that server to a specific, non-default WASD environment (see /ENVIRONMENT) When using the server control /DO= using /ALL specifies to do the action to all servers in that particular environment.
/AUTHORIZATION=.. Control authentication and authorisation behaviour.
See Authentication Policy of WASD Features and Facilities.
/CGI_PREFIX= The prefix to the CGI symbol names created for a script (defaults to "WWW_").
See WASD Web Services - Scripting
/CLUSTER Apply control /DO= to all instances in a cluster (default is to current node instance(s) only).
/DETACH= This qualifier allows a DCL procedure to be specified as input to a directly detached process (in conjunction with /USER).
/DO= Command to be performed by the executing server.
/ENVIRONMENT= Integer indicating in which environment this server is executing
/GBLSEC=DELETE Allows a monitor-associated permanent global section to be explicitly deleted. When a server starts it creates system-accessible, permanent global sections in which to store accounting and request data. As this is permanent it would be possible for a site, perhaps experimenting with servers over a range of ports, to consume significant amounts of global pages and sections. This qualifier allows such sections to be deleted.
/GBLSEC=NOPERM Disables the creation of permanent global sections. They are automatically deleted when the server image exits.
/[NO]LOG[=name] Either disables logging (overrides configuration directive), or enables logging and optionally specifies the log file name (also see section 4.5 Logical Names, logging is disabled by default). If the file specification is "SYS$OUTPUT" the server issues log entries to <stdout>, allowing user-defined log formats to be easily checked and refined.
/NETWORK Run the server and any scripting processes as NETWORK mode rather than the default detached OTHER mode.
/NOTE=string Annotate the server process log with the specified string. Intended to assist auditing server events such as restarts, maaping reloads and the like.
/OUTPUT=filename Server image <stdout> is redirected to the specified file name. Useful when employing the /SYSPLUS report generator.
/PERSONA[=..] Enables and controls detached process scripting.
See Introduction of WASD Scripting Environment.
/PRIORITY= Server process priority (default is 4).
/[NO]PROFILE Allows SYSUAF-authenticated username security profiles to be used for file access.
/PROMISCUOUS[=password] Server will accept any authentication username/password pair (used for testing, demonstrations, etc.)
/PROXY=string Allows proxy maintainance activities to be executed from the command line (e.g. from batch jobs, etc.).
/SCRIPT=AS=username Specifies the username of the default scripting account.
/SERVICE= Comma-separated, list of server services (overrides the [Service] configuration parameter).
/SOFTWARE= An arbitrary string that can be used to override the server software identification (i.e. "HTTPd-WASD/10.4.0 OpenVMS/AXP SSL").
/[NO]SSL[=..] Controls Secure Sockets Layer protocol behaviour.
See Transport Layer Security of WASD Features and Facilities.
/SYSPLUS Displays CLI equivalent System Report PLUS data. Available for circumstances where the server is unresponsive but an interactive session is available. Requires a 132 character width terminal session.
See System Report PLUS of WASD Features and Facilities.
/[NO]SYSUAF[=..] Controls VMS (SYSUAF) authentication/authorisation behaviour.
See SYSUAF-Authenticated Users of WASD Features and Facilities.
/USER=username For VMS 6.2 and later this qualifier allows the /DETACH qualifier to directly create a detached process executing as the specified username.
/VALBLK[=16|64] For server to (try) to use either pre-VMS V8.2 16 byte lock value block or the VMS V8.2 and later 64 byte lock value block.
/VERSION Displays the executable's version string and the copyright notice.
/[NO]WATCH[=..] Controls the use of the WATCH reporting facility.
See WATCH Facility of WASD Features and Facilities.

5.Other Ways to Deploy

5.1Server Environments
5.1.1Ad Hoc Server Wrapper
5.1.2Formal Environments
5.1.3Considerations
5.2Multiple Installations
5.3SELECT.COM Procedure
5.40̷BTAIN.COM Procedure
5.5CLONE.COM Procedure

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.

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

This is a DCL procedure that allows virtually any WASD release HTTP server to be executed in a detached process, either by itself or concurrently with a full release or other ad hoc detached server. The server image and associated configuration files used by this process can be specified within the procedure allowing completely independent versions and environments to be fully supported.

Full usage instructions may be found in the example procedure(s) in WASD_ROOT:[EXAMPLE]*ADHOC*.COM

Two versions are provided, one for pre-v10 and one for post-v10 (due to changes in logical naming schema).

5.1.2Formal Environments

Although the basic infrastructure for supporting multiple environments (i.e. the 0..15 environment number) has been in place since version 8, formal support in server CLI qualifiers and DCL procedures has only been available since version 10. To support version 9 or earlier environments the 5.1.1 Ad Hoc Server Wrapper must be used.

WASD version 10 startup and other run-time procedures have been modified to support running multiple WASD environments simply from independent WASD file-system trees. The standard STARTUP.COM procedure accepts the WASD_ENV parameter to specify which environment (1..15) the server should execute within (primary/default is 1). The procedure then derives the WASD_ROOT logical name from the location of the startup procedure.

For example:

$! start current release $ WASD_STARTUP = "/SYSUAF=(ID,SSL)/PERSONA" $ @DKA0:[WASD_ROOT.STARTUP]STARTUP.COM $! start previous release in environment 2 $ WASD_ENV = 2 $ @DKA0:[WASD_ROOT_MINUS1.STARTUP]STARTUP.COM

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

$ @WASD_FILE_DEVn]
where n can be a non-primary environment number (see 4.5 Logical Names).

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

Pid Process Name State Pri I/O CPU Page flts Pages 00000101 SWAPPER HIB 16 0 0 00:00:11.98 0 0 … 00000111 ACME_SERVER HIB 10 6247 0 00:00:12.63 540 611 M 00000112 QUEUE_MANAGER HIB 10 328 0 00:00:00.18 136 175 00000122 TCPIP$INETACP HIB 10 1249419 0 00:07:33.95 401 326 00000123 TCPIP$ROUTED LEF 6 3495839 0 00:01:15.49 166 165 S … 00000468 WASD:80 HIB 6 132924 0 00:01:29.26 17868 2856 0000046D 2WASD:2280 HIB 6 129344 0 00:01:29.26 17712 2840 0000049D WASD:80-8 LEF 4 4449 0 00:00:00.67 934 194 00000503 2WASD:2280-2 LEF 4 565 0 00:00:00.28 732 102 …
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.

5.2Multiple 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:

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

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.

$ SET DEFAULT WASD_ROOT:[INSTALL] $ @SELECT DKA100:[WASD]WASD1150.ZIP WASD VMS Web Services, Copyright (C) 1996-2020 Mark G.Daniel. This package (all associated programs), comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under the conditions of the GNU GENERAL PUBLIC LICENSE, version 3, or any later version. http://www.gnu.org/licenses/gpl.txt ************************************* * SELECTIVELY UPDATE FROM ARCHIVE * ************************************* This procedure provides a site UPDATE using a full archive as the source. It examines the currently installed package to determine the relationship between the site and the archive. It then selectively extracts required files to bring the site up to revision. It can be used with full source archives as well as the optional object module archives. Each full archive is released with an increment in at least the tweak-level digit in the version string (<major>.<minor>.<tweak> e.g. "11.0.0") so this is used to determine the base-level installation of the current site. If for some reason this is not a standard site then do not use this procedure. Continue? [NO]: y *************************** * CHECK CURRENT VERSION * *************************** This selective update is to 11.5.0 This site has been determined to be 11.4.0 If this is not accurate then do not continue! ************************ * UPDATE FROM 11.4.n * * -or- 11.3.n * ************************ DKA100:[000000]WASD_ROOT.DIR;1 13-APR-2020 01:14:42.25 DKA100:[WASD]WASD1150.ZIP;1 9-JUL-2020 15:53:47.19 Continue? [NO]:

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:

$ SET DEFAULT DKA200:[000000] $ @WASD_ROOT:[INSTALL]0BTAIN DKA100:[WASD]WASD1150.ZIP WASD VMS Web Services, Copyright (C) 1996-2020 Mark G.Daniel. This package (all associated programs), comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under the conditions of the GNU GENERAL PUBLIC LICENSE, version 3, or any later version. http://www.gnu.org/licenses/gpl.txt *********************************** * WASD VMS Web Services v11.5.0 * *********************************** This DCL procedure allows elements of the above version of the WASD package to be extracted and installed/updated in a selective manner. It does require some knowledge of the WASD package and sometimes significant manual intervention. It is intended to allow a site to tailor the WASD content of the installation. Press RETURN to continue: The WASD_ROOT directory is always assumed to be a subdirectory of the current directory and is always created if not already existing. Always perform @0BTAIN from the parent of the (desired) [.WASD_ROOT] even when updating. There is currently no [.WASD_ROOT] in the current directory. Any further action will result in the creation of one. Continue? [NO]: y The selection can be made by specifying one of the listed elements, or by archive path. An overview will be presented and continuing with the option can be declined before continuing. If declined an option to display what would have been extracted is available. If an object module archive is present along with the primary archive the relevant modules are also extracted. 1. CORE extracts build, server, monitor, documentation 2. INSTALL extracts install environment 3. SERVER extracts server code 4. WASDOC extracts documentation and wasDOC code 5. SCRIPTS extracts essential scripts 6. path archive path (e.g. "wasd_root/src/httpd/*") 0. exit Number or string? [0]:

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

$ SET DEFAULT parent_device:[parent_directory] $ UNZIP -jl location:archive.ZIP "*/0btain.com" !(just to check) $ UNZIP -j location:archive.ZIP "*/0btain.com" $ @[]0BTAIN.COM

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

**************************************************************** * - IGNORE THE FOLLOWING - * * %RMS-E-FNF, file not found * * %RMS-F-ISI, invalid internal stream identifier (ISI) value * ****************************************************************
which can be safely ignored (the procedure deletes itself from the extracted-to directory which results in the DCL interpreter reporting the disappearance of the file).

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:

$ @WASD_ROOT:[INSTALL]CLONE WASD VMS Web Services, Copyright (C) 1996-2020 Mark G.Daniel. This package (all associated programs), comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under the conditions of the GNU GENERAL PUBLIC LICENSE, version 3, or any later version. http://www.gnu.org/licenses/gpl.txt *********************** * CLONE THE PACKAGE * *********************** This utility creates a separate DCL procedure containing ZIP commands to archive specified portions of the current system's WASD_ROOT:[000000] tree. That procedure can then be executed to create an archive which may then be UNZIPed on any other system(s) to create a copy of the original. In this way multiple WASD packages can be deployed without going through the full installation process and using the original as a working template. Some portions of the package are essential to any working installation. These are always archived. Others are prompted for and commands to archive those are only added to the procedure if required. Multiple such procedures may be created by specifying unique archive procedure names. Create a cloning procedure? [NO]: y ************************ * DCL PROCEDURE NAME * ************************ If multiple cloning procedures are required enter a specific file name, otherwise use the default. DCL procedure? [CLONE_WASD.COM]: ****************** * ARCHITECTURE * ****************** Executables for multiple architectures ([AXP], [IA64], [X86_64]) detected. Add [AXP] executables? [NO]: y Add [IA64] executables? [NO]: n Add [X86_64] executables? [NO]: n Continue? [NO]: y *************** * ESSENTIAL * *************** These directories and files are essential and always included: [AXP] HTTPD.EXE HTTPD_SSL.EXE HTTPDMON.EXE SECHAN.EXE [AXP-BIN] Alpha script executables [CGI-BIN] architecture-neutral script files [HTTP$NOBODY] server account home [HTTP$SERVER] scripting account home [INSTALL] installation, update and security procedures [LOCAL] local configuration files [LOG] access logs [LOG_SERVER] server process logs [RUNTIME.HTTPD] server runtime files (directory listing graphics, etc) [SCRATCH] scripting scratch space [STARTUP] startup procedures (STARTUP*.COM) Most directories retain some files (e.g. .WWW_HIDDEN, READMEs) but are only optionally populated with other files as requested. Continue? [NO]: y ******************* * CONFIGURATION * ******************* Files from [LOCAL]*.conf (e.g. HTTPD$CONFIG, HTTPD$MAP, etc.) Add? [NO]: y ************* * SCRIPTS * ************* Files from [CGI-BIN] and executables from [AXP-BIN] and/or [IA64-BIN] and/or [X86_64-BIN]. Note that this adds ALL files from these directories. Of course you can manually edit the resultant procedure to remove unwanted items. This also adds the rest of the files from the [RUNTIME...] directory tree (remembering that [RUNTIME.HTTPD] is included with the essential files). Add? [NO]: n ******************* * DOCUMENTATION * ******************* Files from [WASDDOC...]*.* Add? [NO]: y ************************ * EXAMPLE & EXERCISE * ************************ Files from [EXAMPLE]*.* and [EXERCISE]*.*. Add? [NO]: n ************ * SOURCE * ************ Files from [SRC...]*.*. Add? [NO]: n ******************************** * CREATING ARCHIVE PROCEDURE * ******************************** Created WASD_ROOT:[install]CLONE_WASD.COM;1 The contents of this procedure can be manually modified and/or other command lines added to archive or remove specific areas and/or files. ********************* * C O M P L E T E * *********************

6.Index

A‘Abstract’ in WASD Install and Update
 2.4 Accessible Volume
 4.3 Account Support Files
 5.1.1 Ad Hoc Server Wrapper
 ‘Apache License, Version 2.0’ in WASD Install and Update
 7. Attribution and Acknowledgement
B‘Before Updating’ in 3. Update
 ‘Bjöern Höehrmann’ in 7. Attribution and Acknowledgement
C‘Clark Cooper, et.al.’ in 7. Attribution and Acknowledgement
 ‘Cleaning Up’ in 5.1.3 Considerations
 5.5 CLONE.COM Procedure
 5.1.3 Considerations
D‘DCL Procedure 0̷BTAIN.COM’ in 5.4 0̷BTAIN.COM Procedure
 DCL Procedure CLONE.COM
 DCL procedure INSTALL.COM
 DCL Procedure SELECT.COM
 DCL Procedure STARTUP.COM
 DCL Procedure STARTUP_LOCAL.COM
 DCL Procedure STARTUP_SERVER.COM
 DCL Procedure UPDATE.COM
 2.5 Disk Quota
F5.1.2 Formal Environments
 ‘Free Software Foundation’ in 7. Attribution and Acknowledgement
G4.4 Global Pages/Sections
 ‘Global Sections’ in 4.4 Global Pages/Sections
H‘HTTPd Executables’ in 4.3 Account Support Files
I6. Index
 2.9 INSTALL.COM Procedure
 2. Installation
L‘License’ in WASD Install and Update
 ‘Licensed under the Apache License, Version 2.0’ in 7. Attribution and Acknowledgement
 2.11 Local Setup Suggestions
 4.5 Logical Names
M5.2 Multiple Installations
N1. New to WASD? Start Here!
 ‘None of the following licensing appears incompatible with the Apache License’ in 7. Attribution and Acknowledgement
 ‘Note’ in 2.1 Package UNZIP
 ‘Note’ in 2.1 Package UNZIP
 ‘Note’ in 2.10 Quick-Check
 ‘Note’ in 3.1 Package UNZIP
 ‘Note’ in 4.3 Account Support Files
OOBTAIN.COM Procedure
 2.3 ODS-5 Volume
 ‘Ohio State University’ in 7. Attribution and Acknowledgement
 ‘Online Search’ in WASD Install and Update
 ‘OpenSSL Project’ in 7. Attribution and Acknowledgement
 5. Other Ways to Deploy
P2.2 Package Directory Structure
 ‘Package Logical Names’ in 4.5 Logical Names
 2.1 Package UNZIP
 3.1 Package UNZIP
 ‘Paul E. Jones’ in 7. Attribution and Acknowledgement
 ‘Pre-v10 Logical Names’ in 4.5 Logical Names
 ‘Privileged Image’ in 4.3 Account Support Files
 ‘Process Quotas!’ in 4. Server Account and Environment
Q2.10 Quick-Check
R3.3 Re-Linking
 2.12 Reporting Problems
 ‘RSA Data Security’ in 7. Attribution and Acknowledgement
S5.3 SELECT.COM Procedure
 4. Server Account and Environment
 5.1 Server Environments
 ‘Server Image Command-Line Parameters’ in 4.6 Server Startup
 4.6 Server Startup
 ‘Source Archive, Object Module Archives’ in 2.1 Package UNZIP
 ‘Source Archive, Object Module Archives’ in 3.1 Package UNZIP
 ‘STARTUP.COM’ in 4.3 Account Support Files
 ‘STARTUP_LOCAL.COM’ in 4.3 Account Support Files
 ‘STARTUP_SERVER.COM’ in 4.3 Account Support Files
 ‘Stuart Langridge’ in 7. Attribution and Acknowledgement
 2.7 SYSUAF and RIGHTSLIST
T‘Table of Content’ in WASD Install and Update
 ‘Tatsuhiro Tsujikawa’ in 7. Attribution and Acknowledgement
 ‘TCP/IP Agent Resources!’ in 4. Server Account and Environment
 2.8 TCP/IP Infrastructure
 1.2 Troubleshooting?
U3. Update
 3.2 UPDATE.COM Procedure
 ‘Updating From v9.3 or Earlier’ in 3.1 Package UNZIP
 1.1 Using IA64-hosted X86 Cross-Complier?
V2.6 VMS 6.n
 4.2 VMS Scripting Account
 4.1 VMS Server Account
W‘WARNING!’ in 2.7 SYSUAF and RIGHTSLIST
 ‘WASD Install and Update’ in WASD Install and Update
 4.5.1 WASD Name Table
 ‘WASD OpenSSL Archive’ in 2.1 Package UNZIP
 ‘WASD OpenSSL Archive’ in 3.1 Package UNZIP
 ‘WASD VMS Web Services – Copyright © 1996-2021 Mark G. Daniel’ in 7. Attribution and Acknowledgement
 ‘Welcome!’ in 1. New to WASD? Start Here!
5.4 0̷BTAIN.COM Procedure
 0BTAIN.COM Procedure

7.Attribution and Acknowledgement

WASD VMS Web Services – Copyright © 1996-2021 Mark G. Daniel
Licensed under the Apache License, Version 2.0

You may not use this software except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
None of the following licensing appears incompatible with the Apache License
Clark Cooper, et.al.

This package uses the Expat XML parsing toolkit.

Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006 Expat maintainers. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Bjöern Höehrmann

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

Copyright (c) 2008-2009 Bjöern Höehrmann (<bjoern@hoehrmann.de>) Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Free Software Foundation

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

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.
Ohio State University

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

Copyright 1994,1997 The Ohio State University. The Ohio State University will not assert copyright with respect to reproduction, distribution, performance and/or modification of this program by any person or entity that ensures that all copies made, controlled or distributed by or for him or it bear appropriate acknowlegement of the developers of this program.
OpenSSL Project

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

Redistribution and use in source and binary forms, with or without modification, are permitted ...
Paul E. Jones

This package uses SHA-1 hash code.

Copyright (C) 1998, 2009 Paul E. Jones <paulej@packetizer.com> Freeware Public License (FPL) This software is licensed as "freeware." Permission to distribute this software in source and binary forms, including incorporation into other products, is hereby granted without a fee.
RSA Data Security

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

permission granted to make and use derivative works provided that such works are identified as "derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm" in all material mentioning or referencing the derived work.
Stuart Langridge

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

Thanks to many, many people for contributions and suggestions. Licenced as X11: http://www.kryogenix.org/code/browser/licence.html This basically means: do what you want with it.
Tatsuhiro Tsujikawa

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

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

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

WASD Install and Update