OT: news from the trenches (re: Solaris)

[Neil Rieck]

Caveat: I'm not trying to start a flame war here; I just want to inform everyone what our neighbors are up to.

###

I ran into one of my old buddies this week who is responsible for rolling 5-year old (and older) systems into a virtualized environment (mostly running VMware over RHEL; one solution is running Charon-VAX over RHEL) in our data centers in Toronto and Montreal. I asked him if he ever runs into problems doing this (he is pretty much vendor agnostic) so here is his paraphrased reply:

Every system cutover so far runs faster and cheaper in the virtualized environment except Solaris which runs faster and cheaper on newer SPARC Ultra hardware. He said, Solaris on T5-8 offers many more execution threads for use by apps like webservers and databases. I asked him if he was talking about software threads or hardware threads and he replied "both" then sent me the following link of many.

https://blogs.oracle.com/sistare/entry/massive_solaris_scalability_for_the

quote: The T5-8 has 8 sockets, each containing 16 cores of 8 hardware strands each, which Solaris sees as 1024 CPUs to manage

###

Everyone reading this already knows that increasing the number of CPUs doesn't necessarily speed up a system. Competition for common resources -AND- locking (2 points of many) will stall many of them which is why some larger Alpha platforms went the NUMA route. Nevertheless, 1024 is an impressive number.

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

[Dirk Munk]

In November I started a thread with the question how many cores x86 VMS
should support, and I suggested 1024.

A x86 Superdome has a maximum of 240 cores these days, but newer CPUs
will increase that number to 288 I assume. (later this year, or next year).

These T class Sparc CPUs are great for use with many execution threads,
but if you need single threaded high performance, forget them.

[JF Mezei]

On 15-02-18 07:40, Neil Rieck wrote:

> quote: The T5-8 has 8 sockets, each containing 16 cores of 8 hardware strands each, which Solaris sees as 1024 CPUs to manage

I remember the days where people said SPARC was dead, Alpha would
outlive them all.

IBM is prodding along with its Power chip.


By being on commodity hardware, VMS won't have a hardware competitive
advantage over most competitors. So it will have to shine with features
and efficiency to maximize performance on that hardware. Shouldn't be
hard to outperform Windows on the same hardware for instance.

[Kerry Main]

The subset of a DC Consolidation project I am part of right now is 100%
Solaris 10 and the target environment is T5-4's - still on Solaris 10.

These T5's are not shabby by any means. In addition to being designed
for multiple threads, the CPU cores are up to 3.6Ghz each. In addition,
each core has its own on chip HW encryption accelerator that speeds up
handling of security protocols. 2TB physical memory max as well.

Check out:
http://tinyurl.com/dyl22y7

http://tinyurl.com/d9clu4u

Regards,

Kerry Main
Back to the Future IT Inc.
.. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of JF
> Mezei
> Sent: 18-Feb-15 1:08 PM
> To: info...@info-vax.com
> Subject: Re: [New Info-vax] OT: news from the trenches (re: Solaris)
>

Let's not forget that VSI has stated numerous times they do not expect
X86-64 to be the last platform they port OpenVMS to.

In fact, they stated that some of the design decisions being made for
X86-64 will help them with future ports.

[Dirk Munk]

What I meant to say is that if you need a system for fast batch
processing or something like that, Fujitsu and Oracle have a different
class of Sparc CPUs for that kind of work as I'm sure you will know.

[Neil Rieck]

On Wednesday, February 18, 2015 at 8:15:05 PM UTC-5, Kerry Main wrote:
[...snip...]

>
> Let's not forget that VSI has stated numerous times they do not expect
> X86-64 to be the last platform they port OpenVMS to.
>
> In fact, they stated that some of the design decisions being made for
> X86-64 will help them with future ports.
>
> Regards,
>
> Kerry Main
> Back to the Future IT Inc.
> .. Learning from the past to plan the future
>
> Kerry dot main at backtothefutureit dot com

Adding to your points, anyone who has ever bet against Intel has been proven wrong. I suspect their x86-64 products will only get better each year, and this can only be a good thing if OpenVMS can run natively on them.

I'm certain most people reading this know that Intel broke their own rule by announcing a both "a tick" and "a tock" release for 2015. This means we are starting to see new products sooner.

http://hexus.net/tech/news/cpu/74481-intel-broadwell-skylake-client-cpus-launching-2015/
http://www.pcworld.com/article/2683392/pc-confusion-to-linger-on-intels-quick-jump-to-skylake.html
http://www.extremetech.com/computing/186210-intels-14nm-puzzle-as-skylake-details-leak-everybody-asks-is-the-chip-coming-in-2015-or-not

[johnwa...@yahoo.co.uk]

Ticks and tocks duly noted, though quite what people do with all this
CPU power in a laptop or desktop escapes me. Servers are a different
matter (see below). Anyway, moving on...

"anyone who has ever bet against Intel has been proven wrong"

I assume you meant 'anyone who has ever bet against Intel x86 (and x86-64)
has been proved wrong'. Which would seem reasonable.

Outside Intel's x86 comfort zone, which if we are honest is largely a
Windows comfort zone (exception(s): Apple, and maybe tablets+phones built
with x86 SoCs supported by "contra revenue" [1]), Intel have a very
different track record, and not just with the obvious stiff like IA64.

I had a very very quick look at the current HPQ Proliant (Gen8) range just
now. My first impression was that the real high end massive-SMP systems
were being de-emphasised at the moment. But I could be wrong.

Even if I'm not wrong, it may be that HPQ's highest-end x86-64 stuff will
continue but will be marketed distinctly from Proliant. Why anyone would
do that, I'm not sure, though there are some obvious possibilities such
as force fitting the product range and split to match an existing
organisational set of empires.

[1] http://www.extremetech.com/extreme/186367-intels-mobile-division-has-lost-an-astonishing-2-billion-dollars-so-far-this-year

[Simon Clubley]

On 2015-02-19, johnwa...@yahoo.co.uk <johnwa...@yahoo.co.uk> wrote:
>
> "anyone who has ever bet against Intel has been proven wrong"
>
> I assume you meant 'anyone who has ever bet against Intel x86 (and x86-64)
> has been proved wrong'. Which would seem reasonable.
>
> Outside Intel's x86 comfort zone, which if we are honest is largely a
> Windows comfort zone (exception(s): Apple, and maybe tablets+phones built
> with x86 SoCs supported by "contra revenue" [1]), Intel have a very
> different track record, and not just with the obvious stiff like IA64.
>

Indeed.

What people without any embedded knowledge don't seem to realise is that
Intel offerings only cover one part of the computing ecosystem.

Outside of that area, Intel offerings are mostly (or even totally in most
cases) non-existant.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Dirk Munk]

Neil Rieck wrote:
> On Wednesday, February 18, 2015 at 8:15:05 PM UTC-5, Kerry Main wrote:
> [...snip...]
>>
>> Let's not forget that VSI has stated numerous times they do not expect
>> X86-64 to be the last platform they port OpenVMS to.
>>
>> In fact, they stated that some of the design decisions being made for
>> X86-64 will help them with future ports.
>>
>> Regards,
>>
>> Kerry Main
>> Back to the Future IT Inc.
>> .. Learning from the past to plan the future
>>
>> Kerry dot main at backtothefutureit dot com
>
> Adding to your points, anyone who has ever bet against Intel has been proven wrong.

Well, we betted against Intel that the Itanium would fail, and we were
right.

[Stephen Hoffman]

On 2015-02-19 11:36:05 +0000, Neil Rieck said:

> Adding to your points, anyone who has ever bet against Intel has been
> proven wrong. I suspect their x86-64 products will only get better each
> year, and this can only be a good thing if OpenVMS can run natively on
> them.

...Except when Intel was trying to provide an architectural alternative
to x86, where Intel has had somewhat of a history of
less-than-successful attempts.
...Except for ARM, as they and their partners seem to be doing quite
well, and at margins much lower than what Intel typically seeks for
their processors.

> I'm certain most people reading this know that Intel broke their own
> rule by announcing a both "a tick" and "a tock" release for 2015. This
> means we are starting to see new products sooner.

Technically, "Broadwell" shipped in 2014. If "Skylake" rolls out
closer to its release schedule than "Broadwell" managed, then yes,
"Broadwell" and the remaining "Haswell" parts will be replaced somewhat
sooner than usual.


--
Pure Personal Opinion | HoffmanLabs LLC

[Simon Clubley]

On 2015-02-19, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2015-02-19 11:36:05 +0000, Neil Rieck said:
>
>> Adding to your points, anyone who has ever bet against Intel has been
>> proven wrong. I suspect their x86-64 products will only get better each
>> year, and this can only be a good thing if OpenVMS can run natively on
>> them.
>
> ...Except when Intel was trying to provide an architectural alternative
> to x86, where Intel has had somewhat of a history of
> less-than-successful attempts.
> ...Except for ARM, as they and their partners seem to be doing quite
> well, and at margins much lower than what Intel typically seeks for
> their processors.
>

Where's the Intel equivalents of the (for example) Cortex M0/M3/M4 or
the low end MIPS MCUs ?

There's vastly more to the embedded world than just smartphones. :-)

[JF Mezei]

On 15-02-18 20:07, Kerry Main wrote:
>
> Let's not forget that VSI has stated numerous times they do not expect
> X86-64 to be the last platform they port OpenVMS to.

That is because we all know VSI will resurrect the VAX, make it 64 bits
and build 64 core chips running at 5ghz.

:-)

[johnwa...@yahoo.co.uk]

Intel get very nice margins on Xeon, not quite so nice on desktop or
laptop.

And in the SoC market (phones, tablets, etc - stuff that doesn't have
an inherent need for Windows/x86 capability) Intel are practically
paying system builders to use Intel's SoC stuff. More reading on this
subject by searching for "Intel contra revenue".

With the desktop (and maybe laptop) market in the doldrums, there are
interesting times ahead for Intel. They know they need to keep the chip
factories full. But how, three years from now?

[JF Mezei]

On 15-02-19 12:16, Dirk Munk wrote:

> I suspect their x86-64 products will only get better each year, and
> this can only be a good thing if OpenVMS can run natively on them.

One risk is ARM.

It can be that mobile/embedded will go ARM and computers/servers will
stay x86. Or desktops might move to ARM.

Intel has not had success for mobile devices. So even the x86 isn't a
success everywhere.

Consider what happened when AMD decided to make a 64 bit 8086, forcing
Intel to throw in the towel on its policy of 64 bit = itanium and
following AMD's lead.

Imagine if AMD starts to produce high performance server chips based on
ARM architecture ? This might be quite interesting

In fact, Apple is rumoured to be toying with the idea of moving its
desktops/laptops to ARM.


From a VSI point of view, a move to ARM shouldn't be a big deal. In the
past, VMS was tied to vendor who had vested interests in chips, except
for short tenure under Pfeiffer at Compaq. VMS was tied to VAX and then
Alpha, and then to that IA64 thing under HP.

But with VSI "free", they become architecture agnostic since they have
no vested interests in any one specific architecture (until they
resurrect the 64 bit VAX, or course :-)

[Bill Gunshannon]

In article <54e6356d$0$44801$c3e8da3$dd96...@news.astraweb.com>,

JF Mezei <jfmezei...@vaxination.ca> writes:
> On 15-02-19 12:16, Dirk Munk wrote:
>
>> I suspect their x86-64 products will only get better each year, and
>> this can only be a good thing if OpenVMS can run natively on them.
>
> One risk is ARM.
>
> It can be that mobile/embedded will go ARM and computers/servers will
> stay x86. Or desktops might move to ARM.
>
> Intel has not had success for mobile devices. So even the x86 isn't a
> success everywhere.
>
> Consider what happened when AMD decided to make a 64 bit 8086, forcing
> Intel to throw in the towel on its policy of 64 bit = itanium and
> following AMD's lead.
>
> Imagine if AMD starts to produce high performance server chips based on
> ARM architecture ? This might be quite interesting

That is the kind of thinking that brought down Itanium. Do you want
AMD to do the same and cede the market back to Intel?

>
> In fact, Apple is rumoured to be toying with the idea of moving its
> desktops/laptops to ARM.

Haven't heard anything about that. Apple alerady was on non-standard
chips. Where did they end out? And if they moved to ARm and were
successful why shold I think it is anything other than more of their
followers religion?

So much for devil's advocat (although I place little if any value in
what Apple users do. Apple's systems have been technically inferior
since thevery beginning.)

If you have access to a Windows Server 2012 system take a look in
C:\Program Files(x86)\Windows Kits\8.0\bin

Come back and tell people what you see. :-)

>
>
> From a VSI point of view, a move to ARM shouldn't be a big deal. In the
> past, VMS was tied to vendor who had vested interests in chips, except
> for short tenure under Pfeiffer at Compaq. VMS was tied to VAX and then
> Alpha, and then to that IA64 thing under HP.
>
> But with VSI "free", they become architecture agnostic since they have
> no vested interests in any one specific architecture (until they
> resurrect the 64 bit VAX, or course :-)

I expect to see that right after I release 64bit RSTS/E.

bill

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

[Neil Rieck]

It would appear that Microsoft is dropping all support for ARM in the next version of windows. I wonder how much that distraction cost them.

Neil

[Neil Rieck]

I'm still not trying to start a flame war here; I just want to inform everyone what our neighbors are up to.

Today, I saw with my own eyes, two quotes. One was for a new rx2800i2 from HP. The other was for one of those T5-8 thingies from Oracle (I don't recall the actual model at this time). Due to NDAs and such, I cannot disclose the quoted dollar amounts but they where withing a couple k of each other. Now, like automobiles, options can drive the individual prices up and down but I still found these prices to be suspiciously similar. Getting back to my original post in this thread, the T5-8 had way more CPUs as far as the OS was concerned.

p.s. we will still be buying an rx2800i2 because we run OpenVMS-8 with home-grown apps.

[Stephen Hoffman]

On 2015-02-19 23:45:59 +0000, Neil Rieck said:

> p.s. we will still be buying an rx2800i2 because we run OpenVMS-8 with
> home-grown apps.

IIRC, if that's an AlphaServer DS20 box that you're replacing and
barring a large increase in expected load, that rx2800 i2 box is
probably going to be somewhere between overkill and massive overkill.
FWIW.

[Paul Sture]

On 2015-02-19, Bill Gunshannon <bi...@server3.cs.scranton.edu> wrote:
>
> If you have access to a Windows Server 2012 system take a look in
> C:\Program Files(x86)\Windows Kits\8.0\bin
>
> Come back and tell people what you see. :-)

x86, x64 and arm.

FWIW that directory doesn't exist in the evaluation copy of Server 2012
but is there on Windows 8.1 Pro.

--
1972 - IBM begins development on its last tape drive (3480) ever because
of the declining cost of disk drives.

[johnwa...@yahoo.co.uk]

I know Microsoft's messaging has been very confusing of late, but I'd
be interested to hear where "Microsoft is dropping all support for ARM
in the next version of windows" comes from.

Microsoft seem to be wanting to join the "Internet of Things" bandwagon
and that is currently ARM centric (and also largely Linux centric, hence
their interest?).

One recent example covers both confusion and bandwagon: Windows 10 will
be available for the recently announced Raspberry Pi 2. Confusion: there
are many flavours of Windows 10 but no one is clear which one applies
on Raspberry Pi 2. IoT: what little clarity there is says it will be an
IoT flavour of Windows 10, which is distinct (in unclear ways) from the
desktop flavour of Windows 10.

Other examples are available. YMMV. etc.

Content-free MS article on Windows 10 on Raspberry Pi:
https://dev.windows.com/en-us/featured/raspberrypi2support

ZDnet (Marj Jo Foley) article, 2 Feb 2015, with some details from MS on
what the variants of Windows 10 will be (e.g. Win10 Mobile will be for x86
or ARM, Win10 Embedded Compact will also be x86 or ARM):
http://www.zdnet.com/article/microsofts-windows-10-for-iot-what-to-expect/

Mind you, what MS announce, what they deliver, and what survives five years
later are not necessarily the same thing, as any Windows PDA owner (iPAQ,
Jornada, etc) will know to their cost. And indeed any Windows NT for RISC
owner before then.

[Bill Gunshannon]

In article <c53a9e77-5b7a-4168...@googlegroups.com>,

I read the article and it really said that Windows RT was dead. It
was being assumed from this that Microsoft was dropping ARM support.
But, as I pointed out, Server 2012 (which is not RT in any form) has
an ARM branch in its SDK tree. I will hold my back my decision on
ARM's future for a bit yet.

[Neil Rieck]

Your are correct, we are replacing a AS-DS20e with an rx2800 i2. You must remember that my very conservative employer is aware of the fact that we bought the AS in 2002 (making it 13-years old); that HP's most recent roadmap shows standard support for the OS ending soon (depending upon whether you are running 8.3 or 8.4); that our client base has grown from ~120 at the beginning of 2014 to ~1000 today and is still growing.

But here's the kicker (I am not allowed to disclose amounts): if VA was the all-in cost of converting from VAX to Alpha in 2002 (that deal was with Compaq), the all-in cost of converting from Alpha to Itanium is VA/4. Now I must be honest and mention that the platforms are not identical. Our AS came with a RaidArray-3000 (via HSZ22) whilst the rx2800 will include 4 single terabyte drives mirrored via host-based shadowing. Even still, it would seem to me that we cannot afford to not do this.

You already know that your software needs to be under a support contract in order to get the best trade-in value when moving licenses to a new system, but I think HP needs to keep doing stuff like this in order to stay in the game. On top of that, HP's software licensing of OpenVMS products seem much more realistic than Compaq's (and Compaq's was much more realistic than DEC's) so kudos to HP.

Anyway, I was told yesterday that "the funds have been allocated but not yet released" (whatever that means in big-corp lingo) so we haven't placed an order just yet.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Neil Rieck
> Sent: 19-Feb-15 6:34 PM
> To: info...@info-vax.com
> Subject: Re: [New Info-vax] OT: news from the trenches (re: Solaris)
>

[snip..]

>
> It would appear that Microsoft is dropping all support for ARM in the
> next version of windows. I wonder how much that distraction cost them.
>
> Neil

Microsoft has a long history of trying untie itself from being a single
Platform supplier. Alpha (ok, DEC forced this on them with the Alliance
Agreement after NT code was found to contain DTN numbers), Power,
Arm ..

:-)

As much as they hate to admit it, Microsoft is joined to X86 at the hip.

I suspect this is partly due to their internal culture and reluctance to
really get behind anything not X86 related. You need marketing and
ISV support and just because you build the platform does not
guarantee that ISV's will jump behind it.

[Neil Rieck]

On Friday, February 20, 2015 at 7:08:41 PM UTC-5, Neil Rieck wrote:

[...snip...]

A few more thoughts: when you compare the version numbers of c and cxx between Alpha and Itanium it is already apparent that HP is not improving Alpha. On top of this, I have reported two problems with BASIC on Alpha in the past three years which HP promptly fixed for me, but not for everyone else. So Alpha is already in maintenance-only mode.

Unless I missed it, VSI "is working on Itanium" and "intends to work on x86-64" but has never announced any plans regarding Alpha. So I fear that Alpha will end up like VAX, stuck in time. Sure they will chug away for years but that is no good for platforms needing new code. (OS or application)

Now there has been be some unofficial talk about VSI developing C and CXX (bringing C up to the latest C11 standard; adding a "/GCC" switch to both c and c++; etc) but I suspect this will only happen for the Itanium product. If people consider this stuff you will need to step up.

On big show stopper for us is Apache. If we didn't have access to it then we would have been forced off OpenVMS. Now I don't need to point out that improvements to c/c++ are going to make the next port of Apache to OpenVMS easier. If it is easy on Itanium and not so easy on Alpha then I could see a new version of Apache being offered for one but not the other.

Just my 2-cent worth

[Stephen Hoffman]

On 2015-02-21 22:57:01 +0000, Neil Rieck said:

> On Friday, February 20, 2015 at 7:08:41 PM UTC-5, Neil Rieck wrote:
>
> [...snip...]
>
> A few more thoughts: when you compare the version numbers of c and cxx
> between Alpha and Itanium it is already apparent that HP is not
> improving Alpha.

Don't assume that compiler versions or patch kit versions will track
across the architectures. Architecture-specific bugs can and do arise.
There've been cases where VMS releases that predated the initial
releases of patch kits for fixes for other VMS releases already
contained the fixes; that is, where the VMS release was older than the
first available patch for a problem, but contained the fixes.

> On top of this, I have reported two problems with BASIC on Alpha in
> the past three years which HP promptly fixed for me, but not for

> everyone else. So Alpha is already in maintenance-only mode.Unless I

> missed it, VSI "is working on Itanium" and "intends to work on x86-64"
> but has never announced any plans regarding Alpha.

I'd think it fairly unlikely that there'd be great deal of effort
expended on updates for a platform with general new server product
availability that ended most of eight years ago.

> So I fear that Alpha will end up like VAX, stuck in time. Sure they
> will chug away for years but that is no good for platforms needing new
> code. (OS or application)

Folks (still) on Alpha haven't been moving forward. For those willing
to pay, that might be good for support revenues — or quite possibly not
so good for aggregate support revenues, as just keeping all that old
gear going for testing and software maintenance is a cost, and the
engineering effort in performing and merging check-ins increases as the
numbers of supported configurations increases.

Given the competitive landscape for operating systems, I wouldn't
expect to see the classic DEC support-it-for-eons business practices
continue — folks just aren't willing to pay what that costs.

As with the recent x86-64 server hardware practices — usually five and
sometimes seven years availability for maintenance parts, though
details do vary — and the typical five-year long-term support software
products, I'd expect to roll in the new hardware and software on the
local organization's replacement cycle, and not see support for the
older hardware and software continue for as long as DEC often offered.
Out with the old, in with the new. Prices for the x86-64 boxes are
typically lower than those of the Alpha or Itanium servers, so there's
that.

It would not surprise me to learn that VSI might start retiring support
for older hardware and software and even for specific software
components, and quite possibly removing the deprecated code.

Again, we're not in the same world that DEC once operated in; not even
remotely. I'd hope that VSI doesn't blindly follow many of the older
DEC software and business practices here, too. That probably won't end
well, if they just clone the DEC playbook and business practices.

> Now there has been be some unofficial talk about VSI developing C and
> CXX (bringing C up to the latest C11 standard; adding a "/GCC" switch
> to both c and c++; etc)

That /STANDARD=GCC mechanism already exists. It's unfortunately
compatible with an ancient version of GCC; somewhere around GCC 2.8 or
so. GCC is presently at 4.9.2, with 5.0 in development.

> but I suspect this will only happen for the Itanium product. If people
> consider this stuff you will need to step up.

Based on what VSI has commented, their schedule targets Itanium
hardware releases for i2 and i4 servers — and not specifically the
older Itanium hardware — and then the x86-64 port.

Whether VSI ends up adding support for V8.4 and earlier on Itanium or
on Alpha or anything for VAX is not something that they (and HP) seem
willing to step into right now. VSI needs to get V8.4-1H1 out, stable,
and available, they've planned V8.4-1H2, when (if?) the Kittson servers
appear, and they need to get VMS ported to x86-64. Alpha... isn't
anything VSI has commented on.

Personally, if VSI does pick up support for older VMS releases or for
Alpha releases, I'd wonder how well they're doing with moving VMS
forward — they're either doing really well with their finances and
their staffing, or the x86-64 port and the new work is in Deep
Sneakers; getting short shrift.

> On big show stopper for us is Apache. If we didn't have access to it
> then we would have been forced off OpenVMS. Now I don't need to point
> out that improvements to c/c++ are going to make the next port of
> Apache to OpenVMS easier. If it is easy on Itanium and not so easy on
> Alpha then I could see a new version of Apache being offered for one
> but not the other.

What New Shiny might arrive with V8.4-1H1, we shall see. If any, of course.

[Stephen Hoffman]

On 2015-02-22 00:01:17 +0000, Stephen Hoffman said:

Clarification:

> Whether VSI ends up adding support for V8.4 and earlier on Itanium or
> on Alpha or anything for VAX is not something that they (and HP) seem
> willing to step into right now. VSI needs to get V8.4-1H1 out, stable,
> and available, they've planned V8.4-1H2, when (if?) the Kittson servers
> appear, and they need to get VMS ported to x86-64.

[Future releases of...]

> Alpha... isn't anything VSI has commented on.

[Craig A. Berry]

On 2/21/15 4:57 PM, Neil Rieck wrote:

> Unless I missed it, VSI "is working on Itanium" and "intends to work
> on x86-64" but has never announced any plans regarding Alpha.

There are reports (on Facebook) of "an initial Alpha build" at Bolton
but there's never been any statement I've seen that they intend to
produce Alpha releases, and it's not at all clear whether they have the
rights to do so as part of their deal with HP. Or time to even think
about it while trying to get a Poulson release out the door with a small
team.

One of the trickier things for VSI's business model is that probably
close to half of the potential customers for a new release of VMS are
currently on Alpha. Can they offer a new Itanium-only release that makes
it attractive to these folks to switch platforms after more than a
decade of HP making that pretty easy but apparently not easy enough?

Or can they build a better bridge to the future for these customers by
producing one more Alpha release that brings Alpha somewhat up-to-date
and closer to feature parity with what the initial x86_64 release will have?

I have no idea.

> Now there has been be some unofficial talk about VSI developing C and
> CXX (bringing C up to the latest C11 standard; adding a "/GCC" switch to
> both c and c++; etc) but I suspect this will only happen for the Itanium
> product. If people consider this stuff you will need to step up.
>
> On big show stopper for us is Apache. If we didn't have access to it
> then we would have been forced off OpenVMS. Now I don't need to point
> out that improvements to c/c++ are going to make the next port of Apache
> to OpenVMS easier.

Not necessarily. The stated requirements for Apache say "ANSI C," and
when there is no version number specified it usually just means ANSI as
opposed to K & R, or in other words C89. It's likely to be awhile yet
before C99 becomes a requirement, much less C11.

CRTL improvements are an entirely different matter. For example, the
Apache port has its own pipe implementation based on sockets, with a
special privileged image whose sole purpose in life is to increase the
size of the puny socket buffer on one of these pipes to something
greater than 255 bytes, which requires privileges to do. That sort of
hackish nonsense could go away entirely if the CRTL provided a workable
pipe implementation.

[JF Mezei]

On 15-02-21 22:35, Craig A. Berry wrote:

> There are reports (on Facebook) of "an initial Alpha build" at Bolton
> but there's never been any statement I've seen that they intend to
> produce Alpha releases,

HP continues to keep customers on VAX, Alpha and pre poulson IA64
things. VSI can't sell to those customers.

But VSI may have a contract to supply HP with software updates on those
platforms with HP then providing its customers with updates. So not
surprising there would be rumours of them doing builds on Alpha.

[David Froble]

Craig A. Berry wrote:
> On 2/21/15 4:57 PM, Neil Rieck wrote:
>
>> Unless I missed it, VSI "is working on Itanium" and "intends to work
>> on x86-64" but has never announced any plans regarding Alpha.
>
> There are reports (on Facebook) of "an initial Alpha build" at Bolton
> but there's never been any statement I've seen that they intend to
> produce Alpha releases, and it's not at all clear whether they have the
> rights to do so as part of their deal with HP. Or time to even think
> about it while trying to get a Poulson release out the door with a small
> team.

If this report is true, then it sure has cleared up some questions.

How hard is it to have an Alpha sitting around? Not very, I've got more
than one. Even a couple of EV6 based systems.

If you have all the stuff to build the OS, then how hard is it to queue
up the job and go home for the weekend? I don't know. Perhaps some
here might have an idea. It just might not be all that time consuming.

But, that's not the important clue here. If they do indeed have the
Alpha code and build procedures, then Alpha is a possibility. This is
the first I've heard anything about VSI even getting the Alpha code from HP.

Got to wonder if that Facebook report is a back door way of saying
something VSI doesn't want to talk about officially right now.

[Jan-Erik Soderholm]

I thought it was a common code base with conditional builds.

>
> Got to wonder if that Facebook report is a back door way of saying
> something VSI doesn't want to talk about officially right now.

Why should there be a contradiction between "Facebook" and "official"?

[Stephen Hoffman]

On 2015-02-22 04:54:47 +0000, David Froble said:

> If they do indeed have the Alpha code and build procedures, then Alpha
> is a possibility. This is the first I've heard anything about VSI even
> getting the Alpha code from HP.

The source code pool was (and very likely still is) identical. The
same Rdb databases and the same CMS libraries were used, and the same
cluster was used for building both OpenVMS Alpha and OpenVMS I64.
There were obviously architectural differences in various of the source
code modules and there were architecture-specific modules, but — unless
somebody at HP went to a tremendous amount of work to find and excise
the Alpha source bits and Alpha build bits — the source pool is the
same for both Alpha and Itanium. When Alpha split off of VAX, a new
source pool and new tools were created. When Itanium split off Alpha,
I did not repeat that mistake with the source pool or the tools; I
added architecture-specific handling into the source tools. While
there were architectural differences in the build and kitting
procedures, most of the pieces and parts and data files were very
intentionally kept the same.

Have a look at VMSKITBLD.XML, for some of what's user-visible from this
area, as well as the VDE documentation from the OpenVMS Freeware. All
of this was covered in various DECUS presentations, and copies of some
of those are probably still posted around the 'net.

The more time VSI spends with RSX-11D, RSX-11S, RSX-11M, RSX-11M+ and
RSTS and RT and TSX code[1], with the VAX code base and tools, with the
Alpha code base and tools — and this for much of anything beyond some
mixed-architecture cluster testing — the less time can be spent on
getting VMS where VMS needs to be. Alpha is a dead-end platform.
Alpha has been dead-end for over seven years. Folks on Alpha can and
should expect to upgrade. If VSI succeeds with their efforts to port
VMS, then Alpha customers should expect to upgrade to VMS on x86-64.
That x86-64 upgrade will be much easier than porting off VMS, which was
where all this was headed just last summer.

By present standards, Alpha systems are very inefficient, in terms of
power, cooling, physical size and performance. Maintenance costs are
increasing. Peripherals are old and slow, and compatible replacements
and parts are increasing in price. Memory storage and disk storage
capacities are low. There are no new Alpha systems. Refurbs and
salvage and bespoke parts are your options here. Alpha is market
that's been going the wrong way for a number of years, and VSI does not
have infinite resources to try to stem that or to reverse that.

Yes, there are folks that want and do keep Chevy Corvairs or Ford Model
T cars going, and there's a market for those collectors. But they're
not making new Corvairs and new Model Ts, and, well, Corvairs and Model
Ts just aren't what most folks are looking for in cars nowadays. If
VSI goes into the vintage Alpha business, they're either doing really
well and VMS on x86-64 is very successful and they've run out of new
things to do with VMS on x86-64, or it's time to restart the
VMS-to-something-else port — I'd prefer to avoid production VMS
applications on vintage hardware, and definitely don't prefer to deploy
new applications onto vintage hardware. Not if there's a better
alternative. There are better alternatives to Alpha.

###########
[1] Sorry if I missed your favorite PDP-11 operating system or your
favorite PDP box in that list. I can only blame any potential
omissions here on my extensive use of TKB many years ago, as TKB usage
caused sections of memory to be swapped out.

[David Froble]

JF Mezei wrote:
> On 15-02-21 22:35, Craig A. Berry wrote:
>
>> There are reports (on Facebook) of "an initial Alpha build" at Bolton
>> but there's never been any statement I've seen that they intend to
>> produce Alpha releases,
>
> HP continues to keep customers on VAX, Alpha and pre poulson IA64
> things. VSI can't sell to those customers.

You KNOW this for a FACT ?????????????

[Jan-Erik Soderholm]

What the available docs says is that VSI (and HP) will sell
post V8.4 of OpenVMS. They do not say that those post V8.4
versions will *not* be available for Alpha. No, if it actualy
*will* be available is of course a different question...

And the fact that VSI publicly announced a first boot of their
internal OpenVMS build on Alpha indicates that they at least
intend to test future changes on Alpha and possible "back-port"
those additions that makes sense on Alpha. We'll see... :-)


Jan-Erik.

[JF Mezei]

On 15-02-22 11:14, Stephen Hoffman wrote:

> getting VMS where VMS needs to be. Alpha is a dead-end platform.
> Alpha has been dead-end for over seven years.

June 25 2001. That makes it close to 14 years.

> By present standards, Alpha systems are very inefficient, in terms of
> power, cooling, physical size and performance.

Heresy ! How dare you criticise a dear dead friend like that. RIP Alpha
and make everyone remember Alpha as a superb architecture killed by
ennemies who couldn't match it.

Seriously though, VSI may be able to supply HP with updates to Alpha at
a cost that is less than what HP makes from Alpha support revenues. So
it makes sense to continue to milk that cow.

Also, providing updates to Alpha gives VSI freedom to make
interoperability changes/improvements that would otherwise make Alpha no
longer usable in mixed architecture sites/clusters.

What is the unknown variable is how long VSI must continue to provide
updates to VMS on Alpha and/or IA64. It could be in some contract, or it
could be that it is just good business to keep getting paid by HP for
updates to pre-poulson customers, and getting money from poulson-kittson
ones.

And when that market dries up, then VSI can stop keeping IA64/Alpha
alive and focus on x86.

[JF Mezei]

On 15-02-22 12:12, David Froble wrote:

>> HP continues to keep customers on VAX, Alpha and pre poulson IA64
>> things. VSI can't sell to those customers.
>
> You KNOW this for a FACT ?????????????

This has been confirmed here. VSI can sell license/support to customers
who buy Poulson/Kittson boxes. It cannot sell to customers on
pre-poulson hardware. That market remains HP's. But HP is paying VSI for
rights to new versions so they can be distributed to those pre-poulson
HP customers.

