Here's a patch panel picture. Although this still needs a little tidying up, it's fairly representative of the how neat we've tried to be putting the new room together. I'm sure it would be an eye opener for the previous people that let over 30 centimetres of cable spaghetti build up in front of the old computer room's core switches...

Sorry for the lack of entries on here. I've been busy building this room. The majority of the equipment that will end up in the room is brand spanking new kit. All of this has now been racked and cabled, with the exception of some stuff that is lacking cables that the project manager overlooked and failed to order. Fortunately, most of that gear is not required for the first part of the relocation. The rest of the kit is old gear that will be physically relocated from the old room to the new room. This includes the OpenVMS CPUs.

We have just done a transfer test to prove replication on the VMware side, where Mike went beyond the call and worked four days straight. Now that we are passed this, we are working on getting the SAN replication to work over the high speed links. Once this is in place (and some pesky firmware downgraded then upgraded again) we can test the OpenVMS stuff.

Then it's just a matter of making the transfer happen for real. In the case of the OpenVMS stuff, that's two consecutive weekends, the first to move development, and the second to move production.

Because development and production are both based on HP's blade systems, the first weekend is basically a dress rehearsal for the second weekend.

The way this will work is that the data will be replicated to the new DC via SAN replication, the machines will be shut down, and then the CPUs will be physically moved. Once in place, the machines can be booted off the replicated data. As we move, I'll report status here.

I'll also add some photos of the new racks to this post shortly...

We commenced the build on the new data centre yesterday. The backbone cabling is complete enough so that we were able to rack and stack the first of five cabinets, roll the new disk storage onto the floor, and power a few things up.

I'm a bit sore today from having to crawl under the floor to put power in. The hazards of getting old :-)

We are waiting for all the backbone cabling to be complete before we cable the servers in, so we can ensure the appropriate link lights come on. Meanwhile, we'll go back and rack the next cabinet as the cable contractors get through with it.

As of today, I've been on line for 11 years talking about my favourite operating system. Yay me.

Lots of system service calls in the OpenVMS operating system allow you to optionally specify an event flag number (EFN). The documentation states that this is an optional parameter, and usually goes on to say:

Number of the event flag that is set when the $xxx request completes. The efn argument is a longword containing this number; however, $xxx uses only the low-order byte.

When the request is queued, $xxx clears the specified event flag. Then, when the request completes, the specified event flag is set.

In recent versions of the "System Services Reference Manual", an additional paragraph has been added to some of the more frequently used system services that says:

HP strongly recommends the use of the EFN$C_ENF "no event flag" value as the event flag if you are not using an event flag to externally synchronize with the completion of this system service call. The $EFNDEF macro defines EFN$C_ENF. For more information, see the HP OpenVMS Programming Concepts Manual.

And some of the system services even tell you that if you omit the optional EFN parameter, EFN zero, which is certainly a valid EFN, will be cleared and set when the service is called and then completes.

If the system service you are researching doesn't have that information, please just imagine that it's there every time you see the optional EFN parameter.

I can't stress this enough. If you omit this parameter, bad things can and will happen if you are dependent on knowing when events occur.

To state is simply, use EFN$C_ENF everywhere you don't explicitly need to know when an event flag sets, and use a specified event flag (allocated by lib$get_ef) when you do.

On Itanium, the Virtual Hash Page Table is an intermediate cache of address translations that sits between the TLB and physical address translation by walking the page tables. The default value in SYSGEN is 1, which allows for 1024 addresses to be cached.

If you have large application with poor locality of reference, increasing VHPT_SIZE could be beneficial.

Here's a DCL command procedure to calculate a good starting value for SYSGEN parameter VHPT_SIZE:

$! VHPT.COM - see EOF for comments.
$       old_verify = 'f$verify (0)'
$       status = 1
$       say := write sys$output
$       required_privs = "world"
$       old_privs = f$setprv (required_privs)
$       if .not. f$privilege (required_privs)
$       then
$           say "Required privs: " + required_privs
$           status = 38
$           goto exit
$       endif
$       if f$getsyi ("arch_name") .nes. "IA64"
$       then
$           say "This is an IA64 specific command procedure"
$           status = 44
$           goto exit
$       endif
$       have_math = f$type (math) .eqs. "STRING"
$       page_size = f$getsyi ("page_size")
$       context = ""
$       max = -1
$loop:
$       pid = f$pid (context)
$       if pid .eqs. ""
$       then
$           goto end_loop
$       endif
$       test = f$getjpi (pid, "virtpeak") * 512 / page_size * 32 / 1024
$!                   pagelet size-----------^                 ^    ^
$!                   VHPT entry size--------------------------^    ^
$!                   convert to K for VHPT_SIZE--------------------^
$       if test .gt. max
$       then
$           max = test
$       endif
$       goto loop
$end_loop:
$       if have_math
$       then
$           math a = 2 ^ ceil (log (max) / log (2))
$           max = f$element (0, ".", a)
$           rounded = ""
$       else
$           rounded = " rounded up to the nearest power of 2"
$       endif
$       say "Good starting point for VHPT_SIZE is ''max'" + rounded
$exit:
$       set noon
$       junk = f$setprv (old_privs)
$       exit (status + 0*f$verify (old_verify))
$!++
$!
$! DESCRIPTION
$!
$!      This code figures out a good starting point for the VHPT_SIZE SYSGEN
$!      parameter, based on largest peak virtual address size running on this
$!      system.  The maths from this come from BRUDEN OSSG, specifically
$!      this article by Bruce Ellis:
$!
$!              http://brudenossg.com/doc_lib/VMS_VHPT.pdf
$!
$!      This command procedure just makes the calculations more convenient.
$!
$! AUTHOR
$!
$!      James F. Duff
$!
$! DATE WRITTEN
$!
$!      10-Feb-2013
$!
$! MODIFICATION HISTORY
$!
$!      10-Feb-2013     Jim Duff
$!      Original version of module.
$!
$!--

