CHARON-VAX Installation, Configuration, and Migration

A VAX can be virtualized (emulated) on a modern computer, which allows the existing operating system (such as VAX/VMS, OpenVMS, VAXELN), its software, and all applications to be run without change.  No reprogramming is required.  Most customers report that the emulated system is faster than the original.  The CHARON-VAX/6660 Plus product, running on an 4-way dual-core Opteron PC, is faster than any VAX ever built!

This document shows how to get started with the CHARON-VAX product.  Please note that this is not a complete guide – please review it completely and contact Quayle Consulting Inc. with any questions.


Installing CHARON-VAX on Windows using CHARON-VAX XM/XK/XL

Here are the steps to install CHARON-VAX:

  1. Log into Windows as local Administrator, or with Administrator privileges -- do not log in through a domain controller.  The install must be done from the console window -- using Terminal Services or other remote-control software that creates a separate session will not work.
  2. Install the CHARON-VAX software.  Note:  choosing the "default" emulation only changes an icon written to the desktop.  All the VAX models are  installed, depending on the settings in the dongle.
  3. Plug in the dongle when prompted.
  4. Reboot as directed.
  5. If you have a key update, use the HASP-RUS program to update the key. If there is a "fmt" update file, install it first.
  6. CHARON-VAX cannot "share" a network interface with any other network protocols.
    1. Click through Start -> Control Panel -> Network to find the network device(s) to be used by CHARON-VAX.
    2. Make sure the network interface that's to be used by CHARON-VAX has the protocol checked.
    3. All other network interfaces must have the CHARON protocol unchecked.
  7. From the properties page of the network interface, cut the name of the device(s).  Starting at the right side of the name, left click and hold to highlight the entire name.  Press Ctrl-C to get the text into your cut/paste buffer.
  8. Edit an appropriate configuration file (supplied by request from Quayle Consulting) and paste in the device name(s).
  9. "Lock down" the server by following Stromasys application note AN-033.
  10. If you are using physical serial ports, follow these directions from the CHARON-VAX manual:
Open Computer Management, select Device Manager, open Ports (COM&LPT), select the desired COM port, open the Properties dialogue, select the tab Port Settings, then click "Advanced". There you will see FIFO settings. Set the TX FIFO depth to 1 (lowest possible). Otherwise CHARON-VAX/XX is not able to properly detect when the TX FIFO is empty. For the same reason, it is strongly recommend not to enable the option "COMPLETE WRITE REQUESTS IMMEDIATELY".

You are now ready to run CHARON-VAX.

Configuring CHARON-VAX

The CHARON-VAX software requires a configuration file.  Entries in the configuration file include:

  • The model of VAX to emulate
  • The amount of memory to emulate
  • Whether or not to use the "Plus" functionality (if the key is enabled for Plus)
  • What to use as the VAX console.  Choices include mapping to a host's serial port, or launching a terminal emulator.
  • Disks visible to the VAX, how they appear (MSCP, SCSI, etc.), and what they connect to in the host system
  • Tape drives visible to the VAX
  • Network interfaces, and how they appear
  • Optional special devices, such as the VAXprint line-printer emulation
Configuration tips:
  • If a terminal emulator is launched as the console, its executable must be in the same directory as the configuration file.  The "" file which comes with CHARON-VAX works because files ending in ".ht" are associated in Windows with HyperTerminal.
  • The directory holding the configuration file should only have letters and digits in it.  For example, "CHARON VAX" is to be avoided, while "CHARONVAX" is fine.
  • Disks container files and virtual tape container files can be on any drive in the host system, but the directory name cannot contain spaces or dashes.
  • If Windows installs a device driver for a tape drive, its device name is "\\.\Tape0".  The SCSI_Check utility can find devices on the host's SCSI bus, but doesn't work on Windows Server 2003.
  • The VAX 4106 emulation can display devices as either SCSI-connected or MSCP-connected.  The MSCP version is faster.
