INFO-VAX Wed, 26 Mar 2008 Volume 2008 : Issue 172 Contents: Re: Bracknell (Berkshire, UK) and VMS Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Re: Disk shadowing with bad blocks Gigabit cards PCI/PCIX - a few left Re: HP Alpha TCPIP active passive Re: Please critique my backup practices Re: Please critique my backup practices Polycenter Scheduler Re: RX3600 and VMS 8.3 zeroing out errors? Re: zeroing out errors? Re: zeroing out errors? Re: zeroing out errors? Re: zeroing out errors? Re: zeroing out errors? ---------------------------------------------------------------------- Date: Wed, 26 Mar 2008 09:40:17 -0700 (PDT) From: etmsreec@yahoo.co.uk Subject: Re: Bracknell (Berkshire, UK) and VMS Message-ID: <10616a6b-dd80-42d8-9ad5-4be98a2121a9@s12g2000prg.googlegroups.com> On 24 Mar, 13:23, "John Wallace" wrote: > "IanMiller" wrote in message > > news:2937b308-faa8-4a08-b7f5-4fb6a8725c39@s19g2000prg.googlegroups.com... > > > On 21 Mar, 18:32, Didier_Toulouse wrote: > > >http://www.jobserve.com/W47B7E1939656F574.job > > > and what makes you think that that job is for HP? > > > DCE, non current hardware > > I don't think "non current hardware"necessarily means it's not HP, unless > policies and practices have changed radically since the days of DEC, when > finding current hardware was the exception rather than the rule in DEC > offices and datacentres in the UK. (Maybe the "61 HP datacentres into 6" > will be changing this, if it ever happens... just imagine the kind of > Exchange setup that implies...). > > How does Didier turn one advert into "plenty", or are there others he hasn't > yet told us about? > > Bracknell used to have VMS customers including BAe Dynamics (may now be > Matra BAe?) and Siemens Healthcare; current status unknown. > > regards > John There may be support people for HP in Bracknell, but the labs got migrated up the M4 to a site near an old airfield IIRC. that's why India support calls get directed through a Swindon number (01793)... Steve ------------------------------ Date: Wed, 26 Mar 2008 04:52:21 -0700 (PDT) From: tadamsmar Subject: Re: Disk shadowing with bad blocks Message-ID: <66cb909d-11bb-415c-8718-7f94be77baea@s19g2000prg.googlegroups.com> On Mar 25, 8:05=A0pm, David J Dachtera wrote: > tadamsmar wrote: > > > I have a disk that has some bad blocks. > > > When I put it into a shadow set with a disk with no error, the disk > > with the bad blocks logs a few errors, but completes OK. > > > When I do a ANAL/DISK/SHAD, the command ends with a parity error. > > > But, as far as I know, the shadow set is basically sound. =A0I used this= > > disk for months, I get no errors on image backup. > > > Now, if I was not disk shadowing, I could just run the bad block > > finding command and then use the disk without any problems. =A0Seems > > ironic. > > > Is there a way to use this disk in a shadow set without getting these > > errors? =A0 Shadow sets seem to keep hitting the bad blocks. > > After everything in the previous thread, it seems there really only two > things left to try: > > 1. INIT/ERASE > 2. Low-level format > 3. A dangerously high precipice > > David J Dachtera > (formerly dba) DJE Systems- Hide quoted text - > > - Show quoted text - I don't think I am communicating very well at this point. My system works fine if I use only good disks that have no bad physical blocks. But I now have one spare disk with some bad physical blocks. It setting in my office not installed. I tried to use it and this happened: 1. It logged errors during the shadow copy to it from a perfectly good disk. But the copy worked. 2. After the copy, ANAL/DISK/SHAD ends with a parity error. Now, I am thinking about keeping this disk as a spare since is sort of works in a shadow set. But I was wondering if there was as way to avoid having these spurious errors reported. Disk shadowing seems to have no way to stop reporting over and over the bad blocks on this disks. ------------------------------ Date: Wed, 26 Mar 2008 04:55:11 -0700 (PDT) From: AEF Subject: Re: Disk shadowing with bad blocks Message-ID: <8ab6c56a-4f9d-416a-bba6-b78e27a0b99c@13g2000hsb.googlegroups.com> On Mar 26, 7:52 am, tadamsmar wrote: > On Mar 25, 8:05 pm, David J Dachtera > wrote: > > > > > tadamsmar wrote: > > > > I have a disk that has some bad blocks. > > > > When I put it into a shadow set with a disk with no error, the disk > > > with the bad blocks logs a few errors, but completes OK. > > > > When I do a ANAL/DISK/SHAD, the command ends with a parity error. > > > > But, as far as I know, the shadow set is basically sound. I used this > > > disk for months, I get no errors on image backup. > > > > Now, if I was not disk shadowing, I could just run the bad block > > > finding command and then use the disk without any problems. Seems > > > ironic. > > > > Is there a way to use this disk in a shadow set without getting these > > > errors? Shadow sets seem to keep hitting the bad blocks. > > > After everything in the previous thread, it seems there really only two > > things left to try: > > > 1. INIT/ERASE > > 2. Low-level format > > 3. A dangerously high precipice > > > David J Dachtera > > (formerly dba) DJE Systems- Hide quoted text - > > > - Show quoted text - > > I don't think I am communicating very well at this point. > > My system works fine if I use only good disks that have no bad > physical blocks. > > But I now have one spare disk with some bad physical blocks. It > setting in my office not installed. I tried to use it and this > happened: > > 1. It logged errors during the shadow copy to it from a perfectly > good disk. But the copy worked. > > 2. After the copy, ANAL/DISK/SHAD ends with a parity error. > > Now, I am thinking about keeping this disk as a spare since is sort of > works in a shadow set. But I was wondering if there was as way to > avoid having these spurious errors reported. Disk shadowing seems to > have no way to stop reporting over and over the bad blocks on this > disks. Get another disk already. This is the second thread about this problem, no? AEF ------------------------------ Date: Wed, 26 Mar 2008 04:59:37 -0700 (PDT) From: tadamsmar Subject: Re: Disk shadowing with bad blocks Message-ID: On Mar 25, 7:39=A0pm, Rob Brown wrote: > On Tue, 25 Mar 2008, tadamsmar wrote: > > I have a disk that has some bad blocks. > > I don't understand why this disk *still* has bad blocks. =A0The bad > blocks should have all been replaced from the spare blocks by now, > should they not? =A0You have done ANALYZE/MEDIA/EXERCISE, haven't you? Yes, it finds some bad blocks and put their addresses in the bad block file, but that file is wiped out when you put a disk in a shadow set. You are mixing the non-shadow and shadow algorithms for addressing bad blocks. ANAL/MEDIS/EXER is a tool handling bad blocks when you are not shadowing. > > And if you are out of spare blocks, so that you have bad blocks > existing, is the disk worth keeping? =A0It must be on its last legs. =A0It= > will certainly continue to grow bad blocks. I have plenty of spares. Not the problem. > > Finally, my out-of-date "how shadowing works" information says that > all the drives of the shadow set must have bad blocks at the same > locations. =A0If this restriction exists for you, then you will either > have to give up on the drive, or add bad blocks to the other drives of > the shadow set. The bad blocks are not causing any real integrity problems, just spurious error reports. > > -- > > Rob Brown =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b r o w n a t g m= c l d o t c o m > G. Michaels Consulting Ltd. =A0 =A0 =A0(780)438-9343 (voice) > Edmonton =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (780)437-3367 (FA= X) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://= gmcl.com/ ------------------------------ Date: Wed, 26 Mar 2008 05:01:40 -0700 (PDT) From: tadamsmar Subject: Re: Disk shadowing with bad blocks Message-ID: On Mar 25, 7:54=A0pm, Pete wrote: > On Tue, 25 Mar 2008 10:06:43 -0700 (PDT), tadamsmar > > > > > > wrote: > >I have a disk that has some bad blocks. > > >When I put it into a shadow set with a disk with no error, the disk > >with the bad blocks logs a few errors, but completes OK. > > >When I do a ANAL/DISK/SHAD, the command ends with a parity error. > > >But, as far as I know, the shadow set is basically sound. =A0I used this > >disk for months, I get no errors on image backup. > > >Now, if I was not disk shadowing, I could just run the bad block > >finding command and then use the disk without any problems. =A0Seems > >ironic. > > >Is there a way to use this disk in a shadow set without getting these > >errors? =A0 Shadow sets seem to keep hitting the bad blocks. > > =A0Have you logged a service call ? I think if the errorlog, VMS > versions/patch level, log from the ana/disk/shadow, and the hardware > details were included you would get a quicker answer. > > Pete- Hide quoted text - > > - Show quoted text - I don't have a service contract, and the problem is not that critical. ------------------------------ Date: Wed, 26 Mar 2008 05:05:57 -0700 (PDT) From: tadamsmar Subject: Re: Disk shadowing with bad blocks Message-ID: On Mar 26, 7:55=A0am, AEF wrote: > On Mar 26, 7:52 am, tadamsmar wrote: > > > > > > > On Mar 25, 8:05 pm, David J Dachtera > > wrote: > > > > tadamsmar wrote: > > > > > I have a disk that has some bad blocks. > > > > > When I put it into a shadow set with a disk with no error, the disk > > > > with the bad blocks logs a few errors, but completes OK. > > > > > When I do a ANAL/DISK/SHAD, the command ends with a parity error. > > > > > But, as far as I know, the shadow set is basically sound. =A0I used = this > > > > disk for months, I get no errors on image backup. > > > > > Now, if I was not disk shadowing, I could just run the bad block > > > > finding command and then use the disk without any problems. =A0Seems= > > > > ironic. > > > > > Is there a way to use this disk in a shadow set without getting thes= e > > > > errors? =A0 Shadow sets seem to keep hitting the bad blocks. > > > > After everything in the previous thread, it seems there really only tw= o > > > things left to try: > > > > 1. INIT/ERASE > > > 2. Low-level format > > > 3. A dangerously high precipice > > > > David J Dachtera > > > (formerly dba) DJE Systems- Hide quoted text - > > > > - Show quoted text - > > > I don't think I am communicating very well at this point. > > > My system works fine if I use only good disks that have no bad > > physical blocks. > > > But I now have one spare disk with some bad physical blocks. It > > setting in my office not installed. =A0I tried to use it and this > > happened: > > > 1. =A0It logged errors during the shadow copy to it from a perfectly > > good disk. =A0But the copy worked. > > > 2. =A0After the copy, ANAL/DISK/SHAD ends with a parity error. > > > Now, I am thinking about keeping this disk as a spare since is sort of > > works in a shadow set. =A0 But I was wondering if there was as way to > > avoid having these spurious errors reported. =A0 Disk shadowing seems to= > > have no way to stop reporting over and over the bad blocks on this > > disks. > > Get another disk already. This is the second thread about this > problem, no? > > AEF- Hide quoted text - > > - Show quoted text - I already have another disk. Just trying to figure out the usefulness of a disk that has a few bad blocks as a shadow set member. Actually, its the third thread. ------------------------------ Date: Wed, 26 Mar 2008 12:15:42 +0000 From: "R.A.Omond" Subject: Re: Disk shadowing with bad blocks Message-ID: tadamsmar wrote: > [...big snip...] Please bite the bullet and do a low-level format of the disk (this will revector any genuine bad blocks, leaving you (hopefully) with a disk that has no bad blocks visible). Assuming disk is DKA400: $ mcr sys$etc:rztools_alpha RZTools> /h RZT [device] [/command[=value] /...] Commands Value required? Function -------- --------------- -------- [...snip...] FO rmat SCSI FORMAT RZTools> DKA400:/Format And with that, hopefully this thread might come to an end. ------------------------------ Date: Wed, 26 Mar 2008 09:11:20 -0400 From: "Richard B. Gilbert" Subject: Re: Disk shadowing with bad blocks Message-ID: <47EA4B78.4050901@comcast.net> tadamsmar wrote: > On Mar 25, 8:05 pm, David J Dachtera > wrote: > >>tadamsmar wrote: >> >> >>>I have a disk that has some bad blocks. >> >>>When I put it into a shadow set with a disk with no error, the disk >>>with the bad blocks logs a few errors, but completes OK. >> >>>When I do a ANAL/DISK/SHAD, the command ends with a parity error. >> >>>But, as far as I know, the shadow set is basically sound. I used this >>>disk for months, I get no errors on image backup. >> >>>Now, if I was not disk shadowing, I could just run the bad block >>>finding command and then use the disk without any problems. Seems >>>ironic. >> >>>Is there a way to use this disk in a shadow set without getting these >>>errors? Shadow sets seem to keep hitting the bad blocks. >> >>After everything in the previous thread, it seems there really only two >>things left to try: >> >>1. INIT/ERASE >>2. Low-level format >>3. A dangerously high precipice >> >>David J Dachtera >>(formerly dba) DJE Systems- Hide quoted text - >> >>- Show quoted text - > > > I don't think I am communicating very well at this point. > > My system works fine if I use only good disks that have no bad > physical blocks. > > But I now have one spare disk with some bad physical blocks. It > setting in my office not installed. I tried to use it and this > happened: > > 1. It logged errors during the shadow copy to it from a perfectly > good disk. But the copy worked. > > 2. After the copy, ANAL/DISK/SHAD ends with a parity error. > > Now, I am thinking about keeping this disk as a spare since is sort of > works in a shadow set. But I was wondering if there was as way to > avoid having these spurious errors reported. Disk shadowing seems to > have no way to stop reporting over and over the bad blocks on this > disks. I would retire that disk drive to a non critical position; e.g. a paperweight! YMMV! ------------------------------ Date: Wed, 26 Mar 2008 07:19:03 -0700 (PDT) From: tadamsmar Subject: Re: Disk shadowing with bad blocks Message-ID: <899cf6da-97df-4aac-b34a-aa2a13e77887@s12g2000prg.googlegroups.com> On Mar 26, 9:11=A0am, "Richard B. Gilbert" wrote: > tadamsmar wrote: > > On Mar 25, 8:05 pm, David J Dachtera > > wrote: > > >>tadamsmar wrote: > > >>>I have a disk that has some bad blocks. > > >>>When I put it into a shadow set with a disk with no error, the disk > >>>with the bad blocks logs a few errors, but completes OK. > > >>>When I do a ANAL/DISK/SHAD, the command ends with a parity error. > > >>>But, as far as I know, the shadow set is basically sound. =A0I used thi= s > >>>disk for months, I get no errors on image backup. > > >>>Now, if I was not disk shadowing, I could just run the bad block > >>>finding command and then use the disk without any problems. =A0Seems > >>>ironic. > > >>>Is there a way to use this disk in a shadow set without getting these > >>>errors? =A0 Shadow sets seem to keep hitting the bad blocks. > > >>After everything in the previous thread, it seems there really only two > >>things left to try: > > >>1. INIT/ERASE > >>2. Low-level format > >>3. A dangerously high precipice > > >>David J Dachtera > >>(formerly dba) DJE Systems- Hide quoted text - > > >>- Show quoted text - > > > I don't think I am communicating very well at this point. > > > My system works fine if I use only good disks that have no bad > > physical blocks. > > > But I now have one spare disk with some bad physical blocks. It > > setting in my office not installed. =A0I tried to use it and this > > happened: > > > 1. =A0It logged errors during the shadow copy to it from a perfectly > > good disk. =A0But the copy worked. > > > 2. =A0After the copy, ANAL/DISK/SHAD ends with a parity error. > > > Now, I am thinking about keeping this disk as a spare since is sort of > > works in a shadow set. =A0 But I was wondering if there was as way to > > avoid having these spurious errors reported. =A0 Disk shadowing seems to= > > have no way to stop reporting over and over the bad blocks on this > > disks. > > I would retire that disk drive to a non critical position; e.g. a > paperweight! > > YMMV!- Hide quoted text - > > - Show quoted text - I am thinking about keeping it as a backup. If I lost a disk, then I could use it as a temporary replacement till I ordered a new disk. It works fine in a shadow set if you understand the "features" of disk shadowing. The main problem is that you have to sort out real from spurious error reports and the spurious parity errors will be propagated to other disks after you allow the problem disk to be the only member of a shadow set. In that case, you have to go to the trouble of wiping out the spurious parity errors. Could be a paperweight in the meantime if I keep it its anti-static bag. ------------------------------ Date: Wed, 26 Mar 2008 15:54:37 GMT From: Rob Brown Subject: Re: Disk shadowing with bad blocks Message-ID: On Wed, 26 Mar 2008, tadamsmar wrote: > On Mar 25, 7:39 pm, Rob Brown wrote: >> >> And if you are out of spare blocks, so that you have bad blocks >> existing, is the disk worth keeping? It must be on its last legs. It >> will certainly continue to grow bad blocks. > > I have plenty of spares. Not the problem. Obviously you do not have spares, since you have bad blocks. If you had spare blocks, as soon as you wrote to a bad block, it would have been replaced with a good spare block with the same LBN. The host would never know about it. And this happens below the level of BADBLOCK.SYS, which the host maintains. >> Finally, my out-of-date "how shadowing works" information says that >> all the drives of the shadow set must have bad blocks at the same >> locations. If this restriction exists for you, then you will either >> have to give up on the drive, or add bad blocks to the other drives of >> the shadow set. > The bad blocks are not causing any real integrity problems, ;-) What kind of integrity problems is it causing then? ;-) Seriously, if you have data shadowed to a bad block, then you do not have that data shadowed. > just spurious error reports. Then add the bad blocks to the the bad block list on both drives, and then you won't get the error reports. - Rob -- Rob Brown b r o w n a t g m c l d o t c o m G. Michaels Consulting Ltd. (780)438-9343 (voice) Edmonton (780)437-3367 (FAX) http://gmcl.com/ ------------------------------ Date: Wed, 26 Mar 2008 08:59:27 -0700 (PDT) From: AEF Subject: Re: Disk shadowing with bad blocks Message-ID: On Mar 26, 10:19 am, tadamsmar wrote: > On Mar 26, 9:11 am, "Richard B. Gilbert" > wrote: > > > > > tadamsmar wrote: > > > On Mar 25, 8:05 pm, David J Dachtera > > > wrote: > > > >>tadamsmar wrote: > > > >>>I have a disk that has some bad blocks. > > > >>>When I put it into a shadow set with a disk with no error, the disk > > >>>with the bad blocks logs a few errors, but completes OK. > > > >>>When I do a ANAL/DISK/SHAD, the command ends with a parity error. > > > >>>But, as far as I know, the shadow set is basically sound. I used this > > >>>disk for months, I get no errors on image backup. > > > >>>Now, if I was not disk shadowing, I could just run the bad block > > >>>finding command and then use the disk without any problems. Seems > > >>>ironic. > > > >>>Is there a way to use this disk in a shadow set without getting these > > >>>errors? Shadow sets seem to keep hitting the bad blocks. > > > >>After everything in the previous thread, it seems there really only two > > >>things left to try: > > > >>1. INIT/ERASE > > >>2. Low-level format > > >>3. A dangerously high precipice > > > >>David J Dachtera > > >>(formerly dba) DJE Systems- Hide quoted text - > > > >>- Show quoted text - > > > > I don't think I am communicating very well at this point. > > > > My system works fine if I use only good disks that have no bad > > > physical blocks. > > > > But I now have one spare disk with some bad physical blocks. It > > > setting in my office not installed. I tried to use it and this > > > happened: > > > > 1. It logged errors during the shadow copy to it from a perfectly > > > good disk. But the copy worked. > > > > 2. After the copy, ANAL/DISK/SHAD ends with a parity error. > > > > Now, I am thinking about keeping this disk as a spare since is sort of > > > works in a shadow set. But I was wondering if there was as way to > > > avoid having these spurious errors reported. Disk shadowing seems to > > > have no way to stop reporting over and over the bad blocks on this > > > disks. > > > I would retire that disk drive to a non critical position; e.g. a > > paperweight! > > > YMMV!- Hide quoted text - > > > - Show quoted text - > > I am thinking about keeping it as a backup. If I lost a disk, then I > could use it as a temporary replacement till I ordered a new disk. It > works fine in a shadow set if you understand the "features" of disk > shadowing. The main problem is that you have to sort out real from > spurious error reports and the spurious parity errors will be > propagated to other disks after you allow the problem disk to be the > only member of a shadow set. In that case, you have to go to the > trouble of wiping out the spurious parity errors. > > Could be a paperweight in the meantime if I keep it its anti-static > bag. Are you bored? AEf ------------------------------ Date: Wed, 26 Mar 2008 16:09:42 GMT From: Rob Brown Subject: Re: Disk shadowing with bad blocks Message-ID: On Tue, 25 Mar 2008, Rob Brown wrote: > You have done ANALYZE/MEDIA/EXERCISE, haven't you? Perhaps this should have been ANALYZE/MEDIA/EXERCISE/RETRY. -- Rob Brown b r o w n a t g m c l d o t c o m G. Michaels Consulting Ltd. (780)438-9343 (voice) Edmonton (780)437-3367 (FAX) http://gmcl.com/ ------------------------------ Date: Wed, 26 Mar 2008 09:27:32 -0700 (PDT) From: tadamsmar Subject: Re: Disk shadowing with bad blocks Message-ID: <87a80722-3d63-41fd-8427-8f6aa7b0b18d@e10g2000prf.googlegroups.com> On Mar 26, 11:54=A0am, Rob Brown wrote: > On Wed, 26 Mar 2008, tadamsmar wrote: > > On Mar 25, 7:39 pm, Rob Brown wrote: > > >> And if you are out of spare blocks, so that you have bad blocks > >> existing, is the disk worth keeping? =A0It must be on its last legs. = =A0It > >> will certainly continue to grow bad blocks. > > > I have plenty of spares. =A0Not the problem. > > Obviously you do not have spares, since you have bad blocks. > > If you had spare blocks, as soon as you wrote to a bad block, it would > have been replaced with a good spare block with the same LBN. =A0The > host would never know about it. =A0And this happens below the level of > BADBLOCK.SYS, which the host maintains. It does replace the bad blocks. But it still reports the errors. Part of the problem is that disk shadowing reads in big chunks past the end of the files and can hit bad blocks in unused space. So, you don't have a real integrity issue with your shadow set, just spurious parity errors. > > >> Finally, my out-of-date "how shadowing works" information says that > >> all the drives of the shadow set must have bad blocks at the same > >> locations. =A0If this restriction exists for you, then you will either > >> have to give up on the drive, or add bad blocks to the other drives of > >> the shadow set. > > The bad blocks are not causing any real integrity problems, > > ;-) What kind of integrity problems is it causing then? =A0;-) 1. Errors logged during shadow copy 2. ANAL/DISK/SHAD ends with a parity error 3. If you reduce the shadow set to the one disk with the bad blocks, then spurious parity errors are propagated to any disk you add to the shadow set. The parity errors are past the end of files not really inside files. This is a "feature" of VMS disk shadowing, it reports some errors that are not really in files. ANAL/DISK/SHAD fails on these errors. Read the recent threads on this. That's how I learned about this "feature". > > Seriously, if you have data shadowed to a bad block, then you do not > have that data shadowed. > > > just spurious error reports. > > Then add the bad blocks to the the bad block list on both drives, and > then you won't get the error reports. > > - Rob > > -- > > Rob Brown =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b r o w n a t g m= c l d o t c o m > G. Michaels Consulting Ltd. =A0 =A0 =A0(780)438-9343 (voice) > Edmonton =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (780)437-3367 (FA= X) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://= gmcl.com/ ------------------------------ Date: Wed, 26 Mar 2008 09:30:16 -0700 (PDT) From: tadamsmar Subject: Re: Disk shadowing with bad blocks Message-ID: <2a925ef2-23f6-4a5d-bfc6-3380a7768731@s12g2000prg.googlegroups.com> On Mar 26, 8:15=A0am, "R.A.Omond" wrote: > tadamsmar wrote: > > [...big snip...] > > Please bite the bullet and do a low-level format > of the disk (this will revector any genuine bad > blocks, leaving you (hopefully) with a disk that > has no bad blocks visible). > > Assuming disk is DKA400: > > $ mcr sys$etc:rztools_alpha > RZTools> /h > =A0 =A0RZT [device] [/command[=3Dvalue] /...] > > =A0 =A0Commands =A0 Value required? =A0Function > =A0 =A0-------- =A0 --------------- =A0-------- > =A0 [...snip...] > > =A0 =A0FO rmat =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SCSI FORMAT > > RZTools> DKA400:/Format > > And with that, hopefully this thread might come to an end. Thanks! The End (except poor, confused Rob Brown might keep posting) ------------------------------ Date: Wed, 26 Mar 2008 12:53:11 -0400 From: Pete Subject: Re: Disk shadowing with bad blocks Message-ID: <6avku3t7a9jogo2n9vjk53fmvtli1tn5i6@4ax.com> On Wed, 26 Mar 2008 05:01:40 -0700 (PDT), tadamsmar wrote: >On Mar 25, 7:54 pm, Pete wrote: >> On Tue, 25 Mar 2008 10:06:43 -0700 (PDT), tadamsmar >> >> >> >> >> >> wrote: >> >I have a disk that has some bad blocks. >> >> >When I put it into a shadow set with a disk with no error, the disk >> >with the bad blocks logs a few errors, but completes OK. >> >> >When I do a ANAL/DISK/SHAD, the command ends with a parity error. >> >> >But, as far as I know, the shadow set is basically sound.  I used this >> >disk for months, I get no errors on image backup. >> >> >Now, if I was not disk shadowing, I could just run the bad block >> >finding command and then use the disk without any problems.  Seems >> >ironic. >> >> >Is there a way to use this disk in a shadow set without getting these >> >errors?   Shadow sets seem to keep hitting the bad blocks. >> >>  Have you logged a service call ? I think if the errorlog, VMS >> versions/patch level, log from the ana/disk/shadow, and the hardware >> details were included you would get a quicker answer. >> >> Pete- Hide quoted text - >> >> - Show quoted text - > >I don't have a service contract, and the problem is not that critical. Try a low level format (as someone already suggested). If you working with an unsupported disk I would check/read up on AWRE and ARRE bits on the drive. Might be automatic replacement is disabled. While you're reading that you should come across the grown defect list have a look at that. Manual for the drive should be available from the manufacturer. Pete ------------------------------ Date: Wed, 26 Mar 2008 09:28:58 -0400 From: "David Turner, Island Computers" Subject: Gigabit cards PCI/PCIX - a few left Message-ID: At $299 -- Island Computers US Corp PO Box 86 Tybee Island GA 31328 T: 877 636 4332 x201 M: 877 636 4332 x251 I: 00 1 912 786 8501 F: 912 786 8505 E: dturner@islandco.com W: www.islandco.com ------------------------------ Date: Wed, 26 Mar 2008 09:03:07 +0100 From: Joseph Huber Subject: Re: HP Alpha TCPIP active passive Message-ID: M White wrote: > Can someone tell me if HP OVMS TCPIP 5.3 supports FTP passive mode or only > active mode? > I have previously been able to FTP from the OVMS Alpha but now when I try to > send files I get connected and get conformation that I can cd (change dir) > but a dir, put, get all I get is a timeout. The network admin says nothing > has changed on the firewall etc.. But something has changed as I can't get > my windoz ftp client to work either which it use to be able to send/receive > also. > Any thoughts from the OVMS community? Thanks. I'm not sure (running 5.4), but think Yes, it can do passive mode, but it is not the default in an IPv4 network. Try in the FTP client the command SET PASSIVE ON . See HELP SET PASSIVE for further information on the SET PASSIVE keywords. -- Joseph Huber - http://www.huber-joseph.de ------------------------------ Date: Wed, 26 Mar 2008 07:30:39 -0000 From: "John Wallace" Subject: Re: Please critique my backup practices Message-ID: <13ujutolhrr0641@corp.supernews.com> "Michael Moroney" wrote in message news:fs9n15$vfi$1@pcls4.std.com... > "John Wallace" writes: > > > >"Michael Moroney" wrote in message > >news:fs918n$qf8$1@pcls4.std.com... > >> We have heard many time: "Thou shalt not use BACKUP/IGNORE=INTERLOCK". > >> But I have an application that runs continuously and doesn't close its > >> files, so the alternative is no backup of them. I had the idea of doing > >> two incremental backups, the first being a BACKUP/MOD/SINCE=BACKUP/RECORD > >> of the disk, and the second being BACKUP/MOD/SINCE=BACKUP/IGNORE=INTERLOCK > >> (note: no /RECORD) of the disk. The first is a "clean" incremental backup > >> of the disk, and the second, since it is run immediately after the first, > >> will contain only open files plus perhaps a few modified very recently. > >> It would only be used in emergencies. The lack of /RECORD is so the files > >> backed up on the second backup are not considered properly backed up, and > >> any file closed before the next pass of incremental backups will be > >> properly backed up during the next pass. Comments? > >> > > >What do you know about the relationship between the continuously-running > >application's in-memory copy of the file (which the application will see), > >and the on-disk copy of the file (which BACKUP will see)? Without that kind > >of knowledge, comments on the efficacy of /IGNORE=INTERLOCK are likely > >nothing more than speculation (unless the comment is "it's pointless", which > >isn't news to you). > > The application maps data files via $CRMPSC/$MGBLSC and generally forces a > writeback ($UPDSEC) when something important changes. The application is > homegrown and plays *very* fast and loose with the data, but due to the > nature of this beast, that's not as bad as it sounds. If the backup happens to contain valid data from these section files, you're presumably better off than if it didn't? But how do you *know* it will contain valid restorable data? In addition to the usual open file concerns, I'd also want to know about the relationship between the files - as the apps are still active, backups of files may be individually valid but may relate to different points in time, which, depending on the app, may or may not actually be a valid consistent restorable dataset? Even if you test the backup/restore and it appears to work when you test it, as far as I can see you've no guarantee that the standard backup will not, one day, contain inconsistent data e.g. because of unfortunate timing. Murphy says that sooner or later, you will actually need to restore the data but it won't be there in a usable form. What would the impact be if (when) that happened? If this data really is important to you, and you really really really cannot quiesce the app somehow, maybe you might want to think about doing something application-specific (but probably outside the main application) to save a copy of the important live data; maybe something which "knows" about the application's behaviour and knows when a good time to take a self-consistent snapshot might be???? I'm sure there are folks around who could provide better advice than I'm offering. They might want $$$, which would presumably be worthwhile if the data in these files is valuable to you. Regards John ------------------------------ Date: Wed, 26 Mar 2008 02:08:35 -0700 (PDT) From: AEF Subject: Re: Please critique my backup practices Message-ID: On Mar 25, 6:53 pm, David J Dachtera wrote: > AEF wrote: > > > On Mar 21, 11:41 am, David J Dachtera > > wrote: > > > Dale Dellutri wrote: > > > > > On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar wrote: > > > > > On Mar 20, 2:36?pm, Dale Dellutri wrote: > > > > > > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar wrote: > > > > > > > To do a backup, I pop a drive out of a shadowset, back it up and put > > > > > > > it back. > > > > > > > I assume you're talking about VMS Volume Shadowing. ?As far as I know, > > > > > > taking a drive out of a shadowset causes the drive to look the same as > > > > > > if there'd been a power failure. ?In other words, it does not properly > > > > > > close open files. > > > > > > > I assume that you take image backups. ?If so, there's no benefit to > > > > > > taking the drive out of the shadowset to take the image backup. > > > > > > According to service techs that I talked to when I first set up > > > > > > volume shadowing, there's no advantage over taking an image backup > > > > > > of the volume set (the DSA device). > > > > > > > I assume that this is still true. > > > > > > > > The problem is, I don't record the backup dates. > > > > > > > You could record backup dates if you simply took an image backup > > > > > > of the volume set. > > > > > > Don't I have to shutdown my system to do that? > > > > > I finally found the relevant item in "HP Volume Shadowing for > > > > OpenVMS", v7.3-2. Chapter 7, Section titled "Data Consistency > > > > Requirements": "Removal of a shadow set member results in what > > > > is called a crash-consistent copy. That is, the copy of the > > > > data on the removed member is of the same level of consistency > > > > as what would result if the system had failed at that instant." > > > > (pg 124 in my copy). > > > > > Actually, reading the entire section titled "Guidelines for > > > > for Using a Shadow Member for Backup" would be very useful. > > > > The usual technique is to quiesce the application (cause it to close its > > > files), THEN split the shadow-sets. We do something similar with BCVs on > > > an EMC DMX array. This minimizes your "backup window". > > > Why not... > > shut the app > > check that no files are open (except for INDEXF.SYS by the system) > > dismount the shadows set entirely > > Doing so disables mini-copy. See HELP DISMOUNT /POLICY > > David J Dachtera > (formerly dba) DJE Systems Then why does the fine manual say to do it that way? I guess it's a case of safety vs. speed. AEF ------------------------------ Date: 26 Mar 2008 12:50:30 -0600 From: lnewton@stopspam.net (Lawrence Newton) Subject: Polycenter Scheduler Message-ID: Has anyone been able to make the old Polycenter Scheduler V2.1 work on VMS V8.x?? I have it running at V7.3-2. I had to register the image sched_rtl.exe using @sys$update:register_privileged_image and restore vms$ieee_handler.exe to sys$library after each VMS upgrade. It fusses about the sched_rtl image and it won't register. That is only supplied as an .exe so I can't relink. Any ideas?? Lawrence ------------------------------ Date: Wed, 26 Mar 2008 09:37:11 -0700 (PDT) From: etmsreec@yahoo.co.uk Subject: Re: RX3600 and VMS 8.3 Message-ID: <268b60fd-4acd-4a02-8833-2d6340588a3e@i7g2000prf.googlegroups.com> On 24 Mar, 14:52, Chuck Aaron wrote: > If anyone is running the RX3660 or better server with VMS 8.3, can you share > your experience and comments. I am considering moving from an Alpha DS25 > running > vms 8.3 to the Itanium. > > Thank you in Advance, > > Chuck While Robert and Kerry will obviously have good advice, my experience suggests double your memory, then double it again when going Alpha to Integrity. If you don't absolutely needs lots of card slots then I'd seriously consider whether it's worth going for the rx3600 over the rx2660. The rx2660 is a nice bit of kit and is outnumbering our rx3600 sales many to almost none - purely because of price. If you need the extra slots, it can be worth going for the rx6600 instead as that gives you more CPU and memory expansion space. It's a pricier box though. Remember that you get graphics built in on the rx2660 too. VMS 8.3 means that you don't get any console display on the VGA monitor when booting. You can try, but the system crashes part way through boot if the VGA is set to primary. V8.3-1H1 gives you this functionality back, though it means you can't use the console through the iLO as the OPA0: device gets locked to the graphics adapter and doesn't swap back. Steve ------------------------------ Date: Wed, 26 Mar 2008 07:22:11 -0700 (PDT) From: tadamsmar Subject: zeroing out errors? Message-ID: Is there an easy way to zero out the error count you see with SHOW DEV D without rebooting? ------------------------------ Date: 26 Mar 2008 10:28:16 -0500 From: brooks@cuebid.zko.hp.nospam (Rob Brooks) Subject: Re: zeroing out errors? Message-ID: <$lSkB$6e$oGX@cuebid.zko.hp.com> tadamsmar writes: > Is there an easy way to zero out the error count you see with SHOW DEV > D without rebooting? Depending on the version of the operating system, look at $ HELP SET DEVICE /RESET -- Rob Brooks MSL -- Nashua brooks!cuebid.zko.hp.com ------------------------------ Date: Wed, 26 Mar 2008 07:33:03 -0700 (PDT) From: Jim Subject: Re: zeroing out errors? Message-ID: On Mar 26, 10:22=A0am, tadamsmar wrote: > Is there an easy way to zero out the error count you see with SHOW DEV > D > without rebooting? With VMS 7.3-2 and higher you can just "$ set device/reset=3Derror ddcu:" - see "$ help set device" - if you're using an older version of VMS then search some of the better VMS FTP sites for the ZDEC (ZeroDeviceErrorCount) too. ------------------------------ Date: Wed, 26 Mar 2008 14:40:52 +0000 From: "R.A.Omond" Subject: Re: zeroing out errors? Message-ID: tadamsmar wrote: > Is there an easy way to zero out the error count you see with SHOW DEV > D without rebooting? $ set device/reset=error dka400: For older versions of VMS prior to that command being implemented, use DELTA (I'm not going to hand-hold you through that). ------------------------------ Date: Wed, 26 Mar 2008 09:56:21 -0500 From: norm.raphael@metso.com Subject: Re: zeroing out errors? Message-ID: This is a multipart message in MIME format. --=_alternative 0052103785257418_= Content-Type: text/plain; charset="US-ASCII" tadamsmar wrote on 03/26/2008 10:22:11 AM: > Is there an easy way to zero out the error count you see with SHOW DEV > D > without rebooting? There is this... Title: CLEAR_ERRORS - Program to clear error count on all devices, memory and cpu Version: 1.0 Facility: System Management Abstract: This program zeros out device errors by walking the sb, ddb and ucb links. This makes it likely to catch all the error fields, particularly for fiber disks that have one ucb per data path. Cpu and memory errors are also zeroed out. Inspired by program written by Jur van der Burg of Compaq/DEC/HP to zero error counts. Environment: CMKRNL required, I/O database is locked for write access Author: Mark Oakley Verizon Wireless 20-Dec-2002 --=_alternative 0052103785257418_= Content-Type: text/html; charset="US-ASCII"
tadamsmar <tadamsmar@yahoo.com> wrote on 03/26/2008 10:22:11 AM:

