[Info-vax] OT: IBM Offering $9-10 Per Share for Sun

[Neil Rieck]

IBM Reportedly Offering $9 to $10 Per Share for Sun

http://www.dailytech.com/IBM+Reportedly+Offering+9+to+10+Per+Share+for+Sun/article14757.htm

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

[David J Dachtera]

Neil Rieck wrote:
>
> IBM Reportedly Offering $9 to $10 Per Share for Sun
>
> http://www.dailytech.com/IBM+Reportedly+Offering+9+to+10+Per+Share+for+Sun/article14757.htm

Hhhmmm... Well, since HP just inked a deal to distribute and support
Solaris, I guess that would make rivals IBM and HP business partners.

D.J.D.

[Michael Kraemer]

David J Dachtera schrieb:
> Neil Rieck wrote:
>
>>IBM Reportedly Offering $9 to $10 Per Share for Sun
>>
>>http://www.dailytech.com/IBM+Reportedly+Offering+9+to+10+Per+Share+for+Sun/article14757.htm
>
>
> Hhhmmm... Well, since HP just inked a deal to distribute and support
> Solaris, I guess that would make rivals IBM and HP business partners.
>
> D.J.D.

Maybe this thing ends with some surprise:

HP dumps HP-UX on itanic (and itanic altogether) and sells Solaris on x86
IBM dumps AIX on Power and sells Solaris on Power (after having
incorporated some AIX goodies)

[JF Mezei]

Michael Kraemer wrote:

> HP dumps HP-UX on itanic (and itanic altogether) and sells Solaris on x86
> IBM dumps AIX on Power and sells Solaris on Power (after having
> incorporated some AIX goodies)

The way I see it:

HP announced alliance with Sun where HP will sell support services.
IBM buys Sun to get the Sun support revenus and prevent Sun customers
from buying support from HP.

If IBM and HP are duking it out in a pissing contest to see who has the
biggest support/service organ, then IBM buying Sun is a smart move
because it allows IBM to grow its member by 3" and prevent HP from
growing its.

[Neil Rieck]

On Apr 4, 5:26 am, Michael Kraemer <***@gsi.de> wrote:
> David J Dachtera schrieb:
>
> > Neil Rieck wrote:
>
> >>IBM Reportedly Offering $9 to $10 Per Share for Sun
>
> >>http://www.dailytech.com/IBM+Reportedly+Offering+9+to+10+Per+Share+fo...
>
> > Hhhmmm... Well, since HP just inked a deal to distribute and support
> > Solaris, I guess that would make rivals IBM and HP business partners.
>
> > D.J.D.
>
> Maybe this thing ends with some surprise:
>
> HP dumps HP-UX on itanic (and itanic altogether) and sells Solaris on x86
> IBM dumps AIX on Power and sells Solaris on Power (after having
> incorporated some AIX goodies)

My following thoughts are not based upon any hard data.

1) It was my belief that POWER enabled IBM to stay involved in
"enterprise" while they dumped their PC business to Lenovo. If true,
they will not dump POWER (but I'm not so sure about SPARC, UltraSPARC,
etc.)
http://en.wikipedia.org/wiki/SPARC
http://en.wikipedia.org/wiki/POWER

2) HPaq killed off their pre-merger chips in favor of Itanium.
http://en.wikipedia.org/wiki/PA-RISC (nothing new since 2005)
http://en.wikipedia.org/wiki/DEC_Alpha (nothing new since 2004)
http://en.wikipedia.org/wiki/Itanium (nothing new since 2007)

If Itanium development has been stalled at Intel because they are
concentrating on markets which will help them through the current
economic down turn, that leaves HP with three operating systems (HP-
UX, OpenVMS, NonStop) with not much of a future. If I was in HP upper
management, and if I gave a damn about HP's future five years down the
road, I would start a Skunk Works to get these three OSs ported to
x86-64.

(HP supports Solaris which does run on x84-64)

p.s. For years Steve Jobs denied rumors that Apple products would be
based upon Intel chips. Then in 2005 we learned that he had been
running a Skunk Works for more than 5 years to do just this. Job's
peers at HP should take note.

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

[JF Mezei]

Neil Rieck wrote:

> p.s. For years Steve Jobs denied rumors that Apple products would be
> based upon Intel chips. Then in 2005 we learned that he had been
> running a Skunk Works for more than 5 years to do just this. Job's
> peers at HP should take note.


Not quite like that. OS-X is based on freeBSD which has been available
on the 8086 for ages. So when Apple decided to go 8086, it already had
the core of its OS on the 8086 and just had to port the software
layered over the core unix.

Once you have the kernel and compilers done, the rest is fairly easy.

So, yes, there would have been skunk works to do that, but I don't think
it was 5 years. It is more likely to have been 1 or perhaps 2 years,
depending on when Apple started to negotiate with IBM and Intel for the
chips.


Consider that if VMS were ported to the 8086, they probably could reuse
much of the EFI stuff that is already written on VMS and that would save
them much time. And while they would have to write a Macro compiler for
the 8086 and perhaps another compiler, the rest of the compilers already
exist for it. So the port is not as involved as it would be if they were
to port to a brand new architecture where no compilers exist yert (like
VAX to Alpha port).

[Arne Vajhøj]

JF Mezei wrote:
> Neil Rieck wrote:
>> p.s. For years Steve Jobs denied rumors that Apple products would be
>> based upon Intel chips. Then in 2005 we learned that he had been
>> running a Skunk Works for more than 5 years to do just this. Job's
>> peers at HP should take note.
>
>
> Not quite like that. OS-X is based on freeBSD which has been available
> on the 8086 for ages. So when Apple decided to go 8086, it already had
> the core of its OS on the 8086 and just had to port the software
> layered over the core unix.

OS X is not just a FreeBSD.

The kernel is not from FreeBSD.

FreeBSD provides the upper layers.

Arne

[JF Mezei]

Neil Rieck wrote:

> p.s. For years Steve Jobs denied rumors that Apple products would be
> based upon Intel chips. Then in 2005 we learned that he had been
> running a Skunk Works for more than 5 years to do just this. Job's
> peers at HP should take note.


Another thing. Whetever skunk works happened at Apple to allow it to
start to deliver OS-X on the 8086 soon after the annoucement would have
been fully funded and approved/supported skunk works.

This is quite different from midnight hacks by devoted engineers who are
toying with a port to the 8086 and would present it to upper management
only after it had gone far enough to be presentable (or if management
lifted a ban on discussion of porting VMS/Hp-UX/NSK beyond that IA64 thing).

[Arne Vajhøj]

JF Mezei wrote:
> Another thing. Whetever skunk works happened at Apple to allow it to
> start to deliver OS-X on the 8086 soon after the annoucement would have
> been fully funded and approved/supported skunk works.
>
> This is quite different from midnight hacks by devoted engineers who are
> toying with a port to the 8086 and would present it to upper management
> only after it had gone far enough to be presentable (or if management
> lifted a ban on discussion of porting VMS/Hp-UX/NSK beyond that IA64 thing).

You can not port a full OS without it being an approved and funded
project - it is too big.

And the original skunkworks (Lockheed) were approved and funded.

Arne

[JF Mezei]

Arne Vajhøj wrote:

> You can not port a full OS without it being an approved and funded
> project - it is too big.


Correct. but you could have a midnight hack by devloted employees that
get VMS to boot on an 8086 to just beyond VMB.EXE or some other low
level as a proof of concept, and then gosub management and show them
that it is possible to do it and that the tools to port are already
there. Management could then decide to fund the rest of the project.

The advantage of a skunk works is that there is no real deadline as long
as those employees are still there. (This is different from the
Alpha->IA64 port where there was a lot of pressure to deliver ASAP
because it had been announced to customers before staff)

Alpha-IA64 required a large injection of cash to get project moving
fast. A skunk works could just find it minimally and stretch it over a
couple of years and only once you are almost ready to deliver do you
announce it and then formally inject a small wad of cash to productize
the port.

[Arne Vajhøj]

JF Mezei wrote:
> Arne Vajhøj wrote:
>> You can not port a full OS without it being an approved and funded
>> project - it is too big.
>
> Correct. but you could have a midnight hack by devloted employees that
> get VMS to boot on an 8086 to just beyond VMB.EXE or some other low
> level as a proof of concept, and then gosub management and show them
> that it is possible to do it and that the tools to port are already
> there. Management could then decide to fund the rest of the project.
>
> The advantage of a skunk works is that there is no real deadline as long
> as those employees are still there. (This is different from the
> Alpha->IA64 port where there was a lot of pressure to deliver ASAP
> because it had been announced to customers before staff)
>
> Alpha-IA64 required a large injection of cash to get project moving
> fast. A skunk works could just find it minimally and stretch it over a
> couple of years and only once you are almost ready to deliver do you
> announce it and then formally inject a small wad of cash to productize
> the port.

I have never ported an OS to a new HW platform or worked for VMS
engineering.

But I find it very difficult to believe that it is something
where the "let a handful of engineers do a little work in their
spare time" approach will produce anything usable.

It is a significant task. And the people in VMS engineering
have regular work to do.

Arne

[JF Mezei]

Arne Vajhøj wrote:

> But I find it very difficult to believe that it is something
> where the "let a handful of engineers do a little work in their
> spare time" approach will produce anything usable.

Usable ? No. Proof of concept that is usable as basis to do a full
fledged port, Yes.

The first thing that needs to be done is to find out how VMS can work
within today's 8086 architectures (modes, memory protection, registers
etc). Then they need a cross compiler to get the early stuff compiled
and I guess that start by doing the VMS interface to EFI, and other very
low level stuff like memory, process management probably up to sysboot.

Remember that our real engineers know this stuff inside out because they
are not newbies who just got 2 weeks of training. They've gone through
the port to that IA64 thing (and know how the source come is handled to
allow cross platform common source code, and many of them also did the
VAX to Alpha port.

What the midnight hack guys need to do is to show that VMS can run on
that platform by having solved any of the issues imposed by that
architecture.

Consider the port to that IA64 thing. They had to find a way to get ODS
file system to coexist with a DOS partition where EFI code resides. And
they had to make sure that IA64 had the features needed by VMS and if
now, find ways around it. Once that was done, the rest would be fairly
mechanical (but time consuming).

[Christopher]

On Apr 5, 3:59 pm, JF Mezei <***@vaxination.ca> wrote:
> Arne Vajhøj wrote:
> > But I find it very difficult to believe that it is something
> > where the "let a handful of engineers do a little work in their
> > spare time" approach will produce anything usable.
>
> Usable ? No. Proof of concept that is usable as basis to do a full
> fledged port, Yes.
>
> The first thing that needs to be done is to find out how VMS can work
> within today's 8086 architectures (modes, memory protection, registers
> etc). Then they need a cross compiler to get the early stuff compiled

A cross compiler is not necessary. gcc will compile the code handily
on an x86 windows, linux, or solaris box.

> and I guess that start by doing the VMS interface to EFI, and other very
> low level stuff like memory, process management probably up to sysboot.
>
> Remember that our real engineers know this stuff inside out because they
> are not newbies who just got 2 weeks of training. They've gone through
> the port to that IA64 thing (and know how the source come is handled to
> allow cross platform common source code, and many of them also did the
> VAX to Alpha port.
>
> What the midnight hack guys need to do is to show that VMS can run on
> that platform by having solved any of the issues imposed by that
> architecture.

The processor doesn't really have anything to do with it.

[Arne Vajhøj]

Christopher wrote:
> On Apr 5, 3:59 pm, JF Mezei <***@vaxination.ca> wrote:
>> Arne Vajhøj wrote:
>>> But I find it very difficult to believe that it is something
>>> where the "let a handful of engineers do a little work in their
>>> spare time" approach will produce anything usable.
>> Usable ? No. Proof of concept that is usable as basis to do a full
>> fledged port, Yes.
>>
>> The first thing that needs to be done is to find out how VMS can work
>> within today's 8086 architectures (modes, memory protection, registers
>> etc). Then they need a cross compiler to get the early stuff compiled
>
> A cross compiler is not necessary. gcc will compile the code handily
> on an x86 windows, linux, or solaris box.

I don't think GCC will output all necessary stuff - VMS linking and
object files do have some VMS specific features.

Arne

[Christopher]

