1 INFO-VAX	Sun, 10 Dec 2006	Volume 2006 : Issue 679       Contents: Re: Bad Shadow set member  Re: Bad Shadow set member  Re: Bad Shadow set member ! Re: IEEE Decimal Float on Itanium ) Re: OpenVMS Weekly Audio Update - Show #1   F ----------------------------------------------------------------------  % Date: Sun, 10 Dec 2006 09:51:54 +0100 4 From: Jur van der Burg <"vdburg at hotmail dot com">" Subject: Re: Bad Shadow set member4 Message-ID: <457bcaba$0$321$e4fe514c@news.xs4all.nl>  D That's not a bug. You asked specifically for NO copy, and due to the) power outage a merge copy is required....   D Perhaps you would like the /POLICY=REQUIRE_MEMBERS for mount so that) it insists on both members to be present.    Jur.   Tom Linden wrote: I > On Sat, 09 Dec 2006 19:12:40 -0800, AEF <spamsink2001@yahoo.com> wrote:  >  >> >> Tom Linden wrote:G >>> On Sat, 09 Dec 2006 12:19:35 -0800, <norm.raphael@metso.com> wrote:  >>> K >>> > "Tom Linden" <tom@kednos-remove.com> wrote on 12/09/2006 09:31:17 AM:  >> [...] >>> K >>> Sorry, should have been more clear.  The mount caommand issued manually  >>> worked fine  as below 2 >>> MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/ -" >>>   SHADOW=($42$DKA1300:) COMMON >>> I >>> What I was puzzling over was the mount command from the startup file   >>> that >>> had L >>> both members listed failed.  Why wouldn't mount, knowing that one member >>> had L >>> failed, take corrective action and mount the working member.  This seems' >>> fundamental to me for a shadow set.  >>  >> What was the error message??? > - > Looking through my logs this is all I found  >  > $     MOUNT K > DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=($42$DKA1200:,$42$DKA1300:)   > COMMON, > %MOUNT-F-SHDWCOPYREQ, shadow copy required > J > 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 >> >  >  > I > --Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------    Date: 10 Dec 2006 04:09:07 -0800$ From: "AEF" <spamsink2001@yahoo.com>" Subject: Re: Bad Shadow set memberC Message-ID: <1165752547.074311.170530@j44g2000cwa.googlegroups.com>    Jur van der Burg wrote: F > That's not a bug. You asked specifically for NO copy, and due to the+ > power outage a merge copy is required....   G But the other disk was broken, so no copy is even possible. Wouldn't it A make sense for the shadowing software to mount the only available B member? If you had a one-member shadow set, you're saying it stillF wouldn't mount because of the power outage? And even with a merge, the@ software is going to have to randomly pick one or the other disk anyway, right?   > F > Perhaps you would like the /POLICY=REQUIRE_MEMBERS for mount so that+ > it insists on both members to be present.   2 I think that's exactly what the OP *doesn't* want.   AEF    >  > Jur. >  > Tom Linden wrote: K > > On Sat, 09 Dec 2006 19:12:40 -0800, AEF <spamsink2001@yahoo.com> wrote:  > >  > >> > >> Tom Linden wrote:I > >>> On Sat, 09 Dec 2006 12:19:35 -0800, <norm.raphael@metso.com> wrote:  > >>> M > >>> > "Tom Linden" <tom@kednos-remove.com> wrote on 12/09/2006 09:31:17 AM: 
 > >> [...] > >>> M > >>> Sorry, should have been more clear.  The mount caommand issued manually  > >>> worked fine  as below 4 > >>> MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/ -$ > >>>   SHADOW=($42$DKA1300:) COMMON > >>> J > >>> What I was puzzling over was the mount command from the startup file
 > >>> that	 > >>> had N > >>> both members listed failed.  Why wouldn't mount, knowing that one member	 > >>> had N > >>> failed, take corrective action and mount the working member.  This seems) > >>> fundamental to me for a shadow set.  > >>" > >> What was the error message??? > > / > > Looking through my logs this is all I found  > >  > > $     MOUNT L > > DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=($42$DKA1200:,$42$DKA1300:)
 > > COMMON. > > %MOUNT-F-SHDWCOPYREQ, shadow copy required > > K > > Unless the above command is incorrect, this is a bug.  If a member of a  > > shadow set fails, A > > the mount command should recover,  otherwise have shadow sets  > >  > >>
 > >> [...] > >> > >> AEF > >> > >  > >  > > K > > --Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Sun, 10 Dec 2006 06:41:20 -0800 * From: "Tom Linden" <tom@kednos-remove.com>" Subject: Re: Bad Shadow set member) Message-ID: <op.tkclq6fxtte90l@hyrrokkin>   I On Sun, 10 Dec 2006 04:36:57 -0800, Jur van der Burg <"vdburg at hotmail=    =    dot com"> wrote:  ) > That depens on how broken the disk was.  > I >  > But the other disk was broken, so no copy is even possible. Wouldn'=  t  =   > itF >  > make sense for the shadowing software to mount the only available >  > member? > ( > Sure. Don't use /INCLUDE in that case. >  >  >And even with a merge, theE >  > software is going to have to randomly pick one or the other disk  >  > anyway, right?  > I > If you mean for copying the data, no. There's still a 'master' member,=   I > but the handling in case of errors is different than with a full copy.=   E > In the merge case any errors will be propagated from the bad to the D > good member. The only thing that counts in such a case is that the > disk are equal in the end.  I In my case bad meant dead, and that is the point.  When the system reboo=  ted I the the good member would not mount, but as i explained I had to manuall=  y G mount it, which seems to me to be a flaw in the concept since the whole I purpose of shadowing is to provide a higher degree of disaster tolerance=  .    >  > Jur. >  > AEF wrote: >> Jur van der Burg wrote:I >>> That's not a bug. You asked specifically for NO copy, and due to the=   - >>> power outage a merge copy is required.... I >>  But the other disk was broken, so no copy is even possible. Wouldn't=   it D >> make sense for the shadowing software to mount the only availableE >> member? If you had a one-member shadow set, you're saying it still I >> wouldn't mount because of the power outage? And even with a merge, th=  e C >> software is going to have to randomly pick one or the other disk  >> anyway, right?  >>I >>> Perhaps you would like the /POLICY=3DREQUIRE_MEMBERS for mount so th=  at- >>> it insists on both members to be present. 6 >>  I think that's exactly what the OP *doesn't* want. >>  AEF  >> >>> Jur. >>>  >>> Tom Linden wrote: H >>>> On Sat, 09 Dec 2006 19:12:40 -0800, AEF <spamsink2001@yahoo.com>  =   >>>> wrote:  >>>> >>>>> Tom Linden wrote: I >>>>>> On Sat, 09 Dec 2006 12:19:35 -0800, <norm.raphael@metso.com> wrot=  e: >>>>>>I >>>>>>> "Tom Linden" <tom@kednos-remove.com> wrote on 12/09/2006 09:31:1=  7  =   >>>>>>> AM:  >>>>> [...] H >>>>>> Sorry, should have been more clear.  The mount caommand issued  =   >>>>>> manually  >>>>>> worked fine  as below5 >>>>>> MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/ - ' >>>>>>   SHADOW=3D($42$DKA1300:) COMMON  >>>>>>I >>>>>> What I was puzzling over was the mount command from the startup f=  ile  >>>>>> that 
 >>>>>> hadI >>>>>> both members listed failed.  Why wouldn't mount, knowing that one=    =   
 >>>>>> member 
 >>>>>> hadI >>>>>> failed, take corrective action and mount the working member.  Thi=  s  =   >>>>>> seems* >>>>>> fundamental to me for a shadow set.# >>>>> What was the error message??? 0 >>>> Looking through my logs this is all I found >>>> >>>> $     MOUNTI >>>> DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=3D($42$DKA1200:,$42$DK=  A1300:)  >>>> 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,B >>>> the mount command should recover,  otherwise have shadow sets >>>> >>>>> [...]  >>>>> 	 >>>>> AEF  >>>>>  >>>> >>>>4 >>>> --Using Opera's revolutionary e-mail client:  =   >>>> http://www.opera.com/mail/  >>       -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Sun, 10 Dec 2006 06:24:01 -0800 * From: "Tom Linden" <tom@kednos-remove.com>* Subject: Re: IEEE Decimal Float on Itanium) Message-ID: <op.tkckybdrtte90l@hyrrokkin>   G On Sat, 09 Dec 2006 21:59:16 -0800, Bob Gezelter <gezelter@rlgsc.com>    wrote:   >  > Tom Linden wrote: . >> Is this going to be implemented on Itanium? >>5 >> Looks like IBM has the lead on everyone (as usual) ( >> z/Architecture DECIMAL FLOATING-POINT9 >> http://publibfi.boulder.ibm.com/epubs/pdf/a2322320.pdf  >>' >> http://www2.hursley.ibm.com/decimal/  >  > Tom, >  > My US $ 0.02.  > G > I too have used binary integers for years in such situations, because A > in most cases that I have encountered, the scaling was known in G > advance. This is, in effect, using integer with an understood decimal  > point. > E > I agree with Hoff, in that there are likely more desireable ways to I > implement this type of thing on IA-64, if it were desireable. Given the H > IA-64 paradigm, which is essentially compiler generated microcode, theI > equivalent of the IBM architecture extension (e.g., the addendum to the H > z/OS Principles of Operation) would be a series of code templates thatI > would be used by a compiler generating code. If my memory serves, there G > are some interesting ways of doing fast (or at least relatively fast) F > packed decimal arithmetic, although I would have to unearth my notesB > and texts from the last time that I looked at it. It would be an > interesting project.  H In general it is a bad idea to use binary for financial calculations.    Cobol H and PL/I have always supported fixed decimal (BCD) arithmetic, which hadK hardware support on VAX, but which we do in runtime on Alpha, another Alpha A design flaw to further limit market opportunities  The Algorithms K we use (e.g., excess 3) are reasonably efficient and go back to the early    50'sL  from UNIVAC IIRC.  Mike Colishaw, the inventor of Rexx is the driving forceJ behind this, but I must confess that incremental improvement over scaled   fixed L decimal that we provide in PL/I is marginal, in my view.  You get two more  	 digits of H significance, 33 vs. 31 and a much greater range,  but I have never seenK applications where range was a problem or not easily manageable.  A Forex    trading F application, for example, probably would not need precison and scale  
 exceeding say H (20,7) which provides two additional digits for rounding.  IBM has not  	 announced * any support in their compilers, only HASM. > & > - Bob Gezelter, http://www.rlgsc.com >        --  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------    Date: 10 Dec 2006 07:32:13 -0800! From: "Ian Miller" <gxys@uk2.net> 2 Subject: Re: OpenVMS Weekly Audio Update - Show #1B Message-ID: <1165764733.772345.207360@80g2000cwy.googlegroups.com>  E It was deliberately made a format that even Mac users could listen to  :-)    ------------------------------   End of INFO-VAX 2006.679 ************************