VSI OpenVMS Alpha V8.4-2L1 Layered Product Subset Available

[Stephen Hoffman]

Haven't seen it posted here yet, and it's not posted on the VSI web site...

VSI have announced the availability of a subset of the layered products
for the VSI OpenVMS Alpha V8.4-2L1 release.

The following products are included:

ACMS, AvailMan, BASIC, C, C++. COBOL, CXML, DTR, DECdfs, DECforms,
DCPS, DECset, DFO, DCE, DQS, Enterprise Directory LDAP, FMS. Fortran,
I18N, MRU, Pascal, SSM, T4, TDMS

Licensing changes announced, too. One VSI ALPHA-SYSTEM PAK for
OpenVMS, one VSI ALPHA-LP PAK for the layered products.

[Stephen Hoffman]

Post by Stephen Hoffman
Haven't seen it posted here yet, and it's not posted on the VSI web site...
VSI have announced the availability of a subset of the layered products
for the VSI OpenVMS Alpha V8.4-2L1 release.

Good news, BTW.
More of these announcements, please.
More preparation around these sorts of announcements too, please.
Look forward.
Advertise and build on the VSI achievements and advancements.
Also mention about how these steps lead OpenVMS folks to x86-64, which
is the future of the platform.
Discussing the past can be entertaining for some, but these products
and the future (of OpenVMS and of VSI) are what folks are buying.

[Bill Gunshannon]

Post by Stephen Hoffman
Haven't seen it posted here yet, and it's not posted on the VSI web site...
VSI have announced the availability of a subset of the layered products
for the VSI OpenVMS Alpha V8.4-2L1 release.
ACMS, AvailMan, BASIC, C, C++. COBOL, CXML, DTR, DECdfs, DECforms, DCPS,
DECset, DFO, DCE, DQS, Enterprise Directory LDAP, FMS. Fortran, I18N,
MRU, Pascal, SSM, T4, TDMS
Licensing changes announced, too. One VSI ALPHA-SYSTEM PAK for
OpenVMS, one VSI ALPHA-LP PAK for the layered products.

What no Ada?

bill

[Simon Clubley]

Post by Bill Gunshannon
What no Ada?

Given that it's probably going to be an Adacore port, I suspect
VSI/Adacore are trying to work out if Ada on VMS is still viable
from a financial viewpoint.

Simon.

[Bill Gunshannon]

Post by Simon Clubley

Post by Bill Gunshannon
What no Ada?

Given that it's probably going to be an Adacore port, I suspect
VSI/Adacore are trying to work out if Ada on VMS is still viable
from a financial viewpoint.

Finally, someone bit. Adacore? What was it someone was saying about
not using Open Source on VMS? Adacore's Ada compiler is a derivative
of the GPLed GNAT AdaCompiler from NYU. While they work very hard to
keep it out of the Open Source world it is in fact Open Source Software.

bill

[Ian Miller]

Post by Bill Gunshannon

Post by Simon Clubley

Post by Bill Gunshannon
What no Ada?

Given that it's probably going to be an Adacore port, I suspect
VSI/Adacore are trying to work out if Ada on VMS is still viable
from a financial viewpoint.

Finally, someone bit. Adacore? What was it someone was saying about
not using Open Source on VMS? Adacore's Ada compiler is a derivative
of the GPLed GNAT AdaCompiler from NYU. While they work very hard to
keep it out of the Open Source world it is in fact Open Source Software.
bill

See here http://www.vmsadaall.org/index.php/en/80-category-en-gb/72-article-en-gb for another port of GNAT Ada to OpenVMS I64

[Simon Clubley]

Post by Ian Miller
See here http://www.vmsadaall.org/index.php/en/80-category-en-gb/72-article-en-gb for another port of GNAT Ada to OpenVMS I64

The author never answered my question about whether this port is based
on the FSF gcc or the Adacore gcc.

Simon.

[Peter 'EPLAN' LANGSTOeGER]

Post by Simon Clubley

Post by Ian Miller
See here http://www.vmsadaall.org/index.php/en/80-category-en-gb/72-article-en-gb for another port of GNAT Ada to OpenVMS I64

The author never answered my question about whether this port is based
on the FSF gcc or the Adacore gcc.

There is a logo with "FSF GNAT" on the webpage. Could this be a hint?

Just curious

PS: Page has a 2017 date, but mentioned pia-sofer page has nothing newer than 2015

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

Post by Peter 'EPLAN' LANGSTOeGER

Post by Simon Clubley

Post by Ian Miller
See here http://www.vmsadaall.org/index.php/en/80-category-en-gb/72-article-en-gb for another port of GNAT Ada to OpenVMS I64

The author never answered my question about whether this port is based
on the FSF gcc or the Adacore gcc.

There is a logo with "FSF GNAT" on the webpage. Could this be a hint?
Just curious
PS: Page has a 2017 date, but mentioned pia-sofer page has nothing newer than 2015
--
Peter "EPLAN" LANGSTÖGER
Network and OpenVMS system specialist
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

Wander over to comp.lang.ada where on 2 Mar 2017 there is a
thread titled "Gnat Ada on OpenVMS is back". If you haven't
seen it before, you might find it interesting, you will
probably recognise some contributors names.

Having watched attempts to update a non-Linux-hosted gcc/gnat
from gcc 3.4.4? to 4.x not that many years ago for an obscure
target, if Linux isn't where the toolchain is built, life gets
very complicated very quickly. That applies whether the
non-Linux system is VMS or Windows. An appropriate pre-built
toolset does make life rather simpler in that respect.

Have a lot of fun.

[Simon Clubley]

Post by j***@yahoo.co.uk

Post by Peter 'EPLAN' LANGSTOeGER

Post by Simon Clubley

Post by Ian Miller
See here http://www.vmsadaall.org/index.php/en/80-category-en-gb/72-article-en-gb for another port of GNAT Ada to OpenVMS I64

The author never answered my question about whether this port is based
on the FSF gcc or the Adacore gcc.

There is a logo with "FSF GNAT" on the webpage. Could this be a hint?

Yes and No.

I've tried to build the FSF GNAT for a VMS Alpha target and didn't get
very far as it appears there are significant issues with the VMS Alpha
specific code in the FSF version of the gcc codebase.

The IA64 version looks to be in better shape as it shares (IIRC) some
backend code with other targets; however I have never tried to build
the IA64 version because I don't have a machine to run it on.

I was trying to find out if Gerard's build is based on pure FSF gcc
or if some of the Adacore gcc code had to be used to get gcc to build
for an IA64 target.

You also need an Ada compiler to build the Ada compiler. IIRC, Gerard
used GNAT Pro running on Alpha to build the IA64 compiler which probably
avoided a good number of issues. This wasn't an option available to me
so I had to take the cross-compiler running on Linux approach which
didn't work very well for me for this specific case of a VMS Alpha target.

Post by j***@yahoo.co.uk

Post by Peter 'EPLAN' LANGSTOeGER
Just curious
PS: Page has a 2017 date, but mentioned pia-sofer page has nothing newer than 2015

Wander over to comp.lang.ada where on 2 Mar 2017 there is a
thread titled "Gnat Ada on OpenVMS is back". If you haven't
seen it before, you might find it interesting, you will
probably recognise some contributors names.
Having watched attempts to update a non-Linux-hosted gcc/gnat
from gcc 3.4.4? to 4.x not that many years ago for an obscure
target, if Linux isn't where the toolchain is built, life gets
very complicated very quickly. That applies whether the
non-Linux system is VMS or Windows. An appropriate pre-built
toolset does make life rather simpler in that respect.

Tell me about it John, tell me about it. :-(

While we are sending people over to comp.lang.ada, they may find several
threads started by me (with varying degrees of politeness and frustration)
which all basically say the Ada language is a good language but the
Ada compiler situation in general is lousy.

Post by j***@yahoo.co.uk
Have a lot of fun.

Try "Have a lot of frustration. :-)" when to comes to building GNAT
for a non-mainstream target...

Simon.

[Jan-Erik Soderholm]

Post by Simon Clubley

Post by Bill Gunshannon
What no Ada?

Given that it's probably going to be an Adacore port, I suspect
VSI/Adacore are trying to work out if Ada on VMS is still viable
from a financial viewpoint.
Simon.

I would not expect that, on Alpha.

[Simon Clubley]

This post might be inappropriate. Click to display it.

[David Froble]

Post by Simon Clubley

Post by Jan-Erik Soderholm

Post by Simon Clubley

Post by Bill Gunshannon
What no Ada?

Given that it's probably going to be an Adacore port, I suspect
VSI/Adacore are trying to work out if Ada on VMS is still viable
from a financial viewpoint.
Simon.

I would not expect that, on Alpha.

I forgot about the "Alpha" bit when writing my reply (which was
directed towards Ada on x86-64 VMS). Sorry. :-)
Ada 95 on VMS Alpha exists today and is provided by Adacore. (I don't
know about the later Ada versions.)
There's also Ada 83 in the form of DEC Ada (which VSI should control)
so that is actually a valid question from Bill and I would be interested
to see VSI's response.

Again, I know nothing ....

Several times I've seen the statement about what HP transferred to VSI, and
perhaps some things they didn't. So, yeah, did VSI get the Ada 83 stuff?

[John Reagan]

Post by David Froble

Post by Simon Clubley

Post by Jan-Erik Soderholm

Post by Simon Clubley

Post by Bill Gunshannon
What no Ada?

Given that it's probably going to be an Adacore port, I suspect
VSI/Adacore are trying to work out if Ada on VMS is still viable
from a financial viewpoint.
Simon.

I would not expect that, on Alpha.

I forgot about the "Alpha" bit when writing my reply (which was
directed towards Ada on x86-64 VMS). Sorry. :-)
Ada 95 on VMS Alpha exists today and is provided by Adacore. (I don't
know about the later Ada versions.)
There's also Ada 83 in the form of DEC Ada (which VSI should control)
so that is actually a valid question from Bill and I would be interested
to see VSI's response.

Again, I know nothing ....
Several times I've seen the statement about what HP transferred to VSI, and
perhaps some things they didn't. So, yeah, did VSI get the Ada 83 stuff?

Wow. Google Groups must be broken. I thought I was subscribed to comp.os.vms, but it seems I've been dropped into alt.conspiracy.theories. I'm surprised nobody has suggested chemtrails yet.

Yes, we have the DEC Ada 83 compiler for Alpha. Why isn't it on the list? I just didn't get to it yet (I've been busy looking forward :) ). It builds a little different than the other GEM-based compilers. Ada uses an older variant of GEM due to Ada's unique exception handling requirements (later GEM's made some non-upward-compatible changes to the GEM IR to also handle C++ exception handling and the Ada frontend was not changed to follow along). I had asked to defer it since I needed to continue work on the x86 side.

[Simon Clubley]

Post by John Reagan

Post by David Froble

Post by Simon Clubley
I forgot about the "Alpha" bit when writing my reply (which was
directed towards Ada on x86-64 VMS). Sorry. :-)
Ada 95 on VMS Alpha exists today and is provided by Adacore. (I don't
know about the later Ada versions.)
There's also Ada 83 in the form of DEC Ada (which VSI should control)
so that is actually a valid question from Bill and I would be interested
to see VSI's response.

Again, I know nothing ....
Several times I've seen the statement about what HP transferred to VSI, and
perhaps some things they didn't. So, yeah, did VSI get the Ada 83 stuff?

Wow. Google Groups must be broken. I thought I was subscribed to
comp.os.vms, but it seems I've been dropped into alt.conspiracy.theories.
I'm surprised nobody has suggested chemtrails yet.

No, but you should be careful - someone might ask you to turn DEC Ada into
an Ada 95 compiler. :-)

Post by John Reagan
Yes, we have the DEC Ada 83 compiler for Alpha. Why isn't it on the
list? I just didn't get to it yet (I've been busy looking forward :) ).
It builds a little different than the other GEM-based compilers. Ada uses
an older variant of GEM due to Ada's unique exception handling requirements
(later GEM's made some non-upward-compatible changes to the GEM IR to also
handle C++ exception handling and the Ada frontend was not changed to
follow along). I had asked to defer it since I needed to continue work on
the x86 side.

I wasn't aware the Ada GEM version was different.

Thanks for the feedback John.

Simon.

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

Post by Simon Clubley

Post by John Reagan

Post by David Froble

Post by Simon Clubley
I forgot about the "Alpha" bit when writing my reply (which was
directed towards Ada on x86-64 VMS). Sorry. :-)
Ada 95 on VMS Alpha exists today and is provided by Adacore. (I don't
know about the later Ada versions.)
There's also Ada 83 in the form of DEC Ada (which VSI should control)
so that is actually a valid question from Bill and I would be interested
to see VSI's response.

Again, I know nothing ....
Several times I've seen the statement about what HP transferred to VSI, and
perhaps some things they didn't. So, yeah, did VSI get the Ada 83 stuff?

Wow. Google Groups must be broken. I thought I was subscribed to
comp.os.vms, but it seems I've been dropped into alt.conspiracy.theories.
I'm surprised nobody has suggested chemtrails yet.

No, but you should be careful - someone might ask you to turn DEC Ada into
an Ada 95 compiler. :-)

Post by John Reagan
Yes, we have the DEC Ada 83 compiler for Alpha. Why isn't it on the
list? I just didn't get to it yet (I've been busy looking forward :) ).
It builds a little different than the other GEM-based compilers. Ada uses
an older variant of GEM due to Ada's unique exception handling requirements
(later GEM's made some non-upward-compatible changes to the GEM IR to also
handle C++ exception handling and the Ada frontend was not changed to
follow along). I had asked to defer it since I needed to continue work on
the x86 side.

I wasn't aware the Ada GEM version was different.
Thanks for the feedback John.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world

Some customers already tried asking DEC to magick Ada 83 into
Ada 95 some years ago, but the relevant wizardry (and $$$)
could not be located at the time.

Another edge case in the Ada picture may be the current
commercial and technical situation of the former XD Ada
product (VMS front end, M68K target). I have no idea
what that current situation is; I do know at least one
household name company relies on it for some of its
products but for many years chose not to purchase
support (from EDS-Scicon?) because the contract then
on offer was "pay for the gap" as well as pay for a
new contract. Anyway, new owners may mean new rules.

[Arne Vajhøj]

Post by j***@yahoo.co.uk
Some customers already tried asking DEC to magick Ada 83 into
Ada 95 some years ago, but the relevant wizardry (and $$$)
could not be located at the time.

If there were no business case years ago, then I doubt there
will be a business case today. Ada usage has not increased.

Arne

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

Post by Arne Vajhøj

Post by j***@yahoo.co.uk
Some customers already tried asking DEC to magick Ada 83 into
Ada 95 some years ago, but the relevant wizardry (and $$$)
could not be located at the time.

If there were no business case years ago, then I doubt there
will be a business case today. Ada usage has not increased.
Arne

The logic of a business case is sometimes over-ridden by
the personal beliefs of the 'leaders' involved, at the
supplier or the customer or both. I know quite a few Ada
customers saw no logic whatsoever in abandoning Ada 9x on
VMS, but DEC/CPQ/HP management saw things in their own
sweet way.

Like HP buying Autonomy, for example, and the subsequent
multi-billion-dollar writeoffs. Business case for the
acquisition? Invisible.

Go back a little further and there's HP abandoning PalmOs
in favour of Microsoft's mobile strategy of the week.

Plenty more where those came from - Moonshot, TheMachine,
whatever. Arguably, picking Itanium over Alpha fits the
"faith not facts" category too, though back then it
was vaguely plausible that Intel's deep pockets would
lead to IA64 not AMD64 taking the lions share of the
market. Facts turned out not to match faith eventually.

Facts are important. Sometimes faith still wins despite
the facts.

[IanD]

Future projections are a mix of data driven decisions, speculative insight, pure guesswork and personal likes add dislikes

Success breeds success and failures can if one of not careful become self furfilling Doomsday predictions if the negative groundswell is against you

VMS has a lot of love out there but it's nostalgic love, much from people who remember nice aspects of it but perhaps never had to battle with it day by day and who are perhaps not seeing those nice aspects in light of how far forward other platforms have now come

Groundswell trumps corporate dollars in the long run. Gotta get the next block of developers and users interested in it or its going to be a flash in the pan revival

I'm hoping the stint that Clair? did at MIT grows. To start with it might not be something that will attract new grads but if sold in a way to show that there is a business out there in keeping and transforming older systems, it would go a long way towards attracting people. Maybe even a formal discipline might come out of it rather than relying on IT folks of old?

[Ian Miller]

Post by j***@yahoo.co.uk

Post by Simon Clubley

Post by John Reagan

Post by David Froble

Post by Simon Clubley
I forgot about the "Alpha" bit when writing my reply (which was
directed towards Ada on x86-64 VMS). Sorry. :-)
Ada 95 on VMS Alpha exists today and is provided by Adacore. (I don't
know about the later Ada versions.)
There's also Ada 83 in the form of DEC Ada (which VSI should control)
so that is actually a valid question from Bill and I would be interested
to see VSI's response.

Again, I know nothing ....
Several times I've seen the statement about what HP transferred to VSI, and
perhaps some things they didn't. So, yeah, did VSI get the Ada 83 stuff?

Wow. Google Groups must be broken. I thought I was subscribed to
comp.os.vms, but it seems I've been dropped into alt.conspiracy.theories.
I'm surprised nobody has suggested chemtrails yet.

No, but you should be careful - someone might ask you to turn DEC Ada into
an Ada 95 compiler. :-)

Post by John Reagan
Yes, we have the DEC Ada 83 compiler for Alpha. Why isn't it on the
list? I just didn't get to it yet (I've been busy looking forward :) ).
It builds a little different than the other GEM-based compilers. Ada uses
an older variant of GEM due to Ada's unique exception handling requirements
(later GEM's made some non-upward-compatible changes to the GEM IR to also
handle C++ exception handling and the Ada frontend was not changed to
follow along). I had asked to defer it since I needed to continue work on
the x86 side.

I wasn't aware the Ada GEM version was different.
Thanks for the feedback John.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world

Some customers already tried asking DEC to magick Ada 83 into
Ada 95 some years ago, but the relevant wizardry (and $$$)
could not be located at the time.
Another edge case in the Ada picture may be the current
commercial and technical situation of the former XD Ada
product (VMS front end, M68K target). I have no idea
what that current situation is; I do know at least one
household name company relies on it for some of its
products but for many years chose not to purchase
support (from EDS-Scicon?) because the contract then
on offer was "pay for the gap" as well as pay for a
new contract. Anyway, new owners may mean new rules.

Support for XD-ADA and related items is available from DXC Technology (which is where that team are now). It runs on OpenVMS I64 now :-)

[Jan-Erik Soderholm]

Post by Stephen Hoffman
Haven't seen it posted here yet, and it's not posted on the VSI web site...
VSI have announced the availability of a subset of the layered products for
the VSI OpenVMS Alpha V8.4-2L1 release.
ACMS, AvailMan, BASIC, C, C++. COBOL, CXML, DTR, DECdfs, DECforms, DCPS,
DECset, DFO, DCE, DQS, Enterprise Directory LDAP, FMS. Fortran, I18N, MRU,
Pascal, SSM, T4, TDMS
Licensing changes announced, too. One VSI ALPHA-SYSTEM PAK for OpenVMS,
one VSI ALPHA-LP PAK for the layered products.

Yes, I have been asking VSI for that list. The quote we got in early
January refered to some "LP list" but it was not included with the
quote. Now, I was not worried since I had supplied VSI with a
list of the used SW on our systems and got an "OK" on that.

We now (today) agreed on to go on the 3-year offer from VSI (that
includes the prods above, and the free x86 migration) for our systems.
It was actually cheaper then the offer from HP (MPS w/o SE) with
only TCPIP included.

Note also that, besides of the LPs above, other "extras" as Cluster,
HBVS, multi-process support and so on are also inluded. So, of needed,
we can replace our single CPU DS20e with dual CPU DS25s, using the
same PAKs and same cost.

One could always hope that this is a model for the licensing for
the upcomming x86-64 version, but we'll see...

I'm also taking for granted that the "VSI ALPHA-SYSTEM" PAK also
includes unlimited interactive users, so no "USER" PAKs.

As soon as the deal on the licence/support package can go through,
and the availablity/download of the media kit has been sorted out,
I might come back with some first impressions from our test system.

B.t.w, when you quote a 5-digit support contract, why add a extra
line with "Media Kit for OpenVMS" at $278 when it is stated that
it will be an online ISO download? No big deal, but...

Jan-Erik.

[Robert A. Brooks]

Post by Jan-Erik Soderholm
I'm also taking for granted that the "VSI ALPHA-SYSTEM" PAK also
includes unlimited interactive users, so no "USER" PAKs.

Yes, it does.

Post by Jan-Erik Soderholm
B.t.w, when you quote a 5-digit support contract, why add a extra
line with "Media Kit for OpenVMS" at $278 when it is stated that
it will be an online ISO download? No big deal, but...

I'll pass that comment along.

[Jan-Erik Soderholm]

Post by Robert A. Brooks

Post by Jan-Erik Soderholm
I'm also taking for granted that the "VSI ALPHA-SYSTEM" PAK also
includes unlimited interactive users, so no "USER" PAKs.

Yes, it does.

Post by Jan-Erik Soderholm
B.t.w, when you quote a 5-digit support contract, why add a extra
line with "Media Kit for OpenVMS" at $278 when it is stated that
it will be an online ISO download? No big deal, but...

I'll pass that comment along.

Thanks... :-)

It did raise some eyebrows. "Wasn't that an *online* download?" :-)

[Simon Clubley]

Post by Jan-Erik Soderholm
It did raise some eyebrows. "Wasn't that an *online* download?" :-)

Are the downloadable .ISOs themselves signed (or do they at least
have a suitably robust checksum/hash available) ?

Simon.

[Jan-Erik Soderholm]

Post by Simon Clubley

Post by Jan-Erik Soderholm
It did raise some eyebrows. "Wasn't that an *online* download?" :-)

Are the downloadable .ISOs themselves signed (or do they at least
have a suitably robust checksum/hash available) ?
Simon.

Either ask VSI (if they know today) or wait.

[David Froble]

Post by Jan-Erik Soderholm

Post by Robert A. Brooks

Post by Jan-Erik Soderholm
I'm also taking for granted that the "VSI ALPHA-SYSTEM" PAK also
includes unlimited interactive users, so no "USER" PAKs.

Yes, it does.

Post by Jan-Erik Soderholm
B.t.w, when you quote a 5-digit support contract, why add a extra
line with "Media Kit for OpenVMS" at $278 when it is stated that
it will be an online ISO download? No big deal, but...

I'll pass that comment along.

Thanks... :-)
It did raise some eyebrows. "Wasn't that an *online* download?" :-)

Some old DEC thinking there. I'd think VSI will ask, "how did that get in there?"

5 digit support contract sounds good. Enough of those, and VSI should have a
future.

[c***@gmail.com]

Post by David Froble

Post by Jan-Erik Soderholm

Post by Robert A. Brooks

Post by Jan-Erik Soderholm
I'm also taking for granted that the "VSI ALPHA-SYSTEM" PAK also
includes unlimited interactive users, so no "USER" PAKs.

Yes, it does.

Post by Jan-Erik Soderholm
B.t.w, when you quote a 5-digit support contract, why add a extra
line with "Media Kit for OpenVMS" at $278 when it is stated that
it will be an online ISO download? No big deal, but...

I'll pass that comment along.

Thanks... :-)
It did raise some eyebrows. "Wasn't that an *online* download?" :-)

Some old DEC thinking there. I'd think VSI will ask, "how did that get in there?"
5 digit support contract sounds good. Enough of those, and VSI should have a
future.

It was pointed out multiple times by reviewers that the line should be removed but it clearly didn't happen. We apologize for it being in there.

[Jan-Erik Soderholm]

Post by Jan-Erik Soderholm

Post by Stephen Hoffman
Haven't seen it posted here yet, and it's not posted on the VSI web site...
VSI have announced the availability of a subset of the layered products for
the VSI OpenVMS Alpha V8.4-2L1 release.
ACMS, AvailMan, BASIC, C, C++. COBOL, CXML, DTR, DECdfs, DECforms, DCPS,
DECset, DFO, DCE, DQS, Enterprise Directory LDAP, FMS. Fortran, I18N, MRU,
Pascal, SSM, T4, TDMS
Licensing changes announced, too. One VSI ALPHA-SYSTEM PAK for OpenVMS,
one VSI ALPHA-LP PAK for the layered products.

Yes, I have been asking VSI for that list. The quote we got in early
January refered to some "LP list" but it was not included with the
quote. Now, I was not worried since I had supplied VSI with a
list of the used SW on our systems and got an "OK" on that.
We now (today) agreed on to go on the 3-year offer from VSI...

And last week, finaly, the order was sent to VSI and I have received
the 6 PAKs, one "ALPHA-SYSTEM" and one "ALPHA-LP" for each of the
three systems). Now waiting for the details around the ISO downloads
and planning to have at least our test system upgraded during the
summer holiday. The customer is closed down for the next 4 weeks.

The delay from April until now is totaly due to internal issues at
our side, it has nothing to do with VSI.

In the PAK document (sent as PDFs), apart from the traditional table
with PAK details, there is also a "LICENSE REGISTER" command.

Jan-Erik.





(that

Post by Jan-Erik Soderholm
includes the prods above, and the free x86 migration) for our systems.
It was actually cheaper then the offer from HP (MPS w/o SE) with
only TCPIP included.
Note also that, besides of the LPs above, other "extras" as Cluster,
HBVS, multi-process support and so on are also inluded. So, of needed,
we can replace our single CPU DS20e with dual CPU DS25s, using the
same PAKs and same cost.
One could always hope that this is a model for the licensing for
the upcomming x86-64 version, but we'll see...
I'm also taking for granted that the "VSI ALPHA-SYSTEM" PAK also
includes unlimited interactive users, so no "USER" PAKs.
As soon as the deal on the licence/support package can go through,
and the availablity/download of the media kit has been sorted out,
I might come back with some first impressions from our test system.
B.t.w, when you quote a 5-digit support contract, why add a extra
line with "Media Kit for OpenVMS" at $278 when it is stated that
it will be an online ISO download? No big deal, but...
Jan-Erik.

[Jan-Erik Soderholm]

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm

Post by Stephen Hoffman
Haven't seen it posted here yet, and it's not posted on the VSI web site...
VSI have announced the availability of a subset of the layered products for
the VSI OpenVMS Alpha V8.4-2L1 release.
ACMS, AvailMan, BASIC, C, C++. COBOL, CXML, DTR, DECdfs, DECforms, DCPS,
DECset, DFO, DCE, DQS, Enterprise Directory LDAP, FMS. Fortran, I18N, MRU,
Pascal, SSM, T4, TDMS
Licensing changes announced, too. One VSI ALPHA-SYSTEM PAK for OpenVMS,
one VSI ALPHA-LP PAK for the layered products.

Yes, I have been asking VSI for that list. The quote we got in early
January refered to some "LP list" but it was not included with the
quote. Now, I was not worried since I had supplied VSI with a
list of the used SW on our systems and got an "OK" on that.
We now (today) agreed on to go on the 3-year offer from VSI...

And last week, finaly, the order was sent to VSI and I have received
the 6 PAKs, one "ALPHA-SYSTEM" and one "ALPHA-LP" for each of the
three systems). Now waiting for the details around the ISO downloads
and planning to have at least our test system upgraded during the
summer holiday. The customer is closed down for the next 4 weeks.
The delay from April until now is totaly due to internal issues at
our side, it has nothing to do with VSI.
In the PAK document (sent as PDFs), apart from the traditional table
with PAK details, there is also a "LICENSE REGISTER" command.
Jan-Erik.
(that

Post by Jan-Erik Soderholm
includes the prods above, and the free x86 migration) for our systems.
It was actually cheaper then the offer from HP (MPS w/o SE) with
only TCPIP included.
Note also that, besides of the LPs above, other "extras" as Cluster,
HBVS, multi-process support and so on are also inluded. So, of needed,
we can replace our single CPU DS20e with dual CPU DS25s, using the
same PAKs and same cost.
One could always hope that this is a model for the licensing for
the upcomming x86-64 version, but we'll see...
I'm also taking for granted that the "VSI ALPHA-SYSTEM" PAK also
includes unlimited interactive users, so no "USER" PAKs.
As soon as the deal on the licence/support package can go through,
and the availablity/download of the media kit has been sorted out,
I might come back with some first impressions from our test system.
B.t.w, when you quote a 5-digit support contract, why add a extra
line with "Media Kit for OpenVMS" at $278 when it is stated that
it will be an online ISO download? No big deal, but...
Jan-Erik.

ISO files downloaded to our VMS test system. One for the OS and two
for the LP1 and LP2 kits. Looks OK. Can be mounted with LD. The OS
ISO will be copied to a SAN disk so that it can be booted. Next task...

The download was through a sftp link, b.t.w. Worked just OK.

[Jan-Erik Soderholm]

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm

Post by Stephen Hoffman
Haven't seen it posted here yet, and it's not posted on the VSI web site...
VSI have announced the availability of a subset of the layered products for
the VSI OpenVMS Alpha V8.4-2L1 release.
ACMS, AvailMan, BASIC, C, C++. COBOL, CXML, DTR, DECdfs, DECforms, DCPS,
DECset, DFO, DCE, DQS, Enterprise Directory LDAP, FMS. Fortran, I18N, MRU,
Pascal, SSM, T4, TDMS
Licensing changes announced, too. One VSI ALPHA-SYSTEM PAK for OpenVMS,
one VSI ALPHA-LP PAK for the layered products.

Yes, I have been asking VSI for that list. The quote we got in early
January refered to some "LP list" but it was not included with the
quote. Now, I was not worried since I had supplied VSI with a
list of the used SW on our systems and got an "OK" on that.
We now (today) agreed on to go on the 3-year offer from VSI...

And last week, finaly, the order was sent to VSI and I have received
the 6 PAKs, one "ALPHA-SYSTEM" and one "ALPHA-LP" for each of the
three systems). Now waiting for the details around the ISO downloads
and planning to have at least our test system upgraded during the
summer holiday. The customer is closed down for the next 4 weeks.
The delay from April until now is totaly due to internal issues at
our side, it has nothing to do with VSI.
In the PAK document (sent as PDFs), apart from the traditional table
with PAK details, there is also a "LICENSE REGISTER" command.
Jan-Erik.
(that

Post by Jan-Erik Soderholm
includes the prods above, and the free x86 migration) for our systems.
It was actually cheaper then the offer from HP (MPS w/o SE) with
only TCPIP included.
Note also that, besides of the LPs above, other "extras" as Cluster,
HBVS, multi-process support and so on are also inluded. So, of needed,
we can replace our single CPU DS20e with dual CPU DS25s, using the
same PAKs and same cost.
One could always hope that this is a model for the licensing for
the upcomming x86-64 version, but we'll see...
I'm also taking for granted that the "VSI ALPHA-SYSTEM" PAK also
includes unlimited interactive users, so no "USER" PAKs.
As soon as the deal on the licence/support package can go through,
and the availablity/download of the media kit has been sorted out,
I might come back with some first impressions from our test system.
B.t.w, when you quote a 5-digit support contract, why add a extra
line with "Media Kit for OpenVMS" at $278 when it is stated that
it will be an online ISO download? No big deal, but...
Jan-Erik.

ISO files downloaded to our VMS test system. One for the OS and two
for the LP1 and LP2 kits. Looks OK. Can be mounted with LD. The OS
ISO will be copied to a SAN disk so that it can be booted. Next task...
The download was through a sftp link, b.t.w. Worked just OK.

Note (and as the subject of this thread says) that all year it has
been talks about a 8.4-2L1 Alpha version. More or less a recompile
of the current 8.4-2L1 for Itanium. I noticed now that what was
downloaded earlier today was ALpha 8.4-2L2. The cover letter (dated
June-2017) says:

-----------------------------------------------------------------
"VMS Software, Inc. (VSI) is pleased to introduce the VSI OpenVMS
Alpha Performance Release Version 8.4-2L2 operating system (hereafter
referred to as VSI OpenVMS Alpha Version 8.4-2L2) and associated
layered products. VSI OpenVMS Alpha V8.4-2L2 (a modified release of
VSI OpenVMS Alpha V8.4-2L1) has been optimized to take advantage of
architectural features such as byte and word memory reference instructions,
and floating-point improvements, which are available only in AlphaServer
EV6 or later processors. This optimized release improves performance by
taking advantage of faster hardware-based instructions that were previously
emulated in software. NOTE: VSI OpenVMS Alpha V8.4-2L2 will not work on,
and is not supported on, AlphaServer pre-EV6 systems."
-----------------------------------------------------------------

Our boxes uses EV67, so that is fine for us.

-----------------------------------------------------------------
The "8.4-2L2 New Feat and Rel Notes", in section "3.1.4 Considerations When
Building Software to Run on VSI OpenVMS Alpha Versions", also says:

"VSI has created two versions of the VSI OpenVMS Alpha operating system.

• VSI OpenVMS Alpha V8.4-2L1. This is a general purpose VSI OpenVMS Alpha
release that runs on all supported HPE AlphaServer platforms regardless
of chip architecture.

• VSI OpenVMS Alpha V8.4-2L2. This is a rebuild of the VSI OpenVMS Alpha
operating system with compilers that produce specially tuned instructions
to take advantage of later features in the Alpha architecture. These can
provide a performance benefit for some workloads. This release will only
run on, and is only supported on, EV6 and later HPE AlphaServer systems.

If you build software to run on VSI releases of OpenVMS for Alpha systems,
you should carefully choose which version of VSI OpenVMS Alpha to use when
building your product:

• If you intend to use the product on any VSI OpenVMS Alpha release and
all supported target platforms, VSI strongly recommends that you build the
software on VSI OpenVMS V8.4-2L1. This will ensure that any precompiled
system code that is included within the images will run on all systems,
regardless of chip architecture level.

• If you are building tuned code already and only support EV6 or later
processors, you may build on either version of the operating system with
no issues."
-----------------------------------------------------------------


Still fine for us, but can be useful information for someone else looking
at the Alpha offer from VSI...

Regards.

One question... Are those "compilers that produce specially tuned
instructions" the same as compiling with the /ARCH=EV6 switch? Or has
VSI made special versions of the compilers to build VMS itself? Not that
it matters much or that I need (or expect) an answer, but anyway... :-)

And a second question... How large parts of VMS has been recompiled
in this way and is that a reason to run more tests then otherwise?

[[e-mail]]

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm

Post by Stephen Hoffman
Haven't seen it posted here yet, and it's not posted on the VSI web site...
VSI have announced the availability of a subset of the layered products for
the VSI OpenVMS Alpha V8.4-2L1 release.
ACMS, AvailMan, BASIC, C, C++. COBOL, CXML, DTR, DECdfs, DECforms, DCPS,
DECset, DFO, DCE, DQS, Enterprise Directory LDAP, FMS. Fortran, I18N, MRU,
Pascal, SSM, T4, TDMS
Licensing changes announced, too. One VSI ALPHA-SYSTEM PAK for OpenVMS,
one VSI ALPHA-LP PAK for the layered products.

Yes, I have been asking VSI for that list. The quote we got in early
January refered to some "LP list" but it was not included with the
quote. Now, I was not worried since I had supplied VSI with a
list of the used SW on our systems and got an "OK" on that.
We now (today) agreed on to go on the 3-year offer from VSI...