On Apr 5, 6:23 pm, Arne Vajhøj <***@vajhoej.dk> wrote:
> Christopher wrote:
> > On Apr 5, 3:59 pm, JF Mezei <***@vaxination.ca> wrote:
> >> Arne Vajhøj wrote:
> >>> But I find it very difficult to believe that it is something
> >>> where the "let a handful of engineers do a little work in their
> >>> spare time" approach will produce anything usable.
> >> Usable ? No. Proof of concept that is usable as basis to do a full
> >> fledged port, Yes.
>
> >> The first thing that needs to be done is to find out how VMS can work
> >> within today's 8086 architectures (modes, memory protection, registers
> >> etc). Then they need a cross compiler to get the early stuff compiled
>
> > A cross compiler is not necessary. gcc will compile the code handily
> > on an x86 windows, linux, or solaris box.
>
> I don't think GCC will output all necessary stuff - VMS linking and
> object files do have some VMS specific features.
>
> Arne

A POC doesn't need to link against pre-existing VMS binaries. Just
compile all the code with gcc and use the standard linker.

[ChrisQ]

Christopher wrote:
> On Apr 5, 6:23 pm, Arne Vajhøj <***@vajhoej.dk> wrote:
>> Christopher wrote:
>>> On Apr 5, 3:59 pm, JF Mezei <***@vaxination.ca> wrote:
>>>> Arne Vajhøj wrote:
>>>>> But I find it very difficult to believe that it is something
>>>>> where the "let a handful of engineers do a little work in their
>>>>> spare time" approach will produce anything usable.
>>>> Usable ? No. Proof of concept that is usable as basis to do a full
>>>> fledged port, Yes.
>>>> The first thing that needs to be done is to find out how VMS can work
>>>> within today's 8086 architectures (modes, memory protection, registers
>>>> etc). Then they need a cross compiler to get the early stuff compiled
>>> A cross compiler is not necessary. gcc will compile the code handily
>>> on an x86 windows, linux, or solaris box.
>> I don't think GCC will output all necessary stuff - VMS linking and
>> object files do have some VMS specific features.
>>
>> Arne
>
> A POC doesn't need to link against pre-existing VMS binaries. Just
> compile all the code with gcc and use the standard linker.

I don't know if Itanium boxes are primarily pci. If so, then most of the
driver work is most likely done as well. Many should compile with little
or no change. Problem areas will be memory management, kernel and low
level bios stuff, but it's not insurmountable.

I see the main obstacle as being political in that there would be no
justification for itanium development at hp were it not for vms and
hpux. No one there would want to admit that all the money thrown at the
project was in fact effectively worthless and produced so little return.

To get back on topic, Solaris runs very successfully on X86 and is
arguably the most capable and fully featured unix around now. Added to
which it's free to use. With all the open sources linux etc code running
on Solaris, who in their right mind would want to run Linux anymore
anyway, except to hack with, especially if you consider the support
costs ?...

Regards,

Chris

[Arne Vajhøj]

ChrisQ wrote:
> To get back on topic, Solaris runs very successfully on X86 and is
> arguably the most capable and fully featured unix around now. Added to
> which it's free to use. With all the open sources linux etc code running
> on Solaris, who in their right mind would want to run Linux anymore
> anyway, except to hack with, especially if you consider the support
> costs ?...

If you look out in the real world then you will see:
- the number of Solaris system shrinking
- the number of Linux systems exploding

Apparently a lot of people see it different than you.

Arne

[Neil Rieck]

On Apr 6, 7:52 pm, Arne Vajhøj <***@vajhoej.dk> wrote:
> ChrisQ wrote:
> > To get back on topic, Solaris runs very successfully on X86 and is
> > arguably the most capable and fully featured unix around now. Added to
> > which it's free to use. With all the open sources linux etc code running
> > on Solaris, who in their right mind would want to run Linux anymore
> > anyway, except to hack with, especially if you consider the support
> > costs ?...
>
> If you look out in the real world then you will see:
> - the number of Solaris system shrinking
> - the number of Linux systems exploding
>
> Apparently a lot of people see it different than you.
>
> Arne

Oops! I just heard on the radio that the deal has fallen through.

NSR

[ChrisQ]

Arne Vajhøj wrote:
> ChrisQ wrote:
>> To get back on topic, Solaris runs very successfully on X86 and is
>> arguably the most capable and fully featured unix around now. Added to
>> which it's free to use. With all the open sources linux etc code
>> running on Solaris, who in their right mind would want to run Linux
>> anymore anyway, except to hack with, especially if you consider the
>> support costs ?...
>
> If you look out in the real world then you will see:
> - the number of Solaris system shrinking
> - the number of Linux systems exploding
>
> Apparently a lot of people see it different than you.
>
> Arne

Agreed - windows sells more than vms, which illustrates the point that
technical merit rarely has mass market appeal unless it's also hyped
through the roof. Linux was quite fashionable in corporate environments
last year, but free to install and low upfront costs doesn't mean free
to support. It's also getting overcomplex and quite opaque in terms of
required libraries and god knows what else if you want to install some
package or other. Don't know about vms now, but with Solaris, most of
the stuff you need is there and you can have a fair degree of confidence
that it has been properly regression tested when changes are made. Much
in the same way as vms in fact. of course, none of this is cheap, which
is why a quality product can never complete on price alone.

Solaris and Vms, though different in design, have similar technical aims
and have had the same one company or product ethic for 20 years or so.
Some may disagree, but they are both industrial strength os's, whereas
linux is still fairly young. It's not in any way a criticism of linux,
it's a good os, but if you had to choose for a critical application,
based on technical criteria and a solid and singleminded development
timeline, which would you choose ?.

I was quite sad hearing about the ibm takeover news, though it might be
the lesser of two evils if compared to an hp takeover. sgi just filed
for chapter 11, again and it's yet another example of the technical
diversity of computing diminishing. Diversity improves the breed and is
good for progress. If all is Intel, what progress is there other than
what they decide to hand down to us ?. Fewer choices, more expense and
probably less performance gain is my guess...

Regards,

Chris

[JF Mezei]

ChrisQ wrote:

> good for progress. If all is Intel, what progress is there other than
> what they decide to hand down to us ?. Fewer choices, more expense and
> probably less performance gain is my guess...

That is debatable. The 8086 went from a glorified toy controller to a
respectable enterprise chip. One reason was competition. The 8086 went
64 bits because AMD competed against intel and came out with it, forcing
Intel to also come out with it. When Microsoft wanted special
instructions for better video performance, they added them to the 8086.

So while sticking/standardizing to the 8086 may not generate innovation
in terms of new architectures, it will generate innovation in terms of
making the 8086 better and faster than the competitor.

[Arne Vajhøj]

Christopher wrote:
> On Apr 5, 6:23 pm, Arne Vajhøj <***@vajhoej.dk> wrote:
>> Christopher wrote:
>>> On Apr 5, 3:59 pm, JF Mezei <***@vaxination.ca> wrote:
>>>> Arne Vajhøj wrote:
>>>>> But I find it very difficult to believe that it is something
>>>>> where the "let a handful of engineers do a little work in their
>>>>> spare time" approach will produce anything usable.
>>>> Usable ? No. Proof of concept that is usable as basis to do a full
>>>> fledged port, Yes.
>>>> The first thing that needs to be done is to find out how VMS can work
>>>> within today's 8086 architectures (modes, memory protection, registers
>>>> etc). Then they need a cross compiler to get the early stuff compiled
>>> A cross compiler is not necessary. gcc will compile the code handily
>>> on an x86 windows, linux, or solaris box.
>> I don't think GCC will output all necessary stuff - VMS linking and
>> object files do have some VMS specific features.
>
> A POC doesn't need to link against pre-existing VMS binaries.

There will not be any existing VMS/x86-64 binaries to link against.

> Just
> compile all the code with gcc and use the standard linker.

If it is not VMS linker, VMS image format, VMS object format, VMS image
loader etc. then it is not VMS.

Arne

[Christopher]

On Apr 6, 7:40 pm, Arne Vajhøj <***@vajhoej.dk> wrote:
> Christopher wrote:
> > On Apr 5, 6:23 pm, Arne Vajhøj <***@vajhoej.dk> wrote:
> >> Christopher wrote:
> >>> On Apr 5, 3:59 pm, JF Mezei <***@vaxination.ca> wrote:
> >>>> Arne Vajhøj wrote:
> >>>>> But I find it very difficult to believe that it is something
> >>>>> where the "let a handful of engineers do a little work in their
> >>>>> spare time" approach will produce anything usable.
> >>>> Usable ? No. Proof of concept that is usable as basis to do a full
> >>>> fledged port, Yes.
> >>>> The first thing that needs to be done is to find out how VMS can work
> >>>> within today's 8086 architectures (modes, memory protection, registers
> >>>> etc). Then they need a cross compiler to get the early stuff compiled
> >>> A cross compiler is not necessary. gcc will compile the code handily
> >>> on an x86 windows, linux, or solaris box.
> >> I don't think GCC will output all necessary stuff - VMS linking and
> >> object files do have some VMS specific features.
>
> > A POC doesn't need to link against pre-existing VMS binaries.
>
> There will not be any existing VMS/x86-64 binaries to link against.
>
> >                                                               Just
> > compile all the code with gcc and use the standard linker.
>
> If it is not VMS linker, VMS image format, VMS object format, VMS image
> loader etc. then it is not VMS.

That's silly. If your OS is defined by your binary image type, you
have serious perspective problems.

[Arne Vajhøj]

Christopher wrote:
> On Apr 6, 7:40 pm, Arne Vajhøj <***@vajhoej.dk> wrote:
>> Christopher wrote:
>>> On Apr 5, 6:23 pm, Arne Vajhøj <***@vajhoej.dk> wrote:
>>>> Christopher wrote:
>>>>> On Apr 5, 3:59 pm, JF Mezei <***@vaxination.ca> wrote:
>>>>>> Arne Vajhøj wrote:
>>>>>>> But I find it very difficult to believe that it is something
>>>>>>> where the "let a handful of engineers do a little work in their
>>>>>>> spare time" approach will produce anything usable.
>>>>>> Usable ? No. Proof of concept that is usable as basis to do a full
>>>>>> fledged port, Yes.
>>>>>> The first thing that needs to be done is to find out how VMS can work
>>>>>> within today's 8086 architectures (modes, memory protection, registers
>>>>>> etc). Then they need a cross compiler to get the early stuff compiled
>>>>> A cross compiler is not necessary. gcc will compile the code handily
>>>>> on an x86 windows, linux, or solaris box.
>>>> I don't think GCC will output all necessary stuff - VMS linking and
>>>> object files do have some VMS specific features.
>>> A POC doesn't need to link against pre-existing VMS binaries.
>> There will not be any existing VMS/x86-64 binaries to link against.
>>
>>> Just
>>> compile all the code with gcc and use the standard linker.
>> If it is not VMS linker, VMS image format, VMS object format, VMS image
>> loader etc. then it is not VMS.
>
> That's silly. If your OS is defined by your binary image type, you
> have serious perspective problems.

It is not defining VMS, but it would not be VMS without it.

Arne

[Keith Parris]

Arne Vajhøj wrote:
> If it is not VMS linker, VMS image format, VMS object format, VMS image
> loader etc. then it is not VMS.

The fact that OpenVMS uses the standard ELF (Executable and Linkable
Format) for objects and executables on Integrity would seem to make
things easier in this area.

[Arne Vajhøj]

Keith Parris wrote:
> Arne Vajhøj wrote:
>> If it is not VMS linker, VMS image format, VMS object format, VMS image
>> loader etc. then it is not VMS.
>
> The fact that OpenVMS uses the standard ELF (Executable and Linkable
> Format) for objects and executables on Integrity would seem to make
> things easier in this area.

Does it just share some envelope format or can you compile
some code (that are not using any library calls) on Linux/I64,
move it to VMS/I64 and link with it?

Arne

[Keith Parris]

Christopher wrote:
> A cross compiler is not necessary. gcc will compile the code handily
> on an x86 windows, linux, or solaris box.

You'd need gcc front-ends for Bliss and for Macro-32, not just C.

[Arne Vajhøj]

JF Mezei wrote:
> Arne Vajhøj wrote:
>> But I find it very difficult to believe that it is something
>> where the "let a handful of engineers do a little work in their
>> spare time" approach will produce anything usable.
>
> Usable ? No. Proof of concept that is usable as basis to do a full
> fledged port, Yes.

What should be the point?

HP's management knows that it can be done.

They don't want to spend the money on it.

Doing a POC that shows it is possible is pointless.

> Remember that our real engineers know this stuff inside out because they
> are not newbies who just got 2 weeks of training. They've gone through
> the port to that IA64 thing (and know how the source come is handled to
> allow cross platform common source code, and many of them also did the
> VAX to Alpha port.

People with that level of skills are most likely already overloaded
with work.

> What the midnight hack guys need to do is to show that VMS can run on
> that platform by having solved any of the issues imposed by that
> architecture.

VMS can run on x86-64 - it is only a question about how much need
to be changed. If something is not available then that feature
will not be part of VMS on that platform.

Arne

[JF Mezei]

Arne Vajhøj wrote:

> What should be the point?
>
> HP's management knows that it can be done.

Not necesaarily. Consider NSK under Compaq/Pfeiffer where he undertook
to port NSK to Alpha. NSK had special features that required "lockstep"
which was a feature that needed to be added to Alpha (scheduled to come
with EV7, not sure if they bothered).

NSK might be able to run on 8086, but it would require special motherboard.

So it is not obvious to anyone whether VMS could run on today's 8086 on
commodity boards with EFI or whether it would need a special board, or
whether they absolutely need a certain feature be added to the 8086.

So if you have a midnight hack that looks into those issues and confirms
via that proof of concept that VMS could run on commodity EFI based 64
bit 8086s systems, this is significant information that HP should know
because if it is planning a post IA64 life, it is important to know
whether your OS can run on commodity systems or still requires special
systems be built.

The proof of concept can also provide estimates on how many man hours
would be needed (akaL how difficult the port) and whether shared code
base between alpha/IA64 and 8086 is possible.

This discussion is moot because we all know HP's commitment to VMS stops
at IA64. By the time the last IA64 systems are sold, HP will have had
VMS for 10 years and that will free it from all the DOE/COO (or whatever
it was) signed by Compaq with the military.

[Arne Vajhøj]

JF Mezei wrote:
> Arne Vajhøj wrote:
>
>> What should be the point?
>>
>> HP's management knows that it can be done.
>
> Not necesaarily. Consider NSK under Compaq/Pfeiffer where he undertook
> to port NSK to Alpha. NSK had special features that required "lockstep"
> which was a feature that needed to be added to Alpha (scheduled to come
> with EV7, not sure if they bothered).
>
> NSK might be able to run on 8086, but it would require special motherboard.

NSK in it current way of doing things has some special
hardware requirements.

VMS does not have these requirements.

And even how NSK works could be changed if HP decided to.

> So it is not obvious to anyone whether VMS could run on today's 8086 on
> commodity boards with EFI or whether it would need a special board, or
> whether they absolutely need a certain feature be added to the 8086.

It is very obvious to me.


If there is funding to make it happen they could get VMS x64 9.0 to
work.

It may require some changes. But VAX 32 bit to Alpha 64 bit certainly
came with some changes as well.

> So if you have a midnight hack that looks into those issues and confirms
> via that proof of concept that VMS could run on commodity EFI based 64
> bit 8086s systems,

I can not see why the VMS engineers would do that.

And if they did why HP senior management should consider it relevant.

> this is significant information that HP should know
> because if it is planning a post IA64 life, it is important to know
> whether your OS can run on commodity systems or still requires special
> systems be built.

It will do whatever senior management decide it will.

> The proof of concept can also provide estimates on how many man hours
> would be needed (akaL how difficult the port) and whether shared code
> base between alpha/IA64 and 8086 is possible.

They have done it twice before.

A POC may reduce the uncertainty of the estimates a bit, but basically
they do know what it will cost.

Arne

[JF Mezei]

Arne Vajhøj wrote:

> I can not see why the VMS engineers would do that.

Because they love their work ?

Why did some engineers design the DS10L out of a midnight hack ? Once it
was done, Compaq liked it and sold tousands of them in high profile uses
(genome project).

Also, consider the highly theoretical/speculative scenario when VMS
engineers learned that VMS was to be canned with IA64 and that the date
was coming soon. Consider that high end folks at HP were heard saying a
VMS port to 8086 was not possible or too expensive (excuse).

It would have been to the VMS engineer's own interests to do a proof of
concept leading to hard numbers on how big a porting effort it would be
which would have allowed VMS management to counter the false excuses
produced by those within HP not wanting VMS to thrive.


> It will do whatever senior management decide it will.

Correct. But because VMS is not a strategic product for HP, it is to the
VMS group's best self interest to try to change HP's senior managements'
minds. Not an easy job, and no garantee of success. But NOT trying
garantees that HP will let VMS wither away.

An announcement that a midnight hack resulted in a succesful boot of VMS
and a "directory" command on an 8086 server might have generated so much
good will from customers and positive feedback that HP might have had to
change its mind about letting VMS go away.

Re: they have done its twice before:

Correct. But this time around, all of the work to structure the code to
support multiple platforms on a common code base, AND they already have
the EFI interface done. So a port to 8086 would be different and more
"routine" than previous ones.

[Richard B. Gilbert]

JF Mezei wrote:
> Arne Vajhøj wrote:
>
>> I can not see why the VMS engineers would do that.
>
> Because they love their work ?
>
> Why did some engineers design the DS10L out of a midnight hack ? Once it
> was done, Compaq liked it and sold tousands of them in high profile uses
> (genome project).
>
> Also, consider the highly theoretical/speculative scenario when VMS
> engineers learned that VMS was to be canned with IA64 and that the date
> was coming soon. Consider that high end folks at HP were heard saying a
> VMS port to 8086 was not possible or too expensive (excuse).
>

Did you ever consider that, just maybe, it's NOT feasible to port VMS to
an 80x86 architecture? Recall that VMS and the VAX architecture were
designed together and that decisions were made regarding what would be
done in software and what would be done in hardware!

I'm sure that the Alpha architecture was designed with the intention of
supporting both VMS and Unix. The 80X86 architecture was designed for a
micro-computer/personal-computer that would run PC-DOS/MS-DOS. The
80x86 architecture has been a howling success and just about everyone
has used one at one time or another. It will not run VMS as we know it!

I'm aware that there's a VAX emulator program for the 80x86
architecture. As far as I'm concerned it's a toy, a curiosity. I doubt
that it can compete, in the performance arena with Alpha or IA64 hardware.

[JF Mezei]

Richard B. Gilbert wrote:

> Did you ever consider that, just maybe, it's NOT feasible to port VMS to
> an 80x86 architecture?

Yes. But it would not be because of the porting effort, it would be
because HP just doesn't care about long term viability of VMS and
consider VMS to have been in semi-maintenance mode since 2002.


> supporting both VMS and Unix. The 80X86 architecture was designed for a
> micro-computer/personal-computer that would run PC-DOS/MS-DOS.

The 8086 may have started life as a glorified toy controler, but it has
since grown up to 64 bits and equipped with serious system interfaces to
help build large systems.

>It will not run VMS as we know it!

It isn't "8086 won't run VMS", it is more like "VMS will not run on any
platform that is actively developped" once they put IA64 out of its misery.


> I'm aware that there's a VAX emulator program for the 80x86
> architecture. As far as I'm concerned it's a toy, a curiosity. I doubt
> that it can compete, in the performance arena with Alpha or IA64 hardware.

I disagree. I think that a significant portion of the remaining
installed base consists of people who have "mature" systems that are
plugged in and just work. That is why there are still so many vaxes
running plant etc.

They are not concerned about performance. If you have plant machinery
designed to produce 1 tonne of paper per hour, you can't just push a
button to make those machines go faster, so in the end you don't need a
faster computer to control those machines. So having your VAX box moved
to an emulated 8086 gives you compatibility with your older system
without any software worries and with mor readily available spare parts.

If you have a VMS based application whose needs are growing, then you
have long ago left VAX because of growing performance needs. You may
still be on Alpha or have been forced on that IA64 thing. And when IA64
is gone, then you are forced to move to another OS/platform entirely
bexause you won't be able to increase capacity of your computer.

[Michael Kraemer]

JF Mezei schrieb:

>
> They are not concerned about performance. If you have plant machinery
> designed to produce 1 tonne of paper per hour, you can't just push a
> button to make those machines go faster, so in the end you don't need a
> faster computer to control those machines. So having your VAX box moved
> to an emulated 8086 gives you compatibility with your older system
> without any software worries and with mor readily available spare parts.

Which is kind of a strange argument.
The main issue here is reliability, not speed.
Those emulators most probably run on top
of some Linux or (gulp) Windoze OS.
Now we are told here over and over again
how crap these platforms are,
crashing all the time and needing xx patches
per month etc etc.
How can such unreliable platforms host VAX/VMS ?
They would need to be at least as reliable as VAX/VMS
to be worth hosting it.
And if they are just as reliable, why not just skip VMS
and proceed with Linux/Windoze instead ?

[Bill Gunshannon]

In article <grc9pa$saq$00$***@news.t-online.com>,
Michael Kraemer <***@gsi.de> writes:
> JF Mezei schrieb:
>
>>
>> They are not concerned about performance. If you have plant machinery
>> designed to produce 1 tonne of paper per hour, you can't just push a
>> button to make those machines go faster, so in the end you don't need a
>> faster computer to control those machines. So having your VAX box moved
>> to an emulated 8086 gives you compatibility with your older system
>> without any software worries and with mor readily available spare parts.
>
> Which is kind of a strange argument.
> The main issue here is reliability, not speed.
> Those emulators most probably run on top
> of some Linux or (gulp) Windoze OS.
> Now we are told here over and over again
> how crap these platforms are,

And like sheep, you just take that at face value.

> crashing all the time and needing xx patches
> per month etc etc.

Depending on the applications running, most neither crash or need to
be patched all the time. And in the case of patches, a serious IT
infrastructure has that well in hand. I do it for two locations, one
fairly small and the other consisting of what is probably the largest
IT Enterprise in the western hemisphere, if not the world. Both of
them do just fine and can trace the majority of failures to user actions
in particular refusal of users to obey procedures.

> How can such unreliable platforms host VAX/VMS ?

Because this supposed unreliability is a figment of your imagination.

> They would need to be at least as reliable as VAX/VMS
> to be worth hosting it.

And they are.

> And if they are just as reliable, why not just skip VMS
> and proceed with Linux/Windoze instead ?

For the same reason why Linux and Windows are flourishing while VMS is
languishing. "It's the applications!!" There are applications, particularly
homegrown stuff, that runs on VMS and so the IT shop has to stay with VMS.
Sadly (for VMS) more and more of these shops are, in fact, porting their
applications off VMS. So, it looks like the end result is going to be
exactly what youe said above. They are going to "just skip VMS and
proceed with Linux/Windoze instead".

bill


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Michael Kraemer]

Bill Gunshannon schrieb:
> In article <grc9pa$saq$00$***@news.t-online.com>,
> Michael Kraemer <***@gsi.de> writes:
>>
>>Which is kind of a strange argument.
>>The main issue here is reliability, not speed.
>>Those emulators most probably run on top
>>of some Linux or (gulp) Windoze OS.
>>Now we are told here over and over again
>>how crap these platforms are,
>
> And like sheep, you just take that at face value.

I never wrote I'd buy into those exaggerated claims.
I just tried to extend the "logic" spread in this group.
If VMS is superior, it can't be hosted by inferior
OSs such as Linux and Windoze.

>
>>crashing all the time and needing xx patches
>>per month etc etc.
>

[Arne Vajhøj]

Michael Kraemer wrote:
> JF Mezei schrieb:
>> They are not concerned about performance. If you have plant machinery
>> designed to produce 1 tonne of paper per hour, you can't just push a
>> button to make those machines go faster, so in the end you don't need a
>> faster computer to control those machines. So having your VAX box moved
>> to an emulated 8086 gives you compatibility with your older system
>> without any software worries and with mor readily available spare parts.
>
> Which is kind of a strange argument.
> The main issue here is reliability, not speed.
> Those emulators most probably run on top
> of some Linux or (gulp) Windoze OS.
> Now we are told here over and over again
> how crap these platforms are,
> crashing all the time and needing xx patches
> per month etc etc.
> How can such unreliable platforms host VAX/VMS ?
> They would need to be at least as reliable as VAX/VMS
> to be worth hosting it.
> And if they are just as reliable, why not just skip VMS
> and proceed with Linux/Windoze instead ?

Your argument is correct if the stability of the OS is
not affected by how much stuff is running on it.

It could be argued that a stripped down host OS (and Linux
could be stripped down a lot) only running the VAX emulator
would be a lot more stable than the same OS running the same
apps as the VMS system.

But if we look out in the real world, then people are
switching from VMS and various commercial Unix'es to Linux
and Windows.

Arne

[JF Mezei]

BTW: BBC now reports that talks between IBM and Sun may have broken down.

[Michael Kraemer]

JF Mezei schrieb:
> BTW: BBC now reports that talks between IBM and Sun may have broken down.

which could be bad news for Sun technology because now
a certain Wintel company called HP or maybe even M$
could step in.

[Lee Witten]

