1 INFO-VAX	Thu, 14 Dec 2006	Volume 2006 : Issue 686       Contents: /LGICMD suggestion Re: /LGICMD suggestion Re: /LGICMD suggestion Re: /LGICMD suggestion Re: /LGICMD suggestion Re: /LGICMD suggestion Re: /LGICMD suggestion Re: /LGICMD suggestion< Re: Alpha 8.3 BACKUP and bound volumes, size reporting (bug) Re: Bad Address  Re: Bad Address  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: 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 ' Cluster: Deleting CSB for System <node>  consulting job in raleigh nc Re: DEC 3000/400 problems 7 Password expiration and non-interactive access question ; Re: Password expiration and non-interactive access question ; Re: Password expiration and non-interactive access question ; Re: Password expiration and non-interactive access question  Re: PATCH on Alpha and Itanium Testing picture file integrity" Re: Testing picture file integrity) textual description of digital keyboards? - Re: textual description of digital keyboards? - Re: textual description of digital keyboards? ; Re: VAX VMS 7.3,  ana/image running out of virtual memory ? / RE: VMS VERSION - V7.3-2, V8.2, V8.3 difference / Re: VMS VERSION - V7.3-2, V8.2, V8.3 difference   F ----------------------------------------------------------------------  % Date: Wed, 13 Dec 2006 15:57:07 -0800 * From: "Tom Linden" <tom@kednos-remove.com> Subject: /LGICMD suggestion ) Message-ID: <op.tkivhhaatte90l@hyrrokkin>    permitting syntax of the form   1 UAF> modify tom/LGICMD=3D(filespec1, filespec2..)  with the meaning- if filespec1 not available then use filespec2  would be useful    Tom    ------------------------------  % Date: Wed, 13 Dec 2006 16:35:34 -0800 * From: "Tom Linden" <tom@kednos-remove.com> Subject: Re: /LGICMD suggestion ) Message-ID: <op.tkiw9kmvtte90l@hyrrokkin>   9 On Wed, 13 Dec 2006 16:34:18 -0800, Richard B. Gilbert  =    <rgilbert88@comcast.net> wrote:    > Tom Linden wrote:  > ! >>  permitting syntax of the form 5 >>  UAF> modify tom/LGICMD=3D(filespec1, filespec2..)  >> with the meaning 0 >> if filespec1 not available then use filespec2 >> would be useful >>  Tom  >> > I > In some twenty-two years of working with VMS, I can't recall a situati=  on  =   ' > in which this would have been useful!  > I Suppose all user directories and site specific startup applications are =  onI a disk separate from the system disk.  If that disk failed, you couldn't=   G login to your user account, and you might have difficulty for policy  =    reasons 1 (e.g., remote access) logging into system account      -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 13 Dec 2006 19:34:18 -0500 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net>  Subject: Re: /LGICMD suggestion : Message-ID: <9_-dnU_As6eZAR3YnZ2dnUVZ_rHinZ2d@comcast.com>   Tom Linden wrote:    >  > permitting syntax of the form  > 1 > UAF> modify tom/LGICMD=(filespec1, filespec2..)  > with the meaning/ > if filespec1 not available then use filespec2  > would be useful  >  > Tom  >   I In some twenty-two years of working with VMS, I can't recall a situation  % in which this would have been useful!    ------------------------------    Date: 13 Dec 2006 17:00:17 -0800/ From: "David B Sneddon" <dbsneddon@bigpond.com>  Subject: Re: /LGICMD suggestion B Message-ID: <1166058017.082750.98180@t46g2000cwa.googlegroups.com>  A On Dec 14, 12:35 am, "Tom Linden" <t...@kednos-remove.com> wrote: 8 > On Wed, 13 Dec 2006 16:34:18 -0800, Richard B. Gilbert > ! > <rgilber...@comcast.net> wrote:  > > Tom Linden wrote:  > # > >>  permitting syntax of the form 5 > >>  UAF> modify tom/LGICMD=(filespec1, filespec2..)  > >> with the meaning 2 > >> if filespec1 not available then use filespec2 > >> would be useful	 > >>  Tom  > L > > In some twenty-two years of working with VMS, I can't recall a situations > > in which this would have been useful!Suppose all user directories and site specific startup applications are on J > a disk separate from the system disk.  If that disk failed, you couldn'tF > login to your user account, and you might have difficulty for policy	 > reasons 3 > (e.g., remote access) logging into system account  >  > --F > Using Opera's revolutionary e-mail client:http://www.opera.com/mail/   And search lists can't be used?    Dave   ------------------------------  % Date: Wed, 13 Dec 2006 17:56:12 -0800 * From: "Tom Linden" <tom@kednos-remove.com> Subject: Re: /LGICMD suggestion ) Message-ID: <op.tki0zycvtte90l@hyrrokkin>   6 On Wed, 13 Dec 2006 17:00:17 -0800, David B Sneddon  =   <dbsneddon@bigpond.com> wrote:   >  > C > On Dec 14, 12:35 am, "Tom Linden" <t...@kednos-remove.com> wrote: 9 >> On Wed, 13 Dec 2006 16:34:18 -0800, Richard B. Gilbert  >>" >> <rgilber...@comcast.net> wrote: >> > Tom Linden wrote: >>$ >> >>  permitting syntax of the form8 >> >>  UAF> modify tom/LGICMD=3D(filespec1, filespec2..) >> >> with the meaning3 >> >> if filespec1 not available then use filespec2  >> >> would be useful 
 >> >>  Tom >>F >> > In some twenty-two years of working with VMS, I can't recall a  =   >> situationI >> > in which this would have been useful!Suppose all user directories a=  nd  =   , >> site specific startup applications are onI >> a disk separate from the system disk.  If that disk failed, you could=  n't G >> login to your user account, and you might have difficulty for policy 
 >> reasons4 >> (e.g., remote access) logging into system account >> >> -- G >> Using Opera's revolutionary e-mail client:http://www.opera.com/mail/  > ! > And search lists can't be used?    Please explain.  >  > Dave >    ------------------------------    Date: 13 Dec 2006 18:33:53 -0800/ From: "David B Sneddon" <dbsneddon@bigpond.com>  Subject: Re: /LGICMD suggestion A Message-ID: <1166063633.642012.41430@73g2000cwn.googlegroups.com>   @ On Dec 14, 1:56 am, "Tom Linden" <t...@kednos-remove.com> wrote:5 > On Wed, 13 Dec 2006 17:00:17 -0800, David B Sneddon  >  >  >   > <dbsned...@bigpond.com> wrote: > E > > On Dec 14, 12:35 am, "Tom Linden" <t...@kednos-remove.com> wrote: ; > >> On Wed, 13 Dec 2006 16:34:18 -0800, Richard B. Gilbert  > $ > >> <rgilber...@comcast.net> wrote: > >> > Tom Linden wrote: > & > >> >>  permitting syntax of the form8 > >> >>  UAF> modify tom/LGICMD=(filespec1, filespec2..) > >> >> with the meaning5 > >> >> if filespec1 not available then use filespec2  > >> >> would be useful  > >> >>  Tom > E > >> > In some twenty-two years of working with VMS, I can't recall a  > >> situationL > >> > in which this would have been useful!Suppose all user directories and. > >> site specific startup applications are onM > >> a disk separate from the system disk.  If that disk failed, you couldn't I > >> login to your user account, and you might have difficulty for policy  > >> reasons6 > >> (e.g., remote access) logging into system account >  > >> -- I > >> Using Opera's revolutionary e-mail client:http://www.opera.com/mail/  > # > > And search lists can't be used?  >  >Please explain. >  >  >  > > Dave   Totally untested...   0 define/system/exec alldisks disk1:,disk2:,disk3:> define/system/exec toms_login_com alldisks:[user.tom]login.com. mcr authorize modify tom/lgicmd=toms_login.com   Dave   ------------------------------    Date: 13 Dec 2006 18:37:00 -0800/ From: "David B Sneddon" <dbsneddon@bigpond.com>  Subject: Re: /LGICMD suggestion B Message-ID: <1166063820.268251.70080@j72g2000cwa.googlegroups.com>  D On Dec 14, 2:33 am, "David B Sneddon" <dbsned...@bigpond.com> wrote: > 2 > define/system/exec alldisks disk1:,disk2:,disk3:@ > define/system/exec toms_login_com alldisks:[user.tom]login.com0 > mcr authorize modify tom/lgicmd=toms_login.com  / That should be of course /lgicmd=toms_login_com  >  > Dave   ------------------------------  % Date: Wed, 13 Dec 2006 18:51:07 -0800 * From: "Tom Linden" <tom@kednos-remove.com> Subject: Re: /LGICMD suggestion ) Message-ID: <op.tki3jhwette90l@hyrrokkin>   6 On Wed, 13 Dec 2006 18:33:53 -0800, David B Sneddon  =   <dbsneddon@bigpond.com> wrote:   >  > B > On Dec 14, 1:56 am, "Tom Linden" <t...@kednos-remove.com> wrote:6 >> On Wed, 13 Dec 2006 17:00:17 -0800, David B Sneddon >> >> >>! >> <dbsned...@bigpond.com> wrote:  >>F >> > On Dec 14, 12:35 am, "Tom Linden" <t...@kednos-remove.com> wrote:< >> >> On Wed, 13 Dec 2006 16:34:18 -0800, Richard B. Gilbert >>% >> >> <rgilber...@comcast.net> wrote:  >> >> > Tom Linden wrote:  >>' >> >> >>  permitting syntax of the form ; >> >> >>  UAF> modify tom/LGICMD=3D(filespec1, filespec2..)  >> >> >> with the meaning 6 >> >> >> if filespec1 not available then use filespec2 >> >> >> would be useful
 >> >> >>  Tom  >>F >> >> > In some twenty-two years of working with VMS, I can't recall a >> >> situation I >> >> > in which this would have been useful!Suppose all user directorie=  s  =   >> and/ >> >> site specific startup applications are on H >> >> a disk separate from the system disk.  If that disk failed, you  =   >> couldn't I >> >> login to your user account, and you might have difficulty for poli=  cy
 >> >> reasons 7 >> >> (e.g., remote access) logging into system account  >> >> >> --I >> >> Using Opera's revolutionary e-mail client:http://www.opera.com/mai=  l/ >>$ >> > And search lists can't be used? >> >> Please explain. >> >> >>	 >> > Dave  >  > Totally untested...  > 2 > define/system/exec alldisks disk1:,disk2:,disk3:@ > define/system/exec toms_login_com alldisks:[user.tom]login.com2 > mcr authorize modify tom/lgicmd=3Dtoms_login.com >   . Cute, I withdraw the suggestions, thanks mate. > Dave >        -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 13 Dec 2006 14:58:32 -0500 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net> E Subject: Re: Alpha 8.3 BACKUP and bound volumes, size reporting (bug) : Message-ID: <HtCdnb4KZbX5xh3YnZ2dnUVZ_vShnZ2d@comcast.com>   etmsreec@yahoo.co.uk wrote:   @ > Maybe fundamental was a poor choice of word, but given that JFH > complained on another thread that his problems were due to his upgrade > to 7.3 it's not *that* poor. > I > My take, overall, on bound volume sets is similar to that of Richard G. H > - use them if you have to but they're risky things in some situations.I > If one spindle goes, the volume is toast.  Their design, I would guess, H > dates back to when disk storage was expensive.  These days, storage is > cheap. >  <snip>  F I think that cost of the disk was not so much a factor as the size of G disks!!!  I came on board in 1984 when an RA81 with, IIRC, 456MB was a  I huge disk!  It was also expensive; again IIRC it had a $25,000 price tag  D and that MAY have been AFTER educational discount!!!!!  The earlier G drives (washing machine style RPxx or RMxx) were physically bigger but   had even less capacity.   F A bound volume set may be justified if you have a file that is larger D than what a single drive will hold.  My first choice in such a case I would be a bigger disk or a RAID-5 set.  I'd go to a bound volume set if   neither option was available.    ------------------------------    Date: 13 Dec 2006 16:36:09 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: Bad Address3 Message-ID: <YiX6A9DP11sX@eisner.encompasserve.org>   p In article <VcGdnaTB549n6R3YnZ2dnUVZ_qK3nZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:I > It seems as if every time I post to comp.os.vms in the last few days I  ( > get a message with the following text: > : > "CSF Solutions Ltd is now a subsidiary of Logicalis Plc. > < > Your message has been forwarded to the intended recipient,. > but please note the mail address has changed > from <name> @csf.co.uk > to <name> @uk.logicalis.com  > J > Kindly update your contacts list or address book to ensure mail will be  > delivered in the future."  > I > Would the guilty party please fix his return and reply-to addresses or   > his subscription to info-vax?  >  > Thank you.  D I warned the postmaster on the last one and said that future reportsE would be via spamcop.  You+me = Bulk, it is certainly unsolicited and  email.   ------------------------------    Date: 13 Dec 2006 18:58:02 -0800$ From: "AEF" <spamsink2001@yahoo.com> Subject: Re: Bad AddressB Message-ID: <1166065082.091564.37390@n67g2000cwd.googlegroups.com>   Larry Kilgallen wrote:r > In article <VcGdnaTB549n6R3YnZ2dnUVZ_qK3nZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:J > > It seems as if every time I post to comp.os.vms in the last few days I* > > get a message with the following text: > > < > > "CSF Solutions Ltd is now a subsidiary of Logicalis Plc. > > > > > Your message has been forwarded to the intended recipient,0 > > but please note the mail address has changed > > from <name> @csf.co.uk > > to <name> @uk.logicalis.com  > > K > > Kindly update your contacts list or address book to ensure mail will be  > > delivered in the future."  > > J > > Would the guilty party please fix his return and reply-to addresses or! > > his subscription to info-vax?  > >  > > Thank you. > F > I warned the postmaster on the last one and said that future reportsG > would be via spamcop.  You+me = Bulk, it is certainly unsolicited and  > email.  D I, too, have been getting these -- one for every post I post. That's 50% more bulk!  F Just as an aside, my spamsink address also attracts lots of email with= .GE.95% funny characters (none of which are legal in an ODS-2 G filespec!) in the From and Subject fields. Does anyone know what that's F all about? They're unreadable! Am I being spammed by space aliens? :-)E Is there some kind of email noise on the Net??? Is it a new Microsoft % feature? What IS it??? What ARE they?    AEF    ------------------------------  % Date: Wed, 13 Dec 2006 10:47:25 -0800 * From: "Tom Linden" <tom@kednos-remove.com>" Subject: Re: Bad Shadow set member) Message-ID: <op.tkig5biitte90l@hyrrokkin>   G On Wed, 13 Dec 2006 05:14:43 -0800, AEF <spamsink2001@yahoo.com> wrote:    >  > JF Mezei wrote:  >> Tom Linden wrote:I >> > Thanks.  BTW, I am having a new drive overnighted to me.  Anything =  inI >> > particular I need to pay attention to when adding it?  I presume I =   =   >> need  >> > to INIT first?  >> >>I >> If not inited, it reduces the chances that the shadowing software mig=  ht( >> decide to use that drive as a source. >>I >> Also, when you first include the physical drive into the shadowset,  =   
 >> eittherH >> mount it into an existing shadowset, or ensure it is not the first  =  	 >> device 5 >> listed in the /SHADOW=3D(drive1,drive2,drive3,etc)  > E > If he just adds the disk with the system running and uses /CONFIRM,  > that should be enough. > # But I still need to INIT the drive. I DSA0:                   Mounted              0  COMMON        84555222  =     =   40   5A $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)   . $42$DKA1200:  (HAFNER)  Online               1A $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)    so how does this look % $ INIT/SHADOW=3D($42$DKA1200:) common 4 $ mount/confirm DSA0:/shadow=3D($42$DKA1200:) common           -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------    Date: 13 Dec 2006 11:12:28 -0800$ From: "AEF" <spamsink2001@yahoo.com>" Subject: Re: Bad Shadow set memberB Message-ID: <1166037148.781516.228570@80g2000cwy.googlegroups.com>   Tom Linden wrote: I > On Wed, 13 Dec 2006 05:14:43 -0800, AEF <spamsink2001@yahoo.com> wrote:  >  > >  > > JF Mezei wrote:  > >> Tom Linden wrote:L > >> > Thanks.  BTW, I am having a new drive overnighted to me.  Anything inI > >> > particular I need to pay attention to when adding it?  I presume I 	 > >> need  > >> > to INIT first?  > >> > >>L > >> If not inited, it reduces the chances that the shadowing software might* > >> decide to use that drive as a source. > >>H > >> Also, when you first include the physical drive into the shadowset, > >> eittherG > >> mount it into an existing shadowset, or ensure it is not the first  > >> device 5 > >> listed in the /SHADOW=(drive1,drive2,drive3,etc)  > > G > > If he just adds the disk with the system running and uses /CONFIRM,  > > that should be enough. > > % > But I still need to INIT the drive.   F Why? Why do you need to init the drive? It's going to be the target ofG a full copy operation so whatever is there will be clobbered, INITed or  not.  H > DSA0:                   Mounted              0  COMMON        84555222 > 40   5C > $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)  > 0 > $42$DKA1200:  (HAFNER)  Online               1C > $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)  >  > so how does this look % > $ INIT/SHADOW=($42$DKA1200:) common   B The manual says there is no advantage to INIT/SHADOW when adding a( drive to an already existing shadow set.   I quote fromC http://h71000.www7.hp.com/doc/732FINAL/aa-pvxmj-te/aa-pvxmj-te.HTML   = Note that the INITIALIZE/SHADOW command should not be used to G initialize a disk to be added to an existing shadow set, since there is  no benefit to be gained.  4 > $ mount/confirm DSA0:/shadow=($42$DKA1200:) common  F Just use the command above and you'll be fine. For startup I think youD want to specify both disks without /INCLUDE and without /NOCOPY, but with /NOASSIST.    [...]    AEF    ------------------------------    Date: 13 Dec 2006 11:17:08 -0800$ From: "AEF" <spamsink2001@yahoo.com>" Subject: Re: Bad Shadow set memberA Message-ID: <1166037428.413897.84290@f1g2000cwa.googlegroups.com>    Michael Moroney wrote: > prep@prep.synonet.com writes:  > / > >"Tom Linden" <tom@kednos-remove.com> writes:  > G > >> Thanks.  BTW, I am having a new drive overnighted to me.  Anything H > >> in particular I need to pay attention to when adding it?  I presume > >> I need to INIT first? > + > >INIT/ERASE gets you a good speed up AIR.  > I > ...if the current members were also INIT/ERASEd and still largely empty > > (or you have lots of blocks of binary zeroes in your files). > G > Probably never a loss of time since INIT/ERASE is faster than a copy, 4 > and there are likely many blocks of zeroes anyway.  F But isn't the new disk going to be the target of a full copy operation4 anyway? In which case the INIT command is pointless?   AEF    ------------------------------  % Date: Wed, 13 Dec 2006 11:08:35 -0800 * From: "Tom Linden" <tom@kednos-remove.com>" Subject: Re: Bad Shadow set member) Message-ID: <op.tkih4lk4tte90l@hyrrokkin>   G On Wed, 13 Dec 2006 11:12:28 -0800, AEF <spamsink2001@yahoo.com> wrote:    > Tom Linden wrote: I >> On Wed, 13 Dec 2006 05:14:43 -0800, AEF <spamsink2001@yahoo.com> wrot=  e: >> >> > >> > JF Mezei wrote: >> >> Tom Linden wrote: I >> >> > Thanks.  BTW, I am having a new drive overnighted to me.  Anythi=  ng  =    >> in I >> >> > particular I need to pay attention to when adding it?  I presume=   I
 >> >> need >> >> > to INIT first? >> >>  >> >> I >> >> If not inited, it reduces the chances that the shadowing software =   =   >> might+ >> >> decide to use that drive as a source.  >> >> I >> >> Also, when you first include the physical drive into the shadowset=  , 
 >> >> eitther I >> >> mount it into an existing shadowset, or ensure it is not the first=    >> >> device8 >> >> listed in the /SHADOW=3D(drive1,drive2,drive3,etc) >> >I >> > If he just adds the disk with the system running and uses /CONFIRM,=    >> > that should be enough.  >> >& >> But I still need to INIT the drive. > I > Why? Why do you need to init the drive? It's going to be the target of=   I > a full copy operation so whatever is there will be clobbered, INITed o=  r  > not.  F Yes I saw that in the documentation, but what if this drive came off a non-VMS system?    > I >> DSA0:                   Mounted              0  COMMON        8455522=  2 	 >> 40   5 D >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:) >>1 >> $42$DKA1200:  (HAFNER)  Online               1 D >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:) >> >> so how does this look( >> $ INIT/SHADOW=3D($42$DKA1200:) common > D > The manual says there is no advantage to INIT/SHADOW when adding a* > drive to an already existing shadow set. >  > I quote fromE > http://h71000.www7.hp.com/doc/732FINAL/aa-pvxmj-te/aa-pvxmj-te.HTML  > ? > Note that the INITIALIZE/SHADOW command should not be used to I > initialize a disk to be added to an existing shadow set, since there i=  s  > no benefit to be gained. > 7 >> $ mount/confirm DSA0:/shadow=3D($42$DKA1200:) common  > I > Just use the command above and you'll be fine. For startup I think you=   F > want to specify both disks without /INCLUDE and without /NOCOPY, but > with /NOASSIST.  >  > [...]  >  > AEF  >        -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 13 Dec 2006 15:10:09 -0500  From: norm.raphael@metso.com" Subject: Re: Bad Shadow set memberQ Message-ID: <OF4411A2BC.ADB09880-ON85257243.006E882C-85257243.006ECB1E@metso.com>   E "Tom Linden" <tom@kednos-remove.com> wrote on 12/13/2006 02:08:35 PM:   I > On Wed, 13 Dec 2006 11:12:28 -0800, AEF <spamsink2001@yahoo.com> wrote:  >  > > Tom Linden wrote: E > >> On Wed, 13 Dec 2006 05:14:43 -0800, AEF <spamsink2001@yahoo.com>  wrote: > >> > >> > > >> > JF Mezei wrote: > >> >> Tom Linden wrote: B > >> >> > Thanks.  BTW, I am having a new drive overnighted to me. Anything > >> in J > >> >> > particular I need to pay attention to when adding it?  I presume I  > >> >> need > >> >> > to INIT first? > >> >>  > >> >> I > >> >> If not inited, it reduces the chances that the shadowing software 
 > >> might- > >> >> decide to use that drive as a source.  > >> >> K > >> >> Also, when you first include the physical drive into the shadowset,  > >> >> eitther J > >> >> mount it into an existing shadowset, or ensure it is not the first > >> >> device8 > >> >> listed in the /SHADOW=(drive1,drive2,drive3,etc) > >> >J > >> > If he just adds the disk with the system running and uses /CONFIRM, > >> > that should be enough.  > >> >( > >> But I still need to INIT the drive. > > J > > Why? Why do you need to init the drive? It's going to be the target ofK > > a full copy operation so whatever is there will be clobbered, INITed or  > > not. > H > Yes I saw that in the documentation, but what if this drive came off a > non-VMS system?   J No matter.  Drive will be mounted/foreign underneath the shadow driver andK a full copy will be done.  Nothing that was there will matter.  Now if your K new drive is larger than your source drive and you want to prevent garbage- H collection of the old blocks years from now, the I suppose an INIT/ERASEK wouldn't hurt, but old stuff doesn't matter to the target of a shadow copy.    >  > > K > >> DSA0:                   Mounted              0  COMMON        84555222  > >> 40   5 F > >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:) > >>3 > >> $42$DKA1200:  (HAFNER)  Online               1 F > >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:) > >> > >> so how does this look( > >> $ INIT/SHADOW=($42$DKA1200:) common > > F > > The manual says there is no advantage to INIT/SHADOW when adding a, > > drive to an already existing shadow set. > >  > > I quote fromG > > http://h71000.www7.hp.com/doc/732FINAL/aa-pvxmj-te/aa-pvxmj-te.HTML  > > A > > Note that the INITIALIZE/SHADOW command should not be used to K > > initialize a disk to be added to an existing shadow set, since there is  > > no benefit to be gained. > > 7 > >> $ mount/confirm DSA0:/shadow=($42$DKA1200:) common  > > J > > Just use the command above and you'll be fine. For startup I think youH > > want to specify both disks without /INCLUDE and without /NOCOPY, but > > with /NOASSIST.  > > 	 > > [...]  > >  > > AEF  > >  >  >  >  > --G > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------    Date: 13 Dec 2006 12:12:26 -0800$ From: "AEF" <spamsink2001@yahoo.com>" Subject: Re: Bad Shadow set memberB Message-ID: <1166040746.270584.272460@79g2000cws.googlegroups.com>   Tom Linden wrote: I > On Wed, 13 Dec 2006 11:12:28 -0800, AEF <spamsink2001@yahoo.com> wrote:  >  > > Tom Linden wrote: L > >> On Wed, 13 Dec 2006 05:14:43 -0800, AEF <spamsink2001@yahoo.com> wrote: > >> > >> > > >> > JF Mezei wrote: > >> >> Tom Linden wrote: L > >> >> > Thanks.  BTW, I am having a new drive overnighted to me.  Anything > >> in L > >> >> > particular I need to pay attention to when adding it?  I presume I > >> >> need > >> >> > to INIT first? > >> >>  > >> >> I > >> >> If not inited, it reduces the chances that the shadowing software 
 > >> might- > >> >> decide to use that drive as a source.  > >> >> K > >> >> Also, when you first include the physical drive into the shadowset,  > >> >> eitther J > >> >> mount it into an existing shadowset, or ensure it is not the first > >> >> device8 > >> >> listed in the /SHADOW=(drive1,drive2,drive3,etc) > >> >J > >> > If he just adds the disk with the system running and uses /CONFIRM, > >> > that should be enough.  > >> >( > >> But I still need to INIT the drive. > > J > > Why? Why do you need to init the drive? It's going to be the target ofK > > a full copy operation so whatever is there will be clobbered, INITed or  > > not. > H > Yes I saw that in the documentation, but what if this drive came off a > non-VMS system?   G Hmmm. I think that might confuse /CONFIRM because it would be trying to G read the label, but I think it should still work. A quick INIT wouldn't E hurt, but I'd skip the ERASE because it will be the targete of a full  copy operation anyway, no?   >  > > K > >> DSA0:                   Mounted              0  COMMON        84555222  > >> 40   5 F > >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:) > >>3 > >> $42$DKA1200:  (HAFNER)  Online               1 F > >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:) > >> > >> so how does this look( > >> $ INIT/SHADOW=($42$DKA1200:) common > > F > > The manual says there is no advantage to INIT/SHADOW when adding a, > > drive to an already existing shadow set. > >  > > I quote fromG > > http://h71000.www7.hp.com/doc/732FINAL/aa-pvxmj-te/aa-pvxmj-te.HTML  > > A > > Note that the INITIALIZE/SHADOW command should not be used to K > > initialize a disk to be added to an existing shadow set, since there is  > > no benefit to be gained. > > 7 > >> $ mount/confirm DSA0:/shadow=($42$DKA1200:) common  > > J > > Just use the command above and you'll be fine. For startup I think youH > > want to specify both disks without /INCLUDE and without /NOCOPY, but > > with /NOASSIST.  > > 	 > > [...]  > >  > > AEF  > >  >  >  >  > --G > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 13 Dec 2006 12:02:35 -0800 * From: "Tom Linden" <tom@kednos-remove.com>" Subject: Re: Bad Shadow set member) Message-ID: <op.tkikmlcvtte90l@hyrrokkin>   I On Wed, 13 Dec 2006 12:08:42 -0800, Phillip Helbig---remove CLOTHES to  =   . reply <helbig@astro.multiCLOTHESvax.de> wrote:  8 > In article <op.tkc79xsitte90l@hyrrokkin>, "Tom Linden"! > <tom@kednos-remove.com> writes:  > I >> What I would like is to tell VMS I have a two member set, and mount t=  hem I >> both, but if one is bad, mount the good one, and give me diagnostics.=    > 0 > $ MOUNT DSAxxx:/SHADOW=3D(DISK1:,DISK2:) label >  > Don't use /INCLUDE.  >  so change in startup
 $ MOUNT  =  I DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=3D($42$DKA1200:,$42$DKA1300=  :)  =    COMMON toI $ MOUNT DSA0:/CLUSTER/NOASSIST/NOCOPY/SHADOW=3D($42$DKA1200:,$42$DKA1300=  :)  =    COMMON ?  -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 13 Dec 2006 12:15:17 -0800 * From: "Tom Linden" <tom@kednos-remove.com>" Subject: Re: Bad Shadow set member) Message-ID: <op.tkik7rhntte90l@hyrrokkin>   G On Wed, 13 Dec 2006 12:12:26 -0800, AEF <spamsink2001@yahoo.com> wrote:    >  > Tom Linden wrote: I >> On Wed, 13 Dec 2006 11:12:28 -0800, AEF <spamsink2001@yahoo.com> wrot=  e: >> >> > Tom Linden wrote:I >> >> On Wed, 13 Dec 2006 05:14:43 -0800, AEF <spamsink2001@yahoo.com>  =   	 >> wrote:  >> >>  >> >> >  >> >> > JF Mezei wrote:  >> >> >> Tom Linden wrote:G >> >> >> > Thanks.  BTW, I am having a new drive overnighted to me.   =    >> Anything  >> >> inF >> >> >> > particular I need to pay attention to when adding it?  I  =   >> presume I
 >> >> >> need  >> >> >> > to INIT first?  >> >> >> >> >> >>I >> >> >> If not inited, it reduces the chances that the shadowing softwa=  re >> >> might . >> >> >> decide to use that drive as a source. >> >> >>D >> >> >> Also, when you first include the physical drive into the  =  
 >> shadowset,  >> >> >> eittherI >> >> >> mount it into an existing shadowset, or ensure it is not the fi=  rst  >> >> >> device ; >> >> >> listed in the /SHADOW=3D(drive1,drive2,drive3,etc)  >> >> > I >> >> > If he just adds the disk with the system running and uses /CONFI=  RM,  >> >> > that should be enough. >> >> > ) >> >> But I still need to INIT the drive.  >> >I >> > Why? Why do you need to init the drive? It's going to be the target=   of I >> > a full copy operation so whatever is there will be clobbered, INITe=  d  =   >> or 	 >> > not.  >>I >> Yes I saw that in the documentation, but what if this drive came off =  a  >> non-VMS system? > I > Hmmm. I think that might confuse /CONFIRM because it would be trying t=  o I > read the label, but I think it should still work. A quick INIT wouldn'=  t G > hurt, but I'd skip the ERASE because it will be the targete of a full  > copy operation anyway, no? >  >> >> >F >> >> DSA0:                   Mounted              0  COMMON         =   >> 84555222  >> >> 40   5G >> >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)  >> >> 4 >> >> $42$DKA1200:  (HAFNER)  Online               1G >> >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)  >> >>  >> >> so how does this look + >> >> $ INIT/SHADOW=3D($42$DKA1200:) common  >> >G >> > The manual says there is no advantage to INIT/SHADOW when adding a - >> > drive to an already existing shadow set.  >> > >> > I quote from I >> > http://h71000.www7.hp.com/doc/732FINAL/aa-pvxmj-te/aa-pvxmj-te.HTML=    >> >B >> > Note that the INITIALIZE/SHADOW command should not be used toI >> > initialize a disk to be added to an existing shadow set, since ther=  e  =   >> is  >> > no benefit to be gained.  >> >: >> >> $ mount/confirm DSA0:/shadow=3D($42$DKA1200:) common >> >I >> > Just use the command above and you'll be fine. For startup I think =  you I >> > want to specify both disks without /INCLUDE and without /NOCOPY, bu=  t  >> > with /NOASSIST.  8 ODIN> mount/confirm DSA0:/shadow=3D($42$DKA1200:) commonF %MOUNT-F-INCOMPAT, qualifiers incompatible with already mounted volume  I The surviving member was mounted manually as (just copied out of startup=  ) I MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=3D($42$DKA1300:) COMM=  ON  I So it looks like I need first to dismount it, then mount it again, why n=  ot do both?  I MOUNT DSA0:/CLUSTER/NOASSIST/SHADOW=3D($42$DKA1300:,$42$DKA1200:) COMMON=   6 mindful of JF comment about list the good member first     >> >
 >> > [...] >> > >> > AEF >> > >> >> >> >> -- I >> 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: 13 Dec 2006 12:47:23 -0800$ From: "AEF" <spamsink2001@yahoo.com>" Subject: Re: Bad Shadow set memberA Message-ID: <1166042843.541592.77160@79g2000cws.googlegroups.com>    Tom Linden wrote: I > On Wed, 13 Dec 2006 12:12:26 -0800, AEF <spamsink2001@yahoo.com> wrote:  >  > >  > > Tom Linden wrote: L > >> On Wed, 13 Dec 2006 11:12:28 -0800, AEF <spamsink2001@yahoo.com> wrote: > >> > >> > Tom Linden wrote:H > >> >> On Wed, 13 Dec 2006 05:14:43 -0800, AEF <spamsink2001@yahoo.com> > >> wrote:  > >> >> 	 > >> >> >  > >> >> > JF Mezei wrote:  > >> >> >> Tom Linden wrote:E > >> >> >> > Thanks.  BTW, I am having a new drive overnighted to me. 
 > >> Anything 
 > >> >> inE > >> >> >> > particular I need to pay attention to when adding it?  I  > >> presume I > >> >> >> need  > >> >> >> > to INIT first? 
 > >> >> >>
 > >> >> >>L > >> >> >> If not inited, it reduces the chances that the shadowing software
 > >> >> might 0 > >> >> >> decide to use that drive as a source.
 > >> >> >>C > >> >> >> Also, when you first include the physical drive into the  > >> shadowset,  > >> >> >> eittherM > >> >> >> mount it into an existing shadowset, or ensure it is not the first  > >> >> >> device ; > >> >> >> listed in the /SHADOW=(drive1,drive2,drive3,etc) 	 > >> >> > M > >> >> > If he just adds the disk with the system running and uses /CONFIRM,   > >> >> > that should be enough.	 > >> >> > + > >> >> But I still need to INIT the drive.  > >> >M > >> > Why? Why do you need to init the drive? It's going to be the target of K > >> > a full copy operation so whatever is there will be clobbered, INITed  > >> or  > >> > not.  > >>K > >> Yes I saw that in the documentation, but what if this drive came off a  > >> non-VMS system? > > K > > Hmmm. I think that might confuse /CONFIRM because it would be trying to K > > read the label, but I think it should still work. A quick INIT wouldn't I > > hurt, but I'd skip the ERASE because it will be the targete of a full  > > copy operation anyway, no? > >  > >> > >> >> > >> >> DSA0:                   Mounted              0  COMMON
 > >> 84555222  > >> >> 40   5I > >> >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)  > >> >> 6 > >> >> $42$DKA1200:  (HAFNER)  Online               1I > >> >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)  > >> >>  > >> >> so how does this look + > >> >> $ INIT/SHADOW=($42$DKA1200:) common  > >> >I > >> > The manual says there is no advantage to INIT/SHADOW when adding a / > >> > drive to an already existing shadow set.  > >> > > >> > I quote from J > >> > http://h71000.www7.hp.com/doc/732FINAL/aa-pvxmj-te/aa-pvxmj-te.HTML > >> >D > >> > Note that the INITIALIZE/SHADOW command should not be used toK > >> > initialize a disk to be added to an existing shadow set, since there  > >> is  > >> > no benefit to be gained.  > >> >: > >> >> $ mount/confirm DSA0:/shadow=($42$DKA1200:) common > >> >M > >> > Just use the command above and you'll be fine. For startup I think you K > >> > want to specify both disks without /INCLUDE and without /NOCOPY, but  > >> > with /NOASSIST. > 8 > ODIN> mount/confirm DSA0:/shadow=($42$DKA1200:) commonH > %MOUNT-F-INCOMPAT, qualifiers incompatible with already mounted volume  E Maybe it just needed /CLUSTER and/or /SYSTEM; i.e., this would be the = command you'd use to mount a volume privately, so you got the  incompatible error.   K > The surviving member was mounted manually as (just copied out of startup) J > MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=($42$DKA1300:) COMMON   > L > So it looks like I need first to dismount it, then mount it again, why not
 > do both?  E I don't think you need to dismount anything unless you've mounted the % new drive separately for some reason.    > H > MOUNT DSA0:/CLUSTER/NOASSIST/SHADOW=($42$DKA1300:,$42$DKA1200:) COMMON8 > mindful of JF comment about list the good member first  D Try this with /CONFIRM tacked on. It should work with or without the& already mounted member in the command:  E  $ MOUNT DSA0:/CLUSTER/NOASSIST/SHADOW=($42$DKA1200:) COMMON /CONFIRM    [...]    AEF    ------------------------------  % Date: Wed, 13 Dec 2006 13:05:18 -0800 , From: Ken Fairfield <my.full.name@intel.com>" Subject: Re: Bad Shadow set member0 Message-ID: <4ub88eF172go8U1@mid.individual.net>  ( On 12/12/2006 5:44 PM, Tom Linden wrote:4 > On Tue, 12 Dec 2006 17:11:04 -0800, Ken Fairfield ! > <my.full.name@intel.com> wrote:  > + >> On 12/11/2006 7:58 PM, Tom Linden wrote: 5 >>> On Mon, 11 Dec 2006 15:07:26 -0800, Ken Fairfield ( >> [big snip on mounting shadow sets...]( >>>  Any chance you could post the code? >>E >> I'd be happy to, but that was a previous employer...  I'll contact E >> a colleague there and see if he can send a copy along for posting,  >> but no promises.  > G > Thanks.  BTW, I am having a new drive overnighted to me.  Anything in I > particular I need to pay attention to when adding it?  I presume I need  > to INIT first?  B I drive that had never been mounted on VMS needs to be initialized? even when it's the target of a shadow copy.  With recent enough @ versions of VMS (V7.3-1+ ?), you can add /Policy=Verify_Label toB the mount, and do something like this (the label "SCRATCH_DISK" is= documented and required unless you initialize with the actual  shadow set volume label):    $ initialize <dev> scratch_disk # $ mount/system/noassist/poli=veri - 8         dsaxxx /shadow=(first_mem, <dev>) shad_set_label  G I use /Policy=Verify in ALL my disk mount procedures.  When replacing a E failed disk, I initialize the new disk as above as SCRATCH_DISK, then G use a command like the example.  (More precisely, when replacing a bad  @ disk, I've either modified the startup procedures to specify theC replacement disk's device name, or I've done a physical replacement H and the new disk has the same device name as the old one.  Then I invokeH the startup procedure that mounts this shadow set...which specifies both# members _and_ uses /Policy=Verify.)   E I actually don't know whether there is any requirement to specify one G of the current shadow set members or not (probably not).  But I haven't < tried without it and feel just a little better putting it in (superstition you say!). :-)        Regards, Ken  --  6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfield ! D1C Automation VMS System Support " who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------    Date: 13 Dec 2006 13:19:08 -0800$ From: "AEF" <spamsink2001@yahoo.com>" Subject: Re: Bad Shadow set memberB Message-ID: <1166044748.271800.180890@79g2000cws.googlegroups.com>   Tom Linden wrote: I > On Wed, 13 Dec 2006 12:47:23 -0800, AEF <spamsink2001@yahoo.com> wrote:  >  > >  > > Tom Linden wrote: L > >> On Wed, 13 Dec 2006 12:12:26 -0800, AEF <spamsink2001@yahoo.com> wrote: > >> > >> > > >> > Tom Linden wrote:H > >> >> On Wed, 13 Dec 2006 11:12:28 -0800, AEF <spamsink2001@yahoo.com> > >> wrote:  > >> >>  > >> >> > Tom Linden wrote: K > >> >> >> On Wed, 13 Dec 2006 05:14:43 -0800, AEF <spamsink2001@yahoo.com>  > >> >> wrote:
 > >> >> >> > >> >> >> > > >> >> >> > JF Mezei wrote: > >> >> >> >> Tom Linden wrote: H > >> >> >> >> > Thanks.  BTW, I am having a new drive overnighted to me. > >> >> Anything
 > >> >> >> in H > >> >> >> >> > particular I need to pay attention to when adding it?  I > >> >> presume I  > >> >> >> >> need > >> >> >> >> > to INIT first?
 > >> >> >> >> 
 > >> >> >> >> F > >> >> >> >> If not inited, it reduces the chances that the shadowing
 > >> software  > >> >> >> might3 > >> >> >> >> decide to use that drive as a source. 
 > >> >> >> >> F > >> >> >> >> Also, when you first include the physical drive into the > >> >> shadowset, > >> >> >> >> eitther J > >> >> >> >> mount it into an existing shadowset, or ensure it is not the
 > >> first > >> >> >> >> device> > >> >> >> >> listed in the /SHADOW=(drive1,drive2,drive3,etc) > >> >> >> >F > >> >> >> > If he just adds the disk with the system running and uses > >> /CONFIRM,# > >> >> >> > that should be enough.  > >> >> >> >. > >> >> >> But I still need to INIT the drive.	 > >> >> > F > >> >> > Why? Why do you need to init the drive? It's going to be the > >> target ofG > >> >> > a full copy operation so whatever is there will be clobbered,  > >> INITed 
 > >> >> or > >> >> > not. > >> >> L > >> >> Yes I saw that in the documentation, but what if this drive came off > >> a > >> >> non-VMS system?  > >> >K > >> > Hmmm. I think that might confuse /CONFIRM because it would be trying  > >> to E > >> > read the label, but I think it should still work. A quick INIT 
 > >> wouldn't L > >> > hurt, but I'd skip the ERASE because it will be the targete of a full! > >> > copy operation anyway, no?  > >> > > >> >> 	 > >> >> > A > >> >> >> DSA0:                   Mounted              0  COMMON  > >> >> 84555222 > >> >> >> 40   5 L > >> >> >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)
 > >> >> >>9 > >> >> >> $42$DKA1200:  (HAFNER)  Online               1 L > >> >> >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)
 > >> >> >>  > >> >> >> so how does this look. > >> >> >> $ INIT/SHADOW=($42$DKA1200:) common	 > >> >> > L > >> >> > The manual says there is no advantage to INIT/SHADOW when adding a2 > >> >> > drive to an already existing shadow set.	 > >> >> >  > >> >> > I quote fromM > >> >> > http://h71000.www7.hp.com/doc/732FINAL/aa-pvxmj-te/aa-pvxmj-te.HTML 	 > >> >> > G > >> >> > Note that the INITIALIZE/SHADOW command should not be used to H > >> >> > initialize a disk to be added to an existing shadow set, since
 > >> there
 > >> >> is" > >> >> > no benefit to be gained.	 > >> >> > = > >> >> >> $ mount/confirm DSA0:/shadow=($42$DKA1200:) common 	 > >> >> > L > >> >> > Just use the command above and you'll be fine. For startup I think > >> youJ > >> >> > want to specify both disks without /INCLUDE and without /NOCOPY, > >> but > >> >> > with /NOASSIST.  > >>; > >> ODIN> mount/confirm DSA0:/shadow=($42$DKA1200:) common K > >> %MOUNT-F-INCOMPAT, qualifiers incompatible with already mounted volume  > > I > > Maybe it just needed /CLUSTER and/or /SYSTEM; i.e., this would be the A > > command you'd use to mount a volume privately, so you got the  > > incompatible error.  > > E > >> The surviving member was mounted manually as (just copied out of 
 > >> startup) M > >> MOUNT DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=($42$DKA1300:) COMMON  > >  > >>K > >> So it looks like I need first to dismount it, then mount it again, why  > >> not
 > >> do both?  > > I > > I don't think you need to dismount anything unless you've mounted the ) > > new drive separately for some reason.  > >  > >>K > >> MOUNT DSA0:/CLUSTER/NOASSIST/SHADOW=($42$DKA1300:,$42$DKA1200:) COMMON ; > >> mindful of JF comment about list the good member first  > > H > > Try this with /CONFIRM tacked on. It should work with or without the* > > already mounted member in the command: > > I > >  $ MOUNT DSA0:/CLUSTER/NOASSIST/SHADOW=($42$DKA1200:) COMMON /CONFIRM  > J > ODIN> MOUNT DSA0:/CLUSTER/NOASSIST/SHADOW=($42$DKA1200:) COMMON /CONFIRM, > %MOUNT-I-MOUNTED, COMMON mounted on _DSA0:F > %MOUNT-I-SHDWMEMFAIL, _$42$DKA1200: (ODIN) failed as a member of the > shadow setK > -MOUNT-F-MBRTOOSMALL, must be the same size or larger than logical volume  > sizeE > %MOUNT-I-ISAMBR, _$42$DKA1300: (ODIN) is a member of the shadow set  > @ > The drives are identical, so maybe I do need to INIT afterall?  F Could be, or it could be something subtle involving controllers (whichF is beyond my knowledge, but I brought it up because I remember readingD some other posts about such matters). So I don't know. AI quick INITF wouldn't hurt -- I just wouldn't bother with /ERASE as I don't see how it can help matters.   >  > > 	 > > [...]  > >  > > AEF  > >  >  >  >  > --G > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 13 Dec 2006 14:21:06 -0800 * From: "Tom Linden" <tom@kednos-remove.com>" Subject: Re: Bad Shadow set member) Message-ID: <op.tkiq1gzgtte90l@hyrrokkin>   I On Wed, 13 Dec 2006 13:05:18 -0800, Ken Fairfield <my.full.name@intel.co=  m>  =    wrote:  * > On 12/12/2006 5:44 PM, Tom Linden wrote:7 >> On Tue, 12 Dec 2006 17:11:04 -0800, Ken Fairfield  =   " >> <my.full.name@intel.com> wrote: >>, >>> On 12/11/2006 7:58 PM, Tom Linden wrote:6 >>>> On Mon, 11 Dec 2006 15:07:26 -0800, Ken Fairfield) >>> [big snip on mounting shadow sets...] ) >>>>  Any chance you could post the code?  >>> F >>> I'd be happy to, but that was a previous employer...  I'll contactF >>> a colleague there and see if he can send a copy along for posting, >>> but no promises.I >>  Thanks.  BTW, I am having a new drive overnighted to me.  Anything i=  n I >> particular I need to pay attention to when adding it?  I presume I ne=  ed >> to INIT first?  > D > I drive that had never been mounted on VMS needs to be initializedA > even when it's the target of a shadow copy.  With recent enough D > versions of VMS (V7.3-1+ ?), you can add /Policy=3DVerify_Label toD > the mount, and do something like this (the label "SCRATCH_DISK" is? > documented and required unless you initialize with the actual  > shadow set volume label):  > ! > $ initialize <dev> scratch_disk ' > $ mount/system/noassist/poli=3Dveri - < >         dsaxxx /shadow=3D(first_mem, <dev>) shad_set_label > I > I use /Policy=3DVerify in ALL my disk mount procedures.  When replacin=  g a G > failed disk, I initialize the new disk as above as SCRATCH_DISK, then I > use a command like the example.  (More precisely, when replacing a bad=    =   B > disk, I've either modified the startup procedures to specify theE > replacement disk's device name, or I've done a physical replacement I > and the new disk has the same device name as the old one.  Then I invo=  keI > the startup procedure that mounts this shadow set...which specifies bo=  th' > members _and_ uses /Policy=3DVerify.)   ! I followed those instructions and $ ODIN> init $42$DKA1200: scratch_disk: ODIN> mount/cluster/system/noassist/policy=3Dveri dsa0:  =  , /shadow=3D($42$DKA1300:,$42$DKA1200:) common* %MOUNT-I-MOUNTED, COMMON mounted on _DSA0:C %MOUNT-I-ISAMBR, _$42$DKA1300: (ODIN) is a member of the shadow set I %MOUNT-I-SHDWMEMCOPY, _$42$DKA1200: (ODIN) added to the shadow set with =  a  =   copy operation  H $42$DKA1200:    (ODIN)  ShadowCopying        1  (copy trgt DSA0:   2%  =   copied) A $42$DKA1300:    (ODIN)  ShadowSetMember      1  (member of DSA0:)   G It is indeed working, thanks.  Now you say I also need to change the  =    startup?E This is what is in my startup file  (Note the member list order is  =    different than above)   
 $ MOUNT  =  I DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=3D($42$DKA1200:,$42$DKA1300=  :)  =    COMMON   so I should change this to read   I $  MOUNT DSA0:/CLUSTER/NOASSIST/SHADOW=3D($42$DKA1200:,$42$DKA1300:) COM=  MON   + do I need the /POLICY=3DVERI there as well?    > G > I actually don't know whether there is any requirement to specify one I > of the current shadow set members or not (probably not).  But I haven'=  t > > tried without it and feel just a little better putting it in > (superstition you say!). :-) >  >      Regards, Ken        -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 13 Dec 2006 16:31:04 -0800 , From: Ken Fairfield <my.full.name@intel.com>" Subject: Re: Bad Shadow set member0 Message-ID: <4ubka9F17mj7eU1@mid.individual.net>  ( On 12/13/2006 2:21 PM, Tom Linden wrote:4 > On Wed, 13 Dec 2006 13:05:18 -0800, Ken Fairfield ! > <my.full.name@intel.com> wrote:  >  [snip]# > I followed those instructions and & > ODIN> init $42$DKA1200: scratch_disk8 > ODIN> mount/cluster/system/noassist/policy=veri dsa0: , > /shadow=($42$DKA1300:,$42$DKA1200:) common, > %MOUNT-I-MOUNTED, COMMON mounted on _DSA0:E > %MOUNT-I-ISAMBR, _$42$DKA1300: (ODIN) is a member of the shadow set J > %MOUNT-I-SHDWMEMCOPY, _$42$DKA1200: (ODIN) added to the shadow set with  > a copy operation > H > $42$DKA1200:    (ODIN)  ShadowCopying        1  (copy trgt DSA0:   2% 	 > copied) C > $42$DKA1300:    (ODIN)  ShadowSetMember      1  (member of DSA0:)  > G > It is indeed working, thanks.  Now you say I also need to change the  
 > startup?  @ Well, I was just giving an example, plus noting that we *do* use8 that here...extra blade guards cn be a good thing... ;-}  E > This is what is in my startup file  (Note the member list order is   > different than above)  > 
 > $ MOUNT K > DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=($42$DKA1200:,$42$DKA1300:)   > COMMON > ! > so I should change this to read  > K > $  MOUNT DSA0:/CLUSTER/NOASSIST/SHADOW=($42$DKA1200:,$42$DKA1300:) COMMON  > + > do I need the /POLICY=VERI there as well?   C Pending my getting a copy of the old SLAC shadow mounting procedure @ to post, the one that does the /INCLUDE/NOCOPY, yes to your last	 question:   -      $ Mount/Cluster/Noassist/Policy=Verify - :           DSA0: /Shadow=($42$DKA1200:,$42$DKA1300:) COMMON   would be just fine.   C Getting back to the motivation for /NOCOPY, there can be situations @ where you've dismounted a shadow member, e.g., to take a backup.E Then you suffer a power outage (or some other reason that the cluster C goes down).  Now during system startup, you go to mount DSA0.  When E the mount happens, which of the two members becomes the shadow master F and which the copy target?  In this case, the shadow software may lookD at the shadow generation number and make the correct choice, I don'tH know.  But there are situations in which the out-of-date member (becauseB it had been dismounted for some period of time) becomes the shadow* master and overwrites the "good" member...  ? If one member has simply failed, you shouldn't have any problem  with the mount.         Regards, Ken  --  6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfield ! D1C Automation VMS System Support " who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------  % Date: Wed, 13 Dec 2006 16:28:33 -0800 * From: "Tom Linden" <tom@kednos-remove.com>" Subject: Re: Bad Shadow set member) Message-ID: <op.tkiwxvdbtte90l@hyrrokkin>   I On Wed, 13 Dec 2006 16:31:04 -0800, Ken Fairfield <my.full.name@intel.co=  m>  =    wrote:  * > On 12/13/2006 2:21 PM, Tom Linden wrote:7 >> On Wed, 13 Dec 2006 13:05:18 -0800, Ken Fairfield  =   " >> <my.full.name@intel.com> wrote: >> > [snip]$ >> I followed those instructions and' >> ODIN> init $42$DKA1200: scratch_disk = >> ODIN> mount/cluster/system/noassist/policy=3Dveri dsa0:  =   / >> /shadow=3D($42$DKA1300:,$42$DKA1200:) common - >> %MOUNT-I-MOUNTED, COMMON mounted on _DSA0: F >> %MOUNT-I-ISAMBR, _$42$DKA1300: (ODIN) is a member of the shadow setI >> %MOUNT-I-SHDWMEMCOPY, _$42$DKA1200: (ODIN) added to the shadow set wi=  th  =    >> a copy operation I >>  $42$DKA1200:    (ODIN)  ShadowCopying        1  (copy trgt DSA0:   2=  %  =  
 >> copied)D >> $42$DKA1300:    (ODIN)  ShadowSetMember      1  (member of DSA0:)I >>  It is indeed working, thanks.  Now you say I also need to change the=    =    >> startup?  > B > Well, I was just giving an example, plus noting that we *do* use: > that here...extra blade guards cn be a good thing... ;-} > H >> This is what is in my startup file  (Note the member list order is  =   >> different than above) >>  $ MOUNT  =  I >> DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=3D($42$DKA1200:,$42$DKA1=  300:)  =  	 >> COMMON # >>  so I should change this to read I >>  $  MOUNT DSA0:/CLUSTER/NOASSIST/SHADOW=3D($42$DKA1200:,$42$DKA1300:)=    =   	 >> COMMON / >>  do I need the /POLICY=3DVERI there as well?  > E > Pending my getting a copy of the old SLAC shadow mounting procedure B > to post, the one that does the /INCLUDE/NOCOPY, yes to your last > question:  > 1 >      $ Mount/Cluster/Noassist/Policy=3DVerify - > >           DSA0: /Shadow=3D($42$DKA1200:,$42$DKA1300:) COMMON >  > would be just fine.   I And if the disk that was INITed with label SCRATCH_DISK failed for some =   =   reasonC would the surviving member still mount after, say, a power failure?    > E > Getting back to the motivation for /NOCOPY, there can be situations B > where you've dismounted a shadow member, e.g., to take a backup.G > Then you suffer a power outage (or some other reason that the cluster E > goes down).  Now during system startup, you go to mount DSA0.  When G > the mount happens, which of the two members becomes the shadow master I > and which the copy target?  In this case, the shadow software may look=   F > at the shadow generation number and make the correct choice, I don'tI > know.  But there are situations in which the out-of-date member (becau=  seD > it had been dismounted for some period of time) becomes the shadow, > master and overwrites the "good" member... > A > If one member has simply failed, you shouldn't have any problem  > with the mount.  >  >      Regards, Ken        -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Thu, 14 Dec 2006 00:21:45 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Cluster: Deleting CSB for System <node>, Message-ID: <4580DF53.FD98DD9F@teksavvy.com>  D After a power failure,  (yes, murphy's law, yesterday I was pointingG that with screwed up disk, I wanted to stay up because I wasn't sure it D could be remounted.... and low and behold, we got a power failure !)  D Anyhow, during the reboot of the Alpha, I saw the following message:    %CNXMGR  Discovered system WHEEL& %CNXMGR  Deleting CSB for system WHEEL    %CNXMGR  Discovered system WHEEL& %CNXMGR  Deleting CSB for system WHEEL    %CNXMGR  Discovered system WHEEL/ %CNXMGR  Established connection to system WHEEL     F The rest seemed to proceed normally.  Is there anything I should worry about ?   G I did lower the EXPECTED_VOTES in SYSBOOT for all my systems to reflect E retirement of a vaxstation (which will have to temporarily be brought ! back to help restore lost files).     E What was the deleting CSB message really meant ? Is there a reason it  was generated twice ?   " These were seen on an Alpha at 8.3   ------------------------------    Date: 13 Dec 2006 14:34:24 -0800 From: jtower@gmail.com% Subject: consulting job in raleigh nc A Message-ID: <1166049263.899250.3340@j72g2000cwa.googlegroups.com>   F i need someone with solid openvms experience for a semi-quick contractC job (openvms on compaq alpha hardware).  if you'd like to make some D quick holiday cash ping me as jtower@gmail.com and i'll give you theG details.  must be familiar with block devices on openvms and alpha scsi 	 hardware.    ------------------------------  % Date: Wed, 13 Dec 2006 10:57:18 -0800 * From: "Tom Linden" <tom@kednos-remove.com>" Subject: Re: DEC 3000/400 problems) Message-ID: <op.tkihlscvtte90l@hyrrokkin>   H On Wed, 13 Dec 2006 08:55:43 -0800, <alexandre.laguejacques@gmail.com>   wrote:  G > I'm exposing myself to all sorts of ridicule by posing this question, G > but what does the air sensor switch look like?  Unfortunately I don't B > have any documents that describe this component within the power	 > supply!   % I think it is inside the fan housing.  >  > Bob Koehler a crit :  > G >> In article <1165674973.928960.238170@16g2000cwy.googlegroups.com>,   + >> alexandre.laguejacques@gmail.com writes:  >> >G >> > I can obtain a replacement power supply (part H7816-AA) for around K >> > $150.  While I do find this expensive for a hobbyist system, I could    >> at J >> > least consider it if I knew that the motherboard hadn't been fried by% >> > the malfunctioning power supply.  >>< >>    Try cleaning the air sensor switch near the fan first. >        --  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 13 Dec 2006 15:51:07 -0500  From: norm.raphael@metso.com@ Subject: Password expiration and non-interactive access questionQ Message-ID: <OF49A64769.88FEB730-ON85257243.00723863-85257243.00728B0F@metso.com>   F I see an account with NETWORK access only allowed and a recent network login,I but a finite passwordlifetime and a password change date in 1997, yet the  passwordI on the FTP transfers continues to work.  Is this expected behavior?  What  am I not getting?   ------------------------------    Date: 13 Dec 2006 15:14:21 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) D Subject: Re: Password expiration and non-interactive access question3 Message-ID: <4xXLdX97Og3z@eisner.encompasserve.org>   p In article <OF49A64769.88FEB730-ON85257243.00723863-85257243.00728B0F@metso.com>, norm.raphael@metso.com writes: > H > I see an account with NETWORK access only allowed and a recent network > login,K > but a finite passwordlifetime and a password change date in 1997, yet the 
 > passwordK > on the FTP transfers continues to work.  Is this expected behavior?  What  > am I > not getting?  G There is no way for a NETWORK login to change the password, so there is + no occasion for LOGINOUT to force a change.   B For most uses of a password (as distinguished from proxy login) inD such situations the password has been stored in a computer device so; forcing password changes does not increase security anyway.  --  N ==============================================================================0 DoD Instruction 8500.2 field test sites wanted -- 	http://www.LJK.com/LJK/8500_2_fieldtest.html N ==============================================================================   ------------------------------  % Date: Wed, 13 Dec 2006 16:39:15 -0500  From: norm.raphael@metso.comD Subject: Re: Password expiration and non-interactive access questionQ Message-ID: <OFF33EC97B.2E8142E7-ON85257243.0076DBA7-85257243.0076F2E4@metso.com>   H Kilgallen@SpamCop.net (Larry Kilgallen) wrote on 12/13/2006 04:14:21 PM:  ? > In article <OF49A64769.88FEB730-ON85257243.00723863-85257243. 5 > 00728B0F@metso.com>, norm.raphael@metso.com writes:  > > J > > I see an account with NETWORK access only allowed and a recent network
 > > login,I > > but a finite passwordlifetime and a password change date in 1997, yet  the  > > passwordG > > on the FTP transfers continues to work.  Is this expected behavior?  What > > am I > > not getting? > I > There is no way for a NETWORK login to change the password, so there is - > no occasion for LOGINOUT to force a change.  > D > For most uses of a password (as distinguished from proxy login) inF > such situations the password has been stored in a computer device so= > forcing password changes does not increase security anyway.   F Thanks, Larry. That makes sense and is consistent.  Now I just need to enlighten the SOX auditors....   > -- > N ==============================================================================  2 > DoD Instruction 8500.2 field test sites wanted -1 >    http://www.LJK.com/LJK/8500_2_fieldtest.html  > N ==============================================================================   ------------------------------    Date: 13 Dec 2006 16:34:55 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) D Subject: Re: Password expiration and non-interactive access question3 Message-ID: <FJOZtNuNod3J@eisner.encompasserve.org>   p In article <OFF33EC97B.2E8142E7-ON85257243.0076DBA7-85257243.0076F2E4@metso.com>, norm.raphael@metso.com writes: >  > J > Kilgallen@SpamCop.net (Larry Kilgallen) wrote on 12/13/2006 04:14:21 PM: > @ >> In article <OF49A64769.88FEB730-ON85257243.00723863-85257243.6 >> 00728B0F@metso.com>, norm.raphael@metso.com writes: >> >K >> > I see an account with NETWORK access only allowed and a recent network  >> > login, J >> > but a finite passwordlifetime and a password change date in 1997, yet > the 
 >> > password H >> > on the FTP transfers continues to work.  Is this expected behavior? > What	 >> > am I  >> > not getting?  >>J >> There is no way for a NETWORK login to change the password, so there is. >> no occasion for LOGINOUT to force a change. >>E >> For most uses of a password (as distinguished from proxy login) in G >> such situations the password has been stored in a computer device so > >> forcing password changes does not increase security anyway. > H > Thanks, Larry. That makes sense and is consistent.  Now I just need to  > enlighten the SOX auditors....  C Locking the password might reduce the chance that the SOX auditor's C tools would flag this.  It might flag the locked password, but that A is typically something for which a "permitted exceptions" list is  maintained by the site.   P > ============================================================================== > 3 >> DoD Instruction 8500.2 field test sites wanted - 2 >>    http://www.LJK.com/LJK/8500_2_fieldtest.html >>P > ============================================================================== >  >    ------------------------------  # Date: Wed, 13 Dec 2006 20:00:37 GMT & From: John Reagan <john.reagan@hp.com>' Subject: Re: PATCH on Alpha and Itanium 2 Message-ID: <FZYfh.3567$5i2.1776@news.cpqcorp.net>   Albrecht Schlosser wrote:   > Hein RMS van den Heuvel wrote: >  >>F >> http://h71000.www7.hp.com/freeware/freeware60/rms_tools/src/zap.mar >>E >> You tell it to reads a buffer of certain size from a  certain vbn. G >> It simply uses the debugger as GUI for that buffer pointed to by R2.  >> So you just use you normal  >> EXAMINE @R2;  >  > 9 > Nice tool, tried it on Alpha, and it works as expected.  > $ > But it doesn't work on Itanic :-(. > D > There's a difference in the calling mechanism - AFAICS R2 doesn't C > contain the data address (BUF). Using R5 instead works for me :-)   I On Itanium, R2 inside of Macro code doesn't actually live in Itanium R2,  E but rather in Itanium R28.  Normally, when debugging Macro code, the  F Macro compiler creates a symbolic name "R2" and tells the debugger it A lives in R28.  In your case with ZAP.MAR, that debug information  = probably wasn't available.  Alpha R3, R4, and R5 live in the  H corresponding Itanium registers.  That is why moving it to R5 seemed to G work for you.  You could have found the buffer address in R28 prior to   your change.  G The whole description of Macro's register mapping is documented in the  - debugger manuals as well as the Macro manual.    >  >  From the source:  > H > DEBUG:  MOVAB   BUF, R5            ; use R5 instead of R2 for Itanic !# >         MOVZWL  RAB+RAB$W_RSZ, R3 # >         MOVL    RAB+RAB$L_BKT, R4  >         PUSHL   #SS$_DEBUG" >         CALLS   #1, g^LIB$SIGNAL >         BRW     MAIN_LOOP  > H > AFAIK, this would work for Alpha, too (yes, it does, I tried it), but : > not for VAX (since R5 is reserved on VAX (SP?)), right ?  5 R5 is not reserved on the VAX, you can use it freely.    > 
 > Albrecht     --   John Reagan 5 HP Pascal/{A|I}MACRO/COBOL for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------  % Date: Thu, 14 Dec 2006 00:52:56 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ' Subject: Testing picture file integrity , Message-ID: <4580E6A1.D8C8A670@teksavvy.com>  H Does anyone know of an automatable way of testing picture file integrity ? (.jpeg, .gof , .tiff etc).  E I have XV installed. is there a magic switch that would just read the H file, verify its structure and then exit with a status code that lets me know if it is OK or not ?    ------------------------------    Date: 13 Dec 2006 22:05:47 -0800, From: "Cluster-Karl" <karl.rohwedder@gmx.de>+ Subject: Re: Testing picture file integrity B Message-ID: <1166076347.260633.94260@l12g2000cwl.googlegroups.com>   JF Mezei schrieb:   J > Does anyone know of an automatable way of testing picture file integrity > ? (.jpeg, .gof , .tiff etc). > G > I have XV installed. is there a magic switch that would just read the J > file, verify its structure and then exit with a status code that lets me > know if it is OK or not ?   D Perhaps the IDENTIFY image of the IMAGEMAGICK package is a wa to go.  
 regards Kalle    ------------------------------    Date: 13 Dec 2006 11:13:49 -0800( From: "Zack Kline" <Z_kline@hotmail.com>2 Subject: textual description of digital keyboards?C Message-ID: <1166037229.811448.260220@j72g2000cwa.googlegroups.com>    Hello,F      I would appreciate, if possible, as accurate a description of the8 Digital Vt series keyboards as someone can come up with.= Keyboard diagrams are next to useless for me1 and unreadable. F I'd also appreciate a description of how these keyboards are generallyE mapped to the PC. (From someone specifically familiar with Kermit 95, 	 ideally.) ; I apologize in advance if I am asking a difficult question.  Yours, Zack.    ------------------------------  # Date: Wed, 13 Dec 2006 19:18:24 GMT   From: CJT <abujlehc@prodigy.net>6 Subject: Re: textual description of digital keyboards?( Message-ID: <45805200.10101@prodigy.net>   Zack Kline wrote:    > Hello,H >      I would appreciate, if possible, as accurate a description of the: > Digital Vt series keyboards as someone can come up with.? > Keyboard diagrams are next to useless for me1 and unreadable. H > I'd also appreciate a description of how these keyboards are generallyG > mapped to the PC. (From someone specifically familiar with Kermit 95,  > ideally.) = > I apologize in advance if I am asking a difficult question.  > Yours, > Zack.  > 7 Shouldn't such a request come with an offer of payment?    --  D The e-mail address in our reply-to line is reversed in an attempt toC minimize spam.  Our true address is of the form che...@prodigy.net.    ------------------------------  + Date: Wed, 13 Dec 2006 19:55:02 +0000 (UTC) . From: Dale Dellutri <ddelQQQlutr@panQQQix.com>6 Subject: Re: textual description of digital keyboards?, Message-ID: <elplqm$7th$1@reader2.panix.com>  F On 13 Dec 2006 11:13:49 -0800, Zack Kline <Z_kline@hotmail.com> wrote: > Hello,H >      I would appreciate, if possible, as accurate a description of the: > Digital Vt series keyboards as someone can come up with.? > Keyboard diagrams are next to useless for me1 and unreadable. H > I'd also appreciate a description of how these keyboards are generallyG > mapped to the PC. (From someone specifically familiar with Kermit 95,  > ideally.) = > I apologize in advance if I am asking a difficult question.  > Yours, > Zack.    Try:   http://vt100.net/ > Lots of manuals and reference guides, which probably have more tech info that you want.   --  7 Dale Dellutri <ddelQQQlutr@panQQQix.com> (lose the Q's)    ------------------------------  % Date: Wed, 13 Dec 2006 18:44:55 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> D Subject: Re: VAX VMS 7.3,  ana/image running out of virtual memory ?, Message-ID: <45809074.F561F782@teksavvy.com>   Jur van der Burg wrote:  >  > Ok, mea culpa. > E > It's a bug in LDdriver, I just reproduced it and it's present for a . > long time (since LD V8.0), on all platforms.  A How dare you left a bug in VMS :-)  Perhaps if VMS engineers were D threathened to be force-fed with Vegemite or Marmite, they would not leave any bugs in VMS :-)   I Seriously, thank you for confirming this. At least I know what caused it.   D Can you confirm that if I have found files corrupted on RVN 1,  then> your bug will affect only disk blocks on that physical disk ?     < > A fix is on the way, I'll update my website later tonight. > ! > http://www.digiater.nl/lddriver   : Out of curiosity, will this make it back into the main VMS> distribution/patch system now that LDdriver is "part" of VMS ?   ------------------------------  % Date: Wed, 13 Dec 2006 22:39:27 -0500 ' From: "Main, Kerry" <Kerry.Main@hp.com> 8 Subject: RE: VMS VERSION - V7.3-2, V8.2, V8.3 differenceT Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401ED0DF4@tayexc19.americas.cpqcorp.net>   > -----Original Message------ > From: VMSguy [mailto:vmsguy@comcast.net]=20 ! > Sent: December 13, 2006 4:06 AM  > To: Info-VAX@Mvb.Saic.Com 6 > Subject: VMS VERSION - V7.3-2, V8.2, V8.3 difference >=20F > Anyone care to comment on the major differences between the three=202 > versions of VMS for Alpha - V7.3-2, V8.2, V8.3 ? >=20A > I am planning an upgrade to V8.3 however management wants to=20  > stay at V7.3-2 >=20	 > Thanks!  >=20   Coles notes version - V8.3G - general enhancements, added new functionality and bug fixes over V8.2  - better performanceH - more features that enable easier integration and porting of UNIX app's
 to OpenVMS - bug fixes H - V7.3-2 is no longer on standard support after this year (priot version4 support starts Jan 1, 2007 - higher support $'s).=20  
 Reference:? http://h20219.www2.hp.com/services/cache/11779-0-0-225-121.html    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Wed, 13 Dec 2006 23:20:02 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 8 Subject: Re: VMS VERSION - V7.3-2, V8.2, V8.3 difference, Message-ID: <4580D0E0.32132A3C@teksavvy.com>  C For workstations, 8.3 (and perhaps 8.2) also brings 3d graphics for H Radeon 7500 cards, whereas with previous versions, separate licences had to be purchased.  B When I started to setup my 8.3 alpha, I noticed a few of the stuffC needed to be downloaded required 8.3, but my mind is busy trying to C rebuild a disk wrecked by VMS so those details are not in immediate 
 memory areas.    ------------------------------   End of INFO-VAX 2006.686 ************************