Back in the dim dark days when disk was expensive and small, VMS had the concept of volume sets. This was a method whereby you could "bind" two or more disks into a loosely coupled set to store files that were larger than either physical disk.

Volume sets have fallen out of favour over time as disks have become larger, things like RAID have allowed us to combine physical disks into larger disks, and OpenVMS 8.4 support of 2 TiB disks. However, there's one thing that still requires as input an RVN (Relative Volume Number): areas in RMS indexed files.

Before you read on, please be aware that the downside of managing bound volume sets usually outweighs their benefits, Hoff has an article discussing some of the drawbacks. Please understand what you're doing before you do it, particularly in a production environment.

Having said that, wouldn't it be nice if the allocation XAB (and the assocated FDL clauses) allowed you to place RMS areas on different disk drives without those disks being in a volume set?

Of course, I want this feature so that I can place index areas on an SSD and hence justify the expense of buying some :-)

If you'd like to see an example of the currently supported way that this works, and what I'd like as a new feature, read on.

One of the "must have" things for effective systems administration is a centralised monitoring system for things such as down servers and network components, services, CPU, and disk utilisation, etc, etc.

Here, we have dithered around with a number of tools including HP OpenView, IPSentry, HP SIM, and others. It was so messy that I installed a private copy of Nagios so that I could at least get the critical OpenVMS systems under monitoring.

Now it looks like we are making a sustained push to standardise on NimSoft. While this is a MS based product, as long as it works, and centralises all monitoring, I'll be happy.

This company decided to enter into an agreement with a third party disaster recovery supplier to supply storage, rack space, and a managed solution. At my suggestion (made back in 2009 when I was performing the IA64 port for them) the OpenVMS solution uses Continuous Access.

Once this got going, I was unfortunately not consulted about further OpenVMS requirements, and so was had some interesting issues the first time we attempted a disaster recovery test with this setup.

Recently, the Windows guys have been attempting to replicate some large volumes with CA, and have been unable to get the replication group to be managed by the "B" controller.

It turns out that when the third party configured CA, they seriously misconfigured the host port priority screen. Thanks to some support from a mate in the States, I've sorted them out.

The best thing you can do on the "Host port data replication settings" screen is to hit the "Reset to defaults" button, and let the controllers figure it out (or if you know your exact wiring scheme, you can specify priorities).

In our case, we have only a single port wired on each local controller dedicated to CA. The far end is wired redundantly. So this makes it easy, with preferences being local controller A to remote controller A as the first priority, and A to B as the second, then local controller B to remote controller B as the first, and B to A as the second.

This site has an issue that I've seen at a number of sites previously. When a previous systems admin has decided to implement identifiers and ACLs, they've forgotten to co-ordinate the values of the identifiers between the production and QA clusters.

Identifiers are key/value pairs stored in RIGHTSLIST.DAT, and of course the file system does not store the ASCII key, but rather the value when creating an ACL. If you move a file from one cluster to another, and the value of the identifiers in an associated ACL don't match, you end up with unexpected access control list entries with values in them instead of the proper ASCII key. Usually this causes protection problems for the developers.

Unsurprisingly, this problem existed here. I've just done the analysis to sort it all out and have implemented a standardised protection scheme on the QA application and data directories. After a little soak to check for errors, we will roll this out to production.

For some time, my ACLSEARCH utility has been in limbo while I was busy with other things. I knew it didn't work correctly on IA64 drives, but I thought the problem was only limited to ODS-5 disks. Well, I've just had cause to use the utility, and the problem was on any disk that had been initialized or mounted on an IA64 system. Time for a look at what's failing in the code...

It turns out that during the port of the OpenVMS operating system to the IA64 platform, the home block of a disk (which was always located at VBN 2 of INDEXF.SYS) got moved to make way for potential IA64 things (like MBRs and the GPT). I also found out that there is no primary verses alternate home block for a disk any more. They are all regarded as "alternate".

