01-Aug-2022

Maintenance job has usual outcome
Last night’s maintenance run didn’t show anything weird. Although there is a huge amount of spam, numbers aren’t alarming:

PMAS%nbsp;statistics%nbsp;for%nbsp;July
Total%nbsp;messages%nbsp;%nbsp;%nbsp;%nbsp;:%nbsp;%nbsp;%nbsp;3162%nbsp;=%nbsp;100.0%nbsp;o/o
DNS%nbsp;Blacklisted%nbsp;%nbsp;%nbsp;:%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;0%nbsp;=%nbsp;%nbsp;%nbsp;%nbsp;.0%nbsp;o/o%nbsp;(Files:%nbsp;%nbsp;0)
Relay%nbsp;attempts%nbsp;%nbsp;%nbsp;%nbsp;:%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;75%nbsp;=%nbsp;%nbsp;%nbsp;2.3%nbsp;o/o%nbsp;(Files:%nbsp;31)
Accepted%nbsp;by%nbsp;PMAS%nbsp;%nbsp;:%nbsp;%nbsp;%nbsp;3087%nbsp;=%nbsp;%nbsp;97.6%nbsp;o/o%nbsp;(Files:%nbsp;31)
%nbsp;%nbsp;Handled%nbsp;by%nbsp;explicit%nbsp;rule
%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;Rejected%nbsp;:%nbsp;%nbsp;%nbsp;2012%nbsp;=%nbsp;%nbsp;65.1%nbsp;o/o%nbsp;(processed),%nbsp;%nbsp;63.6%nbsp;o/o%nbsp;(all)
%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;Accepted%nbsp;:%nbsp;%nbsp;%nbsp;%nbsp;107%nbsp;=%nbsp;%nbsp;%nbsp;3.4%nbsp;o/o%nbsp;(processed),%nbsp;%nbsp;%nbsp;3.3%nbsp;o/o%nbsp;(all)
%nbsp;%nbsp;Handled%nbsp;by%nbsp;content
%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;Discarded%nbsp;:%nbsp;%nbsp;%nbsp;%nbsp;310%nbsp;=%nbsp;%nbsp;10.0%nbsp;o/o%nbsp;(processed),%nbsp;%nbsp;%nbsp;9.8%nbsp;o/o%nbsp;(all)
%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;Quarantained%nbsp;:%nbsp;%nbsp;%nbsp;%nbsp;542%nbsp;=%nbsp;%nbsp;17.5%nbsp;o/o%nbsp;(processed),%nbsp;%nbsp;17.1%nbsp;o/o%nbsp;(all)
%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;%nbsp;Delivered%nbsp;:%nbsp;%nbsp;%nbsp;%nbsp;116%nbsp;=%nbsp;%nbsp;%nbsp;3.7%nbsp;o/o%nbsp;(processed),%nbsp;%nbsp;%nbsp;3.6%nbsp;o/o%nbsp;(all)

No large amount of relay attempts either. probably just a few on some days, none of the files exceed 4 blocks (2 Kb) in size. Fine.

New case and components for workstation
Since I found UnReal 5 engine is freely available, I started creating virtual worlds. I started with my workstation consisting of an ASUS TUF X299 Mark1 motherboard, an Intel Core I9 processor with 10 cores, 32 GB memory and a NVidia GTX1080 video card in a Sharkoon enclosure. That card is the bare minimum to run the Unreal Editor, but it does the trick. However, it pushes the system to it’s max so the fans were very busy.
To improve performance, I changed my video card for an ASUS RTX3080, 10Gb memory. It does make a difference, but I quickly found out that all fans should run at their max, to keep GPU and CPU on healthy temperatures: GPU ran up to 80 degrees and CPU 60. When the fans ran at high speed, these were lowered to about 45, with a lot of noise. So I decided I should choose a more airy enclosure, that could hold more fans. I found a good case: Lian-Li O11 Dynamic EVO, and I added 8 fans to cool it all down. And now I’m busy: For some projects you need more memory so I added another 32 Mb. Moving from one case into another was one day, not all completed yet but now I don’t have to worry anymore about temperatures: even when fans are at low or moderate speed and high load using UnReal, GPU temp won’t exceed 55 degrees, and the CPU is kept on a healthy 40.
Still need to finish a few things, but I’m happy with it. The only downside: There is no facility to hold the 2 5.25 inch DVD/BR drives, but I’ll find a solution for that.

