Month: September 2015

Moved the images of Trips, Tracks and Travels
The size of the logical disk containing the images of our “expeditions” was extended once before to 15 Gb, but even that is not sufficient; the next bit: our fall trip into Germany (2 years ago – it’s finally done) won’t fit, let alone what is still to come (there still is some work to be done). I do have spare 32Gb disks available so I decided to $ INIT one of them and move the whole directory tree containing the images over to a new directory on that disk, and add the latest album. To access them, I added this directory into the logical that contains all that is part of this environment (including the blog), leaving the now (hopefully) obsolete tree intact:

$&nmsp;sho&nmsp;log&nmsp;tracks
&nmsp;&nmsp;&nmsp;"TRACKS"&nmsp;=&nmsp;"web_disk2:[public.trtrtr.]"&nmsp;(LNM$SYSTEM_TABLE)
&nmsp;&nmsp;&nmsp;&nmsp;&nmsp;&nmsp;&nmsp;&nmsp;=&nmsp;"web2016:[trackimages.]"&nmsp;&nmsp;
&nmsp;&nmsp;&nmsp;&nmsp;&nmsp;&nmsp;&nmsp;&nmsp;=&nmsp;"web_disk2:[blogs.tracks.]"
&nmsp;&nmsp;&nmsp;&nmsp;&nmsp;&nmsp;&nmsp;&nmsp;=&nmsp;"wp43:"
1&nmsp;&nmsp;"WP43"&nmsp;=&nmsp;"web_disk2:[private.wp43.]"&nmsp;(LNM$SYSTEM_TABLE)

Because of this, there was no need at all to add anything in the WASD configuration because all that is referred to is this logical configuration:
redirect /tracks /tracks/index.php
map /tracks**/ /tracks*/index.php
exec+ /tracks/**.php* (phpwasd:)/tracks/*.php* ods=5
pass /tracks/000000/* /tracks/* ods=5 search=none dir=noaccess
pass /tracks/* /tracks/* ods=5 search=none dir=noaccess


Of course, this double definition of the image directory isn’t needed at all. Since all data is copied, the old environment can simply be made inaccessible, by one simple DCL statemnent:


$ def/sys/exec tracks web2016:[trackimages.]/transs=conc, -
_$ web_disk2:[blogs.tracks.]/trans=conc, -
_$ wp43:/trans=conc


without touching anything else.

How I love the elegance of OpenVMS 🙂

Setting up a development environment
For some contrast…
I have two Personal Workstations at had: both 256 Mb, Alpha EV56 at 500 Mh – though one has been speeded up to run at the top available: 600 Mhz – it means that the PCI and memory busses are at full speed as well.
This machine got the memory of the other so it now has a whopping 512 Mb of memory 🙂
Meet Daphne: OpenVMS 8.4, booted in the cluster but with it’s own environment, compilers at all. The disk was thought to be 9Gb but turned out to be a 4.3 Gb one. It contained MySQL, SWS, WASD and WordPress versions so there was little room left. So all this was removed as well as any other data – since the system is booted into the cluster and all disks are designed to be mounted clusterwide, I can use the abundant space on Diana for storage, but have the work done on Daphne.
So far, it’s all as expected.
I could stop here and start developing, but I promised eCube half a year ago to do some testing on their development (Eclipse-based) platform; I proposed a small addition (to be abled to use it on a rooted environment where different parts of an application are stored in separate sub-trees) so I needed to install some extra software: the Nxtware Remote toolsuite. That needs Java and GNV, the toolbox to Unixify an OpenVMS environment to ease porting of *x based software more easily.
Installing the IDE (eCube Nxtware) is no problem.
Installing JAVA is no problem.
Installing GNV is no problem. Well, mostly; there are a few updates to be installed but the question is where to get them? There are several places on Sourceforge and the documentation on the site isn’t exactly helping… Installed these, but it is questionable whether these are really the lastest versions (I found newer ones yesterday…)
Configuring Nxtware shows I need to change a few system and process parameters. Process parameters for Java (otherwise it may not work), system parameters likely for the Nxtware server process. After that, configuration starts with extracting files that will be needed by either the server or clients – and there trouble starts: It cannot extract and process < .PAS> en < .COB> files; but otherwise it seems to run ton the end. Starting the server will tall….

But first, I’ll read the docs.

Stable
This shows that after the last reboot (when the new memory was installed) the load on CPU, process slots and memory has stablelized:

So it’s only memory usage that increased up to the current level and doesn’t change very much – just a spike that is consistent with the extra processes, and so is paging: New processes require memory and of course, this must be acquired and distributed – hence tis paging.
These spikes in number of processes. memory usage and paging occur between 6:45 and 7:00, and between 18:45 and 19:00, every day. You might expect (as I did :)) that there is a batch job that runs at these moments, but $SHO QUE shows none:
$ sho que
Batch queue BACKUP, idle, on DIANA::

Printer queue DCPS_QUEUE, idle, on DIANA::"IP_RawTCP/192.168.0.251:9100",
  mounted form DCPS$DEFAULT (stock=DEFAULT)

Printer queue HPTN2100, stopped, on DIANA::"192.168.0.251:9100",
  mounted form DEFAULT

Batch queue NORMAL, idle, on DIANA::

Generic batch queue SYS$BATCH

  Entry  Jobname         Username             Status
  -----  -------         --------             ------
    218  PreciseMail Stats
                         SYSTEM               Holding until  9-SEP-2015 15:05:00
    207  PreciseMail Notify
                         SYSTEM               Holding until  9-SEP-2015 15:30:00
    190  reset_syslog    SYSTEM               Holding until 10-SEP-2015 00:00:00
    191  scan_log        SYSTEM               Holding until 10-SEP-2015 00:00:00
    192  do_backup       SYSTEM               Holding until 10-SEP-2015 00:00:00
    195  PreciseMail Nightly
                         SYSTEM               Holding until 10-SEP-2015 00:05:00
    200  PreciseMail AutoUpdate
                         SYSTEM               Holding until 10-SEP-2015 02:00:00
    810  save_logs       SYSTEM               Holding until  1-OCT-2015 01:00:00

Generic printer queue SYS$PRINT

Batch queue SYS$START, stopped, on DIANA::

Batch queue T4$BATCH, available, on DIANA::

  Entry  Jobname         Username             Status
  -----  -------         --------             ------
    143  T4$COLLECT      SYSTEM               Executing
    189  T4$COLLECT      SYSTEM               Holding until  9-SEP-2015 23:59:00

Generic server queue TCPIP$SMTP

Generic server queue TCPIP$SMTP_DIANA_00

Server queue TCPIP$SMTP_DIANA_01, stopped, on DIANA::, mounted form DEFAULT

Server queue TCPIP$SMTP_DIANA_1, idle, on DIANA::, mounted form DEFAULT

So now it is a matter of looking for logfiles created on these moments; perhaps $ ACCor $ ANA/AUDIT will show something 🙂
Track images moved
The images of all our trips, tracks and travels now take about 10 Gb – almost the full size of the logical disk that contains all of the web data. Adding another 1 Gb (or more) of the Lahn Wanderweg (walked in 2014), now (almost) ready for publication, would not fit. So I added another 32Gb disk to the system, initialized it and mover all the images to that physical disk. I could of course have created a logical disk of sufficient size (say 20Gb) which is, indeed, easier to move, and backup (just a single file); but I can do so on the current disk, once the files have been removed, the original logical disk could be used as well; just adding the other files to this drive as well – bit by bit – and re-create the disk-containers on that disk once more – in the appropriate size.
This move however gives me time and space to maneuver.
Another addition: Images and videos of Tessa – our Little Black Devil. Video won’t show fluently at the moment because the disk is heavily loaded (because backup of the track-images).

PHP messages
Over the last week – running without throttle, an elevated execution time for PHP scripts and the max of internal memory, PHP seems to work fine; it may be faster (and probably will be) if PHPSHR.EXE is installed, a step to be taken this weekend.
All messages I had in this period:
6 times:

%%%%%%%%%%% OPCOM 1-SEP-2015 09:48:06.60 %%%%%%%%%%%
Message from user HTTP$SERVER on DIANA
Process WASD:80 reports
%HTTPD-W-NOTICED, CGI:1997, not a strict CGI response
-HTTPD-I-SCRIPT, /sysblog/wp-admin/admin-ajax.php (sysblog:[wp-admin]admin-ajax.php) phpwasd:
-HTTPD-I-CGI, 504850205761726E696E673A20204D6F64756C652027646F (2048 bytes) PHP Warning: Module 'dom' already loaded in Unknown on line 0.


(of course on different times, but always in the same module)
and one:

%%%%%%%%%%% OPCOM 3-SEP-2015 13:11:24.71 %%%%%%%%%%%
Message from user HTTP$SERVER on DIANA
Process WASD:80 reports
%HTTPD-W-NOTICED, CGI:2107, not a strict CGI response
-HTTPD-I-SCRIPT, /sysblog/index.php (sysblog:[000000]index.php) phpwasd:
-HTTPD-I-CGI, 2553595354454D2D462D41434356494F2C20616363657373 (118 bytes) %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000592C000, PC=FFFFFFFF8083D9B8, PS=0000001B


Of course the reason may have been that there was no traffic – but that is not the case: WASD logfiles do show quite a number of entries to SYSBLOG and TRACKS- and not just the ones by the worker processes (since these originate from my address, they won’t be shown there, these are filtered out).

Maintetnance
The regular maintenace job has shown no surprises, except that the number of messages is low – less than 1000:

PMAS statistics for August
Total messages    :    976 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :    128 =  13.1 o/o (Files: 26)
Accepted by PMAS  :    848 =  86.8 o/o (Files: 29)
  Handled by explicit rule
         Rejected :    308 =  36.3 o/o (processed),  31.5 o/o (all)
         Accepted :    229 =  27.0 o/o (processed),  23.4 o/o (all)
  Handled by content
        Discarded :    160 =  18.8 o/o (processed),  16.3 o/o (all)
     Quarantained :    124 =  14.6 o/o (processed),  12.7 o/o (all)
        Delivered :     27 =   3.1 o/o (processed),   2.7 o/o (all)

System usage shows the changes in memory of last month: from 512 Mb to 2 Gb, back to 512 Mb due to memory issues, up to to 1.5 Gb after the big outage and latest to 2 Gb valiud memory (where all has been replaced. The differences in CPU-usage haven’t changed much, nor has IO, direct (being disk), buffered and network (mainly internet) though there are slightly less buffered IO’s since throttling has been disabled:

The system seems to be very stable now, so AUTOGEN can be run shortly…