I am running OpenVMS x86_64 E9.2-1 under VirtualBox 7.0.8 on macOS
Ventura 13.3.1 (a). The host is a 2019 MacBook Pro with 2.3 GHz 8-Core
Intel Core i9. The clock isn't working right, most easily seen by the
fact that the following two commands were typed exactly one minute apart:

$ sh time
5-MAY-2023 19:07:35
$ sh time
5-MAY-2023 19:07:45

So the system advances its clock about 10 seconds for every 60 seconds
of actual time.

Another way of illustrating the problem is by running the vups.com from
<https://emuvm.com/download/vups-com-benchmark/>, which says:

Approximate System VUPs Rating : 10430.2 ( min: 950.4 max: 55125.0 )

Divide that number by 6 and it might almost be credible based on numbers
other people have been posting, though a factor of 10-15 would be more
believable. The system is *not* in fact fast at all -- it takes about
15 seconds for MONITOR SYSTEM to initiate its display when nothing at
all is running.

I have not seen this anywhere in the VSI documentation, but this blog post:

<https://raymii.org/s/blog/OpenVMS_9.2_for_x86_Getting_Started.html>

says it's necessary to set the clock characteristics of the virtual
machine like so:

$ vboxmanage modifyvm <vmname> --hpet on

I have done so but observe no difference (everything posted above was
after running this command and restarting VirtualBox). Supposedly this
setting "Enables . . . a High Precision Event Timer (HPET) which can
replace the legacy system timers," whatever that means. I guess one
possibility is that the command, while it returned no errors, also
didn't take effect for some reason. I cannot tell from the following
output whether the non-default setting is in effect:

$ vboxmanage debugvm <vmname> info hpet
HPET status:
config=0000000000000003 isr=0000000000000000
offset=fffffff020435102 counter=0000000000000000 frequency=69841279 fs
legacy-mode=on timer-count=4
Timers:
0: comparator=0000001022973a28 accumulator=0000000000022f4d (9999944 ns)
config=ffffffff0000003c irq=0 en per cap_per cap_64
1: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
config=ffffffff00000000 irq=8
2: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
config=ffffffff00000000 irq=0
3: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
config=ffffffff00000000 irq=0

Has anyone sen anything like this or has any ideas on how to debug/fix
it? The only next step I can think of is to try VMWare Player and see
if it works better than VirtualBox.

On Saturday, May 6, 2023 at 12:49:43 PM UTC-4, Craig A. Berry wrote:
> I am running OpenVMS x86_64 E9.2-1 under VirtualBox 7.0.8 on macOS
> Ventura 13.3.1 (a). The host is a 2019 MacBook Pro with 2.3 GHz 8-Core
> Intel Core i9. The clock isn't working right, most easily seen by the
> fact that the following two commands were typed exactly one minute apart:
>
> $ sh time
> 5-MAY-2023 19:07:35
> $ sh time
> 5-MAY-2023 19:07:45
>
> So the system advances its clock about 10 seconds for every 60 seconds
> of actual time.
> ...
> Has anyone sen anything like this or has any ideas on how to debug/fix
> it? The only next step I can think of is to try VMWare Player and see
> if it works better than VirtualBox.

I haven't seen anything like that, VirtualBox doesn't step the time if my
Windows laptop does to sleep and wake up. On my laptop, VirtualBox
V7.0.6 seems to enable hpet by default, since it show up as enabled in
the logs.

The NTP daemon doesn't seem stable in this envvironment. The drift
file has -1.498 in it.

Like I have always suspected.
I think there is more of an emulator in the OpenVMS x86 code than has
been admitted.
The faster the CPU on the virtualbox the faster your "native X86" code
is gonna run
Anyone care to elaborate or prove this?

DT

On 5/6/2023 12:49 PM, Craig A. Berry wrote:
>
> I am running OpenVMS x86_64 E9.2-1 under VirtualBox 7.0.8 on macOS
> Ventura 13.3.1 (a).  The host is a 2019 MacBook Pro with 2.3 GHz 8-Core
> Intel Core i9.  The clock isn't working right, most easily seen by the
> fact that the following two commands were typed exactly one minute apart:
>
> $ sh time
>    5-MAY-2023 19:07:35
> $ sh time
>    5-MAY-2023 19:07:45
>
> So the system advances its clock about 10 seconds for every 60 seconds
> of actual time.
>
> Another way of illustrating the problem is by running the vups.com from
> <https://emuvm.com/download/vups-com-benchmark/>, which says:
>
>  Approximate System VUPs Rating : 10430.2 ( min: 950.4 max: 55125.0 )
>
> Divide that number by 6 and it might almost be credible based on numbers
> other people have been posting, though a factor of 10-15 would be more
> believable.  The system is *not* in fact fast at all -- it takes about
> 15 seconds for MONITOR SYSTEM to initiate its display when nothing at
> all is running.
>
> I have not seen this anywhere in the VSI documentation, but this blog
> post:
>
> <https://raymii.org/s/blog/OpenVMS_9.2_for_x86_Getting_Started.html>
>
> says it's necessary to set the clock characteristics of the virtual
> machine like so:
>
> $ vboxmanage modifyvm <vmname> --hpet on
>
> I have done so but observe no difference (everything posted above was
> after running this command and restarting VirtualBox).  Supposedly this
> setting "Enables . . . a High Precision Event Timer (HPET) which can
> replace the legacy system timers," whatever that means. I guess one
> possibility is that the command, while it returned no errors, also
> didn't take effect for some reason.  I cannot tell from the following
> output whether the non-default setting is in effect:
>
> $ vboxmanage debugvm <vmname> info hpet
> HPET status:
>  config=0000000000000003     isr=0000000000000000
>  offset=fffffff020435102 counter=0000000000000000 frequency=69841279 fs
>  legacy-mode=on   timer-count=4
> Timers:
>  0: comparator=0000001022973a28 accumulator=0000000000022f4d (9999944 ns)
>         config=ffffffff0000003c irq=0 en per cap_per cap_64
>  1: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>         config=ffffffff00000000 irq=8
>  2: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>         config=ffffffff00000000 irq=0
>  3: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>         config=ffffffff00000000 irq=0
>
>
> Has anyone sen anything like this or has any ideas on how to debug/fix
> it?  The only next step I can think of is to try VMWare Player and see
> if it works better than VirtualBox.
>

On 5/7/2023 6:44 PM, David Turner wrote:
> Like I have always suspected.
> I think there is more of an emulator in the OpenVMS x86 code than has been
> admitted.
> The faster the CPU on the virtualbox the faster your "native X86" code is gonna run
> Anyone care to elaborate or prove this?

With every port, more code has been moved from hardware to firmware to software.

Alpha to IA64 required a new mechanism (SoftWare Interupt Services, otherwise
known as SWIS) to handle stuff that was in VAX hardware and Alpha firmware.
SWIS also exists for X86_64 VMS.

There is no VEST/TIE-like mechanism for running non-X86 code on VMS for X86_64.

This is not a VAX/VMS V1.0 situation where some of the VMS commonly-used system
programs were RSX images.

--

--- Rob

On Sunday, May 7, 2023 at 10:05:59 PM UTC-4, Robert A. Brooks wrote:
> There is no VEST/TIE-like mechanism for running non-X86 code on VMS for X86_64.

Do I remember correctly that some method of running Alpha user code was planned for a future release?

On Sunday, May 7, 2023 at 11:34:47 PM UTC-4, terry-...@glaver.org wrote:
> On Sunday, May 7, 2023 at 10:05:59 PM UTC-4, Robert A. Brooks wrote:
> > There is no VEST/TIE-like mechanism for running non-X86 code on VMS for X86_64.
> Do I remember correctly that some method of running Alpha user code was planned for a future release?

VSI states in their FAQ that they prototyped a working VEST type solution, but....

"We created a prototype binary translator for Alpha to x86-64, however there are no plans at this time to develop this further. Any additional work will be evaluated based on customer requirements."

from: https://vmssoftware.com/about/v9-qa/

Den 2023-05-08 kl. 00:44, skrev David Turner:
> Like I have always suspected.
> I think there is more of an emulator in the OpenVMS x86 code than has been
> admitted.
> The faster the CPU on the virtualbox the faster your "native X86" code is
> gonna run
> Anyone care to elaborate or prove this?

I should not take the writing below as anything of a value.
Just the line saying "it takes about >> 15 seconds for MONITOR
SYSTEM to initiate its display" says that something is really
wrong with that environment. On my laptop with VirtualBox,
MONITOR starts in around 1 sec. I cannot see any difference
between my VirtualBox environment and a real AlphaServer DS20e.

What I can see, is a slight lag in the clock. It looses approx
1 second in 2.5 minutes. But it is not consitent, a few minutes
later, my VirtualBox VMS time was back i phase with our real
production DS20e again. And over a longer timespan, it seems to
keep the time fine.

When looking at the MON screen, I can see that the running clock
at the top right, sometimes jumps over a second and advances 2
secons "in one second", so to speak.

I have not done any NNTP setup.
I have not done that command regarding the clock in the docs.

Regards,
Jan-Erik.

>
>
> DT
>
>
> On 5/6/2023 12:49 PM, Craig A. Berry wrote:
>>
>> I am running OpenVMS x86_64 E9.2-1 under VirtualBox 7.0.8 on macOS
>> Ventura 13.3.1 (a).  The host is a 2019 MacBook Pro with 2.3 GHz 8-Core
>> Intel Core i9.  The clock isn't working right, most easily seen by the
>> fact that the following two commands were typed exactly one minute apart:
>>
>> $ sh time
>>    5-MAY-2023 19:07:35
>> $ sh time
>>    5-MAY-2023 19:07:45
>>
>> So the system advances its clock about 10 seconds for every 60 seconds
>> of actual time.
>>
>> Another way of illustrating the problem is by running the vups.com from
>> <https://emuvm.com/download/vups-com-benchmark/>, which says:
>>
>>  Approximate System VUPs Rating : 10430.2 ( min: 950.4 max: 55125.0 )
>>
>> Divide that number by 6 and it might almost be credible based on numbers
>> other people have been posting, though a factor of 10-15 would be more
>> believable.  The system is *not* in fact fast at all -- it takes about
>> 15 seconds for MONITOR SYSTEM to initiate its display when nothing at
>> all is running.
>>
>> I have not seen this anywhere in the VSI documentation, but this blog post:
>>
>> <https://raymii.org/s/blog/OpenVMS_9.2_for_x86_Getting_Started.html>
>>
>> says it's necessary to set the clock characteristics of the virtual
>> machine like so:
>>
>> $ vboxmanage modifyvm <vmname> --hpet on
>>
>> I have done so but observe no difference (everything posted above was
>> after running this command and restarting VirtualBox).  Supposedly this
>> setting "Enables . . . a High Precision Event Timer (HPET) which can
>> replace the legacy system timers," whatever that means. I guess one
>> possibility is that the command, while it returned no errors, also
>> didn't take effect for some reason.  I cannot tell from the following
>> output whether the non-default setting is in effect:
>>
>> $ vboxmanage debugvm <vmname> info hpet
>> HPET status:
>>  config=0000000000000003     isr=0000000000000000
>>  offset=fffffff020435102 counter=0000000000000000 frequency=69841279 fs
>>  legacy-mode=on   timer-count=4
>> Timers:
>>  0: comparator=0000001022973a28 accumulator=0000000000022f4d (9999944 ns)
>>         config=ffffffff0000003c irq=0 en per cap_per cap_64
>>  1: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>>         config=ffffffff00000000 irq=8
>>  2: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>>         config=ffffffff00000000 irq=0
>>  3: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>>         config=ffffffff00000000 irq=0
>>
>>
>> Has anyone sen anything like this or has any ideas on how to debug/fix
>> it?  The only next step I can think of is to try VMWare Player and see
>> if it works better than VirtualBox.
>>
>

On 5/8/23 1:45 AM, Jan-Erik Söderholm wrote:
> Den 2023-05-08 kl. 00:44, skrev David Turner:
>> Like I have always suspected.
>> I think there is more of an emulator in the OpenVMS x86 code than has
>> been admitted.
>> The faster the CPU on the virtualbox the faster your "native X86" code
>> is gonna run
>> Anyone care to elaborate or prove this?

Prove what? That nothing in this newsgroup stays on-topic?
> I should not take the writing below as anything of a value.

It's of value to me if it helps anyone identify a solution to the
problem I'm having.

> Just the line saying "it takes about >> 15 seconds for MONITOR
> SYSTEM to initiate its display" says that something is really
> wrong with that environment. On my laptop with VirtualBox,
> MONITOR starts in around 1 sec. I cannot see any difference
> between my VirtualBox environment and a real AlphaServer DS20e.

Right. There is no reason to hijack my thread with a conspiracy theory.
I have what must be an extremely common set-up, yet things are
completely haywire. Other people with VirtualBox do not see what I'm
seeing. There must be some combination of host OS / host hardware /
hypervisor / settings that is not an agreeable combo. Speculating
without foundation that OpenVMS x86 runs on an emulator rather than a
hypervisor does not get me any closer to figuring out what the actual
problem is.

