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.