Michael Kraemer <***@gsi.de> wrote in
news:grc9sc$saq$00$***@news.t-online.com:
> JF Mezei schrieb:
>> BTW: BBC now reports that talks between IBM and Sun may have broken
>> down.
>
> which could be bad news for Sun technology because now
> a certain Wintel company called HP or maybe even M$
> could step in.
>

It'd be a shame to see Sun swallowed up by a company
so averse to funding R&D like HP. Last figures I saw
said IBM spends about twice as much on R&D as a
percent of revenue as does HP. Chats I've had with
senior engineers still at HP confirm to my satisfaction
that HP's senior would be damn glad to outsource all R&D
to Intel.

[Richard B. Gilbert]

Lee Witten wrote:
> Michael Kraemer <***@gsi.de> wrote in
> news:grc9sc$saq$00$***@news.t-online.com:
>> JF Mezei schrieb:
>>> BTW: BBC now reports that talks between IBM and Sun may have broken
>>> down.
>> which could be bad news for Sun technology because now
>> a certain Wintel company called HP or maybe even M$
>> could step in.
>>
>
> It'd be a shame to see Sun swallowed up by a company
> so averse to funding R&D like HP. Last figures I saw
> said IBM spends about twice as much on R&D as a
> percent of revenue as does HP. <snip>

IBM has always understood the value of research!

H-P used to when it was younger. They've been poisoned by ink and
toner! Grab an easy buck. . . .

The trouble is that ANYBODY can make and sell ink and toner. R&D is a
little tougher!

[Michael Kraemer]

Richard B. Gilbert schrieb:
> Lee Witten wrote:
>
>> Michael Kraemer <***@gsi.de> wrote in
>> news:grc9sc$saq$00$***@news.t-online.com:
>>
>>> JF Mezei schrieb:
>>>
>>>> BTW: BBC now reports that talks between IBM and Sun may have broken
>>>> down.
>>>
>>> which could be bad news for Sun technology because now
>>> a certain Wintel company called HP or maybe even M$
>>> could step in.
>>>
>>
>> It'd be a shame to see Sun swallowed up by a company
>> so averse to funding R&D like HP. Last figures I saw
>> said IBM spends about twice as much on R&D as a percent of revenue as
>> does HP. <snip>
>
>
> IBM has always understood the value of research!
>
> H-P used to when it was younger.

That was before Belluzzo talked HP into dumping PA-RISC
(and HP-UX) because by 1998 everybody would be on Wintel.
Then he went to SGI and ruined that company as well.
After having accomplished this, he crept back to
his master at Redmond.
If you think Palmer was a bad guy, Belluzzo tops him
by a far margin.

[Bill Gunshannon]

In article <grc9sc$saq$00$***@news.t-online.com>,
Michael Kraemer <***@gsi.de> writes:
> JF Mezei schrieb:
>> BTW: BBC now reports that talks between IBM and Sun may have broken down.
>
> which could be bad news for Sun technology because now
> a certain Wintel company called HP or maybe even M$
> could step in.

Why? Do you think HP is going to offer more per sahre than IBM did?
Not likely. The thing to do now is to watch the market. If the stock
goes up breaking down talks was a good idea. If the stock goes down
they will be back a tthe bargaining table pretty quick.

bill


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Michael Kraemer]

Bill Gunshannon schrieb:
> In article <grc9sc$saq$00$***@news.t-online.com>,
> Michael Kraemer <***@gsi.de> writes:
>
>>JF Mezei schrieb:
>>
>>>BTW: BBC now reports that talks between IBM and Sun may have broken down.
>>
>>which could be bad news for Sun technology because now
>>a certain Wintel company called HP or maybe even M$
>>could step in.
>
>
> Why? Do you think HP is going to offer more per sahre than IBM did?

well, I sneaked into Sun/Solaris NGs and the people there were
not amused to be eaten by Sun's longtime favorite enemy
(the AIX community didn't even take note, BTW).
Then they were sort of happy the takeover might not happen.
Which is rather short-sighted, since it may turn out even
worse, s.a.

> Not likely. The thing to do now is to watch the market. If the stock
> goes up breaking down talks was a good idea. If the stock goes down
> they will be back a tthe bargaining table pretty quick.

The stock tanked.

[Bill Gunshannon]

In article <grdi1o$c22$00$***@news.t-online.com>,
Michael Kraemer <***@gsi.de> writes:
> Bill Gunshannon schrieb:
>> In article <grc9sc$saq$00$***@news.t-online.com>,
>> Michael Kraemer <***@gsi.de> writes:
>>
>>>JF Mezei schrieb:
>>>
>>>>BTW: BBC now reports that talks between IBM and Sun may have broken down.
>>>
>>>which could be bad news for Sun technology because now
>>>a certain Wintel company called HP or maybe even M$
>>>could step in.
>>
>>
>> Why? Do you think HP is going to offer more per sahre than IBM did?
>
> well, I sneaked into Sun/Solaris NGs and the people there were
> not amused to be eaten by Sun's longtime favorite enemy

Yes, but who cares what Usenet thinks? Have you watched their stock today.

> (the AIX community didn't even take note, BTW).
> Then they were sort of happy the takeover might not happen.
> Which is rather short-sighted, since it may turn out even
> worse, s.a.
>
>> Not likely. The thing to do now is to watch the market. If the stock
>> goes up breaking down talks was a good idea. If the stock goes down
>> they will be back a tthe bargaining table pretty quick.
>
> The stock tanked.

Yeah, I'll bet that $9-$10 a share looks pretty good about now. :-)

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Michael Kraemer]

Bill Gunshannon schrieb:

> Why? Do you think HP is going to offer more per sahre than IBM did?
> Not likely. The thing to do now is to watch the market. If the stock
> goes up breaking down talks was a good idea. If the stock goes down
> they will be back a tthe bargaining table pretty quick.

and here we go:

http://www.bloomberg.com/apps/news?pid=20601204&sid=a_Cd1zoHX4cs

[Tom Linden]

On Thu, 16 Apr 2009 06:57:35 -0700, Michael Kraemer <***@gsi.de>
wrote:

> Bill Gunshannon schrieb:
>
>> Why? Do you think HP is going to offer more per sahre than IBM did?
>> Not likely. The thing to do now is to watch the market. If the stock
>> goes up breaking down talks was a good idea. If the stock goes down
>> they will be back a tthe bargaining table pretty quick.
>
> and here we go:
>
> http://www.bloomberg.com/apps/news?pid=20601204&sid=a_Cd1zoHX4cs
>

Out of date
http://www.tgdaily.com/content/view/42048/118/


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

[Arne Vajhøj]

Tom Linden wrote:
> On Thu, 16 Apr 2009 06:57:35 -0700, Michael Kraemer <***@gsi.de>
> wrote:
>> Bill Gunshannon schrieb:
>>> Why? Do you think HP is going to offer more per sahre than IBM did?
>>> Not likely. The thing to do now is to watch the market. If the stock
>>> goes up breaking down talks was a good idea. If the stock goes down
>>> they will be back a tthe bargaining table pretty quick.
>>
>> and here we go:
>>
>> http://www.bloomberg.com/apps/news?pid=20601204&sid=a_Cd1zoHX4cs
>
> Out of date
> http://www.tgdaily.com/content/view/42048/118/

But does IBM really mean it?

I find it hard to believe that the regulatory situation has
changed so much in a couple of weeks.

Maybe they are also just playing hard to get.

Arne

[Bill Gunshannon]

In article <49e7ce0b$0$90272$***@news.sunsite.dk>,
=?ISO-8859-15?Q?Arne_Vajh=F8j?= <***@vajhoej.dk> writes:
> Tom Linden wrote:
>> On Thu, 16 Apr 2009 06:57:35 -0700, Michael Kraemer <***@gsi.de>
>> wrote:
>>> Bill Gunshannon schrieb:
>>>> Why? Do you think HP is going to offer more per sahre than IBM did?
>>>> Not likely. The thing to do now is to watch the market. If the stock
>>>> goes up breaking down talks was a good idea. If the stock goes down
>>>> they will be back a tthe bargaining table pretty quick.
>>>
>>> and here we go:
>>>
>>> http://www.bloomberg.com/apps/news?pid=20601204&sid=a_Cd1zoHX4cs
>>
>> Out of date
>> http://www.tgdaily.com/content/view/42048/118/
>
> But does IBM really mean it?
>
> I find it hard to believe that the regulatory situation has
> changed so much in a couple of weeks.
>
> Maybe they are also just playing hard to get.

I expect they really mean it. Why play hard to get? Based on the current
value of Sun Stock they could offer much less for it. As I said earlier,
I really don't see what IBM was going to get out of buying Sun but
considering its two main assets would be worthless to IBM and probably
dumped, I can see the potential for regulator scrutiny. Of course, if
IBM doesn't buy them they will probably go belly up and it would cause
the exact same problem the regulators would be upset with except they
won't be able to blame IBM.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Arne Vajhøj]

Bill Gunshannon wrote:
> In article <49e7ce0b$0$90272$***@news.sunsite.dk>,
> =?ISO-8859-15?Q?Arne_Vajh=F8j?= <***@vajhoej.dk> writes:
>> Tom Linden wrote:
>>> On Thu, 16 Apr 2009 06:57:35 -0700, Michael Kraemer <***@gsi.de>
>>> wrote:
>>>> Bill Gunshannon schrieb:
>>>>> Why? Do you think HP is going to offer more per sahre than IBM did?
>>>>> Not likely. The thing to do now is to watch the market. If the stock
>>>>> goes up breaking down talks was a good idea. If the stock goes down
>>>>> they will be back a tthe bargaining table pretty quick.
>>>> and here we go:
>>>>
>>>> http://www.bloomberg.com/apps/news?pid=20601204&sid=a_Cd1zoHX4cs
>>> Out of date
>>> http://www.tgdaily.com/content/view/42048/118/
>> But does IBM really mean it?
>>
>> I find it hard to believe that the regulatory situation has
>> changed so much in a couple of weeks.
>>
>> Maybe they are also just playing hard to get.
>
> I expect they really mean it. Why play hard to get? Based on the current
> value of Sun Stock they could offer much less for it. As I said earlier,
> I really don't see what IBM was going to get out of buying Sun but
> considering its two main assets would be worthless to IBM and probably
> dumped, I can see the potential for regulator scrutiny.

But why were IBM interested the first time ??

Arne

[JF Mezei]

Arne Vajhøj wrote:

> But why were IBM interested the first time ??


Perhaps Sun did like Compaq and hired a Wall Street Casino M&A bank, and
that bank contacted IBM and engaged talks to try to sell the concept to IBM.

Perhaps IBM was never really interested, but went thorugh th steps
needed to look into it just in case.

[Arne Vajhøj]

JF Mezei wrote:
> Arne Vajhøj wrote:
>> But why were IBM interested the first time ??
>
> Perhaps Sun did like Compaq and hired a Wall Street Casino M&A bank, and
> that bank contacted IBM and engaged talks to try to sell the concept to IBM.
>
> Perhaps IBM was never really interested, but went thorugh th steps
> needed to look into it just in case.

It does not really fit with what happened - at least not if
the gossip in the press can be believed.

According to those, then IBM did make an offer, but SUN said no
(the current CEO said yes but the previous CEO said no and he got
the board behind him). And now SUN approached IBM and IBM said no.

Arne

[Bill Gunshannon]

In article <49e7db4c$0$90274$***@news.sunsite.dk>,
Arne Vajhøj <***@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> In article <49e7ce0b$0$90272$***@news.sunsite.dk>,
>> =?ISO-8859-15?Q?Arne_Vajh=F8j?= <***@vajhoej.dk> writes:
>>> Tom Linden wrote:
>>>> On Thu, 16 Apr 2009 06:57:35 -0700, Michael Kraemer <***@gsi.de>
>>>> wrote:
>>>>> Bill Gunshannon schrieb:
>>>>>> Why? Do you think HP is going to offer more per sahre than IBM did?
>>>>>> Not likely. The thing to do now is to watch the market. If the stock
>>>>>> goes up breaking down talks was a good idea. If the stock goes down
>>>>>> they will be back a tthe bargaining table pretty quick.
>>>>> and here we go:
>>>>>
>>>>> http://www.bloomberg.com/apps/news?pid=20601204&sid=a_Cd1zoHX4cs
>>>> Out of date
>>>> http://www.tgdaily.com/content/view/42048/118/
>>> But does IBM really mean it?
>>>
>>> I find it hard to believe that the regulatory situation has
>>> changed so much in a couple of weeks.
>>>
>>> Maybe they are also just playing hard to get.
>>
>> I expect they really mean it. Why play hard to get? Based on the current
>> value of Sun Stock they could offer much less for it. As I said earlier,
>> I really don't see what IBM was going to get out of buying Sun but
>> considering its two main assets would be worthless to IBM and probably
>> dumped, I can see the potential for regulator scrutiny.
>
> But why were IBM interested the first time ??

I had heard their only interest was in the Java Technology. If this were
the case and their plan was to just dump SPARC and Solaris (they do have
much more acceptable and prfitable alternatives) I can see where they
might have regulatory oversight concerns. As it stands now, SPARC and
Solaris are probably dead meat but IBM can't be held responsible. Not
sure what will happen to the Java Technology if Sun collapses. Maybe
IBM will end out with it int he end anyway.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Arne Vajhøj]

