On 5/9/2023 8:52 AM, Johnny Billquist wrote:
> 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
>

I can guess that perhaps the biggest technical reason is the lack of old VAX
hardware to test against. A few edits and firing up the build procedure might
be possible. But on what HW do you run the build procedure?

--
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/9/2023 11:52 AM, Dave Froble wrote:
> On 5/9/2023 8:52 AM, Johnny Billquist wrote:
>> 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
>>
>
> I can guess that perhaps the biggest technical reason is the lack of old
> VAX hardware to test against.  A few edits and firing up the build
> procedure might be possible.  But on what HW do you run the build
> procedure?
>

SIMH... :-)

bill

On 2023-05-09 17:49, Dave Froble wrote:
> 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.

That's what I understand as well, and seems to be a reasonable
conclusion. I doubt they'd get any money from such an initiative.

> 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.

That sounds strange. Anyone could release any kind of software for any
VMS version. I doubt HP can say anything about that.

What VSI cannot do is issue licenses for an HPE owned version of VMS,
which is where the VAX issue is stuck.

HPE don't give any more licenses for VMS for VAX, and VSI are not
allowed to for the versions that exist.

VSI could give licenses, if they made a release. But see above...

With regards to the cluster compatibility kit - if such a thing is a
separate product, then I think VSI could very well do that. But I think
it also falls on the same problem - VSI have no interest in doing it. I
doubt they'd make the money back from the work required. So it would
also more be a goodwill thing. But if we want to talk goodwill, a VSI
licensed version of VMS for VAX would most likely generate way more
goodwill.

Johnny

On 2023-05-09 17:52, Dave Froble wrote:
> On 5/9/2023 8:52 AM, Johnny Billquist wrote:
>> 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
>>
>
> I can guess that perhaps the biggest technical reason is the lack of old
> VAX hardware to test against.  A few edits and firing up the build
> procedure might be possible.  But on what HW do you run the build
> procedure?

simh would be perfectly reasonable.

Johnny

On 09/05/2023 17:10, bill wrote:
> On 5/9/2023 11:52 AM, Dave Froble wrote:
>> On 5/9/2023 8:52 AM, Johnny Billquist wrote:
>>> 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
>>>
>>
>> I can guess that perhaps the biggest technical reason is the lack of
>> old VAX hardware to test against.  A few edits and firing up the build
>> procedure might be possible.  But on what HW do you run the build
>> procedure?
>>
>
> SIMH...   :-)
>
> bill
>

Maybe they haven't got a licence PAK?

--
Chris

On 5/9/2023 12:44 PM, Johnny Billquist wrote:
> On 2023-05-09 17:52, Dave Froble wrote:
>> I can guess that perhaps the biggest technical reason is the lack of
>> old VAX hardware to test against.  A few edits and firing up the build
>> procedure might be possible.  But on what HW do you run the build
>> procedure?
>
> simh would be perfectly reasonable.

What about build time?

Arne

On 5/9/2023 6:56 PM, Arne Vajhøj wrote:
> On 5/9/2023 12:44 PM, Johnny Billquist wrote:
>> On 2023-05-09 17:52, Dave Froble wrote:
>>> I can guess that perhaps the biggest technical reason is the lack of old VAX
>>> hardware to test against. A few edits and firing up the build procedure
>>> might be possible. But on what HW do you run the build procedure?
>>
>> simh would be perfectly reasonable.
>
> What about build time?
>
> Arne
>
>

From some past posts, the VAX/VMS build was done on one or more clustered
systems. We don't know of the requirements for an OS build.

As far as time, who cares. If it is to be a one time build for a VSI release,
who is going to care if it takes a month or two? A one time build is all VSI
would need to allow many things, such as hobbyist use, and others.

But, I'm guessing it would not be so simple. None of us knows the requirements
of the build procedure.

