WASD Install and Update

5.Other Ways to Deploy

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.

• WASD creates and populates it's own logical name table (see 4.5 Logical Names).

  It also adds the WASD_FILE_DEV[n] and WASD_ROOT[n] logical names to the SYSTEM logical name table.

• WASD creates and uses rights identifiers.

  Installation creates and associates specific rights identifiers with separate accounts for server and script execution. Some specifically named identifiers have functional meaning to the server. Server startup can create and associate rights identifers used to manage the server run-time environment.

  All executing server images are aware of all other executing server images on the same system and within the same cluster. This performs all manner of coordination (e.g. instance recovery, instantiated services) and data exchange (e.g. $HTTPD/DO=MAP/ALL) activities.

• WASD uses global sections to accumulate data and for communication between WASD instances.

  Some of these are by default permanent and remain on a system unless explicitly removed.

• WASD uses detached scripting processes.

  As it's possible to $STOP a server process (and thereby prevent it's run-down handlers from cleaning up those detached processes). It therefore needs to be able to recognise as its 'own' and clean any such 'orphaned' processes up next time it starts. It does this by having a rights identifier associated with the server process name (e.g. WASD:80 grants its scripting processes WASD_PRC_WASD_80, a second instance WASD2:80, WASD_PRC_WASD2_80, etc.)

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

Has been obsoleted by support added to STARTUP.COM.

5.1.2Formal Environments

The [EXAMPLE]STARTUP.COM procedure (copied into [STARTUP] during installation/update) uses locally assigned DCL symbols for customisation. It easily can be wrapped by another procedure to tailor a site or multiple enviroment startup. Check the startup options described in the procedure prologue.

This is a real-world example used to instantiate a second server enviroment statically linked with OpenSSL 1.1.1n. Note that only the configuration files requiring customisation are wrapped, with WASD_CONFIG_GLOBAL and WASD_CONFIG_MSG using the default files.

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

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

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.

Concurrent Versions

Concurrent Versions

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

• A clash with any existing [WASD_ROOT] directory must be avoided.
  Using the "-d" switch, UNZIP into a working directory using any unique name (WORKING in this example).
  $ SET DEFAULT device:[000000] $ UNZIP -d [.WORKING] device:[dir]archive.ZIP
  Do the same with object module archive(s) if required.
• Rename the WASD root directory into the current directory using a representative name (appending the version number is suggested) and then delete the working directory.
  $ RENAME [.WORKING]WASD_ROOT.DIR []WASD_ROOT_1210.DIR $ DELETE WORKING.DIR;*
• Move into the just renamed directory and build using the parameter INSTALL.
  The build is (always) performed using locally defined logical names.
  $ SET DEFAULT [WASD_ROOT_1210] $ @INSTALL INSTALL

  The INSTALL parameter overrides the install check and advisory message otherwise generated:

  ***************************************** * "WASD_ROOT" LOGICAL NAME DETECTED. * * THIS DOES NOT LOOK LIKE AN INSTALL! * *****************************************
• As appropriate, copy configuration and other files from the current WASD installation to the new.
  Check release notes for any variants.
  $ COPY WASD_ROOT:[LOCAL]*.* [WASD_ROOT_1210.LOCAL]

  Other site-specific localisations similarly may need to be copied or otherwise reproduced.
  For example, server or scripting account LOGIN.COM, custom STARTUP procedures, scripts, etc.

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

• Shut down the currently running server.
  $ HTTPD/DO=EXIT=NOW
• Start the desired version of WASD from its file-system location.
  $ @device:[WASD_ROOT_1210.STARTUP]STARTUP.COM

  WASD logical names and environment will reflect the particular WASD root directory.
  Site-specific elements in the startup might need to be similarly flexible.
  Previous server process logs and access logs may no longer be immediately available.

Various schemas have been proposed and implemented for incorporating multiple version management including the use of hard-links, to the redefinition of WASD logicals to include search lists, to modification of system startup procedures. Whichever is selected being able to move between WASD versions has definite advantages, particularly for production environments.

Moving Between Minor Versions

Once multiple versions are established moving between versions should be a simple as stopping the executing server and then (re-)starting the desired version of WASD from its file-system location.

Moving Between Major Versions

Incompatibilties in global sections may complicate any attempt to jump between major versions (sometimes even between minor versions but that is rare). It is recommended when major versions are moved between to delete associated global sections. This zeroes accounting, etc.

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.

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:

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

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

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: