WTL;DR: Getting the WASD package onto x86-64 is done! Boom-boom.
https://wasd.vsm.com.au/other/#WASD_x86-64
The previous report (04-NOV-2020) described a server installation left
largely unsupervised for six weeks. It was occasionally looked over by a
curious visitor or two and underwent the usual probing by site security
"investigators". And so on for a further six weeks. Three months in total.
V9.0-F EAK
----------
As the latest EAK was recently released by VSI, the original 9.0-D VM was
replaced by 9.0-F. (A decision to skip -E was based on the limited increment
in capability.) 9.0-F allows clustering and was of immediate interest to the
VSM op. And - it works!
View of Cluster from system ID 1033 node: X86V2 20-DEC-2020 21:24:28
+-----------------------+---------+
| SYSTEMS | MEMBERS |
+--------+--------------+---------+
| NODE | SOFTWARE | STATUS |
+--------+--------------+---------+
| X86V2 | VMS V9.0-F | MEMBER |
| HAVEN | VMS V8.4-2L1 | MEMBER |
+--------+--------------+---------+
And very usefully from that, MSCP.
X86V2$ show dev d
Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
X86V2$DKA0: Mounted 0 X86VMS_90F 933576 175 1
X86V2$DKA100: Mounted 0 PAGE 1048205 1 2
X86V2$DKA200: Mounted 0 USER 4193950 1 2
X86V2$DKA300: Mounted 0 USERS 3677930 9 2
8< snip 8<
$10$DKD0: (HAVEN) Mounted 0 (remote mount)
1
$10$DKD1: (HAVEN) Mounted 0 (remote mount)
1
$10$DKD2: (HAVEN) Mounted 0 (remote mount)
1
$10$DKD3: (HAVEN) Mounted 0 (remote mount)
1
MSCP served devices would make moving files around much simpler than FTP -
but is actually much more useful than just that. More shortly.
Once the 9.0-F EAK had been established as the system disk, the previous
additional disks (and content) were also made available, meaning the WASD
server built under the 9.0-D cross-compiler tools and linked on the 9.0-D
system just sprang back into life when 9.0-F booted.
WASD v12.0 and Native 64bit
---------------------------
During the twelve weeks since v11.5.1 had been ported to X86-64, the decision
to remove VAX accomodations was implemented. A large (and continually
increasing) number of code data were 64bit. To accomodate VAX these were
almost exclusively implemented as back-to-back longs ([32][32]) manipulated
using macros and LIB$ routines. More overhead than absolutely necessary and
making for cluttered source code and less obvious intent. These have been
reimplemented as int64s and native 64bit arithmetic.
Example; v11.5.2:
if ((uint)fqptr->EndOfFileVbn <= 1)
PUT_LONG_QUAD (fqptr->FirstFreeByte, (void*)&fqptr->QuadSizeInBytes)
else
if ((uint)fqptr->EndOfFileVbn < 0x400000)
PUT_LONG_QUAD ((((fqptr->EndOfFileVbn-1) << 9) + fqptr->FirstFreeByte),
(void*)&fqptr->QuadSizeInBytes)
else
{
/* greater than 4GB */
PUT_LONG_QUAD (fqptr->EndOfFileVbn-1, (void*)&fqptr->QuadSizeInBytes)
MUL_LONG_QUAD (512, (void*)&fqptr->QuadSizeInBytes)
ADD_LONG_QUAD (fqptr->FirstFreeByte, (void*)&fqptr->QuadSizeInBytes)
}
v12.0.0:
if ((uint)fqptr->EndOfFileVbn <= 1)
fqptr->SizeInBytes64 = fqptr->FirstFreeByte;
else
if ((uint)fqptr->EndOfFileVbn < 0x400000)
fqptr->SizeInBytes64 = ((fqptr->EndOfFileVbn-1) << 9) +
fqptr->FirstFreeByte;
else
{
/* greater than 4GB */
fqptr->SizeInBytes64 = fqptr->EndOfFileVbn-1;
fqptr->SizeInBytes64 *= 512;
fqptr->SizeInBytes64 += fqptr->FirstFreeByte;
}
WASD originated on VAX, then moved to Alpha, on to Itanium, and of course now
x86-64. VAX had twenty-six years of support and continuous development. It
shouldn't moan too loudly at now being passed over. Losses of critical
infrastructure such as OpenSSL and hobbyist licensing compounded the 32bit
consideration. All VAX has been removed from the download page and as-at
VAX-capable kits archived separately.
https://wasd.vsm.com.au/wasd/
WASD x86-64 Port
----------------
Back to getting the WASD package onto x86-64. Well, it's done! (And of
course for the moment, ignoring the probability of lurking gremlins.)
Boom-boom.
During the referenced twelve weeks, further work was done throughout the code
and build environment. The v11.5.1 server originally built under 9.0-D was
shutdown and the tree archived. A standard distribution - WASD1200B2.ZIP -
was created and a (mostly) standard installation performed using that.
Voila! A working v12.0.0b2 installation.
Now I did say *mostly* standard installation. The 9.0-F EAK still employs
cross-compilers. Compiling was performed on the IA64 system, with linking
and package installation on the x86-64 system. This is where the MSCP served
storage proved *most* useful.
The build and installation:
HAVEN$ set default X86V2$DKA300:[000000]
HAVEN$ unzip sys$login:WASD1200B2.ZIP
HAVEN$ set default [wasd_root.install]
HAVEN$ @install install
... only compile selected ...
HAVEN$ rename [wasd_root.src...]obj_ia64.dir obj_x86_64.dir
X86V2$ set default X86V2$DKA300:[wasd_root.install]
X86V2$ @install install
... link pre-compiled object modules selected ...
... installation performed ...
That was it. (If the interim twelve weeks tinkering is ignored.)
http://x86v2.vsm.com.au:7080/
https://x86v2.vsm.com.au:7443/
Still using self-signed server cert so some browser jiggery-pokery most
likely required on initial connection to 7443.
State of the EAK
----------------
I've already sung the praises of clustering/MSCP.
V9.0-D C-RTL issues encountered and reported to VSI have been addressed (e.g.
gethostname()).
$GETRMI is now functioning.
The main standout for WASD is reflected in the above URLs. Attempting to
bind to privileged IP ports (i.e. <= 1023, e.g. 80, 443) still fails with
NOPRIV. The stack reports "VSI TCP/IP X10.7-8, VBOX VBOXFACP, OpenVMS I64
V9.0-F" which is a minor bump (-7 to -8) from previous so possibly nothing
significant has been addressed in this interim product.
I would expect the next significant WASD step would be "H1 2021 - OpenVMS
V9.1 EAK for x86" with its native compilers.
https://vmssoftware.com/products/roadmap/
Happy and safe holiday period, Mark.
|