The CHARON-VAX Launcher application is a very convenient tool to start CHARON-VAX.  Use the "browse" button to find your configuration file.  Some tips:
  • The CHARON-VAX log file is displayed in the main window.  Errors are color-coded.  Red messages usually prevent CHARON-VAX from starting.
  • Click the "Run selected configuration" button to launch CHARON-VAX using the displayed configuration file.
  • The "Edit CFG" button is only active when CHARON-VAX is not running.  When active, it brings the configuration file up in Notepad.  You must close Notepad before the "Run" button will work.
  • The button to create a Windows Service should be avoided until you're to "burn" that configuration file into the Windows Registry as a Windows service.
Things to look out for:
  • It's possible to use the host system's CD drive as a CD drive in the VAX environment.  However, if a disk has been in the drive with a Windows-readable format prior to starting CHARON-VAX, the start of CHARON-VAX will fail.  The host system must be rebooted and the drive left empty until CHARON-VAX starts.
  • CHARON-VAX cannot "share" network interfaces with Windows protocols.  If an emulated interface is off-line or doesn't work, check the protocols on the device.
  • Emulating a VAX processor is a full-time job, so don't be surprised to see that one processor is running at 100% CPU.  This is why dual-processor or hyperthreading is required for a supported configuration.  A special "idle" program is available from Stromasys to throttle the CPU when nothing is happening, but it's not recommended for production use.
  • If the VAX system clock loses time during operation, the host system is most likely too slow for correct performance.  Single-processor systems are very likely to exhibit this behavior.

Migrating Disks Using a Network Connection

My preferred approach is to perform BACKUP/IMAGE operations across DECnet. However, TCP/IP can be used if there is enough scratch space on the physical system.  The general process is:

  1. On the CHARON-VAX system, create a container file (using MKDISK) that's at least 25% bigger than the largest disk on your system.  On a suitably new version of VMS, you could create a container that would hold all of your existing disks at the same time, which would allow you to overlap some operations.
  2. Create empty containers, one for each disk on the original VAX.  You might want to consider making them bigger than the physical disks if they are short on space.
  3. Modify the configuration file to reference all the containers from the previous steps.
  4. Boot VMS.
  5. Start DECnet or TCP/IP.
  6. DECnet migration: Mount the virtual disk created in the first step (the following assumes you've used DUA100 for this disk):
    1. $ INIT DUA100 SCRATCH
  7. TCP/IP migration: Select a disk on the physical system that can hold the BACKUP savesets as they are created.  Assuming that disk is DKA300:
  8. On the physical VAX, shut down all the batch queues, kick off the users, and close any databases.  The commands in SYS$MANAGER:SYSHUTDWN.COM may be helpful.  The goal is to close as many files as possible.  The system disk will have several files open (pagefile, swapfile, etc.), but this is normal.
  9. DECnet migration: I've assumed that the CHARON-VAX system is node 1.400 in this example.  And I've created a DECnet proxy so no username and password are required.
    3. etc.
  10. TCP/IP migration:  FTP each saveset (using binary transfer) and the corresponding .SPEC file (using ASCII transfer) to the CHARON system.  After each saveset is transferred, its characteristics must be reset.  Contact Quayle Consulting for a script to perform this reset.
  11. After each copy is complete and successful, do the following for each disk:
    1. $ MOUNT/FOR DUA100:
    3. $ DISMOUNT DUA100:
    4. If you'd like to test the restored disk, do:
      1. $ MOUNT/OVER=ID DUA100:
      2. $ ANALYZE/DISK DUA100:
      3. $ DISMOUNT DUA100
Note: Tools that automate much of steps 9 through 11 are available on request.

Migrating Disks Using Clustering

Another way to migrate using the network is via clustering.  This is simpler than the DECnet migration, since the disks are directly accessible.  The general process is:

  1. Create empty containers, one for each disk on the original VAX.  You might want to consider making them bigger than the physical disks if they are short on space.
  2. Modify the configuration file to reference all the containers from the previous step.
  3. Boot VMS using one of these two methods:
    1. Using the existing VAX as a boot server.  This requires that you do @CLUSTER_CONFIG on the physical VAX, which modifies the existing system.  The MAC address to specify to CLUSTER_CONFIG can be set using the "STATION_ADDRESS" feature of CHARON-VAX.
    2. Use a stand-alone version of VMS.  If you don't know the cluster number and cluster password, use DECnet to copy SYS$SYSTEM:CLUSTER_AUTHORIZE.DAT from the physical VAX to SYS$SYSTEM on the emulated VAX.  Modify SYSGEN parameters to enable clustering on the emulated VAX and then reboot.
  4. On the physical VAX, shut down all the batch queues, kick off the users, and close any databases.  The goal is to close as many files as possible.  For each disk, you can do (this example is for DKA100):
    1. $ SHOW DEV/FILE DKA100
  5. The system disk will have several files open (pagefile, swapfile, etc.), but this is normal.
  6. Back up each physical disk:
    1. $ MOUNT/FOR DUA100:
    3. $ DISMOUNT DUA100:
    4. If you'd like to test the restored disk, do:
      1. $ MOUNT/OVER=ID DUA100:
      2. $ ANALYZE/DISK DUA100:
      3. $ DISMOUNT DUA100:

Mapping Disks

In the "Migrating Disks" sections, I glossed over an important bit about device naming.  Notice that the original system has disk DKA100, and we restored it to device DUA100.  In CHARON-VAX, the emulated "DU" devices are much higher performance that the emulated "DK" devices.  There's no "DI" device types, since CHARON-VAX doesn't have a DSSI emulation.  So, the names of the disks might need to change on the CHARON-VAX system.

First create a list of the disks on the original system.  In this list, I've included the size of the disk, in blocks, which you'd need to create the matching container files.

Original Device Name
Disk Size, blocks

This looks like we're home free on DUA500 through DUA501, but CHARON-VAX has a limit of DUA255.  And there are DIA and DUB device types, too.

It's possible to define a second DU controller, and those container files would come up as "DUB" devices.  Just add the following to the configuration file:

set DUB container[0]="C:\DISKS\dub0.vdisk"

For the other devices, we choose new device names.  So, for example:

Original Device Name
Disk Size, blocks
New Device Name

The entries in the configuration file would look like:

set DUA container[100]="C:\DISKS\dia0.vdisk"
set DUA container[104]="C:\DISKS\dia4.vdisk"
set DUA container[50]="C:\DISKS\dua500.vdisk"
set DUA container[51]="C:\DISKS\dua501.vdisk"
set DUA container[0]="C:\DISKS\dua0.vdisk"
set DUB container[0]="C:\DISKS\dub0.vdisk"

The container file names could be anything, but that would make it extra confusing.

Now that we've got these devices appearing in the emulated VAX, it's time to hook them up to the old device names.  There are several command procedures in SYS$MANAGER that can be modified to mount disks.  These should be scanned (use SEARCH) for references to the old device names.  The order that these are executed are as follows.

SYSTARTUP_VMS.COM (for VMS V6.0 and later)
SYSTARTUP_V5.COM (for VMS V5.0 through V5.5 and later)

Make sure to check any other command procedures that these routines might call!

When the MOUNT/SYSTEM command is used on a disk whose label is XYZ, a system logical name of DISK$XYZ is created.  If all accesses to that disk use that logical name, you're done.  If only life was that simple...

The devices in the table above can be accessed by any of the following references (excluding the trailing colon):

The local system is assumed, if more than one disk in the cluster matches
$1$DIA0 The ALLOCLASS SYSGEN parameter is 1, or (for DSSI devices) the disk was configured with a value of 1
This is the FULLDEVNAM of the device
If the ALLOCLASS is zero, and SCSNODE is "DAVE", the disks can be accessed via this name.

You have two choices on fixing this situation.  You can either fix every reference, or cheat using logical names.

Here are the logical names you have to set (using the mapping table above).  Don't forget the colon (:) after the new device name!


The DUA0 references don't have to be set, since they didn't change.  Unless the SCSNODE value isn't DAVE anymore.  Suppose we merge system DAVE into the system named FRED.  We'd have to do the following: