Phillip Helbig---undress to reply wrote:

But what the media says is important because it shapes the opinions of
CIOs and CEOs and CFOs who make the iportant platform decisions.

Why didn't HP publicly brag about IA64 being garanteed until at least
2022 ?????

"access to Itanium" does not mean "continued devevelopment and production".

It could simply be access to the IP in case HP wanted to become a chip
company again.

What is important what the contract says about development and chip
production.

Legal contract generally do not use vague words such as "access to
Itanium" unless there is a paragrpah afterwards which defines what
"access to Itanium" means.

If HP is to send 600 million bucks to Intel, you can bet that the
contract will have very precise wording.

I think the damage has already been done. The image of Itanium is
stained especially since HP didn't/couldn't do much to counter Oracle's
attacks because it knew very well that Oracle was right.

The image of HP-UX is stained because of the lack of Oracle.  My guess
is that if Oracle is forced to come back, HP-UX will get the same amount
of Oracle as VMS does... just the DB engine and no apps.

Ya know, I really do not understand this Odyssey thingy.  In the past, anyone who could
easily leave VMS, and could accept the new environment, whatever it was, is most likely
already gone.  Some, I don't know how many, cannot move to weendoze or any Unix/Linux.  So
for them, what the hell good is round 2, or 3, or whatever, of trying to get these people
to move to something that will not do the job for them, for whatever reasons.

As I've wrote before, the applications I'm working with will not move off VMS.  No way, no
how.  So, if there is no future for VMS, then there is no future for my applications, and
that will mean starting over from scratch.  Without some overwhelming reason, and I doubt
there will be one, does anyone with a fraction of a brain think that I'm going to come
near the entity that caused me all my problems with a thousand mile pole?

So JF, while you claim to see fleeing customers, I see customers that given half a chance
will be the most loyal HP has.  Not because they like HP, but because they NEED VMS.  The
question then is, will HP blow off their potentially best customers?

My perspective is, give the customers a chance, such as VMS on x86 and continuing
development, and HP will have customers as long as x86 is a viable CPU.  Even then,
anything that replaces x86 will most likely have an easy upgrade path, if it wants to be
successful.

Thing is, whether HP has the people who could actually do the job, is a rather big question.

Are you sure you meant 2027 rather than 2017?

But what for the desktop?  The majority of the open source movement seems
to be involved in giving us increasingly unfriendly gizmos and "cool
effect" without regard to functionality.

--
Paul Sture

Aehm, I think that at least for hp-ux, there are alternatives to Oracle...
as in quicker , less resource intensive , and with the same performance if
not higher...

"JF Mezei" <jfmezei.spam...@vaxination.ca> ha scritto nel messaggio
news:4fd2b4ee$0$2322$c3e8da3$c8b7d2e6@news.astraweb.com...

On 2012-06-09 03:55:25 +0000, David Froble said:

It's a big-box option for folks with apps and app designs that want or
need big-box iron.

Project Moonshot/Redstone (the Calxeda ARM-based servers built using
giblets from the ProLiant parts bin) and Project Odyssey (Intel Xeon
x86-86 server boards sharing giblets from the Superdome 2 parts bin)
aren't (directly) relevent to OpenVMS users, but can be useful for
OpenVMS sites...

Project Odyssey can provide OpenVMS folks with...

+ a mixed-architecture platform for multi-OS big-box apps, including OpenVMS

+ a big-box platform for VAX or Alpha emulation

Superdome 2 boxes with a mix of Odyssey Xeon processor boards and
Itanium boards can provide a high-end mixed-architecture platform for
an incremental port off of OpenVMS.  The OpenVMS apps and the Xeon
x86-64 apps {Windows, Linux, Unix, whatever} are operating together in
the box, as part of an incremental application software migration.

The Odyssey Xeon processor boards can preserve (some of) the investment
HP and others have in the Superdome 2 platform.  For the sales and
marketing and advertising "process", the Odyssey Xeon boards will give
the marketeers and the buyers some political cover around buying that
Big Itanium Box.

There'll undoubtedly be the usual somewhat gnarly and arcane Microsoft
Windows management tools for the Odyssey Xeon processor boards, of
course.  More interesting to the applications (whether used for porting
or not) will (hopefully) be software support within the Project Odyssey
operating system enabling packages for a shared-memory interconnect;
APIs and libraries for QPI-speed or memory-speed communications among
the instances (as Galaxy called them, and similar to the Galaxy SMCI),
and as a foundation for memory-based network connections.

The NSK servers, Project Odyssey Xeon processor boards and the
Moonshot/Redstone servers are all moving the HP "special sauce" (at
least as far as the HP advertising presents it) into the glue chips and
the boxes and the enablement software; with the sx3000 chipset used in
the SD2.  Outside of a customized ARM design (and whether HP is using
that for a Moonshot box), the processors used across the products are
commodity parts.

Though only useful for curiosity and the most general guidance, the
Odyssey Xeon processor boards will also allow a direct comparison with
the Itanium processors with the same sx3000 interconnect; with what
Xeon can provide for performance when coupled into a high-scale
multiple-socket configuration.

Moonshot/Redstone isn't likely going to be used a host for emulation
(but then, who really knows what some sites need here?), but the
Redstone server boxes can serve as a front-end box for OpenVMS apps; as
a way to offload certain sorts of application processing.  The server
development platform is reportedly due this month, and provides 2,800
servers in a rack.  A box which might be a great way to deal with all
that front-end dreck that would otherwise bury an OpenVMS server in
dinky I/O requests, whether as a web server or as a terminal front-end
interface for those still using that design.

Other then the bit about emulation, none of the above is of any use to me.  Others may
have different requirements.

I'm thinking that you missed the point of my post.  For me, the essential need is VMS, and
none of the rest described above can do anything to help.  That makes it useless junk, at
least to me.

In general, I'm thinking that most of the people who could easily leave VMS have already
done so.  If so, then the rest have the same problem I have.  What is needed is VMS, and
what is not needed is anything else.

So my question remains, what good is all this junk to those who cannot use it ?????

On 2012-06-09 14:36:24 +0000, David Froble said:

The folks still using VMS are doing so for various reasons, and their
requirements can differ.

Often vastly, in my experience.

I didn't miss your point.  Parts of which were, well, emphatically clear.

You're currently being faced with a decision to update your existing
code and increasingly your OpenVMS environment, or to commence a port,
or a rewrite.  Or with encouraging HP to invest in areas of OpenVMS.

This also given your comments around application requirements that are
growing out of what OpenVMS presently provides for software features.

An Odyssey-class box is only useful to you if you've decided to port,
and if you need a big-box to port to.

And yes, opening up discussions of a platform port also open up
discussions of the available hardware vendors; most folks will look at
a variety of vendors, once a hardware port is under consideration.

I'm encountering similar issues across various projects, including
cases where a lack of tools or features makes coding for OpenVMS slower
than on other platforms.  Which means "glue code".  That "glue code" is
upgrading the features and APIs that are available within OpenVMS.  And
that's a pernicious cost on the project or product.  And the time and
cost of creating my own programming and debugging tools, and libraries.

Some.  Some are working on incremental or full ports.  Some are going
to run their VMS hardware into the ground, and then switch to
emulation.  Some have already switched to emulation.  And yes, some
folks have or are porting off of OpenVMS, or are migrating their data
over to different tools.  This varies.

Maybe of no use.  Or maybe an Odyssey-class box would be among the
available choices you do have, if you can't have what you need with VMS
going forward, and are migrating.  Though in your particular case and
your phrasing, you've made it emphatically clear that the HP
representatives will be operating at a profound deficit in any
discussions around providing replacement hardware.

And yes, the easiest path for your applications clearly involves
upgrades and enhancements to OpenVMS, and preferably support past any
end to Itanium processor availability.  And those matters are going to
involve some investments by and various discussions with the HP BCS
folks.  Which probably won't happen here in a newsgroup, given the HP
OpenVMS folks posting here are not those that are making these
decisions.  Well, not unless they've gotten themselves some
stratospheric promotions. :-)

HP's management are printer and wintel oriented. They don't like this
loyalty to an OS because they are stuck with these products they don't
want. They also see the server market as commodity running either wintel
or linux. And let's face it, there are more applications available on
Linux than on VMS.

Hey, HP won't cause your VMS machine to suddently stop. You can buy the
last IA64 produced and run on it for a decade or two, like people have
done for VAX.

As sales and BCS revenues continue to drop, the cost of continued IA64
development have or will become greater than revenues.

Continued IA64 production of Kittson for a decade is akin to producing
VAXes based on 1992 technology today.

That would be the nice thing to do as HP terminates IA64. But HP did
have a pilot to test portability to x86 and it stopped it because costs
were too great. What is not sure is whether this was just based on
porting HP-UX or whether each of the OS had its own separate evaluation.

I would think that porting VMS to x86 would be simpler than HP-UX, in
part due to endianness compatibility.

The bean counters at HP look at revenue potential and costs of porting
and say "no way José"

Hoff could port VMS in a couple of days :-)  But without FredK, writung
the video drivers would b tough.

I'd be interested in knowing how hard it would reall be to port the very
early stages of VMS. Since one can get EFI based 8086, wouldn't the
early modules susch as the initial loader and sysboot be much easier to
port than the port from vax to alpha and alpha to ia64 which didn't have
a common boot firmware ?

On Jun 9, 5:09 pm, Stephen Hoffman <seaoh...@hoffmanlabs.invalid>
wrote:

Why would anyone interested in a Xeon-based "high-scale multiple-
socket configuration" want to wait for Odyssey?

There are already 8socket x86-64 systems on the market. The one from
HPQ is the Proliant DL980 G7 (whose details have been around since
2010 - up to 80 cores and a handful of TB of memory, and quite
possibly more QuickPath bandwidth than a Superdome). It even uses a
Superdome-derived (so HP say) controller to provide a resilient low
latency interconnect between two four-socket "quad building
blocks" (they're not called that officially) to make an 8socket
system. Apparently the Intel glueless interconnect design was sub-
optimal in terms of memory latency in an 8socket system, making it a
bit NUMA-ish. (Yes that may sound familiar).

The DL980 G7 was mentioned earlier today, as was an 8socket system
from SuperMicro, in the "Did any one post this Oracle link already?"
thread, e.g.
http://groups.google.com/group/comp.os.vms/msg/b3051d0275cade43

If folk are for some reason reluctant to do business with HP, then
Dell and IBM do the four socket variant of these systems, which still
probably covers quite a large proportion of the market.

Regardless of hardware capabilities, these boxes would still be better
with a decent enterprise OS. But they're already good enough for lots
of people to bet their businesses on, even with the run of the mill
software already available.

JF Mezei wrote 2012-06-09 18:13:

Which very few real (not hobbyist) users realy need anyway.
Few VMS professional apps uses native graphics. And any
new graphic interfaces are better built using browsers
running on any of the common/popular desktop environments.

On 2012-06-09 17:47:27 +0000, John Wallace said:

Yes, there are.  From various vendors.

HP is aiming at 32 sockets for Project Odyssey.

Obviously at least ten to possibly sixteen or maybe more cores per
socket for that 32-socket configuration seems likely, depending on the
particulars details of the Xeon chip that's current when the Project
Odyssey boxes launch.

Plus whatever RAS features HP might choose to implement, beyond those
of the existing ProLiant configurations.

"HP began cascading mission-critical attributes to x86 with the launch
of the HP ProLiant DL980. For example, the PREMA architecture in the
DL980 takes advantage of some of the scalability and reliability
capabilities offered on Integrity servers. HP will continue to cascade
its mission-critical IP over time across hardware, software and
services to deliver the full mission critical experience on x86."

<http://h30507.www3.hp.com/t5/Mission-Critical-Computing-Blog/Got-Ques...>

The "PREMA architecture" stuff looks to be the marketing buzz-phrase HP
is using here.  There are some additional paragraphs of text around
what HP is incorporating into its "PREMA architecture" marketing
included in the DL980 G7 technical overview:

<http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA3-0643ENW.pdf>

"The machine is...basically two DL580s doubled up and talking across
Intel's "Boxboro" 7500 chipset to make an eight-socket server with 128
memory slots and topping out at 2 TB of main memory."

<http://www.theregister.co.uk/2010/06/22/hp_proliant_blade_rack/page2....>

Architecturally, some folks refer to the DL980 as two four-socket boxes
working together, too.

And I'm sure there are folks here that might have a proposal for that choice.

IIRC, OpenVMS is limited to 64 cores per instance/partition/guest, in
its present implementation.  There were bits stored in quadwords for
various related data structures.  I don't recall if hyperthreading
lowers that count further, though.

Toward David Froble's concerns, if you're not interested in porting off
of OpenVMS (and assuming OpenVMS isn't itself ported), and you're not
looking for a 32-socket Big Box to use for hardware emulation, then
Project Odyssey (or a ProLiant DL-whatever Gen-whatever box) probably
won't be particularly interesting to you.

And no, I'm not looking to supplant HP's marketing group here.  
Discussing that possibility would be entirely "PREMA-ture", of course.

BINGO!  We have a winner.

I have nothing against DECwindows.  But a successful user interface must be something that
the casual user is somewhat familiar with.  Anything else causes a need for training, and
training doesn't produce revenue.  I think it's a safe bet to say that DECwindows is not a
successful user interface.

I've always appreciated VMS for what I could do with it, not for a user interface, and I'm
old enough to appreciate a command line interface.

It seems that whenever Nvidia or AMD/ATI or whoever comes out with a new video chipset,
there is the need for compatable drivers.  These companies write the drivers for weendoze
or they won't sell their products.  There is no economic reality for writing drivers for VMS.

I don't know anything about video drivers.  Therefore I don't know if it's feasable to
define a generic video interface that all operating systems could support, and all video
devices would conform to.  I'm going to guess that as new capabilities are developed, the
generic video interface would quickly become outdated.  Also, with the competition, if a
company saw a way to get just a bit more performance, regard of any standards, they'd do
so.  It's a competitive world out there.

DEC used ATI, and probably other video card vendors.  You can bet they asked for the
company to provide VMS drivers.  You can also bet they didn't like the answer they got.
(Probably wild laughter)

When it comes to video hardware, the hardware seems to chance faster then the software can
change.  Think about that for a while ....

In article <jqvn1a$af...@dont-email.me>,
 David Froble <da...@tsoft-inc.com> wrote:

Perhaps people in your position need to learn Linux and start porting.

--
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective

because you will be able to populate that superdome with some IA64
blades to run your legacy VMS or HPUX code, and some 8086 blades to run
your new software as your port from the old to the new.

As your requirements for IA64 go down, you pull those blades out and
replace with 8086 blades.

Whether the economics of this will work for most customers or just a few
with specific needs remains to be seen. It might be more cost efficient
to keep your existig VMS systems and just buy standard 8086 servers that
are separate.

Once HP fesses up to its plans to EOL IA64 and HP-UX/VMS/NSK, then it is
very likely to also announce some porting help and varous retention
deals to help existing customers stay with HP. Those deals wil involve
some seriously reduced pricing on the new superdomes.

How many servers today in the x86 space still come with a serial port
that is usable for console work ?  Porting VMS without any video drivers
would restrict VMS to one of two servers designed to have serial line
consoles and no graphics.

FredK had provided here some very good explanations of the type of
reverse engineering work he had to do to write video drivers on VMS,
including a basic x86 emulator to execute code provided by the video
card (since it expects to be attached to an x86 box)

His expertise in the field was important and unique enough that he was
retained by HP despite the cuts. Alas, he passed away.

This is about providing basic console fnctionality on the screen
attached to the server (either physical, virtualised via stuff like VNC
or via KVM switches).  When VMS boots, it needs to be able to write to
the console and eventually load its own driver for it. If you want to
login in VT220 mode on the console, it needs a video driver to emulate
character cell on the console.

DECwindows is about running an application o VMS and targetting the
window onto another machine which has a display. This in iself does not
need a video driver on VMS.

Perhaps people in my position should say "screw it" and take a long vacation ..

That is the sad conclusion I have come to some time ago. And thanks to
Oracle, I suspect it is becoming more and more obvious to the VMS community.

Consider this: if HP had plans to port its OS to x86, it would have done
so ASAP so that it could shorten the costly contract with Intel to keep
IA64 on life support.

But if you are planning to EOL the OS when Itanium is ended, then you
want to stretch the life of all that ecosystem as long as possible and
not tell anyone that that ecosystem's future has been decided and it
involves and EOL soon. This allows naive customers to continue to pay HP
lots of money and delays the migration to other vendors when they find
out they have been screwd and lied to by HP.

HP has steadfastedly denied it would port its OS to x86. And Tukwila,
Poulson and Kittson will all ave arrived very late in order to stretch
the remaining life of IA64.

Howver, with the rapidly declining BCS sales, HP may be forced to
rethink its plans. If the OS aren't ported, then HP will have to help
customers migrate to Linux. And the sooned HP announces this, the more
customers it can retain.

In article <4fd42319$0$1580$c3e8da3$92d0a...@news.astraweb.com>,
 JF Mezei <jfmezei.spam...@vaxination.ca> wrote:

Alternatively, if HP made "OpenVMS" actually open, as in open source, I
think we'd all just team up to port it and have done.  I expect several
participants in this group are up for it.  I know *I* am.  and we'd
probably have no shortage of experienced former VMS team members who
were interested.

I have a friend who used to be all about VMS all the time.  He can no
longer find work reliably with VMS.  If he can't, and I can't, don't be
too surprised if you can't.  Which means it doesn't matter much what HP
does.  I found my level of caring degraded drastically recently.

If they won't open source VMS, VMS ends up in the dust bin containing
all sorts of other no-longer-supported OSs.  I find it sad, as I really
adored the os, but I'm not in a position to do anything about it, and
jobs really aren't there for it anyway.  So to stay in IT, it's time to
find a new "home" OS.  Right now, that's looking like Linux.  I just
wish the programming tools there were closer in efficiency to VMS. :-/

And the web.  Don't forget the web.  I wish the web had debugging tools,
period.  Last I looked, it only had the oldest kind of crude debugging
tools.  I've been missing the debugging tools from VMS for years.

--
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective

In article <jr17lj$le...@dont-email.me>,
 David Froble <da...@tsoft-inc.com> wrote:

Wouldn't that be nice.

--
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective

In article <jr0mal$97...@dont-email.me>,
 David Froble <da...@tsoft-inc.com> wrote:

I do.  It's worthless.  Always was, and it hasn't improved any that I've
heard.

Agreed.

Of course not.  The OS developer should write any such.

My understanding is that it's long since been done by each of ATI and
Nvidea, for their chipsets.  Newer chipsets use supersets of older
chipsets' commands.  It's just that if you want the newer benefits, you
have to update your drivers.

If HP, or whomever, adopted the standard Linux front ends, they'd be all
set.  Those front ends have already been tuned to be Windows-like, for
instance.

Heck, I'm going to be available as of 18 June.  If anyone's interested
in pursuing this, let's talk.

--
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective

"Howard S Shubs" <how...@shubs.net> wrote in message
news:howard-D5DA5B.01404710062012@news.giganews.com...

Who can?

For too many years VMS was run as a gravy train for the inner-circle, and
still is :-(

There was/is a lot of filth in VMS that won't let a single cent/penny go
outside their vested interest regardless of merit.

Browsers now have fantastic debigging tools! With the likes of Javascript,
HTML5, XHR2 etc debugging the server is up to you and the language/framework
used. The client is sorted. (Have you noticed that even with the
reponse-format/type blob options with XHR2 and the pitiful Websockets,
nothing comes close to a native full-duplex connection-oriented binary
Socket?)

Cheers Richard Maher

On Jun 10, 5:24 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:

A note on terminology: DECwindows doesn't touch the hardware. When the
term DECwindows is used correctly it is more like a desktop, in the
same area as CDE, KDE, GNOME, etc.

The bit that does the device independent drawing of pictures and
handling of kbd/mouse events (optionally with a network in the middle)
is the industry standard (and open source?) X11. DECwindows sits atop
X11.

Between X11 and the hardware is a layer which includes hardware-
specific device drivers.

If you've got X11 working, CDE, KDE, LXDE, etc, come (almost) for
free, nothing has to be rewritten from scratch, just maybe recompiled
and tested (though I believe modern software practices often leave the
testing part to the customer).

Now, back to your main question I want to address: "How many servers
today in the x86 space still come with a serial port
that is usable for console work "

I have read that the next generation of server OSes from MS will be
designed for running headless (ie no local kbd/mouse/monitor on the
server). This actually sounds quite sensible - why do you need a kbd/
mouse/monitor on 99% of your servers, e.g. if 99% of them are virtual?
And once you have the headless capability for the 99%, maybe the rest
don't need them either?

I don't imagine it'll be a serial console, nor do imagine it will be
an open industry-standard protocol used by MS either, but the
principle will have been established that servers can run headless
once the OS is up.

Now, what about before the OS is up, or while the OS is unusable/
corrupt or just not installed?

Who's heard of Intel vPro technologies on desktops, laptops, or
servers? (Or Intel AMT, another name for the same kind of thing).

If you deal with sensible corporate IT environments, who understand
the need for remote management even WITHOUT the OS, you might have
heard of it in the last few years. One of its features is support for
remote access to BIOS facilities, even including serial line support
of some kind (but mostly via a network that works even when the OS is
unavailable). My five year old HPQ dc7700p desktop at home has some of
this built in, as does the Dell kit at work. (Making the dc7700p NIC
work at all with Windows was an interesting exercise but that's
another story for another day). A vaguely similar offering from AMD
appears to be called SIMFIRE and is based around open royalty free
standards (DASH?) whereas vPro is Intel proprietary.

I know very little about UEFI, some Apple users may well know more,
but it'd be insane if it didn't support vPro-style capabilities in a
generic way. E.g. as described in:
http://h30565.www3.hp.com/t5/Feature-Articles/The-30-year-long-Reign-...
(featuring extensive comments from someone well known round here).

So your decent business desktop, laptop, and server has had headless
capabilities for several years, and will continue to do so.

How hard can it be for VMS hardware and low level software to match
the important bits of that kind of capability?

I'm not sure the lack of a serial console or of low level graphics
drivers is exactly going to be a showstopper for VMS, when even
Windows-system builders are acknowledging these things may not matter
much in the bigger picture.