--
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/9/2023 11:19 PM, Dave Froble wrote:
> On 5/9/2023 6:56 PM, Arne Vajhøj wrote:
>> On 5/9/2023 12:44 PM, Johnny Billquist wrote:
>>> On 2023-05-09 17:52, Dave Froble wrote:
>>>> I can guess that perhaps the biggest technical reason is the lack of
>>>> old VAX
>>>> hardware to test against.  A few edits and firing up the build
>>>> procedure
>>>> might be possible.  But on what HW do you run the build procedure?
>>>
>>> simh would be perfectly reasonable.
>>
>> What about build time?
>>
>> Arne
>>
>>
>
> From some past posts, the VAX/VMS build was done on one or more
> clustered systems.  We don't know of the requirements for an OS build.
>
> As far as time, who cares.  If it is to be a one time build for a VSI
> release, who is going to care if it takes a month or two?  A one time
> build is all VSI would need to allow many things, such as hobbyist use,
> and others.
>
> But, I'm guessing it would not be so simple.  None of us knows the
> requirements of the build procedure.
>

I'll bet at least one person here knows exactly what the requirements
are and how long it is likely to take. :-)

bill

On 5/10/2023 11:11 AM, bill wrote:
> On 5/9/2023 11:19 PM, Dave Froble wrote:
>> On 5/9/2023 6:56 PM, Arne Vajhøj wrote:
>>> On 5/9/2023 12:44 PM, Johnny Billquist wrote:
>>>> On 2023-05-09 17:52, Dave Froble wrote:
>>>>> I can guess that perhaps the biggest technical reason is the lack
>>>>> of old VAX
>>>>> hardware to test against.  A few edits and firing up the build
>>>>> procedure
>>>>> might be possible.  But on what HW do you run the build procedure?
>>>>
>>>> simh would be perfectly reasonable.
>>>
>>> What about build time?
>>
>>  From some past posts, the VAX/VMS build was done on one or more
>> clustered systems.  We don't know of the requirements for an OS build.
>>
>> As far as time, who cares.  If it is to be a one time build for a VSI
>> release, who is going to care if it takes a month or two?  A one time
>> build is all VSI would need to allow many things, such as hobbyist
>> use, and others.
>>
>> But, I'm guessing it would not be so simple.  None of us knows the
>> requirements of the build procedure.
>
> I'll bet at least one person here knows exactly what the requirements
> are and how long it is likely to take.  :-)

Everyone employed in the VMS group at DEC before Alpha arrived
would know the VAX build process.

Probably more than one. John R, Hoff etc..

I expect it to have taken a long time even on a 8xxx cluster.

I remember late 80's building a single (pretty big) application
EXE taking like an hour. VMS is a lot of EXE files.

Obviously the real HW will matter as well. An 8 core i9 and
SIMH emulating a VAX 6660 and SSD disks may help.

Arne

On 2023-05-09 20:18, Chris Townley wrote:
> On 09/05/2023 17:10, bill wrote:
>> On 5/9/2023 11:52 AM, Dave Froble wrote:
>>> On 5/9/2023 8:52 AM, Johnny Billquist wrote:
>>>> 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
>>>>
>>>
>>> I can guess that perhaps the biggest technical reason is the lack of
>>> old VAX hardware to test against.  A few edits and firing up the
>>> build procedure might be possible.  But on what HW do you run the
>>> build procedure?
>>>
>>
>> SIMH...   :-)
>>
>> bill
>>
>
> Maybe they haven't got a licence PAK?

I assume this was a joke. Because the point was that if they built a new
version, they would be the ones generating the PAK...

Johnny

On 2023-05-10 00:56, Arne Vajhøj wrote:
> On 5/9/2023 12:44 PM, Johnny Billquist wrote:
>> On 2023-05-09 17:52, Dave Froble wrote:
>>> I can guess that perhaps the biggest technical reason is the lack of
>>> old VAX hardware to test against.  A few edits and firing up the
>>> build procedure might be possible.  But on what HW do you run the
>>> build procedure?
>>
>> simh would be perfectly reasonable.
>
> What about build time?

Probably a fraction of what it took 20 years ago. Assuming it can be
done without having every model of a VAX available for building.
simh only simulates a subset of existing VAXen. But it moves on very
fast compared to any VAX of old... Hardware have just become so much
faster...

Johnny

On Wednesday, May 10, 2023 at 11:56:16 AM UTC-4, Johnny Billquist wrote:
> On 2023-05-10 00:56, Arne Vajhøj wrote:
> > On 5/9/2023 12:44 PM, Johnny Billquist wrote:
> >> On 2023-05-09 17:52, Dave Froble wrote:
> >>> I can guess that perhaps the biggest technical reason is the lack of
> >>> old VAX hardware to test against. A few edits and firing up the
> >>> build procedure might be possible. But on what HW do you run the
> >>> build procedure?
> >>
> >> simh would be perfectly reasonable.
> >
> > What about build time?
> Probably a fraction of what it took 20 years ago. Assuming it can be
> done without having every model of a VAX available for building.
> simh only simulates a subset of existing VAXen. But it moves on very
> fast compared to any VAX of old... Hardware have just become so much
> faster...
>
> Johnny
This is correct. I still have my VAX 3800 and using the Charon emulator on a 2,4Ghz box, the emulator blows away the "real" hardware in performance.
OpenVMS V5.5-2 used in both cases.

Dan

The last type of VAX system that we used to build VAX VMS was a VAX 7600 (6 cpu), w/maximum memory, etc. (it was named SOXFAN for all your Red Sox fans out there)

As I recall a VMS O/S build didn't take terribly long (couple of hours, I think...the 7600 was a screamer)

On Wednesday, May 10, 2023 at 2:05:43 PM UTC-4, Bob Wilson wrote:
> The last type of VAX system that we used to build VAX VMS was a VAX 7600 (6 cpu), w/maximum memory, etc. (it was named SOXFAN for all your Red Sox fans out there)
>
> As I recall a VMS O/S build didn't take terribly long (couple of hours, I think...the 7600 was a screamer)

Part of the VMS lore I remember is that the 782 had just enough horsepower to build the OS (much
smaller back then) over night..

On 5/11/2023 7:28 AM, David Jones wrote:
> On Wednesday, May 10, 2023 at 2:05:43 PM UTC-4, Bob Wilson wrote:
>> The last type of VAX system that we used to build VAX VMS was a VAX 7600 (6 cpu), w/maximum memory, etc. (it was named SOXFAN for all your Red Sox fans out there)
>>
>> As I recall a VMS O/S build didn't take terribly long (couple of hours, I think...the 7600 was a screamer)
>
> Part of the VMS lore I remember is that the 782 had just enough horsepower to build the OS (much
> smaller back then) over night..

Unless, of course, someone was running the Ada Compiler. Then it could
easily take a month. :-)

bill

On Thu, 2023-05-11 at 08:10 -0400, bill wrote:
> On 5/11/2023 7:28 AM, David Jones wrote:
> > On Wednesday, May 10, 2023 at 2:05:43 PM UTC-4, Bob Wilson wrote:
> > > The last type of VAX system that we used to build VAX VMS was a
> > > VAX 7600 (6 cpu), w/maximum memory, etc. (it was named SOXFAN for
> > > all your Red Sox fans out there)
> > >
> > > As I recall a VMS O/S build didn't take terribly long (couple of
> > > hours, I think...the 7600 was a screamer)
> >
> > Part of the VMS lore I remember is that the 782 had just enough
> > horsepower to build the OS (much
> > smaller back then) over night..
>
> Unless, of course, someone was running the Ada Compiler. Then it
> could easily take a month.  :-)

Now it probably takes a few mins on a threadripper :-D
--
Tactical Nuclear Kittens

On Saturday, May 6, 2023 at 9:49:43 AM UTC-7, 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
I haven't thought about this recently.

As well as I know it, many OS were designed to know about emulators,
and virtual machines, and virtual machines to know about client systems.

The OS should be able to request the right time from VirtualBox.

IBM used to develop new OS running under VM/CMS, so they had to
figure out that early. I suspect it is not unusual to develop OS now
using virtualization.

It might be, though, that someone hasn't gotten around to that one.

Note that IBM S/360 and successors have a convenience for emulation.
OS enter a wait state, when there isn't anything else to do. They stop executing
instructions, and so there is no idle process.

That goes back to the days when hardware was rented, and rental depended
on how much it was used. That is, it would stop charging when the system
stopped executing instructions.

Many emulators and hypervisors recognize the idle loop, though.

