INFO-VAX Mon, 17 Nov 2008 Volume 2008 : Issue 623 Contents: 150 year Re: 150 year Re: 150 year RE: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: Bypass mount/system request at boot time? Re: Emulation Re: Emulation Re: Fibre channel driver documentation In-house testing and patches Re: In-house testing and patches Re: In-house testing and patches Re: In-house testing and patches Re: In-house testing and patches RE: OVMS Integrity BASIC LTU Getting only 1 user at cost of $2400.00??? Re: strange disk state and corrupt new mail file Re: strange disk state and corrupt new mail file Re: VMS, HP and the recession ---------------------------------------------------------------------- Date: Mon, 17 Nov 2008 08:13:36 +0100 From: "The Mip" Subject: 150 year Message-ID: $set ver $ crea foobar.foo $ wr f$file("foobar.foo","bdt") 17-NOV-1858 00:00:00.00 $ wr f$time() 17-NOV-2008 07:53:57.56 150 years since i backed up that file :) - the_mip Lets celebrate with a good old 1 : http://h71000.www7.hp.com/wizard/wiz_2315.html ------------------------------ Date: Mon, 17 Nov 2008 02:48:17 -0500 From: JF Mezei Subject: Re: 150 year Message-ID: <000cfec9$0$12246$c3e8da3@news.astraweb.com> The Mip wrote: > $set ver > $ crea foobar.foo > $ wr f$file("foobar.foo","bdt") > 17-NOV-1858 00:00:00.00 > $ wr f$time() > 17-NOV-2008 07:53:57.56 > > 150 years since i backed up that file :) This is normal since the backup date is all zeros, and all zeros means the "start of history" date for VMS which is 17-NOV-1858. ------------------------------ Date: Mon, 17 Nov 2008 05:38:54 -0800 (PST) From: AEF Subject: Re: 150 year Message-ID: On Nov 17, 3:13=A0am, "The Mip" wrote: > $set ver > $ crea foobar.foo > $ wr f$file("foobar.foo","bdt") > 17-NOV-1858 00:00:00.00 > $ wr f$time() > 17-NOV-2008 07:53:57.56 > > 150 years since i backed up =A0that file :) > > - the_mip > > Lets celebrate with a good old 1 :http://h71000.www7.hp.com/wizard/wiz_23= 15.html And 140 years since you lost the tape! :-) AEF ------------------------------ Date: Mon, 17 Nov 2008 09:10:30 -0500 From: "Peter Weaver" Subject: RE: 150 year Message-ID: > -----Original Message----- > From: The Mip [mailto:Nospam@nowhere.au.dk] > Sent: November 17, 2008 2:14 AM > To: Info-VAX@Mvb.Saic.Com > Subject: 150 year > > $set ver > $ crea foobar.foo > $ wr f$file("foobar.foo","bdt") > 17-NOV-1858 00:00:00.00 > $ wr f$time() > 17-NOV-2008 07:53:57.56 > > 150 years since i backed up that file :) > > - the_mip > > Lets celebrate with a good old 1 : > http://h71000.www7.hp.com/wizard/wiz_2315.html Ever year on this date my heart skips a beat when I first log in on the system and I see the magical string 17-NOV-. My first job was working with the ADMINS/V32 package and anytime I saw the 17-NOV-1858 it meant hours of debugging. Peter Weaver www.weaverconsulting.ca www.openvmsvirtualization.com www.vaxvirtualization.com www.alphavirtualization.com Winner of the 2007 OpenVMS.org Readers' Choice Award for System Management/Performance ------------------------------ Date: Mon, 17 Nov 2008 07:24:58 -0800 (PST) From: AEF Subject: Re: 150 year Message-ID: <6942dd68-2440-4226-b805-399a89a03c9a@g17g2000prg.googlegroups.com> On Nov 17, 3:13=A0am, "The Mip" wrote: > $set ver > $ crea foobar.foo > $ wr f$file("foobar.foo","bdt") > 17-NOV-1858 00:00:00.00 > $ wr f$time() > 17-NOV-2008 07:53:57.56 > > 150 years since i backed up =A0that file :) > > - the_mip > > Lets celebrate with a good old 1 :http://h71000.www7.hp.com/wizard/wiz_23= 15.html So that's fine, but why did VMS adopt this (the Modified Julian Day)? It doesn't say. It doesn't answer the question. AEF ------------------------------ Date: Mon, 17 Nov 2008 10:40:45 -0500 From: "Richard B. Gilbert" Subject: Re: 150 year Message-ID: AEF wrote: > On Nov 17, 3:13 am, "The Mip" wrote: >> $set ver >> $ crea foobar.foo >> $ wr f$file("foobar.foo","bdt") >> 17-NOV-1858 00:00:00.00 >> $ wr f$time() >> 17-NOV-2008 07:53:57.56 >> >> 150 years since i backed up that file :) >> >> - the_mip >> >> Lets celebrate with a good old 1 :http://h71000.www7.hp.com/wizard/wiz_2315.html > > So that's fine, but why did VMS adopt this (the Modified Julian Day)? > It doesn't say. It doesn't answer the question. > > AEF There is an explanation of sorts; something to do with obsoleting star charts or something like that. There is a detailed explanation at: http://h71000.www7.hp.com/wizard/wiz_2315.html As the representation used by VMS will not overflow for more than 3,000 years (it may be 30,000 (I don't recall)) there is no urgent reason to fix the problem! If anybody still cares 3,000 or 30,000 years from now, they can adopt whatever solution(s) meet their needs. ------------------------------ Date: Mon, 17 Nov 2008 08:23:29 -0800 From: "Tom Linden" Subject: Re: 150 year Message-ID: On Sun, 16 Nov 2008 23:13:36 -0800, The Mip wrote: > $set ver > $ crea foobar.foo > $ wr f$file("foobar.foo","bdt") > 17-NOV-1858 00:00:00.00 > $ wr f$time() > 17-NOV-2008 07:53:57.56 > > 150 years since i backed up that file :) > > - the_mip > > Lets celebrate with a good old 1 : > http://h71000.www7.hp.com/wizard/wiz_2315.html > > Here is an interesting addendum, see the comments on the determination of Easter. http://www.kednos.com/calendar.html -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: 17 Nov 2008 12:09:55 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 150 year Message-ID: In article <6942dd68-2440-4226-b805-399a89a03c9a@g17g2000prg.googlegroups.com>, AEF writes: > > So that's fine, but why did VMS adopt this (the Modified Julian Day)? > It doesn't say. It doesn't answer the question. Prior to first ship. ------------------------------ Date: 17 Nov 2008 12:11:48 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 150 year Message-ID: In article , "Richard B. Gilbert" writes: > > As the representation used by VMS will not overflow for more than 3,000 > years (it may be 30,000 (I don't recall)) there is no urgent reason to > fix the problem! > > If anybody still cares 3,000 or 30,000 years from now, they can adopt > whatever solution(s) meet their needs. IIRC the internal representation is good through year 32767. The formatting routines are good through year 9999. Fixes to the formatting routines have been promised prior to year 10000. 3000 years from now is not a problem for VMS. ------------------------------ Date: Mon, 17 Nov 2008 10:56:47 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Bypass mount/system request at boot time? Message-ID: In article <4920EB7D.3020700@vsm.com.au>, Jeremy Begg writes: > >>$ MOUNT/ASSIST is normally appropriate at mount time, but if you have > >>shadow sets you may want to consider /POLICY=REQUIRE_MEMBERS as well, > >>since this gives you a chance to reject the mounting of a single > >>member when it may be possible that the single member that is seen > >>at boot is not the one with the most current data. > > ... > > Having said that, I've never had the problem of a less-than-current disk > > being mounted. While I can see how it can happen, I think it must be a > > rather rare occurrence. Has anyone ever seen it happen, or seen that it > > WOULD HAVE happened had /POLICY=REQUIRE_MEMBERS not been in effect? > 1. Six months previously, the data disk in VAX "A" died. VMS shadowing did > its thing and the application continued to run, relying on the copy on > the disk in VAX "B". No one noticed, because there was no interruption > to service. ("Yay!" for VMS -- or maybe not.) > > 2. On the weekend before I was called in, there was a site power failure > which caused the "dead" disk to come back to life. > > 4. VAX "A" rebooted first, mounted the shadow set (using only the member > local to it) and then there was another power failure. > > 5. Both VAXes rebooted but by this time VAX "A" had the master copy of the > data disk and it was then quietly shadow-copied to VAX "B". > > 6. Users come in after the weekend to find wierdness. Yes, that's one way it can happen. Another: A dies, B continues on. B dies. A comes up. In my cluster, I have the following code in SYLOGICALS.COM: $ WSO := WRITE SYS$OUTPUT $ IF .NOT. F$GETSYI("CLUSTER_MEMBER") .OR. - F$GETSYI("STARTUP_P1") .NES. " " THEN EXIT $ WSO "" $ WSO "" $ WSO "waiting for cluster-wide logicals" $ WSO "" $ CWL_COUNT = 150 $CWL_WAIT: $ IF .NOT. F$GETSYI("CWLOGICALS") $ THEN $ SHOW TIME $ WAIT 0:0:2 $ CWL_COUNT = CWL_COUNT - 1 $ IF CWL_COUNT .EQ. 0 $ THEN $ WSO "" $ WSO "Warning: cluster-wide logicals are not defined" $ EXIT $ ENDIF $GOTO CWL_WAIT $ ENDIF $ IF F$TRNLNM("CLUSTER_UP") $ THEN $ ELSE $ WSO "" $ WSO "" $ WSO "waiting to make sure all cluster members are available" $ WSO "" $ UP_COUNT = 12 $UP_WAIT: $ SHOW TIME $ DANEEL_UP = F$TRNLNM("DANEEL_UP") $ GLADIA_UP = F$TRNLNM("GLADIA_UP") $ ELIJAH_UP = F$TRNLNM("ELIJAH_UP") $ IF (DANEEL_UP .AND. GLADIA_UP .AND. ELIJAH_UP) $ THEN $ DEFINE/TABLE=LNM$SYSCLUSTER CLUSTER_UP TRUE $ ELSE $ WAIT 0:0:10 $ UP_COUNT = UP_COUNT - 1 $ IF UP_COUNT .EQ. 0 $ THEN $ WSO "" $ WSO "Warning: Not all expected cluster members are available!" $ GOTO CLUSTER_CHECKED $ ENDIF $GOTO UP_WAIT $ ENDIF $CLUSTER_CHECKED: $ ENDIF $MOUNT_USER_DISK: $ WSO "" $ MOUNT/CLUSTER/NOASSIST/NOREBUILD - DSA510:/SHADOW=($22$DKA500:,$44$DKA400:) USER $ IF F$GETDVI("DISK$USER","MNT") $ THEN $ FILE := DISK$USER:[SYSTEM.MANAGER]CLUSTER_WIDE_DEFS.COM $ IF F$SEARCH(FILE) .NES. "" THEN @ 'FILE' $ ELSE $ WSO "" $ WSO "Warning: DISK$USER not yet mounted!" $ WAIT 0:0:10 $GOTO MOUNT_USER_DISK $ ENDIF The main idea is to avoid (full) shadow copies just because one member of the cluster came up a few seconds too late. On the other hand, if a member doesn't come up at all, or if a disk doesn't work, I want the one remaining member to mount---that's one of the advantages of volume shadowing. ------------------------------ Date: Mon, 17 Nov 2008 00:14:58 -0800 (PST) From: PR Subject: Re: Emulation Message-ID: On Nov 16, 11:51=A0pm, Wilm Boerhout wrote: > PR vaguely mentioned on 17-11-2008 6:19: > > [snip] > > > That is actuallly a fine plan- except the previous message I replied > > to was suggesting pulling the physcial network plug for the host > > Windows machine to avoid having to keep it patched and up to date. > > > As long as you are willing to take on yet another Windows box to keep > > up to date, and are willing to keep Windows administrators from doing > > silly things to the box which mess up the emulation, it reasonable. > > > Also, with your plan, you have no file by file restore capability. > > > Although I admit, I would tend to do it this way, or else write to a > > "virtual" tape drive that in reality is a disk file. > > You're absolutely right Paul. That is why in the "Windows unconnected" > situation, I recommend either a local tape drive (could be iSCSI to make > it usable on more machines), or snapshot clones of drives with virtual > tapes on them via a SAN solution. Like Stan says, it requires > coordination between the VMS backup schedule and the events in the > Windows world, but once you've established an overall schedule it will > run forever. > > Furthermore, a file by file restore is usually available from the last > backup set, because that will stay "on line" to VMS. If you want less > recent file restores, you need to restore an older set from archived > media to Windows first. > > /Wilm That was kind of the issue in the first place. When you pay $35K for high end tape drives sitting in a high end library behind a high end virtual tape library, you sort of do not want to use some standalone tape drive on a PC class machine, nor do you really want to give that PC uncoordinated access to the tape library. (Tivoli can coordinate access, and perform 'Lan Free' backups.) And that is not uncommon in today's shops by the way. We manage so much storage, that enterprise wide backup with disaster recovery control is almost an absolute necessity. Any machine that doesn't fit into that well is not looked on with favor. Soon -Paul ------------------------------ Date: Mon, 17 Nov 2008 19:40:49 +0100 From: Wilm Boerhout Subject: Re: Emulation Message-ID: <4921bac0$0$8601$ba620dc5@nova.planet.nl> PR vaguely mentioned on 17-11-2008 9:14: > On Nov 16, 11:51 pm, Wilm Boerhout wrote: >> [snip] > That was kind of the issue in the first place. > > When you pay $35K for high end tape drives sitting in a high end > library behind a high end virtual tape library, you sort of do not > want to use some standalone tape drive on a PC class machine, nor do > you really want to give that PC uncoordinated access to the tape > library. (Tivoli can coordinate access, and perform 'Lan Free' > backups.) > > And that is not uncommon in today's shops by the way. We manage so > much storage, that enterprise wide backup with disaster recovery > control is almost an absolute necessity. Any machine that doesn't fit > into that well is not looked on with favor. Well, I guess for every solution proposed there is a shop where the solution doesn't fit :-) I'd rather work the other way 'round: look at the shop and discuss which solution will fit. As I said before, we usually work something out. And remember: Cheap, Secure, Easy, pick any two, but not three... /Wilm ------------------------------ Date: Mon, 17 Nov 2008 07:51:29 +0100 From: Jur van der Burg <"lddriver at digiater dot nl"> Subject: Re: Fibre channel driver documentation Message-ID: <49211471$0$201$e4fe514c@news.xs4all.nl> > If the driver does recognize a device coming online, then perhaps > Jeff's suggestion of disabling and then re-enabling the port will do > the trick. I will have to try it this week. That should work. > Are the FC extension commands documented anywhere other than the > listings? I did an SDA> FC HELP and that produces an interesting set > of commands, but nothing to describe what they do or what they > display. No, FC HELP or the sources are all you can get. It's internal use only, so there's no documentation. But SHOW RING was previously dumping hex data, and now it can show way more than it could in the past. I created that just because I needed it to troubleshoot a problem, and it saved me a lot of time. Jur. FrankS wrote, On 16-11-2008 21:00: > On Nov 16, 8:15 am, Jur van der Burg <"lddriver at digiater dot nl"> > wrote: >> There's no documentation other than the listings. If a device comes >> online then the driver will automaticaaly login. You can display >> what's going on the the FC extension in SDA, like FC SHOW RING [/FULL] >> and/or /SLOW. > > Do you happen to have some listings you'd like to share? :-) > > If the driver does recognize a device coming online, then perhaps > Jeff's suggestion of disabling and then re-enabling the port will do > the trick. I will have to try it this week. > > Are the FC extension commands documented anywhere other than the > listings? I did an SDA> FC HELP and that produces an interesting set > of commands, but nothing to describe what they do or what they > display. ------------------------------ Date: Mon, 17 Nov 2008 05:05:52 -0500 From: JF Mezei Subject: In-house testing and patches Message-ID: <000d1efe$0$12304$c3e8da3@news.astraweb.com> While picking up leaves, I got to think... (it happens sometimes). In the 1980s, DEC had the largest in-house network. It used its own hardware and osftware to run the corporation. It used its own ALL-IN-1 (and mail) to have the in-house email facility. It had its own applications using FMS and whatever. As customers, we didn't see many patches flowing to us. Then comes Bob GQ Palmer who torched the company, ditched DEC's own products and installed "industry standard" stuff. One has to admit that quality control since the 1990s seems to have gone down. (just look at the TCPIP services product). Out of curiosity, is it possible that the high quality of VMS products/software we saw in the 1980s was due to Digital using that very software in house and engineers knew that they had to design something to be used in a 20,000 node environment with high scrutiny over security etc and the end product , by being ready to run inside Digital ,was also ready and tested to run on most customer environmnents. But once Palmer started to dismantle the original Digital Network (completely gone with Compaq and HP), engineers no longer had that large scale in-house test bed whcih generated much internal feedback on problems and had to rely on the small labs without much feedback before the products were signed, sealed and distributed to customers. Why should they improve TPU when they use windows to manage code ? Why should they improve MAIL when they use OUTLOOK for corporate mail ? Back when Digital was using its own products to run the business, there was a lot of motivation to improve the software (not only from customers, but also from internal needs). This is an aspect I have not seen discussed in the couple of books I have read about DEC. Am I totally off trakc in my separate universe ? Or does some of it actually make sense ? ------------------------------ Date: Mon, 17 Nov 2008 10:40:11 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: In-house testing and patches Message-ID: JF Mezei wrote: > Why should they improve MAIL when they > use OUTLOOK for corporate mail ? Why should they improve MAIL when no (real) customer uses it for (real) corporate mail ??? (What *could* be done to MAIL is to polish some of the funtions to automate batch oriented mail with attachements and such. That is, build some tool that packages MIME.EXE, SSF, S-MIME and those tools together into something that runs out-of-the-box...) There is absolutely no reason to put money and resources into the interactive part of MAIL, there is no market for that. (Note, hobbyists does not count as "markets", and probably not VMS-admins either)... > Am I totally off trakc in my separate universe ? As usual, yes. Jan-Erik. ------------------------------ Date: Mon, 17 Nov 2008 12:44:26 +0100 From: Michael Kraemer Subject: Re: In-house testing and patches Message-ID: JF Mezei schrieb: > While picking up leaves, I got to think... (it happens sometimes). I always thought Canada would be buried unter several meters of snow at this time of the year ... > Then comes Bob GQ Palmer who torched the company, ditched DEC's own > products and installed "industry standard" stuff. I'd rather think he tried to clean up the mess the 1980's DEC management had created. > One has to admit that quality control since the 1990s seems to have gone > down. (just look at the TCPIP services product). IIRC UCX predates the Palmer era, and quality wasn't superior already in the early 1990s. > Out of curiosity, is it possible that the high quality of VMS > products/software we saw in the 1980s was due to Digital using that very > software in house and engineers knew that they had to design something > to be used in a 20,000 node environment with high scrutiny over security > etc and the end product , by being ready to run inside Digital ,was also > ready and tested to run on most customer environmnents. I'd rather think software requirements were much lower back then. Today's security issues were almost non-existent in the 1980s, as were requirements for a sophisticated GUI, all kinds of multimedia attachments and probably even I18N (because IT was restricted to professionals who spoke English anyway). > But once Palmer started to dismantle the original Digital Network > (completely gone with Compaq and HP), engineers no longer had that large > scale in-house test bed whcih generated much internal feedback on > problems and had to rely on the small labs without much feedback before > the products were signed, sealed and distributed to customers. > > Why should they improve TPU when they use windows to manage code ? Why > should they improve MAIL when they use OUTLOOK for corporate mail ? Back > when Digital was using its own products to run the business, there was a > lot of motivation to improve the software (not only from customers, but > also from internal needs). Following this logic (lack of inhouse testing leads to inferior products) one would assume that M$ does not use Ouchlook internally. ------------------------------ Date: Mon, 17 Nov 2008 09:09:06 -0500 From: Bob Willard Subject: Re: In-house testing and patches Message-ID: Michael Kraemer wrote: > JF Mezei schrieb: > >> Then comes Bob GQ Palmer who torched the company, ditched DEC's own >> products and installed "industry standard" stuff. > > > I'd rather think he tried to clean up the mess > the 1980's DEC management had created. I can't think of any mess that GQ Bob cleaned up. His primary effort was to sell everything that wasn't nailed down and, while executing that non-vision, to soak up millions of salary/bonus bucks. Yet another empty, albeit tailored and expensive, suit. -- Cheers, Bob ------------------------------ Date: Mon, 17 Nov 2008 07:51:19 -0800 (PST) From: DaveG Subject: Re: In-house testing and patches Message-ID: On Nov 17, 4:05=A0am, JF Mezei wrote: > While picking up leaves, I got to think... (it happens sometimes). > > In the 1980s, DEC had the largest in-house network. It used its own > hardware and osftware to run the corporation. It used its own ALL-IN-1 > (and mail) to have the in-house email facility. It had its own > applications using FMS and whatever. > > As customers, we didn't see many patches flowing to us. > > Then comes Bob GQ Palmer who torched the company, ditched DEC's own > products and installed "industry standard" stuff. > > One has to admit that quality control since the 1990s seems to have gone > down. (just look at the TCPIP services product). > > Out of curiosity, is it possible that the high quality of VMS > products/software we saw in the 1980s was due to Digital using that very > software in house and engineers knew that they had to design something > to be used in a 20,000 node environment with high scrutiny over security > etc and the end product , by being ready to run inside Digital ,was also > ready and tested to run on most customer environmnents. > > But once Palmer started to dismantle the original Digital Network > (completely gone with Compaq and HP), engineers no longer had that large > scale in-house test bed whcih generated much internal feedback on > problems and had to rely on the small labs without much feedback before > the products were signed, sealed and distributed to customers. > > Why should they improve TPU when they use windows to manage code ? Why > should they improve MAIL when they use OUTLOOK for corporate mail ? Back > when Digital was using its own products to run the business, there was a > lot of motivation to improve the software (not only from customers, but > also from internal needs). > > This is an aspect I have not seen discussed in the couple of books I > have read about DEC. > > Am I totally off trakc in my separate universe ? Or does some of it > actually make sense ? Gamma quadrant maybe. Separate universe - not sure. While I was ridding the gutters of the leaves yesterday, what I thought about was "don't fall off the ladder." What happened to DEC is considered, by many, ancient history. Plenty of water has flowed under the bridge since 10 years ago. ------------------------------ Date: Mon, 17 Nov 2008 12:55:03 +0000 From: "Main, Kerry" Subject: RE: OVMS Integrity BASIC LTU Getting only 1 user at cost of $2400.00??? Message-ID: <9D02E14BC0A2AE43A5D16A4CD8EC5A593ED97FBD6B@GVW1158EXB.americas.hpqcorp.net> > -----Original Message----- > From: Arne Vajh=F8j [mailto:arne@vajhoej.dk] > Sent: November 16, 2008 9:26 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: OVMS Integrity BASIC LTU Getting only 1 user at cost of > $2400.00??? > > Main, Kerry wrote: > >> From: Arne Vajh=F8j [mailto:arne@vajhoej.dk] > >> Main, Kerry wrote: > >>>> From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca] > >>>> Jan-Erik S=F6derholm wrote: > >>>>> The SPD (Software Product Description) for HP BASIC is > >>>>> reasonable clear on the licensing options. In IA64, the > >>>>> "Concurrent Use License" is the only option available, > >>>> Then $2400 for a single concurrent use is pretty expensive. > >>>> > >>>> I know that HP apologists will point to DSPP where compilers are > dirt > >>>> cheap. But for people who do development in-house, they don't > qualify > >>>> for DSPP and forcing them to pay those horrendous prices is not > right. > >>> So I guess the Enterprise Oracle licensing at $40K USD/cpu (not > system) > >>> or BEA at $10K per cpu must really upset you then? > >>> > >>> :-) > >> That is for production server stuff. > >> > >> AFAIK then Oracle development tools are completely free. > > > > At the end of the day, its one Oracle bill for whoever is paying. > > It is often two bills going to different departments and > different budgets (if not different companies). > > Arne No, that is not usually the case. The CIO usually has both Development and Prod budget responsibilities. If not, then that company is in serious trouble as there is no single throat to choke from a CEO perspective. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-254-8911 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Mon, 17 Nov 2008 10:42:39 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: strange disk state and corrupt new mail file Message-ID: In article <001279a4$0$9211$c3e8da3@news.astraweb.com>, JF Mezei writes: > For the question "what could have caused this". > > user edits a file called "MAIL.MAI", types nothing in it and then saves > it. it creates a sequential file MAIL.MAI;2 and from that point on, MAIL > will try to write to ;2 and fail. Definitely didn't happen! ------------------------------ Date: Mon, 17 Nov 2008 06:55:23 -0500 From: JF Mezei Subject: Re: strange disk state and corrupt new mail file Message-ID: <000d38b3$0$12289$c3e8da3@news.astraweb.com> Phillip Helbig---remove CLOTHES to reply wrote: > Definitely didn't happen! > If MAIL, for some reason, would have created a new version of MAIL.MAI (first one locked or whatever), that second version would have been properly created as an indexed file and would have contained at least 1 message (the message which triggered mail to create that new MAIL.MAI) If the user didn't edit MAIL.MAI, he could have simply renamed some other file to MAIL.MAI just to cause you trouble. ------------------------------ Date: Mon, 17 Nov 2008 07:36:17 -0500 From: "Richard B. Gilbert" Subject: Re: VMS, HP and the recession Message-ID: David J Dachtera wrote: > Arne Vajhøj wrote: >> Richard Maher wrote: >>>> I think that is correct. >>>> >>>> Most of the VMS revenue must come from support and replacement >>>> boxes for existing systems. >>> Ah, that would explain why Ann McQuaid's lackeys keep getting her to spend >>> all of the development budget on pet projects that are obviously of no use >>> to these "existing systems", whilst steadfastly refusing to provide the same >>> loyal customers with the means of *integrating* these VMS systems into their >>> web-facing architecture, or even just to upgrade/modernize these systems >>> with a simple GUI. >>> >>> Yeah, makes perfect cents :-( >> I guess it makes perfect sense for HP to invest in the pet projects >> they consider instead of the pet projects you consider useful. > > Exactly the point. VMS development is being driven by something other > than customer demand, as we have witnessed. Hence, VMS's slow demise, as > we continue to witness. > >>>> Given what VMS systems are usually used for, then those existing >>>> system will continue unless the company cease to exist. >>> No, I think you'll find that many such systems are being turned-off (for the >>> last time) quite regularly. >> The number of VMS systems are decreasing. But they are not easy targets >> for cost cuts, because 1) they are business critical > > Still replaceable. reference: the Healthcare market, formerly a staunch > VMS stronghold, now being moved to (mostly non-HP) UN*X, thanx to HP. > >> 2) it takes time >> and cost money to migrate to another platform. If it was easy to move >> off VMS, then it probably would have been done already. > > It has been and is being done, even as you read this as healthcare sites > abandon a platform no longer supported by the ISVs. The cost of > transition is considered irrelevant compared to the risk of stagnating > at the ISVs' last supported VMS releases. > > Sorry, "sunshine" - VMS's fate is all but sealed. The handwriting has been on the wall and clearly visible for at least the last thirteen years! I'll be running VMS as long as my hardware lasts but . . . . Some people insisted "it's just graffiti, pay no attention"! It wasn't "just graffiti"! -- draco vulgaris ------------------------------ End of INFO-VAX 2008.623 ************************