And last week, finaly, the order was sent to VSI and I have received
the 6 PAKs, one "ALPHA-SYSTEM" and one "ALPHA-LP" for each of the
three systems). Now waiting for the details around the ISO downloads
and planning to have at least our test system upgraded during the
summer holiday. The customer is closed down for the next 4 weeks.
The delay from April until now is totaly due to internal issues at
our side, it has nothing to do with VSI.
In the PAK document (sent as PDFs), apart from the traditional table
with PAK details, there is also a "LICENSE REGISTER" command.
Jan-Erik.
(that

Post by Jan-Erik Soderholm
includes the prods above, and the free x86 migration) for our systems.
It was actually cheaper then the offer from HP (MPS w/o SE) with
only TCPIP included.
Note also that, besides of the LPs above, other "extras" as Cluster,
HBVS, multi-process support and so on are also inluded. So, of needed,
we can replace our single CPU DS20e with dual CPU DS25s, using the
same PAKs and same cost.
One could always hope that this is a model for the licensing for
the upcomming x86-64 version, but we'll see...
I'm also taking for granted that the "VSI ALPHA-SYSTEM" PAK also
includes unlimited interactive users, so no "USER" PAKs.
As soon as the deal on the licence/support package can go through,
and the availablity/download of the media kit has been sorted out,
I might come back with some first impressions from our test system.
B.t.w, when you quote a 5-digit support contract, why add a extra
line with "Media Kit for OpenVMS" at $278 when it is stated that
it will be an online ISO download? No big deal, but...
Jan-Erik.

ISO files downloaded to our VMS test system. One for the OS and two
for the LP1 and LP2 kits. Looks OK. Can be mounted with LD. The OS
ISO will be copied to a SAN disk so that it can be booted. Next task...
The download was through a sftp link, b.t.w. Worked just OK.

Note (and as the subject of this thread says) that all year it has
been talks about a 8.4-2L1 Alpha version. More or less a recompile
of the current 8.4-2L1 for Itanium. I noticed now that what was
downloaded earlier today was ALpha 8.4-2L2. The cover letter (dated
-----------------------------------------------------------------
"VMS Software, Inc. (VSI) is pleased to introduce the VSI OpenVMS
Alpha Performance Release Version 8.4-2L2 operating system (hereafter
referred to as VSI OpenVMS Alpha Version 8.4-2L2) and associated
layered products. VSI OpenVMS Alpha V8.4-2L2 (a modified release of
VSI OpenVMS Alpha V8.4-2L1) has been optimized to take advantage of
architectural features such as byte and word memory reference instructions,
and floating-point improvements, which are available only in AlphaServer
EV6 or later processors. This optimized release improves performance by
taking advantage of faster hardware-based instructions that were previously
emulated in software. NOTE: VSI OpenVMS Alpha V8.4-2L2 will not work on,
and is not supported on, AlphaServer pre-EV6 systems."
-----------------------------------------------------------------
Our boxes uses EV67, so that is fine for us.
-----------------------------------------------------------------
The "8.4-2L2 New Feat and Rel Notes", in section "3.1.4 Considerations When
"VSI has created two versions of the VSI OpenVMS Alpha operating system.
• VSI OpenVMS Alpha V8.4-2L1. This is a general purpose VSI OpenVMS Alpha
release that runs on all supported HPE AlphaServer platforms regardless
of chip architecture.
• VSI OpenVMS Alpha V8.4-2L2. This is a rebuild of the VSI OpenVMS Alpha
operating system with compilers that produce specially tuned instructions
to take advantage of later features in the Alpha architecture. These can
provide a performance benefit for some workloads. This release will only
run on, and is only supported on, EV6 and later HPE AlphaServer systems.
If you build software to run on VSI releases of OpenVMS for Alpha systems,
you should carefully choose which version of VSI OpenVMS Alpha to use when
• If you intend to use the product on any VSI OpenVMS Alpha release and
all supported target platforms, VSI strongly recommends that you build the
software on VSI OpenVMS V8.4-2L1. This will ensure that any precompiled
system code that is included within the images will run on all systems,
regardless of chip architecture level.
• If you are building tuned code already and only support EV6 or later
processors, you may build on either version of the operating system with
no issues."
-----------------------------------------------------------------
Still fine for us, but can be useful information for someone else looking
at the Alpha offer from VSI...
Regards.
One question... Are those "compilers that produce specially tuned
instructions" the same as compiling with the /ARCH=EV6 switch? Or has
VSI made special versions of the compilers to build VMS itself? Not that
it matters much or that I need (or expect) an answer, but anyway... :-)
And a second question... How large parts of VMS has been recompiled
in this way and is that a reason to run more tests then otherwise?

We did not create special versions of the compilers. We just did a build with C, MACRO, and BLISS using the architecture-specific switches. This was for the entire operating system build, not just selected pieces.

[Jan-Erik Soderholm]

Post by ***@vmssoftware.com

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm

Post by Stephen Hoffman
Haven't seen it posted here yet, and it's not posted on the VSI web site...
VSI have announced the availability of a subset of the layered
products for the VSI OpenVMS Alpha V8.4-2L1 release.
ACMS, AvailMan, BASIC, C, C++. COBOL, CXML, DTR, DECdfs,
DECforms, DCPS, DECset, DFO, DCE, DQS, Enterprise Directory
LDAP, FMS. Fortran, I18N, MRU, Pascal, SSM, T4, TDMS
Licensing changes announced, too. One VSI ALPHA-SYSTEM PAK
for OpenVMS, one VSI ALPHA-LP PAK for the layered products.

Yes, I have been asking VSI for that list. The quote we got in
early January refered to some "LP list" but it was not included
with the quote. Now, I was not worried since I had supplied VSI
with a list of the used SW on our systems and got an "OK" on
that.
We now (today) agreed on to go on the 3-year offer from VSI...

And last week, finaly, the order was sent to VSI and I have
received the 6 PAKs, one "ALPHA-SYSTEM" and one "ALPHA-LP" for
each of the three systems). Now waiting for the details around the
ISO downloads and planning to have at least our test system
upgraded during the summer holiday. The customer is closed down
for the next 4 weeks.
The delay from April until now is totaly due to internal issues
at our side, it has nothing to do with VSI.
In the PAK document (sent as PDFs), apart from the traditional
table with PAK details, there is also a "LICENSE REGISTER"
command.
Jan-Erik.
(that

Post by Jan-Erik Soderholm
includes the prods above, and the free x86 migration) for our
systems. It was actually cheaper then the offer from HP (MPS w/o
SE) with only TCPIP included.
Note also that, besides of the LPs above, other "extras" as
Cluster, HBVS, multi-process support and so on are also inluded.
So, of needed, we can replace our single CPU DS20e with dual CPU
DS25s, using the same PAKs and same cost.
One could always hope that this is a model for the licensing
for the upcomming x86-64 version, but we'll see...
I'm also taking for granted that the "VSI ALPHA-SYSTEM" PAK
also includes unlimited interactive users, so no "USER" PAKs.
As soon as the deal on the licence/support package can go
through, and the availablity/download of the media kit has been
sorted out, I might come back with some first impressions from
our test system.
B.t.w, when you quote a 5-digit support contract, why add a
extra line with "Media Kit for OpenVMS" at $278 when it is
stated that it will be an online ISO download? No big deal,
but...
Jan-Erik.

ISO files downloaded to our VMS test system. One for the OS and two
for the LP1 and LP2 kits. Looks OK. Can be mounted with LD. The OS
ISO will be copied to a SAN disk so that it can be booted. Next task...
The download was through a sftp link, b.t.w. Worked just OK.

Note (and as the subject of this thread says) that all year it has
been talks about a 8.4-2L1 Alpha version. More or less a recompile of
the current 8.4-2L1 for Itanium. I noticed now that what was
downloaded earlier today was ALpha 8.4-2L2. The cover letter (dated
----------------------------------------------------------------- "VMS
Software, Inc. (VSI) is pleased to introduce the VSI OpenVMS Alpha
Performance Release Version 8.4-2L2 operating system (hereafter
referred to as VSI OpenVMS Alpha Version 8.4-2L2) and associated
layered products. VSI OpenVMS Alpha V8.4-2L2 (a modified release of
VSI OpenVMS Alpha V8.4-2L1) has been optimized to take advantage of
architectural features such as byte and word memory reference
instructions, and floating-point improvements, which are available
only in AlphaServer EV6 or later processors. This optimized release
improves performance by taking advantage of faster hardware-based
instructions that were previously emulated in software. NOTE: VSI
OpenVMS Alpha V8.4-2L2 will not work on, and is not supported on,
AlphaServer pre-EV6 systems."
-----------------------------------------------------------------
Our boxes uses EV67, so that is fine for us.
----------------------------------------------------------------- The
"8.4-2L2 New Feat and Rel Notes", in section "3.1.4 Considerations
When Building Software to Run on VSI OpenVMS Alpha Versions", also
"VSI has created two versions of the VSI OpenVMS Alpha operating system.
• VSI OpenVMS Alpha V8.4-2L1. This is a general purpose VSI OpenVMS
Alpha release that runs on all supported HPE AlphaServer platforms
regardless of chip architecture.
• VSI OpenVMS Alpha V8.4-2L2. This is a rebuild of the VSI OpenVMS
Alpha operating system with compilers that produce specially tuned
instructions to take advantage of later features in the Alpha
architecture. These can provide a performance benefit for some
workloads. This release will only run on, and is only supported on,
EV6 and later HPE AlphaServer systems.
If you build software to run on VSI releases of OpenVMS for Alpha
systems, you should carefully choose which version of VSI OpenVMS
• If you intend to use the product on any VSI OpenVMS Alpha release
and all supported target platforms, VSI strongly recommends that you
build the software on VSI OpenVMS V8.4-2L1. This will ensure that any
precompiled system code that is included within the images will run on
all systems, regardless of chip architecture level.
• If you are building tuned code already and only support EV6 or
later processors, you may build on either version of the operating
system with no issues."
-----------------------------------------------------------------
Still fine for us, but can be useful information for someone else
looking at the Alpha offer from VSI...
Regards.
One question... Are those "compilers that produce specially tuned
instructions" the same as compiling with the /ARCH=EV6 switch? Or has
VSI made special versions of the compilers to build VMS itself? Not
that it matters much or that I need (or expect) an answer, but
anyway... :-)
And a second question... How large parts of VMS has been recompiled in
this way and is that a reason to run more tests then otherwise?

We did not create special versions of the compilers. We just did a build
with C, MACRO, and BLISS using the architecture-specific switches. This
was for the entire operating system build, not just selected pieces.

OK, seems reasonable. I'll plan away and we'll see... :-)

Was any particular part where one saw any difference?

I also noticed that 8.2 was excluded from direct upgrade, so
we need two steps for two of our systems, currently at 8.2.
I'm sure there are good reasons behind that, no problem...

[j***@gmail.com]

Post by ***@vmssoftware.com
We did not create special versions of the compilers. We just did a
build with C, MACRO, and BLISS using the architecture-specific switches.
This was for the entire operating system build, not just selected pieces.

Does a similar opportunity exist with the Itanium build of VMS?

[Jan-Erik Soderholm]

Post by j***@gmail.com

Post by ***@vmssoftware.com
We did not create special versions of the compilers. We just did a
build with C, MACRO, and BLISS using the architecture-specific switches.
This was for the entire operating system build, not just selected pieces.

Does a similar opportunity exist with the Itanium build of VMS?

Has Itanium added performance features in the later versions? That is,
throught new instructions or other means that the compiler can use?

Oracle Rdb has for long been shipped in two versions, one "pre-EV56"
and one "EV56 and later". From the Rdb 7.3 release (in March 2011)
the "pre-EV56" kit was dropped altogether.

As I understand, the byte and word instructions come with the EV56
release, so in that regard, EV56 and EV6 would be similar (?).

[John Reagan]

Post by Jan-Erik Soderholm

Post by j***@gmail.com

Post by ***@vmssoftware.com
We did not create special versions of the compilers. We just did a
build with C, MACRO, and BLISS using the architecture-specific switches.
This was for the entire operating system build, not just selected pieces.

Does a similar opportunity exist with the Itanium build of VMS?

Has Itanium added performance features in the later versions? That is,
throught new instructions or other means that the compiler can use?
Oracle Rdb has for long been shipped in two versions, one "pre-EV56"
and one "EV56 and later". From the Rdb 7.3 release (in March 2011)
the "pre-EV56" kit was dropped altogether.
As I understand, the byte and word instructions come with the EV56
release, so in that regard, EV56 and EV6 would be similar (?).

EV6 added ITOF and FTOI instructions to move values between the floating and integer registers without having to store/fetch from memory.

EV6 also was the first out-of-order machine so a side-benefit was in the area of floating trap shadows. Pre-EV6 machines required the compiler to follow specific rules for instructions that follow any floating instruction that might fault. The rules allowed the OS's handler to back-up in the instruction stream. With EV6, the hardware can "backup" so the faulting PC reported to the OS is the actual PC of the faulting floating instruction. This allows GEM to perform better instruction scheduling with EV6 and beyond since it no longer has to worry about those older rules.

[John Reagan]

This post might be inappropriate. Click to display it.

[David Froble]

Post by j***@gmail.com

Post by ***@vmssoftware.com
We did not create special versions of the compilers. We just did a
build with C, MACRO, and BLISS using the architecture-specific switches.
This was for the entire operating system build, not just selected pieces.

Does a similar opportunity exist with the Itanium build of VMS?

Why? You got an EV6 itanic?

:-)

[Jan-Erik Soderholm]

