28-Feb-2007

Patch-time is coming
Al latest patches have been downloaded but since it’s almost March, I guess the next VMS update pack will be delivered within a few weeks. HP has set up a calendar for update kits to be delivered, but, as was toi be expected, I lost track and didn’t save the data. I will have to check the HP site…
Anyway, some time next month, Diana will be rebooted due to these patches. Alas, it won’t be possible to have Dido taking over in the mean time due to the problems that occur on the shared SCSI bus. That’s one of those things that still need investigation and, possibly, adjusting the used SCSI cards: place KZPSA in all machines in stead of KZPBA (Officially, KZPSA should work with OpenVMS – and KZPBA isn’t suppoted for the job). We’ll see.
Bootcamp 2007
Have you planned to attend this year’s bootcamp in Nashua, and flying in over Boston Logan Airport?
One way to get from the airport to Nashua is using a FrontLine cab. A ride is about $70 (at least, that was the fare last year) per person, but last year we found out that if you book as a group that travel together, the fare per person is considerably lower. Just one person will book (and pay) for the whole group.
I’m planning to go (the financing isn’t complete yet), and if you are interested in such an offer, drop me a line. If you can give me a lift, either way, that is most welcome as well. I’ll buy you a beer 😉

Back to normal

Since the last post, the dumbo has finally gave up. Operator.log is back to normal sizes (14K).

The Dummy keeps trying….

I thought he (or she? but most of these dummies are male) had enough, but no:

%%%%%%%%%%% OPCOM 20-FEB-2007 02:52:21.74 %%%%%%%%%%%
Message from user INTERnet on DIANA
INTERnet ACP SMTP Accept Request from Host: 84.246.98.2 Port: 1119

%%%%%%%%%%% OPCOM 20-FEB-2007 02:52:22.00 %%%%%%%%%%%
Message from user TCPIP$SMTP on DIANA
%TCPIP-W-SMTP_UNBKTRNSIP, client IP address 84.246.98.2 is not backtranslatable to a host name
...
%%%%%%%%%%% OPCOM 20-FEB-2007 15:30:06.95 %%%%%%%%%%%
Message from user INTERnet on DIANA
INTERnet ACP SMTP Accept Request from Host: 84.246.98.2 Port: 2672

%%%%%%%%%%% OPCOM 20-FEB-2007 15:30:07.13 %%%%%%%%%%%
Message from user TCPIP$SMTP on DIANA
%TCPIP-W-SMTP_UNBKTRNSIP, client IP address 84.246.98.2 is not backtranslatable to a host name

with some time in between that there wasn’t a message.

WHOIS gives no ABUSE address, and I checked what sould be a feasable address: Since WHOIS locates the address in the UK, I tried http://www.worldhub.co.uk/, and this is a statistics site. Since most seem to be something at ukweb.nl, I tried www.ukweb.nl but that doesn’t make sense either; this links into www.uk.nl – for child care for parent at work.

Or someone is abusing this site.

20-Feb-2007

A new cluster member
Earlier, I downloaded Personal Alpha – not the full freeware version yet, but a two-month trial one – and installed it on Demeter, the company laptop. Of course, VMS was installed on the disk container, and all that I need to do some investigation.
It works fine – as was to be expected. Not very fast, indeed, but well workable.
As it runs on Demeter, the instance is named “Persephone” – in Greek mythology Demeter’s daughter.

Of course, it would be nice to have it connected to Diana – the main VMS machine – as a cluster member. It works fine over the wired network, though the NIC is not usable for Windows anymore and connecting a Windows process (like terminal emulator or FTP program) is not possible. But it works.
Since Personal Alpha will use the same network connections as Windows, I tried to boot it into the cluster via wireless.
Does that work?
Yeah, why not: VMS = VMS and what’s it running on doesn’t really matter! That’s why WAX, Alpha and Itanium work in one cluster. Though not

    officially

supported (meaning it hasn’t passed rigorous testing) but since clustering is as the bare bones of VMS, it is not a true suprise. The actual product (Virtual Alpha) has no problem with clustering either, nor has Charon-VAX; fopr the very same reason: VMS (VAX) = VMS (AXP) = VMS (IA64) = VMS (CharonVAX) = VMS (VirtualAXP) …. (When will this be extended to IA32???).
The size of operator log incresed – but that was to be expected, (re)booting the second machine several times – and complete, including TCPIP processes. That is is over 4 times in size than normal, has another cause, discussed elsewhere.
However, there is a problem in accessing the MSCP-serverd disks. They can be seen, but cannot be accessed, or mounted. But that happened to Dido as well (except for the shared SCSI disks) so that is a more generic issue.

20-Feb-2007

A new cluster member
Earlier, I downloaded Personal Alpha – not the full freeware version yet, but a two-month trial one – and installed it on Demeter, the company laptop. Of course, VMS was installed on the disk container, and all that I need to do some investigation.
It works fine – as was to be expected. Not very fast, indeed, but well workable.
As it runs on Demeter, the instance is named “Persephone” – in Greek mythology Demeter’s daughter.

Of course, it would be nice to have it connected to Diana – the main VMS machine – as a cluster member. It works fine over the wired network, though the NIC is not usable for Windows anymore and connecting a Windows process (like terminal emulator or FTP program) is not possible. But it works.
Since Personal Alpha will use the same network connections as Windows, I tried to boot it into the cluster via wireless.
Does that work?
Yeah, why not: VMS = VMS and what’s it running on doesn’t really matter! That’s why WAX, Alpha and Itanium work in one cluster. Though not

    officially

supported (meaning it hasn’t passed rigorous testing) but since clustering is as the bare bones of VMS, it is not a true suprise. The actual product (Virtual Alpha) has no problem with clustering either, nor has Charon-VAX; fopr the very same reason: VMS (VAX) = VMS (AXP) = VMS (IA64) = VMS (CharonVAX) = VMS (VirtualAXP) …. (When will this be extended to IA32???).
The size of operator log incresed – but that was to be expected, (re)booting the second machine several times – and complete, including TCPIP processes. That is is over 4 times in size than normal, has another cause, discussed elsewhere.
However, there is a problem in accessing the MSCP-serverd disks. They can be seen, but cannot be accessed, or mounted. But that happened to Dido as well (except for the shared SCSI disks) so that is a more generic issue.