> Is there an easy way to zero out the error count you see with SHOW DEV
> D
> without rebooting?

There is this...

 Title:
        CLEAR_ERRORS - Program to clear error count on all devices, memory and cpu

 Version:
        1.0

 Facility:
        System Management

 Abstract:
        This program zeros out device errors by walking the sb, ddb and
        ucb links. This makes it likely to catch all the error fields,
        particularly for fiber disks that have one ucb per data path.
        Cpu and memory errors are also zeroed out.

        Inspired by program written by Jur van der Burg of Compaq/DEC/HP
        to zero error counts.

 Environment:
        CMKRNL required, I/O database is locked for write access

 Author:
        Mark Oakley     Verizon Wireless        20-Dec-2002 --=_alternative 0052103785257418_=-- ------------------------------ Date: 26 Mar 2008 15:01:45 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: zeroing out errors? Message-ID: <47ea6559$0$25036$607ed4bc@cv.net> In article , "R.A.Omond" writes: >tadamsmar wrote: > >> Is there an easy way to zero out the error count you see with SHOW DEV >> D without rebooting? > >$ set device/reset=error dka400: > >For older versions of VMS prior to that command being implemented, >use DELTA (I'm not going to hand-hold you through that). I put together the blurb for DELTA that is included in the OpenVMS FAQ. Here it is for reference from an earlier (non-HTMLized) version of the OpenVMS FAQ: ------------------------------------------------------------ MGMT31. How do I reset the error count(s)? The system reboot is the only supported approach, but it is obviously undesirable in various situations -- there is presently no supported mechanism to reset error counts once the error(s) have been logged. As for an unsupported approach -- and be aware of the potential for causing a system crash... To reset the error count, one needs to determine the system address of the error count field. For a device, this is at an offset within the device's UCB structure. On VAX, the field is at an offset symbolically defined as UCB$W_ERRCNT. On Alpha, this field's offset is symbolically defined as UCB$L_ERRCNT. The former is a word in size; the latter is a longword. (Could it be that Alpha devices are more error prone? ;) You now need to locate the system address of the UCB$%_ERRCNT field of the device you wish to reset. Enter SDA. In the following, you will see designations in {} separated by a /. The first item in braces is to be used on the VAX and the second item should be used on an Alpha. (ie. {VAX/Alpha}) $ ANALYZE/SYSTEM SDA> READ SYS${SYSTEM/LOADABLE_IMAGES}:SYSDEF.STB SDA> SHOW DEVICE ! device designation of device with error SDA> EVALUATE UCB+UCB${W/L}_ERRCNT Hex = hhhhhhhh Decimal = -dddddddddd UCB+offset Record the hexadecimal value 'hhhhhhhh' returned. You can now exit from SDA and $ RUN SYS$SHARE:DELTA or do what I prefer to do, issue the following: SDA> SPAWN RUN SYS$SHARE:DELTA On both VAX and Alpha, the DELTA debugger will be invoked and will ident- ify itself. On Alpha, there will be an Alpha instruction decoded. For those unfamiliar with DELTA, it does not have a prompt and only one error message -- Eh? (Well, for sake of argument, there might be another error produced on the console if you're not careful -- aka. a system crash!) If you are on a VAX, enter the command: [W If you are on Alpha, enter the command: [L These set the prevailing mode to word and longword respectively. Remem- ber the UCB${W/L)_ERRCNT differences? Now issue the command 1;M DELTA will respond with 00000001 You're now poised to ZAP the error count field. To do so you need to en- ter the system address and view its contents. The format of the command to do this is of the form: :/ For an IPID, use the IPID of the SWAPPER process. It is always: 00010001 Thus, to ZAP the error count, you would enter: 00010001:hhhhhhhh/ When you enter the / SDA will return the content of the address hhhhhhhh. This should be the error count (in hexadecimal) of the device in question. If it is not, you did something wrong and I'd suggest you type a carriage return and then enter the command EXIT to get out of DELTA. Regroup and see where your session went awry. If you entered your address correctly and the error count was returned as in the following example, you can proceed. 00010001:80D9C6C8/0001 ! output on VAX 1 error 00010001:80D9C6C8/00000001 ! output on Alpha 1 error You can now ZAP the error count by entering a zero and typing a carriage return. For example: 00010001:80D9C6C8/0001 0 ! output on VAX 1 error 00010001:80D9C6C8/00000001 0 ! output on Alpha 1 error Now type the command EXIT and a carriage return. [Brian Schenkenberger] -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ End of INFO-VAX 2008.172 ************************