INFO-VAX Sun, 30 Mar 2008 Volume 2008 : Issue 180 Contents: Re: Alphaserver/station reliability Re: Alphaserver/station reliability Re: Alphaserver/station reliability RE: Alphaserver/station reliability Re: Does POWER_OFF really work ? Re: Does POWER_OFF really work ? Re: Does POWER_OFF really work ? Re: Does POWER_OFF really work ? Re: RX3600 and VMS 8.3 Re: System Programming Resources for Alpha Architecture ---------------------------------------------------------------------- Date: Sun, 30 Mar 2008 12:44:30 +0100 From: baldrick Subject: Re: Alphaserver/station reliability Message-ID: <13uuv953krn8926@corp.supernews.com> david.pearson@british-energy.com wrote: ... > The reason for this request is to support the use of the Alphas in a > mission-critical role running a legacy app as part of the business > justification. > Posting to the forum preferred but mail to hp@pearson.in also accepted > if confidentiality required. When you have "mission critical", where VMS is concerned, it gives you some of the best availability technology, and if you choose not to use in in your application, it is totally irrelevant if you are using an Alpha, a VAX, an Integrity, an IBM, a PR1ME, Solaris, Windows, Tru64 whatever. You could have the AlphaStation with the world record for the most number of hours being switched on, and Joe Soap will come along and trip up over the power lead. What does it prove? Take it a step further, I've seen VAXes that have run without problem since they were installed, and an Integrity system in which a CPU failed a week after it was installed. The question you should be asking is how can I make the best use of VMS's features so that my application gives 100% availability, regardless of what the hardware underneath is doing. For your money OpenVMS gives you by far and away the richest set of features and mostly built into the core of the operating system, not some additional bit, or several bits of code from a third party company or companies to, for the want of a better expression, keep it up. The offshoot of this is that even when you've not decided to take advantage of clustering, shared storage, network failover, reliable transaction routing (etc.), that the system does a pretty good job of standing up to abuse, so the general wear and tear is taken in its stride, and you end up with people who just take the thing for granted. I can see you love your Alphas, but I can also see you don't really know how to turn them on! ;-) Tru64 in this case has some stolen features from VMS, but it is a case of close but no cigar [for my money]. To be fair here I come across examples from one extreme to the other, precarious systems hanging by a thread and still working, and systems where the only thing that will take them out is the Vogons popping along and demolishing the earth. Application, hardware, environment. My advice to you would be to port to OpenVMS (redesigned appropriately) and the reliability or otherwise of the hardware will become irrelevant. You want proof? Perhaps some systems I could tell you about and then I'd have to kill* you, but there are also systems [on VMS] that if they didn't do what they did, there would be a LOT of dead people. *=figure of speech, but if you are serious about availability I can put you in touch with people to give you guidance. Cheers, nic. -- aka. Mr. C. P. Charges, nclews "at" csc dot c o m ------------------------------ Date: Sun, 30 Mar 2008 13:20:16 +0100 From: "R.A.Omond" Subject: Re: Alphaserver/station reliability Message-ID: Nic wrote: > david.pearson@british-energy.com wrote: > ... > >> The reason for this request is to support the use of the Alphas in a >> mission-critical role running a legacy app as part of the business >> justification. >> Posting to the forum preferred but mail to hp@pearson.in also accepted >> if confidentiality required. > > [...snip...] > I can see you love your Alphas, but I can also see you don't really know > how to turn them on! ;-) Tru64 in this case has some stolen features > from VMS, but it is a case of close but no cigar [for my money]. Seconded (and this from someone who does support for both of these). > [...snip...] > > Application, hardware, environment. My advice to you would be to port to > OpenVMS (redesigned appropriately) and the reliability or otherwise of > the hardware will become irrelevant. A great deal of the UK energy-supply companies have traditionally been VMS users (for what will seem to us to be obvious reasons). Personally I find it scary that British Energy (who run all or most of our nuclear reactors) is apparently not one of these. I'd second Nic's recommendation to port the mission-critical application to VMS, even though it is described as "legacy" (Legacy = Something that works). > You want proof? Perhaps some systems I could tell you about and then I'd > have to kill* you, but there are also systems [on VMS] that if they > didn't do what they did, there would be a LOT of dead people. I know of a good number of these in the UK - hold on, there's someone knocking at my door ... I'll be b... ------------------------------ Date: Sun, 30 Mar 2008 14:46:08 +0100 From: "John Wallace" Subject: Re: Alphaserver/station reliability Message-ID: <13uv6d6m10ffv35@corp.supernews.com> "R.A.Omond" wrote in message news:fso0i2$g45$1$8300dec7@news.demon.co.uk... > Nic wrote: > > > david.pearson@british-energy.com wrote: > > ... > > > >> The reason for this request is to support the use of the Alphas in a > >> mission-critical role running a legacy app as part of the business > >> justification. > >> Posting to the forum preferred but mail to hp@pearson.in also accepted > >> if confidentiality required. > > > > [...snip...] > > I can see you love your Alphas, but I can also see you don't really know > > how to turn them on! ;-) Tru64 in this case has some stolen features > > from VMS, but it is a case of close but no cigar [for my money]. > > Seconded (and this from someone who does support for both of these). > > > [...snip...] > > > > Application, hardware, environment. My advice to you would be to port to > > OpenVMS (redesigned appropriately) and the reliability or otherwise of > > the hardware will become irrelevant. > > A great deal of the UK energy-supply companies have traditionally been > VMS users (for what will seem to us to be obvious reasons). Personally > I find it scary that British Energy (who run all or most of our nuclear > reactors) is apparently not one of these. I'd second Nic's > recommendation to port the mission-critical application to VMS, > even though it is described as "legacy" (Legacy = Something that works). > > > You want proof? Perhaps some systems I could tell you about and then I'd > > have to kill* you, but there are also systems [on VMS] that if they > > didn't do what they did, there would be a LOT of dead people. > > I know of a good number of these in the UK - hold on, there's someone > knocking at my door ... I'll be b... British Energy was/is a nuclear electricity generator, though they may not be British much longer. There are historic reasons why they're not a big DEC customer in the process control area. Not sure what you'd have seen in the way of DEC Export Licensing training, but it should somewhere have mentioned that DEC's Terms and Conditions of Sale require(d) specific high-level authorisation before sale into the nuclear industry, even when the application was monitoring rather than control. This "nuclear end use" clause often led DEC (or DEC-based systems integrators) to "no bid" nuclear business, even when a DEC solution might have offered a better deal than some of the niche stuff which often ended up going in. There would be no such "nuclear end use" concerns at the non-nuclear generators or at regional electricity distribution companies. That being said, many of the high-availability applications in electricity generation and distribution would be things like SCADA and real time control (I'm ignoring billing, CS, etc), and real-time applications like that aren't necessarily going to benefit from cluster availability features - e.g. depending on the setup, the time taken for a cluster transition may have been too long. For that kind of app, a reliable Unix (such as Tru64) on reliable hardware (such as AlphaServer) was often sufficient. regards John ------------------------------ Date: Sun, 30 Mar 2008 15:31:23 +0000 From: "Main, Kerry" Subject: RE: Alphaserver/station reliability Message-ID: > -----Original Message----- > From: John Wallace [mailto:johnwallace4@yahoo.spam.co.uk] > Sent: March 30, 2008 9:46 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Alphaserver/station reliability > > [snip...] > > That being said, many of the high-availability applications in > electricity > generation and distribution would be things like SCADA and real time > control (I'm ignoring billing, CS, etc), and real-time applications > like > that aren't necessarily going to benefit from cluster availability > features - e.g. depending on the setup, the time taken for a cluster > transition may have been too long. For that kind of app, a reliable > Unix > (such as Tru64) on reliable hardware (such as AlphaServer) was often > sufficient. > > regards > John > RASS (reliability, availability, security and scalability) are what most really mission critical environments are looking for. While I am sure there are some exceptions, the "neat new technologies of the day" are typically not in the picture - certainly not at the core. And for obvious reasons, security is becoming an even bigger issue now as well. So, while any platform can have work done to make it much more secure than what the base product offers, the reality facing mission critical (and others as well) is "how do you keep it secure from known issues?" This is where the reputation and proven record of a platform comes into play. If a specific platform is known as a great distributed compute platform, but not very secure because there are 5-20 security patches being released each and every month by the platform provider, then that is likely not a good platform for a centralized, high security environment. Here are a few examples of resent SCADA news releases from SCADA providers: http://www.vista-control.com/itanium_success.htm (Windows to OpenVMS move) "Los Alamos, February 15th. 2007 After implementing mission-critical system= s on Windows-based computers for many years, a customer experienced a virus i= n one of these systems that shut down production for two days while the infected systems were diagnosed, restored and tested. The impact was that plant production was severely impacted at no small cost. Despite internal opposition because of the established standard, Vsystem on HP Itanium serve= rs running OpenVMS was chosen for the next system to be replaced." http://www.availabilitydigest.com/public_articles/0209/qei.pdf (Sept 2007) extract - "The Master Station runs on HP OpenVMS blades or towers. It can b= e configured as a standalone system or in a dual, triple, or quadruple modula= r redundancy configuration, as described later." 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: 30 Mar 2008 06:38:23 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Does POWER_OFF really work ? Message-ID: <47ef355f$0$25045$607ed4bc@cv.net> In article <47ef152b$0$23915$c3e8da3@news.astraweb.com>, JF Mezei writes: >Figured I would shut down one of my alphas for EARTH-HOUR . >{...snip...} As you've experienced, it works about as well as Earth Hour did. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: 30 Mar 2008 09:36:23 +0100 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: Does POWER_OFF really work ? Message-ID: <47ef5f17$1@news.langstoeger.at> In article <47ef152b$0$23915$c3e8da3@news.astraweb.com>, JF Mezei writes: >While doing the shutdown procedure, SHUTDOWN.COM prompts me for shutdown >options and one of them was POWER_OFF . So I selected this. > >But after the shutdown, the power stayed on. (Alpha DS10L , this has the >RMC and from RMC one can power off the unit). > >Is this normal ? (the console is a graphic device, not a serial port) POWER_OFF works on my PWS433au, but (so far) doesn't on my PWS500au, DS10, ... I think it mostly depends if your the supply has a push button or a switch. -- 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: Sun, 30 Mar 2008 08:25:19 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Does POWER_OFF really work ? Message-ID: In article <47ef152b$0$23915$c3e8da3@news.astraweb.com>, JF Mezei writes: > Figured I would shut down one of my alphas for EARTH-HOUR . What is EARTH-HOUR? > While doing the shutdown procedure, SHUTDOWN.COM prompts me for shutdown > options and one of them was POWER_OFF . So I selected this. > > But after the shutdown, the power stayed on. (Alpha DS10L , this has the > RMC and from RMC one can power off the unit). > > Is this normal ? (the console is a graphic device, not a serial port) It depends on the hardware model. I have seen it work on a Personal Workstation, but not on a 3000/600. I believe a necessary, if perhaps not sufficient, condition is that the power switch is the "toggle" type, i.e. one can't tell from the position of the switch whether it is on or off. ------------------------------ Date: 30 Mar 2008 11:46:12 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Does POWER_OFF really work ? Message-ID: <47ef7d84$0$25031$607ed4bc@cv.net> In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: >In article <47ef152b$0$23915$c3e8da3@news.astraweb.com>, JF Mezei > writes: > >> Figured I would shut down one of my alphas for EARTH-HOUR . > >What is EARTH-HOUR? Just a way to make people concerned about the environment feel good about themselves and nothing more. http://www.earthhour.org/ -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Sun, 30 Mar 2008 09:17:17 GMT From: "Colin Butcher" Subject: Re: RX3600 and VMS 8.3 Message-ID: Hi, Having just about finished the implementation of a mission-critical system migration from Alpha to Integrity (rx6600s and rx2660s) then I'm really quite impressed with the performance of the rx family. The 6600 is a very capable box. So is the 2660. As for 3660 v 2660 - it depends on your probable maximum requirements and how much headroom you want to pay for. 32GB memory might sound a lot, but if you have applications that can burn memory for buffering and you can trade memory for performance improvements then you might well find that lots of memory really helps. We tried some interesting tests with DECram in a 192GB rx6600 for a very specific workload - and it was pretty good. If you have the budget / space etc. I'd probably go for the 6600 rather than the 3660. However, as always, it all depends on your workload and what you need to deliver for throughput and response times. Just as important is the surrounding infrastructure, especially the storage. Moving from 1Gbps FC with HSG80s to 4Gbps FC with EVA4100s has given a massive improvement in IO capability. The MSL4048 with the FC Ultrium LTO4 drives is a massive step up as well - we're seeing around 100Mbyte/sec throughput to tape using BACKUP. On the network front - use lots of NICs and split the protocols across them. That's another big improvement area for performance. Use V8.3-1H1 by the way. It's a little bit quicker than V8.3 on the FC IO front because of some driver and internals improvements. It also has a number of other improvements, like the USB V2 support. http://www.downloads.xdelta.co.uk/hp_nl_vmstud_2007/2007_10_02-nl_vmstud_porting-colin_butcher-v1_2.pdf might be useful. It's the slide set from the VMS technical update in Utrecht back on October last year. -- Cheers, Colin. Legacy = Stuff that works properly! ------------------------------ Date: Sun, 30 Mar 2008 11:26:39 +0100 From: "John Wallace" Subject: Re: System Programming Resources for Alpha Architecture Message-ID: <13uur2s1in51916@corp.supernews.com> "Maciej W. Rozycki" wrote in message news:alpine.SOC.1.00.0803300006500.26418@piorun... > Well, I think "System Programming / OS Development / OS Porting" makes it >pretty much clear it is not application programming that is in question >here. I have yet to see an operating system that does not require any >platform-specific code, including handwritten assembly. And then even >higher-level language OS code may require knowledge of processor-specific >details, like architecture of the register file or the TLB. Resources >mentioned elsewhere in this thread should be good enough though. > Maciej Quite. You and I might think that but for some reason we seem to be in a minority here. Some clarification from the original contributor would be welcome in due course, but in the absence of that, his reference to Minix on his Myspace page gives a possible hint that perhaps we're not necessarily looking at traditional application porting here... ------------------------------ End of INFO-VAX 2008.180 ************************