> What I can see, is a slight lag in the clock. It looses approx
> 1 second in 2.5 minutes. But it is not consitent, a few minutes
> later, my VirtualBox VMS time was back i phase with our real
> production DS20e again. And over a longer timespan, it seems to
> keep the time fine.
>
> When looking at the MON screen, I can see that the running clock
> at the top right, sometimes jumps over a second and advances 2
> secons "in one second", so to speak.
>
> I have not done any NNTP setup.
> I have not done that command regarding the clock in the docs.
>
> Regards,
> Jan-Erik.
>
>
>
>>
>>
>> DT
>>
>>
>> On 5/6/2023 12:49 PM, Craig A. Berry wrote:
>>>
>>> I am running OpenVMS x86_64 E9.2-1 under VirtualBox 7.0.8 on macOS
>>> Ventura 13.3.1 (a).  The host is a 2019 MacBook Pro with 2.3 GHz 8-Core
>>> Intel Core i9.  The clock isn't working right, most easily seen by the
>>> fact that the following two commands were typed exactly one minute
>>> apart:
>>>
>>> $ sh time
>>>    5-MAY-2023 19:07:35
>>> $ sh time
>>>    5-MAY-2023 19:07:45
>>>
>>> So the system advances its clock about 10 seconds for every 60 seconds
>>> of actual time.
>>>
>>> Another way of illustrating the problem is by running the vups.com from
>>> <https://emuvm.com/download/vups-com-benchmark/>, which says:
>>>
>>>  Approximate System VUPs Rating : 10430.2 ( min: 950.4 max: 55125.0 )
>>>
>>> Divide that number by 6 and it might almost be credible based on numbers
>>> other people have been posting, though a factor of 10-15 would be more
>>> believable.  The system is *not* in fact fast at all -- it takes about
>>> 15 seconds for MONITOR SYSTEM to initiate its display when nothing at
>>> all is running.
>>>
>>> I have not seen this anywhere in the VSI documentation, but this blog
>>> post:
>>>
>>> <https://raymii.org/s/blog/OpenVMS_9.2_for_x86_Getting_Started.html>
>>>
>>> says it's necessary to set the clock characteristics of the virtual
>>> machine like so:
>>>
>>> $ vboxmanage modifyvm <vmname> --hpet on
>>>
>>> I have done so but observe no difference (everything posted above was
>>> after running this command and restarting VirtualBox).  Supposedly this
>>> setting "Enables . . . a High Precision Event Timer (HPET) which can
>>> replace the legacy system timers," whatever that means. I guess one
>>> possibility is that the command, while it returned no errors, also
>>> didn't take effect for some reason.  I cannot tell from the following
>>> output whether the non-default setting is in effect:
>>>
>>> $ vboxmanage debugvm <vmname> info hpet
>>> HPET status:
>>>  config=0000000000000003     isr=0000000000000000
>>>  offset=fffffff020435102 counter=0000000000000000 frequency=69841279 fs
>>>  legacy-mode=on   timer-count=4
>>> Timers:
>>>  0: comparator=0000001022973a28 accumulator=0000000000022f4d (9999944
>>> ns)
>>>         config=ffffffff0000003c irq=0 en per cap_per cap_64
>>>  1: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>>>         config=ffffffff00000000 irq=8
>>>  2: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>>>         config=ffffffff00000000 irq=0
>>>  3: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>>>         config=ffffffff00000000 irq=0
>>>
>>>
>>> Has anyone sen anything like this or has any ideas on how to debug/fix
>>> it?  The only next step I can think of is to try VMWare Player and see
>>> if it works better than VirtualBox.
>>>
>>
>

Den 2023-05-08 kl. 13:08, skrev Craig A. Berry:
>
> On 5/8/23 1:45 AM, Jan-Erik Söderholm wrote:
>> Den 2023-05-08 kl. 00:44, skrev David Turner:
>>> Like I have always suspected.
>>> I think there is more of an emulator in the OpenVMS x86 code than has
>>> been admitted.
>>> The faster the CPU on the virtualbox the faster your "native X86" code
>>> is gonna run
>>> Anyone care to elaborate or prove this?
>
> Prove what?  That nothing in this newsgroup stays on-topic?
>> I should not take the writing below as anything of a value.
>
> It's of value to me if it helps anyone identify a solution to the
> problem I'm having.
>
>> Just the line saying "it takes about >> 15 seconds for MONITOR
>> SYSTEM to initiate its display" says that something is really
>> wrong with that environment. On my laptop with VirtualBox,
>> MONITOR starts in around 1 sec. I cannot see any difference
>> between my VirtualBox environment and a real AlphaServer DS20e.
>
> Right.  There is no reason to hijack my thread with a conspiracy theory.

Now, did *I* do that? You quoted me before your reply.
It was David T that dragged the "emulator" into this. And he was
of course completely of-track with this "emulator" talk.

