Quayle
          Consulting Inc.

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.  It's not a complete guide -- customers with questions should contact Quayle Consulting Inc. with questions.

Sections:


Application Notes and Documentation

The following CHARON-VAX application notes are available.  Warning: Some of these items are not application to current versions of CHARON-VAX.

Title
Number
Revision Date
Utilities and Interconnects
Interconnects

CHAPI manual
CHAPI

CD-ROM drives usage in CHARON-VAX
AN-046 (05 Nov 2007)
Migrating systems with local DECWINDOWS display to CHARON-VAX
AN-044 (21 Nov 2006)
Tape devices usage in CHARON-VAX
AN-042 (5 May 2006)
CHARON-VAX applying Windows Patches
AN-041 (30 Jan 2006)
CHARON-VAX clustering using the Open-e iSCSI target
AN-040 (4 Jan 2006)
Remote Management of CHARON-VAX
AN-039 (3 Jun 2005)
Replacing legacy removable storage with CHARON-VAX
AN-038 (3 Jan 2005)
CHARON-VAX as an automatic Service; dependencies and restrictions
AN-037 (24 Jan 2005)
Testing various Shared Disk VAX-cluster
AN-036 (16 Sep 2005)
CHARON-VAX network adapter security
AN-035 (3 Jun 2004)
Required Windows Standard Services
AN-033 (16 Jan 2006)
Configuring devices on the Qbus of a VAX or CHARON-VAX
AN-032 (5 Oct 2005)
Using terminal emulators with CHARON-VAX
AN-030 (3 May 2006)
Recommendations Regarding Security of CHARON-VAX Host Platforms
AN-029 (16 Jun 2004)
Avoiding CHARON-VAX disk time out messages on Windows XP
AN-028 (16 Sep 2003)
Using CHARON-VAX on single CPU Windows systems
AN-027
VAX system performance chart (obsolete)
AN-026.pdf

The VAX/VMS licensing structure
AN-025 (23 Jan 06)
Transfer files to CHARON-VAX/AXP virtual SCSI disks
AN-024
Building VMS disk cluster systems with CHARON-VAX
AN-022
Multi-volume tape backup
AN-021
Tape support in CHARON-VAX
AN-020
CHARON-VAX & Alpha/OpenVMS host cluster configuration
AN-019
Ethernet adapters in CHARON-VAX
AN-018
Running VAXELN on CHARON-VAX
AN-017
Running NetBSD 1.5 on CHARON-VAX
AN-016
Accessing SCSI & IDE disks attached to a CHARON-VAX host
AN-014
Serial line LAT terminal performance in CHARON-VAX
AN-013
Running XWindows/Motif applications on CHARON-VAX
AN-012
An example of using VDDRIVER
AN-009
Using ZIP/UNZIP utilities to retain file attributes on VMS
AN-008
Use MGPCX to access DOS floppies in CHARON-VAX
AN-007
Sharing disk container files with other VMS systems
AN-006
Using VAX CD's and floppy disks with CHARON-VAX for OpenVMS/Alpha
AN-005
Using real disks with CHARON-VAX under Windows NT and Windows 2000
AN-004
Connecting CHARON-VAX to a host application
AN-003
Using KERMIT to exchange files with CHARON-VAX
AN-001



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:
Configuration tips:
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:
Things to look out for:

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
    2. $ MOUNT/SYS/NOASSIST 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:
    1. DEFINE/SYS SCRATCH 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.
    1. $ BACKUP/IMAGE/IGNORE=INTER DKA100: 400::DISK$SCRATCH:[000000]DKA100.BCK/SAVE
    2. $ BACKUP/IMAGE/IGNORE=INTER DKA200: 400::DISK$SCRATCH:[000000]DKA200.BCK/SAVE
    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:
    2. $ BACKUP/IMAGE DISK$SCRATCH:[000000]DKA100.BCK/SAVE 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:
    2. $ BACKUP/IMAGE/IGNORE=INTER REAL$DKA100: 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
$1$DIA0
4419450
$1$DIA4
4419450
$1$DUA500
7622370
$1$DUA501
7622370
DAVE$DUA0
3461990
DAVE$DUB0
2766299

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:

load RQDX3/RQDX3 DUB
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
$1$DIA0
4419450
DUA100
$1$DIA4
4419450
DUA104
$1$DUA500
7622370
DUA50
$1$DUA501
7622370
DUA51
DAVE$DUA0
3461990
DUA0
DAVE$DUB0
2766299
DUB0

The entries in the configuration file would look like:

load RQDX3/RQDX3 DUA
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"
load RQDX3/RQDX3 DUB
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.

SYCONFIG.COM
SYSECURITY.COM
SYPAGSWPFILES.COM
SYLOGICALS.COM
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):

Reference
Comment
DIA0
DUA0
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
_$1$DIA0
_DAVE$DUA0
This is the FULLDEVNAM of the device
DAVE$DUA0
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!

$ DEFINE/SYS/EXEC/TRANS=CONCEAL DIA0            DUA100:
$ DEFINE/SYS/EXEC/TRANS=CONCEAL $1$DIA0      DUA100:
$ DEFINE/SYS/EXEC/TRANS=CONCEAL  _$1$DIA0   DUA100:

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:

$ DEFINE/SYS/EXEC/TRANS=CONCEAL DAVE$DUA0     DUA0:
$ DEFINE/SYS/EXEC/TRANS=CONCEAL _DAVE$DUA0   DUA0:

Contact Us!

We respect your privacy -- you will not be added to a mailing list. Check out our plain-language privacy policy.

If the address fields on this form are not suitable for specifying your address, please fill them with NA and provide your mailing address in the message box.

Required fields are labeled with red italic text.

 

Services

Quayle Consulting Inc. provides a complete menu of services, including:

Quayle Consulting in the news:

Quayle Consulting information:

Interesting items:

Stromasys Partner
HP Certified OpenVMS
          System Engineer
HP Business Partner
Quayle Consulting Inc. on LinkedIn
Trademarks
OpenVMS is a trademark of Hewlett-Packard.
CHARON-VAX and CHARON-AXP are trademarks of Stromasys.
Windows is a trademark of Microsoft Corporation, USA.