As an almost daily user of the EISNER:: node of DECUServe,
I began to wonder: Couldn't DECUServe serve as a cost-
effective method for VSI to demonstrate both OpenVMS for
x86-64 and its cross-architecture clustering capabilities
to a wider audience? Since VSI operates this physical
hardware and adding a modestly configured x86-64 virtual
machine would probably not add too much to the existing
operating and maintenance costs of DECUServe.

It could thereby also save a lot of potentially interested
users the time and effort of having to apply for a suitable
evaluation license and having to prepare, install and
configure a (virtual) system, especially those who are
entirely new and unfamiliar to OpenVMS and simply wish to
have an end-user experience.

It's been long since a capable public access VMScluster
system has been available (especially since "Deathrow"
shut down, already quite some years ago).

I realize that I could have posted this in the DEC Notes
of EISNER, but it doesn't appear to be very actively used
these days.

- MG

On 2023-05-31, MG <em_geeNO@SPAMxs4all.nl> wrote:
> As an almost daily user of the EISNER:: node of DECUServe,
> I began to wonder: Couldn't DECUServe serve as a cost-
> effective method for VSI to demonstrate both OpenVMS for
> x86-64 and its cross-architecture clustering capabilities
> to a wider audience? Since VSI operates this physical
> hardware and adding a modestly configured x86-64 virtual
> machine would probably not add too much to the existing
> operating and maintenance costs of DECUServe.
>
> It could thereby also save a lot of potentially interested
> users the time and effort of having to apply for a suitable
> evaluation license and having to prepare, install and
> configure a (virtual) system, especially those who are
> entirely new and unfamiliar to OpenVMS and simply wish to
> have an end-user experience.
>
> It's been long since a capable public access VMScluster
> system has been available (especially since "Deathrow"
> shut down, already quite some years ago).
>
> I realize that I could have posted this in the DEC Notes
> of EISNER, but it doesn't appear to be very actively used
> these days.
>

I suspect that a lot more people read Notes than post to it,
so I suspect your message would have been read by a lot more people
than it would first appear.

BTW, I also suspect there are a lot more people _reading_ comp.os.vms
than posting to it.

As for your proposal, I think it's a good idea. There would have to
be some restrictions (for example, no security research on what would
be a public server[*] unless VSI explicitly authorise this and researchers
stay within the constraints imposed in advance by VSI), but it would be
a really good way of allowing people to easily try out the x86-64 versions
of the layered products.

[*] When doing security research, it's really the kind of thing that
should be done on your own equipment running your own operating system
instances when possible.

Simon.

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

Den 2023-05-31 kl. 14:17, skrev Simon Clubley:
> On 2023-05-31, MG <em_geeNO@SPAMxs4all.nl> wrote:
>> As an almost daily user of the EISNER:: node of DECUServe,
>> I began to wonder: Couldn't DECUServe serve as a cost-
>> effective method for VSI to demonstrate both OpenVMS for
>> x86-64 and its cross-architecture clustering capabilities
>> to a wider audience? Since VSI operates this physical
>> hardware and adding a modestly configured x86-64 virtual
>> machine would probably not add too much to the existing
>> operating and maintenance costs of DECUServe.
>>
>> It could thereby also save a lot of potentially interested
>> users the time and effort of having to apply for a suitable
>> evaluation license and having to prepare, install and
>> configure a (virtual) system, especially those who are
>> entirely new and unfamiliar to OpenVMS and simply wish to
>> have an end-user experience.
>>
>> It's been long since a capable public access VMScluster
>> system has been available (especially since "Deathrow"
>> shut down, already quite some years ago).
>>
>> I realize that I could have posted this in the DEC Notes
>> of EISNER, but it doesn't appear to be very actively used
>> these days.
>>
>
> I suspect that a lot more people read Notes than post to it,
> so I suspect your message would have been read by a lot more people
> than it would first appear.
>
> BTW, I also suspect there are a lot more people _reading_ comp.os.vms
> than posting to it.