I was just confirming that something must be weird in the
setup that was reported, and that was what I commented on. You are
correct that it migth now help you directly, but I thought it could
be of some use/interest anyway.

And I also found it interesting that the clock "ticked" a bit
slow and then jumped forward and skipped a second to catch-up.

But yes, if this had been a common VirtualBox issue, it would
have been know by now, of course.

> I have what must be an extremely common set-up, yet things are
> completely haywire.  Other people with VirtualBox do not see what I'm
> seeing.  There must be some combination of host OS / host hardware /
> hypervisor / settings that is not an agreeable combo.

Sure...

> Speculating
> without foundation that OpenVMS x86 runs on an emulator rather than a
> hypervisor does not get me any closer to figuring out what the actual
> problem is.

Again, *I* did not do added that "speculation"...

On 5/8/23 6:22 AM, Jan-Erik Söderholm wrote:
> Den 2023-05-08 kl. 13:08, skrev Craig A. Berry:

>> Right.  There is no reason to hijack my thread with a conspiracy theory.

> Now, did *I* do that? You quoted me before your reply.

No. I believe the quote indent levels were correct in my post.

> It was David T that dragged the "emulator" into this. And he was
> of course completely of-track with this "emulator" talk.

Yes. I was agreeing with you on that point and hoping (in vain, no
doubt, this being c.o.v) to drag the thread back on track.

Den 2023-05-08 kl. 13:27, skrev Craig A. Berry:
>
> On 5/8/23 6:22 AM, Jan-Erik Söderholm wrote:
>> Den 2023-05-08 kl. 13:08, skrev Craig A. Berry:
>
>>> Right.  There is no reason to hijack my thread with a conspiracy theory.
>
>> Now, did *I* do that? You quoted me before your reply.
>
> No.  I believe the quote indent levels were correct in my post.
>
>> It was David T that dragged the "emulator" into this. And he was
>> of course completely of-track with this "emulator" talk.
>
> Yes.  I was agreeing with you on that point and hoping (in vain, no
> doubt, this being c.o.v) to drag the thread back on track.
>

Sure! :-)
Hope you find some solution! And I do not see it *that* off track...

And, I guess that these issues kind of proves the point that
VSI will/must keep it's *supported* production environments
to a few well proven platforms/environments.

On 5/7/2023 11:34 PM, terry-...@glaver.org wrote:
> On Sunday, May 7, 2023 at 10:05:59 PM UTC-4, Robert A. Brooks wrote:
>> There is no VEST/TIE-like mechanism for running non-X86 code on VMS for X86_64.
>
> Do I remember correctly that some method of running Alpha user code was planned for a future release?

At this point I am amazed there isn't a VAX and an Alpha emulator
included as a part of VMS-x86_64 to allow people to run code that
can not be moved forward.

bill

On 5/8/2023 8:40 AM, bill wrote:
> On 5/7/2023 11:34 PM, terry-...@glaver.org wrote:
>> On Sunday, May 7, 2023 at 10:05:59 PM UTC-4, Robert A. Brooks wrote:
>>> There is no VEST/TIE-like mechanism for running non-X86 code on VMS for X86_64.
>>
>> Do I remember correctly that some method of running Alpha user code was
>> planned for a future release?
>
> At this point I am amazed there isn't a VAX and an Alpha emulator
> included as a part of VMS-x86_64 to allow people to run code that
> can not be moved forward.
>
> bill
>

"At this point" x86 VMS does not have all the compilers working on x86, and the
OS build is not native. "At this point" I have no idea why you'd think such
software would have any priority.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/8/2023 8:53 AM, Dave Froble wrote:
> On 5/8/2023 8:40 AM, bill wrote:
>> On 5/7/2023 11:34 PM, terry-...@glaver.org wrote:
>>> On Sunday, May 7, 2023 at 10:05:59 PM UTC-4, Robert A. Brooks wrote:
>>>> There is no VEST/TIE-like mechanism for running non-X86 code on VMS
>>>> for X86_64.
>>>
>>> Do I remember correctly that some method of running Alpha user code was
>>> planned for a future release?
>>
>> At this point I am amazed there isn't a VAX and an Alpha emulator
>> included as a part of VMS-x86_64 to allow people to run code that
>> can not be moved forward.
>>
>> bill
>>
>
> "At this point" x86 VMS does not have all the compilers working on x86,
> and the OS build is not native.  "At this point" I have no idea why
> you'd think such software would have any priority.
>

Because we often hear that there are still people running Vaxen
with VMS on them and I expect moving a program from the VAX to
x86-64 would be difficult if not impossible (especially if it
has any MACRO in it!) VAX hardware is getting rarer and rarer.
I just see it as an alternative to trying to develop a VEST.