Bill Gunshannon wrote:
> In article <49e7db4c$0$90274$***@news.sunsite.dk>,
> Arne Vajhøj <***@vajhoej.dk> writes:
>> Bill Gunshannon wrote:
>>> In article <49e7ce0b$0$90272$***@news.sunsite.dk>,
>>> =?ISO-8859-15?Q?Arne_Vajh=F8j?= <***@vajhoej.dk> writes:
>>>> Tom Linden wrote:
>>>>> On Thu, 16 Apr 2009 06:57:35 -0700, Michael Kraemer <***@gsi.de>
>>>>> wrote:
>>>>>> Bill Gunshannon schrieb:
>>>>>>> Why? Do you think HP is going to offer more per sahre than IBM did?
>>>>>>> Not likely. The thing to do now is to watch the market. If the stock
>>>>>>> goes up breaking down talks was a good idea. If the stock goes down
>>>>>>> they will be back a tthe bargaining table pretty quick.
>>>>>> and here we go:
>>>>>>
>>>>>> http://www.bloomberg.com/apps/news?pid=20601204&sid=a_Cd1zoHX4cs
>>>>> Out of date
>>>>> http://www.tgdaily.com/content/view/42048/118/
>>>> But does IBM really mean it?
>>>>
>>>> I find it hard to believe that the regulatory situation has
>>>> changed so much in a couple of weeks.
>>>>
>>>> Maybe they are also just playing hard to get.
>>> I expect they really mean it. Why play hard to get? Based on the current
>>> value of Sun Stock they could offer much less for it. As I said earlier,
>>> I really don't see what IBM was going to get out of buying Sun but
>>> considering its two main assets would be worthless to IBM and probably
>>> dumped, I can see the potential for regulator scrutiny.
>> But why were IBM interested the first time ??
>
> I had heard their only interest was in the Java Technology. If this were
> the case and their plan was to just dump SPARC and Solaris (they do have
> much more acceptable and prfitable alternatives) I can see where they
> might have regulatory oversight concerns. As it stands now, SPARC and
> Solaris are probably dead meat but IBM can't be held responsible. Not
> sure what will happen to the Java Technology if Sun collapses. Maybe
> IBM will end out with it int he end anyway.

Sounds very plausible.

But it does not explain what has changed recently.

Regarding Java, then the what SUN has is the trademarks. Practically
all the Java code has been outsourced and the various specifications
are done by the JCP. I am sure IBM and Oracle would prefer to buy
the Java trademarks instead of Microsoft, but I don't think they would
pay billions for them.

Arne

[Bill Gunshannon]

In article <gs7df6$igg$02$***@news.t-online.com>,
Michael Kraemer <***@gsi.de> writes:
> Bill Gunshannon schrieb:
>
>> Why? Do you think HP is going to offer more per sahre than IBM did?
>> Not likely. The thing to do now is to watch the market. If the stock
>> goes up breaking down talks was a good idea. If the stock goes down
>> they will be back a tthe bargaining table pretty quick.
>
> and here we go:
>
> http://www.bloomberg.com/apps/news?pid=20601204&sid=a_Cd1zoHX4cs
>

No surprises there. I guess Sun now has to hope that IBM is still
interested. Considering how much their stock has slid I guess they
should also hope IBM is willing to make the same offer. :-)

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Arne Vajhøj]

Michael Kraemer wrote:
> Bill Gunshannon schrieb:
>> Why? Do you think HP is going to offer more per sahre than IBM did?
>> Not likely. The thing to do now is to watch the market. If the stock
>> goes up breaking down talks was a good idea. If the stock goes down
>> they will be back a tthe bargaining table pretty quick.
>
> and here we go:
>
> http://www.bloomberg.com/apps/news?pid=20601204&sid=a_Cd1zoHX4cs

They don't want to do a "Yahoo".

Arne

[j***@yahoo.co.uk]

On Apr 6, 5:01 am, "Richard B. Gilbert" <***@comcast.net>
wrote:
> JF Mezei wrote:
> > Arne Vajhøj wrote:
>
> >> I can not see why the VMS engineers would do that.
>
> > Because they love their work ?
>
> > Why did some engineers design the DS10L out of a midnight hack ? Once it
> > was done, Compaq liked it and sold tousands of them in high profile uses
> > (genome project).
>
> > Also, consider the highly theoretical/speculative scenario when VMS
> > engineers learned that VMS was to be canned with IA64 and that the date
> > was coming soon. Consider that high end folks at HP were heard saying a
> > VMS port to 8086 was not possible or too expensive (excuse).
>
> Did you ever consider that, just maybe, it's NOT feasible to port VMS to
> an 80x86 architecture?  Recall that VMS and the VAX architecture were
> designed together and that decisions were made regarding what would be
> done in software and what would be done in hardware!
>
> I'm sure that the Alpha architecture was designed with the intention of
> supporting both VMS and Unix.  The 80X86 architecture was designed for a
> micro-computer/personal-computer that would run PC-DOS/MS-DOS.  The
> 80x86 architecture has been a howling success and just about everyone
> has used one at one time or another.  It will not run VMS as we know it!
>
> I'm aware that there's a VAX emulator program for the 80x86
> architecture.  As far as I'm concerned it's a toy, a curiosity.  I doubt
> that it can compete, in the performance arena with Alpha or IA64 hardware.

Fortunately these days in this picture we're not stuck with classic
x86 architecture. We're talking about its next generation successor,
the AMD64 architecture, which just happens to have succeeded in being
remarkably compatible (transparently so, in the vast majority of
cases) with classic x86 when it needs to be, whilst also behaving like
a real 64bit architecture when *that* is what's needed.

As for x86 systems hardware: it's already been pointed out that the
innards of any reasonably modern low-end Alpha (from any AlphaStation
onward) were remarkably PC-like in terms of chips and functionalities,
and the same could presumably be said to some extent for Itanium,
especially if Quickpath for Itanium ever actually comes out (even
though it's no longer going to be socket-compatible, it presumably
needs to be architecturally compatible, unless silly subsetting games
and the like come into the picture).

[Lee Witten]

***@yahoo.co.uk wrote in
news:f34e7983-8ffb-416d-8bcd-***@f32g2000vbf.googlegroups.com:
> Fortunately these days in this picture we're not stuck with classic
> x86 architecture. We're talking about its next generation successor,
> the AMD64 architecture, which just happens to have succeeded in being
> remarkably compatible (transparently so, in the vast majority of
> cases) with classic x86 when it needs to be, whilst also behaving like
> a real 64bit architecture when *that* is what's needed.

Agreed.

> As for x86 systems hardware: it's already been pointed out that the
> innards of any reasonably modern low-end Alpha (from any AlphaStation
> onward) were remarkably PC-like in terms of chips and functionalities,
> and the same could presumably be said to some extent for Itanium,
> especially if Quickpath for Itanium ever actually comes out (even
> though it's no longer going to be socket-compatible, it presumably
> needs to be architecturally compatible, unless silly subsetting games
> and the like come into the picture).

There are enough differences to make support a non-trivial effort.

And if the hardware is identical, there won't be much if any advantage
for using itanium/alpha, other than if you need to run vms.

One could have seen the itanium floating point as a strong advantage,
but it's almost nil versus the nahalem (sp) generation of x86 CPUs.

[j***@yahoo.co.uk]

On Apr 6, 1:22 pm, Lee Witten <***@nospam.com> wrote:
> ***@yahoo.co.uk wrote innews:f34e7983-8ffb-416d-8bcd-***@f32g2000vbf.googlegroups.com:
>
> > Fortunately these days in this picture we're not stuck with classic
> > x86 architecture. We're talking about its next generation successor,
> > the AMD64 architecture, which just happens to have succeeded in being
> > remarkably compatible (transparently so, in the vast majority of
> > cases) with classic x86 when it needs to be, whilst also behaving like
> > a real 64bit architecture when *that* is what's needed.
>
> Agreed.
>
> > As for x86 systems hardware: it's already been pointed out that the
> > innards of any reasonably modern low-end Alpha (from any AlphaStation
> > onward) were remarkably PC-like in terms of chips and functionalities,
> > and the same could presumably be said to some extent for Itanium,
> > especially if Quickpath for Itanium ever actually comes out (even
> > though it's no longer going to be socket-compatible, it presumably
> > needs to be architecturally compatible, unless silly subsetting games
> > and the like come into the picture).
>
> There are enough differences to make support a non-trivial effort.
>

Well, it all depends on what you mean by "trivial" and by "support".
Are there many differences between an Alpha/VMS driver for card/
chipset XYZ and an Itanium/VMS driver for card/chipset XYZ? So why
would an AMD64/VMS driver introduce significant new differences
(examples welcome)? The system core chipset may (obviously) be
different between the two families; whether Quickpath would make such
a porting exercise any easier remains to be seen.

Presumably if there was a sensible business case for doing it (porting
and qualifying on a limited subset of Proliant/AMD64 servers), it
would get done, right?

> And if the hardware is identical, there won't be much if any advantage
> for using itanium/alpha, other than if you need to run vms.
>
> One could have seen the itanium floating point as a strong advantage,
> but it's almost nil versus the nahalem (sp) generation of x86 CPUs.

Indeed. Plus for some classes of HPTC, this week's fashion seems to be
to use graphics cards as low cost high performance FP compute engines,
so long as the user doesn't mind some changes to the apps.

[Richard B. Gilbert]

***@yahoo.co.uk wrote:
> On Apr 6, 5:01 am, "Richard B. Gilbert" <***@comcast.net>
> wrote:
>> JF Mezei wrote:
>>> Arne Vajhøj wrote:
>>>> I can not see why the VMS engineers would do that.
>>> Because they love their work ?
>>> Why did some engineers design the DS10L out of a midnight hack ? Once it
>>> was done, Compaq liked it and sold tousands of them in high profile uses
>>> (genome project).
>>> Also, consider the highly theoretical/speculative scenario when VMS
>>> engineers learned that VMS was to be canned with IA64 and that the date
>>> was coming soon. Consider that high end folks at HP were heard saying a
>>> VMS port to 8086 was not possible or too expensive (excuse).
>> Did you ever consider that, just maybe, it's NOT feasible to port VMS to
>> an 80x86 architecture? Recall that VMS and the VAX architecture were
>> designed together and that decisions were made regarding what would be
>> done in software and what would be done in hardware!
>>
>> I'm sure that the Alpha architecture was designed with the intention of
>> supporting both VMS and Unix. The 80X86 architecture was designed for a
>> micro-computer/personal-computer that would run PC-DOS/MS-DOS. The
>> 80x86 architecture has been a howling success and just about everyone
>> has used one at one time or another. It will not run VMS as we know it!
>>
>> I'm aware that there's a VAX emulator program for the 80x86
>> architecture. As far as I'm concerned it's a toy, a curiosity. I doubt
>> that it can compete, in the performance arena with Alpha or IA64 hardware.
>
> Fortunately these days in this picture we're not stuck with classic
> x86 architecture. We're talking about its next generation successor,
> the AMD64 architecture, which just happens to have succeeded in being
> remarkably compatible (transparently so, in the vast majority of
> cases) with classic x86 when it needs to be, whilst also behaving like
> a real 64bit architecture when *that* is what's needed.
>
> As for x86 systems hardware: it's already been pointed out that the
> innards of any reasonably modern low-end Alpha (from any AlphaStation
> onward) were remarkably PC-like in terms of chips and functionalities,

The Alpha was intended to be able to run Windows. AFAIK few people ever
did but the possibility was there!

[Bill Gunshannon]

In article <***@comcast.net>,
"Richard B. Gilbert" <***@comcast.net> writes:
> ***@yahoo.co.uk wrote:
>> On Apr 6, 5:01 am, "Richard B. Gilbert" <***@comcast.net>
>> wrote:
>>> JF Mezei wrote:
>>>> Arne Vajhøj wrote:
>>>>> I can not see why the VMS engineers would do that.
>>>> Because they love their work ?
>>>> Why did some engineers design the DS10L out of a midnight hack ? Once it
>>>> was done, Compaq liked it and sold tousands of them in high profile uses
>>>> (genome project).
>>>> Also, consider the highly theoretical/speculative scenario when VMS
>>>> engineers learned that VMS was to be canned with IA64 and that the date
>>>> was coming soon. Consider that high end folks at HP were heard saying a
>>>> VMS port to 8086 was not possible or too expensive (excuse).
>>> Did you ever consider that, just maybe, it's NOT feasible to port VMS to
>>> an 80x86 architecture? Recall that VMS and the VAX architecture were
>>> designed together and that decisions were made regarding what would be
>>> done in software and what would be done in hardware!
>>>
>>> I'm sure that the Alpha architecture was designed with the intention of
>>> supporting both VMS and Unix. The 80X86 architecture was designed for a
>>> micro-computer/personal-computer that would run PC-DOS/MS-DOS. The
>>> 80x86 architecture has been a howling success and just about everyone
>>> has used one at one time or another. It will not run VMS as we know it!
>>>
>>> I'm aware that there's a VAX emulator program for the 80x86
>>> architecture. As far as I'm concerned it's a toy, a curiosity. I doubt
>>> that it can compete, in the performance arena with Alpha or IA64 hardware.
>>
>> Fortunately these days in this picture we're not stuck with classic
>> x86 architecture. We're talking about its next generation successor,
>> the AMD64 architecture, which just happens to have succeeded in being
>> remarkably compatible (transparently so, in the vast majority of
>> cases) with classic x86 when it needs to be, whilst also behaving like
>> a real 64bit architecture when *that* is what's needed.
>>
>> As for x86 systems hardware: it's already been pointed out that the
>> innards of any reasonably modern low-end Alpha (from any AlphaStation
>> onward) were remarkably PC-like in terms of chips and functionalities,
>
> The Alpha was intended to be able to run Windows. AFAIK few people ever
> did but the possibility was there!

The very first Alpha I saw was running Windows. It lasted about a week
before being replaced with an Intel box running Windows. Anyone want to
hazard a guess as to why it was abandoned?


No applications!!!

Now, where have we heard this before?

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Arne Vajhøj]

Richard B. Gilbert wrote:
> ***@yahoo.co.uk wrote:
>> As for x86 systems hardware: it's already been pointed out that the
>> innards of any reasonably modern low-end Alpha (from any AlphaStation
>> onward) were remarkably PC-like in terms of chips and functionalities,
>
> The Alpha was intended to be able to run Windows. AFAIK few people ever
> did but the possibility was there!

For a few years NT Alpha actually sold decent for various server
usage.

Arne

[Bill Gunshannon]

In article <***@giganews.com>,
"Richard B. Gilbert" <***@comcast.net> writes:
> JF Mezei wrote:
>> Arne Vajhøj wrote:
>>
>>> I can not see why the VMS engineers would do that.
>>
>> Because they love their work ?
>>
>> Why did some engineers design the DS10L out of a midnight hack ? Once it
>> was done, Compaq liked it and sold tousands of them in high profile uses
>> (genome project).
>>
>> Also, consider the highly theoretical/speculative scenario when VMS
>> engineers learned that VMS was to be canned with IA64 and that the date
>> was coming soon. Consider that high end folks at HP were heard saying a
>> VMS port to 8086 was not possible or too expensive (excuse).
>>
>
> Did you ever consider that, just maybe, it's NOT feasible to port VMS to
> an 80x86 architecture?

Ridiculous. There is nothing a VAX could do that modern CPU's can't.

> Recall that VMS and the VAX architecture were
> designed together and that decisions were made regarding what would be
> done in software and what would be done in hardware!


And still it was ported to Alpha and IA64 and while you might say
that the Alpha was designed with at least the knowledge of VMS, IA64
definitely was not.

>
> I'm sure that the Alpha architecture was designed with the intention of
> supporting both VMS and Unix.

A real big assumption. I, personally, doubt the hardware engineers
who designed Alpha had anything but a user level knowledge of VMS.

> The 80X86 architecture was designed for a
> micro-computer/personal-computer that would run PC-DOS/MS-DOS.

That assumption is also ridiculous. The 80x86 architecture was already
on it's path before MSDOS was created. You do know that Intel was not
the first choice for the IBM PC. It's just too bad it won in the long run.

> The
> 80x86 architecture has been a howling success and just about everyone
> has used one at one time or another. It will not run VMS as we know it!

Again, there is no evidence to support that claim.

>
> I'm aware that there's a VAX emulator program for the 80x86
> architecture. As far as I'm concerned it's a toy, a curiosity. I doubt
> that it can compete, in the performance arena with Alpha or IA64 hardware.

I think the Charon people would take you to task over that statement.
There are a lot of production shops using VAX emulation and will probably
be a lot more. If an emulator running on the x86 architecture can provide
everything needed for VMS to function, the a port is very doable with,
at most, an HAL needed. But even that is pure speculation. It is most
likely that VMS could be ported and run just fine on the current Intel/AMD
64bit architectures. It is a purely business and not a technical decision
not to do it.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Arne Vajhøj]

Bill Gunshannon wrote:
>> Recall that VMS and the VAX architecture were
>> designed together and that decisions were made regarding what would be
>> done in software and what would be done in hardware!
>
>
> And still it was ported to Alpha and IA64 and while you might say
> that the Alpha was designed with at least the knowledge of VMS, IA64
> definitely was not.

Yup.

>> I'm sure that the Alpha architecture was designed with the intention of
>> supporting both VMS and Unix.
>
> A real big assumption. I, personally, doubt the hardware engineers
> who designed Alpha had anything but a user level knowledge of VMS.

Considering the support for VAX float, VMS PALCode etc. then that
does not sound likely.

Arne

[Christopher]

On Apr 6, 12:01 am, "Richard B. Gilbert" <***@comcast.net>
wrote:
> JF Mezei wrote:
> > Arne Vajhøj wrote:
>
> >> I can not see why the VMS engineers would do that.
>
> > Because they love their work ?
>
> > Why did some engineers design the DS10L out of a midnight hack ? Once it
> > was done, Compaq liked it and sold tousands of them in high profile uses
> > (genome project).
>
> > Also, consider the highly theoretical/speculative scenario when VMS
> > engineers learned that VMS was to be canned with IA64 and that the date
> > was coming soon. Consider that high end folks at HP were heard saying a
> > VMS port to 8086 was not possible or too expensive (excuse).
>
> Did you ever consider that, just maybe, it's NOT feasible to port VMS to
> an 80x86 architecture?  Recall that VMS and the VAX architecture were
> designed together and that decisions were made regarding what would be
> done in software and what would be done in hardware!

That is just silly. VMS will run on ANY Turing-complete
architecture. It may run better on certain archs than others, but
there is nothing so special about VMS that it can't be made to run on
x64 platforms.

[Bob Koehler]

>
> That is just silly. VMS will run on ANY Turing-complete
> architecture. It may run better on certain archs than others, but
> there is nothing so special about VMS that it can't be made to run on
> x64 platforms.

Turing said nothing about performance. AS far as Turing is
considered SIMH running VMS on a x86 is VMS running on an x86.

But there are no major architectural needs for VMS that x86 doesn't
already handle.

[Bill Gunshannon]

In article <e+***@eisner.encompasserve.org>,
***@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>
>> That is just silly. VMS will run on ANY Turing-complete
>> architecture. It may run better on certain archs than others, but
>> there is nothing so special about VMS that it can't be made to run on
>> x64 platforms.
>
> Turing said nothing about performance. AS far as Turing is
> considered SIMH running VMS on a x86 is VMS running on an x86.

Especially if you stop thinking about SIMH on Windows, DOS or Linux as
anything but an HAL.

>
> But there are no major architectural needs for VMS that x86 doesn't
> already handle.

Porting to the x86 architecture and the 64bit version in particular has
never been about architectural needs it is about management desires.

bill


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Arne Vajhøj]

Christopher wrote:
> On Apr 6, 12:01 am, "Richard B. Gilbert" <***@comcast.net>
> wrote:
>> JF Mezei wrote:
>>> Arne Vajhøj wrote:
>>>> I can not see why the VMS engineers would do that.
>>> Because they love their work ?
>>> Why did some engineers design the DS10L out of a midnight hack ? Once it
>>> was done, Compaq liked it and sold tousands of them in high profile uses
>>> (genome project).
>>> Also, consider the highly theoretical/speculative scenario when VMS
>>> engineers learned that VMS was to be canned with IA64 and that the date
>>> was coming soon. Consider that high end folks at HP were heard saying a
>>> VMS port to 8086 was not possible or too expensive (excuse).
>> Did you ever consider that, just maybe, it's NOT feasible to port VMS to
>> an 80x86 architecture? Recall that VMS and the VAX architecture were
>> designed together and that decisions were made regarding what would be
>> done in software and what would be done in hardware!
>
> That is just silly. VMS will run on ANY Turing-complete
> architecture.

Computer science can prove that.

But it does not have any practical point.

I believe they have a 2 state 3 color Turing machine.

I don't think running VMS on that would work very well.

Arne

[Arne Vajhøj]

Richard B. Gilbert wrote:
> Did you ever consider that, just maybe, it's NOT feasible to port VMS to
> an 80x86 architecture? Recall that VMS and the VAX architecture were
> designed together and that decisions were made regarding what would be
> done in software and what would be done in hardware!
>
> I'm sure that the Alpha architecture was designed with the intention of
> supporting both VMS and Unix. The 80X86 architecture was designed for a
> micro-computer/personal-computer that would run PC-DOS/MS-DOS.

I64 was not designed for VMS and they still managed to get it working.

> It will not run VMS as we know it!

If DCL and all the API's work like they always have then it will
be VMS for the users. The users does not really care about the
various workarounds that may have been necessary deep insider
scheduler/memory management/IO to get things working.

Arne

[Arne Vajhøj]

JF Mezei wrote:
> Arne Vajhøj wrote:
>> I can not see why the VMS engineers would do that.
>
> Because they love their work ?

I think most of them love their job more than their work. They
have families to feed just like everybody else.

> Also, consider the highly theoretical/speculative scenario when VMS
> engineers learned that VMS was to be canned with IA64 and that the date
> was coming soon. Consider that high end folks at HP were heard saying a
> VMS port to 8086 was not possible or too expensive (excuse).
>
> It would have been to the VMS engineer's own interests to do a proof of
> concept leading to hard numbers on how big a porting effort it would be
> which would have allowed VMS management to counter the false excuses
> produced by those within HP not wanting VMS to thrive.

Countering false excuses from senior management with a POC seems
more likely to get the employees black marks in their reviews than
changing senior managements decision.

>> It will do whatever senior management decide it will.
>
> Correct. But because VMS is not a strategic product for HP, it is to the
> VMS group's best self interest to try to change HP's senior managements'
> minds. Not an easy job, and no garantee of success. But NOT trying
> garantees that HP will let VMS wither away.
>
> An announcement that a midnight hack resulted in a succesful boot of VMS
> and a "directory" command on an 8086 server might have generated so much
> good will from customers and positive feedback that HP might have had to
> change its mind about letting VMS go away.

Goodwill does not matter much.

Get orders for 5 B$ of VMS/x86-64 equipment and they will listen.

Arne

[Keith Parris]

Arne Vajhøj wrote:
> JF Mezei wrote:
>> Not necesaarily. Consider NSK under Compaq/Pfeiffer where he undertook
>> to port NSK to Alpha. NSK had special features that required "lockstep"
>> which was a feature that needed to be added to Alpha (scheduled to come
>> with EV7, not sure if they bothered).
...
> NSK in it current way of doing things has some special
> hardware requirements.
...
> And even how NSK works could be changed if HP decided to.

(Probably because Lockstepping started to interfere with processor
performance) NSK changed course for Itanium and no longer requires
Lockstep -- they took a different approach called NonStop Advanced
Architecture (NSAA) where instead of having two pairs of lock-stepped
processors, they instead compare the outputs of 3 processors. Cheaper,
faster, and can use mainstream processors. See
http://h20223.www2.hp.com/NonStopComputing/cache/77119-0-0-0-121.html

[j***@yahoo.co.uk]

On Apr 14, 10:08 pm, Keith Parris <***@yahoo.com>
wrote:
> Arne Vajhøj wrote:
> > JF Mezei wrote:
> >> Not necesaarily. Consider NSK under Compaq/Pfeiffer where he undertook
> >> to port NSK to Alpha. NSK had special features that required "lockstep"
> >> which was a feature that needed to be added to Alpha (scheduled to come
> >> with EV7, not sure if they bothered).
> ...
> > NSK in it current way of doing things has some special
> > hardware requirements.
> ...
> > And even how NSK works could be changed if HP decided to.
>
> (Probably because Lockstepping started to interfere with processor
> performance) NSK changed course for Itanium and no longer requires
> Lockstep -- they took a different approach called NonStop Advanced
> Architecture (NSAA) where instead of having two pairs of lock-stepped
> processors, they instead compare the outputs of 3 processors. Cheaper,
> faster, and can use mainstream processors. Seehttp://h20223.www2.hp.com/NonStopComputing/cache/77119-0-0-0-121.html

That's interesting. I'd always wondered how "lockstep" (whatever it
actually meant) on Alpha would cope with the kind of "soft errors" you
are likely to see from time to time in modern systems - a routine
cache miss on one processor but not on its other half needn't
necessarily be fatal, but on a trivial level would result in loss of
exact synchronisation between the two processors.

Perhaps you can point to a paper with a more detailed description of
what "lockstep" has traditionally meant? The one I've just checked,
"Fault Tolerance in Tandem Computer Systems" [1] goes back before
"mainstream" MIPS RISC chips came into the Tandem family, and seems to
state that the processor chips themselves weren't necessarily in
lockstep, only their interactions with the IO bus needed to be in sync
(eg page 6, 3rd paragraph), because this simplifies the error
detection problem. That architecture would also seemingly have
eliminated any need for two MIPS chips to be in lockstep (and, by the
same logic, eliminates the need for two EV7 chips to be in lockstep)
by using software and a reliable message passing IO bus to make sure
that *the software's view of the system* consistently survives any
single hardware or software failure.

When you said "can use mainstream processors", do you mean NonStop for
AMD64 is on the way, or did mainstream get redefined yet again?

[1] http://www.hpl.hp.com/techreports/tandem/TR-90.5.pdf

[j***@yahoo.co.uk]

On Apr 14, 11:30 pm, ***@yahoo.co.uk wrote:
> On Apr 14, 10:08 pm, Keith Parris <***@yahoo.com>
> wrote:
>
>
>
> > Arne Vajhøj wrote:
> > > JF Mezei wrote:
> > >> Not necesaarily. Consider NSK under Compaq/Pfeiffer where he undertook
> > >> to port NSK to Alpha. NSK had special features that required "lockstep"
> > >> which was a feature that needed to be added to Alpha (scheduled to come
> > >> with EV7, not sure if they bothered).
> > ...
> > > NSK in it current way of doing things has some special
> > > hardware requirements.
> > ...
> > > And even how NSK works could be changed if HP decided to.
>
> > (Probably because Lockstepping started to interfere with processor
> > performance) NSK changed course for Itanium and no longer requires
> > Lockstep -- they took a different approach called NonStop Advanced
> > Architecture (NSAA) where instead of having two pairs of lock-stepped
> > processors, they instead compare the outputs of 3 processors. Cheaper,
> > faster, and can use mainstream processors. Seehttp://h20223.www2.hp.com/NonStopComputing/cache/77119-0-0-0-121.html
>
> That's interesting. I'd always wondered how "lockstep" (whatever it
> actually meant) on Alpha would cope with the kind of "soft errors" you
> are likely to see from time to time in modern systems - a routine
> cache miss on one processor but not on its other half needn't
> necessarily be fatal, but on a trivial level would result in loss of
> exact synchronisation between the two processors.
>
> Perhaps you can point to a paper with a more detailed description of
> what "lockstep" has traditionally meant? The one I've just checked,
> "Fault Tolerance in Tandem Computer Systems" [1] goes back before
> "mainstream" MIPS RISC chips came into the Tandem family, and seems to
> state that the processor chips themselves weren't necessarily in
> lockstep, only their interactions with the IO bus needed to be in sync
> (eg page 6, 3rd paragraph), because this simplifies the error
> detection problem. That architecture would also seemingly have
> eliminated any need for two MIPS chips to be in lockstep (and, by the
> same logic, eliminates the need for two EV7 chips to be in lockstep)
> by using software and a reliable message passing IO bus to make sure
> that *the software's view of the system* consistently survives any
> single hardware or software failure.
>
> When you said "can use mainstream processors", do you mean NonStop for
> AMD64 is on the way, or did mainstream get redefined yet again?
>
> [1]http://www.hpl.hp.com/techreports/tandem/TR-90.5.pdf

Bah humbug. "routine cache miss" should have been more like "routine
random soft uncorrectable cache error (which might typically just end
up being treated as a cache miss)". Sorry for the error.

[Arne Vajhøj]

Keith Parris wrote:
> Arne Vajhøj wrote:
>> JF Mezei wrote:
>>> Not necesaarily. Consider NSK under Compaq/Pfeiffer where he undertook
>>> to port NSK to Alpha. NSK had special features that required "lockstep"
>>> which was a feature that needed to be added to Alpha (scheduled to come
>>> with EV7, not sure if they bothered).
> ...
>> NSK in it current way of doing things has some special
>> hardware requirements.
> ...
>> And even how NSK works could be changed if HP decided to.
>
> (Probably because Lockstepping started to interfere with processor
> performance) NSK changed course for Itanium and no longer requires
> Lockstep -- they took a different approach called NonStop Advanced
> Architecture (NSAA) where instead of having two pairs of lock-stepped
> processors, they instead compare the outputs of 3 processors. Cheaper,
> faster, and can use mainstream processors. See
> http://h20223.www2.hp.com/NonStopComputing/cache/77119-0-0-0-121.html

Not surprising.

Arne

[Richard B. Gilbert]

Arne Vajhøj wrote:
> Keith Parris wrote:
>> Arne Vajhøj wrote:
>>> JF Mezei wrote:
>>>> Not necesaarily. Consider NSK under Compaq/Pfeiffer where he undertook
>>>> to port NSK to Alpha. NSK had special features that required "lockstep"
>>>> which was a feature that needed to be added to Alpha (scheduled to come
>>>> with EV7, not sure if they bothered).
>> ...
>>> NSK in it current way of doing things has some special
>>> hardware requirements.
>> ...
>>> And even how NSK works could be changed if HP decided to.
>>
>> (Probably because Lockstepping started to interfere with processor
>> performance) NSK changed course for Itanium and no longer requires
>> Lockstep -- they took a different approach called NonStop Advanced
>> Architecture (NSAA) where instead of having two pairs of lock-stepped
>> processors, they instead compare the outputs of 3 processors. Cheaper,
>> faster, and can use mainstream processors. See
>> http://h20223.www2.hp.com/NonStopComputing/cache/77119-0-0-0-121.html
>
> Not surprising.
>
> Arne

"I've told you once, I've told you twice, what I tell you three times is
true."

[Richard B. Gilbert]

Arne Vajhøj wrote:
> JF Mezei wrote:
>> Arne Vajhøj wrote:
>>> But I find it very difficult to believe that it is something
>>> where the "let a handful of engineers do a little work in their
>>> spare time" approach will produce anything usable.
>>
>> Usable ? No. Proof of concept that is usable as basis to do a full
>> fledged port, Yes.
>
> What should be the point?
>
> HP's management knows that it can be done.
>
> They don't want to spend the money on it.
>
> Doing a POC that shows it is possible is pointless.
>
>> Remember that our real engineers know this stuff inside out because they
>> are not newbies who just got 2 weeks of training. They've gone through
>> the port to that IA64 thing (and know how the source come is handled to
>> allow cross platform common source code, and many of them also did the
>> VAX to Alpha port.
>
> People with that level of skills are most likely already overloaded
> with work.
>
>> What the midnight hack guys need to do is to show that VMS can run on
>> that platform by having solved any of the issues imposed by that
>> architecture.
>
> VMS can run on x86-64 - it is only a question about how much need
> to be changed. If something is not available then that feature
> will not be part of VMS on that platform.
>
> Arne

One of the best parts of the VAX-Alpha port was that VMS remained VMS
and if your application code did not have hardware dependencies, such as
hard coded 512 byte page size, the port was a breeze! You called the
same system services with the same arguments and got the same results.

I ported Tony Ivanov's "make" utility to Alpha. I had to clean up a few
things to make them conform to the ANSI C Standard and make the compiler
quit complaining. Once I cleaned up the K&Risms it compiled without
error and worked. ISTR that I found and fixed a fairly trivial bug
along the way. I think I also ported Gnu grep and Gnu gawk around the
same time. Those ports were also trivial to do; make the compiler stop
complaining and they just worked.

A VMS port that does not support all the features of VMS would be a
pretty lame port!

[Arne Vajhøj]

Richard B. Gilbert wrote:
> Arne Vajhøj wrote:
>> JF Mezei wrote:
>>> Arne Vajhøj wrote:
>>>> But I find it very difficult to believe that it is something
>>>> where the "let a handful of engineers do a little work in their
>>>> spare time" approach will produce anything usable.
>>>
>>> Usable ? No. Proof of concept that is usable as basis to do a full
>>> fledged port, Yes.
>>
>> What should be the point?
>>
>> HP's management knows that it can be done.
>>
>> They don't want to spend the money on it.
>>
>> Doing a POC that shows it is possible is pointless.
>>
>>> Remember that our real engineers know this stuff inside out because they
>>> are not newbies who just got 2 weeks of training. They've gone through
>>> the port to that IA64 thing (and know how the source come is handled to
>>> allow cross platform common source code, and many of them also did the
>>> VAX to Alpha port.
>>
>> People with that level of skills are most likely already overloaded
>> with work.
>>
>>> What the midnight hack guys need to do is to show that VMS can run on
>>> that platform by having solved any of the issues imposed by that
>>> architecture.
>>
>> VMS can run on x86-64 - it is only a question about how much need
>> to be changed. If something is not available then that feature
>> will not be part of VMS on that platform.
>
> One of the best parts of the VAX-Alpha port was that VMS remained VMS
> and if your application code did not have hardware dependencies, such as
> hard coded 512 byte page size, the port was a breeze! You called the
> same system services with the same arguments and got the same results.
>
> I ported Tony Ivanov's "make" utility to Alpha. I had to clean up a few
> things to make them conform to the ANSI C Standard and make the compiler
> quit complaining. Once I cleaned up the K&Risms it compiled without
> error and worked. ISTR that I found and fixed a fairly trivial bug
> along the way. I think I also ported Gnu grep and Gnu gawk around the
> same time. Those ports were also trivial to do; make the compiler stop
> complaining and they just worked.
>
> A VMS port that does not support all the features of VMS would be a
> pretty lame port!

The C RTL and VMS system services are not that dependent on the
hardware.

4 modes and some page protection is what comes to my mind.

Getting HLL code and DCL scipts to run should not be a problem.

The VMS core with scheduling, memory management and IO would need
to use the features available.

Just as they did for I64. It was not designed for VMS as the
two previous were.

Arne

[Bob Koehler]

Richard B. Gilbert wrote:
> ***@yahoo.co.uk wrote:
>> As for x86 systems hardware: it's already been pointed out that the
>> innards of any reasonably modern low-end Alpha (from any AlphaStation
>> onward) were remarkably PC-like in terms of chips and functionalities,
>
> The Alpha was intended to be able to run Windows. AFAIK few people ever
> did but the possibility was there!

The Alpha was designed to be OS neuteral. It still is.

[Michael Austin]

Bob Koehler wrote:
> Richard B. Gilbert wrote:
>> ***@yahoo.co.uk wrote:
>>> As for x86 systems hardware: it's already been pointed out that the
>>> innards of any reasonably modern low-end Alpha (from any AlphaStation
>>> onward) were remarkably PC-like in terms of chips and functionalities,
>> The Alpha was intended to be able to run Windows. AFAIK few people ever
>> did but the possibility was there!
>
> The Alpha was designed to be OS neuteral. It still is.
>


And if would dig back through the cobwebs in your brains you would
recall that Alpha was the PRIMARY development platform for WNT from it's
inception in early 91/92 until the late 90's (98/99 timeframe IIRC - my
cobwebs fog things up too).

And there were lots of people in the early '90s that did run W-NT on
Windows. One of the 2100's I owned for a long time was initially a WNT
box. (Never while I owned it though :) as I immediately dumped it and
installed VMS.)

[j***@yahoo.co.uk]

