DECNet hickup Revisited

Yesterday I learned how to translate the MAC address in the message to a DECNet address: Take the last two bytes, swap them, convert to decimal number, DIV and MOD by 1024 and you end up with network.node. As it turns out to be 21.01 – or the machine itself. That makes sense: HTTP$NOBODY is the CGI-user of the WASD server. Now locate service number 17 (hex?). The question remains what happened…

DECNet hickup???

DECNet???
In yesterday’s logfile, I found a number of entries like this:
%%%%%%%%%%% OPCOM 23-MAY-2007 11:59:13.74 %%%%%%%%%%%
Message from user SYSTEM on DIANA
Event: Access Control Violation from: Node LOCAL:.DIANA Session Control,
at: 2007-05-23-12:59:13.150+02:00Iinf
NSAP Address=49::00-15:AA-00-04-00-01-54:21,
Source=UIC = [0,0]HTTP$NOBODY,
Destination=number = 17,
Destination User="",
Destination Account="",
Node Name=LOCAL:.DIANA
eventUid 05E361FC-0925-11DC-A8A1-0000F87653E2
entityUid 415FAA9C-F8E3-11DB-81F1-AA0004000154
streamUid 5144F470-F8E3-11DB-82D7-AA0004000154

That looks like DECNet, run by the webserver??? (given the user HTTP$NOBODY) but the webserver logfile doesn’t show anything on this. I know that at that time SSH did not respond at all, and the webserver was very slow. No idea what could have caused it.
49:: is not on my network, that’s for sure.

23-May-2007

T4_WASDLOG
The program is ready, the code documented. Some other documents need to be compiled before the kit (one zipfile containing the (Pascal) source, objectfile and executable can be published.
Interesting feature: I build the program ENTIRELY on my laptop, using Personal Alpha (VMS 8.2, to be complete).

22-May-2007

Errors
The performance tools have run after installation, but the procedurelog showed a number of errors, that I thought to be related to the previously installed verion, that I had to de-install before installing the new one. So I simply re-installed the product, reconfigured it and started it again. Next midnight, it started again and one day later, I got results, but niot exactly what I expected. Some problems got away, but others kept appearing. It now runs all day as it should, returning files, in all about 16000 blocks or 8 Mb each day (no big deal on a 18Gb disk) where monitor’s recording is by far the biggest contributor. But processing this big file gives a warning that should not occur:

(00:00:01) $ T4Extr T4_DIANA_22MAY2007_0001_2359_Mon.Dat -
/Csv_File=T4_DIANA_22MAY2007_0001_2359_Mon.Csv -
/Class=(All,NoScs,NoDisk,NoRms) -
/Process_Name=("*LMD0*","*SHAD*","*PRODOPER*","*BATCH*"♦
%SYSTEM-W-BADFILEHDR, bad file header

It says Warning, but the resulting file is indeed missing, resulting in even more errors later on where these extractions are expected to exist.
Luckily, I’m here at the OpenVMS bootcamp, very close to the engineers that are responsible for the product. I told them and they will dive into it.
They have requested to get a saveset of the monitor output file, and I already had that on Demeter, so I zipped it to mail it to the engineer – but for some reason, it cannot be uploaded….
WASD acces logs as input
For serving the web, performance is a major issue, that’s one reason why I want to have T4 on the system. One source containing usefull information for this purpose is, of course, the webserver access log file: How many request were served in one minute, how many bytes have been transferred and how many occurrences of each status-group (100,200…) show up? I created a program to extract this data from the logfile into a CSV file that can be used in the T4-stack. It works:
Example T4 output but some extra work is needed before it’s fit to be released.

18-May-2007

New tool installed
Today I learned more about the T4 performance tool. Basically it’s using the standard MONITOR tool, sampling once a minute (by default), but the data files are slightly adapted, and translated to standard comma separated files that can be tansferred to a Windows box for display and ((most of all: visual) analysis of related items, on one screen…
It is so powerfull that it might shine a light on the PHP performance problems that occur at times, so I installed it on Diana and have it run to examine the outcome. Another thing to do is to process tye Webserver logs to a T4-compatible file so that can be processed as well. That’s somethging to be done.
Some more issues with PHP
I don’t know what caused it, but it was not possible to simply add new users to the Botcamp blog. The main issue seemed to be that the user’s password wasn’t stored, or not stored properly, and I had to alter it a number of times – to a not yet used value – until it worked. After that, I realised that “contributor” meant that a post still needed confirmation from the blog’s administrator. Not exactly what I had in mind.
anywway, upto now it seems to work – the only drawback is there can be just one session logged in at a time (from one machine, that is). Quite obvious from one IE window. It might be that a second instance of IE could do, but it’s no big deal to logout and login differently, so I leave it as it is.