INFO-VAX Wed, 21 Mar 2007 Volume 2007 : Issue 160 Contents: 216 Million Americans Are Scientifically Illiterate (Part II) Re: 216 Million Americans Are Scientifically Illiterate (Part II) Re: 216 Million Americans Are Scientifically Illiterate (Part II) Re: Cool new features in OpenVMS 8.3 Digital Super user Re: end of DLT? Belluzzo strikes again Re: Itanium exception handling performance Re: Itanium exception handling performance Re: Kermit Large File Support Re: Kermit Large File Support Re: Kermit Large File Support Re: Problems zipping RBF file Re: Problems zipping RBF file Re: Suggestion for the VMS X-windows server Re: system job que manager not running Re: system job que manager not running US looking to merge with Canada, Mexico! Re: US looking to merge with Canada, Mexico! Re: US looking to merge with Canada, Mexico! vme data transactios Which tapes for 3R-A0692-AA drive? Which tapes for 3R-A0692-AA drive? Re: Willing to bet this is Windows at its best Re: Willing to bet this is Windows at its best Re: Willing to bet this is Windows at its best ---------------------------------------------------------------------- Date: 21 Mar 2007 04:41:53 -0700 From: "n.rieck@sympatico.ca" Subject: 216 Million Americans Are Scientifically Illiterate (Part II) Message-ID: <1174477313.571765.275110@d57g2000hsg.googlegroups.com> 216 Million Americans Are Scientifically Illiterate (Part II) http://www.technologyreview.com/blog/duncan/17563/ Although I agree with this article, it is not limitted to Americans. And recent discussions in COV (with everything from "global warming" to the "bible") make be believe it applies to computer people as well. ### I especially like the comments left by the second blogger: I had this sad realization a long time ago, that most lay people, especially those without college education, view science as just another religion. They don't understand what is going on, and therefore even if they choose to believe in science, they do it through the same mental process as one believes in religion. They do it through a leap of faith. Their rationalization may go something like this: "...well, all these scientists and engineers and other smart*ss people 'believe' in science, therefore they might be onto something. I don't really grasp what is going on, but I'll just believe them, because they are smart" So, people who think like this, suspend their critical thinking, bend to social pressure, and bow to authority. If they say that evolution is true, but they arrived at this belief through a religious-like process, then we are not really making much progress, are we? It is also said that most European laymen believe in evolution, unlike most American laymen. But if you scratch the surface, and start to ask those Europeans some questions, you'll notice that they don't understand evolution. They just believe in it. And then of course, religion provides definite, and comforting answers: "don't worry, God will take care of you". Science on the opposite - it leaves you hanging, and it tells you how insignificant and pathetic you are. It doesn't take a genius to figure out which religion people are going to choose. People are babies. They long for warmth and comfort, even at the expense of rational thinking. ### Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: 21 Mar 2007 04:59:18 -0700 From: bob@instantwhip.com Subject: Re: 216 Million Americans Are Scientifically Illiterate (Part II) Message-ID: <1174478358.151838.226750@e65g2000hsc.googlegroups.com> On Mar 21, 7:41 am, "n.ri...@sympatico.ca" wrote: > 216 Million Americans Are Scientifically Illiterate (Part II) > > And then of course, religion provides definite, and comforting > answers: "don't worry, God will take care of you". Science on the > opposite - it leaves you hanging, and it tells you how insignificant > and pathetic you are. It doesn't take a genius to figure out which > religion people are going to choose. People are babies. They long for > warmth and comfort, even at the expense of rational thinking. science is telling you more and more every day that God is real ... creation started it all ... we all came from the same mother and father ... that everything is unique and there is an order to the whole universe ... We are still waiting for science to explain the resurrection of Jesus Christ, and the miracles he did, raising men from the dead, curing blindness, leprosy, crippleds, blood diseases, all witnessed by thousands of individuals who when given a simple choice to renounce everything, they allowed themselves to be mauled by lions or worse ... science cannot even explain the shroud of turin yet and how the reverse negative like image of a man believed to be Christ got on that cloth ... ------------------------------ Date: 21 Mar 2007 07:09:07 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: 216 Million Americans Are Scientifically Illiterate (Part II) Message-ID: > 216 Million Americans Are Scientifically Illiterate (Part II) > > http://www.technologyreview.com/blog/duncan/17563/ > > Although I agree with this article, it is not limitted to Americans. > And recent discussions in COV (with everything from "global warming" > to the "bible") make be believe it applies to computer people as well. > > ### > > I especially like the comments left by the second blogger: I did not see any VMS content in that post. Perhaps another newsgroup was intended, like the VME questions. ------------------------------ Date: Wed, 21 Mar 2007 10:41:30 -0700 From: - Subject: Re: Cool new features in OpenVMS 8.3 Message-ID: Paul Repacholi wrote: > Doc writes: > >> However, can they break AES? That's the nice new thing in >> BACKUP/ENCRYPT. > > Would it get the nod from `standards' if they couldn't? /break AES/ is not the correct question. > http://csrc.nist.gov/CryptoToolkit/aes/ So, can they break Rijndael? http://www.schneier.com/paper-rijndael.html 'Twould be nice if VMS allowed one to switch ciphers. Wouldn't be AES (i.e. interoperable & filled w/ yummy NSA goodness), but it /might/ be more "secure". ------------------------------ Date: 21 Mar 2007 02:51:25 -0700 From: "mb301@hotmail.com" Subject: Digital Super user Message-ID: <1174470685.847594.248770@y80g2000hsf.googlegroups.com> Look what's on e-bay... http://cgi.ebay.co.uk/DEC-DIGITAL-PIN-BADGE-ALPHASERVER-MAINFRAME-VAX_W0QQitemZ130089205725QQcategoryZ1479QQssPageNameZWDVWQQrdZ1QQcmdZViewItem ------------------------------ Date: Wed, 21 Mar 2007 10:40:38 -0700 From: David Mathog Subject: Re: end of DLT? Belluzzo strikes again Message-ID: Andrew wrote: > Many industry regulators having noted the publicity around losses of > tapes in transit to off site storage facilities and the loses in some > of these facilities are beginning to require tapes to be encrypted so > this will become commonplace. commonplace != good thing. DRM on audio files is "commonplace". The problem with encrypted files is that they are damned fragile. Lose a 1024byte chunk out of a 10Gb text file and 99.9999% of the data remains. Lose the same number of bytes in the same position out of the same file encrypted and, depending on the encryption method, it will most likely either not be possible to recover data roughly "after" that block, or in the worst cases, any data at all. Best case the data is encrypted in "smallish" blocks of say 1Mb each, and then only that block is lost. Does the LTO-4 do this? I understand that security is needed for certain tape backups. However imagine what fun would ensue for a particularly paranoid company which kept just three copies of its encryption keys, only to find years later when they lose both the LTO-4 drives and the master set in a fire that the two backup copies are unreadable. (What, CD's go bad?!!?!?!!!) So all in all, it's unclear to me that encrypting backup files is clearly better than traditional physical security measures. Regards, David Mathog ------------------------------ Date: 21 Mar 2007 07:06:08 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Itanium exception handling performance Message-ID: <4hVN+nqs46vE@eisner.encompasserve.org> > I will be sure to keep I64 issues in mind when writing code. Of course the term "exception" is supposed to be a code word that this is an abnormal occurance. Besides hardware designers there are going to be language implementers and even language designers taking their cue from that term and overloading "exception handling" with lots of neat but expensive features. When coding one should not depend on exceptions for "normal" processing. ------------------------------ Date: Wed, 21 Mar 2007 05:04:22 -0800 From: "Tom Linden" Subject: Re: Itanium exception handling performance Message-ID: On Wed, 21 Mar 2007 04:06:08 -0800, Larry Kilgallen wrote: >> I will be sure to keep I64 issues in mind when writing code. > > Of course the term "exception" is supposed to be a code word that this > is an abnormal occurance. Besides hardware designers there are going > to be language implementers and even language designers taking their > cue from that term and overloading "exception handling" with lots of > neat but expensive features. > > When coding one should not depend on exceptions for "normal" processing. Well, there are some exceptions (:-} ) ON ENDFILE BEGIN; /* finished reading the file now start the processing*/ END; -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Wed, 21 Mar 2007 09:19:44 GMT From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) Subject: Re: Kermit Large File Support Message-ID: <00A64EDF.78F5AB2F@SSRL.SLAC.STANFORD.EDU> In article <07030321341363_2020028F@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: > By the way, I've been corresponding with Mr. da Cruz regarding this >stuff, and there's more than a little hope of seeing support for large >files in Kermit for VMS on non-VAX systems (and support for the optional >"Built-in FTP client", albeit not supporting any of the fancy VMS >attribute preservation schemes) in the next pre-release Kermit kit. >(You'll probably get command-line case preservation, too, with SET PROC >/PARS = EXTE.) And, if I didn't break too much, probably in the next >real release, as well. > > I don't know when anything will appear, but I suspect that there will >be an announcment when it does. This is excellent news. Thanks, Steven, for the work you do making this open-source stuff run right on VMS. -- Alan (happy wget user, likes the idea of VMS feature parity in Kermit) ------------------------------ Date: Wed, 21 Mar 2007 10:11:11 +0100 From: Paul Sture Subject: Re: Kermit Large File Support Message-ID: In article <00A64EDF.78F5AB2F@SSRL.SLAC.STANFORD.EDU>, winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) wrote: > In article <07030321341363_2020028F@antinode.org>, sms@antinode.org (Steven > M. Schweda) writes: > > By the way, I've been corresponding with Mr. da Cruz regarding this > >stuff, and there's more than a little hope of seeing support for large > >files in Kermit for VMS on non-VAX systems (and support for the optional > >"Built-in FTP client", albeit not supporting any of the fancy VMS > >attribute preservation schemes) in the next pre-release Kermit kit. > >(You'll probably get command-line case preservation, too, with SET PROC > >/PARS = EXTE.) And, if I didn't break too much, probably in the next > >real release, as well. > > > > I don't know when anything will appear, but I suspect that there will > >be an announcment when it does. > > This is excellent news. Thanks, Steven, for the work you do making this > open-source stuff run right on VMS. My thanks too, Steven. > -- Alan (happy wget user, likes the idea of VMS feature parity in Kermit) Me too on wget; It is a useful tool. I've just realised that I'm more up to date with wget, zip and unzip on VMS than I am on OS X :-) -- Paul Sture ------------------------------ Date: Wed, 21 Mar 2007 10:56:06 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Kermit Large File Support Message-ID: <07032110560636_2020028F@antinode.org> From: Paul Sture > In article <00A64EDF.78F5AB2F@SSRL.SLAC.STANFORD.EDU>, > winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) > wrote: > > > [...] is excellent news. Thanks, Steven, for the work you do making this > > open-source stuff run right on VMS. > My thanks too, Steven. Gratitude is always welcome, and it sure beats the usual rantings and ravings here on science and gods, but you should be careful, now. "Run differently" might be closer to the truth in some cases. (Of course, in some cases, "different" does imply better.) > [...] I've just realised that I'm more up > to date with wget, zip and unzip on VMS than I am on OS X :-) There are definitely some old versions of the Info-ZIP and other products getting shipped with various operating systems. Trying to keep everything up to date everywhere seems like a job for Sisyphus. SMS. ------------------------------ Date: Wed, 21 Mar 2007 10:07:54 -0700 From: DeanW Subject: Re: Problems zipping RBF file Message-ID: <3f119ada0703211007s7d9c0fh371ce677c193d0c2@mail.gmail.com> [Update...] On 3/19/07, David J Dachtera wrote: > DeanW wrote: > Well, Steve Schweda *IS* the ZIP/UNZIP guru these days! > > That said, yes - "stored 0%" means the file *WAS* stored in the archive, but was > not compressed. Er, not exactly. The resulting ZIP file is 1 block, and shows 0 bytes stored at 0% compression. If we ZIP the BCK, it reports "62% deflated"... but comparing file sizes suggests a compression ratio of 40:1. And the input file (RBF) is ~7.8M blocks- yeah, ~3.9GB: -------------------->8 cut here 8<-------------------- LT$2007-03-21.RBF;1 File ID: (234520,10,0) Size: 7831908/7831936 Owner: [CONSULT,SYSTEM] Created: 21-MAR-2007 01:01:25.62 Revised: 21-MAR-2007 02:50:56.80 (2) Expires: Backup: Effective: Recording: File organization: Sequential Shelved state: Online Caching attribute: Writethrough File attributes: Allocation: 7831936, Extend: 2048, Global buffer count: 0, No version limit, Backups disabled Record format: Fixed length 32256 byte records Record attributes: None RMS attributes: None Journaling enabled: None File protection: System:RWED, Owner:RWED, Group:RE, World: Access Cntrl List: None Client attributes: None Total of 1 file, 7831908/7831936 blocks. -------------------->8 cut here 8<-------------------- So, theoretically, this shouldn't work *at all*. Zip 2.32 actually does seem to work with the RBF itself, and I'm told they've successfully extracted the RBF and built a database from it. Scary. I'm going to spend some time today working on the zip/unzip betas that Steve Schwenda referred to... (The issue with BACKUP causing performance issues- I noted that the BACKUP account had DIOLM=4000, for unknown reasons, possibly done by a former system manager so it'd get all the bandwidth it wanted. We cranked that down to 100; waiting for reports from users to see if that helps.) ------------------------------ Date: Wed, 21 Mar 2007 10:20:51 -0700 From: DeanW Subject: Re: Problems zipping RBF file Message-ID: <3f119ada0703211020g7508ab41va5c57a69dbaf3a87@mail.gmail.com> On 20 Mar 2007 14:09:54 -0700, twnews@kittles.com wrote: > I had the exact same problem 2 weeks ago. The RDB backup file > would not zip. It seemed to think it did, but it only placed an empty > place holder in the zip file (no data, no content at all). I thought > all of the same things that are listed here. I figured it would be > easy, so I tried a quick upgrade of zip to the latest version before I > posted here. That fixed it! As I say, "I would rather have it fixed > and not know why, then have it broken (with no clear fix) and know > why!" I am very confident that the newest version of zip will fix > your problems. Just download it and replace your current zip.exe with it. a) Yes, the current zip "works". I did once catch an error message along the lines of "unexpected bytes past EOF"- I didn't capture the exact message- with the older version. b) It *shouldn't* work- my input file is nearly twice the expected capabilities of zip 2.x. More work needs to be done... ------------------------------ Date: Wed, 21 Mar 2007 10:35:35 -0700 From: - Subject: Re: Suggestion for the VMS X-windows server Message-ID: Phillip Helbig---remove CLOTHES to reply wrote: > In article , - writes: > >> Michael Kraemer wrote: >>> - schrieb: >>> >>>> Using VMS as an X server doesn't make a lot of sense these days. > > Why not? > Because the scarce/expensive resources are better off invested in useful work. The GUI stuff (X server) should be moved to a machine designed for GUI. OTOH, I don't know if there'd be much win w/r/t/ Mozilla. My guess is that the web-page cache will still eat into PGFILQUO whether the server is on the VMS box or another machine. Some Mozilla plug-in could be leaking memory; moving to a separate server wouldn't fix that issue. The OP should tune down the browser cache[1]. If it isn't the browser cache, then /definitely/ move the X server to another box. [1] See about:cache for current settings ------------------------------ Date: 21 Mar 2007 08:22:44 +0100 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: system job que manager not running Message-ID: <4600eb54$1@news.langstoeger.at> In article <975b$46003c8b$cef8887a$24877@TEKSAVVY.COM>, JF Mezei writes: >Also, what logical did you change ? Remember that QMAN$MASTER points to a >directory, not a file. Wrong! QMAN$MASTER should point to the master file (containing the info about all the queue managers). eg. "QMAN$MASTER" [exec] = "DISK$VMSSYS:[VMS$COMMON.SYSEXE]QMAN$MASTER.DAT" I think you confused it with the parameter for starting a queue manager $ START/MANAGER[/NAME=SYS$PRINT_MANAGER/ON=*] [dirspec] just my 0.02 -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Wed, 21 Mar 2007 07:44:06 -0000 From: "chris" Subject: Re: system job que manager not running Message-ID: <4600defe$1_1@glkas0286.greenlnk.net> apologies for being a bit vague on the porblem description. The problem was that unknown to me a 7.3version vms node was running on our cluster of 40 odd 7.2 nodes. This node wasnt confiured properly in the cluster so when i ran the logical .com file (which also contained DSE QMAN$MASTER logical) to change a logical on all the 7.2 nodes, it tried to set up the que logical on the rougue node. When we started the queues we kept getting bad parameter errors. Simply shutting this 7.3 box down and rerunning the logical file and starting the queues sorted it. "Peter 'EPLAN' LANGSTOeGER" wrote in message news:4600eb54$1@news.langstoeger.at... > In article <975b$46003c8b$cef8887a$24877@TEKSAVVY.COM>, JF Mezei > writes: >>Also, what logical did you change ? Remember that QMAN$MASTER points to a >>directory, not a file. > > Wrong! > QMAN$MASTER should point to the master file (containing the info > about all the queue managers). > > eg. > > "QMAN$MASTER" [exec] = "DISK$VMSSYS:[VMS$COMMON.SYSEXE]QMAN$MASTER.DAT" > > I think you confused it with the parameter for starting a queue manager > > $ START/MANAGER[/NAME=SYS$PRINT_MANAGER/ON=*] [dirspec] > > just my 0.02 > -- > Peter "EPLAN" LANGSTOEGER > Network and OpenVMS system specialist > E-mail peter@langstoeger.at > A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: 21 Mar 2007 05:08:55 -0700 From: bob@instantwhip.com Subject: US looking to merge with Canada, Mexico! Message-ID: <1174478935.462771.318800@l77g2000hsb.googlegroups.com> one step closer to global government ... and the rapture ... http://www.worldnetdaily.com/news/article.asp?ARTICLE_ID=54796 ------------------------------ Date: 21 Mar 2007 05:10:27 -0700 From: bob@instantwhip.com Subject: Re: US looking to merge with Canada, Mexico! Message-ID: <1174479027.106296.313330@n76g2000hsh.googlegroups.com> On Mar 21, 8:08 am, b...@instantwhip.com wrote: > one step closer to global government ... and the rapture ... > > http://www.worldnetdaily.com/news/article.asp?ARTICLE_ID=54796 hey J.F., this means you may soon becoming an american ... :) ------------------------------ Date: 21 Mar 2007 07:53:43 -0700 From: "Rich Jordan" Subject: Re: US looking to merge with Canada, Mexico! Message-ID: <1174488823.370005.274510@o5g2000hsb.googlegroups.com> Please stop posting this kind of stuff in COMP.OS.VMS. Its off topic, it fills the archives with off topic clutter, and makes this newsgroup (as has happened to so many others that get buried by off-topic flamewars) hostile to those looking for information about VMS and related products. There are appropriate venues and newsgroups available for subjects like this one, global warming, politics, etc. Don't screw up this one, please. ------------------------------ Date: 21 Mar 2007 00:15:21 -0700 From: prahlad63@gmail.com Subject: vme data transactios Message-ID: <1174461321.620594.59030@l77g2000hsb.googlegroups.com> I Have PPC 7410 board with TUNDRA asa vme data transactions pls tell me how to transfer the data through the tundra to vme bus ------------------------------ Date: 21 Mar 2007 05:00:03 -0700 From: "tadamsmar" Subject: Which tapes for 3R-A0692-AA drive? Message-ID: <1174478403.377591.278830@n76g2000hsh.googlegroups.com> Does anyone know which types of tapes will the 3R-A0692-AA read and/or write? It's listed as a 20/40 GB DDS4. But will it R/W any of DDS1 thru DDS3? I can't find much about the specs on the web. Thanks! ------------------------------ Date: 21 Mar 2007 05:00:04 -0700 From: "tadamsmar" Subject: Which tapes for 3R-A0692-AA drive? Message-ID: <1174478404.536048.167190@o5g2000hsb.googlegroups.com> Does anyone know which types of tapes will the 3R-A0692-AA read and/or write? It's listed as a 20/40 GB DDS4. But will it R/W any of DDS1 thru DDS3? I can't find much about the specs on the web. Thanks! ------------------------------ Date: Wed, 21 Mar 2007 10:01:04 +0100 From: Paul Sture Subject: Re: Willing to bet this is Windows at its best Message-ID: In article , Kilgallen@SpamCop.net (Larry Kilgallen) wrote: > In article , Maverick > writes: > > Bob Willard wrote: > >> tomarsin2015@comcast.net wrote: > > >>> That's what happened to a computer technician reformatting a disk > >>> drive at the Alaska Department of Revenue. While doing routine > >>> maintenance work, the technician accidentally deleted applicant > >>> information for an oil-funded account - one of Alaska residents' > >>> biggest perks - and mistakenly reformatted the backup drive, as well. > > >> Even the most dedicated M$ haters should not be able to blame WinDuhs for > >> this goof. This is an obvious case of fumble-fingers at work; multiple > >> f-f at that. > > > > But do you know any other operating system that would allow this? > > At the first site where all of my work was on VMS, on the first day > I was there, an operator did a DSC backup in the wrong direction, > wiping out the current data with the stale data. A similar mistake is still a possibility with VMS standalone BACKUP. One alternative is to create a (fairly minimal) boot disk containing customer/site/cluster specific procedures which do appropriate checks on volume information and perform such backups on the operator's behalf. Another alternative could be to drive the console via a console management package and a script, but the thought of having to parse console output gives me cold feet in the context of reliable backups. -- Paul Sture ------------------------------ Date: 21 Mar 2007 03:59:07 -0700 From: "Ramon F Herrera" Subject: Re: Willing to bet this is Windows at its best Message-ID: <1174474747.845420.281940@n59g2000hsh.googlegroups.com> On Mar 20, 10:32 am, Bob Willard wrote: > tomarsin2...@comcast.net wrote: > > Oops! Techie wipes out $38 billion fund > > Keystroke mistake deletes data forAlaska'soil-funded account > > > JUNEAU,Alaska- Perhaps you know that sinking feeling when a single > > keystroke accidentally destroys hours of work. Now imagine wiping out > > a disk drive containing an account worth $38 billion. > > > That's what happened to acomputertechnician reformatting a disk > > drive at theAlaskaDepartmentofRevenue. While doing routine > > maintenance work, the technician accidentally deleted applicant > > information for an oil-funded account - one ofAlaskaresidents' > > biggest perks - and mistakenly reformatted the backup drive, as well. > > > There was still hope, until thedepartmentdiscovered its third line > > of defense, backup tapes, were unreadable > > > "Nobody panicked, but we instantly went into planning for the worst- > > case scenario," said Permanent Fund Dividend Division Director Amy > > Skow. Thecomputerfoul-up last July would end up costing the > >departmentmore than $200,000. > > > Over the next few days, as thedepartment, the division and > > consultants from Microsoft Corp. and Dell Inc. labored to retrieve the > > data, it became obvious the worst-case scenario was at hand. > > > Nine months worth of information concerning the yearly payout from the > >AlaskaPermanent Fund was gone: some 800,000 electronic images that > > had been painstakingly scanned into the system months earlier, the > > 2006 paper applications that people had either mailed in or filed over > > the counter, and supporting documentation such as birth certificates > > and proof of residence. > > > And the only backup was the paperwork itself - stored in more than 300 > > cardboard boxes. > > > "We had to bring that paper back to the scanning room, and send it > > through again, and quality control it, and then you have to have a way > > to link that paper to that person's file," Skow said. > > > Half a dozen seasonal workers came back to assist the regular division > > staff, and about 70 people working overtime and weekends re-entered > > all the lost data by the end of August. > > > "They were just ready, willing and able to chip in and, in fact, we > > needed all of them to chip in to get all the paperwork rescanned in a > > timely manner so that we could meet our obligations to the public," > > Skow said. > > Even the most dedicated M$ haters should not be able to blame WinDuhs for > this goof. This is an obvious case of fumble-fingers at work; multiple > f-f at that. > -- > Cheers, Bob The whole issue is embedded in the IT culture: the biggest lie Microsoft has propagated is that any retarded with half a brain can be a computer administrator. Good, solid operating systems tend to complement good, competent professionals, and vice versa. -Ramon ------------------------------ Date: 21 Mar 2007 07:38:58 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Willing to bet this is Windows at its best Message-ID: In article , Paul Sture writes: > > A similar mistake is still a possibility with VMS standalone BACKUP. > We had that problem several times when standalone BACKUP replaced standalone DSC. ------------------------------ End of INFO-VAX 2007.160 ************************