Free Alpha emulators running under Linux ?

[Simon Clubley]

At the moment, I run my home Alpha system on a FreeAXP instance
running under Windows.

It would be nice to switch to running an Alpha emulator under Linux
while switching to the VSI version of Alpha VMS.

What is the current state of play for free Alpha emulators running
under Linux ?

When I last looked at this a number of years ago, the only Linux based
emulator I could find at the time was es40 and that wasn't very usable
at the time.

There's some basic Alpha support in simh, but the last time I looked,
it was missing many of the features that would have made it a viable
full system emulator.

Thanks,

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[John H. Reinhardt]

On 1/2/2022 3:09 AM, Simon Clubley wrote:
> At the moment, I run my home Alpha system on a FreeAXP instance
> running under Windows.
>
> It would be nice to switch to running an Alpha emulator under Linux
> while switching to the VSI version of Alpha VMS.
>
> What is the current state of play for free Alpha emulators running
> under Linux ?
>
> When I last looked at this a number of years ago, the only Linux based
> emulator I could find at the time was es40 and that wasn't very usable
> at the time.
>

Things haven't improved. There is the AXPBox (forked from es40) which has been discussed here before. Currently at V1.10 it still isn't as stable as the commercial Windows apps. All the other previously available non-commercial non-Windows (and even commercial, I think) Alpha emulators have disappeared.

https://github.com/lenticularis39/axpbox
https://raymii.org/s/blog/AXPBox-version-1.0.0-released.html

Wikipedia knows of these: <https://en.wikipedia.org/wiki/List_of_computer_system_emulators#AlphaServer>
But I don't think that's up to date.

Zane Healy has this list which was last updated Feb 2021
<http://www.avanthar.com/healyzh/decemulation/Alpha.html>

> There's some basic Alpha support in simh, but the last time I looked,
> it was missing many of the features that would have made it a viable
> full system emulator.
>

The Alpha support in simh has languished. As far as I know, nobody has done any work on it in a long time.

> Thanks,
>
> Simon.
>

I have to check but now there may be issues with running the VSI CLP under AXPBox if it emulates an ES40. There have been discussions (on the VSI Forums) and VSI is limiting the PAKs to "desktop" servers i.e. DS10 class. I don't know if the licenses have enough units to run an ES40. VSI will give 150 units and that's all. If an ES40 is rated under that, then it will be okay but that's also the limit for a cluster so clustering an AXPbox ES40 with any other Alpha might be problematical.

The gist of it:

"This limitation was set deliberately after some discussion of what was the reasonable limit for a home system, how big a home cluster could be, and what hardware to consider viable for home use. It was decided that a two-node cluster system is enough to try and learn how to set up and use one of the most important and famous OpenVMS features, i.e. the OS level clustering."

and also:

"We do not think that having a departmental class server is reasonable for home use either as they are too noisy, bulky, and consume a lot of power. Other than that, the existing emulators that are provided for free, such as AXPbox and FreeAXP, emulate only the workgroup class systems as well, while the commercial emulators often provide support for higher-class systems. This means that giving more units would put this program to a risk of being improperly used which we definitely do not want to."


The full text is here:
<https://forum.vmssoftware.com/viewtopic.php?f=2&t=130&sid=6c00ba38fb1a41a7ce7f57908625e328#p988>

These are the posts which triggered the discussion:
https://forum.vmssoftware.com/viewtopic.php?f=1&t=254
https://forum.vmssoftware.com/viewtopic.php?f=5&t=116&p=983#p979

So VSI has decided how big a Hobbyist can go with their home systems. I guess that's their right but it rubs raw a bit after the freedom of the DEC/Compaq/HP Hobbyist program.

--
John H. Reinhardt

[Phil Howell]

Check out the AXPBox wiki on the GitHub page
https://github-wiki-see.page/m/lenticularis39/axpbox/wiki
and these from Remy
https://raymii.org/s/blog/Installing_the_es40_AlphaServer_emulator_0.18_on_Ubuntu_16.04_and_trying_to_install_openVMS_8.4_on_es40.html#google_vignette
https://raymii.org/s/tutorials/Installing_OpenVMS_8.4_Alpha_in_AXPbox_with_networking.html

Phil

[^P]

On Monday, January 3, 2022 at 8:17:26 AM UTC+1, Phil Howell wrote:
https://raymii.org/s/blog/Installing_the_es40_AlphaServer_emulator_0.18_on_Ubuntu_16.04_and_trying_to_install_openVMS_8.4_on_es40.html#google_vignette
> https://raymii.org/s/tutorials/Installing_OpenVMS_8.4_Alpha_in_AXPbox_with_networking.html
>
> Phil