On Apr 7, 3:38 pm, Michael Austin <***@firstdbasource.com> wrote:
> Bob Koehler wrote:
> >  Richard B. Gilbert wrote:
> >> ***@yahoo.co.uk wrote:
> >>> As for x86 systems hardware: it's already been pointed out that the
> >>> innards of any reasonably modern low-end Alpha (from any AlphaStation
> >>> onward) were remarkably PC-like in terms of chips and functionalities,
> >> The Alpha was intended to be able to run Windows.  AFAIK few people ever
> >> did but the possibility was there!
>
> >    The Alpha was designed to be OS neuteral.  It still is.
>
> And if would dig back through the cobwebs in your brains you would
> recall that Alpha was the PRIMARY development platform for WNT from it's
> inception in early 91/92 until the late 90's (98/99 timeframe IIRC - my
> cobwebs fog things up too).
>
> And there were lots of people in the early '90s that did run W-NT on
> Windows. One of the 2100's I owned for a long time was initially a WNT
> box. (Never while I owned it though :) as I immediately dumped it and
> installed VMS.)

In the early days of Windows NT, it was a multi-platform OS, with
versions for x86 and Alpha and MIPS and PowerPC.

Some early NT Alphas did well in some specific applications, eg
PostScript to raster image conversion for high end imagesetters in the
print industry - NT Alphas ran existing Windows apps a whole lot
faster than than the competition did.

But in the general market, Alpha was hindered by at least two major
factors, one technical which was duly fixed (the lack of byte
operations in EV4 did get fixed in due course). And another one leads
right back to Palmer and Gates; remember the Gates quote "Bob, you can
be Larry's friend or you can be my friend" (slightly paraphrased).

http://www.nytimes.com/1998/09/10/business/digital-employees-tell-of-threats-by-gates-over-product.html

Palmer foolishly took Gates seriously, perhaps not realising that
Gates would soon drop what little NT/Alpha support had actually
existed (about as much as exists today for Itanium - an OS, bits of an
IDE, some server bits), and not realising that MS would soon sign a
deal with HP for "premier class services" when DEC had seemingly
already been promised exclusivity on a similar deal.

Not much later, DEC HQ were made another promise which turned out to
be a p.o.s - in the Intel/DEC patent settlement, "drop your
unaffordable Alpha stuff and we (Intel) will supply you the world's
first and best and cheapest (because of volume) industry standard
64bit chips". Well, it turns out it was AMD that got to define
"industry standard 64bit" at an affordable price, and HP-UX and VMS
are duly looking a little bit more vulnerable than they otherwise
would be.

[JF Mezei]

***@yahoo.co.uk wrote:

> http://www.nytimes.com/1998/09/10/business/digital-employees-tell-of-threats-by-gates-over-product.html

Interesting article. At the time this decision was made (1997), Palmer
was already working to shape Digital so that Compaq could purchase it.
(Palmer started to shape Digital for Compaq a full 3 years prior to the
announcement of the takeover).

Seems to me that Compaq would have been involved in influencing the
pro-Microsoft decision since Compaq wouldn't have wanted to negatively
impact its own relationship with Microsoft once it purchased Digital.

[Arne Vajhøj]

***@yahoo.co.uk wrote:
> Some early NT Alphas did well in some specific applications, eg
> PostScript to raster image conversion for high end imagesetters in the
> print industry - NT Alphas ran existing Windows apps a whole lot
> faster than than the competition did.

I remember Oracle/SQLServer/Exchange servers running on NT/Alpha.

Arne

[Lee Witten]

Michael Austin <***@firstdbasource.com> wrote in
news:NzJCl.28594$***@nlpi067.nbdc.sbc.com:
> And if would dig back through the cobwebs in your brains you would
> recall that Alpha was the PRIMARY development platform for WNT from
> it's inception in early 91/92 until the late 90's (98/99 timeframe
> IIRC - my cobwebs fog things up too).

The Alphaserver 4100 was one hell of a WNT server in its day.

It wouldn't surprise me if M$ owned many, many of them.

[Richard B. Gilbert]

Bob Koehler wrote:
> Richard B. Gilbert wrote:
>> ***@yahoo.co.uk wrote:
>>> As for x86 systems hardware: it's already been pointed out that the
>>> innards of any reasonably modern low-end Alpha (from any AlphaStation
>>> onward) were remarkably PC-like in terms of chips and functionalities,
>> The Alpha was intended to be able to run Windows. AFAIK few people ever
>> did but the possibility was there!
>
> The Alpha was designed to be OS neutral. It still is.
>

Which does not contradict what I said! Alpha's can and do run VMS, Unix,
Linux, and <obligatory retching noises> Windows. DEC did that on purpose!

There was a time when Alpha was the fastest iron money could buy! If
DEC had been willing and able to sell at a market price they could have
conquered the world. Instead, they shot themselves in the foot.
Clear up to the hips!!

[Arne Vajhøj]

Bob Koehler wrote:
> Richard B. Gilbert wrote:
>> ***@yahoo.co.uk wrote:
>>> As for x86 systems hardware: it's already been pointed out that the
>>> innards of any reasonably modern low-end Alpha (from any AlphaStation
>>> onward) were remarkably PC-like in terms of chips and functionalities,
>> The Alpha was intended to be able to run Windows. AFAIK few people ever
>> did but the possibility was there!
>
> The Alpha was designed to be OS neuteral. It still is.

It is not being developed or produced anymore.

But the systems produced is certainly still capable of running
multiple OS's.

Arne

[Bob Koehler]

In article <00218dac$0$20644$***@news.astraweb.com>, JF Mezei <***@vaxination.ca> writes:
> Arne Vajhøj wrote:
>
>> But I find it very difficult to believe that it is something
>> where the "let a handful of engineers do a little work in their
>> spare time" approach will produce anything usable.
>
> Usable ? No. Proof of concept that is usable as basis to do a full
> fledged port, Yes.

Emerald.

[Arne Vajhøj]

Neil Rieck wrote:
> On Apr 4, 5:26 am, Michael Kraemer <***@gsi.de> wrote:
>> David J Dachtera schrieb:
>>> Neil Rieck wrote:
>>>> IBM Reportedly Offering $9 to $10 Per Share for Sun
>>>> http://www.dailytech.com/IBM+Reportedly+Offering+9+to+10+Per+Share+fo...
>>> Hhhmmm... Well, since HP just inked a deal to distribute and support
>>> Solaris, I guess that would make rivals IBM and HP business partners.
>>> D.J.D.
>> Maybe this thing ends with some surprise:
>>
>> HP dumps HP-UX on itanic (and itanic altogether) and sells Solaris on x86
>> IBM dumps AIX on Power and sells Solaris on Power (after having
>> incorporated some AIX goodies)
>
> My following thoughts are not based upon any hard data.
>
> 1) It was my belief that POWER enabled IBM to stay involved in
> "enterprise" while they dumped their PC business to Lenovo. If true,
> they will not dump POWER (but I'm not so sure about SPARC, UltraSPARC,
> etc.)

IBM will keep Power and AIX around for many many years.

But I have no doubt that x86-64 and Linux is the long term strategy
for IBM.


> If Itanium development has been stalled at Intel because they are
> concentrating on markets which will help them through the current
> economic down turn,

I don't think Intel is stalling Itanium because of the recession - they
are stalling Itanium because it does not sell enough.

> that leaves HP with three operating systems (HP-
> UX, OpenVMS, NonStop) with not much of a future.

True.

Long term - no current software has a future.

But those 3 are on the endangered species list.

> If I was in HP upper
> management, and if I gave a damn about HP's future five years down the
> road, I would start a Skunk Works to get these three OSs ported to
> x86-64.

That is one option.

But it seems much more likely that they will want to just keep them
alive long enough to get everyone on Linux.

Arne

[Bill Gunshannon]

In article <gr75i0$8o4$02$***@news.t-online.com>,
Michael Kraemer <***@gsi.de> writes:
> David J Dachtera schrieb:
>> Neil Rieck wrote:
>>
>>>IBM Reportedly Offering $9 to $10 Per Share for Sun
>>>
>>>http://www.dailytech.com/IBM+Reportedly+Offering+9+to+10+Per+Share+for+Sun/article14757.htm
>>
>>
>> Hhhmmm... Well, since HP just inked a deal to distribute and support
>> Solaris, I guess that would make rivals IBM and HP business partners.
>>
>> D.J.D.
>
> Maybe this thing ends with some surprise:
>
> HP dumps HP-UX on itanic (and itanic altogether) and sells Solaris on x86
> IBM dumps AIX on Power and sells Solaris on Power (after having
> incorporated some AIX goodies)

And just why would IBM want to do that? Personally, I can't even imagine
IBM's interest in Solaris at all so I guess Sun must have something else
of value. And, compared to Power, I can't see it being Sparc either.

bill


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Arne Vajhøj]

Bill Gunshannon wrote:
> In article <gr75i0$8o4$02$***@news.t-online.com>,
> Michael Kraemer <***@gsi.de> writes:
>> David J Dachtera schrieb:
>>> Neil Rieck wrote:
>>>> IBM Reportedly Offering $9 to $10 Per Share for Sun
>>>>
>>>> http://www.dailytech.com/IBM+Reportedly+Offering+9+to+10+Per+Share+for+Sun/article14757.htm
>>>
>>> Hhhmmm... Well, since HP just inked a deal to distribute and support
>>> Solaris, I guess that would make rivals IBM and HP business partners.
>>
>> HP dumps HP-UX on itanic (and itanic altogether) and sells Solaris on x86
>> IBM dumps AIX on Power and sells Solaris on Power (after having
>> incorporated some AIX goodies)
>
> And just why would IBM want to do that? Personally, I can't even imagine
> IBM's interest in Solaris at all so I guess Sun must have something else
> of value. And, compared to Power, I can't see it being Sparc either.

Well - I considered Michaels prediction to be a joke.

It seems obvious to me that IBM wants the market share for servers
and storage. Now. Over time we will see some product consolidation.
But IBM is used to a rather diversified product portfolio. Informix
is a good example of them not being in a hurry to kill products.

My guess would be that AIX and Power will live a few years more
than Solaris and SPARC, but they will need to keep both Solaris and
SPARC for a long time to avoid loosing customer confidence.

Arne

[JF Mezei]

Arne Vajhøj wrote:

> It seems obvious to me that IBM wants the market share for servers
> and storage.

To me, IBM wants the service and support revenus and especially doesn't
want HP to get them as HP was poised to do with its new agreement with Sun.

[Arne Vajhøj]

JF Mezei wrote:
> Arne Vajhøj wrote:
>> It seems obvious to me that IBM wants the market share for servers
>> and storage.
>
> To me, IBM wants the service and support revenus and especially doesn't
> want HP to get them as HP was poised to do with its new agreement with Sun.

AFAIK SUN is relative small in services - mostly just their own HW
and OS.

Arne

[Arne Vajhøj]

David J Dachtera wrote:
> Neil Rieck wrote:
>> IBM Reportedly Offering $9 to $10 Per Share for Sun
>>
>> http://www.dailytech.com/IBM+Reportedly+Offering+9+to+10+Per+Share+for+Sun/article14757.htm
>
> Hhhmmm... Well, since HP just inked a deal to distribute and support
> Solaris, I guess that would make rivals IBM and HP business partners.

Not really anything unsual in that.

IBM sell systems with Oracle, Microsoft and Redhat stuff on.

HP sells stuff with Microsoft, Oracle, IBM and Redhat stuff on.

It's not personal it's strictly business.

Arne

[IanMiller]

On Apr 3, 7:54 pm, Neil Rieck <***@sympatico.ca> wrote:
> IBM Reportedly Offering $9 to $10 Per Share for Sun
>
> http://www.dailytech.com/IBM+Reportedly+Offering+9+to+10+Per+Share+fo...
>
> Neil Rieck
> Kitchener/Waterloo/Cambridge,
> Ontario, Canada.http://www3.sympatico.ca/n.rieck/OpenVMS.html

IBM-Sun takeover talks 'collapse'
http://news.bbc.co.uk/1/hi/business/7985274.stm

[Arne Vajhøj]

IanMiller wrote:
> On Apr 3, 7:54 pm, Neil Rieck <***@sympatico.ca> wrote:
>> IBM Reportedly Offering $9 to $10 Per Share for Sun
>>
>> http://www.dailytech.com/IBM+Reportedly+Offering+9+to+10+Per+Share+fo...
>>
>> Neil Rieck
>> Kitchener/Waterloo/Cambridge,
>> Ontario, Canada.http://www3.sympatico.ca/n.rieck/OpenVMS.html
>
> IBM-Sun takeover talks 'collapse'
> http://news.bbc.co.uk/1/hi/business/7985274.stm

The talks could be over.

Or they could just be playing high stakes poker about the
price.

SUN's stock went down the floor as a consequence, so
some stockholder may be calling the board and suggest
that SUN do not make another "Yahoo".

The deal is not so likely as it was 2 days ago, but
it could be resurrected.

Arne