TL;DR  WASD v12.1 compiles under VSI SSL111 and then links (as might
       be expected) under SSL111 object code or shared image.  The same
       code also links under VSI SSL3 object or image.  And vice-versa.

WASD has been working with early releases of OpenSSL 3.0 to ensure ongoing
compatibility.  While most sites are currently employing some version of
OpenSSL 1.1.1 (e.g. VSI SSL111) the 1.1.1 stream reaches EO(support)L later
in 2023.  VSI will be moving to SSL3 for integrated VMS TLS/SSL before then.

The current VSI Roadmap and the recent VSI Webinar (both as at 12-Jan-2023)
has SSL3 being the default SSL built-in being 3.0 during H1 CY2023.

  https://vmssoftware.com/about/roadmap/
  https://vmssoftware.com/about/webinars/

WASD v12.1 will be ready.  Already working with OpenSSL 3.0.  Just a relink
of the then current WASD will be sufficient to migrate.

While OpenSSL 3.0 is a significant rewrite employing a new set of
functionality based on a higher-level model of providers of crypto resources,
with these being consumed by crypto programs, significant effort has been
invested by OpenSSL.org to ensure code based on OpenSSL 1.1.1 concepts and
APIs continue to work (some corner-cases exempted), even though underlying
lower level implementations may be be processed differently, with

  https://www.openssl.org/docs/man3.0/man7/migration_guide.html

containing descriptions of these.  Not that any migration immediately will be
required of WASD, it is imagined that over the next few years some legacy,
low-level functionality will be deprecated and new ways to accomplish those
objectives adopted.

Back to v12.1 and SSL111/SSL3.  While OpenSSL.org has gone to some trouble to
make OpenSSL 1.1.1 programs build under OpenSSL 3.0 there are some minor
implementation differences that make them binary incompatible.  You cannot
compile on 1.1.1 and link using 3.0, or vice-versa.

To avoid releasing multiple SSL object code sets, the approach taken by WASD
is to provide a couple of small shims and then selectively linking these in
or out at build time.  With WASD v12.1 just search SESOLA.C for "SESOLA123"
or "SESOLA321", and look for the resulting small object modules

 $ DIR WASD_ROOT:[SRC.HTTPD.OBJ_*]SESOLA*

WASD v12.1 is good to go (to SSL 3 :-)

Attached is an image showing two separate X86 WASD built using the same
(cross-compiled) object code, one linked against VSI SSL111, the other SSL3.

As advised on info-WASD, no longer will WASD-specific SSL kits be necessary

  https://wasd.vsm.com.au/info-WASD/2022/0070

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