[David Froble]

Or, it could mean they just fired up the build and went home for the
weekend, just for laughs.

Steve has already indicated that it might be difficult to separate the
Alpha stuff from the itanic stuff. Probably no attempt was made, as it
could have screwed up the itanic build.

But, from my perspective, I've learned something I didn't previously know.

[David Froble]

Citation needed.

I have not seen any such statements. They have said what they can and
will do. I do not remember seeing any statements about what VSI cannot do.

What is not prohibited, is allowed ....

[Jan-Erik Soderholm]

I have not seen any statement against new Alpha versions.
It's up to each one to belive if there will be any or not,
of course...

I'e only seen the distinction between V8.4 and post-V8.4.
Which is kind of logical if it still is the same codebase.

[JF Mezei]

On 15-02-22 15:57, Jan-Erik Soderholm wrote:

> I have not seen any statement against new Alpha versions.
> It's up to each one to belive if there will be any or not,
> of course...

The statements are with regards to which customers VSI are allowed to
acquire. They acquire customers on poulson and beyond hardware, they do
not acquire customers on pre-poulson hardware. Those remain HP's.

This means that any new version of VMS on IA64 (and possibly on Alpha)
is distributed to "old" customers via HP, not by VSI. And this implies
HP paying VSI for rights to distribute new versions of VMS to those
customers VSI cannot acquire and which remain HPs.

[mcle...@gmail.com]

An "Alpha build" from VSI?

Was it for some specific team (i.e. a department server) ?
Was it for "build on one machine then transfer image to another"?
Was it really "alpha build" as in first build? (Bad choice of names if it was).

Where's Clair Grant's comments on this build or maybe John Reagan's?

[David Froble]

I asked for a citation JF, not some more of your opinion.

Either show me where someone officially said that, or, IT NEVER HAPPENED!!

[David Froble]

JF Mezei wrote:
> On 15-02-22 15:57, Jan-Erik Soderholm wrote:
>
>> I have not seen any statement against new Alpha versions.
>> It's up to each one to belive if there will be any or not,
>> of course...
>
>
> The statements are with regards to which customers VSI are allowed to
> acquire. They acquire customers on poulson and beyond hardware, they do
> not acquire customers on pre-poulson hardware. Those remain HP's.

Also ....

I've seen statements that new versions would come from VSI. I NEVER saw
anything said that people on older HW could not get the new versions
directly from VSI. Now, if you've seen this, let us know where.

[Jan-Erik Soderholm]

JF Mezei skrev den 2015-02-22 22:22:
> On 15-02-22 15:57, Jan-Erik Soderholm wrote:
>
>> I have not seen any statement against new Alpha versions.
>> It's up to each one to belive if there will be any or not,
>> of course...
>
>

> The statements...

Reference?

> are with regards to which customers VSI are allowed to
> acquire. They acquire customers on poulson and beyond hardware, they do
> not acquire customers on pre-poulson hardware. Those remain HP's.

The only thing I have seen is about "up to V8.4" vs. "post V8.4".

It is logical for HP to keep support of current VMS with the
current HP personell that knows it. At least for the time beeing.
And let VSI support any new development not done within the
VMS group at HP.

>
> This means that any new version of VMS on IA64 (and possibly on Alpha)
> is distributed to "old" customers via HP, not by VSI. And this implies
> HP paying VSI for rights to distribute new versions of VMS to those
> customers VSI cannot acquire and which remain HPs.
>

That doesn't mean a thing. HP will also keep on distributing *any*
new version of VMS, for those customers who prefer to have a single
contact for HW and SW. Probably quite a lot of them, I guess.

For VSI it doesn't metter much which route the money takes as
long as they end up at VSI...






>
>

[Craig A. Berry]

On 2/22/15 3:44 PM, mcle...@gmail.com wrote:

> An "Alpha build" from VSI?
>
> Was it for some specific team (i.e. a department server) ?
> Was it for "build on one machine then transfer image to another"?
> Was it really "alpha build" as in first build? (Bad choice of names if it was).

Decide for yourself. Go to:

https://www.facebook.com/vmssoftware

and scroll back to November 4, 2014.

There could be many reasons for building on Alpha. They may be preparing
to handle support calls escalated to engineering, or it may be they will
be updating layered products but not the operating system and need a
debug build of the OS handy, or it may be that they are keeping options
open for the future, or it may be that they considered it a way to
validate their build environment, or it may just be that it's hard to
keep the chef from tasting the soup and when you point a bunch of once
and former VMS engineers at a pile of hardware and say "create a build
farm" it just doesn't occur to them *not* to build on Alpha if the
hardware is available.

> Where's Clair Grant's comments on this build or maybe John Reagan's?

Why should they make comments? There are plenty of public statements
about the releases they are planning and anything for Alpha isn't
currently one of them.

Not that I think an Alpha release is completely out of the question in
the future, especially after HP shuts down regular support for Alpha 8.4
in 2017.

[JF Mezei]

On 15-02-22 17:24, David Froble wrote:

> I asked for a citation JF, not some more of your opinion.

Look up explanations from a few of the VSI employees in this very
newsgroup. They were responding to one of my questions.

They confirmed that HP has the possibility of distributing newer
versions of VMS to the pre-poulson customers. (with VSI getting money in
some form).

I you don't believe and can't search, than I don't care that it never
happened because it won't make a difference to me.

[John Reagan]

On Sunday, February 22, 2015 at 4:44:37 PM UTC-5, mcle...@gmail.com wrote:


>
> Where's Clair Grant's comments on this build or maybe John Reagan's?

Moi? I doubt it was me.

However, I can tell you at least one reason we need to build Alpha. You need to build the latest Alpha RTLs so you can AEST them to place on the Itanium kit. And actually, the Alpha RTLs that get translated are sometimes not the exact same versions as actually ship with Alpha. For instance the translated Fortran RTL and the native Fortran RTL share LUNs if I remember correctly so the one that is translated knows to call into the native one to coordinate the sharing.

Our development cluster has two ES47s in it.

[Simon Clubley]

On 2015-02-22, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>
> The more time VSI spends with RSX-11D, RSX-11S, RSX-11M, RSX-11M+ and
> RSTS and RT and TSX code[1], with the VAX code base and tools, with the

> Alpha code base and tools ? and this for much of anything beyond some
> mixed-architecture cluster testing ? the less time can be spent on

> getting VMS where VMS needs to be. Alpha is a dead-end platform.
>

[snip]

> By present standards, Alpha systems are very inefficient, in terms of
> power, cooling, physical size and performance.

Those Alpha cases are _solid_ however. :-) My home Alphastation may not
have been powered up in years, but it's got a laser printer parked on
top of it.

>
> ###########
> [1] Sorry if I missed your favorite PDP-11 operating system or your
> favorite PDP box in that list. I can only blame any potential
> omissions here on my extensive use of TKB many years ago, as TKB usage
> caused sections of memory to be swapped out.
>

I don't think anyone (even Bill G) has suggested that VSI resurrect
the PDP-11 OS options. I do fully sympathise about TKB however. :-)
One too many overlay builds by any chance ? :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Neil Rieck]

On Saturday, February 21, 2015 at 10:35:46 PM UTC-5, Craig A. Berry wrote:
> >
> > On big show stopper for us is Apache. If we didn't have access to it
> > then we would have been forced off OpenVMS. Now I don't need to point
> > out that improvements to c/c++ are going to make the next port of Apache
> > to OpenVMS easier.
>
> Not necessarily. The stated requirements for Apache say "ANSI C," and
> when there is no version number specified it usually just means ANSI as
> opposed to K & R, or in other words C89. It's likely to be awhile yet
> before C99 becomes a requirement, much less C11.
>
> CRTL improvements are an entirely different matter. For example, the
> Apache port has its own pipe implementation based on sockets, with a
> special privileged image whose sole purpose in life is to increase the
> size of the puny socket buffer on one of these pipes to something
> greater than 255 bytes, which requires privileges to do. That sort of
> hackish nonsense could go away entirely if the CRTL provided a workable
> pipe implementation.

Thanks for this clarification. It will make me sleep a little easier :-)

Now if we could just convince HP to move Apache beyond 2.0.xx (2.4.xx is the latest release)

[Neil Rieck]

> to pay, that might be good for support revenues -- or quite possibly not

> so good for aggregate support revenues, as just keeping all that old
> gear going for testing and software maintenance is a cost, and the
> engineering effort in performing and merging check-ins increases as the
> numbers of supported configurations increases.
>
> Given the competitive landscape for operating systems, I wouldn't
> expect to see the classic DEC support-it-for-eons business practices

> continue -- folks just aren't willing to pay what that costs.
>
> As with the recent x86-64 server hardware practices -- usually five and

> sometimes seven years availability for maintenance parts, though

> details do vary -- and the typical five-year long-term support software

> products, I'd expect to roll in the new hardware and software on the
> local organization's replacement cycle, and not see support for the
> older hardware and software continue for as long as DEC often offered.
> Out with the old, in with the new. Prices for the x86-64 boxes are
> typically lower than those of the Alpha or Itanium servers, so there's
> that.
>
> It would not surprise me to learn that VSI might start retiring support
> for older hardware and software and even for specific software
> components, and quite possibly removing the deprecated code.
>
> Again, we're not in the same world that DEC once operated in; not even
> remotely. I'd hope that VSI doesn't blindly follow many of the older
> DEC software and business practices here, too. That probably won't end
> well, if they just clone the DEC playbook and business practices.
>
> > Now there has been be some unofficial talk about VSI developing C and
> > CXX (bringing C up to the latest C11 standard; adding a "/GCC" switch
> > to both c and c++; etc)
>
> That /STANDARD=GCC mechanism already exists. It's unfortunately
> compatible with an ancient version of GCC; somewhere around GCC 2.8 or
> so. GCC is presently at 4.9.2, with 5.0 in development.
>
> > but I suspect this will only happen for the Itanium product. If people
> > consider this stuff you will need to step up.
>
> Based on what VSI has commented, their schedule targets Itanium

> hardware releases for i2 and i4 servers -- and not specifically the
> older Itanium hardware -- and then the x86-64 port.

>
> Whether VSI ends up adding support for V8.4 and earlier on Itanium or
> on Alpha or anything for VAX is not something that they (and HP) seem
> willing to step into right now. VSI needs to get V8.4-1H1 out, stable,
> and available, they've planned V8.4-1H2, when (if?) the Kittson servers
> appear, and they need to get VMS ported to x86-64. Alpha... isn't
> anything VSI has commented on.
>
> Personally, if VSI does pick up support for older VMS releases or for
> Alpha releases, I'd wonder how well they're doing with moving VMS

> forward -- they're either doing really well with their finances and

> their staffing, or the x86-64 port and the new work is in Deep
> Sneakers; getting short shrift.
>
> > On big show stopper for us is Apache. If we didn't have access to it
> > then we would have been forced off OpenVMS. Now I don't need to point
> > out that improvements to c/c++ are going to make the next port of
> > Apache to OpenVMS easier. If it is easy on Itanium and not so easy on
> > Alpha then I could see a new version of Apache being offered for one
> > but not the other.
>
> What New Shiny might arrive with V8.4-1H1, we shall see. If any, of course.
>
>
> --
> Pure Personal Opinion | HoffmanLabs LLC