Alpha is in a similar but not quite as near to extinction.

bill

On 5/8/2023 8:40 AM, bill wrote:
> On 5/7/2023 11:34 PM, terry-...@glaver.org wrote:
>> On Sunday, May 7, 2023 at 10:05:59 PM UTC-4, Robert A. Brooks wrote:
>>> There is no VEST/TIE-like mechanism for running non-X86 code on VMS
>>> for X86_64.
>>
>> Do I remember correctly that some method of running Alpha user code
>> was planned for a future release?
>
> At this point I am amazed there isn't a VAX and an Alpha emulator
> included as a part of VMS-x86_64 to allow people to run code that
> can not be moved forward.

If you mean a true emulator then I don't see the point - there are
plenty of such products available from third parties. If anyone need
one, then they buy one. No need for VSI to do anything.

(VSI would also have a small problem supplying a VMS version for
a VAX simulator)

If you mean something like VEST or AEST (which is a translation not
an emulation) - it would probably be called IEST to follow naming
convention, then my guess is that if VSI were DEC/HP size, then they
would have created such a beast, but they are not. VSI is a smaller
company and they have to prioritize. IEST with the possibility to
also process images that has already been through AEST and
possible VEST would be a lot of work. So they decided not to do it.

Arne

On 5/8/2023 9:11 AM, bill wrote:
> On 5/8/2023 8:53 AM, Dave Froble wrote:
>> On 5/8/2023 8:40 AM, bill wrote:
>>> At this point I am amazed there isn't a VAX and an Alpha emulator
>>> included as a part of VMS-x86_64 to allow people to run code that
>>> can not be moved forward.
>>
>> "At this point" x86 VMS does not have all the compilers working on
>> x86, and the OS build is not native.  "At this point" I have no idea
>> why you'd think such software would have any priority.
>
> Because we often hear that there are still people running Vaxen
> with VMS on them and I expect moving a program from the VAX to
> x86-64 would be difficult if not impossible (especially if it
> has any MACRO in it!) VAX hardware is getting rarer and rarer.
> I just see it as an alternative to trying to develop a VEST.

There are people with that need.

But solutions are already available.

Stromasys Charon-VAX is probably the most well known.

https://www.stromasys.com/solution/charon-vax

You pay - you get your VAX - you get support - I assume
Stromasys can even help with the license transfer.

What should VSI contribute with?

> Alpha is in a similar but not quite as near to extinction.

There are even more Alpha simulators available.

https://www.stromasys.com/solution/charon-axp

https://emuvm.com/

Arne

> But solutions are already available.
>
> Stromasys Charon-VAX is probably the most well known.
>
> https://www.stromasys.com/solution/charon-vax
>
> You pay - you get your VAX - you get support - I assume
> Stromasys can even help with the license transfer.
>
> What should VSI contribute with?
> > Alpha is in a similar but not quite as near to extinction.
> There are even more Alpha simulators available.
>
> https://www.stromasys.com/solution/charon-axp
>
> https://emuvm.com/
>
> Arne

Yes, Stromays can help with the license transfer (and general VAX and OpenVMS operational support too!)
The same goes for the Alpha platform.

Dan

Full disclosure: I work for Stromasys providing the above support.

In article <kbsanjFfrbrU1@mid.individual.net>, bill.gunshannon@gmail.com
(bill) wrote:

> Because we often hear that there are still people running Vaxen
> with VMS on them and I expect moving a program from the VAX to
> x86-64 would be difficult if not impossible (especially if it
> has any MACRO in it!)

If you have the source, the MACRO cross-compiler to x86 is available. It
had to be: chunks of VMS are still written in it.

John

On 5/8/2023 9:14 AM, Arne Vajhøj wrote:
>
>
> If you mean a true emulator then I don't see the point - there are
> plenty of such products available from third parties. If anyone need
> one, then they buy one. No need for VSI to do anything.

