Best way to convert bound volume sets to single larger disk?

[Robert_Boyd]

After reading the documentation and looking at the articles in Ask The Wizard I haven't found what I thought would surely exist.

If I want to convert a bound volume set and preserve links for files with multiple directory entries, I want BACKUP to do the job for me.

Is there another tool or some unpublished qualifier that will tell BACKUP to merge all of the files from a volume set into one output device?

If BACKUP won't do this, isn't it a good idea to add the capability to BACKUP, since the VMS Wizard is discouraging people from creating bound volume sets now that significantly larger disks are available? I have several volume sets I want to convert and I don't want to worry about messing up multiply linked files.

Any suggestions?

Robert

[Robert Gezelter]

Robert,

The HELP text for BACKUP/IMAGE states explicitly that /IMAGE processes "an entire volume or volume set".

Since I have not done this particular evolution recently (and I am about to sit down for dinner), I would recommend:
- create a two (small) volume bound set using LDDRIVER; creating a variety of files on both
volumes, including multiply linked files.
- do a BACKUP/IMAGE, specifying the first volume of the set
- restore the resulting save set to an LD volume twice the size of the two LD volumes used in steps 1/2.
- examine the resulting structure to verify that everything is as it should be.

Needless to say, I would recommend saving the Bound Volume set version of the disk following the conversion so that it is available in the event that something untoward happens during or following the conversion operation. OpenVMS is perhaps the most robust system out there, but part of that robustness is system managers opting to take conservative choices when doing high-value operations.

That said, if you have access to host based volume shadowing, consider the possibilities covered in my HP Tech Forum 2005 presentation, "Migrating OpenVMS Storage Environments without Interruption or Disruption" (located at: http://www.rlgsc.com/hptechnologyforum/2005/1146.html) as a way to ensure the ability to increase volume size without interrupting active users, a capability formerly only available through the use of bound volume sets.

- Bob Gezelter, http://www.rlgsc.com
P.S. "Conservative choice" refers to always having a fallback position. It does preclude being technically agressive.

[Robert_Boyd]

Thanks for the suggestion Bob.

The problem is that BACKUP/IMAGE preserves the file id's of the pieces from each input volume set member and wants to recreate those FIDs identically on the output volumes.

I don't know of any way to merge the FIDs into a new volume on a single device that would preserve links.

Robert

[Robert Gezelter]

Robert,

Ok, a comment. Some details need to be checked carefully.

I have not had to recently perform this transformation, however, I have worked with the details of bound volumes enough that I believe that there are some ways to deal with this that are not too bad.

In particular, I would want to carefully check the behavior of space allocation during restore, and what actually happens during the restore. I dislike speculating in a public forum, because I do not have the time this evening to perform the needed experiments. One option that comes to mind is resizing the lead volume of the volume set and then performing a fixup process on the result. From 25 years of working with all of the variants of volumes, I believe that this would work, if done correctly.

- Bob Gezelter, http://www.rlgsc.com

[Karl Rohwedder]

Robert,

there a lot of entries regarding volume sets in the 'ask the wizard' section, all which lead to the conclusion, that BACKUP/IMAGE is NOT the right tool to convert volume sets into single volumes (you already read all these, I suppose).
This can only be done directory wise.


regards Kalle

[Ian Miller.]

I think a non-image backup operation to copy the files

BACKUP diska:[*...]*.*;* diskb:[*...]/OWN=ORIG

[Robert Gezelter]

Karl,

With all due respect, I must partially disagree with your conclusion regarding the entries in Ask The Wizard (ATW) as to the conclusion about BACKUP and Bound Volume Sets.

In the current series of ATW, there is indeed one reference (ATW 8948, "BACKUP, MOUNT/BIND, and Bound Volume Sets") which makes the comment:
"Given increases in disk capacities and decreases in costs,
the OpenVMS Wizard generally discourages continued use of
bound-volume sets."

In general, if a single volume will do the job, it remains the preferred choice. However, Bound Volume Sets serve many purposes, and are useful in many situations. They are one of several alternative technologies, each of which has their strengths and weaknesses.

The limitations of BACKUP when restoring an image save set, do not mean than BACKUP does not have a place in the conversion operation, just that it is not the entire picture.

As one who has dealt with the internals of the Files-11, Level 2/5 structure since the beginning, and with volume sets since the beginning, I can assure you that more can be done, with no risk, than the direct application of standard tools used singly. One of the great strengths of the underlying design is that when one needs flexability, it is almost invariably there.

- Bob Gezelter, http://www.rlgsc.com
(One who has changed the cluster factor on a disk PRIOR to the existence of BACKUP without using COPY in any way, shape, or form).

[Jan van den Ende]

Robert,

the way Ian suggests would also be my way.

The one thing to watch out for however, is the potential existance of alias files or directories, which can complicate things quite a bit. And from the original question I got the idea that THAT was the real issue!

AFAIK there is NO straightforward solution there.
You will just have to do the resolving by hand.
If you KNOW where the aliasses are, it is not too hard (just a SET FILE/ENTER instead of a directory tree backup), but that IS the crux: You have to KNOW them and be thoroughly aware of them!

It can be done, but BE CAREFULL!

PS.
I _DO_ agree that it would be very desirable for BACKUP to be able to deal with that situation in a VMS-worthy way!

Success.

Proost.

Have one on me.

jpe

[Robert_Boyd]

After looking at the DFU capabilities I was able to discover that 2 of the volume sets I want to convert do not currently have any alias entries.

The command to generate a list of alias entries with DFU is:

$ DFU DIRECTORY/ALIAS

So at least I've reduced the size of my problem set considerably. I at least have a way to be certain about what the aliases are without having to do fancy footwork with the output of DIRECTORY/FILE_ID.

Thanks for all the suggestions so far.

I've been thinking about this issue -- if someone is in a contingency recovery situation and then get faced with this problem it could get kind of messy if they don't have an identically matched environment and need to restore without having addressed this issue. This would be an easy issue to overlook in the planning stages -- of course if you go ahead and do the implementation and testing you'll figure it out in all likelyhood.

Robert

[Robert Gezelter]

Robert,

Actually, in the emergency recovery situation, the most expeditious way to deal with it is to use LDDRIVER to simulate the multiple disk configuration and then sort things out later (or use the various EVA facilities to similarly fake out the disk configuration issue).

You are correct that it DOES that need be taken into account when planning contingency/restart configurations.

It brings back memories of one of my first systems (and IBM System /360 Model 40) where our reciprocal recovery machine was its twin at a sister institution, except for the small detail that the IO configurations were mirror images of one another (Ours: Disks at 1xx addresses, Tapes at 2xx addresses; Theirs: Disks at 2xx; Tapes at 1xx). It required a field service call -- BILLABLE -- to switch the configurations back and forth.

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

Robert,

Hopefully the take home message from this experience is "bound volume sets - just say NO".

Sorry, I know that doesn't help you in your current situation, but might prevent others from finding themselves there in future.

[Stanley F Quayle]

This thread is very timely -- just yesterday, I came across a prospective CHARON-VAX customer that has a huge (250) number of RZ-28 disks in Storageworks racks which are in bound volume sets.

It's not that they're running an ancient VMS (they're on V7.1), it's just that they haven't invested in new disks for a looong time.

Getting their storage strategy to something that can actually be supported is almost worth the price of the conversion alone...

[Robert_Boyd]

As I posted on comp.os.vms yesterday:

Since BACKUP/IMAGE/NOALIAS is not an option,
The workaround that seems most direct for this problem is the following procedure:

Capture the output of
$ DFU DIRECTORY/ALIAS /OUTPUT=.aliases

to generate a list of aliased files on the input volume set. Then do
the following:

$ backup/noalias :[000000]*.dir; :[000000]/by_owner=ORIGINAL
$ backup/noalias :[*...]*.*;* :[*...]/by_owner=ORIGINAL


Then for each aliased file delete all but one of the copies and perform the appropriate SET FILE/ENTER commands to re-create the structure of the input volume.

I'm posting CONVERT_VOLUME_SET.COM which implements this technique to dcl.OpenVMS.org

Robert

[Uwe Zessin]

Bound volume sets certainly are useful, sometimes!

I remember in the VAX/VMS V4 days we had an online area of PCB CAD data. Using a 3x400 MBytes BVS saved us from rewriting the archival software and playing any management voodo - until we had a bad massbus controller that destroyed one member :-(

But luckily you don't have a bad controller every day. Looking back I still beleive it was the right decision to use BVSets.


It is too bad that OpenVMS does not have a volume manager - anybody with a 'business case'? ;-)

[Robert Gezelter]

Robert,

Actually, I would recommended moving volume 1 of the set to the larger disk, then identifying files that needed to be relocated by using DIR/FID and SORT.

In a volume set, new files are created on the volume with the most free space. A simple COPY of a file on the wrong volume will then move it to the correct volume. To force this behavior, simply tie up all the free space on the other volumes by defining junk files in each of the root MFDs ([000000]) on each volume.

At that point, you should have migrated all of the files from the other volumes onto the first volume (you need to make sure that no files spanned multiple volumes, but that can be done by using ANALYZE/DISK or reading the INDEX file.

At this point, a small does of magic (either using LD to fake the other members of the set), or modifying the list of volumes will allow you to release the other volumes).

I do not guarantee that the above is without error or omission, I have written it from memory without re-reading the Files-11 Documenetation.

- Bob Gezelter, http://www.rlgsc.com

[Robert_Boyd]

Bob,

Thanks for the ideas -- I can see there might be an instance where that could come in as useful.

It turned out to be far simpler in my case to use the mechanism I described and posted to the DCL site. Without DFU it might have been necessary to do the process you described.

Fortunately DFU made it very easy to reconstruct the alias files.

Thanks to you and to the creator(s) of DFU!

Robert

[Robert_Boyd]

Thanks for all the ideas!

Robert