I guess I should clarify my comments about GNU mode. First off, while it is true that CLI switch "/standard=gnu" exists for CXX, it does not exist for C (at least not HP C V7.3-010 on OpenVMS Alpha V8.4 but I will check for possible updates today).

{ comment: this might not be a negative since most people today use a C++ compiler to write C programs }

But this switch doesn't extend to features in the respective libraries: for example, strftime on OpenVMS does not support "%z" but does support "%Z" (I have been told this is a GCC extension)

I have been told there are many gnu extensions which simplify the parsing of name_server returns; something probably necessary on most computer systems today.

Neil

[Bill Gunshannon]

In article <6849c603-4e36-40bd...@googlegroups.com>,

Neil Rieck <n.r...@sympatico.ca> writes:
> On Friday, February 20, 2015 at 7:08:41 PM UTC-5, Neil Rieck wrote:
> [...snip...]

> A few more thoughts: when you compare the version numbers of c and cxx between Alpha and Itanium it is already apparent that HP is not improving Alpha. On top of this, I have reported two problems with BASIC on Alpha in the p=

> ast three years which HP promptly fixed for me, but not for everyone else. So Alpha is already in maintenance-only mode.
>

> Unless I missed it, VSI "is working on Itanium" and "intends to work on x86-64" but has never announced any plans regarding Alpha. So I fear that Alpha will end up like VAX, stuck in time. Sure they will chug away for years but that is no good for platforms needing new code. (OS or application)
>

I thought VSI said early on that their agreement with HP did not include
the Alpha and they would not be permitted to do anything for it.

> Now there has been be some unofficial talk about VSI developing C and CXX (bringing C up to the latest C11 standard; adding a "/GCC" switch to both c and c++; etc) but I suspect this will only happen for the Itanium product. If people consider this stuff you will need to step up.
>

See comment above!!

> On big show stopper for us is Apache. If we didn't have access to it then we would have been forced off OpenVMS. Now I don't need to point out that improvements to c/c++ are going to make the next port of Apache to OpenVMS easier. If it is easy on Itanium and not so easy on Alpha then I could see a new version of Apache being offered for one but not the other.
>

> Just my 2-cent worth
>

Welcome to the real world. Aplha is dead and HP is still happily driving
nails into the coffin.

bill

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

[Bill Gunshannon]

In article <mcb7q2$g6l$1...@dont-email.me>,

Are you sure? I thought they explicitly stated in accord with their
agreement with HP, they could not and thus would not be doing anything
with Alpha.

[Bill Gunshannon]

In article <mcdfh5$2a1$2...@dont-email.me>,

As I stated, I remember early statements from VSI about what was
allowed and not allowed and I think Alpha fell nto the "not" catagory.

>
> What is not prohibited, is allowed ....

Try telling that to a lawyer. The days of "It is easier to ask
forgiveness than permission." are long gone and failure to accept
that could prove very costly.

[Jan-Erik Soderholm]

Bill Gunshannon skrev den 2015-02-23 14:49:
> In article <mcb7q2$g6l$1...@dont-email.me>,
> Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>> On 2015-02-22 00:01:17 +0000, Stephen Hoffman said:
>>
>> Clarification:
>>
>>> Whether VSI ends up adding support for V8.4 and earlier on Itanium or
>>> on Alpha or anything for VAX is not something that they (and HP) seem
>>> willing to step into right now. VSI needs to get V8.4-1H1 out, stable,
>>> and available, they've planned V8.4-1H2, when (if?) the Kittson servers
>>> appear, and they need to get VMS ported to x86-64.
>>
>> [Future releases of...]
>>
>>> Alpha... isn't anything VSI has commented on.
>
> Are you sure? I thought they explicitly stated in accord with their
> agreement with HP, they could not and thus would not be doing anything
> with Alpha.
>
> bill
>

As i recal, they would not do anything up to and including
the currect V8.4. Whatever is true, Alpha is not their focus
area, of course. :-)

[JF Mezei]

On 15-02-23 08:49, Bill Gunshannon wrote:

> Are you sure? I thought they explicitly stated in accord with their
> agreement with HP, they could not and thus would not be doing anything
> with Alpha.

Nop. Alpha and pre-poulson customers are out of reach of VSI as they
remain HP customers. HP is free to order Alpha/IA64 updates from VSI to
distribute to those customers. (whether HP has actually done so is not
conformed).

[David Froble]

Bill Gunshannon wrote:
> In article <mcb7q2$g6l$1...@dont-email.me>,
> Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>> On 2015-02-22 00:01:17 +0000, Stephen Hoffman said:
>>
>> Clarification:
>>
>>> Whether VSI ends up adding support for V8.4 and earlier on Itanium or
>>> on Alpha or anything for VAX is not something that they (and HP) seem
>>> willing to step into right now. VSI needs to get V8.4-1H1 out, stable,
>>> and available, they've planned V8.4-1H2, when (if?) the Kittson servers
>>> appear, and they need to get VMS ported to x86-64.
>> [Future releases of...]
>>
>>> Alpha... isn't anything VSI has commented on.
>
> Are you sure? I thought they explicitly stated in accord with their
> agreement with HP, they could not and thus would not be doing anything
> with Alpha.
>
> bill
>

I do not recall reading anything that says what VSI will not, or can
not, do. What I've read is that the old stuff remains HP's, and new
versions VSI produces belong to VSI.

VSI has indicated what they will do, and that is reasonable. But I have
not seen one thing, other than they cannot sell support for the old
stuff, and that wasn't real clear, that specifies anything they cannot do.

Someone I won't mention by initials seems to thing that if VSI doesn't
say they will do something, then that implies they cannot do such.
Don't know where he learned his logic.

Speculation aside, revenue from the new itanic releases, and the future
of x86, sure seems like more than enough to keep them busy for a while.

[Phillip Helbig (undress to reply)]

In article <mccv8k$vbr$1...@dont-email.me>, Stephen Hoffman

<seao...@hoffmanlabs.invalid> writes:

> The source code pool was (and very likely still is) identical. The
> same Rdb databases and the same CMS libraries were used, and the same
> cluster was used for building both OpenVMS Alpha and OpenVMS I64.

So Rdb is used internally in the VMS build? Interesting.

> By present standards, Alpha systems are very inefficient, in terms of

> power, cooling, physical size and performance. Maintenance costs are
> increasing. Peripherals are old and slow, and compatible replacements
> and parts are increasing in price. Memory storage and disk storage
> capacities are low. There are no new Alpha systems. Refurbs and
> salvage and bespoke parts are your options here. Alpha is market
> that's been going the wrong way for a number of years, and VSI does not
> have infinite resources to try to stem that or to reverse that.

That's why VMS on x86 might be the first new VMS system I have bought in
a long time, if there is an "entry-level" system available.

[clairg...@gmail.com]

I was traveling last week and am just catching up with this thread. John and Steve have said most everything but I'll throw in my view. Yes, Alpha systems are a critical piece of our build environment. We've toyed with what it would take to eliminate Alpha but there is no big hurry to do anything.

We build both Alpha VMS and Itanium VMS from the same set of sources that live in Rdb. We will be adding x86 support to these sources just as we added Itanium support to the Alpha sources a few (many?) years ago.

Also, regardless of any legal dos or don'ts we will continue to build Alpha VMS. I don't want to unnecessarily burn any bridges; the future is not that predictable.

We will support selected i2 and i4 systems with our releases. We will also pick and choose a few pre-i2 Itanium systems based on demand which we have had plenty of already. Yes, we need to stay focused but we won't completely ignore large sets of people who want to support us.

[Phillip Helbig (undress to reply)]

In article <d1a9d043-5ec5-469b...@googlegroups.com>,

clairg...@gmail.com writes:

> We build both Alpha VMS and Itanium VMS from the same set of sources that
> live in Rdb.

Is there some description of this process? Particularly how the sources
live in Rdb.

[John Reagan]

On Tuesday, February 24, 2015 at 1:31:44 PM UTC-5, Phillip Helbig (undress to reply) wrote:

>
> Is there some description of this process? Particularly how the sources
> live in Rdb.

He meant "source lives in CMS managed by VDE which it turn uses Rdb"

[Dirk Munk]

hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) wrote:
> In article <mccv8k$vbr$1...@dont-email.me>, Stephen Hoffman
> <seao...@hoffmanlabs.invalid> writes:
>
>> The source code pool was (and very likely still is) identical. The
>> same Rdb databases and the same CMS libraries were used, and the same
>> cluster was used for building both OpenVMS Alpha and OpenVMS I64.
>
> So Rdb is used internally in the VMS build? Interesting.
>

No, CMS/MMS is used to store the sources etc. and CMS/MMS is using RdB
under the hood. As you will know CMS/MMS is/was part of DECset.

[Dirk Munk]

I've been reading this contribution several times now to understand what
you're trying to say.

So VSI has all the means to build Alpha VMS versions and layered
products, and VSI is making those builds.

Now I'm getting to the "burning bridges" remark, and "ignoring large
sets of people" remark.

It seems to me as if you are trying to say this:

if there is sufficient customer demand
and
if HP is willing to deliver or allow Alpha VMS upgrades again
and
if HP and VSI can agree on the commercial matters
and
if VSI has sufficient resources available,
then
it is thinkable that VSI and/or HP will provide upgrades for Alpha VMS
and Alpha layered products again.

Am I right?

[Stephen Hoffman]

On 2015-02-24 23:28:11 +0000, Dirk Munk said:

> hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) wrote:
>> In article <mccv8k$vbr$1...@dont-email.me>, Stephen Hoffman
>> <seao...@hoffmanlabs.invalid> writes:
>>
>>> The source code pool was (and very likely still is) identical. The
>>> same Rdb databases and the same CMS libraries were used, and the same
>>> cluster was used for building both OpenVMS Alpha and OpenVMS I64.
>>
>> So Rdb is used internally in the VMS build? Interesting.
>
> No, CMS/MMS is used to store the sources etc. and CMS/MMS is using RdB
> under the hood. As you will know CMS/MMS is/was part of DECset.

Yes, Oracle Rdb is very centrally used within the OpenVMS builds.

DECset MMS is not central to and is not particularly used within the
OpenVMS builds.

In isolation, neither DECset CMS nor DECset MMS uses nor depends on Oracle Rdb.

VDE and DCL procedures that call VDE are used to access and to maintain
the sources, with the file delta data being stored in CMS, with binary
blobs being stored alongside the CMS libraries, and with the file and
release relationships, notifications, reviews, change history and the
rest all stored in Rdb. VDE in particular is used to manage the
hundreds of CMS libraries involved and the rest of the bits as a unit,
as well as implementing mechanisms that DECset CMS didn't and variously
still doesn't provide.

The OpenVMS build is a collection of data-driven and entirely custom,
parallelized DCL procedures, and not based on DECset MMS, though there
are probably a few MMS bits within some specific VMS facilities. The
build is most definitely not MMS-based. The build fetches the data
from CMS for various reasons, though VDE does contain its own
dependency-based builder.

As I've mentioned earlier in this thread, VDE and its (extensive)
documentation is available on the Freeware for those that are
interested in a look at VDE and its associated tools and facilities,
and there are probably still some OpenVMS build environment
presentations posted around the 'net for those that are interested in a
more general overview of the environment. One of these presentations
was at DECUS San Diego in 1999, entitled "VDE: The OpenVMS Source Code
Control System", though I don't immediately find a copy of that
presentation posted. Similar customer sessions were presented a few
other times. (VDE being one of the most expensive pieces of Freeware
around, when you account for the Orace Rdb dependency. But I digress.)