How does VMS keep track of time?

On 5/11/2023 7:02 PM, gah4 wrote:
> How does VMS keep track of time?

According to IDSM then it reads time from the HW clock
at boot and then update it N (N >= 1000) times per
second at IPL 22.

Arne

On Thursday, May 11, 2023 at 4:42:06 PM UTC-7, Arne Vajhøj wrote:
> On 5/11/2023 7:02 PM, gah4 wrote:
> > How does VMS keep track of time?

> According to IDSM then it reads time from the HW clock
> at boot and then update it N (N >= 1000) times per
> second at IPL 22.
So, for all architectures?

https://www.digiater.nl/openvms/freeware/v60/vmsfaq/vmsfaq_004.html

On Saturday, May 6, 2023 at 9:49:43 AM UTC-7, 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:

If you Google for virtualbox clock, there are over 15 million hits.
(That is, for all guest OS.)

I didn't follow all of them, but it does seem that the ones that work have
guest OS that know how to ask VB about the clock, instead of using
the usual one.

Den 2023-05-12 kl. 03:49, skrev gah4:
> On Saturday, May 6, 2023 at 9:49:43 AM UTC-7, 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:
>
>
> If you Google for virtualbox clock, there are over 15 million hits.
> (That is, for all guest OS.)
>
> I didn't follow all of them, but it does seem that the ones that work have
> guest OS that know how to ask VB about the clock, instead of using
> the usual one.
>

Actually, that was how I thought it worked. Since I observed that
the clock in my VirtualBox VMS environment lagge a bit behind
but each 10-20 sec, it jumpt ahead and skipped a second so that
it become in sync with the host Windows environment again.

I do not understand how VMS "knows" to jump a second ahead in
any other way then to ask some other environment. No NNTP here...

Den 2023-05-12 kl. 09:51, skrev Jan-Erik Söderholm:
> Den 2023-05-12 kl. 03:49, skrev gah4:
>> On Saturday, May 6, 2023 at 9:49:43 AM UTC-7, 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:
>>
>>
>> If you Google for virtualbox clock, there are over 15 million hits.
>> (That is, for all guest OS.)
>>
>> I didn't follow all of them, but it does seem that the ones that work have
>> guest OS that know how to ask VB about the clock, instead of using
>> the usual one.
>>
>
> Actually, that was how I thought it worked. Since I observed that
> the clock in my VirtualBox VMS environment lagge a bit behind
> but each 10-20 sec, it jumpt ahead and skipped a second so that
> it become in sync with the host Windows environment again.
>
> I do not understand how VMS "knows" to jump a second ahead in
> any other way then to ask some other environment. No NNTP here...

Btw, and I might have missed some posts, but do we have more then one
report of the VMS clock showing the wrong time?

On 2023-05-12 01:02, gah4 wrote:
> On Saturday, May 6, 2023 at 9:49:43 AM UTC-7, 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
>
> I haven't thought about this recently.
>
> As well as I know it, many OS were designed to know about emulators,
> and virtual machines, and virtual machines to know about client systems.
>
> The OS should be able to request the right time from VirtualBox.

That is something you could/would do at boot time to get initial time,
but not after that.
During normal operation, most OSes uses a clock interrupt at a known
frequency, and this is in turn used to update the wall clock in the OS.
There are some tickless operating systems - mostly embedded RTOS stuff
where you want to reduce power consumption, but otherwise this is how
you normally do stuff, since you want to schedule all kind of things
based on time, and it would make no sense to have a VM go out and read
the host time hundreds of times per second as a way of just polling to
get time.

But here is where and why you can observe time drift. In real hardware,
this clock interrupt is very regular and reliable. In an emulator, you
are exposed to the timing variations caused by the scheduling of the VM
itself, which means you cannot deliver clock interrupts anywhere near at
the same level of accuracy as hardware can.

VMs thus usually try to detect drift over time, and compensate by
fielding extra clock interrupts to "catch up", so that over a longer
period, you still have the correct number of interrupts happening. But
this is a bit tricky, and VMs sometimes don't do this perfectly.

But it should normally only expose small variations in the clock
compared to a proper wall clock.