Switch to Diana didn’t go as expected
I have run my server on Dione now for over 6 months so I decided it is time to switch to Diana. Yesterday I prepared for a switch: Copy whatever I had done on Dione to Diana (Willibrordpad images, MySQL database and CMS files) and had the system running completely except for a few services that would cause conflicts if running. Tonight, I retrieved the log data shown above, to be added on Diana, after Dione was switched off. A few minor problems activating these services, but all was running in the end, so I could shutdown Dione.
Wrong. Not enough. I should have copied the certificate files now on Dione to Diana as well, but I could indeed access the web. Except for the blogs; for some reason, index.php could not be found. HomeDesk did work and showed that indeed, sysblog:[000000]index.php could not be found. I tried using DCL but $ dir sysblog:[000000]index.php failed to find the file. It is probably a matter of logicals, but this needs to be investigated. . So I restarted Dione and keep it running until this is solved.

CMS program
I picked it up again but had a problem uploading the files to Dahpne (the PWS). I now know what caused it and the solution has been implemented, so as soon as I get started again, I can upload the new files and compile – and create a test program to see if it works

Numpy redone

There still wasn’t a complete build of Numpy using just lapack and blas as an example., si I had to redo the build – from scratch – on the Linux system. Done that and have output to guide me – but whether it is complete and fit for VMS on Alpha, remains to be seen. Combined with Brett’s DCL-procedure, it should be possible to get on.

Start with Numpy

Now XBLAS and LAPACk are done, I can start with Numpy. Brett Cameron has done this before, I can use that as the base for the command procedures that will be like the one I did with SCipy: part by part. Some files have been added by Brett and I added these files to my environment. But there were still some files to be adapted, where internal definitions in the compilers differ: gcc would use “__alpha__” where my (Compaq) C version (7.3) uses “__alpha” to set the CPU type. Otherwise, the CPU type could not be determined. I guess this will nor be the only one.

Once these changes were included, I could start building core.common – the first one already fails beyond repair (all is the same as defined by Brett – and that seemed to work. I just added /deb/noopt, /lis= and /obj= options because that conforms my environment):

$ cc/accept=novaxc_keywords/noopt/deb/names=(as_is,shortened)/define=(_OSF_SOURCE,_USE_STD_STAT)/include=cc$include/warn=disable=(
QUESTCOMPARE,QUESTCOMPARE1)/lis=NUMPY_LIS:/mach/obj=NUMPY_OBJ:/arch=host array_assign.c

