Welcome!

This chapter provides a quick guide to getting your WASD package installed, configured and serving. This covers initial installation. (NUMBERED) (Unzip Package\BOLD)

Install the files following the guidelines in (cr_install). (Note\BOLD) that more than one archive may be needed ((hd_setup_source_object)).

If (Secure Sockets Layer\BOLD) (SSL) is to be used and an SSL server image to be built the SSL product must be installed at this stage (see (HREF=[-.features]features.sdml!../features/#hd_ssl_sources)(doc_features.sdml)). An existing HP SSL for OpenVMS product requires no additional step. If the WASD SSL package it must UNZIPed into the [.WASD_ROOT] tree at this stage. $ SET DEFAULT [.WASD_ROOT] $ UNZIP device:[dir]archive.ZIP (INSTALL Package\BOLD)

Server installation is performed using the INSTALL.COM procedure ((hd_setup_install)). (UNNUMBERED) (Build Package - \BOLD) Compile and link, or just link supplied object files to produce VMS executables for the system's version of VMS. (Check Package - \BOLD) Check basic operation of the package ((hd_quick_check)). (Create Server and Scripting Accounts - \BOLD) Create two independent accounts, one for executing the server, the other for executing scripts ((hd_server_account)). If quotas are enabled on the target disk provides an ambit allocation for these accounts. Review this at some stage. (Set Package Security - \BOLD) This sections traverses the newly installed tree and sets all package directories and files to required levels of access ((hd_securing_maintain)). (Copy Support and Configuration Files - \BOLD) Copy the example server support and configuration files ((hd_account_support_files)). (Install Scripts - \BOLD) Selectively copy groups of scripts from package build directories into the scripting directories. (Configure Package\BOLD)

Following the execution of the INSTALL.COM procedure the package should require only minor, further configuration.

(Initially\BOLD) two files may require alteration. (NUMBERED) 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 ((hd_account_support_files)). The only configuration that should require immediate attention will be to the mapping rules ((cr_mapping_rule)).

(More generally\BOLD) server runtime configuration involves the considerations discussed in (hd_site_organisation) along with the following aspects: (UNNUMBERED) Configuring the HTTP server run-time characteristics ((cr_config)). Mapping request paths to the VMS file system, and to other things such as scripts ((cr_mapping_rule)). Customizing some messages (or all if non-English language environment) ((cr_msg_config)). Establishing an authentication and authorization environment. (Start Server\BOLD)

Execute the startup procedure. Get your browser and connect! (Find Out What's Wrong :^\BOLD)

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 (HTML/OFF) (cr_install), (HTML/ON) (hd_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 (hd_setup_problems). (--------------------------------------------------------------------) (Installation and Update\cr_install)

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: Archive: SYS$SYSDEVICE:[WASD]WASD1000.ZIP;1 WASD VMS Web Services, Copyright (C) 1996-2009 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 * Full release of v10.0.0 (November 2009) ************************************************** *** 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]WASD1000.ZIP * To build/link images use the appropriate one of: $ @device:[WASD_ROOT]INSTALL $ @HT_ROOT:[000000]UPDATE (In future this will be: $ @WASD_ROOT:[000000]UPDATE) * NOTE: Accounting data will be zeroed when v10.0 first starts. ... VMS file attributes saved ... use UnZip 5.2+ on OpenVMS Archive created 7-NOV-2009 Length Date Time Name -------- ---- ---- ---- 0 11-07-09 08:18 wasd_root/axp-bin/ 0 11-07-09 08:18 wasd_root/axp/ 0 11-07-09 08:18 wasd_root/cgi-bin/ 0 11-07-09 08:18 wasd_root/doc/ 0 11-07-09 08:19 wasd_root/example/ 0 11-07-09 08:19 wasd_root/exercise/ 2734 03-06-03 17:20 wasd_root/favicon.ico ... 90685 09-24-09 06:12 wasd_root/src/utils/wotsup.c 1990 05-10-05 09:21 wasd_root/src/utils/wotsup.com 270 11-07-09 06:59 wasd_root/startup/readme.html 426 11-07-09 06:38 wasd_root/vax-bin/readme.html 452 11-07-09 06:18 wasd_root/vax/readme.html -------- ------- 16630443 908 files (Package UNZIP\hd_unzip_install)

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]

It should be unarchived to restore the VMS file system characteristics. $ UNZIP device:[dir]archive.ZIP (Updating From v9.3 or Earlier) (Before UNZIPing\BOLD) the v10 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\BOLD). The v10 package uses [WASD_ROOT] as its 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 v10 package is not suitable for updating from existing v8.0 or earlier installation. (Source Archive, Object Module Archives\hd_setup_source_object)

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 VAX, 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 UNZIPped 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-VAX.ZIP The WASD distribution and package organisation fully supports mixed-architecture clusters (AXP, Itanium and/or VAX in the one cluster) as one integrated installation. (WASD OpenSSL Archive\hd_setup_wasd_ssl)

Building an SSL-capable version of the server is a common requirement. WASD SSL is discussed in detail in (HREF=[-.features]features.sdml!../features/#cr_ssl)(doc_features.sdml) 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. 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 SET DEFAULT in the following example. $ SET DEFAULT [.WASD_ROOT] $ UNZIP device:[dir]OPENSSLWASD(nnn).ZIP (Existing Installations\hd_install_existing)

When installing an archive as an update to an existing installation consider the following. (UNNUMBERED) Some (insurance) on the directory tree is recommended in case the update should fail or otherwise be unusable or problematic (of course, this is good advice whenever about to make major changes to anything!) This may be in the format of a regular site backup, special pre-update backup, or special pre-update ZIP archive of the directory tree. The latter two could be accomplished using commands similar to the following: $ BACKUP WASD_ROOT:[000000...] location:WASDROOT.BCK/SAVE/VERIFY $ ZIP "-V" location:WASDROOT.ZIP device:[WASD_ROOT...]*.* $ ZIP "-T" location:WASDROOT.ZIP If using ZIP then ensure that a previous version of the target ZIP file does not already exist. If it does then that version is updated, a new version is not created. For existing files a new version is created (the first time this is about to occur the UNZIPper requests permission - either (A) for all, or (y) or (n) or a per-file basis). It is possible to (selectively) extract portions of a tree if something has become damaged. This would be accomplished by specifying what needs to be extracted from the archive (instead of the default (all)), as illustrated by the following example where only the Alpha object modules are extracted. $ SET DEFAULT device:[000000] $ UNZIP device:[dir]archive-AXP.ZIP ht_root/src/httpd/obj_axp/*.* (ODS-5 Volumes\hd_setup_ods5)

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!) (Accessible Volume\hd_setup_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 DKA0: ALPHASYS object of class VOLUME Owner: [1,1] Protection: (System: RWCD, Owner: RWCD, Group: RWCD, World: RWCD) Access Control List: () (Package Directory Structure\hd_setup_directories)

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 ((hd_securing_package)).

((Package Directory Structure\BOLD)) (2\15) (Directory\Description) ([AXP-BIN]\Alpha executable script files) ([AXP]\Alpha build and utility area) ([CGI-BIN]\architecture-neutral script files) ([DOC]\package documentation) ([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) ([VAX-BIN]\VAX executable script files) ([VAX]\VAX build and utility area) (TCP/IP Infrastructure\hd_setup_install_tcpip)

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. (SYSUAF and RIGHTSLIST WARNING!\hd_setup_install_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\BOLD), 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\BOLD), required for script process management, to RIGHTSLIST.DAT.

These behaviours must be considered in site environments where such changes are prohibited or closely controlled. (Installation DCL Procedure\hd_setup_install)

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: (NUMBERED) (Build Executables - \BOLD) 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. (Check Package - \BOLD) Executes a procedure that runs up the HTTPd in demonstration mode. Allows evaluation/checking of the basic package ((hd_quick_check)). (Create Server and Scripting Accounts - \BOLD) Create two, independent accounts, one for executing the server, the other for executing scripts ((hd_server_account)). If quotas are enabled on the target disk provides an ambit allocation for these accounts. Review this at some stage. (Set Package Security - \BOLD) This section traverses the newly installed tree and sets all package directories and files to required levels of access. For directory settings see (hd_securing_package). (Copy Support and Configuration Files - \BOLD) Copy the example server support and configuration files ((hd_account_support_files)). (Install Scripts - \BOLD) Selectively copy groups of scripts from package build directories into the scripting directories.

Support files to consider when customizing startup, etc. (see (hd_account_support_files) for further detail): (SIMPLE) STARTUP.COM STARTUP_LOCAL.COM STARTUP_SERVER.COM (Update DCL Procedure\hd_setup_update)

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! (Updating From v9.3 or Earlier) (Before UNZIPing\BOLD) the v10 package and when updating an existing v9.3 or earlier installation the current (root directory must be renamed from HT_ROOT.DIR to WASD_ROOT.DIR\BOLD). The v10 package uses [WASD_ROOT] as its 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 v10 package is not suitable for updating from an existing v8.0 or earlier installation.

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: (NUMBERED) (Build Executables - \BOLD) 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. (Server Quick-Check - \BOLD) Executes a procedure that runs up the HTTPd in demonstration mode. Allows evaluation/checking of the basic package ((hd_quick_check)). (Server Support/Configuration Files - \BOLD) Copies changed example HTTP server configuration and support files from the [EXAMPLE] directory to the [HTTP$SERVER], [LOCAL] and [STARTUP] directories. (Update Scripts - \BOLD) Selectively copy groups of scripts from package build directories into the scripting directories. (Reapply Package Security - \BOLD) This section traverses the updated tree and sets all package directories and files to required levels of access. For directory settings see (hd_securing_package). (Post-Update Cleanup - \BOLD) Prompts for permission to execute the post-update procedure described below. (Purge Files - \BOLD) 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 [...] (Quick-Check\hd_quick_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. $ @WASD_ROOT:[INSTALL]DEMO.COM ******************************* * 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)? []: anyoldpassword %DCL-S-SPAWNED, process SYSTEM_1604 spawned %DCL-S-ATTACHED, terminal now attached to process SYSTEM_1604 %HTTPD-I-SOFTWAREID, HTTPd-WASD/10.0.0 OpenVMS/AXP SSL WASD VMS Hypertext Services, Copyright (C) 1996-2009 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 %HTTPD-I-STARTUP, 16-AUG-2009 00:31:06 %HTTPD-I-WASD_ROOT, DKA0:[WASD_ROOT] %HTTPD-I-ENVIRONMENT, 0 %HTTPD-I-SYSTEM, Digital Personal WorkStation VMS V8.3 %HTTPD-W-SYSPRV, operating with implicit SYSPRV (UIC group 1) %HTTPD-I-TCPIP, HP TCPIP$IPC_SHR V5.6-ECO2 (24-JUL-2007 14:35:19.90) %HTTPD-I-MODE, INTERACTIVE %HTTPD-I-ODS5, supported by Alpha VMS V8.3 %HTTPD-I-GMT, +09:30 %HTTPD-I-INSTANCE, supervisor %HTTPD-I-GZIP, using ZLIB 1.2.3 %HTTPD-I-GBLSEC, created global section of 16 page(let)s %HTTPD-I-INSTANCE, 1 process %HTTPD-I-SSL, OpenSSL 0.9.8f 11 Oct 2007 %HTTPD-I-SSL, protocol(s) SSLv2/v3 %HTTPD-I-INSTANCE, process name WASD:7080 %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-SCRIPTING, as HTTP$NOBODY %HTTPD-I-DCL, subprocess scripting %HTTPD-I-ACTIVITY, created global section of 992 page(let)s %HTTPD-I-SERVICE, http://klaatu.private.net:7080 %HTTPD-I-SERVICE, https://klaatu.private.net:7443 %HTTPD-I-SSL, klaatu.private.net:7443 %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, 16-AUG-2009 00:31:07, accepting requests

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

) (HTML/OFF) should display something resembling - /-- / \ /(W A S D\BOLD)\ Welcome to (((WASD VMS Web Services))\BOLD) version 10.0 Empowered by VMS \/---\ / -- (HTML/ON) 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. ((Clone) Procedure\hd_clone_procedure)

The [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. (Re-Linking\hd_relinking)

After a major update to the operating system the package may refuse to start, reporting a message like: %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 DCL procedure, (hd_setup_update). (VMS 6.(n) \hd_version_6061)

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! (VMS 5.5-(n) \hd_version_552)

WASD does not build or run under VMS 5.5-2 or earlier. (Local Setup Suggestions\hd_setup_suggestions)

Package updates (will never\BOLD) contain anything in these directories: (SIMPLE) WASD_ROOT:[HTTP$NOBODY] WASD_ROOT:[HTTP$SERVER] WASD_ROOT:[LOCAL] WASD_ROOT:[STARTUP]

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-ever the local site manages system startup. These could be placed in the WASD_ROOT:[STARTUP] directory. (Reporting Problems\hd_setup_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 (()) 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.\BOLD) 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 (HTML= Mark.Daniel@wasd.vsm.com.au ) (HTML/OFF) (Mark.Daniel@wasd.vsm.com.au) (HTML/ON) (--------------------------------------------------------------------) (Server Account and Environment\cr_server_account)

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: (UNNUMBERED) Textual pages OK, but pages with a significant number of images having some or all (broken). Scripts failing mysteriously, particularly when multiple in use concurrently. Server and associated scripts all apparently waiting MWAIT or RWAST states. 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 (HREF=[-.features]features.sdml!../features/#cr_watch)(doc_features.sdml)) 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. (VMS Server Account\hd_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 (VMS Scripting Account\hd_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 (Account Support Files\hd_account_support_files) Support procedures often change between versions. It is always advisable to check the versions documentation before installing or updating. (....................................................................) (HTML= Examples may be found in WASD_ROOT:[EXAMPLE]. ) (HTML/OFF) Examples may be found in WASD_ROOT:[EXAMPLE].

(online Web link) (HTML/ON) (....................................................................) (HTTPd Executables\hd_httpd_exe)

Two server executables can be built by the package. (UNNUMBERED) (HTTPD.EXE - \BOLD) basic server (HTTPD_SSL.EXE - \BOLD) SSL-enabled server. (Privileged Image\hd_server_install)

As the HTTP$SERVER account should be completely unprivileged, and the HTTPd image requires ALTPRI, CMKRNL, DETACH, NETMBX, TMPMBX, PRMGBL, PRMMBX, PSWAPM, SECURITY, SHMEM (VAX only), SYSGBL, SYSLCK, SYSNAM, SYSPRV and WORLD privileges (see the (doc_readmore.sdml) 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,PRMGBL,PRMMBX,PSWAPM,- SECURITY,SYSGBL,SYSLCK,SYSNAM,SYSPRV,WORLD) (STARTUP.COM\hd_server_startup)

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

On VAX platforms prior to VMS V6.2 the startup uses a system batch queue. By default SYS$BATCH is used. An alternate queue can be specified. $ @DKA0:[WASD_ROOT.STARTUP]STARTUP WASD_DECNET=1 WASD_BATCH_QUEUE=THIS$BATCH

Check the procedure itself for detail on symbol names and functionality. (HTML=

See WASD_ROOT:[EXAMPLE]STARTUP.COM ) (HTML/OFF)

See WASD_ROOT:[EXAMPLE]STARTUP.COM (HTML/ON) (STARTUP_LOCAL.COM\hd_server_startup_local)

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. (HTML=

See WASD_ROOT:[EXAMPLE]STARTUP_LOCAL.COM ) (HTML/OFF)

See WASD_ROOT:[EXAMPLE]STARTUP_LOCAL.COM (HTML/ON) (STARTUP_SERVER.COM\hd_httpd_startup_server_com)

This procedure serves two purposes. (NUMBERED) Server startup: (UNNUMBERED) If on VAX VMS V6.0 or V6.1 it is submitted to the SYS$BATCH queue during startup. The batch portion creates a detached process, which then again uses this procedure as input, supporting the executing HTTPd. With more modern versions and architectures of VMS the procedure becomes SYS$COMMAND for a detached process created directly during the execution of STARTUP.COM. The procedure then controls the activation of the HTTPd executable image during server restarts and exits. (HTML=

See WASD_ROOT:[EXAMPLE]STARTUP_SERVER.COM ) (HTML/OFF)

See WASD_ROOT:[EXAMPLE]STARTUP_SERVER.COM (HTML/ON)

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 (--------------------------------------------------------------------) (Global Pages/Sections\hd_global_pages)

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\BOLD))

(3\15\40\7) (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. ((hd_server_command_startup)). The startup qualifier /GBLSEC=NOPERM disables the creation of permanent global sections eliminating this requirement. (--------------------------------------------------------------------) (Logical Names\hd_logical_names)

WASD version 10 uses an independent logical name table (something previous versions did not, see (hd_wasd_name_table) below) and a different logical naming schema to earlier versions.

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\BOLD))

(4\13\6\24) (Logical Name\Table\Description\Pre-v10 Equivalent) (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.\same) (CGI_BIN\WASD\Directory containing architecture-neutral script files.\same) (CGI_EXE\WASD\Directory containing architecture-specific script executables.\same) (HT_EXE\WASD\Pre-v10.0 backward compatibility for WASD_EXE.\same) (HT_LOGS\WASD\Pre-v10.0 backward compatibility for WASD_LOG.\same) (HT_ROOT\SYSTEM\Pre-v10.0 backward compatibility for WASD_ROOT.\same) (HT_SCRATCH\WASD\Pre-v10.0 backward compatibility for WASD_SCRATCH.\same) (WASD_AXP\WASD\Directory containing Alpha executable images (WASD_ROOT:[AXP]).\HT_AXP **) (WASD_AUTH\WASD\Directory containing authentication/authorization databases (files, (WASD_ROOT:[LOCAL])).\none) (WASD_CGI_AXP\WASD\Directory containing Alpha script executables (WASD_ROOT:[AXP-BIN]).\CGI_AXP) (WASD_CGI_IA64\WASD\Directory containing Itanium script executables (WASD_ROOT:[IA64-BIN]).\CGI_IA64) (WASD_CGI_VAX\WASD\Directory containing VAX script executables (WASD_ROOT:[VAX-BIN]).\CGI_VAX) (WASD_CONFIG\WASD\Location of the configuration files. Can be defined as a search list.\none) (WASD_CONFIG_AUTH\WASD\Location of the authentication/authorization configuration file.\HTTPD$AUTH) (WASD_CONFIG_GLOBAL\WASD\Location of the configuration file.\HTTPD$CONFIG) (WASD_CONFIG_MAP\WASD\Location of the mapping rule file.\HTTPD$MAP) (WASD_CONFIG_MSG\WASD\Location of the message file.\HTTPD$MSG) (WASD_CONFIG_SERVICE\WASD\Location of the optional service (virtual host) configuration file.\HTTPD$SERVICE) (WASD_DECNET_CGI_OBJECT\SYSTEM\ Locates the supporting DCL procedure. DECnet objects are system-global.\none) (WASD_DECNET_OSU_OBJECT\SYSTEM\ Locates the supporting DCL procedure. DECnet objects are system-global.\none) (WASD_EXE\WASD\Directory containing the executable images.\HT_EXE **) (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).\none) (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.\HTTPD$GMT) (WASD_IA64\WASD\Directory containing Itanium executable images.\HT_IA64) (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.\HT_LOG) (WASD_LOGS\WASD\Optional definition, for convenient log file specification.\HT_LOGS **) (WASD_ROOT\SYSTEM\Location of WASD Web Services directory tree, as a concealed device.\HT_ROOT **) (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].\HT_SCRATCH **) (WASD_SITELOG\WASD\Location of the optional plain-text site log file.\HTTPD$SITELOG) (WASD_SSL_CAFILE\WASD\When using the SSL executable this logical locates the optional Certificate Authority list file.\HTTPD$SSL_CAFILE) (WASD_SSL_CERT\WASD\When using the SSL executable this logical locates the default certificate.\HTTPD$SSL_CERT) (WASD_SERVER_LOGS\WASD\Location of the server process logs.\HT_SERVER_LOGS) (WASD_STARTUP_SERVER\WASD\Used to pass parameters to the server image startup command line.\HTTPD_STARTUP_SERVER) (WASD_VAX\WASD\Directory containing VAX executable images.\HT_VAX) (\\\**(provided for backward compatibility)) (WASD Name Table\hd_wasd_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_VAX" = "WASD_ROOT:[VAX-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_VAX" = "WASD_ROOT:[VAX]" "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_DEV(n) logical names are used for non-primary WASD environments (see (HREF=[-.features]features.sdml!../features/#cr_instances_and_environments)(doc_features.sdml)). (Pre-v10\hd_wasd_name_table_prev10)

The server code accepts both the v10 and pre-v10 schemas. If it cannot find a v10 logical name it attempts to use a pre-v10 logical name. This has been provided in an effort to make the transition as seamless as possible for existing sites. In addition the revised startup procedures configure and use WASD_TABLE but can be directed to use the SYSTEM table by STARTUP.COM being provided a WASD_TABLE=0 parameter (see (hd_server_startup)). $ WASD_TABLE = 0 $ @DKA0:[WASD_ROOT.STARTUP]STARTUP.COM (Server Startup\hd_server_command_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 (hd_httpd_startup_server_com).

((Server Image Command-Line Parameters\BOLD))

(2\20) (Parameter/Qualifier\Description) (/ACCEPT=\Comma-separated list of hosts/domains allowed to connect to the server.) (/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=[SSL,ALL]\The (SSL) keyword causes all authentication (both SYSUAF and HTA database) to be available only via (https:) requests. The (ALL) keyword forces the server to deny access to any path that does not have authorization in place against it.) (/CGI_PREFIX=\The prefix to the CGI symbol names created for a script (defaults to (WWW_), similar to the CERN VMS HTTPd, see (Scripting Environment) document).) (/CLUSTER\Apply control /DO= to all instances in the cluster (default is to per-node instances only).) (/DEMO\Places the server into demonstration mode designed to allow full package capabilities to be demonstrated. Used by the [INSTALL]DEMO.COM procedure.) (/DETACH=\For VMS 6.2 and later 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) (/FILBUF=\Number of bytes in the read buffer for files open for processing (i.e. menu files, image mapping configuration files, pre-processed HTML files, etc., not direct file transfers).) (/FORMAT=\Overrides the configuration parameter [LogFormat].) (/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. See also the /GBLSEC=NOPERM described immediately below.) (/GBLSEC=NOPERM\Disables the creation of permanent global sections. They are automatically deleted when the server image exits.) (/REJECT=\Comma-separated list of hosts/domains not allowed to connect to the server.) (/[NO]LOG[=name]\Either disables logging (overrides configuration directive), or enables logging and optionally specifies the log file name (also see section (hd_logical_names), logging is disabled by default). If the file specification is (SYS$OUTPUT) the server issues log entries to (), allowing user-defined log formats to be easily checked and refined.) (/NOMONITOR\Allows the update of the data read by HTTPDMON to be disabled.) (/NETBUF=\Minimum number of bytes in the network read buffer.) (/NETWORK\Run the server and any scripting processes as NETWORK mode rather than the default detached OTHER mode.) (/OUTBUF=\Number of bytes in the output buffer (for direct file transfers, buffered output from menu interpretation, HTML-preprocessing, etc.)) (/PERIOD=\Overrides the configuration parameter [LogPeriod].) (/PERSONA[=(ident-name), RELAXED,AUTHORIZED, RELAXED=AUTHORIZED]\ Enables detached process scripting. When used without the (ident-name) all non-privileged accounts (appropriately mapped of course) may have scripts executed under them. If the optional (ident-name) is supplied it specifies the name of a rights identifier the account must be granted before scripts can be activated under it. The RELAXED, AUTHORIZED and RELAXED=AUTHORIZED further control the use of persona functionality with privileged accounts. See (Scripting Overview, Introduction) for further detail.) (/PORT=\Overrides the configuration parameter [Port] BUT is in turn overridden by the [Service] configuration parameter and /SERVICE= qualifier (is really only useful for use with the /DO= qualifier).) (/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 activitied 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/9.0.0 OpenVMS/AXP SSL)).) (/[NO]SSL[=version]\Controls Secure Sockets Layer protocol behaviour. The version can be any of (2), (3) or (23) (i.e. both 2 and 3, and the default) specifying which SSL protocol version the server will service.) (/SUBBUF=\Number bytes in a (sub)process' SYS$OUTPUT buffer.) (/[NO]SWAP\Controls whether the server process may be swapped out of the balance set (default is swapping disabled).) (/[NO]SYSUAF[=ID,PROXY,SSL,WASD]\Allows or disallows (D) username authentication using the server system's SYSUAF, the optional (SSL) keyword causes SYSUAF authentication to be available only via (https:) requests, the optional (PROXY) keyword allows SYSUAF proxying, and the optional (ID) keyword makes SYSUAF authentication only available to account possessing a specific identifier. The (WASD) keyword makes the deprecated, "hard-wired" WASD identifier environment available to this server.) (/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[=1664]\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.) (--------------------------------------------------------------------)