If you see a much slower progress of time (or faster) than the wall
clock, then the VM is probably generating clock interrupts at a
different frequency than the OS is expecting.

> Note that IBM S/360 and successors have a convenience for emulation.
> OS enter a wait state, when there isn't anything else to do. They stop executing
> instructions, and so there is no idle process.

Well, there usually still is an idle process, or loop, but it's not
doing a busy-wait spin loop.

> Many emulators and hypervisors recognize the idle loop, though.
>
> How does VMS keep track of time?

Same as pretty much anything else. You have a clock interrupt at a
regular interval and the OS counts time based on that.

VMS started off on the VAX, however, and that architecture do not have a
WAIT instruction, so at idle, the processor is really just spinning.
Not sure if that was amended on Alpha or later.

But a WAIT is commonly only stopping the processor until something
happens, which usually is an interrupt. If there is still nothing to do
after the interrupt handler finish, the processor would loop back to the
WAIT again.

simh (for example) do detect the idle loop in VMS (on VAX), and pause
execution if it detects this loop, to let the host rest.

Johnny

On 2023-05-12 09:51, Jan-Erik Söderholm wrote:
> Den 2023-05-12 kl. 03:49, skrev gah4:
>> On Saturday, May 6, 2023 at 9:49:43 AM UTC-7, 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:
>>
>>
>> If you Google for virtualbox clock, there are over 15 million hits.
>> (That is, for all guest OS.)
>>
>> I didn't follow all of them, but it does seem that the ones that work
>> have
>> guest OS that know how to ask VB about the clock, instead of using
>> the usual one.
>>
>
> Actually, that was how I thought it worked. Since I observed that
> the clock in my VirtualBox VMS environment lagge a bit behind
> but each 10-20 sec, it jumpt ahead and skipped a second so that
> it become in sync with the host Windows environment again.
>
> I do not understand how VMS "knows" to jump a second ahead in
> any other way then to ask some other environment. No NNTP here...

VMS don't know. And no, it is also not querying VirtualBox as such.
There is a defined RTC in the architecture and/or platform, which can be
queried. Be that on real hardware or emulation. And this is used to find
out the time at boot.

VirtualBox of course knows the time in the host, and it just transfers
this information over to the emulated machine via this simulated RTC.

As for how VMS "jumps", it's pretty simple. VMS advances the clock at
ever clock interrupt. The emulated environment knows how many clock
interrupts have been fielded, and how many should have been fielded, and
compensates by fielding extra interrupts if needed, to catch up. All of
that is done in VirtualBox, and VMS have no clue.

Johnny

On Friday, May 12, 2023 at 2:56:13 AM UTC-7, Johnny Billquist wrote:

(snip, I wrote)

> > How does VMS keep track of time?

> Same as pretty much anything else. You have a clock interrupt at a
> regular interval and the OS counts time based on that.
> VMS started off on the VAX, however, and that architecture do not have a
> WAIT instruction, so at idle, the processor is really just spinning.
> Not sure if that was amended on Alpha or later.
> But a WAIT is commonly only stopping the processor until something
> happens, which usually is an interrupt. If there is still nothing to do
> after the interrupt handler finish, the processor would loop back to the
> WAIT again.
Yes. On the other hand, when the OS gives up, usually at IPL time when
something fails, there is disabled WAIT state. That is, no interrupts
enabled, in which case it stops.

> simh (for example) do detect the idle loop in VMS (on VAX), and pause
> execution if it detects this loop, to let the host rest.
Some put a special instruction in the loop to make it easier for emulators.

There are two time related things that OS need to do. One is tell what
time of day, month, year, it is. The other is task switching, and any other
short time related events.

IBM S/360 uses the same system for both, as you describe.

But S/370 adds a TOD clock, which keeps track of time, and a separate
system for non TOD related timing. One complication with the TOD clock
in Y2K days, is that access is not privileged, such that it can't be emulated
by VM. So, VM/370 and successor guests read the hardware TOD clock.
But other timing uses a different timer which is emulated.

So, some VirtualBox guests have a special way to get the host clock for
TOD functions, but the interrupt clock for others. Saves a lot of work
keeping two clocks synchronized.