Jorge,
All your questions were related, so my opinion that asking them all at once was appropriate.
I haven't seen this mentioned so far.
VMS will only allow a single instance of a volume name to be mounted in a shared fashion within the cluster.
In other words, you will not be able to mount both the old and the new using /CLUSTER, /SYSTEM or /GROUP unless you modify the volume label.
To do that, use the set volume/label=newlabel command.
If you are using logical names as displayed by f$getdvi("$1$DGA33","LOGVOLNAM") to access the drive (as you hopefully are), then you will need to dismount/remount the disk for that logical name to change.
Also, as you are moving the disk, now is the best time to use the init commands appropriate for the new disk. I would choose a /CLUSTER that is a power of 2, (current recommendations are for a clustersize of 16, but that really depends on what the disk is going to be used for). You also should at least consider initializing with /LIMIT and if you anticipate many files on the drive, you should preallocate file headers with /HEADERS and perhaps a large /MAXIMUM_FILES. If you will have a large number of files in the top level directory [000000] (MFD) consider using /DIRECTORIES.
The following can be changed later with set volume, but you may want to do it up front. If you have sufficient memory, and you expect files to grow, and therefore become fragmented, you can reduce the performance penalty by specifying /WINDOW=80 (or at least something higher than the default of 7). Note that this can also be specified at volume mount time. You can reduce fragmentation by specifying /EXTENSION to be larger than the default. Note that this is only a last resort, as it can also be set system wide with the SET RMS command. There is a current discussion about where to place the majority of the blocks used by the INDEXF.SYS file using the /INDEX=xxxx command. INDEXF.SYS contains (in addition to some other things) the file headers for all files on the disk. The file headers store meta data for each file, i.e. dates, ownership, protection, attributes, etc.
Once you have initialized the drive, then you want to backup/image/noinit so the special settings you used are not discarded.
Here's a summary of the commands I would use to do what you want.
Assuming going from $1$dga23: to $1$dga33: and using a prived account like SYSTEM.
$! stop applications using the disk
$! verify no files open
$! from each cluster member do the following:
$! show device/files $1$DGA23:
Here's an example of a disk with no files open:
$ show dev/file dkc200
Files accessed on device $4$DKC200: (SIGMA, OMEGA) on 20-JUN-2007 19:38:52.99
Process name PID File name
00000000 [000000]INDEXF.SYS;1
$
INDEXF.SYS always shows up with PID 00000000
You don't state if this disk is your system disk, if it is, you will need to boot off the VMS distribution disk to backup to the other drive.
I would change the label on the original disk at this time.
$ set volume/label=DISK23_OLD $1$DGA23:
Also, I like to do an analyze/disk/repair before the backup.
$ analyze/disk/repair $1$DGA23:
You may get an informational message about the quota file if you are not using disk quotas.
Dismount the disk clusterwide
$ dism/cluster $1$dga23:
Mount the disk for your process. /nowrite to prevent costly accidents, and so the underlying disk doesn't change while you are copying it.
$ mount/nowrite $1$dga23: disk23_old
Initialize the new disk with label DISK23_NEW and appropriate qualifiers.
$! example only, you need to determine what is right for you.
$ init $1$dga33: disk23_new /system /owner=[1,1] /cluster=16 /headers=100000 /limit ! etc.
Mount the destination disk that you have initialized with /cluster etc.
$ mount/for $1$dga33:
%MOUNT-I-MOUNTED, DISK23_NEW mounted on _$1$DGA33: (JORGE)
Backup old disk to new. I like to use /truncate when new clustersize is not integral multiple of the old clustersize. I also use /IGNORE=NOBACKUP. /VERIFY if you want to know for sure you have a good backup. Note: a /verify when going disk to disk is for the paranoid, as the probability of an error here is no worse than when the device is in normal operation. However, since the input disk is write locked, a /verify should not generate any errors. If it does, there are real problems.
$ backup/image/noinit/ignore=nobackup $1$dga23: $1$dga33: /truncate
Pay attention to any errors or warnings that are issued.
If you are not running 8.3 with patches, the /limit you used when you initialized the drive may be lost. In that case, you will need to reset it.
$ dismount $1$dga33:
$ mou/ov=id $1$dga33:
%MOUNT-I-MOUNTED, DISK23_NEW mounted on _$1$DGA33: (JORGE)
Ok, I also like to do an analyze disk after a disk-to-disk image backup.
$ analyze/disk $1$dga33:
Other than the possible QUOTA.SYS not found message, you shouldn't get any warnings or errors here. If you do, you need to investigate them before moving forward.
Note: At this point, you can still revert to the original state, all you need do is dismount the write locked $1$DGA23, mount it private, reset the volume label to DISK23 on $1$DGA23:, dismount it, and remount it clusterwide.
Assuming everything looks good on the new copy, you have two choices. Change any references to $1$DGA23 to $1$DGA33 (hopefully the only place this needs to be done is where the disk is mounted), or change the unit ID so VMS sees the new disk with the old physical name. To do that you will need to dismount both devices from all VMS nodes, and then from the disk controller unpresent the old and new devices and then present the new device with the old unit identifier. You would probably want to present the old device with the new identifier, just so you could see the way it was.
Note: At this time the volume labels still have the _OLD and _NEW tags, so you will be able to easily verify that you are working with the correct device, even if the physical device name has changed.
Either change your mount commands in your startup procedures or change the physical device name. For this example, I will assume you are going to change the unit identifiers associated with the disks, as that has fewer possible side effects.
Mount the new device.
$ mount /ov=id $1$dga23: ! note using old phy name
%MOUNT-I-MOUNTED, DISK23_NEW mounted on _$1$DGA23: (JORGE)
Verify that it is really the correct device.
Reset the volume label to DISK23 and if needed, set /LIMIT
$ set volume/label=DISK23/limit $1$DGA23:
One more dismount and then mount clusterwide
$ dism $1$dga23:
$ mount/cluster/window=80/extent=128 $1$dga23: disk23 ! /window and /extent can be set here (for example)
Ok, restart the applications, do some test, you should be done.
Good luck,
Jon
it depends