[Craig A. Berry]

On 2/23/15 6:44 AM, Neil Rieck wrote:

>
> I guess I should clarify my comments about GNU mode. First off, while
> it is true that CLI switch "/standard=gnu" exists for CXX, it does
> not exist for C (at least not HP C V7.3-010 on OpenVMS Alpha V8.4 but
> I will check for possible updates today).
>
> { comment: this might not be a negative since most people today use a
> C++ compiler to write C programs }

I don't think that's true. What is true is that you usually get both
compilers as part of the same product or package. The fact that you have
to buy them separately on VMS isn't how it's typically done in the rest
of the industry.

> But this switch doesn't extend to features in the respective
> libraries: for example, strftime on OpenVMS does not support "%z" but
> does support "%Z" (I have been told this is a GCC extension)

As I said here recently, %z is C99, not GNU. If you want more modern C on
VMS, what you want is C99 and C11, not anything remotely resembling the
/standard=gnu from C++.

> I have been told there are many gnu extensions which simplify the
> parsing of name_server returns; something probably necessary on most
> computer systems today.

I'm skeptical since the code that does that sort of thing would need to
be portable but I guess it's possible.

[mcle...@gmail.com]

So HP and now VSI have to pay Oracle for Rdb licence fees in order to maintain and develop VMS?


John

[David Froble]

I think Clair wrote what he intended to write, and doesn't want to, or
cannot, say more.

Which is fine for now. i4 and x86 are enough problems for now.

[David Froble]

mcle...@gmail.com wrote:

> So HP and now VSI have to pay Oracle for Rdb licence fees in order to maintain and develop VMS?

Well, you could turn it around ans say that Oracle has to pay
DEC/Compaq/HP/VSI VMS license fees in order to maintain and develop RDB.

I can imagine there being some quid-pro-quo arrangements.

I can imagine DEC retaining rights to use RDB internally when the
product was given to Oracle.

[Jan-Erik Soderholm]

So what? Any craftsman has to pay for his tools. It would be
very hard for, say, a carpenter to work without tools. I also
expect the VMS engineers to use appropriate tools. If Rdb happens
to be the right tool for the job here, what is the problem?

[Bill Gunshannon]

In article <69aff$54ed0d87$5ed4324a$26...@news.ziggo.nl>,

If. If. If.

If we had ice cream, we could have cake and ice cream, if we had cake.

[Bill Gunshannon]

In article <mcjhqu$4h6$2...@dont-email.me>,

David Froble <da...@tsoft-inc.com> writes:
> mcle...@gmail.com wrote:
>
>> So HP and now VSI have to pay Oracle for Rdb licence fees in order to maintain and develop VMS?
>
> Well, you could turn it around ans say that Oracle has to pay
> DEC/Compaq/HP/VSI VMS license fees in order to maintain and develop RDB.
>
> I can imagine there being some quid-pro-quo arrangements.

I think not. At least my understanding was that Oracle got Rdb,
lock, stock and barrel.

>
> I can imagine DEC retaining rights to use RDB internally when the
> product was given to Oracle.

That runs contrary to most of the things that have been done by DEC and
it's follow-ons since its demise. At least based on what has been said
here for years.

[David Froble]

Bill Gunshannon wrote:
> In article <mcjhqu$4h6$2...@dont-email.me>,
> David Froble <da...@tsoft-inc.com> writes:
>> mcle...@gmail.com wrote:
>>
>>> So HP and now VSI have to pay Oracle for Rdb licence fees in order to maintain and develop VMS?
>> Well, you could turn it around ans say that Oracle has to pay
>> DEC/Compaq/HP/VSI VMS license fees in order to maintain and develop RDB.
>>
>> I can imagine there being some quid-pro-quo arrangements.
>
> I think not. At least my understanding was that Oracle got Rdb,
> lock, stock and barrel.
>
>> I can imagine DEC retaining rights to use RDB internally when the
>> product was given to Oracle.
>
> That runs contrary to most of the things that have been done by DEC and
> it's follow-ons since its demise. At least based on what has been said
> here for years.
>
> bill
>

I fear that's probably correct. Expecting anything reasonable to come
out of the Palmer era is probably unreasonable.

[Dirk Munk]

Up till know I was under the impression that VSI would definitely not do
any work for the Alpha platform. Now it seems as if Clair isn't
completely ruling out work for the Alpha any more. That would be a major
difference.

[David Froble]

If it's common code, then any work done to it would be applicable to all
platforms that use the common code.

Whether they then build and distribute new Alpha versions is another matter.

[clairg...@gmail.com]

Nothing has changed. VSI has no plans to do anything with Alpha. I'm just trying to make sure that if the legal agreements and company policies in place today change in the future, we don't do anything technically to make it unduly difficult or impossible to pursue more possibilities. There is no hidden agenda here, for very little cost we can avoid the potential of looking really stupid.

[JF Mezei]

On 15-02-25 12:43, clairg...@gmail.com wrote:

> Nothing has changed. VSI has no plans to do anything with Alpha. I'm just trying to make sure that if the legal agreements and company policies in place today change in the future, we don't do anything technically to make it unduly difficult or impossible to pursue more possibilities. There is no hidden agenda here, for very little cost we can avoid the potential of looking really stupid.
>

Are fixes to Alpha 8.4 and below, which HP claims will be available to
customers on support going to be done by HP in India or by you ?

[Dirk Munk]

I wasn't trying to imply that VSI has plans or a hidden agenda to do
something with Alpha. On the other hand if you would rule out for 100%
that you would ever do any work for the Alpha again, then you could
safely delete the Alpha branch on your development server. But you want
to keep your options open (very wise :-) ), and that is what I wanted to
express with my four ifs.

[Phillip Helbig (undress to reply)]

In article <f90f1c82-8746-4590...@googlegroups.com>, John

Reagan <xyzz...@gmail.com> writes:

> On Tuesday, February 24, 2015 at 1:31:44 PM UTC-5, Phillip Helbig (undress to reply) wrote:
>
> >

> > Is there some description of this process? Particularly how the sources
> > live in Rdb.
>

> He meant "source lives in CMS managed by VDE which it turn uses Rdb"

OK. I didn't think the source code was stored in Rdb (though, in
principle, it could be). What is VDE?

[Phillip Helbig (undress to reply)]

In article <44e8b$54ed090c$5ed4324a$22...@news.ziggo.nl>, Dirk Munk

<mu...@home.nl> writes:

> >> The source code pool was (and very likely still is) identical. The
> >> same Rdb databases and the same CMS libraries were used, and the same
> >> cluster was used for building both OpenVMS Alpha and OpenVMS I64.
> >
> > So Rdb is used internally in the VMS build? Interesting.
>

> No, CMS/MMS is used to store the sources etc. and CMS/MMS is using RdB
> under the hood. As you will know CMS/MMS is/was part of DECset.

CMS and MMS I'm (somewhat) familiar with, but they don't use Rdb under
the hood, do they?

[Dirk Munk]

hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) wrote:

The OpenVMS Development Environment (VDE) package is the set of tools
that the OpenVMS development group uses to control and to track changes
to the multiple VDE libraries that comprise the OpenVMS Master Pack.

[John Reagan]

On Wednesday, February 25, 2015 at 3:35:37 PM UTC-5, Dirk Munk wrote:

> I wasn't trying to imply that VSI has plans or a hidden agenda to do
> something with Alpha. On the other hand if you would rule out for 100%
> that you would ever do any work for the Alpha again, then you could
> safely delete the Alpha branch on your development server. But you want
> to keep your options open (very wise :-) ), and that is what I wanted to
> express with my four ifs.

There is no "Alpha branch". There are modules that get compiled only for Alpha. There are modules with embedded #if/%if directives with Alpha-specific code.

[John Reagan]

On Wednesday, February 25, 2015 at 3:40:35 PM UTC-5, Phillip Helbig (undress to reply) wrote:

> CMS and MMS I'm (somewhat) familiar with, but they don't use Rdb under
> the hood, do they?

No.

[Jan-Erik Soderholm]

But, you can ask MMS/CMS to fetch code from CDD, not?
And CDD uses Rdb "under the hood".

But as I understand VDE is the umbrella that ties all
together and that (VDE) uses Rdb to keep track, right?

Not that it mater *that* much...

[John Reagan]

On Wednesday, February 25, 2015 at 4:16:47 PM UTC-5, Jan-Erik Soderholm wrote:
> John Reagan skrev den 2015-02-25 22:12:
> > On Wednesday, February 25, 2015 at 3:40:35 PM UTC-5, Phillip Helbig (undress to reply) wrote:
> >
> >> CMS and MMS I'm (somewhat) familiar with, but they don't use Rdb under
> >> the hood, do they?
> >
> > No.
> >
>
> But, you can ask MMS/CMS to fetch code from CDD, not?
> And CDD uses Rdb "under the hood".

Not that I know of. Most of the compilers have %DICTIONARY directives that extract data definitions from the CDD and convert to language-specific syntax. I've never seen entire code modules inside of the CDD. Even with the compiler %DICTIONARY directive, I wouldn't say that the compiler uses Rdb to compile.

>
> But as I understand VDE is the umbrella that ties all
> together and that (VDE) uses Rdb to keep track, right?
>

Yes

[JF Mezei]

On 15-02-25 15:35, Dirk Munk wrote:

> I wasn't trying to imply that VSI has plans or a hidden agenda to do
> something with Alpha. On the other hand if you would rule out for 100%
> that you would ever do any work for the Alpha again,

Consider the possibiliy of VEST (or whatever) of Alpha binaries being
made available on the new x86 VMS. (as well as equivalent for IA64 binaries)

Such an endeavoiur would require some up-to-date Alpha libraries and
likely some intermediate libraries. So better keep the Alpha code base
in there and in synch.


If/when a decision is made that a Vest-like translator for Alpha
binaries on x86 will NOT be made availble, then they can spend the
time"money to trim the code tree of all Alpha branches. Lots of #IFDEF
removal work to be done :-)

[Stephen Hoffman]

On 2015-02-25 21:16:47 +0000, Jan-Erik Soderholm said:

> John Reagan skrev den 2015-02-25 22:12:
>> On Wednesday, February 25, 2015 at 3:40:35 PM UTC-5, Phillip Helbig
>> (undress to reply) wrote:
>>
>>> CMS and MMS I'm (somewhat) familiar with, but they don't use Rdb under
>>> the hood, do they?
>>
>> No.
>
> But, you can ask MMS/CMS to fetch code from CDD, not?

VDE does not use CDD/Repository in any fashion, nor do VMS builds make
particular use of MMS, nor do users access CMS directly.

> And CDD uses Rdb "under the hood".

VDE does use Rdb, but does not use CDD in any fashion.

> But as I understand VDE is the umbrella that ties all together and that
> (VDE) uses Rdb to keep track, right?

Correct.

[Paul Sture]

On 2015-02-25, Phillip Helbig (undress to reply)

From the VMS Freeware V7 README:

"VDE, UTILITIES, OpenVMS Source Code Control System

The VDE tools allow you to maintain and to control multiple CMS
libraries as a single unit.

Full documentation of VDE is available in Postscript, HTML, and
Bookreader formats.

VDE requires the presence of various software tools, including CMS
and Oracle Rdb. Complete details are in the installation manual.

PLMENU is a set of procedures layered on VDE and CMS that provide
various functions. A subset of PLMENU tools are included here."