I guess I'm just to subtle. I certainly didn't mean for VSI to re-
invent the wheel yet again. I meant that they should [ick up one of
these existing emulators (SIMH for the VAX) do a port for VMS (if
it doesn't already exist) and then bundle them with VMS-x86_64.
IMHO a reasonable alternative to the VEST idea. I am sure any VAX
emulation will be faster than the fastest hardware VAX ever built.
Alpha, I couldn't say.

>
> (VSI would also have a small problem supplying a VMS version for
> a VAX simulator)

Well, once things smooth out keeping these VAX customers on VMS might
just be the incentive they need to do a VSI VAX Version. I am pretty
sure they have said in the past that they have the license to do this
but just didn't see a business case.

>
> If you mean something like VEST or AEST (which is a translation not
> an emulation) - it would probably be called IEST to follow naming
> convention, then my guess is that if VSI were DEC/HP size, then they
> would have created such a beast, but they are not. VSI is a smaller
> company and they have to prioritize. IEST with the possibility to
> also process images that has already been through AEST and
> possible VEST would be a lot of work. So they decided not to do it.

I see it as an alternative. And, I expect a much more reliable one.
I have never run anything VESTed or AESTed but I can see a lot of ways
that could go wrong. I think even more so with the new architecture.

bill

On Monday, May 8, 2023 at 2:56:05 PM UTC-4, bill wrote:
> I guess I'm just to subtle. I certainly didn't mean for VSI to re-
> invent the wheel yet again. I meant that they should [ick up one of
> these existing emulators (SIMH for the VAX) do a port for VMS (if
> it doesn't already exist) and then bundle them with VMS-x86_64.
> IMHO a reasonable alternative to the VEST idea. I am sure any VAX
> emulation will be faster than the fastest hardware VAX ever built.
> Alpha, I couldn't say.

IMH expects to be running operating systems (at least in the VAX
case). It might need substantial changes to its design to provide
only instruction emulation and to simply produce calls to equivalent
x86-64 VMS functions.

If you just mean running a complete VAX/VMS environment, since
x86-64 VMS already runs under a hypervisor it would probably be
better to just run vanilla SIMH as another VM. If VSI ever releases
a "cluster compatibility kit" for VAX/VMS, it could even be a poten-
tially-supported cluster environment.

There is also the issue that some / many (I don't have that info, but
I assume VSI has some idea) VAX customers are still on VAX due
to dependency on [semi-]custom hardware. With the small number
of VMS customers I'm familiar with, VAX -> Alpha was usually "We
can't" while Alpha -> Itanium was "We won't".

On 5/8/2023 6:32 PM, terry-...@glaver.org wrote:

> If you just mean running a complete VAX/VMS environment, since
> x86-64 VMS already runs under a hypervisor it would probably be
> better to just run vanilla SIMH as another VM. If VSI ever releases
> a "cluster compatibility kit" for VAX/VMS, it could even be a poten-
> tially-supported cluster environment.

I can say with a staggeringly high level of confidence that
VSI will *never* release anything for the VAX.

As I've said before, we have the rights to release
a VSI-built version of VAX/VMS, but we won't.

--

--- Rob

On Monday, May 8, 2023 at 7:39:59 PM UTC-4, Robert A. Brooks wrote:
> I can say with a staggeringly high level of confidence that
> VSI will *never* release anything for the VAX.

I'm just going by https://vmssoftware.com/about/v9-qa #12,
"Can I cluster VAX 7.3 with OpenVMS x86?"

I wasn't implying that VSI might produce a whole new VAX/VMS
kit, just that if there's going to be supported clustering, most times
in the past with HPaqital it has usually required a "cluster com-
patibility" kit on the older systems. I seem to remember some of
these being listed as "supported" and some "only as a temporary
migration aid".

Whether such a thing is desirable or practical is only known to
VSI. If some customers are migrating from VAX to x86-64 it could
be useful.

I'm aware that there are finite resources being pulled in several
different directions. As I said in the previous paragraph, VSI is
in the best (only) position to know if this is a good use of those
resources.

On 2023-05-08 00:44, David Turner wrote:
> Like I have always suspected.
> I think there is more of an emulator in the OpenVMS x86 code than has
> been admitted.
> The faster the CPU on the virtualbox the faster your "native X86" code
> is gonna run
> Anyone care to elaborate or prove this?

Wait...

Did you expect the emulated CPU to run at the same speed independent of
the actual CPU speed?

Johnny

>
>
> DT
>
>
> On 5/6/2023 12:49 PM, Craig A. Berry wrote:
>>
>> I am running OpenVMS x86_64 E9.2-1 under VirtualBox 7.0.8 on macOS
>> Ventura 13.3.1 (a).  The host is a 2019 MacBook Pro with 2.3 GHz 8-Core
>> Intel Core i9.  The clock isn't working right, most easily seen by the
>> fact that the following two commands were typed exactly one minute apart:
>>
>> $ sh time
>>    5-MAY-2023 19:07:35
>> $ sh time
>>    5-MAY-2023 19:07:45
>>
>> So the system advances its clock about 10 seconds for every 60 seconds
>> of actual time.
>>
>> Another way of illustrating the problem is by running the vups.com from
>> <https://emuvm.com/download/vups-com-benchmark/>, which says:
>>
>>  Approximate System VUPs Rating : 10430.2 ( min: 950.4 max: 55125.0 )
>>
>> Divide that number by 6 and it might almost be credible based on numbers
>> other people have been posting, though a factor of 10-15 would be more
>> believable.  The system is *not* in fact fast at all -- it takes about
>> 15 seconds for MONITOR SYSTEM to initiate its display when nothing at
>> all is running.
>>
>> I have not seen this anywhere in the VSI documentation, but this blog
>> post:
>>
>> <https://raymii.org/s/blog/OpenVMS_9.2_for_x86_Getting_Started.html>
>>
>> says it's necessary to set the clock characteristics of the virtual
>> machine like so:
>>
>> $ vboxmanage modifyvm <vmname> --hpet on
>>
>> I have done so but observe no difference (everything posted above was
>> after running this command and restarting VirtualBox).  Supposedly this
>> setting "Enables . . . a High Precision Event Timer (HPET) which can
>> replace the legacy system timers," whatever that means. I guess one
>> possibility is that the command, while it returned no errors, also
>> didn't take effect for some reason.  I cannot tell from the following
>> output whether the non-default setting is in effect:
>>
>> $ vboxmanage debugvm <vmname> info hpet
>> HPET status:
>>  config=0000000000000003     isr=0000000000000000
>>  offset=fffffff020435102 counter=0000000000000000 frequency=69841279 fs
>>  legacy-mode=on   timer-count=4
>> Timers:
>>  0: comparator=0000001022973a28 accumulator=0000000000022f4d (9999944 ns)
>>         config=ffffffff0000003c irq=0 en per cap_per cap_64
>>  1: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>>         config=ffffffff00000000 irq=8
>>  2: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>>         config=ffffffff00000000 irq=0
>>  3: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>>         config=ffffffff00000000 irq=0
>>
>>
>> Has anyone sen anything like this or has any ideas on how to debug/fix
>> it?  The only next step I can think of is to try VMWare Player and see
>> if it works better than VirtualBox.
>>
>

On 2023-05-09 01:39, Robert A. Brooks wrote:
> On 5/8/2023 6:32 PM, terry-...@glaver.org wrote:
>
>> If you just mean running a complete VAX/VMS environment, since
>> x86-64 VMS already runs under a hypervisor it would probably be
>> better to just run vanilla SIMH as another VM. If VSI ever releases
>> a "cluster compatibility kit" for VAX/VMS, it could even be a poten-
>> tially-supported cluster environment.
>
> I can say with a staggeringly high level of confidence that
> VSI will *never* release anything for the VAX.
>
> As I've said before, we have the rights to release
> a VSI-built version of VAX/VMS, but we won't.

Fully understood and understandable.

But there is a whole lot of people who wish VSI would just re-release
V7.3 with a VSI stamp on it, so it could be handled for hobbyists.

But I understand that even that is probably too much work to be worth
it. Extremely little return on any work done.

Johnny

On 5/8/2023 8:43 PM, terry-...@glaver.org wrote:
> On Monday, May 8, 2023 at 7:39:59 PM UTC-4, Robert A. Brooks wrote:
>> I can say with a staggeringly high level of confidence that
>> VSI will *never* release anything for the VAX.
>
> I'm just going by https://vmssoftware.com/about/v9-qa #12,
> "Can I cluster VAX 7.3 with OpenVMS x86?"
>
> I wasn't implying that VSI might produce a whole new VAX/VMS
> kit, just that if there's going to be supported clustering, most times
> in the past with HPaqital it has usually required a "cluster com-
> patibility" kit on the older systems. I seem to remember some of
> these being listed as "supported" and some "only as a temporary
> migration aid".
>
> Whether such a thing is desirable or practical is only known to
> VSI. If some customers are migrating from VAX to x86-64 it could
> be useful.
>
> I'm aware that there are finite resources being pulled in several
> different directions. As I said in the previous paragraph, VSI is
> in the best (only) position to know if this is a good use of those
> resources.
>

Ok, here is how I understand the issue ...

VSI is able to release a new VSI VAX/VMS. They choose not to do so. A
reasonable decision. That is not their future.

VSI is not allowed to release anything for DEC/Compaq/HP releases of VMS. I may
not understand correctly, but that seems to be what they have said more than
once. Thus, they cannot legally release a cluster compatibility kit for
VAX/VMS. Unless they issued a new release of VAX/VMS, which most likely will
not happen.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486