There is also DECaxp:
https://github.com/JonathanBelanger/DECaxp

^P

[Simon Clubley]

On 2022-01-02, John H. Reinhardt <johnhre...@thereinhardts.org> wrote:
> On 1/2/2022 3:09 AM, Simon Clubley wrote:
>> At the moment, I run my home Alpha system on a FreeAXP instance
>> running under Windows.
>>
>> It would be nice to switch to running an Alpha emulator under Linux
>> while switching to the VSI version of Alpha VMS.
>>
>> What is the current state of play for free Alpha emulators running
>> under Linux ?
>>
>> When I last looked at this a number of years ago, the only Linux based
>> emulator I could find at the time was es40 and that wasn't very usable
>> at the time.
>>
>
> Things haven't improved. There is the AXPBox (forked from es40) which
> has been discussed here before. Currently at V1.10 it still isn't as
> stable as the commercial Windows apps. All the other previously available
> non-commercial non-Windows (and even commercial, I think) Alpha emulators
> have disappeared.
>

Thanks for the links and the summary.

I've gone through the links you and others have provided and see what
you mean.

The licence units issue was a bit of a surprise and something I had not
realised. While I criticise VSI for many things, that is something I
actually do understand from their viewpoint, given the number and types
of comments about bypassing the existing licencing terms.

It does raise one interesting question however: what does the concept
of licencing units even mean when it comes to x86-64 VMS ?

After all, unlike with the DEC hardware, you can't really add meaningful
markers to generic x86-64 hardware to indicate what type of system it is.

Oh well, it looks like it's going to still be FreeAXP on Windows for now... :-)

[Simon Clubley]

On 2022-01-03, ^P <peter.lju...@gmail.com> wrote:
>
> There is also DECaxp:
> https://github.com/JonathanBelanger/DECaxp
>

That's been archived on GitHub and the GitLab page isn't showing for
me for some reason right now. Has anyone tried this and how robust
is it ?

[John Dallman]

In article <squj4j$h25$1...@dont-email.me>,

clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> It does raise one interesting question however: what does the
> concept of licencing units even mean when it comes to x86-64 VMS?

Oracle deals with this by charging for their database by the number of
processor cores you use, with a scaling factor based on the processor
model.

<https://www.oracle.com/assets/databaselicensing-070584.pdf>

<http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-
070634.pdf>

It isn't a perfect system, as shown by the number of companies offering
to help optimise Oracle license costs, but it seems to work well enough.

John

[John H. Reinhardt]

On 1/3/2022 6:03 AM, John Dallman wrote:
> In article <squj4j$h25$1...@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>
>> It does raise one interesting question however: what does the
>> concept of licencing units even mean when it comes to x86-64 VMS?
>

I imagine they will do it the way they do Integrity licensing - probably per socket but maybe per core, or as with Integrity, they may give you a choice of one or the other when you buy the license.

> Oracle deals with this by charging for their database by the number of
> processor cores you use, with a scaling factor based on the processor
> model.
>
> <https://www.oracle.com/assets/databaselicensing-070584.pdf>
>
> <http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-
> 070634.pdf>
>
> It isn't a perfect system, as shown by the number of companies offering
> to help optimise Oracle license costs, but it seems to work well enough.
>

Yes, most of the optimization comes from managing VH hosts - Oracle;s per core applies to the VM host, not the VM guest so that you have to make sure when you have a large installation that the VM guests with Oracle databases are limited to VM Hosts with the number of cores total that you have licensed. At my work we have to do this all the time. we have probably 20 VM Host systems running a few hundred VM Guests and of those about half have Oracle databases. The server group has to be careful how the VM migration is set up to make sure our Oracle license capacity isn't exceeded.

> John

--
John H. Reinhardt

[Arne Vajhøj]

On 1/3/2022 10:23 AM, John H. Reinhardt wrote:
> On 1/3/2022 6:03 AM, John Dallman wrote:
>> In article <squj4j$h25$1...@dont-email.me>,
>> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>>> It does raise one interesting question however: what does the
>>> concept of licencing units even mean when it comes to x86-64 VMS?
>>
>
> I imagine they will do it the way they do Integrity licensing - probably
> per socket but maybe per core, or as with Integrity, they may give you a
> choice of one or the other when you buy the license.

I don't think per socket will make much sense in the future. Per
core or actually VCPU is what makes sense.

Examples:

You have VMS running on a 4 VCPU VM on ESXi that run 19 other
VMS on a 2s32c64t box and then you move it all to a new 2s48c96t box.

You have VMS running on a 4 VCPU EC2 instance and have no idea
what the HW is.

In those cases sockets does not have any relevant meaning.

Arne

[^P]