So, this explained why the code was working on my home alpha (that's never even heard of Itanium) and failing at work, even on the Alpha (which is now part of a mixed architecture cluster).

After a lot of messing around, an alternative way to access a home block was arrived at. Unfortunately, this requires a visit to kernel land, so the utility now must be linked against the base image.

With a few other minor tweaks (including moving the section mapping INDEXF.SYS from P1 space to P0 space (those IA64 things are picky)) I have working code again.

You can download ACLSEARCH X01-05 on the downloads page.

My hosting provider has just notified me that an operating system upgrade will be occuring in the next couple of days (wish they could be more specific). If the site goes down, you now know what's happening.

Time to go and ensure my backups are up-to-date...

A quick DCL hack to display which CPU is managing each fastpath capable device.

A few new programming examples have been added to the site. They are for the following services: sys$get_arith_exception, sys$gettim_prec, and sys$power_control.

A second disaster recovery test was performed over the weekend. While we still have some niggling little problems (accessing the EVA's console from the test network, for example), everything worked flawlessly. I now have the recovery time down to approximately 40 minutes (which is a better deal that something like 20 hours when we did this with tape restores).

Yesterday we tested part of our DR plan. This is the bit that restores the major ERP system to functionality. Without this system we're dead in the water.

Recently, we switched this system from a "restore from tape" plan to a "replicate data with Continuous Access" plan. We originally attempted to test this plan back in July, and while this test was declared a failure due to networking setup issues, this one went like a charm.

All systems restored in just over two hours (which I'm hoping we can get under an hour with some more automation).

Recently, we acquired a two processor BL860c i2 blade for inclusion in our development cluster. We justified this by pointing out that the development cluster (which also doubles as the QA/Test cluster) had no where near enough CPU power to run our full overnight processing stream. As our overnight run consists of (nearly) identical streams of parallel processing, we had been testing small subsets and hoping that the operative word "nearly" would not bite us. The addition of the i2 will allow a full run in a timely fashion (read "less that 8 hours").

In addition, we recently had an incident where the management processor of our single BL860c in development went nuts, resulting in a 24+ hour outage while various hardware swaps were tried to rectify the problem (the large outage resulted from someone dropping the ball when it came to backing up the MP settings). It was pointed out to management that they had a development team and a number of testers from the business all waiting for the recovery of this machine, and adding a second Itanium based machine would remove this single point of failure.

There were certainly some "interesting" configuration exercises required to get the new machine up and running the way we wanted it.

Did you know that the status value in the I/O status block for most of the "get information" calls is a longword? I have the sneaking suspicion that this changed some time in recent history (where "recent history" equals "some time after VMS 5.x") when the number of $GETxxI routine return values exceeded the size of a word.

What this means in practice is that you should be testing and returning the full longword rather than just the word for calls such as $GETSYI(W), $GETJPI(W), $GETQUI(W), etc.

As an example, here's a section of code that does the wrong thing and then the correct thing:

#define __NEW_STARLET 1

#include <stdio.h>
#include <stdlib.h>
#include <ssdef.h>
#include <stsdef.h>
#include <efndef.h>
#include <quidef.h>
#include <iledef.h>
#include <iosbdef.h>
#include <descrip.h>
#include <lib$routines.h>
#include <starlet.h>

#define errchk_sig(arg) if (!$VMS_STATUS_SUCCESS(arg)) (void)lib$signal(arg);


/******************************************************************************/
int main (void) {

static IOSB iosb;
static int r0_status;
static int qflags;
static unsigned int status;
static unsigned int flags = 0x000f;
static ILE3 quiitms[] = { 4, QUI$_QUEUE_FLAGS, &qflags, NULL,
                          0, 0, NULL, NULL };

static char msg[255+1];
static struct dsc$descriptor_s msg_d = { 0,
                                         DSC$K_DTYPE_T,
                                         DSC$K_CLASS_S,
                                         msg };

    /*
    ** This call will succeed requesting information, but because our item
    ** list is missing the queue name we want info on, the IOSB will contain
    ** a status indicating we didn't pass enough parameters.
    */
    r0_status = sys$getquiw (EFN$C_ENF,
                             QUI$_DISPLAY_QUEUE,
                             0,
                             quiitms,
                             &iosb,
                             0,
                             0);
    errchk_sig (r0_status);

    /*
    ** Display the word value.  Perhaps not what we were expecting.
    */
    (void)printf ("iosb.iosb$w_status = %d\n",
                  iosb.iosb$w_status);
    msg_d.dsc$w_length = sizeof (msg) - 1;
    status = iosb.iosb$w_status;
    r0_status = lib$sys_getmsg (&status,
                                &msg_d.dsc$w_length,
                                &msg_d,
                                &flags);
    errchk_sig (r0_status);
    (void)printf ("%-.*s\n",
                  msg_d.dsc$w_length,
                  msg_d.dsc$a_pointer);

    /*
    ** Display the correct longword value.
    */
    (void)printf ("iosb.iosb$l_getxxi_status = %d\n",
                  iosb.iosb$l_getxxi_status);
    msg_d.dsc$w_length = sizeof (msg) - 1;
    status = iosb.iosb$l_getxxi_status;
    r0_status = lib$sys_getmsg (&status,
                                &msg_d.dsc$w_length,
                                &msg_d,
                                &flags);
    errchk_sig (r0_status);

    (void)printf ("%-.*s\n",
                  msg_d.dsc$w_length,
                  msg_d.dsc$a_pointer);
}

Compiling, linking and running this code produces the following output:

$ cc demo.c
$ link demo
$ run demo
iosb.iosb$w_status = 33036
%SYSTEM-F-NOMSG, Message number 0000810C
iosb.iosb$l_getxxi_status = 295180
%JBC-F-MISREQPAR, missing required parameter
$

This time on development. A little back story: the system this occurred on is running on a blade system, and the management processor in the blade system had been acting flaky. HP decided to swap out the blade, but the engineer on site forgot to back up the NVRAM before he swapped out the old blade, and we ended up with an unbootable box. After much stuffing around, we managed to boot the box in a non-standard way. A day later, we saw this crash.

While cleaning up some boot definitions with SYS$MANAGER:BOOT_OPTIONS.COM ready to relocate the system disk from one EVA disk group to another, we experienced a crash. The problem has been escalated to OpenVMS Engineering as we are running the latest and greatest update patch (UPDATE-V1000).

Here's an article with the best method I've yet seen to clean up old versions of the linux kernel from your machine.

Seeing commands like

dpkg -l 'linux-*' | 
sed '/^ii/!d;/'"$(uname -r | 
sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | 
xargs sudo apt-get -y purge

make me glad I'm not a linux systems manager :-)