Available as a .PCSI at:

<http://www.decuslib.com/freeware/freewarev70/vde/>

or

<http://www.digiater.nl/openvms/freeware/v70/vde/>

--
Don't ever use the last two versions of GCC in serious stuff :)
-- fortune cookie seen on GCC Bugzilla – Bug List

[Bob Koehler]

In article <54ee4da0$0$29444$c3e8da3$e074...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
>
> Consider the possibiliy of VEST (or whatever) of Alpha binaries being
> made available on the new x86 VMS. (as well as equivalent for IA64 binaries)

IIRC, VSI has already made an announcement on thier plans in this
area. No need to speculate.

[Stephen Hoffman]

JF already knows that
<https://groups.google.com/d/msg/comp.os.vms/m513D7NK1i0/ciHjIY0l4EkJ>.

[clairg...@gmail.com]

This is one of the trickiest parts of the entire partnership. Here is the theory: updates for 8.4 and prior will be produced by the HP VMS Team and updates to 8.4-1H1 and later will come from us. However, behind the curtains the groups will be sharing what they find/fix and deciding what to do in their own code base. Every detail of how this will be done in practice has not been fleshed out yet but that is our working strategy. There are tons of "what ifs" possible but we will just have to work through them as we gain experience. This will never be perfect but it should be doable to a great degree.

[William Pechter]

In article <ckmtq0...@mid.individual.net>,
Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>In article <54e6356d$0$44801$c3e8da3$dd96...@news.astraweb.com>,
> JF Mezei <jfmezei...@vaxination.ca> writes:
>> On 15-02-19 12:16, Dirk Munk wrote:
>>
>>> I suspect their x86-64 products will only get better each year, and
>>> this can only be a good thing if OpenVMS can run natively on them.
>>
>> One risk is ARM.
>>
>> It can be that mobile/embedded will go ARM and computers/servers will
>> stay x86. Or desktops might move to ARM.
>>
>> Intel has not had success for mobile devices. So even the x86 isn't a
>> success everywhere.
>>
>> Consider what happened when AMD decided to make a 64 bit 8086, forcing
>> Intel to throw in the towel on its policy of 64 bit = itanium and
>> following AMD's lead.
>>
>> Imagine if AMD starts to produce high performance server chips based on
>> ARM architecture ? This might be quite interesting
>
>That is the kind of thinking that brought down Itanium. Do you want
>AMD to do the same and cede the market back to Intel?
>>
>> In fact, Apple is rumoured to be toying with the idea of moving its
>> desktops/laptops to ARM.
>
>Haven't heard anything about that. Apple alerady was on non-standard
>chips. Where did they end out? And if they moved to ARm and were
>successful why shold I think it is anything other than more of their
>followers religion?
>
>So much for devil's advocat (although I place little if any value in
>what Apple users do. Apple's systems have been technically inferior
>since thevery beginning.)
>
>If you have access to a Windows Server 2012 system take a look in
>C:\Program Files(x86)\Windows Kits\8.0\bin
>
>Come back and tell people what you see. :-)
>
>
>>
>>
>> From a VSI point of view, a move to ARM shouldn't be a big deal. In the
>> past, VMS was tied to vendor who had vested interests in chips, except
>> for short tenure under Pfeiffer at Compaq. VMS was tied to VAX and then
>> Alpha, and then to that IA64 thing under HP.
>>
>> But with VSI "free", they become architecture agnostic since they have
>> no vested interests in any one specific architecture (until they
>> resurrect the 64 bit VAX, or course :-)
>
>I expect to see that right after I release 64bit RSTS/E.

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

Damn... Bill I started a design layout for 32 bit PDP11's back in the 90's.
You want me to do 64 bit now... 8-).

The main issue was really getting in different memory management with
larger pages... I'd use 4096 now to match the new disks.

Who's doing the Basic Plus...

Bill

--
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-gmail.com http://xkcd.com/705/

[Bill Gunshannon]

In article <mda237$35q$1...@pechter.eternal-september.org>,

> Damn... Bill I started a design layout for 32 bit PDP11's back in the 90's.
> You want me to do 64 bit now... 8-).
>
> The main issue was really getting in different memory management with
> larger pages... I'd use 4096 now to match the new disks.
>
> Who's doing the Basic Plus...
>

People always laugh, but I actually expect that given the full sources for
everything RSTS/E and the necessary permissions to do it, I could probably
single-handedly have a port running on some other architecture in less
than a year. And being as I am about to be retired (this time for real!!)
in just a couple of months, it's not like I wouldn't have the time to do
it. Hmmm... RSTS/E-6809. Maybe RSTS/E-Z80 and, of course, RSTS/E-agnostic.

[Jonathan]

> > Damn... Bill I started a design layout for 32 bit PDP11's back in the 90's.
> > You want me to do 64 bit now... 8-).
> >
> > The main issue was really getting in different memory management with
> > larger pages... I'd use 4096 now to match the new disks.
> >
> > Who's doing the Basic Plus...

We'll do it, we did the first one. :)

Jonathan

EGH

[David Froble]

Jonathan wrote:

>>> Who's doing the Basic Plus...
>
> We'll do it, we did the first one. :)
>
> Jonathan
>
> EGH

John, always good to hear you're still kicking ...

:-)

Is Dave (I think that is his name) Hart still there? It would maybe be
good to hear some stories from the old days, who did what, why, and how.

[Bill Gunshannon]

In article <4f386b01-19f1-4c59...@googlegroups.com>,

Jonathan <jtc...@gmail.com> writes:
>> > Damn... Bill I started a design layout for 32 bit PDP11's back in the 90's.
>> > You want me to do 64 bit now... 8-).
>> >
>> > The main issue was really getting in different memory management with
>> > larger pages... I'd use 4096 now to match the new disks.
>> >
>> > Who's doing the Basic Plus...
>
> We'll do it, we did the first one. :)

What was it written in? MACRO-11?

bill

>
> Jonathan
>
> EGH
>
>> >
>>
>> People always laugh, but I actually expect that given the full sources for
>> everything RSTS/E and the necessary permissions to do it, I could probably
>> single-handedly have a port running on some other architecture in less
>> than a year. And being as I am about to be retired (this time for real!!)
>> in just a couple of months, it's not like I wouldn't have the time to do
>> it. Hmmm... RSTS/E-6809. Maybe RSTS/E-Z80 and, of course, RSTS/E-agnostic.
>>
>> bill

[seasoned_geek]

Sadly, putting VMS on x86 will ensure it a market life of minutes, not years. It is a special OS and needs a special kick booty chip. The earlier comments in this thread about Solaris running faster and better on SPARC T5 should provide a guiding light, but it won't. By all accounts Solaris should have been long gone from the market by now, but, a certain segment of the market cannot make do with Wal-mart quality chips so Solaris continues.

VMS also serves a market segment which cannot make do with Wal-mart quality chips. Porting VMS to Wal-mart quality chips ensures its demise. Porting VMS to the Wal-mart quality x86 line is like feeding chocolate to dogs. They beg for it, but for them it is fatal.

[johnwa...@yahoo.co.uk]

On Wednesday, 11 March 2015 11:06:59 UTC, seasoned_geek wrote:
> Sadly, putting VMS on x86 will ensure it a market life of minutes, not years. It is a special OS and needs a special kick booty chip. The earlier comments in this thread about Solaris running faster and better on SPARC T5 should provide a guiding light, but it won't. By all accounts Solaris should have been long gone from the market by now, but, a certain segment of the market cannot make do with Wal-mart quality chips so Solaris continues.
>
> VMS also serves a market segment which cannot make do with Wal-mart quality chips. Porting VMS to Wal-mart quality chips ensures its demise. Porting VMS to the Wal-mart quality x86 line is like feeding chocolate to dogs. They beg for it, but for them it is fatal.

It's not The Chip Inside(tm) that makes a cheap x86 system a nasty
system, especially now Intel have finally abandoned that ridiculous
IA64 thing in favour of designing and making their own AMD64 clones
(x86-64 is of course an architecture which Intel HQ had earlier said
was impossible to do, but times change...).

People have been continuing to buy VMS largely *despite* IA64, not
*because* of IA64.

Porting VMS to AMD64 with support on a suitably qualified subset of
HPQ servers, the same servers already found in most of the world's
enterprise-class datacentres [1], removes one of the obstacles to VMS's
continued survival. That announcment alone indicates that VSI are
to be taken reasonably seriously. Announcements are just a start.

A completed x86-64 port also removes one of the barriers to entry
for outfits that may just want a low cost low hassle way to try
kicking the tyres of a VMS system - no longer need there be any
need to try to scrounge an IA64 box from HP or a reseller, when
the hardware involved is likely the same hardware that is bread
and butter to these organisations. That may of course mean that
now isn't a good time for a reseller to be dependent on margins
on VMS-specific hardware, but any reseller still in that situation
has been heading for trouble anyway.

Lots of other things to think about for VSI and VMS.

[1] I see earlier this week HP announced a deal with Foxconn for
"Cloudline" servers which are said to appeal to Facebook/Google/etc -
basically a commodity low end server with none of the Proliant value
add, a box that has little consequence if it fails because no one
really cares about lost or corrupt data at FB or G, and you can throw
the box away when it fails because they're bought by the thousand
on a 2year lifecycle anyway. I'm not sure why that will now be an HP
market just by adding an HP badge and HP margins. More relevantly,
massive but lightweight scalability historically hasn't been the VMS
market. It probably still isn't, but my crystal ball is bust again.

[Stephen Hoffman]

What's your alternative to x86-64 here? How much will the "special
kick booty chip" cost to produce and integrate?

Running your own competitive microprocessor designs and your own fab
requires huge scale and huge funding, or you're off the price and
performance curve — DEC bailed long ago, HP got Intel to partner and to
fab their design and that looks to end with Kittson, and IBM is the
only the most recent entity that is exiting the custom microprocessor
business.

Alternatives to x86-64? There's SPARC, and some designs like MIPS that
aren't as common with general computing, and various ARM designs are
moving into the low-end. Or dropping a few billion dollars into your
own design and your own fab or trying to use an outside fab, and with
no clear path to break-even. For example, Intel Fab 42 was to in in
Chandler AZ, and — though its opening has been postponed indefinitely —
was expected to cost Intel five billion dollars.

As for SPARC and Solaris, Oracle's business is apparently contracting —
they're profitable and variously more profitable than they've been, but
that's over fewer customers, per one of the more recent financial
reports. There's still good money in those existing Oracle customers,
but a contracting customer base is not popular with investors, and a
declining base means application availability for current and potential
new customers eventually becomes a problem.

For existing Solaris customers that want to move, there's illumos,
where there really wasn't a good path for OpenVMS customers.

I do still think VSI will be headed toward their own bespoke server
line directly or through a partnership, even if the folks at VSI might
not really want to take on that cost and that overhead. Servers using
Intel Xeon with ECC memory (q.v. rowhammer), and with decent-grade
components with available OpenVMS driver support. Quite possibly with
some sort of a DSMOSX lock-in for OpenVMS, for that matter.
<http://en.wikipedia.org/wiki/Apple–Intel_architecture#Dont_Steal_Mac_OS_X.kext>
Customers probably won't like the ~five to ~seven year server lifetime
of these servers and of x86-64 servers in general, but then the newer
servers have been the same or cheaper, and the efficiency and the
density has been increasing.

