1 INFO-VAX	Fri, 13 Oct 2006	Volume 2006 : Issue 562       Contents:@ Re: Best way to get my email archive out of VMS and onto my Mac? CQD-223A/TM jumpers and manual" Re: CQD-223A/TM jumpers and manual" Re: CQD-223A/TM jumpers and manual Re: Death of VMS Re: Death of VMS. Re: Debugger GUI only working on some machines# Did HP-UX support also go to India? ' Re: Did HP-UX support also go to India?  Re: Opteron P Re: OT: for the serious computer hobbyist - UniVac Factronic Computer   System  P Re: OT: for the serious computer hobbyist - UniVac Factronic Computer  System  S Re: PARSEC: SPAMMERS Re: PARSEC: SPAMMERS Re: Reading 100 magnetic tapes Re: Reading 100 magnetic tapes Re: VMS Support in India Re: VMS Support in India Re: VMS VS LINUX  F ----------------------------------------------------------------------  % Date: Fri, 13 Oct 2006 02:16:07 +0200 $ From: Bill Bennett <no.spam@plea.se>I Subject: Re: Best way to get my email archive out of VMS and onto my Mac? / Message-ID: <egmls8$vq0$03$1@news.t-online.com>    Hi Dave,  E I guess I would ask if you really need/want to move all that mail to   another customI mail database; long before I got a Mac, I had started extracting my mail  
 out of VMSH MAIL into flat files (typically one file per folder, all folders from a  cabinet in theF same directory ... but some very active folders, like COV, split into  multiple files by E date), largely because I found it easier to find things by searching   through the I flat files with SEARCH than by using the search features of VMS MAIL ...   and thenL moving the archives to another system (in my case a Mac) was a simple KermitI run; and I can search through them pretty much as easily with egrep in a   TerminalH window as I could with SEARCH (although I still have the archives on my  hobbyist VAXstation for emergencies :)   E If you do decide to move your mail into a client database, you might   want to haveI a look at Emailchemy, a tool which allows you to convert between various   email D formats:  see http://www.weirdkid.com/products/emailchemy/index.html  D I used it once to move my Mac mail from Netscape to Mail.app, which  worked fine...   Hope it helps, Bill Bennett   Dave Spencer wrote:   W > Folks, I've got email in my personal account on OpenVMS that goes all the way back to V > the 80's. I'm considering transfering it all somehow to my personal computer - a Mac > running OS X.  > W > Naturally, I've got thousands and thousands of messages, all of which are filed using Y > VMSmail. And of course, I've taken advantage of all the features of VMSmail and created Y > a number of mail files as "cabinets" with meaningful names such as auctions, merchants, X > business, etc. each of which having many folders that further categorize the nature or > purpose of the message.  > W > I've been using the Mac's Mail app for some time as a temporary tool for emailing out W > files to people as attachments as well as reading HTML-based email messages. While it Z > works very well, it's a little light in the area of providing a strong filing mechanism.] > Yes, you can create folders; but I have so much stuff filed in so many folders that I would \ > be looking at hundreds of folders in a very lengthy list. Not good enough for my purposes. > [ > So it comes down to two issues. Is somebody aware of a good email client for the Mac that Z > will handle the volume of email that I have? And once I find a client, how on earth am IF > going to transfer all that email off of my VMS box and onto the Mac? >  > Suggestions??  >  > Thanks in advance, >  >  > -- Dave Spencer    ------------------------------    Date: 12 Oct 2006 14:12:29 -0700- From: "RomaX MANIAX" <diego.claeys@gmail.com> ' Subject: CQD-223A/TM jumpers and manual C Message-ID: <1160687549.741914.274060@c28g2000cwb.googlegroups.com>    Hi,   ? can someone provide me the manual or the jumpers settings for a  CQD-223A/TM card please.   Thanks to all.   ------------------------------  # Date: Thu, 12 Oct 2006 21:59:00 GMT % From: Rob Brown <mylastname@gmcl.com> + Subject: Re: CQD-223A/TM jumpers and manual D Message-ID: <Pine.LNX.4.61.0610121557430.9629@localhost.localdomain>  ( On Thu, 12 Oct 2006, RomaX MANIAX wrote:  A > can someone provide me the manual or the jumpers settings for a  > CQD-223A/TM card please.   Did you check = <http://www.bitsavers.org/pdf/cmd/CQD-220_CQD-223_Nov90.pdf>?      --    B Rob Brown                        b r o w n a t g m c l d o t c o m6 G. Michaels Consulting Ltd.      (780)438-9343 (voice)4 Edmonton                         (780)437-3367 (FAX)2                                   http://gmcl.com/   ------------------------------  % Date: Thu, 12 Oct 2006 19:38:57 -0500 # From: Alex Zorrilla <apz@zxeng.com> + Subject: Re: CQD-223A/TM jumpers and manual + Message-ID: <egmn650u3i@enews4.newsguy.com>   K Get it from Silicon Image's website.  They are the ones who bought out CMD.   2 http://www.siliconimage.com/support/index.aspx -->( KnowledgeBase (link on left of page) --> CMD Systems Products -->
 CQD Series       RomaX MANIAX wrote:  > Hi,  > A > can someone provide me the manual or the jumpers settings for a  > CQD-223A/TM card please. >  > Thanks to all. >    ------------------------------  # Date: Thu, 12 Oct 2006 19:07:10 GMT & From: John Reagan <john.reagan@hp.com> Subject: Re: Death of VMS 2 Message-ID: <ynwXg.1015$R71.1002@news.cpqcorp.net>   prep@prep.synonet.com wrote:. > "Tom Linden" <tom@kednos-remove.com> writes: >  > D >>I think it was around 1982 when Keating asked me if we would do anE >>Ada for the VAX, and I think at that time he had responsibility for 2 >>all langugaes, but as I said, I was an outsider. >  > L > You did the Ada compiler! I didn't know that. I still have the `Ada Medal' > from a long ago DECUS..  >   F Ada 93 on OpenVMS VAX and OpenVMS Alpha is provided by us.  Ada 95 on F OpenVMS Alpha and OpenVMS I64 is provided by AdaCore (www.adacore.com)   --   John Reagan 5 HP Pascal/{A|I}MACRO/COBOL for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------  % Date: Thu, 12 Oct 2006 13:57:06 -0700 * From: "Tom Linden" <tom@kednos-remove.com> Subject: Re: Death of VMS ) Message-ID: <op.thbttgfxtte90l@hyrrokkin>   B On Thu, 12 Oct 2006 08:24:33 -0700, <prep@prep.synonet.com> wrote:  . > "Tom Linden" <tom@kednos-remove.com> writes: > E >> I think it was around 1982 when Keating asked me if we would do an F >> Ada for the VAX, and I think at that time he had responsibility for3 >> all langugaes, but as I said, I was an outsider.  > G > You did the Ada compiler! I didn't know that. I still have the `Ada    > Medal' > from a long ago DECUS..  > G Sorry, I didn't say i did it, I was asked and I declined, I didn't want I to use Diana which was inferior to our intermediate repreasentation, also  I would only do it in PL/I.        --  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------    Date: 12 Oct 2006 14:53:21 -0700 From: amelia_airhead@yahoo.com7 Subject: Re: Debugger GUI only working on some machines A Message-ID: <1160690001.519945.71310@i3g2000cwc.googlegroups.com>    Hello Jeff,   C   I redefined the debug display as you instructed.  It has the same  information F as it does on the successful GUI run but finishes with the same error:  #   OpenVMS Alpha version information '   %DEBUG-I-INITIAL, Language: ADA, etc. 3   %DEBUG-I-NOTATMAIN, Type GO to reach Main program 3   %DEBUG-W-NEEDMORE, unexpected end of command line   D and then I'm back at the prompt.  I didn't type "go" so where is the second message coming from?  	   Thanks,    Amelia   Jeff wrote: ! > amelia_airhead@yahoo.com wrote: 
 > > Hello, > > H > >   Three of us are attempting to use the debugger on our own machines > > and failing. > >  > > On our own machines:I > >   run theProgram.exe - The GUI flashes up on the screen and goes away  > > immediately. > G > I'm sorry to hear you are having trouble. Below are some suggestions.  >  > ? > >   debug/keep - The GUI comes up with an information message = > >       %DEBUG-I-VERSION: Expected VMSDEBUG.DAT version: 72 D > >       We are running version 7.2, the vmsdebug.dat in the system > > default directory doesI > >       say it's version is 72.  Does this mean it can't find the .DAT?  > > I'm not finding a 6 > >       definition in the help messages for VERSION. > H > This informational message is one that can be safely ignored. DEBUG isN > complaining about the version string inside the file SYS$LOGIN:VMSDEBUG.DAT. >  > J > > Is there some other log I can find information on why the debugger GUI > > is not saying up on our  > > own machines?  > I > Please temporarily disable the debugger's DECwindows interface and then  > run your program:  > $ >      $ define dbg$decw$display " " >      $ run theProgram  > E > I expect that you will see some additional error messages that will C > provide clues to the problem. Please post the results if you need  > further assistance.  > 	 > Thanks.  >  > -Jeff " > -HP OpenVMS DEBUG project leader   ------------------------------    Date: 12 Oct 2006 13:02:06 -07003 From: "n.rieck@sympatico.ca" <n.rieck@sympatico.ca> , Subject: Did HP-UX support also go to India?B Message-ID: <1160683326.379082.93010@h48g2000cwc.googlegroups.com>  ? So did HP-UX support also go to India? (or was it just OpenVMS)   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  % Date: Thu, 12 Oct 2006 16:30:46 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: Did HP-UX support also go to India?, Message-ID: <452EA5EA.36EAC4AF@teksavvy.com>   "n.rieck@sympatico.ca" wrote:  > A > So did HP-UX support also go to India? (or was it just OpenVMS)   G bob at instant whip provided a link a few days ago of a complaint about G HP support being a problem area because of outsourcing. When I read it, G I saw it as a general problem for all enterprise customers. VMS was not  mentioned specifically.    ------------------------------  % Date: Thu, 12 Oct 2006 18:38:01 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca>  Subject: Re: Opteron; Message-ID: <452ec3a2$0$5939$9a6e19ea@news.newshosting.com>   5 "Tom Linden" <tom@kednos-remove.com> wrote in message # news:op.tg9vxilztte90l@hyrrokkin... A > Might be a good time for VMS Engineering to feed any additional  > requirements to AMD  >  > . > AMD gives deeper peek into quad-core Opteron >  >  > Rick Merritt EE Times  > (10/10/2006 8:09 PM EDT) > H > SAN JOSE, Calif. - Advanced Micro Devices Inc. (AMD) provided a deeperL > look into the quad-core Opteron, detailing six areas where it will enhance% > the CPU expected to appear in 2007.  > E > Ben Sander, a principal member of technical staff at AMD, described G > Barcelona, the company's first 65-nm server chip and its first native K > quad-core architecture at a presentation at the Fall Processor Forum here D > Tuesday (Oct. 10). Improvements range from 128-bit wide multimediaD > pathways to an upgraded memory controller and a third-level cache. > L > "A lot of these enhancements involve just a few percentage points of addedC > performance here and there in an effort to build up a story about E > significant improvements to the overall architecture," Sander said.  > G > AMD will not detail until later this year expected benchmarks for its  > quad-core processor. > K > Barcelona widens from 64- to 128-bits the width of the execution path for K > multimedia instruction extensions. In tandem, the chip speeds up the rate J > at which it feeds multimedia data and instructions to the CPU. The movesC > will give a boost to a range of media encode/decode and technical  > computing applications.  > K > In addition, the company has redesigned the two memory controllers on the I > Opteron so they can act independently. That should make more DRAM banks E > available at any given time and reduce page conflicts, Sander said.  > J > The updated memory controller will support DDR2, DDR3 and fully bufferedC > DIMM memories. However, AMD does not expect OEMs to use the first 5 > generation of FB-DIMMs with Barcelona, Sander said.  > L > Barcelona provides two levels of private cache for each core, a 64Kbyte L1I > and 512 Kbyte L2. The chip sports a relatively small 2Mbyte third-level 1 > cache that will be expanded in a follow on CPU.  > F > To speed up virtualization, Barcelona builds in hardware support forG > nested paging. The feature essentially caches address translations to K > reduce memory accesses that take up as much as three-quarters of the time % > of today's virtualization software.  > F > "We have achieved a 20:1 server consolidation ratio inside AMD usingF > virtualization, so it's obviously a huge cost savings," said Sander. >   ' Similar info but from a different site.   ' AMD Unveils Barcelona Quad-Core Details R http://www.extremetech.com/article2/0,1558,2027633,00.asp?kc=ETRSS02129TX1K0000532  E Note that these buses are 128 bits wide. If memory serves, (some/all) K Itanium paths are 192 bits wide. So I wonder how much time will pass before . Itanium is officially labelled "no necessary"?  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html9 http://www3.sympatico.ca/n.rieck/links/openvms_demos.html    ------------------------------  % Date: Thu, 12 Oct 2006 19:32:35 -0500 # From: Alex Zorrilla <apz@zxeng.com> Y Subject: Re: OT: for the serious computer hobbyist - UniVac Factronic Computer   System   + Message-ID: <egmmq80te2@enews4.newsguy.com>   H I can just imagine some self-proclaimed l33ter try to pimp this box and  overclock it....    B "The first thing we did was to take all the old heatsinks off and F replace all the old thermal compound with Arctic Silver V.  Everybody G knowsz that the stock stuff is crap.  When you are overclocking, every   little bit helps.   I "We also saw that the old owners must have emptied out the water cooling  D unit, though the bottom did have some sort of weird silvery colored I blobs.  Great!  That saved us the trouble of emptying it out.  We filled  D it up with some UV-reactive ethylene glycol and hooked it up to our G fishtank water pump.  We even found an old radiator in a junkyard that  G belonged to an old Subaru pickup truck, and we figured that would be a  3 perfect way to dissipate the heat outside the case.   E "Well, with that cool windowed case (those guys were really ahead of  C their time!) and the glow-in-the-dark antifreeze, we really needed  D something to light it up.  Then Jody came up with the perfect idea. C Take out all those old burnt out light bulbs (there must have been  L 1000's of them) and replace them with neon Christmas tree lights.  Sweeeeet!  > "We have also ordered some deep blue cold cathode lights from C pimprigz.com (shameless sponsor plug) to put around those windows.  G Those lights should be coming in any day now, so we'll be sure to have  8 some pix up once we get this baby up and running!!!!!!!"         JF Mezei wrote:  > Ian Miller wrote: 3 >> http://atlanta.craigslist.org/sys/219423935.html  >>I >> "UNIVAC I used 5,200 vacuum tubes,[2] weighed 29,000 pounds (13 metric G >> tons), consumed 125 kW, and could perform about 1,905 operations per & >> second running on a 2.25 MHz clock. > I > Almost as fast as the all mighty Microvax II :-)  Does this come with a 8 > wall of little flashing lights like in sci-fi movies ?   ------------------------------  % Date: Thu, 12 Oct 2006 15:24:05 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> Y Subject: Re: OT: for the serious computer hobbyist - UniVac Factronic Computer  System  S , Message-ID: <452E964E.6E8680DC@teksavvy.com>   Ian Miller wrote:  > 2 > http://atlanta.craigslist.org/sys/219423935.html > H > "UNIVAC I used 5,200 vacuum tubes,[2] weighed 29,000 pounds (13 metricF > tons), consumed 125 kW, and could perform about 1,905 operations per% > second running on a 2.25 MHz clock.   G Almost as fast as the all mighty Microvax II :-)  Does this come with a 6 wall of little flashing lights like in sci-fi movies ?   ------------------------------  % Date: Thu, 12 Oct 2006 15:04:12 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: PARSEC: SPAMMERS , Message-ID: <452E91A6.ABE47050@teksavvy.com>  D I received a private email today from Parsec explaining how they hadF gotten my email, apologising and confirming they opted me out of their% list. So this was a honourable thing.   D Lets hope their learned from their mistake and be very careful aboutD such mailings in the future. The private email I got went a long way towards fixing their error.    ------------------------------    Date: 12 Oct 2006 16:21:53 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: PARSEC: SPAMMERS 3 Message-ID: <61YiXYHiu6BA@eisner.encompasserve.org>   l In article <013801c6ee25$958c2c30$2802a8c0@CHARONVAX>, "Peter Weaver" <info-vax@weaverconsulting.ca> writes:H >> formally apology to the VMS community for our invitation appearing as >> spam. > L > It did not "appear" to be spam, it was spam. If you are going to apologize" > then apologize for what you did. > H >> There is on opt-out link to remove you from our distribution list andJ >> the opt-out request is taken very seriously.  Once received, we respectH >> your request and remove your e-mail information from our records.  IfJ >> you do not want to use the opt-out feature, please call us toll-free at/ >> 877.462.7732 press 0 and ask for Dawn Rubin.  > K > You miss the point, nobody should have to opt-out if they never opted-in. J > Whatever list you have now is not an opt-in list and it should be thrownL > away and started from scratch. If you want to build an opt-in list then doN > it correctly; Ask people if they want to opt-in when they visit your websiteN > or at shows or on the phone, send one email asking them to verify their wishI > to opt-in, if you do not get the verification then do not send any more  > email to that address.  ) If the above is not clear, take a look at   8 	http://www.cluelessmailers.org/info/listmanagement.html   ------------------------------  % Date: Fri, 13 Oct 2006 01:52:13 +0200 $ From: Bill Bennett <no.spam@plea.se>' Subject: Re: Reading 100 magnetic tapes / Message-ID: <egmkfe$td0$03$1@news.t-online.com>    apogeusistemas@gmail.com wrote: 	 > Hi all:  > ' >    I have to read 100 magnetic tapes.  > 2 >    My intention is read one tape, save data to a > 1 >    directory and create a save_set and zip this  > E >    save_set with pkzip and send to a W2K server (big space to store  > data). > 0 >    I'll make this task 100 times. (100 tapes). > + >    I'd like know if I'll have reliability  >     & >    in this process. What you think ? >      >    Regards >  Hi apogeusistemas,  J You've gotten some good advice already, particularly in the initial threadH (starting with the post by WWWeb through the one by briggs), but since II did something like this (tried to recover data from 10-15 year old BACKUP L tapes) a few years ago, I thought I'd toss in my thoughts ... as some of theK earlier  posters suggested,  deterioration of the oxide coating on the tape I will likely be your main problem, and because you will rub off more oxide J onto the tape heads every time you try to read a tape, your signal quality will be worse after every try.  K For example, I had a few tapes that I could read once (to make a directory) G and then was unable to read a second time to recover the data!   In one I case, the volume header was corrupted by the first pass, so that the tape G couldn't even be mouted again for a recovery pass.  As you might expect I from the comments about deterioration of the oxide coating, on tapes that H I had to try to read several times, I generally found that the number ofL errors increased with every try ... and since I cleaned the tape heads afterH each pass, I could see that the amount of oxide that rubbed off onto the) heads tended to get worse with every try.   I So after a few false starts (and trying a couple of different tape drives K to convince myself that the problem was with the tapes, etc.), I settled on  this approach:  H    1) Since my tapes all had an ANSI volume label, I could mount them asH a labeled volume and try to copy all the save sets to disk with a simpleB COPY MTx0:*.* DKxy:* command ... the idea here was to minimize theH tape motion by avoiding any rereading of  bad blocks, which tends to rubF off more oxide on the heads and cause your signal to deteriorate.  ForK about a third of my tapes, I was able to recover all off the save sets this  way.I    2) Once you get the save sets on disk with COPY, you should check them F with BACKUP (extract the contents to a scratch disk at least); some ofG the save sets recovered with COPY will likely have errors in them, that F BACKUP can detect with the redundant information it puts into the saveG sets ... if BACKUP reports only errors "recovered by redundancy group," B you are OK -- BACKUP was able to correct the errors; but if BACKUP; reports "unrecoverable" errors, you will want to try again. J    3) For tapes that couldn't be read all the way through with COPY or forD save sets recovered with COPY that contain unrecoverable errors, youL will want to try to read the save sets you didn't get on the first pass fromB the tape using BACKUP; by using BACKUP to read specific save sets,K you can (within limits, see below) skip over earlier files on the tape that G you already have (or have given up on), and as was mentioned by earlier A posters, you will be using the CRC-based error recovery mechanism I built into BACKUP to try to recover from any errors that are encountered. J For about another third of my tapes, I was able to recover essentially allB of the data (with perhaps a few missing tape blocks) with multiple BACKUP passes.  K Another third of my tapes I either couldn't read at all (couldn't mount) or E was only able to recover a small amount of data from them; these were G generally tapes of intermediate age ... perversely enough, I had little A problem reading the oldest tapes, which were recorded at 1600 bpi ? with PE encoding; I had the worst problems with tapes that were B recorded at 6250 bpi with GCR encoding (and not only the oldest ofD those tapes).  Possibly some of the problems I had with the tapes at@ 6250 bpi were due to tape quality or alignment problems with theE drives use to write the tapes; I didn't have enough information about J those variables to detect any such effects by the time I tried to read theI tape ... but one thing that certainly contributed to the problems was the G fact that GCR encoding incorporates its own error detection/correction, F and that when an error is detected by the hardware, the drive firmwareE (or the tape device driver?) causes the drive to reread the bad block D repeatedly, which tends to dirty up the heads even more and make theH signal at that point on the tape even worse ... and if that point on theD tape happens to be in a part of the tape that has to be read for theI system to locate a particular file on the tape (in a volume or file label C record), you may not be able to access files on the tape beyond the  bad record at all.  A However, there are ways around that sort of problem ... a company F that specializes in data recovery will typically have tape drives withG custom firmware that doesn't try to rub the oxide off the tape at a bad C spot.  Also they will have tools that allow them to manually locate = tape marks on a tape, so that they can manually put a new BOT D marker on the tape just before the next file after a bad spot, whichD allows them to access files farther along on the tape.  These pointsB bring us back to a suggestion made by several earlier posters:  ifC the data on these tapes is really important to you, you should look E into the possibility of having a data recovery service try to recover C the data for you ... you can wait until you start to have problems, ? but remember that the more you try to read a tape yourself, the C worse the signal will be on the tape and the less likely it will be B that even a data recovery service will be able to get anything off	 the tape.   ; Of course, your chances of success will also depend to some C extent on the organization of the data ... in my case, for example, ? the data consisted of a large number of partially redundant and A overlapping BACKUP save sets, so that I could recover essentially F everything that was still of interest from the 2/3 of the tapes that IH could read.  (Also it helped that I still had the original tape listings< on disk, so I knew what was on the tapes I couldn't read...)  = Anyway, good luck to you!  I hope these comments will help to ; answer your original question about how reliable you should & expect the recovery operation to be...   Bill Bennett   ------------------------------    Date: 12 Oct 2006 22:28:55 -0700 From: apogeusistemas@gmail.com' Subject: Re: Reading 100 magnetic tapes C Message-ID: <1160717335.470225.228200@i42g2000cwa.googlegroups.com>    Bill Bennett wrote: ! > apogeusistemas@gmail.com wrote:  > > Hi all:  > > ) > >    I have to read 100 magnetic tapes.  > > 4 > >    My intention is read one tape, save data to a > > 3 > >    directory and create a save_set and zip this  > > G > >    save_set with pkzip and send to a W2K server (big space to store 
 > > data). > > 2 > >    I'll make this task 100 times. (100 tapes). > > - > >    I'd like know if I'll have reliability  > > ( > >    in this process. What you think ? > >  > >    Regards > >  > Hi apogeusistemas, > L > You've gotten some good advice already, particularly in the initial threadJ > (starting with the post by WWWeb through the one by briggs), but since IK > did something like this (tried to recover data from 10-15 year old BACKUP N > tapes) a few years ago, I thought I'd toss in my thoughts ... as some of theM > earlier  posters suggested,  deterioration of the oxide coating on the tape K > will likely be your main problem, and because you will rub off more oxide L > onto the tape heads every time you try to read a tape, your signal quality  > will be worse after every try. > M > For example, I had a few tapes that I could read once (to make a directory) I > and then was unable to read a second time to recover the data!   In one K > case, the volume header was corrupted by the first pass, so that the tape I > couldn't even be mouted again for a recovery pass.  As you might expect K > from the comments about deterioration of the oxide coating, on tapes that J > I had to try to read several times, I generally found that the number ofN > errors increased with every try ... and since I cleaned the tape heads afterJ > each pass, I could see that the amount of oxide that rubbed off onto the+ > heads tended to get worse with every try.  > K > So after a few false starts (and trying a couple of different tape drives M > to convince myself that the problem was with the tapes, etc.), I settled on  > this approach: > J >    1) Since my tapes all had an ANSI volume label, I could mount them asJ > a labeled volume and try to copy all the save sets to disk with a simpleD > COPY MTx0:*.* DKxy:* command ... the idea here was to minimize theJ > tape motion by avoiding any rereading of  bad blocks, which tends to rubH > off more oxide on the heads and cause your signal to deteriorate.  ForM > about a third of my tapes, I was able to recover all off the save sets this  > way.K >    2) Once you get the save sets on disk with COPY, you should check them H > with BACKUP (extract the contents to a scratch disk at least); some ofI > the save sets recovered with COPY will likely have errors in them, that H > BACKUP can detect with the redundant information it puts into the saveI > sets ... if BACKUP reports only errors "recovered by redundancy group," D > you are OK -- BACKUP was able to correct the errors; but if BACKUP= > reports "unrecoverable" errors, you will want to try again. L >    3) For tapes that couldn't be read all the way through with COPY or forF > save sets recovered with COPY that contain unrecoverable errors, youN > will want to try to read the save sets you didn't get on the first pass fromD > the tape using BACKUP; by using BACKUP to read specific save sets,M > you can (within limits, see below) skip over earlier files on the tape that I > you already have (or have given up on), and as was mentioned by earlier C > posters, you will be using the CRC-based error recovery mechanism K > built into BACKUP to try to recover from any errors that are encountered. L > For about another third of my tapes, I was able to recover essentially allD > of the data (with perhaps a few missing tape blocks) with multiple > BACKUP passes. > M > Another third of my tapes I either couldn't read at all (couldn't mount) or G > was only able to recover a small amount of data from them; these were I > generally tapes of intermediate age ... perversely enough, I had little C > problem reading the oldest tapes, which were recorded at 1600 bpi A > with PE encoding; I had the worst problems with tapes that were D > recorded at 6250 bpi with GCR encoding (and not only the oldest ofF > those tapes).  Possibly some of the problems I had with the tapes atB > 6250 bpi were due to tape quality or alignment problems with theG > drives use to write the tapes; I didn't have enough information about L > those variables to detect any such effects by the time I tried to read theK > tape ... but one thing that certainly contributed to the problems was the I > fact that GCR encoding incorporates its own error detection/correction, H > and that when an error is detected by the hardware, the drive firmwareG > (or the tape device driver?) causes the drive to reread the bad block F > repeatedly, which tends to dirty up the heads even more and make theJ > signal at that point on the tape even worse ... and if that point on theF > tape happens to be in a part of the tape that has to be read for theK > system to locate a particular file on the tape (in a volume or file label E > record), you may not be able to access files on the tape beyond the  > bad record at all. > C > However, there are ways around that sort of problem ... a company H > that specializes in data recovery will typically have tape drives withI > custom firmware that doesn't try to rub the oxide off the tape at a bad E > spot.  Also they will have tools that allow them to manually locate ? > tape marks on a tape, so that they can manually put a new BOT F > marker on the tape just before the next file after a bad spot, whichF > allows them to access files farther along on the tape.  These pointsD > bring us back to a suggestion made by several earlier posters:  ifE > the data on these tapes is really important to you, you should look G > into the possibility of having a data recovery service try to recover E > the data for you ... you can wait until you start to have problems, A > but remember that the more you try to read a tape yourself, the E > worse the signal will be on the tape and the less likely it will be D > that even a data recovery service will be able to get anything off > the tape.  > = > Of course, your chances of success will also depend to some E > extent on the organization of the data ... in my case, for example, A > the data consisted of a large number of partially redundant and C > overlapping BACKUP save sets, so that I could recover essentially H > everything that was still of interest from the 2/3 of the tapes that IJ > could read.  (Also it helped that I still had the original tape listings> > on disk, so I knew what was on the tapes I couldn't read...) > ? > Anyway, good luck to you!  I hope these comments will help to = > answer your original question about how reliable you should ( > expect the recovery operation to be... >  > Bill Bennett  9 Thanks folks. I think that I couldn't choice a best place / to post my question than here in comp.os.vms !!    ------------------------------  % Date: Thu, 12 Oct 2006 15:13:53 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ! Subject: Re: VMS Support in India , Message-ID: <452E93EB.77517C5E@teksavvy.com>   DaveG wrote:H > Didn't suggest that roadmaps were/are legal commitments.  Roadmaps canF > and often do change for a variety of reasons.  And to answer the VAXH > 8.2 comment.  Is it *really* worth the engineering effort?  Is there aI > large enough customer ( not hobbyist ) demand to make worth it for them  > to do?  My guess is no.     F You said it: the roadmap is not a commitment. It can change any minute HP wants to change it.    E VMS customers deserve some comittements these days because of all the  apparent changes/downsizing.   ------------------------------  % Date: Thu, 12 Oct 2006 17:30:10 -0400 ' From: Dave Froble <davef@tsoft-inc.com> ! Subject: Re: VMS Support in India 9 Message-ID: <wNWdnZMptaMoLLPYnZ2dnUVZ_qGdnZ2d@libcom.com>    DaveG wrote: > JF Mezei wrote:  >> DaveG wrote: H >>> How do you *know* that Nemo is/was the last hurrah for VMS?  Current >>> roadmaps show otherwise. >>J >> VMS customers have learned thatr roadmaps are not legal commitments. HPH >> can change them at any time. Where is the VAX version of 8.2 that had >> been on the roadmap ? > H > Didn't suggest that roadmaps were/are legal commitments.  Roadmaps canF > and often do change for a variety of reasons.  And to answer the VAXH > 8.2 comment.  Is it *really* worth the engineering effort?  Is there aI > large enough customer ( not hobbyist ) demand to make worth it for them  > to do?  My guess is no.  > 	 > Dave...  >   G You may be entirely correct about the number of paying customers still  I on VAX.  Regardless, if even one is still paying for a support contract,  G then HP is not holding up their side of the contract.  I've never seen  I in the support agreements where the number of people subscribing has any  G bearing on the level of support provided to a particular customer.  If  H there are any VAX customers still paying for support, then HP has acted E in 'bad faith' in taking their money, knowing full well they have no  & intentions on supporting the customer.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Thu, 12 Oct 2006 13:38:20 -0600 + From: Mark Berryman <mark@theberrymans.com>  Subject: Re: VMS VS LINUX % Message-ID: <452e3740$1@mvb.saic.com>    Robert Deininger wrote: B > In article <slrneinp0v.423.usenet@zappy.catbert.org>, Dan Foster > <usenet@evilphb.org> wrote:  >  > H >>        4. HP is not selling VMS servers in the workstation or low-endM >>           arena; they are concentrated on medium range and high end sales.  > G > This is simply false.  HP is selling entry-level servers (see rx1620, G > rx2620) and "workstations" (use the optional built-in graphics in the K > above, or add a better-performing PCI graphics card).  VMS supports these K > configurations.  They are among the most popular VMS/Integrity offerings.  > I > Integrity "workstations" are servers with graphics, keyboard, and mouse L > added, which is the same situation we've had on AlphaServers/AlphaStationsD > for a number of years.  The only difference is the verbiage in the( > marketing materials and product names.  L Apparently we differ on the definition of a workstation.  All of my current K workstations support both graphics and sound, including my Alpha VMS based  P workstation.  To my knowledge, HP is not currently selling any VMS workstations P with sound capabilities and, as far this customer is concerned, that means that * they are not selling any VMS workstations.  
 Mark Berryman    ------------------------------   End of INFO-VAX 2006.562 ************************