First day
Looked into the first (approximately) 24 hours running with the new parameters; not just increased a number of process parameters, but removed some settings required for a number of programs I don’t use anymore, and an increment of page file size (not a requirement but based on minimal values): memory usage (both physical and virtual) have decreased a little from 75% to 50%, but it’s my feeling that mainly due to increased page file sizes.
Paging however, seems the same:

until about 10:00 system time this morning:

It may have to do with PMAS receiving mail, that requires the data to be available. But that has gone on for several hours from midnight, a message per minute; but after about 9:50 messages come in every 5 seconds, so it may well have to do with PMAS – or SYSLOGD writing out messages. Checked the syslogd output – the only available source at the moment – and found the address, residing in Thailand ( so I blocked it from accessing the network.

(To be continued)


Changed system parameters
Remember I had problems with MariaDB and PHP? I knew there were some changes to be done to the system, and where, but to what values? I asked Mark Berryman (who ported PHP and MariaDB to VMS – so he has some experience in the matter) and he came up with another set of values – in the PQL (Process Quota Limits) area; he has the same type of system as I do (DS10, 2 Gb memory) so I changed my system accordingly: some limits doubled, others tripled in value – which makes sense since the original values come from a 256Gb system….

parameter          old       new
-------------- -------   -------
PQL_DFILLM         128       200
PQL_DWSDEFAULT    2352      6531
PQL_MWSDEFAULT    2352      6531
PQL_DWSQUOTA      4704     13062
PQL_MWSQUOTA      4704     13062
PQL_DWSEXTENT   262144   1280000
PQL_MWSEXTENT   262144   1280000

Since WSDDAULT parameters are not dynamic, I had to reboot.
The result is eminent: the blog runs way faster and smoother; but time will tell whether this is right or needs even more adjustments.
I aloo noted an error in calling MySQL shutwond and startup procedures, and corrected them

Next is a WordPress update 🙂

(Done. Now on 4.7.4)

Next to do is trying PHP 5.4 again, to see whether that stays alive.


Cleanup and configuration changes
First of all, I have started a new accounting file – thought it’s time to do so after 5 years: It takes quite some time to get to the latest data (the file is 256 Mb in size…). Next, I extracted the data of the server-executoree (HTTP%NOBODY) after 01-Jan-2017, to find out what mnay cause the PHP problems. It could be a matter of sizing. It looks like it, and that meant I had to change the working set parameters of this user:

UAF> sho http$nobody

Username: HTTP$NOBODY                      Owner:  WASD Scripting
Account:  WEBSRV                           UIC:    [76,1] ([HTTP$NOBODY])
CLI:      DCL                              Tables: DCLTABLES
Flags:  DisNewMail DisMail
Primary days:   Mon Tue Wed Thu Fri
Secondary days:                     Sat Sun
Primary   000000000011111111112222  Secondary 000000000011111111112222
Day Hours 012345678901234567890123  Day Hours 012345678901234567890123
Network:  ##### Full access ######            ##### Full access ######
Batch:    -----  No access  ------            -----  No access  ------
Local:    -----  No access  ------            -----  No access  ------
Dialup:   -----  No access  ------            -----  No access  ------
Remote:   -----  No access  ------            -----  No access  ------
Expiration:            (none)    Pwdminimum:  6   Login Fails:     0
Pwdlifetime:         90 00:00    Pwdchange:  14-AUG-2012 07:49
Last Login: 14-AUG-2012 07:48 (interactive), 13-APR-2017 19:20 (non-interactive)
Maxjobs:         0  Fillm:       500  Bytlm:       500000
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
Maxdetach:       0  BIOlm:      2000  JTquota:       4000
Prclm:         100  DIOlm:      1000  WSdef:         1000
Prio:            4  ASTlm:      2000  WSquo:         4000
Queprio:         0  TQElm:       100  WSextent:     20000
CPU:        (none)  Enqlm:       500  Pgflquo:     500000
Authorized Privileges:
Default Privileges:
Identifier                         Value           Attributes
  WASD_HTTP_NOBODY                 %X8001001D
UAF> mod http$nobody/wsquo=8000/wsextend=30000/biolm=2048/diolm=1024
%UAF-I-MDFYMSG, user record(s) updated

That should make at least some difference, time will tell.

Another addition is a job that should tell me about the workload during some time, it may mean I’ll have to do some changes to system parameters and reboot. But this will take a few weeks to set in.

MariaDb test
I had installed MariaDb 5.5, as ported by Mark Berryman. There were two issue with the creation of SSL certificates: The routine wasn’t found where expected, and though all references are to SSL$ROOT:, there is one that refers to SSLROOT (within one of these procedures). Might have been a local issue, and was easily circumvented.
I copied MySQL database using conversion routines, in stead of creating a new one and loading the export (the backup of then database).
One thing to change anyway is the port to listen on: 3306 is currently in use my MySQL 5.1 that is used by the blogs. So I changed this to 3316, and started the server.
Next I connected using mysql -u root -p – entered my password, and could access the data. But at some point, the server crashed, it seems to occur in LIBRTL. This happened three times, same signature (at first glance).

That means contacting Mark Berryman….


Power failure
Around 23:30 (GMT +2) the power broke down in my neigbourhood, just when I was about to call it a day. It lasted for about 40 minutes, as I found out about 4:00. I restarted Diana, found some changes that I still needed to do for the blog logicals, and restart MySQL for some reason, but all seems well now.
One of the changes still there was using PHP 5.4 – which I left for the moment: It seems to do pretty well. So all in all it might well be that it is not PHP causing problems, but MSQL – something I noted earlier; this is a fresh instance and the speed the blog runs on now is remarkable.
Time to switch to MariaDB ?

Weird, though: I have a VT400 as terminal on Diana, all it shows on startup is the banner up to the notion it jumps to the loader – nothing on console on the startup sequence like you normally would get….

(as it turned out: 5.4 does give trouble: this post couldn’t be published, and running the blog gave an error….So I reversed to 5.2)


All the same – and some investigation started.
No surprises.

PMAS statistics for March
Total messages    :   2802 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :    529 =  18.8 o/o (Files: 31)
Accepted by PMAS  :   2273 =  81.1 o/o (Files: 31)
  Handled by explicit rule
         Rejected :   1488 =  65.4 o/o (processed),  53.1 o/o (all)
         Accepted :    151 =   6.6 o/o (processed),   5.3 o/o (all)
  Handled by content
        Discarded :    364 =  16.0 o/o (processed),  12.9 o/o (all)
     Quarantained :    251 =  11.0 o/o (processed),   8.9 o/o (all)
        Delivered :     19 =    .8 o/o (processed),    .6 o/o (all)

The number of relay attempts was down last months. there were two days with a higher amount (files just over 40 blocks in size), but all the same address ( – a hosting site in Sacramento (USA)) faking an address in my domain. Since the mail didn’t originate from the inside (and therefore lacks the mail server address) it’s rejected.

  • 18-Mar, between 00:54:42.23 and 00:57:02.37 (145)
  • 26-Mar, between 09:54:58.68 and 09:57:19.61 (150)
  • A few more but that were single attempts.

    WP will be updated this week.

    Started examining the reason why PHP 5.3 gives me such trouble, I’ll be evaluating PHP 5.2 performance first to get at least some ide of what is going on in the system when running PHP…


    Apart from what happened last month, there is not much to look at. PMAS does its work:
    PMAS statistics for February
    Total messages    :   2534 = 100.0 o/o
    DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
    Relay attempts    :     73 =   2.8 o/o (Files: 28)
    Accepted by PMAS  :   2461 =  97.1 o/o (Files: 28)
      Handled by explicit rule
             Rejected :   1682 =  68.3 o/o (processed),  66.3 o/o (all)
             Accepted :    200 =   8.1 o/o (processed),   7.8 o/o (all)
      Handled by content
            Discarded :    278 =  11.2 o/o (processed),  10.9 o/o (all)
         Quarantained :    264 =  10.7 o/o (processed),  10.4 o/o (all)
            Delivered :     37 =   1.5 o/o (processed),   1.4 o/o (all)

    Just the number of rejected messages is larger than normal, I’ve seen them coming in in the last week only; 26-Feb-2017 being most: Looking at the size of operator.log, it was over 1200 blocks on that day; the others that week were over 400, except for one, where less than 100 should be normal. The number of relay attempts was little; only on 08-Feb the attempts resulted in a log that was over 4 blocks in size, and mainly from one source – trying to relay. It could have been a test, sending from address as “antispam@nmap.scanme.org”, “antispam@diana.intra.grootersnet.nl” or “antispam@[]” to a number of addresses all related to the same organization. I checked this address and it is listed in a number of blacklists, so it might as well be an attempt to see if there is a way to abuse the mailserver. But that checks the IP address of the sending server and if it not from my own address, and the recipient is outside my domain, it will fail.
    As simple as that.

    I had some trouble installing OpenVMS on the Itanium servers – one at least. It would find the DVD, start reading it but then halt. First, I thought it could have been a bad DVD, so I tried to read it on my old PWS, and I could access the files (not run the executables because these at I64 images, not AXP…). The DVD wasn’t as bad as I thought it was….
    So first I could try to make it accessible over the network: meaning I would have to start Infoserver on the PWS (which should be possible since that runs VMS 8.4). At last, found the documentation on the Internet to set it up, but the docs were a bit limited but with the examples, I think I had it all right, but in the end, I couldn’t start Infoserver on that box – still have to find out what caused it to fail.
    Second, I found out that I need to enable the iLO unit first – meaning I had to connect it the the network (it will be set up using DHCP to begin with), see what address was assigned to it – with dhcpdbdump, the MAC address is recognizable as from the Itanium server) and access MP on the iLO using telnet (it’s on the local network so why bother about security?). Now I could boot from internal DVD and installation did start and finish. The only thing yet to do is to install the licenses and do the TCPIP configuration (and give the iLO its own. fixed address (and name)). BTW: The first Itanium is now named Iris.

    No news on the PHP front
    There are a few things to consider.
    First, in the WASD global configuration I have a line:



    causing PHPWASD to run whenever there is an extension .PHP found. I’m pretty sure it will run the executable the logical PHPWASD refers to, because otherwise there would have a version conflict with PHPSHR.EXE: Each version I have on the system resides in its own directory, referred to by logical PHP_ROOT:. This is the item that is used when I run PHP_INFO.PHP, there is no other reference elsewhere to this script; And it shows all the correct data – with the correct version at that time.

    However, in the mapping, the blogs have their own reference:

    redirect /sysblog /sysblog/index.php
    map /sysblog**/ /sysblog*/index.php
    exec+ /sysblog/**.php* (phpwasd:)/sysblog/*.php* ods=5
    pass /sysblog/000000/* /sysblog/* ods=5 search=none dir=noaccess
    pass /sysblog/* /sysblog/* ods=5 search=none dir=noaccess

    which runs PHPWASD (the logical – explicitly via the logical) by it’s own rule.
    Now what happens if BOTH start running? It might mean that the one that I expect to run (the one in the mapping) will run into an I/o error, or it might not be able to access a sourcefile; or it may finbd it’s access to the database is blocked, causing a timeout in database access (as is shown in the PUP error log file).

    Another possibility that has crossed my mind: In the past I noted that PHP 5.3 and up will run a larger number of sub-processes. It might be that I have run out of process slots, or that the parsing, translating and execution of PHP code takes a far larger amount of system resources, causing the script not finishing in time (that is noted too, so I doubled the maximum execution time), but it might be the time to finish database transactions may have to be increased too. Another (and perhaps, better) solution is to increase the working set of the PHPWASD: processes: It hasn’t been changed since I started running PHP on a 256Mb system….Now I’ve seen that the peak working set can be increased – given the number of pagefaults…

    So these are paths to consider. I didn’t get an answer of Mark Berryman yet.


    Back to the beginning
    Publishing a post, or updating one, proved to be impossible. Whatever done, publishing it would end in an error:

    Status: 502
    Script-Control: X-error-text="Cannot access script, i/o error.."
    Script-Control: X-error-module="PHPWASD"
    Script-Control: X-error-line=1337

    and afterwards, there is part of the request submitted – including the text I added:

    In PHP_errors since last night, theer is just one message, every 3 minutes or so:

    PHP Fatal error: Maximum execution time of 60 seconds exceeded in Unknown on line 0

    so I decided to revert this update until the system is more stable…


    Still issues with 5.4
    For some reason access to any blog fails due to an error signalled by the PHP engine: failure to access a script: IO error. But it doesn’t tell which one, and it’s not signalled in the error log file. If one blog fails, all will – until the cache is flushed and all PHP-connections are aborted.
    This not just happens with this blog but with Travels as well, and with my friend’s site. Got inn trouble there to start with, I installed a plugin for agenda (linked to Google agenda) and when setting it up, trouble seems to happen. One thing however was found after properly assigning Tracks: had it defined to the wrong directory (but all seemed to be there): that one failed to finish database access within the time set in PHP.ini (30 seconds); This has now been extended to one minute.
    But even adding this simple post made the server freeze. – I couldn’t publish it, and when returning at some point, I lost connection to some scripts that take care of the look-and-feel of the dashboard. It seems to happen after the content has been saved as draft automatically….

    So I disabled 5.4 and started 5.3; See if that helps (it is the minimum I need for the agenda software). But the problem exists here as well. However, it will get back to activity – after some time (perhaps it’s just the save that takes too much time?)


    Update succeeded
    I renamed the directory holding the ‘bad’ WP version, and renamed the directory holding the correct version to the proper name, so all I needed to do next was tell WASD to restart.
    Next, I set the PHP version to 5.4

    That’s what you’re looking at now.

    I have version 5.5 and 5.6 also on the system but I’m not sure the startup procedures have been updated to my setup. So that needs to be checked first; if all is well, I nay update PHP even further.


    More on PHP 5.3 and up: Continued
    Discussed the matter on the WASD-INFO list – and agreed it is a local issue: Mark Daniel has checked the installation of WordPress on his systems and he found no extra bytes. The only thing that may have caused the problem is unzip. The executable on Diana is quite old, and I found the latest (6.0) on info-zip.com. Downloaded it, built it on VMS and used it to install a separate version of WordPress. There are no extra bytes (good), all directories are lowercase now, files look good – but still, multiple dots in the filenames still occur, so the wp2vms procedure is still needed (ran it anyway to find out). For that, I set up a logical, and next, defined SYSBLOG to use it.
    Well, this post has been added using this version!
    It means I have to do some extra work, so all blogs run this version. After that, higher versions of PHP will probably work now.