Special chips are a differentiator and a value when they're enough
special to warrant the costs and the hassles involved. That might be
faster, or it might mean better battery efficiency, or some other
factor. But the cost difference inherent in lower volumes and in the
added software work means that even chips and systems that are
ostensibly better designs are a tough sale in the market. At least
until you're operating at a scale well past where VSI is right now.

But to your point, whether the x86-64 port works out for VSI, we shall see.

[Stephen Hoffman]

On 2015-03-11 12:35:21 +0000, johnwa...@yahoo.co.uk said:

> [1] I see earlier this week HP announced a deal with Foxconn
> for"Cloudline" servers which are said to appeal to Facebook/Google/etc
> - basically a commodity low end server with none of the Proliant value
> add, a box that has little consequence if it fails because no one
> really cares about lost or corrupt data at FB or G, and you can throw
> the box away when it fails because they're bought by the thousand on a
> 2year lifecycle anyway. I'm not sure why that will now be an HP market
> just by adding an HP badge and HP margins. More relevantly, massive but
> lightweight scalability historically hasn't been the VMS market. It
> probably still isn't, but my crystal ball is bust again.

Was looking for specs on those, though the Open Compute stuff is very
interesting — standard server designs from various sources
<http://blogs.microsoft.com/firehose/2014/01/27/microsoft-contributes-cloud-server-designs-to-the-open-compute-project/>,
and with hardware available from various vendors, and where the buyer
can also spec the associated external components. Having standard
connections and features means wider support, and not having to adapt
to or to customize to the value-add features and protocols that are
offered by specific server vendors.

As for reliability features, Intel has been moving what various folks
have called RAS into their upper-end processors for some years.
<http://labs.hoffmanlabs.com/node/95> Intel are now selling RAS
features on their lower-end Xeon Processor D SoC that they recently
announced; RDIMM ECC, etc.

Yes, VSI is going to be dealing with what the Intel chips — or the AMD
chips, if VSI decides to add support for specific features of those —
are reporting up to the OS level for diagnostics or for host-OS
assistance with a detected error or for logging purposes, with the
recent chips. What isn't automatically dealt with by the chips, that
is.

Yes, the product lifetimes of the boxes are getting shorter.
Conversely, the newer boxes can be more dense or more power-efficient —
the older Itanium and Alpha boxes I work with are pretty hot, and
they're slow. As for reliability, if you use low-end low-cost on your
memory or install the cheapest disks you can find — as can happen with
an Integrity server or an AlphaServer, for that matter — you'll
probably have memory errors or disk errors. The bottom-end x86-64
boxes that the value-conscious folks tend to buy are pretty awful, too.
The upper end boxes have correspondingly higher-grade parts, and
better reliability.

As for what passes for VMS-related hardware reliability, DEC Field
Service used to be into one data center I'm familiar with once or twice
a month for random problems with any of five VAX boxes years ago —
memory failures, failed disks, dead controllers, failed systems. With
newer gear, that frequency of maintenance is just not something that's
required now, even with the value-conscious boxes. Those VAX boxes
cost US$50K for the middle configuration, and $100K for the upper-end
configuration, per box. I can afford to replace quite a few mid-upper
ProLiant-grade x86-64 server boxes for that, and more often, and still
have change left over for a nice steaming mug of tea. That, and the
newer boxes tend to be less expensive to power and cool, or I can stuff
more boxes into less space in the data center. Times change.

[li...@openmailbox.org]

On Wed, 11 Mar 2015 10:27:48 -0400
Stephen Hoffman via Info-vax <info...@rbnsn.com> wrote:

> On 2015-03-11 11:06:57 +0000, seasoned_geek said:
>
> > Sadly, putting VMS on x86 will ensure it a market life of minutes, not
> > years. It is a special OS and needs a special kick booty chip. The
> > earlier comments in this thread about Solaris running faster and better
> > on SPARC T5 should provide a guiding light, but it won't. By all
> > accounts Solaris should have been long gone from the market by now,
> > but, a certain segment of the market cannot make do with Wal-mart
> > quality chips so Solaris continues.
> >
> > VMS also serves a market segment which cannot make do with Wal-mart
> > quality chips. Porting VMS to Wal-mart quality chips ensures its
> > demise. Porting VMS to the Wal-mart quality x86 line is like feeding
> > chocolate to dogs. They beg for it, but for them it is fatal.
>
> What's your alternative to x86-64 here? How much will the "special
> kick booty chip" cost to produce and integrate?

There's a lot more wrong with Intel than can ever be fixed. I agree a good
processor would be nice from a programmer's POV and from a healthy market
POV.

SPARC is an open design. I don't know who's fabbing them today but if it
isn't Oracle itself than there's no R&D cost in using SPARC chips. They're
very good and they have some great features but they are not as fast as the
fastest Intel chips. If that doesn't matter than SPARC is a great design
with a lot going for it.

> As for SPARC and Solaris, Oracle's business is apparently contracting —
> they're profitable and variously more profitable than they've been, but
> that's over fewer customers, per one of the more recent financial
> reports.

There has been some discussion on various Solaris mailing lists about all
this. What you wrote is entirely intentional on Oracle's part. I would seem
there is great ego involved and getting the bish fish with killer deals and
ignoring small-mid sized companies is what it is all about now.

Oracle no longer markets or views SPARC as a general platform, it's only
used as an appliance engine for EXA-boxes (Oracle database appliances, etc.)
Solaris will eventually probably go away because of this "strategy."

A shame, because Solaris is a nice OS and the servers are very well
thought out and well made. OpenBoot is great. SPARC is a great platform.
And Solaris really does run better on it than on X86. You can feel it.

--
Please DO NOT COPY ME on mailing list replies. I read the mailing list.
RSA 4096 fingerprint 7940 3F02 16D3 AFEE F2F8 ACAA 557C 4B36 98E4 4D49

[Stephen Hoffman]

On 2015-03-11 15:37:02 +0000, <li...@openmailbox.org> said:

> On Wed, 11 Mar 2015 10:27:48 -0400 Stephen Hoffman via Info-vax
> <info...@rbnsn.com> wrote:
>
>> What's your alternative to x86-64 here? How much will the "special
>> kick booty chip" cost to produce and integrate?
>
> There's a lot more wrong with Intel than can ever be fixed.

Undoubtedly. But that's not a dragon that VSI can slay.

In short, what's your alternative here? SPARC just isn't it.

Whether ARM — which has its own warts, not the least of which is the
confusion and the misuse of TrustZone, and that SBSA is only just
getting going — will see increasing success in the server space, or
whether the Mill CPU can get traction?

Right now, it's Intel (and AMD) x86-64, and ARM as the most
likely-looking new candidate being ARMv8-A and SBSA designs.

> I agree a good processor would be nice from a programmer's POV and from
> a healthy market POV.

Good and elegant processors can and often do fail in the market,
whether we're discussing VAX or Alpha or other designs.

> SPARC is an open design. I don't know who's fabbing them today but if
> it isn't Oracle itself than there's no R&D cost in using SPARC chips.
> They're very good and they have some great features but they are not as
> fast as the fastest Intel chips. If that doesn't matter than SPARC is a
> great design with a lot going for it.

The great thing about open standards: there are so many to choose from.

Sure, having an open design — as is the case with Open Compute widgets
I mentioned elsewhere recently — can be a good thing, but you then have
to have the associated infrastructure and the available products, and
your products either have to be appreciably better than the competitive
products, or cheaper, or more efficient.

Right now, not running on the mainstream Windows x86-64 platform means
that whatever processor parts and server parts and system parts you
have is selling in lower volume, which means your prices are inherently
going to be somewhere between higher and much higher, which means you
inherently have a deeper competitive hole to dig yourself out of.

Whether OpenRISC <http://en.wikipedia.org/wiki/OpenRISC?> or some other
open-source hardware
<http://en.wikipedia.org/wiki/Open-source_hardware> gets you there,
eventually? That depends on how many designs and how many systems
become available, and particularly whether — and as end-user folks have
only rarely been willing to do — whether enough folks are willing to
migrate to what is an incompatible hardware to really matter; whether
there's enough interest to get the volumes high enough, and the prices
down.

>
>> As for SPARC and Solaris, Oracle's business is apparently contracting —
>> they're profitable and variously more profitable than they've been,
>> but that's over fewer customers, per one of the more recent financial
>> reports.
>
> There has been some discussion on various Solaris mailing lists about
> all this. What you wrote is entirely intentional on Oracle's part. I
> would seem there is great ego involved and getting the bish fish with
> killer deals and ignoring small-mid sized companies is what it is all
> about now.

I'd wager that Oracle sales would be happy to sell to smaller firms,
but they're running into some stiff competition with the likes of
PostgreSQL, SQLite and other databases. Some firms can and will need
vendor support, and that might mean commercial support for their
current databases, or a migration to Oracle. But there's a whole lot
of SQL code — and more than a little NoSQL code, for that matter —
which does not involve Oracle. Oracle wants to change that, but
whether they can do that often enough by moving folks up to their
premier products from MySQL remains to be determined.

> Oracle no longer markets or views SPARC as a general platform, it's
> only used as an appliance engine for EXA-boxes (Oracle database
> appliances, etc.) Solaris will eventually probably go away because of
> this "strategy."
>
> A shame, because Solaris is a nice OS and the servers are very well
> thought out and well made. OpenBoot is great. SPARC is a great
> platform. And Solaris really does run better on it than on X86. You
> can feel it.

Oracle is undoubtedly looking at their costs and their revenues, and
particularly at the associated trends.

Being on the wrong end of a market commoditization is not a pretty
place for any business, as you either need to drive massive volumes and
drive your costs down (q.v.
<http://en.wikipedia.org/wiki/Economies_of_scale>), or you need to have
enough of a value-add that folks still want to buy your gear.
Everybody's selling generic x86-64 boxes running Windows, so you're not
going to have an easy path to that, other than through cost reductions.
The folks that are shipping generic x86-64 boxes running Windows are
basically trapped by each other and by their ever-dropping prices they
can sell their equipment at — for pricing, there's
<http://gizmodo.com/hp-stream-11-review-200-and-worth-every-penny-1668809067>
and
<http://arstechnica.com/gadgets/2015/02/cheap-functional-upgradeable-hps-stream-and-pavilion-mini-desktops-reviewed/>
— and thus the vendors are left to make revenue with add-ons (and that
occasionally cause problems
<http://arstechnica.com/security/2015/02/ssl-busting-code-that-threatened-lenovo-users-found-in-a-dozen-more-apps/>)
or through post-sales services and support and add-ons — and HP is one
of the few vendors that is reasonably well positioned here and
particularly for the business markets, or the vendor can try to add
value — which takes time and effort and with no clear and no certain
path to a return even assuming the cash is available for that effort,
and whether it's trying to create value from custom software or a
custom OS or custom add-on features such as distributed management — or
to consolidate and buy up competitors, or the vendor can sell off and
exit the market while the current products and services and retail
shelf space and trademarks still have some value to potential buyers.

Elegance and simplicity can sell, if you invest in what that costs,
really work at all of what that means, and if you can market it.
Effectively. But an elegant processor architecture? That's a much
tougher sale to make to an end-user, particularly given how much more
that elegant processor can cost as compared with a design that's in
ginormous production volumes.

FWIW and if processor elegance is of general interest to you, maybe
have a look at the ARMv8-vintage architecture, within the current crop
of potential choices.