Conference vaxaxp::vmsnotes

    It shouldn't be relevant but:
    
    The disks that he binds into the volumeset are freshly initialised
    aren't they ?  Anything else is unsupported and furthermore, doesn't
    work...

    The disk to bind in the existing volume is a freshly initialized disk.
    There is not always to display this error messages. You shall find that
    he runs a command script, some of them are no problem, but some of them
    display this error. Any advice on it ? I assume the original disk 
    is already used a period of time. Does it work to use $mount/bind command 
    to add a new initialized disk to an existing used disk.
    
     

>> Does it work to use $mount/bind command 
>> to add a new initialized disk to an existing used disk.
 Yes, this is supported                                     

    re .0
    
    What does DISK$LOGHIS translate to? Which disk is being copied to? Are
    they specifying /VOLUME on the COPY?
    
    Perhaps the failures are intermittent because at times one disk is
    being copied to and at times the other (or indeed a single file might be
    spread across both disks).
    
    I don't know what the specific error means in practical terms. Have you
    tried STARS etc.?
    
    Are they using any unusual qualifiers on the INIT command (for the new
    disk)?
    
    Try ANAL/DISK
    
    Check for hardware errors (SHOW ERROR).

   My customer uses the following command to bind the disk.

$allocate $22$dia28: logdsk1
$allocate $22$dia30: logdsk2
$allocate $22$dia35: logdsk3
$allocate $22$dia40: logdsk4
$!
$init/system logdsk1 loghis1
$init/system logdsk2 loghis2
$init/system logdsk3 loghis3
$init/system logdsk4 loghis4
$!
$$deallocate $22$dia28: logdsk1
$deallocate $22$dia30: logdsk2
$deallocate $22$dia35: logdsk3
$deallocate $22$dia40: logdsk4
$!
$mount/bind=loghis/system logdsk1,logdsk2,logdsk3,logdsk4 -
loghis1,loghis2,loghis3,loghis4
$exit

Does it have any problem on his mount/bind command procedure. Any advice should
be appreciated.
    
    I only use $mount/bind on my system, there is no problem, but I find
    that customer uses $mount/bind/system. Does it support /system
    qualifiers ?
    

    
    This ought to work. Maybe just a bad disk in the bunch. You may want
    to study how the files are spread over the disks. The basic bound 
    volume set algoritmes are very easy... whenever a new file allocation 
    is to take place, look for the disk with more disk blocks free (even
    1 block for say TEST.DIR will make a difference) and stick it there.
    If a file grows, stick to its original disk untill that is entirely
    full (or an extenstion header is needed?) and then create an extension
    header on the disk with most blocks free at that point.
    So, after those copies failed, try some DIRE/FILE and DUMP/HEAD to
    understand the spread. Are those files big enough to need more than
    one disk?
    
    Note... from a performance point of view, they may want to consider
    using DISK STRIPING for example through our SW_RAID product.
    
    hth,
    	Hein.

re .5
    
    The procedure looks fine to me.
    
>$deallocate $22$dia28: logdsk1
    
    Hmmm. This looks like a (harmless) bug.

    $ DEALLOCATE only takes one parameter but DCL seems to ignore any number of
    extraneous parameters.
    
> Does it support /system qualifiers ?
    
    Without testing it, I see no reason why /SYSTEM would be incompatible
    with /BIND.
    
    Have you any results from ANAL/DISK? A STARS search? SHOW ERROR?

|>$deallocate $22$dia28: logdsk1
|
|    Hmmm. This looks like a (harmless) bug.
|
|    $ DEALLOCATE only takes one parameter but DCL seems to ignore any number of
|    extraneous parameters.

V7.1 (properly) complains about the extraneous parameter.

-Mike

This might be a file system bug. It looks like he
has bad file headers on one of the disks. If you have to ipmt
it we will need a copy of indexf.sys off each of the 
disks in the bound volume set. 

- Jim