Stay on Alpha forever? - VMS

This is a discussion on Stay on Alpha forever? - VMS ; On 08/02/07 05:17, Neil Rieck wrote: > On Aug 1, 10:13 pm, JF Mezei wrote: >> Another possible avenue if the Alpha maintenance costs are too high >> would be to consider buying 64 bit 8086 servers and running the ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 76

Thread: Stay on Alpha forever?

  1. Re: Stay on Alpha forever?

    On 08/02/07 05:17, Neil Rieck wrote:
    > On Aug 1, 10:13 pm, JF Mezei wrote:
    >> Another possible avenue if the Alpha maintenance costs are too high
    >> would be to consider buying 64 bit 8086 servers and running the Alpha
    >> emulator (*). This will eventually give you performance boosts compared
    >> to exists systems without the need to migrate to that IA64 thing.
    >>

    >
    > Unlike PDP, VAX, and Alpha servers, most 8086 based stuff (64 bit or
    > not) has been manufactured dirt-cheap and very rarely supports server-
    > quality features like hardware-based error-detection on memory, caches
    > and I/O channels. On top of this, DEC systems could always do single-
    > bit (and sometimes 2-bit) error correction in memory.
    >
    > ps-1: PC motherboards supporting parity exist but most of the time
    > parity-checking is disabled and only 8-bit chips are installed


    Sure, PC motherboards are cheap.

    But x86(-64) *server* motherboards are *not* cheap. And, depending
    on how much you want to spend, they *do* provide all the important
    server-level features.

    That's why they're server mobos, not PC mobos.

    > ps-2: A few months back I watched a technician "fix a problem" by
    > disabling partity-checking in BIOS. Some people just don't get it.


    And Field Circus was so named because... they worked on PCs?

    I think not.

    > So I wouldn't recommend a permanent PC/emulator solution at this time.
    > But there are plenty of new and used Alpha systems available from
    > multiple sources so if people can't move to Itanium then they should
    > just move to a bigger better Alpha while wait until Itanium supports
    > all the stuff you need.



    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  2. Re: Stay on Alpha forever?

    In article ,
    Ron Johnson wrote:

    > On 08/02/07 02:24, P. Sture wrote:
    > > In article ,
    > > Kilgallen@SpamCop.net (Larry Kilgallen) wrote:
    > >
    > >> In article , moroney@world.std.spaamtrap.com
    > >> (Michael Moroney) writes:
    > >>
    > >>> Do you need a performance boost now? What kind of performance boost are
    > >>> you likely to need in the future?
    > >> Note that there are some domains where no performance boost is needed.
    > >> The best example I have heard of is the software reading toll tickets
    > >> on toll roads. That is a case where the bandwidth of the road is never
    > >> going to increase enough to tax the computer capacity. And I am quite
    > >> careful before I use the word "never".

    > >
    > > Putting a GUI on it would probably do the trick. Totally unnecessary I
    > > agree, but I wouldn't be at all surprised if someone somewhere has at
    > > least proposed it.

    >
    > Don't even go there.


    Tell me about it. I should have added a big :-(

    > We had a beautifully fast system written in C, Rdb & DECforms. The
    > customer wanted GUI and 3-tier C-S, though, object-oriented
    > middleware, blah blah. So that's what they got.


    The sad thing is that that story appears to be far from unusual.

    > God, I hate customers. Especially government customers who couldn't
    > find their arses with both hands.


    :-(

    --
    Paul Sture

    Sue's OpenVMS bookmarks:
    http://eisner.encompasserve.org/~stu...bookmarks.html

  3. Re: Stay on Alpha forever?

    Larry Kilgallen wrote:

    >
    > But that is a self-selecting sample, of those for whom a port made
    > sense and for whom there were appropriate compilers on IPF.


    Only partially true. Lots of customers who have come to the HP/Intel
    Developer's Forum came for the cheap hardware with little or no guess if
    their code could port or not. It is true that folks with PL/I code for
    instance might have been steered away, I have seen customers who just
    came with a saveset that even they haven't looked inside of before.
    Many of those ported easily.

    There has been only one case with me where a customer had this rather
    ugly Macro-32 application on Alpha which directly manipulated the FP,
    SP, etc. to emulate some PDP-11 application. I looked for about 30
    minutes and threw up my hands. I recommended they stay on Alpha or go
    to a VAX emulator product.

    --
    John Reagan
    OpenVMS Pascal/Macro-32/COBOL Project Leader
    Hewlett-Packard Company

  4. FP on IA64 Re: Stay on Alpha forever?

    On Thu, 02 Aug 2007 05:57:09 -0700, John Reagan wrote:

    > There has been only one case with me where a customer had this rather
    > ugly Macro-32 application on Alpha which directly manipulated the FP,
    > SP, etc. to emulate some PDP-11 application. I looked for about 30
    > minutes and threw up my hands. I recommended they stay on Alpha or go
    > to a VAX emulator product.


    BTW, why no frame pointer? I remember Mips did something similar and it
    made signal handling rather cumbersome.


    --
    PL/I for OpenVMS
    www.kednos.com

  5. Re: Stay on Alpha forever?

    On Aug 1, 3:17 pm, tadamsmar wrote:
    > I am evaluating an upgrade to Integrity.
    >
    > I am pretty sure the upgrade is going to be more costly than staying
    > on Alpha. I don't have good estimates, but I would ballpark the costs
    > in the tens of thousands, with no significant return on investment.
    >
    > But the app is mission-critical with no end-date in site.
    >
    > Can a costly upgrade be justfied simply because you can't stay on
    > Alphas forever?


    tadamsmar,

    Without an audit of the source code, it is impossible to make an
    accurate assessment. However, having attended three of the porting
    seminars (once as a student, twice as an Encompass volunteer), some
    comments are appropriate.

    Many people were able to port to Itanium simply by recompiling, even
    when the OpenVMS software was not yet released (see my article on the
    2006 Mahwah, New Jersey porting seminar at
    http://www.openvms.org/stories.php?s.../12/07/0088240 ). The
    results of this seminar echoed the comments that I made at the outset
    of the Itanium effort at the Compaq Enterprise Technology Symposium in
    September 2001 (see http://www.rlgsc.com/cets/2001/1620.html ).

    The most common problem in porting is simply a straightforward problem
    with lack of sources, lack of build files, or sources that have not
    been compiled for an extended period of time. As an example,. there is
    a lot of C code written for the old VAX C compiler, with the relaxed
    standards that were current at the time. The newer C compilers do not
    support these extensions, necessitating textual changes that are not
    complex, but they can be voluminous.

    My recently paper "Strategies for Migrating from Alpha and VAX systems
    to HP Integrity Servers on OpenVMS" in the OpenVMS Technical Journal,
    Volume 10 (see http://www.rlgsc.com/publications/vm...trategies.html
    ), addressed the strategic question of how the costs and intensity of
    the migration effort can be reduced through strategic use of both
    mixed architecture OpenVMS clusters and the binary translator. I
    demonstrated how to strategically structure a migration as an
    incremental effort, so as to reduce risk and intensity.

    Without information, it is hard to speculate as to how much effort is
    required to migrate your workload to Itanium. What is clear from my
    experiences is that the risk and effort are often less than is
    perceived.

    - Bob Gezelter, http://www.rlgsc.com


  6. Re: Stay on Alpha forever?

    On Aug 1, 4:58 pm, "Guy Peleg"
    wrote:
    > "tadamsmar" wrote in message
    >
    > news:1185995866.368720.29970@g4g2000hsf.googlegrou ps.com...
    >
    > >I am evaluating an upgrade to Integrity.

    >
    > > I am pretty sure the upgrade is going to be more costly than staying
    > > on Alpha. I don't have good estimates, but I would ballpark the costs
    > > in the tens of thousands, with no significant return on investment.

    >
    > > But the app is mission-critical with no end-date in site.

    >
    > > Can a costly upgrade be justfied simply because you can't stay on
    > > Alphas forever?

    >
    > There are few reasons I could think of that justify migration:
    >
    > 1. Performance - most of the applications I've seen, got significant
    > performance boost by going to Itanium.


    I can't identify a performance need for us.

    >
    > 2. New hardware support - if you need 10gb lan adapter, it's
    > only available on Itanium


    Don't see the need in our case.

    >
    > 3. Cost of software support - should be lower but YMMV based
    > on local country policy.


    We have dropped most of our software support, so I think the support
    costs would rise. Of course we would *have* support; there is always
    the possibility that we would need support that we currently don't
    have.

    >
    > 99% of customer I've worked with completed the port itself in less
    > than a week. Planning and testing takes longer of course.


    I don't think that will happen. I think we may need to reintegrate
    our custom code with a different commercial software package.

    But if, I can avoid that, the the port could go fast.

    >
    > fwiw,
    >
    > Guy Peleg
    > BRUDEN-OSSGhttp://www.brudenossg.com
    >
    >
    >
    > --
    > Posted via a free Usenet account fromhttp://www.teranews.com




  7. Re: Stay on Alpha forever?

    On Aug 1, 5:29 pm, moro...@world.std.spaamtrap.com (Michael Moroney)
    wrote:
    > tadamsmar writes:
    > >I am evaluating an upgrade to Integrity.
    > >I am pretty sure the upgrade is going to be more costly than staying
    > >on Alpha. I don't have good estimates, but I would ballpark the costs
    > >in the tens of thousands, with no significant return on investment.
    > >But the app is mission-critical with no end-date in site.
    > >Can a costly upgrade be justfied simply because you can't stay on
    > >Alphas forever?

    >
    > Not enough info.
    >
    > Are your Alphas already old, the latest model or somewhere in between?


    I am replacing an AS400 soon with a DS10. At that point
    we will have one AlphaServer 800 and five DS10's. The oldest in
    production will be the AS800, 5+ years old, I think.

    >
    > Do you need a performance boost now? What kind of performance boost are
    > you likely to need in the future?


    Don't forsee a need for a performance boost.

    >
    > Can you expand your application by adding nodes to a cluster, or CPU cards
    > and/or memory to your existing Alphas? Can they be upgraded to a better
    > model?


    I am running 7.3.2. Can upgrade to any box that will run that.

    Don't see any expansion issues.

    >
    > How likely are you going to need to use new hardware - hardware that
    > will only be available on Integrity?


    Don't forsee that.

    >
    > Will the Itanic upgrade pay for itself in reduced maint. cost or power
    > consumption (wait...Itanic power consumption...scratch that argument!)?


    Actually, Itanic might draw less power, and reduce maintenance.

    >
    > How available are (and will be) spare parts and systems? How much $?


    We will have one spare old AS400 when I replace it. An one DS10 is a
    defacto spare but it is "in production" in a currently unused
    location. And my development machine is a "hot" backup for any failed
    production machine (not that hot, takes 30 minutes to switch to it).

    All systems except the non-real-time database machine have disk
    shadowing.

    I can get a spare or replacement if I can justify the cost.

    I have UPSes on all boxes in an attempt to avoid power failures that
    can lead to hardware failures.

    >
    > How good of an idea is it to run a mission critical app. on "old" Alphas?
    > That's what people will be thinking in the future.
    >
    > Also, a path to consider is to upgrade to Itanic "later". The choice
    > isn't binary, upgrade right now or stay on Alpha forever, is it?


    No, we could upgrade later. I don't know if it will be harder to get
    consulting, or whatever later.

    I guess waiting would allow one to see what the future holds for
    OpenVMS. But is the future likely to be different?


  8. Re: Stay on Alpha forever?

    On Aug 1, 5:42 pm, Neil Rieck wrote:
    > On Aug 1, 3:17 pm,tadamsmar wrote:
    >
    > > I am evaluating an upgrade to Integrity.

    >
    > > I am pretty sure the upgrade is going to be more costly than staying
    > > on Alpha. I don't have good estimates, but I would ballpark the costs
    > > in the tens of thousands, with no significant return on investment.

    >
    > > But the app is mission-critical with no end-date in site.

    >
    > > Can a costly upgrade be justfied simply because you can't stay on
    > > Alphas forever?

    >
    > What kind of CPU are you currently running on?
    >
    > Neil Rieck
    > Kitchener/Waterloo/Cambridge,
    > Ontario, Canada.http://www3.sympatico.ca/n.rieck/


    DS10s, one AlphaServer800.


  9. Re: Stay on Alpha forever?

    John Reagan writes:

    >There has been only one case with me where a customer had this rather
    >ugly Macro-32 application on Alpha which directly manipulated the FP,
    >SP, etc. to emulate some PDP-11 application. I looked for about 30
    >minutes and threw up my hands. I recommended they stay on Alpha or go
    >to a VAX emulator product.


    (waves!)

    It's on a VAX, not an Alpha. The Alpha compiler would have choked on the
    bizarre code just as much as the Itanium compiler does now.

  10. Re: FP on IA64 Re: Stay on Alpha forever?

    "Tom Linden" writes:

    >On Thu, 02 Aug 2007 05:57:09 -0700, John Reagan wrote:


    >> There has been only one case with me where a customer had this rather
    >> ugly Macro-32 application on Alpha which directly manipulated the FP,
    >> SP, etc. to emulate some PDP-11 application. I looked for about 30
    >> minutes and threw up my hands. I recommended they stay on Alpha or go
    >> to a VAX emulator product.


    >BTW, why no frame pointer? I remember Mips did something similar and it
    >made signal handling rather cumbersome.


    It's 'emulated'. Normal code such as 'MOVAB x,(FP)' is interpreted as
    'they want to set a condition handler' and code is generated to do so,
    however the Itanium actually does this. Directly messing with the FP
    is not normal code.

  11. Re: Stay on Alpha forever?

    In article , "Tom Linden" writes:
    >On Wed, 01 Aug 2007 12:17:46 -0700, tadamsmar wrote:
    >
    >> I am evaluating an upgrade to Integrity.
    >>
    >> I am pretty sure the upgrade is going to be more costly than staying
    >> on Alpha. I don't have good estimates, but I would ballpark the costs
    >> in the tens of thousands, with no significant return on investment.
    >>
    >> But the app is mission-critical with no end-date in site.
    >>
    >> Can a costly upgrade be justfied simply because you can't stay on
    >> Alphas forever?
    >>

    >This is the wrong forum to seek that advice, in a sense. It is more of an
    >analysis of your own business plans. I can tell you that I know of
    >organizations with large VAXen planning to keep them in service past 2020.
    >Why? Because Digital didn't properly handled the the VAX - Alpha
    >transition.
    >
    >Just as Alpha had less capability then VAX, Itanium likewise has less than
    >Alpha, and to the extent that this doesn't impact you then you could give
    >Itanium a try, if you can make a business case for doing so. Incidentally,
    >I found that Alpha executables are about 3x those of VAX, and only recently
    >dtermined that there is an expansion of executables form Alpha to Itanium,
    >maybe a about a factor of two. Is this significant for the end user,
    >probably
    >not, but for us of those that muck about in the entrails, it is an
    >indication of
    >poor design.
    >

    For VAX to Alpha it wasn't poor design but just because the excutable had
    more instructions due to the fact that it was on a RISC chip.

    The doubling for Itanium is probably due to similar changes caused by compiler
    hints and other things to do with running on an EPIC architecture.

    I assume that by less capability in the above you are refering to software
    availability. In most cases Alphas would easily outperform Vax systems.

    David Webb
    Security team leader
    CCSS
    Middlesex University


    >
    >--
    >PL/I for OpenVMS
    >www.kednos.com


  12. Re: Stay on Alpha forever?

    Neil Rieck writes:

    >On Aug 2, 12:34 am, moro...@world.std.spaamtrap.com (Michael Moroney)
    >wrote:
    >[...snip...]
    >>
    >> Most of the VMS porting from Alpha to Itanic _is_ very straightforward
    >> when using a higher level language.
    >>
    >> On the other hand, if you're going from VAX to Itanic, and using Macro,
    >> and doing just about every crazy trick possible...let's not go there...
    >>


    >Do yourself a favour and start converting your Macro-32 code to C/C++
    >now.


    That's what *I* want to do, but the customer is always right...

  13. Re: Stay on Alpha forever?

    On Thu, 02 Aug 2007 09:18:48 -0700, wrote:

    > In article , "Tom Linden"
    > writes:
    >> On Wed, 01 Aug 2007 12:17:46 -0700, tadamsmar
    >> wrote:
    >>
    >>> I am evaluating an upgrade to Integrity.
    >>>
    >>> I am pretty sure the upgrade is going to be more costly than staying
    >>> on Alpha. I don't have good estimates, but I would ballpark the costs
    >>> in the tens of thousands, with no significant return on investment.
    >>>
    >>> But the app is mission-critical with no end-date in site.
    >>>
    >>> Can a costly upgrade be justfied simply because you can't stay on
    >>> Alphas forever?
    >>>

    >> This is the wrong forum to seek that advice, in a sense. It is more of
    >> an
    >> analysis of your own business plans. I can tell you that I know of
    >> organizations with large VAXen planning to keep them in service past
    >> 2020.
    >> Why? Because Digital didn't properly handled the the VAX - Alpha
    >> transition.
    >>
    >> Just as Alpha had less capability then VAX, Itanium likewise has less
    >> than
    >> Alpha, and to the extent that this doesn't impact you then you could
    >> give
    >> Itanium a try, if you can make a business case for doing so.
    >> Incidentally,
    >> I found that Alpha executables are about 3x those of VAX, and only
    >> recently
    >> dtermined that there is an expansion of executables form Alpha to
    >> Itanium,
    >> maybe a about a factor of two. Is this significant for the end user,
    >> probably
    >> not, but for us of those that muck about in the entrails, it is an
    >> indication of
    >> poor design.
    >>

    > For VAX to Alpha it wasn't poor design but just because the excutable had
    > more instructions due to the fact that it was on a RISC chip.


    We have this discussion before, perhaps to ennui, but what I found running
    the PL/I test suite was that normalizing to clock speed a 3x Alpha had the
    same performance as a VAX. The larger, weaker instrucution set also
    demands
    larger memory bandwidth and larger caches
    >
    > The doubling for Itanium is probably due to similar changes caused by
    > compiler
    > hints and other things to do with running on an EPIC architecture.
    >
    > I assume that by less capability in the above you are refering to
    > software
    > availability. In most cases Alphas would easily outperform Vax systems.

    Yes. Of course, VAX was left alone.
    >
    > David Webb
    > Security team leader
    > CCSS
    > Middlesex University
    >
    >
    >>
    >> --
    >> PL/I for OpenVMS
    >> www.kednos.com




    --
    PL/I for OpenVMS
    www.kednos.com

  14. Re: Stay on Alpha forever?

    tadamsmar wrote:
    > I am evaluating an upgrade to Integrity.
    >
    > I am pretty sure the upgrade is going to be more costly than staying
    > on Alpha. I don't have good estimates, but I would ballpark the costs
    > in the tens of thousands, with no significant return on investment.
    >
    > But the app is mission-critical with no end-date in site.
    >
    > Can a costly upgrade be justfied simply because you can't stay on
    > Alphas forever?



    First, apologies in advance for an on-topic post. :-)

    Hardware does not last forever; hardware can and does "rot".

    The expertise in the particular application bits and the platform bits,
    and the availability of compatible tools, can and does tend to decline
    over time, too.

    For AlphaServer DS10 or similar boxes here, you can maintain your own
    spares. And I would. But the spares and particularly the peripheral
    devices can and tend to do decompose over time; mechanical devices and
    electronics just don't last forever.

    Emulation can be a viable and short-term solution, and can potentially
    allow you to remove older hardware from the equation. Emulation does
    not, however, remove risk -- the software stack is even longer, and you
    end up with the same basic issues involved with hardware support, albeit
    from the hardware emulator (software) vendor, and from the underlying
    operating system software platform. In the case of SIMH, for instance,
    you may well end up owning the emulator support. (Don't read that as a
    recommendation against emulation, simply that it is not a panacea.)

    For tens of thousands of dollars, you can purchase a fair stable of
    spare parts for AlphaServer DS10 and related gear. And you'll have some
    budget left over. Porting a non-trivial application off of OpenVMS
    Alpha -- whether to OpenVMS I64 or to another platform -- will almost
    certainly cost more. Particular if prerequisite products are not available.

    You can choose to incrementally move toward more portable code here,
    too, though there's no payback in that effort until and unless you
    actually do port.

    If you do choose to move toward a port, you can also choose whether this
    work is going to be an incremental port toward OpenVMS I64, or over
    toward Microsoft Windows, or toward a UNIX 03 or similar platform model.

    A port to OpenVMS I64 will be the smallest port/jump, and UNIX 03 and
    Windows will be of higher difficulty.

    A lack of critical prerequisite layered products can demolish all
    savings from the basic OpenVMS-to-OpenVMS port.

    Once you open up the porting discussion, you do need and want to open up
    the discussion across all platforms, and least for some form of
    investigation. You'll also particularly want to look for a COTS
    application -- whether an existing and available commercial package, or
    the creation of a semi- or fully-custom package that can itself
    subsequently be commercialized -- that can be tailored to meet your
    particular business-critical requirements.

    Some related OpenVMS porting topics:

    http://64.223.189.234/node/225 (off of OpenVMS)
    http://64.223.189.234/node/226 (to OpenVMS I64)

    Hoff

    --
    www.HoffmanLabs.com
    Services for OpenVMS

  15. Re: Stay on Alpha forever?

    On Aug 2, 7:36 am, Ron Johnson wrote:
    > On 08/02/07 05:17, Neil Rieck wrote:
    >

    [...snip...]
    >
    > Sure, PC motherboards are cheap.
    >
    > But x86(-64) *server* motherboards are *not* cheap. And, depending
    > on how much you want to spend, they *do* provide all the important
    > server-level features.
    >
    > That's why they're server mobos, not PC mobos.
    >


    I think you are agreeing with my statement. First off, x86-64 doesn't
    incude the Itanium family. But you are correct in stating that most
    server mobos do include most of the stuff I mentioned as being
    important. { as an aside, SUN released a SPARC chip a few years back
    with no parity detection in one of the internal caches so I don't
    think you can assume that all server platforms are built the way we
    would want them to be, but I digress } Some non-server mobos contain
    some of this stuff as well but it means you need to pay a little more
    for DIMMs with parity support.

    Every day I encounter more people who are being dumbed-down by
    constant exposure to Wintel technology. Many would pick a fight with
    you If you even suggested that parity detection/correction was a
    requirement; most would fight you even more after you tell them the
    price of this requirement. (I can hear it now)

    So I stand by my original statement: don't install x86 whatever with
    an emulator unless you are really painted into a corner. It is better
    to buy a bigger Alpha (although you are still going to take a small
    hit on the software licences).

    p.s. I'm running a DS20 with 3GB of memory on OpenVMS-8.2. Most of the
    file system is cached so this thing just flys. Everyone should install
    more memory if possible. To make the best use of the file cache,
    everyone should be running OpenVMS-7.3-2 at the very minimum.

    Neil Rieck
    Kitchener/Waterloo/Cambridge,
    Ontario, Canada.
    http://www3.sympatico.ca/n.rieck/



  16. Re: Stay on Alpha forever?


    "Neil Rieck" wrote in message
    news:1186078261.486853.196470@x35g2000prf.googlegr oups.com...
    > On Aug 2, 7:36 am, Ron Johnson wrote:
    > > On 08/02/07 05:17, Neil Rieck wrote:
    > >

    > [...snip...]
    > >
    > > Sure, PC motherboards are cheap.
    > >
    > > But x86(-64) *server* motherboards are *not* cheap. And, depending
    > > on how much you want to spend, they *do* provide all the important
    > > server-level features.
    > >
    > > That's why they're server mobos, not PC mobos.
    > >

    >
    > I think you are agreeing with my statement. First off, x86-64 doesn't
    > incude the Itanium family. But you are correct in stating that most
    > server mobos do include most of the stuff I mentioned as being
    > important. { as an aside, SUN released a SPARC chip a few years back
    > with no parity detection in one of the internal caches so I don't
    > think you can assume that all server platforms are built the way we
    > would want them to be, but I digress } Some non-server mobos contain
    > some of this stuff as well but it means you need to pay a little more
    > for DIMMs with parity support.
    >
    > Every day I encounter more people who are being dumbed-down by
    > constant exposure to Wintel technology. Many would pick a fight with
    > you If you even suggested that parity detection/correction was a
    > requirement; most would fight you even more after you tell them the
    > price of this requirement. (I can hear it now)
    >
    > So I stand by my original statement: don't install x86 whatever with
    > an emulator unless you are really painted into a corner. It is better
    > to buy a bigger Alpha (although you are still going to take a small
    > hit on the software licences).
    >
    > p.s. I'm running a DS20 with 3GB of memory on OpenVMS-8.2. Most of the
    > file system is cached so this thing just flys. Everyone should install
    > more memory if possible. To make the best use of the file cache,
    > everyone should be running OpenVMS-7.3-2 at the very minimum.
    >
    > Neil Rieck
    > Kitchener/Waterloo/Cambridge,
    > Ontario, Canada.
    > http://www3.sympatico.ca/n.rieck/
    >
    >


    Please don't compare chalk and cheese. If you wish, compare current Itaniums
    with something like similarly priced Proliant-class boxes, not with el
    cheapo commodity-priced desktop-based stuff. Compaq's better Proliants have
    had plenty of RAS features for many years, and the research I have done says
    they (and their equivalents from IBM, Sun, etc) compare quite reasonably
    with Itanium boxes, at least at the low end.

    By far the least reliable bit of a typical Proliant these days is not
    hardware, it's Windows. But try telling that to the people doing
    VMware-based (or similar) server consolidation (or to those about to throw
    away a real VMS box to replace it with Charon?).

    Also, you might want to refer to ECC memory rather than parity memory;
    parity memory doesn't do corrections and is therefore largely useless, as
    any AlphaServer 400 owner who's fully populated the memory will tell you
    (mean time between unsolicited VMS reboots <28 days for a customer I was
    working with, they had to swap dozens of them for AlphaServer 1000As in the
    end, with real ECC memory). That AlphaServer 400 experience shows that the
    idea of relatively poor availability due to putting a "server" badge on
    desktop-class hardware isn't new, and wasn't/isn't confined to the PC world.
    It also showed (way back then) that adding lots of memory introduces snags
    unless it's ECC memory. ECC still isn't common on desktop/laptop machines,
    but 1GB or more of memory is not unusual these days, which makes me wonder
    how many crashes folks are going to see because of undetected main memory
    errors. They'll mostly just blame Windows of course, and historically they'd
    have been right to do so.

    2p
    John



  17. Re: Stay on Alpha forever?

    Michael Moroney wrote:
    > John Reagan writes:
    >
    >
    >>There has been only one case with me where a customer had this rather
    >>ugly Macro-32 application on Alpha which directly manipulated the FP,
    >>SP, etc. to emulate some PDP-11 application. I looked for about 30
    >>minutes and threw up my hands. I recommended they stay on Alpha or go
    >>to a VAX emulator product.

    >
    >
    > (waves!)
    >
    > It's on a VAX, not an Alpha. The Alpha compiler would have choked on the
    > bizarre code just as much as the Itanium compiler does now.


    Oh yeah. I remember now. Duh!

    --
    John Reagan
    OpenVMS Pascal/Macro-32/COBOL Project Leader
    Hewlett-Packard Company

  18. Re: Stay on Alpha forever?

    In article , Ron Johnson writes:
    > On 08/01/07 17:00, Larry Kilgallen wrote:
    >> In article , moroney@world.std.spaamtrap.com (Michael Moroney) writes:
    >>
    >>> Do you need a performance boost now? What kind of performance boost are
    >>> you likely to need in the future?

    >>
    >> Note that there are some domains where no performance boost is needed.
    >> The best example I have heard of is the software reading toll tickets
    >> on toll roads. That is a case where the bandwidth of the road is never
    >> going to increase enough to tax the computer capacity. And I am quite
    >> careful before I use the word "never".

    >
    > More plazas, more lanes, especially more customers, and, if various


    No, the bandwidth limit is the road.

    > agencies have sharing agreements (think E-ZPass, for those of you in
    > the NE United States), more reciprocity processing.
    >
    > Eventually, "more, more, more" maxes out the box.


    Do you have an example of this ? The one discussed at DECUS for many
    years switched to Alpha from PDP-11 due to parts availability, not for
    performance reasons.

  19. Re: FP on IA64 Re: Stay on Alpha forever?

    Michael Moroney wrote:
    > "Tom Linden" writes:
    >
    >
    >>On Thu, 02 Aug 2007 05:57:09 -0700, John Reagan wrote:

    >
    >
    >>>There has been only one case with me where a customer had this rather
    >>>ugly Macro-32 application on Alpha which directly manipulated the FP,
    >>>SP, etc. to emulate some PDP-11 application. I looked for about 30
    >>>minutes and threw up my hands. I recommended they stay on Alpha or go
    >>>to a VAX emulator product.

    >
    >
    >>BTW, why no frame pointer? I remember Mips did something similar and it
    >>made signal handling rather cumbersome.

    >
    >
    > It's 'emulated'. Normal code such as 'MOVAB x,(FP)' is interpreted as
    > 'they want to set a condition handler' and code is generated to do so,
    > however the Itanium actually does this. Directly messing with the FP
    > is not normal code.


    The Intel Run-time Conventions (ie, their calling standard) for Itanium
    doesn't have a frame pointer. It made it easier to use Intel technology
    for the C++ compiler and it make it easier for the compilers to do early
    testing Linux Itanium.

    --
    John Reagan
    OpenVMS Pascal/Macro-32/COBOL Project Leader
    Hewlett-Packard Company

  20. Re: Stay on Alpha forever?

    In article , moroney@world.std.spaamtrap.com (Michael Moroney) writes:
    > Kilgallen@SpamCop.net (Larry Kilgallen) writes:
    >
    >>In article <46b0e7c6$0$23226$88260bb3@free.teranews.com>, "Guy Peleg" writes:

    >
    >>> 99% of customer I've worked with completed the port itself in less
    >>> than a week.

    >
    >>But that is a self-selecting sample, of those for whom a port made
    >>sense and for whom there were appropriate compilers on IPF.

    >
    > Most of the VMS porting from Alpha to Itanic _is_ very straightforward
    > when using a higher level language.


    You don't get much higher level that Ada or PL/I, the two notable
    discontinuities where HP has declined to provide support.

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast