New development environment
having worked with a graphical IDE for the last 4 years (using Delphi on Windows in my daily job) I think it’s time to install something similar on de VMS boxes. I have used the HP(E) supplied NetBeans solution on my PWS – which is way too small to run such a heavy Java application in it’s 256 Mb memory. But it’s free…
Nevertheless, it hasn’t been updated for years and there is a newer kid on the block – Eclipse based, with a Java component on the VMS side. Since the basis is Unix/Linux based, you’ll also need GNV – GNU for VMS: Nxtware-remote, by eCube. I had it all on Diana but it has been years ago that I had it installed – so I re-installed Java and GNV – the latter has been quite a challenge, since though it looked as if the installation succeeded, it didn’t. Even manually removing the whole installation by hand failed.
As it turned out, it might have been that, due to getting the whole thing on the system, there was a link set up that needed to be removed – using GNV programs. That I just deleted….Luckily I had the whole lot on Dahpne, being a cluster member I could copy what I needed: mnt.exe and umnt.exe. Setting up foreign commands to use them:
$ mnt := PSXROOT:[bin]mnt.exe
$ umnt := PSXROOT:[bin]umnt.exe

I could figure out what to do:
$ mnt

shows mounted file systems and mount points, so
get rid of the link – and now re-installation completed..

After that, I could install Nxtware-Remote, and start $ @NXTware-Remote_Configure to set it all up. Now it proved needed to changes a number of SYSGEN parameters (and a number of process quota). Done so, and so I needed a reboot.
Because I had done some cleanup since last boot, a few things didn’t go as planned: MaraiDB didn’t start, not did the webserver. This was caused by specifying a logical that I removed (since it was completely obsolete – a residue from an older instance – and disk. After I updated the startup files for the webserver, it did start, but the database still failed. Since this is done on batch, where SUBMIT has /NOLOG parameter, you’re in the dark. After adding a logfile to the SUBMIT command, I found out the reason: Since the server runs under user MYSQL051_SVR, this needs to login – but it has a captive commandfile:

Username: MYSQL051_SRV Owner:
Account: MYSQL051 UIC: [37775,1] ([MYSQL051,MYSQL051_SRV])
Flags: DisCtlY DefCLI LockPwd Restricted DisWelcome DisNewMail DisMail
DisReport DisReconnect

and logical MYSQL051_ROOT has also been removed…After I added the definition to the command file starting the database server, it started.

A hard test of the startup procedures, but now these are corrected, next startup should go fine.

Now it’s waiting for the licences

WordPress update
Starting the blog to create this post, I was notified a new version of WordPress was available (4.9.2) – so I downloaded it (and Aksimet 4.0.2, thatmatches this version) and installed them.

Next advantage of restart of the webserver: Since some process workingset quota have been enlarged, it seems the blog is faster …
Perhaps I can now run a higher PHP version as well.


More on certificate renewal
Comparing genealogy (wichh got the certificate a few days ago) and both webmail and homedesk made it clear that the mapping for the certificates is fine:

map /.well-known/acme-challenge/* \
/wcme/.well-known/acme-challenge/* map=once
script /wcme* /cgi-bin/wcme*
pass * 403

# ...

but authorization wasn’t:

#/.well-known/* read

/* read+write

so nothing could be done on port 80…Obvious, since access to both webmail and homedesk require authentication. For genealogy, unauthorized access is an option, so here it states

/* read
/public/* read

and so I changed the settings for webmail and homedesk accordingly, and now the certificates were created and stored in place.
But the browsers still complained about the invalidity of the certificates, even after clearing the bowser and server caches. The only way to get around it was to restart the server (from the web-admin page, or by
$ httpd/do=restart from the commandline – the same thing.

Now wait until April, for the next renewal…

I wrote a small report on all issues on the WASD mailing list.


Cleaning up 2017
The new years starts with some house-keeping of last year. No surprises, mail is still mostly rubbish:

PMAS statistics for December
Total messages    :   3082 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :    405 =  13.1 o/o (Files: 31)
Accepted by PMAS  :   2677 =  86.8 o/o (Files: 31)
  Handled by explicit rule
         Rejected :   1836 =  68.5 o/o (processed),  59.5 o/o (all)
         Accepted :    171 =   6.3 o/o (processed),   5.5 o/o (all)
  Handled by content
        Discarded :    445 =  16.6 o/o (processed),  14.4 o/o (all)
     Quarantained :    204 =   7.6 o/o (processed),   6.6 o/o (all)
        Delivered :     21 =    .7 o/o (processed),    .6 o/o (all)

Just two days show a larger amount of relay attempts:

  • 14-DEC-2017 03:26:10.51 to 03:29:14.29 (190) (
  • 22-DEC-2017 04:20:08.50 to 04:24:03.01 (184) (
  • trying to send a mail from a (bogus user)@grootersnet.nl to 1029mandaditos@gmail.com, both addresses are owned by Hostwinds.com. Quite possible that the router should have blocked them, since I’ve blocked addresses from Hostswinds.com there, but it is possible that these addresses are not properly set (both are /17 addresses according analysis, and since the sender address is forged, so could be the sender address…)
    Anyway, I notified hostwinds.com of these attempts – there have been similar attempts in November).

    BTW: A (real user)@grootersnet.nl to any other outside address will fail as well, since PMAS has a rule to reject any grootersnet.nl sender from outside the local domain…

    Next is a manual job: Moving all 2017 data into one location. That’s the next job tonight.

    Failed certification renewal
    There were a few things to do here.
    First, I needed to update WCME, I was still running the first version (1.0.0) and a new one (1.2.0) was already downloaded but never moved to VMS and installed there. So that was the first activity to do. Next, it failed – again – even after replacing the INSTALLed executable. As it turned out, it was a matter of directory access protection. After that, genealogy.grootersnet.nl got a new one, but webmail and homedesk failed again – due too many failed renewals. So I have to wait some time and retry. But since genealogy.grootersnet.nl does have the new certificate, I guess these two will be renewed as well soon.


    WordPress update
    As stated on my last post, there is a new WordPress version: Just installed it, so now running WP 4.9.1.

    Not related (because I’ve seen this before:

    Connection lost. Saving has been disabled until you’re reconnected. We’re backing up this post in your browser, just in case.

    I know there are some issues with timing, probably, especially in the admin environment (normal user is slow as well, but admin is worse….) Artea for investigation – but without the PHP code it will be hard to locate the problem. (There is no good way to debug the WP code…).
    Changed some parameters in php.ini, see if that helps….


    All the same
    Once more, no surprises in the monthly maintenance job. The vast majority of mail has been rejected on explicit rules, or by the content:

    PMAS statistics for November
    Total messages    :   4463 = 100.0 o/o
    DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
    Relay attempts    :    622 =  13.9 o/o (Files: 30)
    Accepted by PMAS  :   3841 =  86.0 o/o (Files: 30)
      Handled by explicit rule
             Rejected :   3024 =  78.7 o/o (processed),  67.7 o/o (all)
             Accepted :    187 =   4.8 o/o (processed),   4.1 o/o (all)
      Handled by content
            Discarded :    423 =  11.0 o/o (processed),   9.4 o/o (all)
         Quarantained :    183 =   4.7 o/o (processed),   4.1 o/o (all)
            Delivered :     24 =    .6 o/o (processed),    .5 o/o (all)

    The number of relay attemps have been larger this month, especially on 5th, 16th and 30th – all files contained almost 180 attempts, and I found the attempts originated from two networks, both leading to Hostwinds1 in Tulsa (US), trying a fake grootersnet.nl user sending to 1029mandaditos@gmail.com:

  • 5-NOV-2017 03:23:11.22 – 03:26:33.68 (175 attempts from
  • 16-NOV-2017 20:04:23.00 – 20:12:07.85 (178 attempts from
  • 30-NOV-2017 00:22:01.61 – 00:58:39.57 (187 attempts from
  • Hostwinds.com has been notified of this, and the networks have been excluded for access – in the router – for some time. I’ll keep an eye on these addresses.

    Next WP update pending 🙂


    Maintenance report
    Nothing wrong with the maintenance job:
    PMAS statistics for October
    Total messages    :   4087 = 100.0 o/o
    DNS Blacklisted   :    108 =   2.6 o/o (Files:  1)
    Relay attempts    :     26 =    .6 o/o (Files: 31)
    Accepted by PMAS  :   3953 =  96.7 o/o (Files: 31)
      Handled by explicit rule
             Rejected :   3074 =  77.7 o/o (processed),  75.2 o/o (all)
             Accepted :    190 =   4.8 o/o (processed),   4.6 o/o (all)
      Handled by content
            Discarded :    400 =  10.1 o/o (processed),   9.7 o/o (all)
         Quarantained :    253 =   6.4 o/o (processed),   6.1 o/o (all)
            Delivered :     36 =    .9 o/o (processed),    .8 o/o (all)

    Even no large anti-relay files. Most have a few entries, but none is larger than 4 blocks (2Kb)

    More on PHP
    I changed the workingset parameters of the WASD scripring user (HTTP$NOBODY) because these may cause problems with PHP:

  • Bytelm 50000 to 1000000
  • wsdef 1000 to 2048
  • wsquo 8000 to 131072
  • wsextent 30000 to 524298
  • pgflquo 500000 to 1000000
  • but that didn’t make any difference for this, just that the blogs run faster, at least without updates… But PHP 5.4 and up won’t run once it fails. Though Mrak said that the adapted PHPWASD version would output the io-error code, none is shown. What I do see are the settings of the HTTP$SERVER account (that is: What’s left of the quota): Large enough.
    |19:53:51.14 CGI 1374 0004 CGI VARIABLES 1,632 bytes|
    |19:53:51.21 CGI 2214 0004 CGI NOT a strict CGI response!|
    AST:1944/2000 BIO:1949/2000 BYT:4953856/4999424 DIO:998/1000 ENQ:450/500 FIL:286/300 PGFL:461376/500000 PRC:0/100 TQ:97/100
    |19:53:51.21 ERROR 0437 **** INTERNAL CGI:2215, not a strict CGI response|
    |19:53:51.22 ERROR 1122 0004 RESPONSE DCL:5321 (basic-only) 502(502) "Script did not provide an acceptable response."|
    |19:53:51.23 GZIP 1008 0004 RESPONSE DEFLATE no, minimal content-length|
    |19:53:51.23 REQUEST 1162 0004 REQUEST STATUS 502 (Bad Gateway) rx:377 tx:917 bytes 0.109368 seconds 11,831 B/s|

    It’s getting worse. At some point, there is another response: The browser cannot find the site, and WATCH shows:
    |20:15:49.47 CGI 1374 0002 CGI VARIABLES 1,642 bytes|
    |20:15:49.47 REQUEST 1162 0002 REQUEST STATUS 000 (Unknown Code!) rx:389 tx:0 bytes 0.002929 seconds 132,787 B/s|

    But when requested immediately after a restart, the site – even the admin pages – will show when the URL is entered in the browser – but next actions will cause the same error – even:

    |20:18:14.11 CGI 1374 0002 CGI VARIABLES 2,023 bytes|
    |20:18:14.11 NET 1802 0001 CONNECT ACCEPTED,38057 on http://www.grootersnet.nl,80 ( BG37011:|
    |20:18:14.11 CGI 2326 0002 CGI RESPONSE header line 1 'Status: 502' 11 bytes|
    |20:18:14.11 CGI 2326 0002 CGI RESPONSE header line 2 'Script-Control: X-error-text="Cannot chdir("/tracks/wp-admin"), i/o error."' 84 bytes|
    |20:18:14.11 CGI 2326 0002 CGI RESPONSE header line 3 'Script-Control: X-error-module="PHPWASD"' 40 bytes|
    |20:18:14.11 CGI 2326 0002 CGI RESPONSE header line 4 'Script-Control: X-error-line=1384' 33 bytes|
    |20:18:14.11 CGI 2588 0002 CGI RESPONSE stream mode|
    |20:18:14.11 ERROR 1122 0002 RESPONSE PHPWASD:1384 (basic-only) 502(502) "Cannot chdir("/tracks/wp-admin"), i/o error."|
    |20:18:14.11 GZIP 1008 0002 RESPONSE DEFLATE no, minimal content-length|
    |20:18:14.11 REQUEST 1162 0002 REQUEST STATUS 502 (Bad Gateway) rx:748 tx:917 bytes 0.006836 seconds 243,581 B/s|

    even when CGI-compliance is disabled….

    WordPress update
    Nevertheless, the update of WordPress (to 4.8.3) was straightforward.


    Internet connection broken
    Yesterday at 11:15 (or so) the internet connection was down at my ISP – it looked like a broken cable. They rerouted at the end of the afternoon so in the evening I did have connectivity again. This morning however, it was down again for a few hours, due to repair. Why they removed rerouting before the rupture was repaired – I don’t know. But it’s not the right thing to do ….
    PHP again
    Mark Berryman gave me something to work with: looking whether it is memory that causes problems with PHP7. He explained there are several big differences between versions 5 and 7: 7 id fully 64-bit and checks memory boundaries, something PHP 5 (32 bit) doesn’t. So the idea is to switch memory checks off by defining
    and he supplied special builds of the WASD PHP engine – but didn’t tell what the changes imply: Logging?

    Tried them this evening – but without result.

    I also set the memory boundary in PHP.INI to 512M – four times from the original. But even that didn’t help.

    So back to the version that does work…

    (There may be an issue with the database: Connection is lost, at times.. Perhaps PHP 5.2-13 does have problems as well??)


    PHP updates are a problem
    Installed PHP 7.0 tonight and set things up.
    The blogs show up once but on login, the site fails with a 502 error: Seems to be an IO error on PHPWASD (which is the PHP7.0 version of PHPWASD.EXE) but the problems seems to lay elsewhere, because the logfile states:
    %HTTPD-W-NOTICED, 30-OCT-2017 20:56:35, CGI:2215, not a strict CGI response
    -NOTICED-I-SERVICE, http://www.grootersnet.nl:80
    -NOTICED-I-URI, GET (8 bytes) /Tracks/
    -NOTICED-I-SCRIPT, /tracks/index.php tracks:[000000]index.php (phpwasd:) TRACKS:[000000]index.php
    -NOTICED-I-CGI, 2544434C2D572D414354494D4147452C206572726F722061 (50 bytes) %DCL-W-ACTIMAGE, error activating image PHPWASDSHR
    -NOTICED-I-RXTX, err:0/0 raw:330/0 net:330/0

    Even after restarting WASD. After that, normal access is no problem, until login is attempted – and I get the same error: need to restart the server before I can access the site again….

    I also tried 5.4 – which did work. But that is now failing also – from the beginning.

    So back to 5.2-13, for now…
    Later, I retried 5.4. It seemed to work, but posting an update to this post caused it to fail, for some reason. A second try didn’t, so the verdicht should be “unstable”. WATCH showed this error also:

    215108 .72 DCL      5813 0003 DCL        WRITE CGIPLUSIN %X00000001
    215108.72 DCL      5813 0003 DCL        WRITE CGIPLUSIN %X00000001
    215108.72 DCL      5068 0003 DCL        READ SYS$OUTPUT %X00000001 158 bytes
    53746174 75733A20 3530320D 0A536372 6970742D 436F6E74 726F6C3A 20582D65 Status 502..Script-Control X-e
    72726F72 2D746578 743D2243 616E6E6F 74206163 63657373 20736372 6970742C rror-text=Cannot access script,
    20692F6F 20657272 6F722E2E 220D0A53 63726970 742D436F 6E74726F 6C3A2058  io error....Script-Control X
    2D657272 6F722D6D 6F64756C 653D2250 48505741 5344220D 0A536372 6970742D -error-module=PHPWASD..Script-
    436F6E74 726F6C3A 20582D65 72726F72 2D6C696E 653D3133 34390D0A 0D0A     Control X-error-line=1349....
    215108.72 CGI      2326 0003 CGI        RESPONSE header line 1 'Status 502' 11 bytes
    215108.72 CGI      2326 0003 CGI        RESPONSE header line 2 'Script-Control X-error-text=Cannot access script, io error..' 64 bytes
    215108.72 CGI      2326 0003 CGI        RESPONSE header line 3 'Script-Control X-error-module=PHPWASD' 40 bytes
    215108.72 CGI      2326 0003 CGI        RESPONSE header line 4 'Script-Control X-error-line=1349' 33 bytes
    215108.72 CGI      2588 0003 CGI        RESPONSE stream mode
    215108.72 ERROR    1122 0003 RESPONSE   PHPWASD1349 (basic-only) 502(502) Cannot access script, io error..
    215108.72 DCL      5921 0003 DCL        WRITE HTTP$INPUT 181 bytes

    But nothing of this was shown on screen – it all looked fine on the screen. Perhaps it’s just in the administration panels…


    All blogs on MariaDB
    Tonight I installed the latest version of MariaDB that has been published on OpenVMS (5.5.58) and moved all blogs to that version. Or stated otherwise: phased out MySQL 5.1.43, that served me well for several years. Since my requests have been included (ask what port to be used – not 3306 since yoy may have multiple database engines running…) this went fine: Copy the MYSQL databases to MariaDB and convert them. It meant I needed to redo the changes I did on the Trips, Tracks and Travels blog but since these are minor, it was not much of a problem. Added a new entry as well.
    So far, it seems that this blog is faster than the other, but time will tell about the full performance.
    If all runs well for some time, the next step is to update PHP – preferably to the latest version (7.0.24) that has been set up – but not yet activated.