Post by Jan-Erik Soderholm
Note (and as the subject of this thread says) that all year it has
been talks about a 8.4-2L1 Alpha version. More or less a recompile
of the current 8.4-2L1 for Itanium. I noticed now that what was
downloaded earlier today was ALpha 8.4-2L2. The cover letter (dated

Now 2L2 is also official on the VSI site:

http://www.vmssoftware.com/index.html

http://www.prweb.com/releases/2017/07/prweb14487932.htm

"Depending on the specific CPU and operating system features a customer’s
application uses, the new Alpha V8.4-2L2 release could render performance
improvements of between 15% and 50%. [...]", said Eddie Orcutt

[[e-mail]]

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm
Note (and as the subject of this thread says) that all year it has
been talks about a 8.4-2L1 Alpha version. More or less a recompile
of the current 8.4-2L1 for Itanium. I noticed now that what was
downloaded earlier today was ALpha 8.4-2L2. The cover letter (dated

http://www.vmssoftware.com/index.html
http://www.prweb.com/releases/2017/07/prweb14487932.htm
"Depending on the specific CPU and operating system features a customer’s
application uses, the new Alpha V8.4-2L2 release could render performance
improvements of between 15% and 50%. [...]", said Eddie Orcutt

Those are real numbers from some tests we ran. Here is my simplistic way to look at it. Every execlet is 5%-10% smaller and RMS is 15% smaller, compared to unoptimized (the standard build). That means many, many code paths in the heart of the operating system are shorter with the use of byte/word instructions. You can certainly make a more precise analysis but that was from my quick look at comparing the result disks from the 2L1 and 2L2 builds, picked a bunch of routines and looked at the generated code.

[John Reagan]

Post by ***@vmssoftware.com

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm
Note (and as the subject of this thread says) that all year it has
been talks about a 8.4-2L1 Alpha version. More or less a recompile
of the current 8.4-2L1 for Itanium. I noticed now that what was
downloaded earlier today was ALpha 8.4-2L2. The cover letter (dated

http://www.vmssoftware.com/index.html
http://www.prweb.com/releases/2017/07/prweb14487932.htm
"Depending on the specific CPU and operating system features a customer’s
application uses, the new Alpha V8.4-2L2 release could render performance
improvements of between 15% and 50%. [...]", said Eddie Orcutt

Those are real numbers from some tests we ran. Here is my simplistic way to look at it. Every execlet is 5%-10% smaller and RMS is 15% smaller, compared to unoptimized (the standard build). That means many, many code paths in the heart of the operating system are shorter with the use of byte/word instructions. You can certainly make a more precise analysis but that was from my quick look at comparing the result disks from the 2L1 and 2L2 builds, picked a bunch of routines and looked at the generated code.

Not to nitpick, but to avoid confusion. The standard build is NOT unoptimized. The build uses the default of /OPT=LEVEL=4 for all compiles. However, the default /ARCH value is EV4 (which also sets the default for /OPT=TUNE). We added /ARCH=EV6 to the compilations. We did not add/remove/change any /OPT qualifiers.

[Jan-Erik Soderholm]

Post by John Reagan

Post by ***@vmssoftware.com

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm
Note (and as the subject of this thread says) that all year it
has been talks about a 8.4-2L1 Alpha version. More or less a
recompile of the current 8.4-2L1 for Itanium. I noticed now that
what was downloaded earlier today was ALpha 8.4-2L2. The cover

http://www.vmssoftware.com/index.html
http://www.prweb.com/releases/2017/07/prweb14487932.htm
"Depending on the specific CPU and operating system features a
customer’s application uses, the new Alpha V8.4-2L2 release could
render performance improvements of between 15% and 50%. [...]", said
Eddie Orcutt

Those are real numbers from some tests we ran. Here is my simplistic
way to look at it. Every execlet is 5%-10% smaller and RMS is 15%
smaller, compared to unoptimized (the standard build). That means
many, many code paths in the heart of the operating system are shorter
with the use of byte/word instructions. You can certainly make a more
precise analysis but that was from my quick look at comparing the
result disks from the 2L1 and 2L2 builds, picked a bunch of routines
and looked at the generated code.

Not to nitpick, but to avoid confusion. The standard build is NOT
unoptimized. The build uses the default of /OPT=LEVEL=4 for all
compiles. However, the default /ARCH value is EV4 (which also sets the
default for /OPT=TUNE). We added /ARCH=EV6 to the compilations. We did
not add/remove/change any /OPT qualifiers.

I guess that /ARCH=67 would not have made any major difference... :-)

Thanks fr the details. Sometimes one here about weird things happening
when the /OPT level is changed like things working OK when running
with /NOOPT (to be able to debug) but not OK when run with /OPT.
So it seems good that that part wasn't changed.

I will certenly run some simple test to see if I can notice
some difference after the 2L2 upgrade.

And, it does sound as a nice gain from that simple change.

Even if Alpha is not *that* forward looking I'm pleased to
see that VSI cares for the Alpha customers.

Now back to preparing for the upgrade...

[Stephen Hoffman]

Post by John Reagan

Post by ***@vmssoftware.com
Those

{..."performance improvements of between 15% and 50%"...}

Post by John Reagan

Post by ***@vmssoftware.com
are real numbers from some tests we ran. Here is my simplistic way to
look at it. Every execlet is 5%-10% smaller and RMS is 15% smaller,
compared to unoptimized (the standard build). That means many, many
code paths in the heart of the operating system are shorter with the
use of byte/word instructions. You can certainly make a more precise
analysis but that was from my quick look at comparing the result disks
from the 2L1 and 2L2 builds, picked a bunch of routines and looked at
the generated code.

Not to nitpick, but to avoid confusion. The standard build is NOT
unoptimized. The build uses the default of /OPT=LEVEL=4 for all
compiles. However, the default /ARCH value is EV4 (which also sets the
default for /OPT=TUNE). We added /ARCH=EV6 to the compilations. We
did not add/remove/change any /OPT qualifiers.

This approach interspersed duplicated architecture-specific instruction
streams throughout the objects and executables, and the compilers added
conditional gates to select the appropriate code. In broad terms, with
some code for execution on EV5 and prior, and separate code for EV56
and later. This approach is conceptually quite simple for the
end-users, and certainly more than a little effort involved in the
compiler code scheduling and optimizations, but clearly an approach
with more than a little run-time overhead involved. In addition to
what Clair and John have mentioned above, this also means that the
processor instruction caches are less efficiently populated, and less
efficiently used with the branches necessary for interspersed-code
design.

One alternative to this approach that's been discussed occasionally
uses so-called fat binaries, where the executable code for the
different architectures had different binaries within the same file
package, and there was one selection when the code was activated.
(This approach was used on another platform to select code optimized
for different targets, and for 32- and 64-bit addressing.) This
approach makes for more complex packaging, uses additional storage,
means the compilers and the linker can need multiple passes to build
the selected architecture-specific code, and adds some selection logic
into the image activator. This approach also means there's no
run-time overhead past the image activator selecting the appropriate
binary to activate, and the unnecessary variants can be potentially
even be expunged to save on the storage.

There's no right way to do this, of course. The trade-offs and the
quest for sufficient degree of upward-compatibility are often
themselves sources of trouble, complexity and overhead. Trade-offs
between application development efforts and expenses and complexity,
and of end-user performance or complexity or suchlike, too. It's never
simple.

[John Reagan]

Post by Stephen Hoffman

Post by John Reagan

Post by ***@vmssoftware.com
Those

{..."performance improvements of between 15% and 50%"...}

Post by John Reagan

Post by ***@vmssoftware.com
are real numbers from some tests we ran. Here is my simplistic way to
look at it. Every execlet is 5%-10% smaller and RMS is 15% smaller,
compared to unoptimized (the standard build). That means many, many
code paths in the heart of the operating system are shorter with the
use of byte/word instructions. You can certainly make a more precise
analysis but that was from my quick look at comparing the result disks
from the 2L1 and 2L2 builds, picked a bunch of routines and looked at
the generated code.

Not to nitpick, but to avoid confusion. The standard build is NOT
unoptimized. The build uses the default of /OPT=LEVEL=4 for all
compiles. However, the default /ARCH value is EV4 (which also sets the
default for /OPT=TUNE). We added /ARCH=EV6 to the compilations. We
did not add/remove/change any /OPT qualifiers.

This approach interspersed duplicated architecture-specific instruction
streams throughout the objects and executables, and the compilers added
conditional gates to select the appropriate code.

Uh, that isn't what you get. /ARCH=EV6 gets pure EV6 only code.

int ext_int;
short ext_word;
char ext_char;

int main() {
int i;

i = ext_int;
i = ext_word;
i = ext_char;
}

A63D0018 00CC LDQ R17, 24(FP) ; 000008
A0310000 00D0 LDL i, EXT_INT ; R1, (R17)
A65D0020 00D4 LDQ R18, 32(FP) ; 000009
30320000 00D8 LDWU i, EXT_WORD ; R1, (R18)
73E10021 00DC SEXTW i, i ; R1, R1
A41D0028 00E0 LDQ R0, 40(FP) ; 000010
28200000 00E4 LDBU i, EXT_CHAR ; R1, (R0)
73E10001 00E8 SEXTB i, i ; R1, R1

[Stephen Hoffman]

Post by John Reagan

Post by Stephen Hoffman

Post by John Reagan
Not to nitpick, but to avoid confusion. The standard build is NOT
unoptimized. The build uses the default of /OPT=LEVEL=4 for all
compiles. However, the default /ARCH value is EV4 (which also sets the
default for /OPT=TUNE). We added /ARCH=EV6 to the compilations. We
did not add/remove/change any /OPT qualifiers.

This approach interspersed duplicated architecture-specific instruction
streams throughout the objects and executables, and the compilers added
conditional gates to select the appropriate code.

Uh, that isn't what you get. /ARCH=EV6 gets pure EV6 only code.

I was referring to the existing approach used in all OpenVMS Alpha
releases prior to 2L2. To the default /ARCH setting.

Pondering whether the underpinnings built for EV6 and later matter to
the application code, other than around performance differences and
image sizes. If not (and I don't immediately see how), then there's
seemingly no need to identify the build to the application code. This
particularly assuming that all future builds will be EV6 or later, as
I'm guessing there's not going to be a whole lot of interest in
supporting parallel releases. (I mention this new-features
differentiation as HPE shipped a few new features in patch kits for
V8.4, with no way to differentiate those at run-time. That
undifferentiated packaging used by HPE doesn't seem to line up with
this build-oriented difference, though; that this isn't a new feature,
but an optimization and the effective end of support for earlier Alpha
processors.)

All good fodder for VTJ or VU or a VSI blog entry somewhere, too.

[John Reagan]

Post by Stephen Hoffman

Post by John Reagan

Post by Stephen Hoffman

Post by John Reagan
Not to nitpick, but to avoid confusion. The standard build is NOT
unoptimized. The build uses the default of /OPT=LEVEL=4 for all
compiles. However, the default /ARCH value is EV4 (which also sets the
default for /OPT=TUNE). We added /ARCH=EV6 to the compilations. We
did not add/remove/change any /OPT qualifiers.

This approach interspersed duplicated architecture-specific instruction
streams throughout the objects and executables, and the compilers added
conditional gates to select the appropriate code.

Uh, that isn't what you get. /ARCH=EV6 gets pure EV6 only code.

I was referring to the existing approach used in all OpenVMS Alpha
releases prior to 2L2. To the default /ARCH setting.

With the default of /ARCH=GENERIC (ie, EV4), you don't get any architecture-specific code in the normal cases, just the traditional ugly code

47FB041D 00C8 MOV R27, FP
A63D0018 00CC LDQ R17, 24(FP) ; 000008
A0310000 00D0 LDL i, EXT_INT ; R1, (R17)
A65D0020 00D4 LDQ R18, 32(FP) ; 000009
2E720000 00D8 LDQ_U R19, EXT_WORD ; R19, (R18)
4A7202D3 00DC EXTWL R19, EXT_WORD, R19 ; R19, R18, R19
F240000A 00E0 BLBS EXT_WORD, L$2 ; R18, L$2
47F30401 00E4 MOV R19, i ; R19, R1
00E8 L$3:
48261721 00E8 SLL i, 48, i ; R1, 48, R1
48261781 00EC SRA i, 48, i ; R1, 48, R1
A61D0028 00F0 LDQ R16, 40(FP) ; 000010
2C10FFFF 00F4 LDQ_U R0, -1(R16)
48100F40 00F8 EXTQH R0, R16, R0
48071781 00FC SRA R0, 56, i ; R0, 56, R1
47E03400 0100 MOV 1, R0 ; 000011
47F5041D 0104 MOV R21, FP
6BFA8001 0108 RET R26
010C L$2: ; 000009
2E920001 010C LDQ_U R20, EXT_WORD ; R20, 1(R18)
4A920B54 0110 EXTWH R20, EXT_WORD, R20 ; R20, R18, R20
46930401 0114 BIS R20, R19, i ; R20, R19, R1
C3FFFFF3 0118 BR L$3


You do see some uses of AMASK to guard things like "trailz()" and the like to enable the use of a specific post-EV4 instruction. There are a few cases where GEM will generate some AMASK-based code if you do something like:

CC /OPT=TUNE=EV6 without specifying an /ARCH qualifier. I did find a single use of that in the system but it isn't something you get by default.

[David Froble]

Post by Stephen Hoffman

Post by John Reagan

Post by ***@vmssoftware.com
Those

{..."performance improvements of between 15% and 50%"...}

Post by John Reagan

Post by ***@vmssoftware.com
are real numbers from some tests we ran. Here is my simplistic way to
look at it. Every execlet is 5%-10% smaller and RMS is 15% smaller,
compared to unoptimized (the standard build). That means many, many
code paths in the heart of the operating system are shorter with the
use of byte/word instructions. You can certainly make a more precise
analysis but that was from my quick look at comparing the result
disks from the 2L1 and 2L2 builds, picked a bunch of routines and
looked at the generated code.

Not to nitpick, but to avoid confusion. The standard build is NOT
unoptimized. The build uses the default of /OPT=LEVEL=4 for all
compiles. However, the default /ARCH value is EV4 (which also sets
the default for /OPT=TUNE). We added /ARCH=EV6 to the compilations.
We did not add/remove/change any /OPT qualifiers.

This approach interspersed duplicated architecture-specific instruction
streams throughout the objects and executables, and the compilers added
conditional gates to select the appropriate code. In broad terms, with
some code for execution on EV5 and prior, and separate code for EV56 and
later. This approach is conceptually quite simple for the end-users,
and certainly more than a little effort involved in the compiler code
scheduling and optimizations, but clearly an approach with more than a
little run-time overhead involved. In addition to what Clair and John
have mentioned above, this also means that the processor instruction
caches are less efficiently populated, and less efficiently used with
the branches necessary for interspersed-code design.
One alternative to this approach that's been discussed occasionally uses
so-called fat binaries, where the executable code for the different
architectures had different binaries within the same file package, and
there was one selection when the code was activated. (This approach
was used on another platform to select code optimized for different
targets, and for 32- and 64-bit addressing.) This approach makes for
more complex packaging, uses additional storage, means the compilers and
the linker can need multiple passes to build the selected
architecture-specific code, and adds some selection logic into the image
activator. This approach also means there's no run-time overhead past
the image activator selecting the appropriate binary to activate, and
the unnecessary variants can be potentially even be expunged to save on
the storage.
There's no right way to do this, of course. The trade-offs and the
quest for sufficient degree of upward-compatibility are often themselves
sources of trouble, complexity and overhead. Trade-offs between
application development efforts and expenses and complexity, and of
end-user performance or complexity or suchlike, too. It's never simple.

As you mention, this isn't easily answered, and no perfect path. However, so
far, I haven't heard anyone "sneezing" at 15% to 50% performance improvement.

Still saying "good job VSI".

[Stephen Hoffman]

..However, so far, I haven't heard anyone "sneezing" at 15% to 50%
performance improvement.
Still saying "good job VSI".

Ayup. But then I've been a proponent of breaking compatibility for a
while. Welcome aboard, David!

[David Froble]

Post by Stephen Hoffman

..However, so far, I haven't heard anyone "sneezing" at 15% to 50%
performance improvement.
Still saying "good job VSI".

Ayup. But then I've been a proponent of breaking compatibility for a
while. Welcome aboard, David!

I don't look at it so much as "breaking compatibility" as "supporting new HW.

If any Alpha's could be considered "new".

It's something that should have happened when EV6 first was introduced. But,
let's not go into "pitiful" ...

[David Froble]

Post by ***@vmssoftware.com

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm
Note (and as the subject of this thread says) that all year it has
been talks about a 8.4-2L1 Alpha version. More or less a recompile
of the current 8.4-2L1 for Itanium. I noticed now that what was
downloaded earlier today was ALpha 8.4-2L2. The cover letter (dated

http://www.vmssoftware.com/index.html
http://www.prweb.com/releases/2017/07/prweb14487932.htm
"Depending on the specific CPU and operating system features a customer’s
application uses, the new Alpha V8.4-2L2 release could render performance
improvements of between 15% and 50%. [...]", said Eddie Orcutt

Those are real numbers from some tests we ran. Here is my simplistic way to look at it. Every execlet is 5%-10% smaller and RMS is 15% smaller, compared to unoptimized (the standard build). That means many, many code paths in the heart of the operating system are shorter with the use of byte/word instructions. You can certainly make a more precise analysis but that was from my quick look at comparing the result disks from the 2L1 and 2L2 builds, picked a bunch of routines and looked at the generated code.

"Let's see, we got these EV6 and beyond processors. Why aren't we taking
advantage of them?"

Good job!

[Jan-Erik Soderholm]

Post by David Froble

Post by ***@vmssoftware.com

Post by Jan-Erik Soderholm

Post by Jan-Erik Soderholm
Note (and as the subject of this thread says) that all year it has
been talks about a 8.4-2L1 Alpha version. More or less a recompile
of the current 8.4-2L1 for Itanium. I noticed now that what was
downloaded earlier today was ALpha 8.4-2L2. The cover letter (dated

http://www.vmssoftware.com/index.html
http://www.prweb.com/releases/2017/07/prweb14487932.htm
"Depending on the specific CPU and operating system features a customer’s
application uses, the new Alpha V8.4-2L2 release could render performance
improvements of between 15% and 50%. [...]", said Eddie Orcutt

Those are real numbers from some tests we ran. Here is my simplistic way
to look at it. Every execlet is 5%-10% smaller and RMS is 15% smaller,
compared to unoptimized (the standard build). That means many, many code
paths in the heart of the operating system are shorter with the use of
byte/word instructions. You can certainly make a more precise analysis
but that was from my quick look at comparing the result disks from the
2L1 and 2L2 builds, picked a bunch of routines and looked at the
generated code.

"Let's see, we got these EV6 and beyond processors. Why aren't we taking
advantage of them?"
Good job!

And the number of Alphas, still in production use, that has
non-EV6 (or better) processors are probably very small.
Yes, a logical decision to take... :-)

[Stephen Hoffman]

Post by Jan-Erik Soderholm
"Depending on the specific CPU and operating system features a
customer’s application uses, the new Alpha V8.4-2L2 release could
render performance improvements of between 15% and 50%. [...]", said
Eddie Orcutt

This is an example of the direct cost of compatibility. While there
are ways around this and not the least of which are separate
installation kits or vastly more complex installations or fat binaries
or such, "simply" tossing out the oldest of the hardware and the oldest
of the software can sometimes allow substantial gains for more recent
configurations.

[Simon Clubley]

Post by Jan-Erik Soderholm
ISO files downloaded to our VMS test system. One for the OS and two
for the LP1 and LP2 kits. Looks OK. Can be mounted with LD. The OS
ISO will be copied to a SAN disk so that it can be booted. Next task...
The download was through a sftp link, b.t.w. Worked just OK.

Are there any cryptographic signature or hash files to allow you to
verify the ISOs after you have downloaded them ?

If VSI have not done this, I strongly recommend they do so; this is
expected and standard these days. It may be a good idea to keep the
signatures and/or hashes on the website instead as that means both
the website and the sftp server would have to be compromised.

Simon.

[Jan-Erik Soderholm]

Post by Simon Clubley

Post by Jan-Erik Soderholm
ISO files downloaded to our VMS test system. One for the OS and two
for the LP1 and LP2 kits. Looks OK. Can be mounted with LD. The OS
ISO will be copied to a SAN disk so that it can be booted. Next task...
The download was through a sftp link, b.t.w. Worked just OK.

Are there any cryptographic signature or hash files to allow you to
verify the ISOs after you have downloaded them ?

Each .ISO file also has a .ISO_VNC file. The download instructions says:

------------------------------------------------------------------
If you are already running VSI OpenVMS Alpha V8.4-2L1 you can use the
VMS Notary to validate the kit:

$! Extract the Alpha V8.4-2L2 ISO image file
$ run ALPHA0842L2.ZIPEXE
UnZipSFX 6.01 of 29 September 2014, by Info-ZIP (http://www.info-zip.org).
inflating: ALPHA0842L2.ISO
extracting: ALPHA0842L2.ISO_VNC
$ show symbol notary
NOTARY == "$VMS_NOTARY.EXE"
$ notary -i ALPHA0842L2.ISO_VNC
Success
------------------------------------------------------------------

Of course *I* cannot do that since we do not run VSI OpenVMS yet...

[Simon Clubley]

Post by Jan-Erik Soderholm

Post by Simon Clubley
Are there any cryptographic signature or hash files to allow you to
verify the ISOs after you have downloaded them ?

------------------------------------------------------------------
If you are already running VSI OpenVMS Alpha V8.4-2L1 you can use the
$! Extract the Alpha V8.4-2L2 ISO image file
$ run ALPHA0842L2.ZIPEXE
UnZipSFX 6.01 of 29 September 2014, by Info-ZIP (http://www.info-zip.org).
inflating: ALPHA0842L2.ISO
extracting: ALPHA0842L2.ISO_VNC
$ show symbol notary
NOTARY == "$VMS_NOTARY.EXE"
$ notary -i ALPHA0842L2.ISO_VNC
Success
------------------------------------------------------------------
Of course *I* cannot do that since we do not run VSI OpenVMS yet...

Interesting; thanks Jan-Erik.

I still think it would be a good idea to generate a more standard
hash or signature so the .ISO can be verified on a non-VMS system
before you run any code present in the .ISO.

Simon.

[Stephen Hoffman]

I still think it would be a good idea to generate a more standard hash
or signature so the .ISO can be verified on a non-VMS system before you
run any code present in the .ISO.

Ayup; a SHA-2 would be a common mechanism for that, and SHA-2 tools are
present in OpenVMS and other platforms.

How this all fits together and where there might be holes and where
this is all headed longer-term... is a whole 'nother story.

openssl dgst -sha256, etc