Galaxy on ES45 - VMS

This is a discussion on Galaxy on ES45 - VMS ; Is it possible? If not, why not (out of curiosity)? -- PL/I for OpenVMS www.kednos.com...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Galaxy on ES45

  1. Galaxy on ES45

    Is it possible? If not, why not (out of curiosity)?

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

  2. Re: Galaxy on ES45

    Galaxy does not work on the ES45, which is one reason why I don't have one
    of them.

    I think it's either console or IO bus related (you need a console per
    instance, plus you need the ability to split the IO buses as on the ES47,
    ES40 and the 4100), but I don't know for certain.

    --
    Cheers, Colin.
    Legacy = Stuff that works properly!



  3. Re: Galaxy on ES45

    JF Mezei wrote:
    > Tom Linden wrote:
    >> Is it possible? If not, why not (out of curiosity)?

    >
    > It is my uneducated guess that Galaxy requires certain facilities that
    > were implented in the Wildwire class machines (followed by GS class
    > machines).


    Some 4xxx/ES4x boxes do support Galaxy.

    I think Tom is asking why ES45 is different.

    Arne

  4. Re: Galaxy on ES45

    Arne Vajh°j wrote:
    > JF Mezei wrote:
    >> Tom Linden wrote:
    >>> Is it possible? If not, why not (out of curiosity)?

    >>
    >> It is my uneducated guess that Galaxy requires certain facilities that
    >> were implented in the Wildwire class machines (followed by GS class
    >> machines).

    >
    > Some 4xxx/ES4x boxes do support Galaxy.
    >
    > I think Tom is asking why ES45 is different.
    >
    > Arne


    Perhaps because there wasn't much demand?

    Galaxy, IIRC, allowed you to run N instances of VMS on a Galaxy capable
    box with N CPUs. Or, you could devote two CPU's to the same O/S
    instance and run two instances on a four CPU box. You could cluster
    these instances. I never quite saw the point.

    From DEC/Compaq/HP's point of view, they sold a Galaxy license for each
    additional instance, and possibly a cluster license as well.


    Perhaps very few saw the point.

  5. Re: Galaxy on ES45

    Richard B. Gilbert wrote:
    > Perhaps because there wasn't much demand?
    >
    > Galaxy, IIRC, allowed you to run N instances of VMS on a Galaxy capable
    > box with N CPUs. Or, you could devote two CPU's to the same O/S
    > instance and run two instances on a four CPU box. You could cluster
    > these instances. I never quite saw the point.
    >
    > From DEC/Compaq/HP's point of view, they sold a Galaxy license for each
    > additional instance, and possibly a cluster license as well.
    >
    > Perhaps very few saw the point.


    True.

    But considering how VMWare sell today, then maybe Galaxy
    could have sold better with the right marketing and
    pricing.

    Arne

  6. Re: Galaxy on ES45

    Arne Vajh°j wrote:
    > Richard B. Gilbert wrote:
    >> Perhaps because there wasn't much demand?
    >>
    >> Galaxy, IIRC, allowed you to run N instances of VMS on a Galaxy
    >> capable box with N CPUs. Or, you could devote two CPU's to the same
    >> O/S instance and run two instances on a four CPU box. You could
    >> cluster these instances. I never quite saw the point.
    >>
    >> From DEC/Compaq/HP's point of view, they sold a Galaxy license for
    >> each additional instance, and possibly a cluster license as well.
    >>
    >> Perhaps very few saw the point.

    >
    > True.
    >
    > But considering how VMWare sell today, then maybe Galaxy
    > could have sold better with the right marketing and
    > pricing.


    With the "right marketing and pricing" Digital Equipment Corporation
    might still exist today!




  7. Re: Galaxy on ES45

    On Sun, 25 May 2008 14:01:12 -0700, Arne Vajh°j wrote:

    > JF Mezei wrote:
    >> Tom Linden wrote:
    >>> Is it possible? If not, why not (out of curiosity)?

    >> It is my uneducated guess that Galaxy requires certain facilities that
    >> were implented in the Wildwire class machines (followed by GS class
    >> machines).

    >
    > Some 4xxx/ES4x boxes do support Galaxy.
    >
    > I think Tom is asking why ES45 is different.
    >
    > Arne


    Right. Colin's answer is likely the correct one. But is odd since
    the ES40 and ES47 support it but not the ES45.

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

  8. RE: Galaxy on ES45

    > -----Original Message-----
    > From: Arne Vajh°j [mailto:arne@vajhoej.dk]
    > Sent: May 25, 2008 8:14 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Galaxy on ES45
    >
    > Richard B. Gilbert wrote:
    > > Perhaps because there wasn't much demand?
    > >
    > > Galaxy, IIRC, allowed you to run N instances of VMS on a Galaxy

    > capable
    > > box with N CPUs. Or, you could devote two CPU's to the same O/S
    > > instance and run two instances on a four CPU box. You could cluster
    > > these instances. I never quite saw the point.
    > >
    > > From DEC/Compaq/HP's point of view, they sold a Galaxy license for

    > each
    > > additional instance, and possibly a cluster license as well.
    > >
    > > Perhaps very few saw the point.

    >
    > True.
    >
    > But considering how VMWare sell today, then maybe Galaxy
    > could have sold better with the right marketing and
    > pricing.
    >
    > Arne


    Well, that might be part of it, but the OpenVMS Cust might simply ask
    "why not just run these applications on the same OS instance?"

    For Windows/Linux environments, cultural and technical issues make
    App sharing extremely difficult. Hence, VMware is an easy short term
    solution for them. Course, they soon have to manage VM's that multiply
    like rabbits, but that's another discussion.

    OpenVMS Cust's have been doing App sharing for decades.

    Having stated this, I have heard of a few instances where some Cust's
    Have asked for the capability to create OpenVMS Dev instances quickly,
    but when pressed with the blades alternative, quite a few of them
    preferred the blade approach since there was no virtual drivers etc
    and the blade environment presented a closer reality to their prod
    Integrity environments.

    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.





  9. Re: Galaxy on ES45

    Main, Kerry wrote:

    > Having stated this, I have heard of a few instances where some Cust's
    > Have asked for the capability to create OpenVMS Dev instances quickly,
    > but when pressed with the blades alternative, quite a few of them
    > preferred the blade approach since there was no virtual drivers etc
    > and the blade environment presented a closer reality to their prod
    > Integrity environments.



    Are there many types of applications which do not really make use of
    multi-CPU ? In such a case, wouldn't splitting a multi CPU machine into
    a galaxy multi-instance allow multiple separate instances of the
    application to each use their own "1 cpu" machine ?

    Also, if you run 3 instances of VMS on a galaxy box, you could perform
    VMS or application upgrades on one node, and then progressively reboot
    the others from the new disk and perform a rolling upgrade on one
    physical machine. (although one would argue that if you need that level
    of availability, you probably want to have separate machines so that you
    can perform hardware maintenance on one machine while others remain up).

  10. Re: Galaxy on ES45

    In article ,
    "Colin Butcher" wrote:

    > Galaxy does not work on the ES45, which is one reason why I don't have one
    > of them.
    >
    > I think it's either console or IO bus related (you need a console per
    > instance, plus you need the ability to split the IO buses as on the ES47,
    > ES40 and the 4100), but I don't know for certain.


    Galaxy support was in the original plan for the ES45. The firmware work
    necessary to support it was postponed due to time-to-market pressure.

    After ES45 shipped, the FW work was postponed again, and eventually
    cancelled completely.

    Contributing factors include (in no particular order):
    1. Marvel FW work was higher priority.

    2. The Marvel systems, including ES47, were clearly better Galaxy
    systems than ES45. Once ES47 shipped, ES45 became much less interesting
    as a Galaxy platform.

    3. ES40 has serious limitations as a Galaxy platform, at least for some
    usage models. You can make 2 Galaxy instances (partitions), but their
    I/O resources are somewhat coupled. Bus resets and other events in one
    instance can spill over into the other instance. This is a hardware
    limitation; the FW and OS have to deal with it as best they can. ES45
    Galaxy would have reduced, but not eliminated, these problems.

    4. There was little perceived demand for Galaxy at the time. Lack of
    publicity and pricing problems may well have contributed. Most of the
    visible demand was better matched to Marvel than to ES45. Given the
    perceived level of demand and the difficulty making Galaxy well work on
    ES40/ES45, management decided not to finish the engineering (and
    subsequent testing) work on ES45.


    I was the engineering project leader for VMS on ES45 at the time. The
    model 1 system had already shipped, and we were working on the model 2
    upgrades, including the 1.25 GHz CPUs. The Alphaserver group was mainly
    focused on DS25, DS15, and the Marvel systems. VMS engineering was
    working on all sorts of stuff, but the platform support group had Marvel
    and Itanium work at much higher priority than Galaxy on ES45. I
    remember it being an easy decision for product management to cancel
    Galaxy on ES45. And, unless there was a lot of demand out there that
    the managers didn't see, it was the right choice.

    If anyone needs a smallish Galaxy-capable system today, I recommend
    ES47. Or a refurbished ES40 if the price must be very low.

    -- Robert

  11. Re: Galaxy on ES45

    On May 27, 4:43*pm, Robert Deininger
    wrote:
    > In article ,
    > *"Colin Butcher" wrote:
    >
    > > Galaxy does not work on the ES45, which is one reason why I don't have one
    > > of them.

    >
    > > I think it's either console or IO bus related (you need a console per
    > > instance, plus you need the ability to split the IO buses as on the ES47,
    > > ES40 and the 4100), but I don't know for certain.

    >
    > Galaxy support was in the original plan for the ES45. *The firmware work
    > necessary to support it was postponed due to time-to-market pressure.
    >
    > After ES45 shipped, the FW work was postponed again, and eventually
    > cancelled completely.
    >
    > Contributing factors include (in no particular order):
    > 1. Marvel FW work was higher priority.
    >
    > 2. The Marvel systems, including ES47, were clearly better Galaxy
    > systems than ES45. *Once ES47 shipped, ES45 became much less interesting
    > as a Galaxy platform.
    >
    > 3. ES40 has serious limitations as a Galaxy platform, at least for some
    > usage models. *You can make 2 Galaxy instances (partitions), but their
    > I/O resources are somewhat coupled. *Bus resets and other events in one
    > instance can spill over into the other instance. *This is a hardware
    > limitation; the FW and OS have to deal with it as best they can. *ES45
    > Galaxy would have reduced, but not eliminated, these problems.
    >
    > 4. There was little perceived demand for Galaxy at the time. Lack of
    > publicity and pricing problems may well have contributed. *Most of the
    > visible demand was better matched to Marvel than to ES45. * Given the
    > perceived level of demand and the difficulty making Galaxy well work on
    > ES40/ES45, management decided not to finish the engineering (and
    > subsequent testing) work on ES45.
    >
    > I was the engineering project leader for VMS on ES45 at the time. *The
    > model 1 system had already shipped, and we were working on the model 2
    > upgrades, including the 1.25 GHz CPUs. *The Alphaserver group was mainly
    > focused on DS25, DS15, and the Marvel systems. *VMS engineering was
    > working on all sorts of stuff, but the platform support group had Marvel
    > and Itanium work at much higher priority than Galaxy on ES45. *I
    > remember it being an easy decision for product management to cancel
    > Galaxy on ES45. *And, unless there was a lot of demand out there that
    > the managers didn't see, it was the right choice.
    >
    > If anyone needs a smallish Galaxy-capable system today, I recommend
    > ES47. *Or a refurbished ES40 if the price must be very low.
    >
    > * -- Robert


    Thanks for the in depth explanation Robert. Its not often we see such
    and in this case, it makes sense.


  12. Re: Galaxy on ES45

    Main, Kerry wrote:
    > From: Arne Vajh°j [mailto:arne@vajhoej.dk]
    >> But considering how VMWare sell today, then maybe Galaxy
    >> could have sold better with the right marketing and

    >
    > Well, that might be part of it, but the OpenVMS Cust might simply ask
    > "why not just run these applications on the same OS instance?"


    Other OS than VMS.

    Different VMS versions.

    They want to be able to reboot on system without effecting
    the other apps.

    Arne

  13. RE: Galaxy on ES45


    > -----Original Message-----
    > From: Arne Vajh°j [mailto:arne@vajhoej.dk]
    > Sent: June 1, 2008 10:02 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Galaxy on ES45
    >
    > Main, Kerry wrote:
    > > From: Arne Vajh°j [mailto:arne@vajhoej.dk]
    > >> But considering how VMWare sell today, then maybe Galaxy
    > >> could have sold better with the right marketing and

    > >
    > > Well, that might be part of it, but the OpenVMS Cust might simply ask
    > > "why not just run these applications on the same OS instance?"

    >
    > Other OS than VMS.


    I was talking about OpenVMS Cust's who have been doing App stacking for decades.

    >
    > Different VMS versions.


    Different VMS versions are supported in a Cluster - that's no reason to not
    consolidate to a common cluster environment.

    >
    > They want to be able to reboot on system without effecting
    > the other apps.
    >
    > Arne


    Well, I would ask "why do you want to reboot for?", but even if it were
    required, you can do that with a properly set-up cluster i.e. zero impact
    on end users. Since the load is shared in a common cluster, you do not even
    have to tell them that a specific node is being brought out of service.

    Simply set a flag (e.g. logins=0) which allows current users to continue,
    but all new users are directed to some other node in the cluster. When all
    current users on that specific server are done, simply shut that server down
    with zero impact on end users. [there are a few misc other things to consider
    like batch jobs, but these are also items that can be easily handled.]

    As John indicated, the issue with "run all on enterprise functions on Apps
    like SAP" is that you give up flexibility to adapt to changing and different
    local business requirements. And the future is all about having a nimble,
    quick to react company that is heavily focussed on rapidly changing local
    service requirements.


    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.


  14. RE: Galaxy on ES45


    > -----Original Message-----
    > From: Arne Vajh°j [mailto:arne@vajhoej.dk]
    > Sent: June 1, 2008 10:02 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Galaxy on ES45
    >
    > Main, Kerry wrote:
    > > From: Arne Vajh°j [mailto:arne@vajhoej.dk]
    > >> But considering how VMWare sell today, then maybe Galaxy
    > >> could have sold better with the right marketing and

    > >
    > > Well, that might be part of it, but the OpenVMS Cust might simply ask
    > > "why not just run these applications on the same OS instance?"

    >
    > Other OS than VMS.


    I was talking about OpenVMS Cust's who have been doing App stacking for decades.

    >
    > Different VMS versions.


    Different VMS versions are supported in a Cluster - that's no reason to not
    consolidate to a common cluster environment.

    >
    > They want to be able to reboot on system without effecting
    > the other apps.
    >
    > Arne


    Well, I would ask "why do you want to reboot for?", but even if it were
    required, you can do that with a properly set-up cluster i.e. zero impact
    on end users. Since the load is shared in a common cluster, you do not even
    have to tell them that a specific node is being brought out of service.

    Simply set a flag (e.g. logins=0) which allows current users to continue,
    but all new users are directed to some other node in the cluster. When all
    current users on that specific server are done, simply shut that server down
    with zero impact on end users. [there are a few misc other things to consider
    like batch jobs, but these are also items that can be easily handled.]

    As John indicated, the issue with "run all on enterprise functions on Apps
    like SAP" is that you give up flexibility to adapt to changing and different
    local business requirements. And the future is all about having a nimble,
    quick to react company that is heavily focussed on rapidly changing local
    service requirements.


    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.


+ Reply to Thread