| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 172.1 | something along these lines? | POMPY::LESLIE | Andy Leslie, DEC man walking... | Tue Feb 11 1997 09:21 | 5 | 
|  |     $ dismount $1$dua99 		! mem of shadow set
    $ mount/over=id $1$dua99            ! mount privately
    $ set vol/label=oldwhat $1$dua99 	! set label
    $ dismount $1$dua99 		! dismount
    $ mount/sys $1$dua99 oldwhat	! mount system wide
 | 
| 172.2 | Not with volume sets | IJSAPL::VELDEN |  | Tue Feb 11 1997 09:53 | 6 | 
|  |     Andy,..
    
    Thanks for answering, but as far as I know this doesn't work with
    volumesets. 
    
    Frans
 | 
| 172.3 |  | POMPY::LESLIE | Andy Leslie, DEC man walking... | Tue Feb 11 1997 09:58 | 5 | 
|  |     Hmm. That's what I get for not reading the question properly
    (%ANDY-F-INSUFF_COFFEE)
    
    Surely if you change the lables of the disks, then
    mount/bind=oldwhatsit it'll work?
 | 
| 172.4 |  | AUSS::GARSON | DECcharity Program Office | Tue Feb 11 1997 21:02 | 10 | 
|  |     re .2
    
    What goes wrong? (for the benefit of those of us who couldn't be
    bothered trying it)
    
    Why do you use the volume set? That's a pretty comprehensive disk
    arrangement you have but I don't see the purpose of the volume set. If
    it is causing a problem then maybe you can get rid of it.
                                                                    
    The host based shadowing looked to be a little over the top too.
 | 
| 172.5 | Using volume sets | IJSAPL::VELDEN |  | Thu Feb 13 1997 04:44 | 27 | 
|  |     
    The issue with volumesets is that if, for example, you use a mirrored
    volume-set (mirrored on a HSJ and the volumeset bind with VMS) and you
    take the mirror members out of the volume set, than it is possible to
    mount this mirror members private as a second volumeset with no loss
    of the data. But if you try to mount this mirror member as a second 
    volumeset with the /system qualifier than VMS answers something like:
    cannot mount this set because this label is already in use. 
    
    The main problem is that, as far as I know, you cannot change this
    label. So again my question: does somebody know a proper way to get
    this second volumeset system-width mounted with another label and no
    loss of the data?
    
    As I said in .0, the reason we want to use volumesets is because the
    growth in the amount of data which will result, if we don't use volume
    sets, in batch cycles which take to long (there are only 24 hours in a
    day).
    
    I hope the problem is more clarified,
    
    
    Frans
    
    
    
       
 | 