Original project is here:
https://gitlab.com/osf1/DECaxp

[osf1]

This is not the original repository. It's my port to get the (then) current version of DECaxp compiled and running on macOS 10.15. The original project is still a work in progress, but there was no activity for quite a while. Not sure, if it's still under development by Jonathan Belanger.

BR
OSF1

[Simon Clubley]

I've now had a look at the original GitLab repository. Last worked on
9 months ago with unanswered issues dating back to a year ago about it
not compiling, so I would assume the answer is no.

I also see the question about whether it can actually run VMS is
still unanswered after 7 months.

Has anyone managed to get the current version to compile and, if so,
have you been able to get it to run VMS ?

Just asking before I spend days trying to get it to work and only then
discover that it's known to be broken or doesn't run VMS properly. :-)

[osf1]

Simon Clubley schrieb am Dienstag, 4. Januar 2022 um 19:34:07 UTC+1:
> I've now had a look at the original GitLab repository. Last worked on
> 9 months ago with unanswered issues dating back to a year ago about it
> not compiling, so I would assume the answer is no.
>
> I also see the question about whether it can actually run VMS is
> still unanswered after 7 months.
>
> Has anyone managed to get the current version to compile and, if so,
> have you been able to get it to run VMS ?
>
> Just asking before I spend days trying to get it to work and only then
> discover that it's known to be broken or doesn't run VMS properly. :-)
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

It will not run VMS at this stage. It's missing several parts, to emulate a complete system. I don't remember now, what exactly, but I don't think, the disk I/O parts (ATA/ATAPI) where complete and I don't think the serial ports as well, but haven't checked this.

[Simon Clubley]

On 2022-01-05, osf1 <npw...@googlemail.com> wrote:
>
> It will not run VMS at this stage. It's missing several parts, to emulate a complete system. I don't remember now, what exactly, but I don't think, the disk I/O parts (ATA/ATAPI) where complete and I don't think the serial ports as well, but haven't checked this.

Thanks for the feedback.

It looks like the last changes were in these areas before the project
was apparently abandoned 9 months ago on GitLab. I may give it a brief
tryout at some point just to see if there's now enough to run VMS.

If I do try it at some point, I will report success or failure back here.

[^P]

On Wednesday, January 5, 2022 at 2:41:06 PM UTC+1, Simon Clubley wrote:
> On 2022-01-05, osf1 <npw...@googlemail.com> wrote:
> >
> > It will not run VMS at this stage. It's missing several parts, to emulate a complete system. I don't remember now, what exactly, but I don't think, the disk I/O parts (ATA/ATAPI) where complete and I don't think the serial ports as well, but haven't checked this.
> Thanks for the feedback.
>
> It looks like the last changes were in these areas before the project
> was apparently abandoned 9 months ago on GitLab. I may give it a brief
> tryout at some point just to see if there's now enough to run VMS.
>
> If I do try it at some point, I will report success or failure back here.
> Simon.
>

So it's more or less only AXPBOX left then

[cao...@pitbulluk.org]

I've noticed that axpbox is more stable when compiled -O2 (rather than the default -O3) though that probably depends on the linux platform - Arm in this case.
Strangely enough, lowering the amount of optimisation like that was also required to get KLH10 to work correctly.

K

[Simon Clubley]

On 2022-01-05, cao...@pitbulluk.org <cao...@pitbulluk.org> wrote:
>
> I've noticed that axpbox is more stable when compiled -O2 (rather than the default -O3) though that probably depends on the linux platform - Arm in this case.
> Strangely enough, lowering the amount of optimisation like that was also required to get KLH10 to work correctly.
>

Actually, that's a common enough problem with code in general when the
programmer makes unjustified assumptions about the environment the code
is operating in and those assumptions become invalid because the compiler
applies fully legal optimisations which then break the code.

It's quite possible for example, that code which is accidentally working
using the default settings with the existing GEM based VMS compilers may
actually break when the same code is compiled under the new upcoming
LLVM-based compilers.

[John Reagan]

On Thursday, January 6, 2022 at 1:48:11 PM UTC-5, Simon Clubley wrote:
> On 2022-01-05, cao...@pitbulluk.org <cao...@pitbulluk.org> wrote:

>
> It's quite possible for example, that code which is accidentally working
> using the default settings with the existing GEM based VMS compilers may
> actually break when the same code is compiled under the new upcoming
> LLVM-based compilers.
> Simon.
>

Since that happened when porting from Alpha to Itanium (both GEM) or even
when we added features to GEM, it is guaranteed to happen again.

[David Turner]

Artem Alimarin offers a CHEAP version of AlphaVM
Meant for Educators and Hobbyists. It runs on Linux/Windows and he has
built a MAC variant too
Best emulator out there

