1 INFO-VAX	Sun, 10 Dec 2006	Volume 2006 : Issue 678       Contents: Re: Bad Shadow set member  Re: Bad Shadow set member  Re: Bad Shadow set member  Re: Bad Shadow set member  Re: Bad Shadow set member  Re: Bad Shadow set member  Re: Bad Shadow set member . Re: Can you emulate openvms on x86 windows XP?! Re: IEEE Decimal Float on Itanium * Re: Managed vs unmanaged switch in cluster" Re: Standalone vs a regular backup" Re: Standalone vs a regular backup" Re: Standalone vs a regular backup8 Re: Suggestion: use LAT for updating expired VMS license  F ----------------------------------------------------------------------  $ Date: Sat, 9 Dec 2006 15:19:35 -0500 From: norm.raphael@metso.com" Subject: Re: Bad Shadow set memberQ Message-ID: <OF26F0257F.979D6627-ON8525723F.006F2692-8525723F.006FC114@metso.com>   + This is a multipart message in MIME format. " --=_alternative 006FC1108525723F_=, Content-Type: text/plain; charset="US-ASCII"  E "Tom Linden" <tom@kednos-remove.com> wrote on 12/09/2006 09:31:17 AM:   H > following a power outage one of the shadow sets did not mount.  Turns  one < > Turns one of the two members, $42$DKA1200:,  had gone bad. >  > This is in the startup3 > $ MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/ -  + > SHADOW=($42$DKA1200:,$42$DKA1300:) COMMON  >  > 7 > So I had to manually mount omitting the first member.  > C > Doesn't mount detect that one member is bad and mount the other?   > Am I  missing a qualifier?  D It turns out you asked it to do a copy if needed with the "INCLUDE" J qualifer, but told it not to copy and not to mount if a copy was required I with the "NOCOPY" qualifier.  This protected and alerted you rather well.  (HELP is your friend.)   MOUNT   
   /INCLUDE  ?         /INCLUDE virtual-unit-name[:] /SHADOW=(physical-device-          name[:][,...])A         /NOINCLUDE virtual-unit-name[:] /SHADOW=(physical-device-           name[:][,...]) (default)  E      Automatically reconstructs a former shadow set to the way it was F      before the shadow set was dissolved. This qualifier is applicableB      only if you have the volume shadowing option. Refer to Volume6      Shadowing for OpenVMS for additional information.  ?      The /INCLUDE qualifier automatically mounts and restores a A      shadow set to the way it was before a system failure. Supply F      the exact virtual-unit name that was used when the shadow set wasE      You must also include the /SHADOW qualifier and specify at least B      one of the disk devices from the original shadow set. Use theF      standard device-naming format $allocation-class$ddcu[:]. Omit the-      parentheses if you name only one device.   B      The /INCLUDE qualifier is position independent; it can appear"      anywhere on the command line.  )      The default qualifier is /NOINCLUDE.         Example  C      The following example shows how to create a shadow set wherein F      the software determines automatically the shadow set members thatF      should be mounted. The /SHADOW qualifier ensures the correct copyE      operation for the two shadow set members. In this case, $1$DUA10 B      is the more current volume and becomes the source of the copy      operation to $1$DUA11.   ?      If the shadow set was properly dismounted and no write I/O <      requests remain outstanding, the shadow set devices are>      consistent and are added back without the need for a copy@      or merge operation. Otherwise, Volume Shadowing for OpenVMS6      automatically performs a copy or merge operation.  6      $ MOUNT/INCLUDE DSA0: /SHADOW=$1$DUA10: SHADOWVOL1      %MOUNT-I-MOUNTED, SHADOWVOL mounted on DSA0: H      %MOUNT-I-SHDWMEMSUCC, _$1$DUA10: (MEMBER1) is now a valid member of      the shadow set G      %MOUNT-I-SHDWMEMCOPY, _$1$DUA11: (MEMBER2) added to the shadow set       with a copy operation    MOUNT      /COPY   9         /COPY virtual-unit-name[:] /SHADOW=(physical-dev-           name[:][,...]) (default);         /NOCOPY virtual-unit-name[:] /SHADOW=(physical-dev-          name[:][,...])  F      Enables or disables copy operations on physical devices specifiedF      when you mount a shadow set. This qualifier is applicable only ifD      you have the volume shadowing option. Refer to Volume Shadowing,      for OpenVMS for additional information.  C      The /COPY qualifier instructs MOUNT to perform copy operations B      on shadow set members. You can mount shadow sets with /NOCOPY?      to test if proposed shadow set members are targets of copy A      operations. If any of the specified volumes is a target of a B      copy operation, the command quits without mounting any of theC      specified volumes (including those that did not require a copy       operation).  A      The /NOCOPY qualifier is similar to /CONFIRM. Use /NOCOPY to E      mount shadow sets in the site-specific startup command procedure @      SYS$MANAGER:SYSTARTUP_VMS.COM; use /CONFIRM for interactive      mounting.        Example  D      The following example shows how to use the /NOCOPY qualifier toE      check the status of potential shadow set members before any data F      is erased. The command instructs MOUNT to build a shadow set withD      the specified devices only if a copy operation is not required.B      Because the device DUA7 required a copy operation to become aF      member of the shadow set, the mount failed. You could reissue theC      command specifying /COPY to instruct MOUNT to build the shadow 0      set providing the necessary copy operation.  @      $ MOUNT/NOCOPY DSA2: /SHADOW=($1$DUA4:,$1$DUA6:,$1$DUA7:) -!      _$  SHADOWVOL DISK$SHADOWVOL /      %MOUNT-F-SHDWCOPYREQ, shadow copy required E      %MOUNT-I-SHDWMEMFAIL, DUA7: failed as a member of the shadow set /      %MOUNT-F-SHDWCOPYREQ, shadow copy required      " --=_alternative 006FC1108525723F_=+ Content-Type: text/html; charset="US-ASCII"      <br>I <br><font size=2><tt>&quot;Tom Linden&quot; &lt;tom@kednos-remove.com&gt; $ wrote on 12/09/2006 09:31:17 AM:<br> <br>O &gt; following a power outage one of the shadow sets did not mount. &nbsp;Turns  one<br> H &gt; Turns one of the two members, $42$DKA1200:, &nbsp;had gone bad.<br>	 &gt; <br>  &gt; This is in the startup<br> B &gt; $ MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/ - </tt></font>G <br><font size=2><tt>&gt; SHADOW=($42$DKA1200:,$42$DKA1300:) COMMON<br> 	 &gt; <br> 	 &gt; <br> > &gt; So I had to manually mount omitting the first member.<br>	 &gt; <br> X &gt; Doesn't mount detect that one member is bad and mount the other? &nbsp;</tt></font>E <br><font size=2><tt>&gt; Am I &nbsp;missing a qualifier?</tt></font>  <br>J <br><font size=2><tt>It turns out you asked it to do a copy if needed with$ the &quot;INCLUDE&quot; </tt></font>G <br><font size=2><tt>qualifer, but told it not to copy and not to mount # if a copy was required </tt></font> F <br><font size=2><tt>with the &quot;NOCOPY&quot; qualifier. &nbsp;This2 protected and alerted you rather well.</tt></font>7 <br><font size=2><tt>(HELP is your friend.)</tt></font>  <br><font size=2><tt><br>  MOUNT</tt></font>  <br>0 <br><font size=2><tt>&nbsp; /INCLUDE</tt></font> <br>N <br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; /INCLUDE virtual-unit-name[:]% /SHADOW=(physical-device-</tt></font> K <br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; name[:][,...])</tt></font> P <br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; /NOINCLUDE virtual-unit-name[:]% /SHADOW=(physical-device-</tt></font> U <br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; name[:][,...]) (default)</tt></font>  <br>L <br><font size=2><tt>&nbsp; &nbsp; &nbsp;Automatically reconstructs a former( shadow set to the way it was</tt></font>M <br><font size=2><tt>&nbsp; &nbsp; &nbsp;before the shadow set was dissolved. ( This qualifier is applicable</tt></font>N <br><font size=2><tt>&nbsp; &nbsp; &nbsp;only if you have the volume shadowing# option. Refer to Volume</tt></font> M <br><font size=2><tt>&nbsp; &nbsp; &nbsp;Shadowing for OpenVMS for additional  information.</tt></font> <br>M <br><font size=2><tt>&nbsp; &nbsp; &nbsp;The /INCLUDE qualifier automatically ! mounts and restores a</tt></font> L <br><font size=2><tt>&nbsp; &nbsp; &nbsp;shadow set to the way it was before$ a system failure. Supply</tt></font>I <br><font size=2><tt>&nbsp; &nbsp; &nbsp;the exact virtual-unit name that , was used when the shadow set was</tt></font>J <br><font size=2><tt>&nbsp; &nbsp; &nbsp;You must also include the /SHADOW* qualifier and specify at least</tt></font>I <br><font size=2><tt>&nbsp; &nbsp; &nbsp;one of the disk devices from the ( original shadow set. Use the</tt></font>F <br><font size=2><tt>&nbsp; &nbsp; &nbsp;standard device-naming format/ $allocation-class$ddcu[:]. Omit the</tt></font> I <br><font size=2><tt>&nbsp; &nbsp; &nbsp;parentheses if you name only one  device.</tt></font>  <br>K <br><font size=2><tt>&nbsp; &nbsp; &nbsp;The /INCLUDE qualifier is position & independent; it can appear</tt></font>R <br><font size=2><tt>&nbsp; &nbsp; &nbsp;anywhere on the command line.</tt></font> <br>Y <br><font size=2><tt>&nbsp; &nbsp; &nbsp;The default qualifier is /NOINCLUDE.</tt></font>  <br>< <br><font size=2><tt>&nbsp; &nbsp; &nbsp;Example</tt></font> <br>H <br><font size=2><tt>&nbsp; &nbsp; &nbsp;The following example shows how* to create a shadow set wherein</tt></font>N <br><font size=2><tt>&nbsp; &nbsp; &nbsp;the software determines automatically' the shadow set members that</tt></font> G <br><font size=2><tt>&nbsp; &nbsp; &nbsp;should be mounted. The /SHADOW . qualifier ensures the correct copy</tt></font>I <br><font size=2><tt>&nbsp; &nbsp; &nbsp;operation for the two shadow set + members. In this case, $1$DUA10</tt></font> G <br><font size=2><tt>&nbsp; &nbsp; &nbsp;is the more current volume and * becomes the source of the copy</tt></font>K <br><font size=2><tt>&nbsp; &nbsp; &nbsp;operation to $1$DUA11.</tt></font>  <br>G <br><font size=2><tt>&nbsp; &nbsp; &nbsp;If the shadow set was properly ' dismounted and no write I/O</tt></font> I <br><font size=2><tt>&nbsp; &nbsp; &nbsp;requests remain outstanding, the " shadow set devices are</tt></font>F <br><font size=2><tt>&nbsp; &nbsp; &nbsp;consistent and are added back' without the need for a copy</tt></font> G <br><font size=2><tt>&nbsp; &nbsp; &nbsp;or merge operation. Otherwise, ( Volume Shadowing for OpenVMS</tt></font>F <br><font size=2><tt>&nbsp; &nbsp; &nbsp;automatically performs a copy or merge operation.</tt></font>  <br>P <br><font size=2><tt>&nbsp; &nbsp; &nbsp;$ MOUNT/INCLUDE DSA0: /SHADOW=$1$DUA10: SHADOWVOL</tt></font> L <br><font size=2><tt>&nbsp; &nbsp; &nbsp;%MOUNT-I-MOUNTED, SHADOWVOL mounted on DSA0:</tt></font>I <br><font size=2><tt>&nbsp; &nbsp; &nbsp;%MOUNT-I-SHDWMEMSUCC, _$1$DUA10: . (MEMBER1) is now a valid member of</tt></font>C <br><font size=2><tt>&nbsp; &nbsp; &nbsp;the shadow set</tt></font> I <br><font size=2><tt>&nbsp; &nbsp; &nbsp;%MOUNT-I-SHDWMEMCOPY, _$1$DUA11: - (MEMBER2) added to the shadow set</tt></font> J <br><font size=2><tt>&nbsp; &nbsp; &nbsp;with a copy operation</tt></font>. <br><font size=2><tt>&nbsp; &nbsp;</tt></font>& <br><font size=2><tt>MOUNT</tt></font> <br>- <br><font size=2><tt>&nbsp; /COPY</tt></font>  <br>K <br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; /COPY virtual-unit-name[:] " /SHADOW=(physical-dev-</tt></font>U <br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; name[:][,...]) (default)</tt></font> M <br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; /NOCOPY virtual-unit-name[:] " /SHADOW=(physical-dev-</tt></font>K <br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; name[:][,...])</tt></font>  <br>L <br><font size=2><tt>&nbsp; &nbsp; &nbsp;Enables or disables copy operations) on physical devices specified</tt></font> J <br><font size=2><tt>&nbsp; &nbsp; &nbsp;when you mount a shadow set. This+ qualifier is applicable only if</tt></font> F <br><font size=2><tt>&nbsp; &nbsp; &nbsp;you have the volume shadowing- option. Refer to Volume Shadowing</tt></font> \ <br><font size=2><tt>&nbsp; &nbsp; &nbsp;for OpenVMS for additional information.</tt></font> <br>F <br><font size=2><tt>&nbsp; &nbsp; &nbsp;The /COPY qualifier instructs, MOUNT to perform copy operations</tt></font>G <br><font size=2><tt>&nbsp; &nbsp; &nbsp;on shadow set members. You can * mount shadow sets with /NOCOPY</tt></font>G <br><font size=2><tt>&nbsp; &nbsp; &nbsp;to test if proposed shadow set ' members are targets of copy</tt></font> L <br><font size=2><tt>&nbsp; &nbsp; &nbsp;operations. If any of the specified$ volumes is a target of a</tt></font>J <br><font size=2><tt>&nbsp; &nbsp; &nbsp;copy operation, the command quits' without mounting any of the</tt></font> K <br><font size=2><tt>&nbsp; &nbsp; &nbsp;specified volumes (including those ' that did not require a copy</tt></font> @ <br><font size=2><tt>&nbsp; &nbsp; &nbsp;operation).</tt></font> <br>I <br><font size=2><tt>&nbsp; &nbsp; &nbsp;The /NOCOPY qualifier is similar ' to /CONFIRM. Use /NOCOPY to</tt></font> O <br><font size=2><tt>&nbsp; &nbsp; &nbsp;mount shadow sets in the site-specific % startup command procedure</tt></font> G <br><font size=2><tt>&nbsp; &nbsp; &nbsp;SYS$MANAGER:SYSTARTUP_VMS.COM; ( use /CONFIRM for interactive</tt></font>> <br><font size=2><tt>&nbsp; &nbsp; &nbsp;mounting.</tt></font> <br>< <br><font size=2><tt>&nbsp; &nbsp; &nbsp;Example</tt></font> <br>H <br><font size=2><tt>&nbsp; &nbsp; &nbsp;The following example shows how+ to use the /NOCOPY qualifier to</tt></font> F <br><font size=2><tt>&nbsp; &nbsp; &nbsp;check the status of potential. shadow set members before any data</tt></font>I <br><font size=2><tt>&nbsp; &nbsp; &nbsp;is erased. The command instructs , MOUNT to build a shadow set with</tt></font>F <br><font size=2><tt>&nbsp; &nbsp; &nbsp;the specified devices only if- a copy operation is not required.</tt></font> I <br><font size=2><tt>&nbsp; &nbsp; &nbsp;Because the device DUA7 required ( a copy operation to become a</tt></font>F <br><font size=2><tt>&nbsp; &nbsp; &nbsp;member of the shadow set, the/ mount failed. You could reissue the</tt></font> M <br><font size=2><tt>&nbsp; &nbsp; &nbsp;command specifying /COPY to instruct % MOUNT to build the shadow</tt></font> I <br><font size=2><tt>&nbsp; &nbsp; &nbsp;set providing the necessary copy  operation.</tt></font> <br>b <br><font size=2><tt>&nbsp; &nbsp; &nbsp;$ MOUNT/NOCOPY DSA2: /SHADOW=($1$DUA4:,$1$DUA6:,$1$DUA7:)
 -</tt></font> V <br><font size=2><tt>&nbsp; &nbsp; &nbsp;_$ &nbsp;SHADOWVOL DISK$SHADOWVOL</tt></font>J <br><font size=2><tt>&nbsp; &nbsp; &nbsp;%MOUNT-F-SHDWCOPYREQ, shadow copy required</tt></font>K <br><font size=2><tt>&nbsp; &nbsp; &nbsp;%MOUNT-I-SHDWMEMFAIL, DUA7: failed ) as a member of the shadow set</tt></font> J <br><font size=2><tt>&nbsp; &nbsp; &nbsp;%MOUNT-F-SHDWCOPYREQ, shadow copy required</tt></font>. <br><font size=2><tt>&nbsp; &nbsp;</tt></font> <br>$ --=_alternative 006FC1108525723F_=--   ------------------------------   Date: 9 Dec 2006 14:41:40 -0800 $ From: "AEF" <spamsink2001@yahoo.com>" Subject: Re: Bad Shadow set memberA Message-ID: <1165704100.173454.31980@73g2000cwn.googlegroups.com>    norm.raphael@metso.com wrote: G > "Tom Linden" <tom@kednos-remove.com> wrote on 12/09/2006 09:31:17 AM:  > I > > following a power outage one of the shadow sets did not mount.  Turns  > one > > > Turns one of the two members, $42$DKA1200:,  had gone bad. > >  > > This is in the startup4 > > $ MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/ -- > > SHADOW=($42$DKA1200:,$42$DKA1300:) COMMON  > >  > > 9 > > So I had to manually mount omitting the first member.  > > D > > Doesn't mount detect that one member is bad and mount the other? > > Am I  missing a qualifier? > E > It turns out you asked it to do a copy if needed with the "INCLUDE" K > qualifer, but told it not to copy and not to mount if a copy was required K > with the "NOCOPY" qualifier.  This protected and alerted you rather well.   D But no copy operation was required. There was only one working disk.D Your explanation would make sense only if the first member listed inD the command is assumed to be the most current. Is that the case? And! where is that hidden in the docs?    [...]    AEF    ------------------------------  % Date: Sat, 09 Dec 2006 14:35:32 -0800 * From: "Tom Linden" <tom@kednos-remove.com>" Subject: Re: Bad Shadow set member) Message-ID: <op.tkbc1izgtte90l@hyrrokkin>   C On Sat, 09 Dec 2006 12:19:35 -0800, <norm.raphael@metso.com> wrote:   G > "Tom Linden" <tom@kednos-remove.com> wrote on 12/09/2006 09:31:17 AM:  > I >> following a power outage one of the shadow sets did not mount.  Turns=    > one = >> Turns one of the two members, $42$DKA1200:,  had gone bad.  >> >> This is in the startup 3 >> $ MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/ - . >> SHADOW=3D($42$DKA1200:,$42$DKA1300:) COMMON >> >>8 >> So I had to manually mount omitting the first member. >>C >> Doesn't mount detect that one member is bad and mount the other?  >> Am I  missing a qualifier?  > E > It turns out you asked it to do a copy if needed with the "INCLUDE" I > qualifer, but told it not to copy and not to mount if a copy was requi=  red I > with the "NOCOPY" qualifier.  This protected and alerted you rather we=  ll.  > (HELP is your friend.)  G Sorry, should have been more clear.  The mount caommand issued manually  worked fine  as below . MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/ -    SHADOW=3D($42$DKA1300:) COMMON  I What I was puzzling over was the mount command from the startup file tha=  t  =   had I both members listed failed.  Why wouldn't mount, knowing that one member=    =    had I failed, take corrective action and mount the working member.  This seems=   # fundamental to me for a shadow set.    >  > MOUNT  >  >   /INCLUDE > C >         /INCLUDE virtual-unit-name[:] /SHADOW=3D(physical-device-  >         name[:][,...])E >         /NOINCLUDE virtual-unit-name[:] /SHADOW=3D(physical-device- " >         name[:][,...]) (default) > G >      Automatically reconstructs a former shadow set to the way it was I >      before the shadow set was dissolved. This qualifier is applicable=   D >      only if you have the volume shadowing option. Refer to Volume8 >      Shadowing for OpenVMS for additional information. > A >      The /INCLUDE qualifier automatically mounts and restores a C >      shadow set to the way it was before a system failure. Supply I >      the exact virtual-unit name that was used when the shadow set was=   G >      You must also include the /SHADOW qualifier and specify at least D >      one of the disk devices from the original shadow set. Use theI >      standard device-naming format $allocation-class$ddcu[:]. Omit the=   / >      parentheses if you name only one device.  > D >      The /INCLUDE qualifier is position independent; it can appear$ >      anywhere on the command line. > + >      The default qualifier is /NOINCLUDE.  >  >      Example > E >      The following example shows how to create a shadow set wherein I >      the software determines automatically the shadow set members that=   I >      should be mounted. The /SHADOW qualifier ensures the correct copy=   G >      operation for the two shadow set members. In this case, $1$DUA10 D >      is the more current volume and becomes the source of the copy >      operation to $1$DUA11.  > A >      If the shadow set was properly dismounted and no write I/O > >      requests remain outstanding, the shadow set devices are@ >      consistent and are added back without the need for a copyB >      or merge operation. Otherwise, Volume Shadowing for OpenVMS8 >      automatically performs a copy or merge operation. > : >      $ MOUNT/INCLUDE DSA0: /SHADOW=3D$1$DUA10: SHADOWVOL3 >      %MOUNT-I-MOUNTED, SHADOWVOL mounted on DSA0: I >      %MOUNT-I-SHDWMEMSUCC, _$1$DUA10: (MEMBER1) is now a valid member =  of >      the shadow set I >      %MOUNT-I-SHDWMEMCOPY, _$1$DUA11: (MEMBER2) added to the shadow se=  t  >      with a copy operation > MOUNT  > 	 >   /COPY  > = >         /COPY virtual-unit-name[:] /SHADOW=3D(physical-dev- " >         name[:][,...]) (default)? >         /NOCOPY virtual-unit-name[:] /SHADOW=3D(physical-dev-  >         name[:][,...]) > I >      Enables or disables copy operations on physical devices specified=   I >      when you mount a shadow set. This qualifier is applicable only if=   F >      you have the volume shadowing option. Refer to Volume Shadowing. >      for OpenVMS for additional information. > E >      The /COPY qualifier instructs MOUNT to perform copy operations D >      on shadow set members. You can mount shadow sets with /NOCOPYA >      to test if proposed shadow set members are targets of copy C >      operations. If any of the specified volumes is a target of a D >      copy operation, the command quits without mounting any of theE >      specified volumes (including those that did not require a copy  >      operation). > C >      The /NOCOPY qualifier is similar to /CONFIRM. Use /NOCOPY to G >      mount shadow sets in the site-specific startup command procedure B >      SYS$MANAGER:SYSTARTUP_VMS.COM; use /CONFIRM for interactive >      mounting. >  >      Example > F >      The following example shows how to use the /NOCOPY qualifier toG >      check the status of potential shadow set members before any data I >      is erased. The command instructs MOUNT to build a shadow set with=   F >      the specified devices only if a copy operation is not required.D >      Because the device DUA7 required a copy operation to become aI >      member of the shadow set, the mount failed. You could reissue the=   E >      command specifying /COPY to instruct MOUNT to build the shadow 2 >      set providing the necessary copy operation. > D >      $ MOUNT/NOCOPY DSA2: /SHADOW=3D($1$DUA4:,$1$DUA6:,$1$DUA7:) -# >      _$  SHADOWVOL DISK$SHADOWVOL 1 >      %MOUNT-F-SHDWCOPYREQ, shadow copy required G >      %MOUNT-I-SHDWMEMFAIL, DUA7: failed as a member of the shadow set 1 >      %MOUNT-F-SHDWCOPYREQ, shadow copy required  >        -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------   Date: 9 Dec 2006 15:12:46 -0800 ! From: "Ian Miller" <gxys@uk2.net> " Subject: Re: Bad Shadow set memberB Message-ID: <1165705966.544698.116670@73g2000cwn.googlegroups.com>  E I think by using /INCLUDE you are insisting the shadow set is created F as it was with two members. As one disk was  not available then it did not mount the shadow set.  Try it without /INCLUDE    ------------------------------   Date: 9 Dec 2006 19:12:40 -0800 $ From: "AEF" <spamsink2001@yahoo.com>" Subject: Re: Bad Shadow set memberC Message-ID: <1165720360.501263.101150@j44g2000cwa.googlegroups.com>    Tom Linden wrote: E > On Sat, 09 Dec 2006 12:19:35 -0800, <norm.raphael@metso.com> wrote:  > I > > "Tom Linden" <tom@kednos-remove.com> wrote on 12/09/2006 09:31:17 AM:  [...]  > I > Sorry, should have been more clear.  The mount caommand issued manually  > worked fine  as below 0 > MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/ -  >   SHADOW=($42$DKA1300:) COMMON > K > What I was puzzling over was the mount command from the startup file that  > had J > both members listed failed.  Why wouldn't mount, knowing that one member > had J > failed, take corrective action and mount the working member.  This seems% > fundamental to me for a shadow set.    What was the error message???    [...]    AEF    ------------------------------  % Date: Sat, 09 Dec 2006 19:31:18 -0800 * From: "Tom Linden" <tom@kednos-remove.com>" Subject: Re: Bad Shadow set member) Message-ID: <op.tkbqqgqrtte90l@hyrrokkin>   G On Sat, 09 Dec 2006 19:12:40 -0800, AEF <spamsink2001@yahoo.com> wrote:    >  > Tom Linden wrote: F >> On Sat, 09 Dec 2006 12:19:35 -0800, <norm.raphael@metso.com> wrote: >>I >> > "Tom Linden" <tom@kednos-remove.com> wrote on 12/09/2006 09:31:17 A=  M: > [...]  >>I >> Sorry, should have been more clear.  The mount caommand issued manual=  ly >> worked fine  as below1 >> MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/ - # >>   SHADOW=3D($42$DKA1300:) COMMON  >>I >> What I was puzzling over was the mount command from the startup file =   =   >> that  >> hadI >> both members listed failed.  Why wouldn't mount, knowing that one mem=  ber  >> hadI >> failed, take corrective action and mount the working member.  This se=  ems & >> fundamental to me for a shadow set. >  > What was the error message???   + Looking through my logs this is all I found    $     MOUNT  =  I DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=3D($42$DKA1200:,$42$DKA1300=  :)  =    COMMON* %MOUNT-F-SHDWCOPYREQ, shadow copy required  I Unless the above command is incorrect, this is a bug.  If a member of a =   =   shadow set fails, = the mount command should recover,  otherwise have shadow sets    >  > [...]  >  > AEF  >        -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Sat, 09 Dec 2006 19:37:39 -0800 * From: "Tom Linden" <tom@kednos-remove.com>" Subject: Re: Bad Shadow set member) Message-ID: <op.tkbq01cvtte90l@hyrrokkin>   D On Sat, 09 Dec 2006 15:12:46 -0800, Ian Miller <gxys@uk2.net> wrote:  G > I think by using /INCLUDE you are insisting the shadow set is created I > as it was with two members. As one disk was  not available then it did=    > not mount the shadow set.  > Try it without /INCLUDE  > A So you are saying that I should not have /imclude in the startup?   
 $ MOUNT  =  I DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=3D($42$DKA1200:,$42$DKA1300=  :)  =    COMMON  F so that without the /include if one member is bad it will mount the  =   other?   if both are good, it will mount both?    -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Sat, 09 Dec 2006 20:21:53 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 7 Subject: Re: Can you emulate openvms on x86 windows XP? 8 Message-ID: <b61ec$457b6141$cef8887a$11362@TEKSAVVY.COM>   davidc@montagar.com wrote:E > The correct web site is http://www.openvmshobbyist.com for all your  > Hobbyist information.     K Yeah. but www.montagar.com  is quicker to type and easier to remember, and  K besides, you deserve some publicity for all the good work you are doing :-)   G Now, if you were to program your montagar web site to send an electric  J shock to my mouse if I were to click on the hobbyist link, then perhaps I J might be convinced to work on remembering that long name for the hobbyist  stuff ! :-)    ------------------------------   Date: 9 Dec 2006 21:59:16 -0800 ) From: "Bob Gezelter" <gezelter@rlgsc.com> * Subject: Re: IEEE Decimal Float on ItaniumB Message-ID: <1165730356.936089.246350@80g2000cwy.googlegroups.com>   Tom Linden wrote: - > Is this going to be implemented on Itanium?  > 4 > Looks like IBM has the lead on everyone (as usual)' > z/Architecture DECIMAL FLOATING-POINT 8 > http://publibfi.boulder.ibm.com/epubs/pdf/a2322320.pdf > & > http://www2.hursley.ibm.com/decimal/   Tom,  
 My US $ 0.02.   E I too have used binary integers for years in such situations, because ? in most cases that I have encountered, the scaling was known in E advance. This is, in effect, using integer with an understood decimal  point.  C I agree with Hoff, in that there are likely more desireable ways to G implement this type of thing on IA-64, if it were desireable. Given the F IA-64 paradigm, which is essentially compiler generated microcode, theG equivalent of the IBM architecture extension (e.g., the addendum to the F z/OS Principles of Operation) would be a series of code templates thatG would be used by a compiler generating code. If my memory serves, there E are some interesting ways of doing fast (or at least relatively fast) D packed decimal arithmetic, although I would have to unearth my notes@ and texts from the last time that I looked at it. It would be an interesting project.  $ - Bob Gezelter, http://www.rlgsc.com   ------------------------------  % Date: Sat, 09 Dec 2006 18:20:39 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 3 Subject: Re: Managed vs unmanaged switch in cluster 8 Message-ID: <ea2b0$457b44d7$cef8887a$26783@TEKSAVVY.COM>   Robert Deininger wrote: I > The only problems I've experienced personally were with autonegotiation  > failures.   L Yep and over the years, I have seen many discussions here about people with  negotiation problems.     L > the LAN device drivers.  And the LANCP utility makes it easier to see whatE > is going on from the VMS side, and control network settings to some I > extent.  You no longer have to reboot to change the duplex setting, for 
 > example.  F Except on VAX where LANCP is more limited in functionality. (SHWO DEV , /CHARACTERISTICS doesn't exist for instance)    I > Details of the deficiencies might be useful here.  Are there functional  > problems?   F I described them back in end of september/early october when I got my K alpha. it could mop boot, but not join a cluster. (sort of strange to have  J it mop boot with vaxcluster=0 and still be able to access its system disk I on the boot node). I don't know enough about SCS use of ethernet to know  ' what feature would have cause problems.     , > VMS and windows send and receive packets.   K But VMS is more likely to use features of ethernet which Windows don't use  I and perhaps such features were never tested on that switch. (which was a   combo switch/router).   K I was like you before, a switch is a switch and transfers all packets. But  5 I have seen one occasion where that was not the case.     O > I'm curious how you perceive a PC's use of ethernet to differ from VMS's use.   E Obviously, since that switch failed to transfer all packets in a SCS  G environment, VMS uses some/a feature of ethernet that was not properly   implemented on that switch.     G > Dunno.  I've never used it.  Do you find yourself diagnosing a lot of  > ethernet problems?    J When I was with the cable company, yes. I had to use ethermon to prove to L them that I was receiving data from then and sending a DHCP request without  gettting any DHCP response.   F Anothere example is to verify how the TCPIP Services cluster failover I actually works at the arp level to see why one device on the lan doesn't  D update its ARP table with the new MAC address associated with an IP.  L > Unless you make an effort to actually measure latency and response time onI > your VMS system, you likely won't notice a difference due to a switch.      = OK, what could I do to measure performance before and after ?   J Note that on the switch, since the addition of the alpha, I have seen the L collision light on often during the copy of large files across the ethernet.    >If not, don't worry about it.   C I am not *worried* about performance. Just wondering if it makes a  K difference and if so, how to measure it. I plan to bring in a second alpha  B and between the two alpha and the mac, full 100mbps could be used.   ------------------------------  % Date: Sun, 10 Dec 2006 01:17:04 +0800  From: prep@prep.synonet.com + Subject: Re: Standalone vs a regular backup 0 Message-ID: <87mz5x3s6n.fsf@k9.prep.synonet.com>  % "H Vlems" <hvlems@freenet.de> writes:   ? > Standalone backup makes IMAGE backups, can't remember whether E > /PHYSICAL is even an option with SAB but those who feel they really E > need a physical backup do that for a very specific purpose, usually  > just once.  ) It was, but HSC backup did it way faster!    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.? ------------ And now a word from our sponsor ------------------ > Want to have instant messaging, and chat rooms, and discussion: groups for your local users or business, you need dbabble!? --  See http://netwinsite.com/sponsor/sponsor_dbabble.htm  ----    ------------------------------   Date: 9 Dec 2006 14:56:17 -0800 $ From: "AEF" <spamsink2001@yahoo.com>+ Subject: Re: Standalone vs a regular backup B Message-ID: <1165704977.588925.98200@j72g2000cwa.googlegroups.com>   H Vlems wrote: > Richard B. Gilbert schreef:  > # > > tomarsin2015@comcast.net wrote:  > >  [...] I > Standalone backup makes IMAGE backups, can't remember whether /PHYSICAL B > is even an option with SAB but those who feel they really need aI > physical backup do that for a very specific purpose, usually just once.   ( You can use /IMAGE or /PHYSICAL in SAB.    AEF    [...]    ------------------------------   Date: 10 Dec 2006 04:14:03 GMT) From: Hans Bachner <Hans@Bachner.priv.at> + Subject: Re: Standalone vs a regular backup 0 Message-ID: <elg52q.7n.1@usenet.bachner.priv.at>  " H Vlems <hvlems@freenet.de> wrote:   <snip>B > If the " week backup"  is not an image saveset then it cannot be > restored with SAB.    I If you can install VMS on a spare disk, you can use "standard" backup to  + restore your system disk from there, but...   2 > Then again, chances are slim that such a saveset& > would build a functional systemdisk.  D ... this requires some manual work, but should be possible. In most H cases, the system disk of a standalone node has one link only which you > need to repair - the entry of [000000]vms$common.dir as [sys0]
 syscommon.dir   # > No owner information nor security G > attributes will be restored so the resulting system is unlikely to be  > a copy of  what was lost.   J This is not true - owner and security information is also maintained with 6 non-image backups (just restore with /OWNER=ORIGINAL).   Hans.    ------------------------------   Date: 10 Dec 2006 03:55:00 GMT) From: Hans Bachner <Hans@Bachner.priv.at> A Subject: Re: Suggestion: use LAT for updating expired VMS license 0 Message-ID: <elg3v3.7n.1@usenet.bachner.priv.at>  I Using LAT is an excellent suggestion, the rest can be done even slightly   easier:   5 George Cornelius <cornelius@encompasserve.org> wrote:    <snip>  F >  4. $ LICENSE ISSUE VMS-USER/PROC/OUT=VMS-USER.PAK ! Or whatever PAK
 >  is needed  A >     $ LICENSE ENABLE VMS-USER ! Reenable - prior op disables it  >     $ TYPE VMS-USER.PAK  <snip>  
 make that    $ LICENSE ISSUE VMS-USER/PROC  $ LICENSE ENABLE VMS-USER   B If you omit the /OUTPUT qualifier, you get the result directly to < SYS$OUTPUT (your SETHOST.LOG) and can save the TYPE command.   Hans.    ------------------------------   End of INFO-VAX 2006.678 ************************