long, boring explanation of minicopy (and HBVS, in general)

From: Rob Brooks (brooks_at_cuebid.zko.dec.nospam)
Date: 05/29/04 

Date: Sat, 29 May 2004 19:53:25 GMT

(Phillip Helbig---remove CLOTHES to reply) writes:
> There have been various threads on this topic, but there doesn't seem to
> be a general consensus about what works, what is the proper behaviour,
> what is the actual behaviour etc.

I have been following a bit of these discussions, but not with any great
detail. Independent of whether or not there has been any comp.os.vms
consensus about what is the proper behaviour, if you ask a specific
question about perceived behaviour, I'll tell you what the expected
behaviour is, assuming a modern version of OpenVMS.

> I'm still confused about VAX support. Which of the following situations
> would benefit from DISMOUNT/POLICY-MINICOPY (assume two VAX and one
> ALPHA node in the cluster):

A VAX cannot have a minicopy bitmap on it. A VAX **can** have its
writes registered on a minicopy bitmap that exists on an Alpha (or Itanium,
for V8.2 and beyond. The implementation of Host-Based Volume Shadowing on
Itanium **IS IDENTICAL** to that on the Alpha hardware. The only differences
in the code exist to deal with the differences in the calling standards of the
two architectures.)

In all the examples you give, the only one that could not benefit
from minicopy is the one where the Alpha is shut down. For the others,
as long as the shadow set is mounted on an Alpha (even if its connection
is MSCP through a surviving VAX), you can use minicopy. If a shadow
set is mounted on an Alpha, but its only connection is MSCP through
the VAX being shut down, then you cannot use minicopy.

If this is not clear, please let me know and I'll take another stab at it.

Also, have you read the manual? If you have and it is not clear, let me
know that, also. We think that the manual does a very good job at explaining
this. If we're wrong, we'll clarify whatever is confusing.

Note that for V8.2, the shadowing manual has been substantially
modified to account for Host-Based Minimerge (HBMM) and the new copy/merge
priority scheme that gives a system manager complete control over what
systems perform merges/copies on each shadow set and in what order the
merges/copies are done. This merge/copy priority stuff is pretty
useful, we think. The merge/copy priority scheme will also be in the
HBMM kit for V7.3-2 that will be in field test in about a month, and
available for production near the end of the year.
             

-- 
Rob Brooks    VMS Engineering -- I/O Exec Group     brooks!cuebid.zko.dec.com

Relevant Pages

  • Re: two questions about MINICOPY
    ... >> connection to the shadow set fails), can I expect that a) a minicopy ... > shadow server knows nothing about files. ... >> mounting it from an ALPHA after all, ...
    (comp.os.vms)
  • Re: Wierd problem when alpha blitting image with text in it
    ... When the shadow is faded out, ... constant alpha is applied to the whole window. ... windows can have per-pixel but cannot have any child windows. ... So this leaves me with the image pixels being however opaque they ...
    (microsoft.public.win32.programmer.gdi)
  • Re: host-based minimerge and VAX
    ... Whereas minicopy requires that all cluster members have minicopy ... While HBMM does not run on OpenVMS Alpha V7.3 ...
    (comp.os.vms)
  • minicopy, VAX, ALPHA, SHADOW_MAX_COPY, SYSMAN, SYSGEN
    ... I find that DISMOUNT/POLICY=MINICOPY followed by a MOUNT ... command allows a minicopy as opposed to a full copy even if none of the ... members on the shadow set has a direct connection to an ALPHA. ... o the MOUNT command must be issued from an ALPHA ...
    (comp.os.vms)
  • Re: Wierd problem when alpha blitting image with text in it
    ... When the shadow is faded out, ... constant alpha is applied to the whole window. ... constant opacity and alpha channel at the same time, ...
    (microsoft.public.win32.programmer.gdi)