www.emuvm.com

His email is ar...@emuvm.com

[Arne Vajhøj]

On 1/7/2022 2:35 PM, David Turner wrote:
> On 1/6/2022 4:51 PM, John Reagan wrote:
>> On Thursday, January 6, 2022 at 1:48:11 PM UTC-5, Simon Clubley wrote:
>>> On 2022-01-05, cao...@pitbulluk.org <cao...@pitbulluk.org> wrote:
>>> It's quite possible for example, that code which is accidentally working
>>> using the default settings with the existing GEM based VMS compilers may
>>> actually break when the same code is compiled under the new upcoming
>>> LLVM-based compilers.
>>> Simon.
>>>
>> Since that happened when porting from Alpha to Itanium (both GEM) or even
>> when we added features to GEM, it is guaranteed to happen again.

> Artem Alimarin offers a CHEAP version of AlphaVM
> Meant for Educators and Hobbyists. It runs on Linux/Windows and he has
> built a MAC variant too
> Best emulator out there
>
> www.emuvm.com
>
> His email is ar...@emuvm.com

The product is great. I have used it a bit and it works
perfect.

But cheap is 500 dollar for first year and 250 dollar per
year after that.

Compared to DEC prices in the past that is very cheap.

But compared to VMS x86-64 in the future it is not
so cheap.

You can run a 1 VCPU 2 GB memory instance on AWS EC2
24 x 7 for less than 250 dollar per year. And if just
run occasionally then it will cost nothing.

Arne

[Subcommandante XDelta]

On Sun, 2 Jan 2022 09:09:42 -0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>At the moment, I run my home Alpha system on a FreeAXP instance
>running under Windows.
>
>It would be nice to switch to running an Alpha emulator under Linux
>while switching to the VSI version of Alpha VMS.
>
>What is the current state of play for free Alpha emulators running
>under Linux ?
>
>When I last looked at this a number of years ago, the only Linux based
>emulator I could find at the time was es40 and that wasn't very usable
>at the time.
>
>There's some basic Alpha support in simh, but the last time I looked,
>it was missing many of the features that would have made it a viable
>full system emulator.
>
>Thanks,
>
>Simon.

Whilst strictly off-topic, relative to your specific query about free
AXP/Linux emulators, the VLF hate to see good digits suffer needlessly
- this should help you potter about, happily enough, in your
temperature controlled, false floor, backyard shed, with your hobbyist
VMS systems:

Stromasys.CHARON-AXP.v4.2.Build.142-01.68704122.Retail.GNU.Linux.x64.Cracked-VLF

File-hosts:

https://www.mirrored.to/files/0UAHF0R6/

Usenet Binaries Newsgroups:

https://binsearch.info/?q=Stromasys.CHARON-AXP.v4.2.Build.142-01.68704122.Retail.GNU.Linux.x64.Cracked-VLF

Old (2013), but solid gold.

We don't like to see good digits suffer, nor do we think that
Stromasys, historically, have suffered - no principals, in their right
minds, of any business or institution, would risk their enterprise, or
organisation, by running their business critical, or mission critical,
production systems, on a cracked hardware emulator - you would want
established business relationships with the hardware emulator
developers, so that there are no delays, whatsoever, in getting
technical support.

We only formally, warrant that our work is sufficient for hobbyist
systems - however, at a pinch, you could also duct tape implement them
in a nuclear power station, to get things working again, if need be,
and if there was no other timely alternative.

Best regards,

VLF: The VMS Liberation Front
In VMS We Trust.

PS: A shout out and salute to Gérard Calliet and the team at the
VMSgenerations Working Group - the VLF greatly admire their above
ground work, from afar - industry association, institutional response,
aggregate activism, in the relation to VSI is the way to go -
individual petitioning will not cut it.

$!------------------------- damn straight --------------------------!$
$ opprobrium/level=kittens/mode=conniptions/input=VLF:/output=NL: !$
$!-------------------------- enough said ---------------------------!$

[Subcommandante XDelta]

comp.os.vms college,

Whilst, strictly speaking, off-topic, in furtherance of the thesis:

https://pastebin.com/AB8xvgd7

The 'Pastebin' text snippet website benchmarks "safe to visit".

In regards to VAX/VMS, if any VMS hobbyist or VMS shop, that you know,
is suffering, then relieve them of their misery, forthwith.

Best regards,

VLF: The VMS Liberation Front
In VMS We Trust.

$!------------------------- damn straight --------------------------!$
$ opprobrium/level=kittens/mode=conniptions/input=VLF:/output=NL: !$
$!-------------------------- enough said ---------------------------!$