I was troubleshooting an issue where the FCP call rate was showing as extremely high on a node in the development cluster. The file lookup rate in the same MONITOR FCP window showed a corresponding number, so I knew something was doing a lot of directory access somewhere.

I tracked it down to a piece of code that created a filename that included a timestamp as part of the name, assuming that that would be unique enough to prevent collisions with other concurrently running versions of the program. Well, when that wasn't good enough, the problem occurred with the program going into a loop doing file lookups (via a spawned DIRECTORY command, but that's another story). Here's how to create a guaranteed unique filename in COBOL:

identification division.
program-id. testit.

environment division.

data division.
working-storage section.
01 ret-status pic s9(09) comp.
01 uid-bin.
   03 uid-bit pic s9(09) comp occurs 4.
01 filename pic x(33).

procedure division.
0-start.
    call "sys$create_uid" using by reference uid-bin
        giving ret-status.
    if ret-status is failure
        call "lib$signal" using by value ret-status.
    call "sys$fao" using by descriptor "!8XL!8XL!8XL.!8XL"
                         omitted
                         by descriptor filename
                         uid-bit(1)
                         uid-bit(2)
                         uid-bit(3)
                         uid-bit(4)
        giving ret-status.
    if ret-status is failure
        call "lib$signal" using by value ret-status.
    display filename.

0-end.
    stop run.

Occasionally, programmers ask us to convert RMS files to extend the record size or add additional indexes. On the occasion that's prompting this post, the programmers handed us an FDL file to add a new alternate key and extend the file at the same time. Obviously, there were a bunch of programs recompiled to reference the new record length to be installed along with the file convert.

We do changes like this on Sundays, where (theoretically) the system is unavailable. As the system is either being used 24 hours a day other than that, changes at other times are extremely problematic, and will generally impact users in some part of the country.

To cut a long story short, the programmer's testing had failed to uncover that the field that was turned into an alternate key had its value updated under certain conditions... and the FDL used to convert the file specified no changes for that key. So when a program attempted to change the value, a stack dump resulted.

Recently, I talked about looking for a cable database, and ended up settling for RackTables. Since then, I've ended up becoming a very big fan of this Open Source freeware product.

My only complaint was that the product didn't support patch panel to patch panel cabling, but that I could live with it as I was planning on using multi-core cables for the back end wiring, so it would have been easy to figure out what went where.

For reasons that shall remain obscure I've been looking at how to disassemble IA64 executable images.

There are a few options.

Shortly, it looks like I'm going to get the opportunity to rebuild our data centre from the ground up with nearly all new equipment. The design is rather cable dense (lots of VMware nodes with seven, yep, count them, seven) network connections per 1 RU server.

Because the design calls for five racks and the network port counts only call for a couple of switches of each type (10 Gbit/s ethernet, 1 G/bit/s ethernet, and 8 Gbit/s fibrechannel) there are going to be quite a few patch panels in between racks to distribute switch ports for network fabrics without a switch physically mounted in that rack.

It appears that the cable count is somewhere around the 600+ mark.

Does anyone know of a good cable management database that does:

I've already explored CablePro, WireCAD, RackSmith, ODCNMS, OpenCabling, CableManager and a few others...

Update: I've settled on RackTables, which does everything I need except for patch panel to patch panel links, and the developers are promising that on their roadmap. I can get by without that at the moment as I'm only looking at 24 links, and I can work it out manually.

This is example C code of how to generate an SNMP trap via the eSNMP API on OpenVMS. The SNMP example that ships with the operating system is far too complicated to take in one gulp, particularly if all you want to do is trap.

The XQPERR crash I reported and reproduced has been acknowledged by Engineering: "We debugged the reproducer ... and found that a bug got introduced as part [of the] SYMLINK enhancement on 8.4".

Engineering have provided me with a new version of F11BXQP.EXE, which appears to fix the problem. Now I just need the official kit so I can install in production.

For reference, the Quix case is QXCM1001219891.

Recently I published a XQP crash footprint on IA64 8.4. The cause of the crash is quite strange, and appears to be something not correctly handling FCBs describing a directory index being placed on the LRU buffer list.

The FCB contains a status longword with the two bits of interest being FCB$V_ISDIR and FCB$V_DIR. These two bits indicate that the FCB describes a directory and is on the LRU list, respectively.

The issue appears to be that under certain circumstances, FCBs get placed on the LRU list without the FCB$V_DIR bit being set. This should not be possible (?)

When the kernel needs a new FCB, it looks at the LRU list to find the first one on the list. In the case of the crash, all the FCBs on the LRU list did not meet the selection criteria because none of them had the FCB$V_DIR bit set. The system failed an assert, and down we went.

A new utility called HC (short for Header Count) has been added to the Downloads page. This utility gives you a count of the number of headers in use, and also gives you a count of the number of words that are free in INDEXF.SYS to store additional retrieval pointers. This gives you an idea of how many more times the index file can be extended before you hit the dreaded %SYSTEM-W-HEADERFULL error.