<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    The 2 instances boot ok now.<br>
    <br>
    Thanks to all again.<br>
    <br>
    Patrick.<br>
    <br>
    Le 20/10/2011 22:55, Matt a écrit :
    <blockquote cite="mid:4EA08AB0.4050003@btinternet.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      On 20/10/2011 19:16, Boucher, François wrote:
      <blockquote
        cite="mid:B3C24EA955FF0C4EA14658997CD3E25E4CCF9AFD@CAHIER.gst.uqam.ca"
        type="cite">
        <meta http-equiv="Content-Type" content="text/html;
          charset=ISO-8859-1">
        <meta name="Generator" content="MS Exchange Server version
          6.5.7654.12">
        <title>VMS Cluster boot on an unique container </title>
        <!-- Converted from text/plain format -->
        <p><font size="2">Hi!<br>
            <br>
            I never succeeded to operate a cluster of machines that
            attaches directly<br>
            to the same disk drives file images, when a first node
            writes to the system<br>
            disk, the other node was not aware of the changes and it
            ended up in a filesystem<br>
            corruption.  Perhaps I did not found the correct way to
            create/configure some sort of<br>
            dual-port scsi devices?</font><br>
        </p>
      </blockquote>
      The trick is to make sure that all nodes have the same ALLOCLASS
      parameter. This will cause there to be multiple devices in the
      cluster with the same full name (e.g. $1$DUA0) so VMS will assume
      they are the same physical device and the lock manager will take
      care of concurrent access. The only catch is that _every_ disk
      device that has the same name between two nodes is assumed to be
      the same physical device. If you attach them to different
      containers on the host side then you will get strange results and
      probably data corruption.<br>
      <br>
      To boot the secondary nodes with Simh use the R5 parameter to
      specify an alternative system root:<br>
      <br>
      sim> boot rq0 /r5:10000000<br>
      <br>
      to boot from SYS1.<br>
      <br>
      Matt<br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Simh mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a>
<a class="moz-txt-link-freetext" href="http://mailman.trailing-edge.com/mailman/listinfo/simh">http://mailman.trailing-edge.com/mailman/listinfo/simh</a></pre>
    </blockquote>
    <br>
  </body>
</html>