INFO-VAX Sat, 29 Mar 2008 Volume 2008 : Issue 178 Contents: Re: Alphaserver/station reliability Re: scripting a telnet session to VMS Re: System Programming Resources for Alpha Architecture Re: System Programming Resources for Alpha Architecture Re: System Programming Resources for Alpha Architecture Re: System Programming Resources for Alpha Architecture ---------------------------------------------------------------------- Date: Sat, 29 Mar 2008 15:53:54 GMT From: Michael Austin Subject: Re: Alphaserver/station reliability Message-ID: david.pearson@british-energy.com wrote: > This is a little bit of an open request but for the installation and > application I'm trying to justify it would really help me if I could > get some 'real' uptime data from the wider industry on how reliable > AlphaServers are. I know they have outstanding performance and are > used by half of wall street etc. but it would be great to know from > the real guys who have to keep these things running the real facts > behind the claims. > The two models I'm interested in are Alphaserver DS25 (a number of, > both single and dual processor) and an Alphastation DS15. All will be > running Tru64 Unix 5.1b. > Simple feedback such as "Typical application, date installed, MTBF/ > uptime/failure rate etc., whether frequently power-cycled or running > 24/7" would be great. Direct contact details to confirm this would > also be appreciated but not essential. > 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. My experience with the hardware is >365 days of uptime - depending on necessary patching for production issues. Hardware runs forever.. ------------------------------ Date: 29 Mar 2008 06:35:12 GMT From: "David Weatherall" Subject: Re: scripting a telnet session to VMS Message-ID: <65668vF2ea5luU1@mid.individual.net> Tom Linden wrote: > On Thu, 27 Mar 2008 17:44:29 -0700, VAXman- <@SendSpamHere.ORG> wrote: > > > > C# is a nice language. > > > > I thougth it was just a black key. > > > D-flat might be a more descriptive name Ah but that was what's-his-name in DDJ, Oh yes Al Stevens, invention. He was a C, C++ programmer and a Jazz pianist IIRC. BTW Is DDJ still going in the US? I've a collection going back to the early 80's but had gotten the impression it had died about a year(?) ago. It simply stopped appearing on the Munich bookshop's shelf and the lady behind the counter said it had ceased publication. Cheers - Dave. ------------------------------ Date: Sat, 29 Mar 2008 05:10:29 -0700 (PDT) From: Neil Rieck Subject: Re: System Programming Resources for Alpha Architecture Message-ID: On Mar 27, 3:02=A0pm, The-G...@hotmail.com wrote: > Does anyone know of any good resources for System Programming / OS > Development / OS Porting to Alpha Architecture? =A0Books, ebooks, or > sites online would be a big help. =A0Thanks in advance! > > James T. Sprinkle (The Grue)http://www.myspace.com/jamestsprinkle I'm not sure what you are trying to do, but I've found that it is not a good idea to get too machine specific. Properly written VAX applications will almost always compile and run on Alpha and Itanium. Having said that, look at these two books. http://www.theminimumyouneedtoknow.com/openvms_application_developer_book.ht= ml "Writing VAX/VMS Applications Using Pascal" which is out of print but can sometimes be found a used bookseller sites like www.bookfinder.com Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/openvms_demos.html http://www3.sympatico.ca/n.rieck/docs/alpha_diary.html (porting info) http://www3.sympatico.ca/n.rieck/docs/hacking_OpenVMS_starlet.html http://www3.sympatico.ca/n.rieck/links/cool_openvms.html ------------------------------ Date: Sat, 29 Mar 2008 14:00:44 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: System Programming Resources for Alpha Architecture Message-ID: In article , Neil Rieck writes: > On Mar 27, 3:02=A0pm, The-G...@hotmail.com wrote: > > Does anyone know of any good resources for System Programming / OS > > Development / OS Porting to Alpha Architecture? =A0Books, ebooks, or > > sites online would be a big help. =A0Thanks in advance! > > > > James T. Sprinkle (The Grue)http://www.myspace.com/jamestsprinkle > > I'm not sure what you are trying to do, but I've found that it is not > a good idea to get too machine specific. Properly written VAX > applications will almost always compile and run on Alpha and Itanium. Indeed. However, if he needs to "port", then he probably has an application which is NOT written properly, i.e. contains assumptions which are valid for VAX but not for ALPHA. Often sticking to the language standard will solve some of these problems, but having the compiler flag non-standard stuff which might be dangerous (when the code runs on another platform) will also flag non-standard stuff which might be required (e.g. DEC-specific extensions). ------------------------------ Date: Sat, 29 Mar 2008 09:29:23 -0700 (PDT) From: Neil Rieck Subject: Re: System Programming Resources for Alpha Architecture Message-ID: On Mar 29, 10:00 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- remove CLOTHES to reply) wrote: > In article > , > > Neil Rieck writes: > > On Mar 27, 3:02=A0pm, The-G...@hotmail.com wrote: > > > Does anyone know of any good resources for System Programming / OS > > > Development / OS Porting to Alpha Architecture? =A0Books, ebooks, or > > > sites online would be a big help. =A0Thanks in advance! > > > > James T. Sprinkle (The Grue)http://www.myspace.com/jamestsprinkle > > > I'm not sure what you are trying to do, but I've found that it is not > > a good idea to get too machine specific. Properly written VAX > > applications will almost always compile and run on Alpha and Itanium. > > Indeed. However, if he needs to "port", then he probably has an > application which is NOT written properly, i.e. contains assumptions > which are valid for VAX but not for ALPHA. Often sticking to the > language standard will solve some of these problems, but having the > compiler flag non-standard stuff which might be dangerous (when the code > runs on another platform) will also flag non-standard stuff which might > be required (e.g. DEC-specific extensions). Agreed. About 5 years back while I was porting some code from VAX to Alpha, I ran into a bunch of custom DEC-C functions which were mapped onto VAX instructions. A very clever programmer was able to squeeze a few more drops of performance out of an underpowered VAX box, and he probably received a cool bonus for pulling this off, but he should not have done this. Worse still, here I was using my low level VAX machine language skills to decode what was happening in "C". In five years more time, there might not have been anyone around with the skills to do this kind of port. So the key here is to avoid, whenever possible, architecture specific code leaving the bulk of those decisions to the system calls. If you must insert architecture specific code, make sure it is disabled with complier lexicals and includes lots of source-code remarks. NSR ------------------------------ Date: Sat, 29 Mar 2008 13:17:42 -0400 From: "Richard B. Gilbert" Subject: Re: System Programming Resources for Alpha Architecture Message-ID: <47EE79B6.5060303@comcast.net> Neil Rieck wrote: > On Mar 29, 10:00 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- > remove CLOTHES to reply) wrote: > >>In article >>, >> >>Neil Rieck writes: >> >>>On Mar 27, 3:02=A0pm, The-G...@hotmail.com wrote: >>> >>>>Does anyone know of any good resources for System Programming / OS >>>>Development / OS Porting to Alpha Architecture? =A0Books, ebooks, or >>>>sites online would be a big help. =A0Thanks in advance! >>> >>>>James T. Sprinkle (The Grue)http://www.myspace.com/jamestsprinkle >>> >>>I'm not sure what you are trying to do, but I've found that it is not >>>a good idea to get too machine specific. Properly written VAX >>>applications will almost always compile and run on Alpha and Itanium. >> >>Indeed. However, if he needs to "port", then he probably has an >>application which is NOT written properly, i.e. contains assumptions >>which are valid for VAX but not for ALPHA. Often sticking to the >>language standard will solve some of these problems, but having the >>compiler flag non-standard stuff which might be dangerous (when the code >>runs on another platform) will also flag non-standard stuff which might >>be required (e.g. DEC-specific extensions). > > > Agreed. About 5 years back while I was porting some code from VAX to > Alpha, I ran into a bunch of custom DEC-C functions which were mapped > onto VAX instructions. A very clever programmer was able to squeeze a > few more drops of performance out of an underpowered VAX box, and he > probably received a cool bonus for pulling this off, but he should not > have done this. > Of course he should have done it! It's what he was paid to do. It justifies his existence! Clearly, he failed to document it well enough to satisfy you but if I had a dollar for every programmer who under documents his work, I'd be traveling in a chauffeur driven Rolls-Royce!!! Documentation usually happens ONLY when someone MAKES it happen! The usual procedure is "get the code out the door and to hell with the documentation". That's when you get the documentation from hell! Or no documentation! > Worse still, here I was using my low level VAX machine language skills > to decode what was happening in "C". In five years more time, there > might not have been anyone around with the skills to do this kind of > port. I'm available! I hope to remain available for a few more years! > So the key here is to avoid, whenever possible, architecture > specific code leaving the bulk of those decisions to the system calls. > If you must insert architecture specific code, make sure it is > disabled with complier lexicals and includes lots of source-code > remarks. > > NSR > ------------------------------ End of INFO-VAX 2008.178 ************************