| 172.7 | simple enough - but gotta hack about or program... | CERN::HOBBS | Congrats to the Ignoble Peace Prize winner!  (http://www.eecs.harvard.edu/ig_nobel) | Thu Feb 13 1997 05:22 | 77 | 
|  | The volset and volume names are stored in <000000>VOLSET.SYS on RVN 1.
tignes$ sho dev disk$kits
Device                  Device           Error    Volume         Free  Trans Mnt
 Name                   Status           Count     Label        Blocks Count Cnt
COMBIN$DKB0:            Mounted              0  KITS.1          297630     1   4
COMBIN$DKB100:          Mounted              0  KITS.2          297690     1   4
COMBIN$DKB200:          Mounted              0  KITS.3           24262     1   4
tignes$ with readall dump disk$kits:<000000>volset.sys
Dump of file KITS$:<000000>VOLSET.SYS;1 on 13-FEB-1997 11:07:51.42
File ID (6,6,1)   End of file block 1 / Allocated 3
Virtual block number 1 (00000001), 512 (0200) bytes
 00000000 20202020 20202020 5354494B KITS        .... 000000
 00000000 00000000 00000000 00000000 ................ 000010
 00000000 00000000 00000000 00000000 ................ 000020
 00000000 00000000 00000000 00000000 ................ 000030
 00000000 20202020 2020312E 5354494B KITS.1      .... 000040
 00000000 00000000 00000000 00000000 ................ 000050
 00000000 00000000 00000000 00000000 ................ 000060
 00000000 00000000 00000000 00000000 ................ 000070
 00000000 20202020 2020322E 5354494B KITS.2      .... 000080
 00000000 00000000 00000000 00000000 ................ 000090
 00000000 00000000 00000000 00000000 ................ 0000A0
 00000000 00000000 00000000 00000000 ................ 0000B0
 00000000 20202020 2020332E 5354494B KITS.3      .... 0000C0
 00000000 00000000 00000000 00000000 ................ 0000D0
 00000000 00000000 00000000 00000000 ................ 0000E0
 00000000 00000000 00000000 00000000 ................ 0000F0
 00000000 00000000 00000000 00000000 ................ 000100
 00000000 00000000 00000000 00000000 ................ 000110
 00000000 00000000 00000000 00000000 ................ 000120
So, what you need to do is:
	$ mount the set privately
	$ set volume /name=newname for each of the devices in the set
	$ patch the first 12 bytes of <000000>VOLSET.SYS on the root
	  volume to get the new set name
	$ dismount
	$ mount/system
crans$ patch/abs/nonew volset.sys
  PATCH  Version 7.1    26-JUL-1995
%PATCH-I-NOGBL, some or all global symbols not accessible
%PATCH-I-NOLCL, image does not contain local symbols
PATCH>e/asc 0:0c
PAA:  'FOOB'
00000004:  'AR  '
00000008:  '    '
0000000C:  ''
PATCH>rep/asc 0
OLD>'FOOB'
OLD>'AR  '
OLD>exit
NEW>'KITS'
NEW>'    '
NEW>exit
old:    PAA:  'FOOB'
old:    00000004:  'AR  '
new:    PAA:  'KITS'
new:    00000004:  '    '
PATCH>update
%PATCH-I-OVERLAY, KITS$:<000000>VOLSET.SYS;1 being overwritten
PATCH> Exit
   (note = the example patch is shows me restoring the correct name...)
-cw
 | 
| 172.8 |  | CSC64::BLAYLOCK | If at first you doubt,doubt again. | Thu Feb 13 1997 11:12 | 5 | 
|  | 
The volume set name is also kept in the volume home block
(VBN 2 and others of INDEXF.SYS) so patching VOLSET.SYS does
complete the job.  DFU (see NOTED::HACKERS) may be able to 
fix up the home block information.
 | 
| 172.9 |  | AUSS::GARSON | DECcharity Program Office | Thu Feb 13 1997 16:59 | 14 | 
|  |     re .5
    
    Well we probably shouldn't be suggesting hacks for a production
    environment but perhaps if you just clear out VOLSET.SYS and rebind,
    you can create a new volume set.
    
    I assume that it is the reporting that needs the shadow disks to be
    mounted /SYSTEM. BACKUP wouldn't need this. Can you restore the
    database elsewhere to do the reporting? Of course you can do the
    reporting single stream with a privately mounted set but you may not
    get optimal performance.
    
    The reason I questioned the use of volume sets is that given that you
    are already using stripe sets, why not just make the stripe sets bigger?
 | 
| 172.10 |  | UTRTSC::thecow.uto.dec.com::JurVanDerBurg | Change mode to Panic! | Fri Feb 14 1997 01:04 | 8 | 
|  | Re .0
Frans,
We've been through this before did'nt we? What was the problem with striping
instead of volume sets?
Jur.
 | 
| 172.11 | Continuing... | IJSAPL::VELDEN |  | Mon Feb 17 1997 08:10 | 17 | 
|  |     Re .9 and .10
    
    At the moment the customer is using stripe-sets of 5 and 6 members (RZ29's).
    As I said before, the performance and time issues are very important at
    this site. We also looked at host-based striping, but the problem with this
    is that we will have a device of at least 15 RZ29's using Contoller-
    and Host-Based striping. This means a vey long backup time. When using 
    volume sets it will be possible to backup in parallel the different volume 
    set members.
    
    We want to do the restore of the database simply by taking out the mirror
    set, change the bind name, and mount this with the /system qualifier.
    This happens twice because we also use host-based shadowing.
    So we can use one set for backup and the other for reports.
    
    Frans
    
 |