TL;DR  WASD Perl and Python persistent engines updated.**

WASD rules for activating scripts are generally fairly straightforward.

Most of these have been around since the dawn of (WASD) time.

The code has some default actions; from [SRC.HTTPD]DCL.C prologue:

  SCRIPT RUNTIME ENVIRONMENTS
  ---------------------------
  File types (extensions) and associated scripting languages can be
  defined in the configuration file.  The syntax is "type foreign-verb".
  For example:

    [DclRunTime]
    .PL  $PERL_EXE:PERL.EXE
    .CGI PERL

  Three are predefined, ".COM" for DCL procedures, ".CLD" to define a
  verb via command-definition file, and ".EXE" for executables.  There
  are two further. run-time types, CGIplus and (persitant) Run-Time
  Environment (RTE) indicated by enclosing them in parentheses.
  For example:

    [DclRunTime]
    .PL  (HT_EXE:PERLRTE.EXE)
    .HLB (CGI-BIN:[000000]CONAN)

In addition, mapping rules allow various combinations of extended run-time
executables:

  exec+ (cgi-bin:[000000]SOME.EXE)/cgiplus-bin/*.some /cgi-bin/*.some
  exec (!cgi-bin:[000000]OTHER.EXE)/cgi-bin/*.other /cgi-bin/*.other

  https://wasd.vsm.com.au/wasd_root/wasdoc/scripting/#scriptmapping
  https://wasd.vsm.com.au/wasd_root/wasdoc/config/#execuxecandscriptscriptmappingrules

So, what has this to do with Perl and Python RTEs?  Read on...

PERL AND PYTHON
~~~~~~~~~~~~~~~
The PerlRTE and PyRTE run-time environments have required recent tweaking, in
part to ensure continued operation with VSI "official" releases of Perl (5,
version 34, subversion 0 (v5.34.0) built for VMS_x86_64) and Python (VSI
I64VMS PYTHON A3.10-0RELEASE001), and in other part to improve efficiency and
some capability.

  https://vmssoftware.com/products/perl/
  https://vmssoftware.com/products/python/

PERLRTE
~~~~~~~
In testing for the X86 indigenous Perl the barest of build and code changes
were required.

Of course once you've opened the patient up it's difficult to resist the urge
to delve around inside the incisions; keyhole be damned.  The PerlRTE CGI
interface relied on a static array of CGI variables to "know" what to expect
in the CGI environment (in common with other CGI applications/scripts).

This being a long standing irritant with PerlRTE I decided to try making such
environments more versatile.  There is no LIB$GET_SYMBOL() with wildcard, to
list available DCL symbols, as is available with the DCL verb

  $ SHOW SYMBOL /ALL /GLOBAL

So I started with that verb.  Some code to create a Pseudo-Terminal and
LIB$SPAWN() attached to that, issue the "SHOW SYMBOL/ALL/GLOBAL" and collect
the results, parsing them into an equivalent structure as the CGIplus
variables, and subprocess exit.  Added over a second to a formerly sub-second
request on my Alpha.  Too much overhead.

However that gave me an idea.  What about a DCL symbol that listed the names
of all the CGI variable symbol names of a particular request (there are a
number of fixed CGI variables but also optional and idiosyncratic ones).  It
would then be a straightforward bit of code for a standard CGI script to
parse these out to get the full scope of a CGI script's variables.  So, from
WASD v12.1.1, the GATEWAY_SYMBOLS symbol is created internally by the server
and provides a comma-separated list of symbol names.  Really, very, very low
overhead.

  https://wasd.vsm.com.au/cgi-bin/cgi_symbols
  https://wasd.vsm.com.au/cgi-bin/cgi_symbols?one+two+three+four+five
  https://wasd.vsm.com.au/cgi-bin/cgi_symbols?one=1&two=2&three=3&four=4&five=5

(wish I'd thought of this a couple of decades ago)

THE B-WORD
~~~~~~~~~~
In playing around with getting all of the variations in script activation
tested and working (CGI, CGIplus, RTE), of course, I came across some
corner-cases.  Bugs in other words.  These are not to do with the vast
majority of activation types.  And of course, addressed from v12.1.1.

There also can be interactions where the same script is activated via all of
standard CGI, CGIplus and RTE.  Apart from demonstrating the performance
advantages of CGIplus vs. CGI it's best to stick to one or the other.

PYRTE
~~~~~
Python Run-Time Environment began some 16 years ago with the Python 2.n
port(s) by Jean-François Piéronne.  The PyRTE grew largely with his help and
guidance.  In late 2020 JFP released a "beta" Python 3 port for which WASD
PyRTE was successfully adapted.  A final release of the JFP Python 3 port
slipped.  The next thing was a VSI Python 3 port released for Itanium.

The previous PyRTE-3 JFP port didn't immediately build against the VSI
release.  After some (considerable) fiddling around (and several throwing of
hands in the air) PyRTE has been adapted for the VSI release.  These
difficulties most probably due to my lack of any real familiarity with Python
internals.  VSI's approach is to use DECC$... features to try and make the
behaviour as U*x/Posix as possible, I guess to minimise VMSism code changes. 

The engine has had a significant rework, shaving possibly 10% off the
performance of PyRTE-2.  The persistence of PyRTE-3 is still streets ahead of
starting the Python interpreter each time and so the 10% is almost
negligible.

The latest PYRTE.C also builds against the JFP Python v2.n package (on my
Alpha for example) and so provides some support for environments still using
that version.  However, WASD PyRTE-3 will only be supported for VSI
"official" releases.  We'd be expecting an X86 release in due course.

You can check the delta by looking through the source code for

  PY_MAJOR_VERSION

  https://wasd.vsm.com.au/wasd_root/src/python/pyrte.c

There are 45 differences.

PyRTE also has had its standard CGI upgraded to use GATEWAY_SYMBOLS from WASD
v12.1.1.  Although much of the value of the Python persistent engine is to
avoid Python standard CGI startup overheads, might as well be consistent.

DOWNLOAD
~~~~~~~~
The latest version of PerlRTE for Alpha, Itanium and X86 is available.

Also the latest version of PyRTE-3 only for Itanium.  Note that this is a
dot-zero release.  YMMV with more complex Python applications.  PyRTE-2
(Alpha and Itanium) is still available using the original 2017 kit.

  https://wasd.vsm.com.au/wasd/

** “I took a speed-reading course and read War and Peace in twenty minutes.
It involves Russia.”  Woody Allen

This item is one of a collection at
https://wasd.vsm.com.au/other/#occasional