Even better would probably be to use the offical VSI forum.
https://forum.vmssoftware.com/

That is where the future is and where VSI replies.

On 2023-05-31, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>
> Even better would probably be to use the offical VSI forum.
> https://forum.vmssoftware.com/
>
> That is where the future is and where VSI replies.

VSI seem to be very hit-and-miss about whether they reply to forum
postings or not.

For example, I see they never replied to Mark's questions and
observations about excessive kernel mode overhead, which he asked
a full month ago. :-(

Simon.

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

On Wednesday, May 31, 2023 at 9:01:15 AM UTC-4, Simon Clubley wrote:
> On 2023-05-31, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
> >
> > Even better would probably be to use the offical VSI forum.
> > https://forum.vmssoftware.com/
> >
> > That is where the future is and where VSI replies.
> VSI seem to be very hit-and-miss about whether they reply to forum
> postings or not.
>
> For example, I see they never replied to Mark's questions and
> observations about excessive kernel mode overhead, which he asked
> a full month ago. :-(
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
I missed those questions from Mark (and I couldn't easily find them),
but the forums are not an official support channel (even with frowny faces)

John

Den 2023-05-31 kl. 15:45, skrev John Reagan:
> On Wednesday, May 31, 2023 at 9:01:15 AM UTC-4, Simon Clubley wrote:
>> On 2023-05-31, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>>
>>> Even better would probably be to use the offical VSI forum.
>>> https://forum.vmssoftware.com/
>>>
>>> That is where the future is and where VSI replies.
>> VSI seem to be very hit-and-miss about whether they reply to forum
>> postings or not.
>>
>> For example, I see they never replied to Mark's questions and
>> observations about excessive kernel mode overhead, which he asked
>> a full month ago. :-(
>> Simon.
>>
>> --
>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>> Walking destinations on a map are further away than they appear.
> I missed those questions from Mark (and I couldn't easily find them),
> but the forums are not an official support channel (even with frowny faces)
>
> John

The main point is that a forum in that form is more of what any
modern IT techie expect from a forum. Usenet is dying.

I was not sayng that you'd get better answers there or such.
Just that it is where we want OpenVMS to belong, the "future".

And Marks findings was some interesting observations, but not
much that can be said about that, with the current build
methods and general lack of detail refinement, I guess...

On Wednesday, May 31, 2023 at 9:51:23 AM UTC-4, Jan-Erik Söderholm wrote:
> Den 2023-05-31 kl. 15:45, skrev John Reagan:
> > On Wednesday, May 31, 2023 at 9:01:15 AM UTC-4, Simon Clubley wrote:
> >> On 2023-05-31, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
> >>>
> >>> Even better would probably be to use the offical VSI forum.
> >>> https://forum.vmssoftware.com/
> >>>
> >>> That is where the future is and where VSI replies.
> >> VSI seem to be very hit-and-miss about whether they reply to forum
> >> postings or not.
> >>
> >> For example, I see they never replied to Mark's questions and
> >> observations about excessive kernel mode overhead, which he asked
> >> a full month ago. :-(
> >> Simon.
> >>
> >> --
> >> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> >> Walking destinations on a map are further away than they appear.
> > I missed those questions from Mark (and I couldn't easily find them),
> > but the forums are not an official support channel (even with frowny faces)
> >
> > John
> The main point is that a forum in that form is more of what any
> modern IT techie expect from a forum. Usenet is dying.
>
> I was not sayng that you'd get better answers there or such.
> Just that it is where we want OpenVMS to belong, the "future".
>
> And Marks findings was some interesting observations, but not
> much that can be said about that, with the current build
> methods and general lack of detail refinement, I guess...

Given that is has been stated that the code is not optimized yes, I care nothing about any type of performance data at the moment other than a worksdoesn't work type of test. The performance effort will come later.

Dan

On 2023-05-31, John Reagan <xyzzy1959@gmail.com> wrote:
> I missed those questions from Mark (and I couldn't easily find them),
> but the forums are not an official support channel (even with frowny faces)
>

https://forum.vmssoftware.com/viewtopic.php?f=21&t=8654

Your management keep pushing community people towards the forums, along
with promises that people from VSI will review the issues raised there
on a regular basis.

Simon.

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

On 2023-05-31, abrsvc <dansabrservices@yahoo.com> wrote:
>
> Given that is has been stated that the code is not optimized yes, I care nothing about any type of performance data at the moment other than a worksdoesn't work type of test. The performance effort will come later.
>

You should Dan, because there are performance issues and then there
are performance issues.

It would be nice to get an indication from VSI whether the issues are
related to poor compiler code (which should be easily fixable hopefully)
or whether it is due to some architecture or design limitation, which is
not so easily fixed.

Given the problem as described, it could be either one of those two,
or a combination of both. I am having a hard time however seeing how poor
compiler code by itself could be having such a dramatic impact on this
type of kernel code.

Simon.

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

On Wednesday, May 31, 2023 at 1:23:02 PM UTC-4, Simon Clubley wrote:
> On 2023-05-31, abrsvc <dansabr...@yahoo.com> wrote:
> >
> > Given that is has been stated that the code is not optimized yes, I care nothing about any type of performance data at the moment other than a worksdoesn't work type of test. The performance effort will come later.
> >
> You should Dan, because there are performance issues and then there
> are performance issues.
>
> It would be nice to get an indication from VSI whether the issues are
> related to poor compiler code (which should be easily fixable hopefully)
> or whether it is due to some architecture or design limitation, which is
> not so easily fixed.
>
> Given the problem as described, it could be either one of those two,
> or a combination of both. I am having a hard time however seeing how poor
> compiler code by itself could be having such a dramatic impact on this
> type of kernel code.
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
I briefly skimmed the data (there is a lot of it). And I'm not an expert in this
area of the system.

Compiler optimizers rarely eliminate call frames (other than doing inline
expansion but that doesn't make the work go away). Call/return overhead
on x86 is very fast (think like JSB/RET on VAX or JSR/RET on Alpha).

Other than the shuffling of PTEs that everybody is focusing on, I'll point out
that x86 does not provide a hardware 'probe' instruction. If you want to use
'probe' to confirm access to any address, the OS (any OS, not just OpenVMS)
has to crawl around in the page tables to find the final PTE to check the access
flags. With 4K pages, those PTEs can be 4 or even 5 level deep.

We are very much aware that 'probe' can be pain and deep page table entries..
Using large hardware page sizes can reduce the depth of the page table structures
but might require code inspection. Reducing or eliminating probes can help as well.
The old theory was to probe always to avoid an exception rarely. For x86 perhaps
it might be better to skip probes but be ready to handle the rare exceptions?
An optimizer might "tighten" up the probe code but at the end of the day, there are
lots of pointers to follow and protection masks to extract and compare.

Another addition to the system (and related to that exe$random_harvest_direct seen
on some of the stack frames) is harvesting entropy at some interval.

On 5/31/2023 7:41 AM, MG wrote:
> As an almost daily user of the EISNER:: node of DECUServe,
> I began to wonder: Couldn't DECUServe serve as a cost-
> effective method for VSI to demonstrate both OpenVMS for
> x86-64 and its cross-architecture clustering capabilities
> to a wider audience?  Since VSI operates this physical
> hardware and adding a modestly configured x86-64 virtual
> machine would probably not add too much to the existing
> operating and maintenance costs of DECUServe.
>
> It could thereby also save a lot of potentially interested
> users the time and effort of having to apply for a suitable
> evaluation license and having to prepare, install and
> configure a (virtual) system, especially those who are
> entirely new and unfamiliar to OpenVMS and simply wish to
> have an end-user experience.
>
> It's been long since a capable public access VMScluster
> system has been available (especially since "Deathrow"
> shut down, already quite some years ago).

The totally new to VMS just wanting to try a few DCL commands
probably do not care what architecture they are running on - most
likely they will not even know. VMS is VMS.

But setting up a mixed mode cluster would be a pretty cool
demo.

And why not go all out? VAX + Alpha + Itanium + x86-64!!

Send a news flash to all IT magazines in the world and get
a bit of press.

Arne

On 31-May-2023 21:34, Arne Vajhøj wrote:
> The totally new to VMS just wanting to try a few DCL commands
> probably do not care what architecture they are running on - most
> likely they will not even know. VMS is VMS.

On what other platform can one run "a few DCL commands"?

> And why not go all out? VAX + Alpha + Itanium + x86-64!!

Electricity and other maintenance costs...? To just name
a few things (as I also mentioned in my original message).

- MG

On 5/31/2023 3:43 PM, MG wrote:
> On 31-May-2023 21:34, Arne Vajhøj wrote:
>> The totally new to VMS just wanting to try a few DCL commands
>> probably do not care what architecture they are running on - most
>> likely they will not even know. VMS is VMS.
>
> On what other platform can one run "a few DCL commands"?

????

VMS runs on 4 (instruction set) architectures: VAX, Alpha, Itanium
and x86-64.

And for those wanting to try DCL then I don't think it matters
which.

>> And why not go all out? VAX + Alpha + Itanium + x86-64!!
>
> Electricity and other maintenance costs...?  To just name
> a few things (as I also mentioned in my original message).

Everything cost.

But I think the PR value would be worth the electricity and
more.

Arne

On 31-May-2023 21:47, Arne Vajhøj wrote:
>> On what other platform can one run "a few DCL commands"?
>
> ????

Well, I was wondering, too, because beyond these as you mention
here...
> VMS runs on 4 (instruction set) architectures: VAX, Alpha,
> Itanium and x86-64.

.... I know none. (And thank you for mentioning these, because
this is surely very 'esoteric' information!)

> And for those wanting to try DCL then I don't think it
> matters which.

Maybe enough interested people don't want to worry about
that and simply would like the option of registering and
logging onto a fully installed and configured remote
system...?

- MG

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj via
> Info-vax
> Sent: Wednesday, May 31, 2023 4:34 PM
> To: info-vax@rbnsn.com
> Cc: Arne Vajhøj <arne@vajhoej.dk>
> Subject: Re: [Info-vax] Time to turn DECUServe into a mixed VMScluster?
>
> On 5/31/2023 7:41 AM, MG wrote:
> > As an almost daily user of the EISNER:: node of DECUServe, I began to
> > wonder: Couldn't DECUServe serve as a cost- effective method for VSI
> > to demonstrate both OpenVMS for
> > x86-64 and its cross-architecture clustering capabilities to a wider
> > audience? Since VSI operates this physical hardware and adding a
> > modestly configured x86-64 virtual machine would probably not add too
> > much to the existing operating and maintenance costs of DECUServe.
> >
> > It could thereby also save a lot of potentially interested users the
> > time and effort of having to apply for a suitable evaluation license
> > and having to prepare, install and configure a (virtual) system,
> > especially those who are entirely new and unfamiliar to OpenVMS and
> > simply wish to have an end-user experience.
> >
> > It's been long since a capable public access VMScluster system has
> > been available (especially since "Deathrow"
> > shut down, already quite some years ago).
>
> The totally new to VMS just wanting to try a few DCL commands probably do
> not care what architecture they are running on - most likely they will not even
> know. VMS is VMS.
>
> But setting up a mixed mode cluster would be a pretty cool demo.
>
> And why not go all out? VAX + Alpha + Itanium + x86-64!!
>
> Send a news flash to all IT magazines in the world and get a bit of press.
>
> Arne
>

Well, its an interesting idea as I have a Vax/Alpha/IA64 lab cluster (ok, in stand mode right now, but were previously part of a cluster)

Fully not supported, but a 4 different HW arch cluster would be a nice thing to showcase for bragging rights - 4 different HW arch's running in same single OS cluster.

Q for the VSI folks - is there anything embedded in the code that would prevent a VAX 32bit server from joining a AX64/IA64/X86 64bit cluster?

😊

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 31-May-2023 14:17, Simon Clubley wrote:
> I suspect that a lot more people read Notes than post to it,
> so I suspect your message would have been read by a lot more people
> than it would first appear.

Going by "Last new note", there appears to be nothing more 'recent'
than 18-MAR-2021...

Michael Brown's VAXforumII, however, has seen some activity lately.
For those interested with DECUServe accounts, give it a try:

$ RUN DISK_USER:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM

- MG

On 5/31/2023 3:40 PM, MG wrote:
> On 31-May-2023 14:17, Simon Clubley wrote:
>> I suspect that a lot more people read Notes than post to it,
>> so I suspect your message would have been read by a lot more people
>> than it would first appear.
>
> Going by "Last new note", there appears to be nothing more 'recent'
> than 18-MAR-2021...
>
> Michael Brown's VAXforumII, however, has seen some activity lately.
> For those interested with DECUServe accounts, give it a try:
>
>   $ RUN DISK_USER:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM
>
>  - MG
>

$ RUN DISK_USER:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM
%DCL-W-ACTIMAGE, error activating image DISK_USER
[DECUSERVE_USER.BROWN_MI.SHARE
..BIN]FORUM
-CLI-E-IMGNAME, image file
DSA3:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM.EXE;
-RMS-E-PRV, insufficient privilege or file protection violation

On 5/31/2023 4:23 PM, kemain.nospam@gmail.com wrote:
>
>
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj via
>> Info-vax
>> Sent: Wednesday, May 31, 2023 4:34 PM
>> To: info-vax@rbnsn.com
>> Cc: Arne Vajhøj <arne@vajhoej.dk>
>> Subject: Re: [Info-vax] Time to turn DECUServe into a mixed VMScluster?
>>
>> On 5/31/2023 7:41 AM, MG wrote:
>>> As an almost daily user of the EISNER:: node of DECUServe, I began to
>>> wonder: Couldn't DECUServe serve as a cost- effective method for VSI
>>> to demonstrate both OpenVMS for
>>> x86-64 and its cross-architecture clustering capabilities to a wider
>>> audience? Since VSI operates this physical hardware and adding a
>>> modestly configured x86-64 virtual machine would probably not add too
>>> much to the existing operating and maintenance costs of DECUServe.
>>>
>>> It could thereby also save a lot of potentially interested users the
>>> time and effort of having to apply for a suitable evaluation license
>>> and having to prepare, install and configure a (virtual) system,
>>> especially those who are entirely new and unfamiliar to OpenVMS and
>>> simply wish to have an end-user experience.
>>>
>>> It's been long since a capable public access VMScluster system has
>>> been available (especially since "Deathrow"
>>> shut down, already quite some years ago).
>>
>> The totally new to VMS just wanting to try a few DCL commands probably do
>> not care what architecture they are running on - most likely they will not even
>> know. VMS is VMS.
>>
>> But setting up a mixed mode cluster would be a pretty cool demo.
>>
>> And why not go all out? VAX + Alpha + Itanium + x86-64!!
>>
>> Send a news flash to all IT magazines in the world and get a bit of press.
>>
>> Arne
>>
>
> Well, its an interesting idea as I have a Vax/Alpha/IA64 lab cluster (ok, in stand mode right now, but were previously part of a cluster)
>
> Fully not supported, but a 4 different HW arch cluster would be a nice thing to showcase for bragging rights - 4 different HW arch's running in same single OS cluster.
>
> Q for the VSI folks - is there anything embedded in the code that would prevent a VAX 32bit server from joining a AX64/IA64/X86 64bit cluster?
>

If my feeble memory still works, I think that has already been answered.

x86 cluster communications will be modified, and to include Alpha and/or itanic,
a patch for either will be required. No patches for VAX, since VSI does not
have a VAX release to which patches can be provided.

--
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 1-Jun-2023 00:26, Lee Gleason wrote:
> On 5/31/2023 3:40 PM, MG wrote:
>> Michael Brown's VAXforumII, however, has seen some activity lately.
>> For those interested with DECUServe accounts, give it a try:
>>
>>    $ RUN DISK_USER:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM
>
> $ RUN DISK_USER:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM
> %DCL-W-ACTIMAGE, error activating image DISK_USER
> [DECUSERVE_USER.BROWN_MI.SHARE
> .BIN]FORUM
> -CLI-E-IMGNAME, image file
> DSA3:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM.EXE;
> -RMS-E-PRV, insufficient privilege or file protection violation

Strange, it works for me. Here's some additional information:
-------------------------------------[SOF]-------------------------------------
SYS$LOGIN:$ SHOW SYMBOL VAXFORUM
VAXF*ORUM == "RUN DISK_USER:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM"
SYS$LOGIN:$ DIRECTORY /SECURITY
DISK_USER:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM.EXE

Directory DSA3:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]

FORUM.EXE;124 [BROWN_MI] (RWED,RWED,RE,)

Total of 1 file.
-------------------------------------[EOF]-------------------------------------

Is it possible that your SYS$LOGIN: has different security
attributes set?

- MG

On 01/06/2023 00:00, MG wrote:
> On 1-Jun-2023 00:26, Lee Gleason wrote:
>> On 5/31/2023 3:40 PM, MG wrote:
>>> Michael Brown's VAXforumII, however, has seen some activity lately.
>>> For those interested with DECUServe accounts, give it a try:
>>>
>>>    $ RUN DISK_USER:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM
>>
>> $ RUN DISK_USER:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM
>> %DCL-W-ACTIMAGE, error activating image DISK_USER
>> [DECUSERVE_USER.BROWN_MI.SHARE
>> .BIN]FORUM
>> -CLI-E-IMGNAME, image file
>> DSA3:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM.EXE;
>> -RMS-E-PRV, insufficient privilege or file protection violation
>
> Strange, it works for me.  Here's some additional information:
> -------------------------------------[SOF]-------------------------------------
> SYS$LOGIN:$ SHOW SYMBOL VAXFORUM
>   VAXF*ORUM == "RUN DISK_USER:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM"
> SYS$LOGIN:$ DIRECTORY /SECURITY
> DISK_USER:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]FORUM.EXE
>
> Directory DSA3:[DECUSERVE_USER.BROWN_MI.SHARE.BIN]
>
> FORUM.EXE;124        [BROWN_MI]                       (RWED,RWED,RE,)
>
> Total of 1 file.
> -------------------------------------[EOF]-------------------------------------
>
> Is it possible that your SYS$LOGIN: has different security
> attributes set?
>
>  - MG
>
Above shows that you own it, so not surprising that you can run it, but
no world access...

--
Chris

In article <nnd$6f0d1a96$39b9159a@34e78233e2c9d371>,
MG <em_geeNO@SPAMxs4all.nl> wrote:
>On 31-May-2023 21:34, Arne Vajhøj wrote:
>> The totally new to VMS just wanting to try a few DCL commands
>> probably do not care what architecture they are running on - most
>> likely they will not even know. VMS is VMS.
>
>On what other platform can one run "a few DCL commands"?

VAX. The future is VAX. Digital has it now!
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 1-Jun-2023 01:08, Chris Townley wrote:
> Above shows that you own it, so not surprising that you can run it, but
> no world access...

Incorrect, user BROWN_MI (Michael Brown) owns it, I have read and
execute access as a fellow group (i.e. DECUServe user group) member.
I originally found out about VAXforumII by seeing it mentioned in
Michael Brown's PLAN.TXT file.

- MG

On 5/31/2023 1:23 PM, kemain.nospam@gmail.com wrote:
>
>
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj via
>> Info-vax
>> Sent: Wednesday, May 31, 2023 4:34 PM
>> To: info-vax@rbnsn.com
>> Cc: Arne Vajhøj <arne@vajhoej.dk>
>> Subject: Re: [Info-vax] Time to turn DECUServe into a mixed VMScluster?
>>
>> On 5/31/2023 7:41 AM, MG wrote:
>>> As an almost daily user of the EISNER:: node of DECUServe, I began to
>>> wonder: Couldn't DECUServe serve as a cost- effective method for VSI
>>> to demonstrate both OpenVMS for
>>> x86-64 and its cross-architecture clustering capabilities to a wider
>>> audience? Since VSI operates this physical hardware and adding a
>>> modestly configured x86-64 virtual machine would probably not add too
>>> much to the existing operating and maintenance costs of DECUServe.
>>>
>>> It could thereby also save a lot of potentially interested users the
>>> time and effort of having to apply for a suitable evaluation license
>>> and having to prepare, install and configure a (virtual) system,
>>> especially those who are entirely new and unfamiliar to OpenVMS and
>>> simply wish to have an end-user experience.
>>>
>>> It's been long since a capable public access VMScluster system has
>>> been available (especially since "Deathrow"
>>> shut down, already quite some years ago).
>>
>> The totally new to VMS just wanting to try a few DCL commands probably do
>> not care what architecture they are running on - most likely they will not even
>> know. VMS is VMS.
>>
>> But setting up a mixed mode cluster would be a pretty cool demo.
>>
>> And why not go all out? VAX + Alpha + Itanium + x86-64!!
>>
>> Send a news flash to all IT magazines in the world and get a bit of press.
>
> Well, its an interesting idea as I have a Vax/Alpha/IA64 lab cluster
> (ok, in stand mode right now, but were previously part of a cluster)
>
> Fully not supported, but a 4 different HW arch cluster would be a
> nice thing to showcase for bragging rights - 4 different HW arch's running in
> same single OS cluster.
>
> Q for the VSI folks - is there anything embedded in the code that
> would prevent a VAX 32bit server from joining a AX64/IA64/X86 64bit cluster?
>
> 😊

It has been seen "working".

https://forum.vmssoftware.com/viewtopic.php?f=37&t=8674

Arne

On 5/31/2023 7:41 AM, MG wrote:
> As an almost daily user of the EISNER:: node of DECUServe,
> I began to wonder: Couldn't DECUServe serve as a cost-
> effective method for VSI to demonstrate both OpenVMS for
> x86-64 and its cross-architecture clustering capabilities
> to a wider audience?  Since VSI operates this physical
> hardware and adding a modestly configured x86-64 virtual
> machine would probably not add too much to the existing
> operating and maintenance costs of DECUServe.

As the VSI person who manages EISNER, I largely agree with this.

However, we're in the middle of moving to a different colocation facility,
and until that move is completed some time in mid-July, I really cannot
consider adding additional resources.

--

--- Rob

On Wednesday, May 31, 2023 at 6:33:17 PM UTC-4, Dave Froble wrote:
> If my feeble memory still works, I think that has already been answered.
>
> x86 cluster communications will be modified, and to include Alpha and/or itanic,
> a patch for either will be required. No patches for VAX, since VSI does not
> have a VAX release to which patches can be provided.

As a reminder, the VSI FAQ still says "Clustering of VSI OpenVMS for x86-64 with VAX/VMS systems is still under investigation at this time." See: https://vmssoftware.com/about/v9-qa/