static NPY_INLINE int PyInt_Check(PyObject *op) {
......................^
%CC-E-CLOSEPAREN, Missing ")".
at line number 35 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

if (!PyLong_Check(op)) {
.........^
%CC-E-BADEXPR, Invalid expression.
at line number 37 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

#define PyInt_AS_LONG PyLong_AsLong
......................^
%CC-W-MACROREDEF, The redefinition of the macro "PyInt_AS_LONG" conflicts with a current definition because one is object-like and t
he other is function-like. The redefinition is now in effect.
at line number 46 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

#define PyString_Check PyBytes_Check
.......................^
%CC-W-MACROREDEF, The redefinition of the macro "PyString_Check" conflicts with a current definition because one is object-like and
the other is function-like. The redefinition is now in effect.
at line number 89 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

#define PyString_AS_STRING PyBytes_AS_STRING
...........................^
%CC-W-MACROREDEF, The redefinition of the macro "PyString_AS_STRING" conflicts with a current definition because one is object-like
and the other is function-like. The redefinition is now in effect.
at line number 93 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

#define PyString_GET_SIZE PyBytes_GET_SIZE
..........................^
%CC-W-MACROREDEF, The redefinition of the macro "PyString_GET_SIZE" conflicts with a current definition because one is object-like a
nd the other is function-like. The redefinition is now in effect.
at line number 99 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

PyUnicode_ConcatAndDel(PyObject **left, PyObject *right)
................................^
%CC-E-NOTEXPECTING, Error parsing parameter list. Found "*" when expecting one of: ",", ")".
at line number 152 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_SETREF(*left, PyUnicode_Concat(*left, right));
....^
%CC-E-BADEXPR, Invalid expression.
at line number 154 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_SETREF(*left, PyUnicode_Concat(*left, right));
....^
%CC-E-BADSTMT, Invalid statement.
at line number 154 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(right);
....^
%CC-E-BADEXPR, Invalid expression.
at line number 155 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(right);
....^
%CC-E-BADSTMT, Invalid statement.
at line number 155 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

PyUnicode_Concat2(PyObject **left, PyObject *right)
...........................^
%CC-E-NOTEXPECTING, Error parsing parameter list. Found "*" when expecting one of: ",", ")".
at line number 159 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_SETREF(*left, PyUnicode_Concat(*left, right));
....^
%CC-E-BADEXPR, Invalid expression.
at line number 161 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_SETREF(*left, PyUnicode_Concat(*left, right));
....^
%CC-E-BADSTMT, Invalid statement.
at line number 161 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

npy_PyFile_Dup2(PyObject *file, char *mode, npy_off_t *orig_pos)
.........................^
%CC-E-NOTEXPECTING, Error parsing parameter list. Found "*" when expecting one of: ",", ")".
at line number 172 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(ret);
....^
%CC-E-BADEXPR, Invalid expression.
at line number 191 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(ret);
....^
%CC-E-BADSTMT, Invalid statement.
at line number 191 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(os);
....^
%CC-E-BADEXPR, Invalid expression.
at line number 206 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(os);
....^
%CC-E-BADSTMT, Invalid statement.
at line number 206 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(ret);
....^
%CC-E-BADEXPR, Invalid expression.
at line number 211 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(ret);
....^
%CC-E-BADSTMT, Invalid statement.
at line number 211 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(io);
........^
%CC-E-BADEXPR, Invalid expression.
at line number 236 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(io);
........^
%CC-E-BADSTMT, Invalid statement.
at line number 236 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(io_raw);
........^
%CC-E-BADEXPR, Invalid expression.
at line number 242 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(io_raw);
........^
%CC-E-BADSTMT, Invalid statement.
at line number 242 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(ret);
....^
%CC-E-BADEXPR, Invalid expression.
at line number 261 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(ret);
....^
%CC-E-BADSTMT, Invalid statement.
at line number 261 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

npy_PyFile_DupClose2(PyObject *file, FILE* handle, npy_off_t orig_pos)
..............................^
%CC-E-NOTEXPECTING, Error parsing parameter list. Found "*" when expecting one of: ",", ")".
at line number 278 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(io);
........^
%CC-E-BADEXPR, Invalid expression.
at line number 314 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(io);
........^
%CC-E-BADSTMT, Invalid statement.
at line number 314 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(io_raw);
........^
%CC-E-BADEXPR, Invalid expression.
at line number 319 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(io_raw);
........^
%CC-E-BADSTMT, Invalid statement.
at line number 319 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

Py_DECREF(ret);
....^
%CC-E-BADEXPR, Invalid expression.
at line number 340 in file NUMPY_ROOT:[numpy.core.include.numpy]npy_3kcompat.h;1

%CC-F-TOOMANYERR, More than 30 errors were encountered in the course of compilation.

Here I must consult Bret on how to get around this – he must have mastered this before.

XBLAS – requirement for some LAPACK images – built and used

Downloaded xblas and accompanying VMSPATCH container from TU Delft, and installed it after setting up the environment. Again, the content of the patch file was put into the package itself, because including the intended structure would require quite a lot of changes in the VMS build-files.
Started the building process, the only changes needed were (again) splitting some lines that cases problems with LIBR commands – lines exceeding the maximum length of 1091 bytes. Also, one more change was added to VMS_Auto64: reading the sourcefile (unit 42) would fail if the linesize exceeded some length (128?). It was solved by adding recordsize of 512 in the OPEN statement.

XBLAS built without problems in the end.

Now I could finish LAPACK built – one of the link commands required XBLAS…

To make things easy, I created subdirectories for each system – XBLAS, LAPACK, NUMPY and SCIPY – under VMSBuild. Each of these hold the structure:

  • [.EXE] to hoild executables (and shared images)
  • [.LIS] to hold list and mapfiles
  • [.LIB] to hold libraries
  • [.OBJ] to hold .OBJ files
  • and after building the subsystem, al files that are to be used elsewhere, are placed in this structure. Files that are only local will be kept within the package.

    It also meant changes in the procedure creating the environment, and in the procedures that build the subsystem.

    Also, I reversed the usage of symbol vms_auto64 – where the mms-files state “sys$library:vms_auto64” that I commented-out in favour of “vms_auto64”. Main reason for this is that both LAPACK and XBLAS referred to sys$library: for the local object-library, but that resides within the sy=ubsystem itself. It meant I had to redefine sys$library anyway, so the [.EXE] directory that is within VMSBuild – and holds vms_aut64.exe – could be added as well.

    All files will be added to the repository

    Lapack 3.9.0 done

    Installed Lapack 3.9.0 aside 3.8.0, and merged the changes that I had to make in the MMS files into the files of 3.9.0 – except what I had to remove from those in 3.8.0. No problems in building – except lines that are too long, but after adding option “recl=512” when one of the files is opened; it seems that default maximum length for read function is 256 – or less. After I extended this to 512, the error was gone.

    It takes several hours before everything is done – but Lapack 3.9.0 is complete.