INFO-VAX Sat, 03 Mar 2007 Volume 2007 : Issue 124 Contents: Re: Canadian OpenVMS Seminar (07.02.20) Re: Cluster connection lost when one link fails? Re: History of VMS and related operating systems Re: Oracle moves to per-chip licencing SCSI disk firmware update question Re: SCSI disk firmware update question Re: SCSI disk firmware update question Re: Wanted: MicroVAX I / VAXstation I owners ---------------------------------------------------------------------- Date: Sat, 3 Mar 2007 16:45:14 -0000 From: "John Wallace" Subject: Re: Canadian OpenVMS Seminar (07.02.20) Message-ID: <12uj9h1c9qom063@corp.supernews.com> "Robert Deininger" wrote in message news:rdeininger-0203070859270001@dialup-4.233.149.95.dial1.manchester1.level 3.net... Thanks for your time in continuing the dialog(ue); I hope others find it as useful as I do. > The marketing folks mostly don't understand the technical details, so they > can't describe them satisfactorily. What you really want is for technical > folks to take the time to explain the details to non-experts, and then > have the marketing folks make it presentable (without making it wrong) and > then work to make sure everyone sees the information. > Sounds about right. HP are expecting customers to make purchasing decisions based on this kind of info, so if it exists, why not have it in a ready-digested form for folks (customers, employees, etc) who care about this kind of thing? > topic]. AFAIK, no HP marketing folks pay attention to this newsgroup, so > your message isn't getting through. Maybe HP marketing don't read here, but some people who should be important to HP marketing read here. They're called customers (or maybe ex-customers, or more valuably, prospective customers). And some HP folk who do talk to customers read and contribute here, which is surely much appreciated; maybe HP marketing could usefully listen to their input too. > I'm not a marketeer, and I have neither the time nor the inclination to > dig through other CPU specs and argue the benefits. Understood, same here. Right now, wading through inches of Itanium vs AMD64 stuff isn't top of my priorities, much though I might love to, especially when some folks in HP have (one would hope) already analysed the same info and produced a "technical summary" which had some level of credible content, in order to (continue to) justify the "Itanium not x86-64" decision. If folks doing that summary choose not to share that info inside HP, and particularly choose not to share it with the HP people who do talk to the outside world, and if the end result is the HP people answer important and relevant questions with non-answers like "cosmic rays", it's not a good reflection on HP, and in due course it might even have some impact on the level of business. On the other hand, there may be perfectly good (but externally invisible) non-technical reasons justifying the "no x86-64" decision. Even if that was to be the case, meaningless answers to the "what RAS features are missing", like the "cosmic rays" answer we've had through other channels so far, help no one. Your recent contributions are hopefully helping readers understand why sensible answers to the "RAS features" question might be non-trivial as well as important. It's a shame you're not permitted to know the real answers, 'cos you're clearly in a better position to understand than most and you'd probably put it over quite nicely, but 'twas ever thus in the world of big business. Rock<>hard place. > Forget the stuff you learned in your introduction to digitial > electronics. Preaching to the converted here. Some folk seem to like the occasional war story: I had great fun in the 1980s educating some of my relatively new hardware design colleagues about the harsh realities of signal propagation, and timing "glitches", and... I was a physics/electronics graduate who ended up in a mostly-software job in a company making mil-spec safety-critical control systems. On one occasion one of the new generation of digital systems was costing the company thousands of pounds a week, because mil-spec processor cards were frequently dying (unrepairably) during the EPROM-reprogramming process. Neither the designer of the programmer nor his hardware colleagues had realised that some parts of the on-board EPROM programming system [1] needed to be treated as a transmission line because the programming pulses had fast rising edges ("what's a transmission line?"), and the resulting overvoltage transients were often enough to write off the whole processor card. On another occasion I redesigned a terminal driver for the in-house test equipment and systems started mysteriously crashing occasionally. "Your software's broken" said the hardware folks (perhaps understandably as they had previously been using a somewhat broken terminal driver, hence the redesign). The new software wasn't broken, and in due course, extended troubleshooting with a logic analyser exposed a previously-hidden implementation flaw in the CPU/interrupt inteface; the hardware folks said "it can't do that" but the observed evidence occasionally said otherwise and some different synchronisation logic on the interrupt controller made the problem go away permanently. More recently I've occasionally done similar troubleshooting stuff in systems based on Alpha and (very occasionally) Proliant too but there's not much I can say about those, except to say that the most fun has usually involved trying to make 3rd-party kit of one kind or another work cleanly, reliably, repeatably in a system which apparently works just fine on its own. In the world of Windows, the multi-vendor integration challenge is a common problem but one which is commonly ignored, the "reboot, reinstall, live with it" sequence being acceptable in most cases. In the world of VMS where that sequence isn't acceptable, it shouldn't be such a big problem (for customers) because systems and devices don't get formal support till folks in the know have seen it repeatably work right, hopefully. That does mean that the world of VMS-supported kit can only ever be a tiny subset of the available kit, but if the VMS-supported world was an appropriate subset of (say) Proliant-class x86-64 kit, would that help the OpenVMS business vs today's setup? Summary: been there, done that, got the T-shirt, forgotten where I put it :) [1] The mil-spec processor cards in this system had soldered-in EPROMs (you wouldn't want sockets in a production unit). To reprogram the processor cards you removed them from the system box and plugged them into a factory support box. Design of the not-mil-spec not-safety-critical support box was seen as an appropriate task for an up and coming digital engineer who knew a bit about software. ------------------------------ Date: 3 Mar 2007 02:48:46 -0800 From: "Volker Halle" Subject: Re: Cluster connection lost when one link fails? Message-ID: <1172918926.360308.76310@s48g2000cws.googlegroups.com> A solution is now publicly available in VMS83I_LAN-V0300 (for OpenVMS I64 V8.3). Please refer to the problem description and analysis in section 5.2.4 CLUEXIT in the release notes of this patch. Drivers affected are: [SYS$LDR]SYS$EWDRIVER.EXE [SYS$LDR]SYS$EWDRIVER_DE500BA.EXE Volker. ------------------------------ Date: 3 Mar 2007 03:21:01 -0800 From: "UnderMine" Subject: Re: History of VMS and related operating systems Message-ID: <1172920861.335920.67840@30g2000cwc.googlegroups.com> On Mar 2, 10:25 am, "vaxorcist" wrote: > Besides, what would you consider a "Release Date"? > - A date given in an official DEC announcement > - The Release Date of the Version Release Notes Manual > - The date when distribution media was written > - ... Previously I have been trying to locate any dates at all ;) But since I restarted the project in January I have been documenting Announced, Released and Withdrawn dates where I know them. For the VMS pages I have Added another column 'built' but would 'tapes dated' be better? Usually there is only the press releases/announcements to go on sometimes these indicate that the software is available now, sometimes they give a date in the future and if they are from Microsoft you have no idea (Windows 4 Chicago announced 4/7/1992, Windows 95 Beta 9/8/1994, Windows 95 Released 24/8/1995 but then it needed service pack 1 31/12/1995 and we won't even mention Vista :( 2002-2007 ) > I'm still looking for the following versions: Thanks for all your help Paddy ------------------------------ Date: Sat, 03 Mar 2007 08:05:09 GMT From: "Malcolm Dunnett" Subject: Re: Oracle moves to per-chip licencing Message-ID: "Ian Miller" wrote in message news:1172876407.298757.129560@8g2000cwh.googlegroups.com... | Interesting but Does Oracle Standard Edition and Standad Edition One | run on VMS? | Standard Edition up to version 9.2 runs on VMS, but Oracle is not going to release Standard Edition 10.x on VMS. Apparently Oracle doesn't feel anyone wants Standard Edition on VMS. Standard Edition 9.2 is not available for Itanium, so the per socket licensing changes are moot for VMS (there aren't any multi-core Alphas are there?) From what I read in the referenced article the price changes also apply to Enterprise Edition. It appear that Intel cores are counted as half a CPU, so the price for Enterprise Edition on multi-core Itanium systems should now be half of what it previously was. ------------------------------ Date: Sat, 03 Mar 2007 11:07:56 -0500 From: bradhamilton Subject: SCSI disk firmware update question Message-ID: <45E99D5C.6070901@comcast.net> Hi Folks, I searched through the c.o.v. "archive", and could not find a quick answer to this question: If I update the firmware on my SCSI disks, will I "lose" any information currently residing on the disks? It's a good idea to backup data before making any changes, but I'm a hobbyist with no tape drive. I can shut down the system, boot minimally, do image backups to an archive disk, remove the archive disk, update the scsi disk firmware, and reboot, but if I can safely avoid the backup work, it would sure save some downtime. TIA ------------------------------ Date: Sat, 03 Mar 2007 11:23:59 -0500 From: "Richard B. gilbert" Subject: Re: SCSI disk firmware update question Message-ID: <45E9A11F.9040306@comcast.net> bradhamilton wrote: > Hi Folks, > > I searched through the c.o.v. "archive", and could not find a quick > answer to this question: > > If I update the firmware on my SCSI disks, will I "lose" any information > currently residing on the disks? > > It's a good idea to backup data before making any changes, but I'm a > hobbyist with no tape drive. I can shut down the system, boot > minimally, do image backups to an archive disk, remove the archive disk, > update the scsi disk firmware, and reboot, but if I can safely avoid the > backup work, it would sure save some downtime. > > TIA Updating the firmware does not inherently wipe the disk. The risk is that something will go wrong with the update leaving you with an unusable disk. What problem are you trying to solve by updating the firmware? In a career spanning some twenty years with disks from the RA (SDI) series , to DSSI and SCSI disks, I don't believe I EVER needed to update the firmware. ------------------------------ Date: Sat, 03 Mar 2007 12:04:38 -0500 From: bradhamilton Subject: Re: SCSI disk firmware update question Message-ID: <45E9AAA6.5030209@comcast.net> Richard B. gilbert wrote: > Updating the firmware does not inherently wipe the disk. The risk is > that something will go wrong with the update leaving you with an > unusable disk. > > What problem are you trying to solve by updating the firmware? In a > career spanning some twenty years with disks from the RA (SDI) series , > to DSSI and SCSI disks, I don't believe I EVER needed to update the > firmware. I have been attempting (without success) to create minimum-boot environments on one or more non-system disks, (using @sys$system:axp*min*) so that I may boot "minimally" without using the CD (which is much slower). In my time as a system manager, I was able to do this in many different Alpha VMS HW "environments" without issue. I am unable to do this on my hobbyist system here at home; I successfully install the above-named software, and I can start the minimal boot process, which inevitably fails trying to read the pointer to the boot block. I suspect that this happens for one of two reasons: - The 73GB data disks have never had their firmware "updated" since I've purchased them (they are all Seagates, purchased via e-bay, that I have successfully "shoe-horned" into empty topgun-blue SBB carriers; they reside happily in two BA-356X boxen, and have been holding and serving data to the system without error for a couple of years now). - The 73GB disks are "too large" to host a minimum environment for booting. I was hoping to prove/disprove one of the two hypotheses by upgrading firmware (if possible). Of course, there could be several more reasons why booting minimally is not working, but these are the only two possibilities that currently come to mind. All are welcome to jump in and offer opinions, advice, etc. ------------------------------ Date: 3 Mar 2007 09:14:52 -0800 From: sean@obanion.us Subject: Re: Wanted: MicroVAX I / VAXstation I owners Message-ID: <1172942091.825878.220890@h3g2000cwc.googlegroups.com> On Mar 2, 3:04 am, "vaxorcist" wrote: > Who else has got (and eventually runs) the worlds slowest VAX ever ??? > > I'm going to build one from parts and will probably need some help. > All OSes welcome! > > Regards > > Ulli Wan't the VAX-11/730 slower? I think it was about .3 VUP... When I installed bsd 4.1 (circa 1985, it was new!), the installation notes said the the 730 was not fast enough to be usefull. Sean ------------------------------ End of INFO-VAX 2007.124 ************************