Time to turn DECUServe into a mixed VMScluster?

[MG]

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

[Simon Clubley]

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.

[Jan-Erik Söderholm]

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.

[Simon Clubley]

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

[John Reagan]

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

[Jan-Erik Söderholm]

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

[abrsvc]

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

[Simon Clubley]

On 2023-05-31, John Reagan <xyzz...@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 Clubley]

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.

[John Reagan]

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.

[Arne Vajhøj]

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

[MG]

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

[Arne Vajhøj]

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

[MG]

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

[kemain...@gmail.com]

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

[MG]

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

[Lee Gleason]

%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

[Dave Froble]

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: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[MG]

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

[Chris Townley]

Above shows that you own it, so not surprising that you can run it, but
no world access...

--
Chris

[Scott Dorsey]

In article <nnd$6f0d1a96$39b9159a@34e78233e2c9d371>,

MG <em_g...@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."

[MG]

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

[Arne Vajhøj]

> 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

[Robert A. Brooks]

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

[terry-...@glaver.org]

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/

[Mark Daniel]

On 1/6/2023 2:44 am, Simon Clubley wrote:
> On 2023-05-31, John Reagan <xyzz...@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

Encouraging additional comment

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

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

Early on I posted

https://forum.vmssoftware.com/viewtopic.php?f=37&t=8480&p=17485#p17485

echoing similar sentiments.

> Simon.

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

[Simon Clubley]

On 2023-05-31, Scott Dorsey <klu...@panix.com> wrote:
> In article <nnd$6f0d1a96$39b9159a@34e78233e2c9d371>,
> MG <em_g...@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!

"Nothing sucks like a VAX". :-)

[Simon Clubley]

On 2023-06-01, terry-...@glaver.org <terry-...@glaver.org> wrote:

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

Correct. If you are going to show off VMS clustering then it has to be
secure clustering, which means the VSI changes and which means no VAX.

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

That will be unencrypted clustering because otherwise VSI would have to
create a clustering compatibillity kit for existing VAX versions, which
they are not allowed to do.

[Dave Froble]

Yes, but if VSI decides to "improve" the cluster communications, and there are
reasons to do so, then I see two possibilities for clustering with a VAX.

1) Issue a patch for VAX/VMS, which my understanding is they cannot do.

2) Include both any new protocol along with the current protocol on Alpha,
itanic, and x86. And that would sort of wipe out any security measures that
might be in the new protocol.

[Rich Alderson]

MG <em_g...@SPAMxs4all.nl> writes:

> 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"?

Umm, RSTS/E springs immediately to mind, followed closely by IAS...

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

[Johnny Billquist]

On 2023-05-31 21:43, 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"?

I know that Arne's point was that such users just look at it as "VMS",
not knowing or caring what hardware architecture they might be running on.

But to answer your question more literally, I could say RSX or RSTS/E as
well. DCL was not VMS only. Just telnet to mim.stupi.net, and log in as
user guest with password guest, and play with DCL under RSX...

Johnny

[Johnny Billquist]

On 2023-06-01 14:03, Simon Clubley wrote:
> On 2023-05-31, Scott Dorsey <klu...@panix.com> wrote:
>> In article <nnd$6f0d1a96$39b9159a@34e78233e2c9d371>,
>> MG <em_g...@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!
>
> "Nothing sucks like a VAX". :-)

I wonder if people will ever get that this quote is incorrect.

There is a vacuum brand called VAX, but the quoted slogan was from
another brand - Electrolux. "Nothing sucks like Electrolux". Which even
rhymes properly.

Johnny

[Johnny Billquist]

On 2023-06-01 20:28, Rich Alderson wrote:
> MG <em_g...@SPAMxs4all.nl> writes:
>
>> 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"?
>
> Umm, RSTS/E springs immediately to mind, followed closely by IAS...

I can't remember for sure if DCL was originally for IAS or RSX-11M-PLUS,
and everything else came after that.

Johnny

[Johnny Billquist]

On 2023-06-01 14:06, Simon Clubley wrote:
> On 2023-06-01, terry-...@glaver.org <terry-...@glaver.org> wrote:
>> 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.
>
> Correct. If you are going to show off VMS clustering then it has to be
> secure clustering, which means the VSI changes and which means no VAX.
>
>>
>> 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/
>
> That will be unencrypted clustering because otherwise VSI would have to
> create a clustering compatibillity kit for existing VAX versions, which
> they are not allowed to do.

Says who?

Why would they not be allowed to create any software for VMS for VAX? I
strongly suspect that is an incorrect statement.

They cannot issue licenses for VMS for VAX without creating a new
version of VMS, but that have no bearing on the ability to distribute
some other software for VMS on VAX.

It would be like saying that noone is allowed to create any new software
for VMS on VAX. Which would be an extremely weird thing to claim.

Johnny

[Dave Froble]

You may be correct. Would be nice. However, we're discussing something tightly
coupled with the OS. A good question for VSI.

[Arne Vajhøj]

On 6/1/2023 6:34 PM, Johnny Billquist wrote:

> On 2023-06-01 14:06, Simon Clubley wrote:
>> On 2023-06-01, terry-...@glaver.org <terry-...@glaver.org> wrote:
>>> 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/
>>
>> That will be unencrypted clustering because otherwise VSI would have to
>> create a clustering compatibillity kit for existing VAX versions, which
>> they are not allowed to do.

They are certainly allowed.

VSI has stated numerous times that they are allowed to release
a VMS VAX version but that they have no intention of doing so
for commercial reasons.

> Says who?
>
> Why would they not be allowed to create any software for VMS for VAX? I
> strongly suspect that is an incorrect statement.
>
> They cannot issue licenses for VMS for VAX without creating a new
> version of VMS, but that have no bearing on the ability to distribute
> some other software for VMS on VAX.
>
> It would be like saying that noone is allowed to create any new software
> for VMS on VAX. Which would be an extremely weird thing to claim.

VSI could certainly create a chess game for VMS VAX or any
other type of application without any complications.

But clustering is pretty tightly integrated into VMS.

I suspect that they may not be able to change the
cluster protocol without releasing a new VMS version.

Which they can but won't.

Arne

[Arne Vajhøj]

On 6/1/2023 9:53 AM, Dave Froble wrote:
> On 6/1/2023 12:44 AM, terry-...@glaver.org wrote:
>> 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/
>>
>
> Yes, but if VSI decides to "improve" the cluster communications, and
> there are reasons to do so, then I see two possibilities for clustering
> with a VAX.
>
> 1) Issue a patch for VAX/VMS, which my understanding is they cannot do.
>
> 2) Include both any new protocol along with the current protocol on
> Alpha, itanic, and x86.  And that would sort of wipe out any security
> measures that might be in the new protocol.

I am not sure that I understand the problem.

We are talking about a PR stunt here - running a VMS cluster with
4 architecture to get some good press.

Nobody cares whether that system uses encrypted clustering
traffic or not.

Some will care about encrypted clustering traffic in a production
environment.

But such an environment is not likely to want such a 4
architecture cluster or to include VAX (it seems reasonable
to assume that a VMS VAX system today is "frozen" aka don't
want to change anything).

If the new VMS cluster software negotiate encryption and only
enable if both ends support it then sites could patch and
get encryption for Alpha - x86-64 and Itanium - x86-64
if they want to (or auditors force them to).

Arne

[MG]

Apologies, I regret having created this thread.

- MG

[Single Stage to Orbit]

On Thu, 2023-06-01 at 19:48 -0400, Arne Vajhøj wrote:
> > It would be like saying that noone is allowed to create any new
> > software
> > for VMS on VAX. Which would be an extremely weird thing to claim.
>
> VSI could certainly create a chess game for VMS VAX or any
> other type of application without any complications.
>
> But clustering is pretty tightly integrated into VMS.
>
> I suspect that they may not be able to change the
> cluster protocol without releasing a new VMS version.

I know DEC used to release the source code on microfiche. It should be
straightforward to scroll through the listings and see if your
assertion can be proved.
--
Tactical Nuclear Kittens

[abrsvc]

Just for clarity:

VMS (and later OpenVMS) source LISTINGS were available on microfiche until V5.4-2. After that the listings were on CD.
You could purchase sources on a separate license and those were available as well, but there were restrictions. Some portions of VMS havenever been available either as source or listings (licensing parts for example). I am not aware of these listings being available for VSI versions though.

Dan

[Simon Clubley]

On 2023-06-01, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
> I am not sure that I understand the problem.
>

That's obvious. :-)

> We are talking about a PR stunt here - running a VMS cluster with
> 4 architecture to get some good press.
>
> Nobody cares whether that system uses encrypted clustering
> traffic or not.
>

How good do you think the press coverage will be when they find out
this super-duper clustering technology is using completely unencrypted
protocols ?

[Simon Clubley]

On 2023-06-01, Rich Alderson <ne...@alderson.users.panix.com> wrote:
> MG <em_g...@SPAMxs4all.nl> writes:
>
>> 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"?
>
> Umm, RSTS/E springs immediately to mind, followed closely by IAS...
>

I still miss /MO:4096 :-) ...

[Simon Clubley]

On 2023-06-01, Johnny Billquist <b...@softjar.se> wrote:
> On 2023-06-01 14:03, Simon Clubley wrote:
>> On 2023-05-31, Scott Dorsey <klu...@panix.com> wrote:
>>> In article <nnd$6f0d1a96$39b9159a@34e78233e2c9d371>,
>>> MG <em_g...@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!
>>
>> "Nothing sucks like a VAX". :-)
>
> I wonder if people will ever get that this quote is incorrect.
>
> There is a vacuum brand called VAX, but the quoted slogan was from
> another brand - Electrolux. "Nothing sucks like Electrolux". Which even
> rhymes properly.
>
> Johnny
>

No, it was used by the VAX vacuum cleaner people as well.

Could not find any direct advertising material references, but did find
these references:

http://catb.org/jargon/html/V/VAX.html

https://news.ycombinator.com/item?id=14884244

[Simon Clubley]

On 2023-06-01, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 2023-06-01 14:06, Simon Clubley wrote:
>>> On 2023-06-01, terry-...@glaver.org <terry-...@glaver.org> wrote:
>>>> 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/
>>>
>>> That will be unencrypted clustering because otherwise VSI would have to
>>> create a clustering compatibillity kit for existing VAX versions, which
>>> they are not allowed to do.
>
> They are certainly allowed.
>
> VSI has stated numerous times that they are allowed to release
> a VMS VAX version but that they have no intention of doing so
> for commercial reasons.
>

Please note the phrase "for existing VAX versions" above.

[Dave Froble]

On 6/2/2023 8:26 AM, Simon Clubley wrote:
> On 2023-06-01, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>
>> I am not sure that I understand the problem.
>>
>
> That's obvious. :-)

Yes ...

>> We are talking about a PR stunt here - running a VMS cluster with
>> 4 architecture to get some good press.

There appear to be users of emulated VAX systems. These could be serious
production systems. Perhaps such users would like to add an x86 VMS system, and
to cluster it with their emulated VAX systems. Why? I don't know, and it
doesn't matter. So, considering it a "PR stunt" is unfair to such users.

>> Nobody cares whether that system uses encrypted clustering
>> traffic or not.
>>
>
> How good do you think the press coverage will be when they find out
> this super-duper clustering technology is using completely unencrypted
> protocols ?

Nothwithstanding Simon's paranoia, it is an issue for potential customers.
Myself, I'd suggest a bit of security. But it isn't my horse in this race.

[abrsvc]

I have real VAX, Alpha and Itanium systems. Perhaps if I spin up an X86 version and cluster all of them together that would suffice?
I can add some emulated systems to the mix for fun too.

What would make this a PR win? What proof would you want for this? I am willing to put it together if it makes sense.

Dan

[Simon Clubley]

On 2023-06-02, abrsvc <dansabr...@yahoo.com> wrote:

To be honest Dan, I am not really seeing the PR merits of just linking
a current architecture (x86-64), two obsolete architectures (VAX and Alpha),
and one mostly obsolete architecture (Itanium) together in a cluster.

The general reaction to that outside of the VMS world is likely to be
"so what ?".

I should also point out you can build a Linux cluster across a larger
range of architectures. Even if the Linux clustering capabilities are
not as advanced as VMS, these days they can be made to be suitable for
a good range of tasks.

What _would_ be PR worthy is exactly what HP/HPE did 15 years ago, when
they physically destroyed cluster nodes and then everyone watched while
the remaining nodes recovered without data loss, especially if VMS was
still the way fastest to recover as it was back then.

However, expectations have moved on since then and such an explosion
and simulated workload would have to be on a far larger scale than it
was back then to be really newsworthy.

[Bob Gezelter]

Johnny,

VAX/VMS DCL was present at the initial public handbook point, and highly likely earlier.

RSX-11M-PLUS genesis is later. RSX-11M DCL is well later (I was a field test site for RSX-11M 3.2).

IAS I cannot speak to. Also, did not encounter RSTS/E till later.

Somewhere I had a TOPS-20 reference card, but cannot go looking for it.

- Bob Gezelter, http://www.rlgsc.com

[Mark Berryman]

On 5/31/23 1:34 PM, Arne Vajhøj wrote:
> 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.

I have a running Alpha/Itanium/X86_64 cluster (which makes it trivially
easy to use the cross tools (when necessary) for x86 builds). I could
add a simh VAX if that is really necessary.

What, exactly, would you like to see?

Mark Berryman

[Rich Alderson]

Bob Gezelter <geze...@rlgsc.com> writes:

> VAX/VMS DCL was present at the initial public handbook point, and highly
> likely earlier.

> RSX-11M-PLUS genesis is later. RSX-11M DCL is well later (I was a field test
> site for RSX-11M 3.2).

> IAS I cannot speak to. Also, did not encounter RSTS/E till later.

> Somewhere I had a TOPS-20 reference card, but cannot go looking for it.

The TOPS-20 EXEC is very different from DCL, and predates the VAX and VMS by
several years. Most of the lessons learned from EXEC were thrown away.

[Dan Cross]

In article <mdd1qit...@panix5.panix.com>,

Rich Alderson <ne...@alderson.users.panix.com> wrote:
>Bob Gezelter <geze...@rlgsc.com> writes:
>
>> VAX/VMS DCL was present at the initial public handbook point, and highly
>> likely earlier.
>
>> RSX-11M-PLUS genesis is later. RSX-11M DCL is well later (I was a field test
>> site for RSX-11M 3.2).
>
>> IAS I cannot speak to. Also, did not encounter RSTS/E till later.
>
>> Somewhere I had a TOPS-20 reference card, but cannot go looking for it.
>
>The TOPS-20 EXEC is very different from DCL, and predates the VAX and VMS by
>several years. Most of the lessons learned from EXEC were thrown away.

Dan Murphy's document on the history of TOPS-20 discusses this
somewhat. It seems that TOPS-20's EXEC not only influenced DCL
but was also influenced by DCL; ironically, the big change they
introduced for DCL compatibility was not picked up by VMS,
which went with the TENEX mechanism instead. Oops.

https://opost.com/tenex/hbook.html

- Dan C.

[Arne Vajhøj]

On 6/2/2023 8:37 AM, Simon Clubley wrote:
> On 2023-06-01, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>> On 2023-06-01 14:06, Simon Clubley wrote:
>>>> On 2023-06-01, terry-...@glaver.org <terry-...@glaver.org> wrote:
>>>>> 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/
>>>>
>>>> That will be unencrypted clustering because otherwise VSI would have to
>>>> create a clustering compatibillity kit for existing VAX versions, which
>>>> they are not allowed to do.
>>
>> They are certainly allowed.
>>
>> VSI has stated numerous times that they are allowed to release
>> a VMS VAX version but that they have no intention of doing so
>> for commercial reasons.
>
> Please note the phrase "for existing VAX versions" above.

Yes but:

if clustering is integrated with VMS => this functionality require a new
VMS version which they are allowed to but don't want to

if clustering is not integrated with VMS => this functionality can be
provided without a new VMS version and they are allowed to but
don't want to.

Arne

[Arne Vajhøj]

On 6/2/2023 8:59 AM, abrsvc wrote:
> I have real VAX, Alpha and Itanium systems. Perhaps if I spin up an
> X86 version and cluster all of them together that would suffice? I
> can add some emulated systems to the mix for fun too.
>
> What would make this a PR win? What proof would you want for this?
> I am willing to put it together if it makes sense.

It has already been done per post to VSI forum.

We know that it works/"works".

It is all about getting some PR for it.

The point is to demonstrate VMS compatibility.

80's VMS, 90's VMS, 00's VMS and todays VMS are
extremely compatible and interoperable.

That may be enough to get attention from some
IT media.

And it is a message that IT decision makers
like to hear.

But setting it up, making it available to view in some
form, keep it running for some weeks/months etc. will
take some time.

And given that VSI is making the money from VMS sale, then
it seems natural if they do the work.

If they believe in the idea. Which is not given.

Arne

[Arne Vajhøj]

On 6/2/2023 1:36 PM, Simon Clubley wrote:
> On 2023-06-02, abrsvc <dansabr...@yahoo.com> wrote:
>> I have real VAX, Alpha and Itanium systems. Perhaps if I spin up
>> an X86 version and cluster all of them together that would
>> suffice? I can add some emulated systems to the mix for fun too.
>>
>> What would make this a PR win? What proof would you want for
>> this? I am willing to put it together if it makes sense.
>>
>
> To be honest Dan, I am not really seeing the PR merits of just
> linking a current architecture (x86-64), two obsolete architectures
> (VAX and Alpha), and one mostly obsolete architecture (Itanium)
> together in a cluster.
>
> The general reaction to that outside of the VMS world is likely to
> be "so what ?".
>
> I should also point out you can build a Linux cluster across a
> larger range of architectures. Even if the Linux clustering
> capabilities are not as advanced as VMS, these days they can be made
> to be suitable for a good range of tasks.

You are missing the point.

The interesting aspect of the different hardware architectures for VMS
is not the different instruction sets per se but the age they belong to.

I am sure that RHEL 9 / x86-64 and RHEL 9 / ARM64 are very compatible
and interoperable.

But the VMS equivalent of that would be that VMS 9 / x86-64 and
the *non-existing* VMS 9 / Itanium are very compatible
and interoperable.

The fact that VMS / VAX, VMS / Alpha, VMS / Itanium and VMS / x86-64
are compatible and interoperable should be compared to:

SunOS 4.1 - Solaris 2.7 - RHEL 2 - RHEL 9
WinNT 3.1 - Win 2000 - Win 2008R2 - Win 2022

or something like that.

Is that a fair comparison? Not really. But marketing is
not about being fair!

> What _would_ be PR worthy is exactly what HP/HPE did 15 years ago,
> when they physically destroyed cluster nodes and then everyone
> watched while the remaining nodes recovered without data loss,
> especially if VMS was still the way fastest to recover as it was back
> then.
>
> However, expectations have moved on since then and such an explosion
> and simulated workload would have to be on a far larger scale than
> it was back then to be really newsworthy.

Everybody can do stuff like that today.

The fact that the functionality is typical in the applications
and not the OS does not matter much.

Arne

[Arne Vajhøj]

VSI doing it and trying to get some positive PR.

:-)

Arne

[Arne Vajhøj]

On 6/2/2023 8:26 AM, Simon Clubley wrote:

> On 2023-06-01, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> We are talking about a PR stunt here - running a VMS cluster with
>> 4 architecture to get some good press.
>>
>> Nobody cares whether that system uses encrypted clustering
>> traffic or not.
>
> How good do you think the press coverage will be when they find out
> this super-duper clustering technology is using completely unencrypted
> protocols ?

I don't see the problem.

Decision makers will not be interested in such detail.

The sysadm/network/security professionals will know that
a lot of data center traffic is unencrypted and ZTA
initiatives are work in progress. And as soon as they
hear the age of the involved systems then they will
not expect encryption. If they hear that there are plans
to add encryption for the systems less than 25 years old,
then they will be very happy.

That leaves the group of random internet whiners. And
they don't matter.

Arne

[Arne Vajhøj]

On 6/2/2023 8:38 AM, Dave Froble wrote:
>> On 2023-06-01, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>> We are talking about a PR stunt here - running a VMS cluster with
>>> 4 architecture to get some good press.
>
> There appear to be users of emulated VAX systems.  These could be
> serious production systems.  Perhaps such users would like to add an x86
> VMS system, and to cluster it with their emulated VAX systems.  Why?  I
> don't know, and it doesn't matter.

We know that some VMS VAX systems still in production. Hundreds maybe
thousands.

But as I wrote in that post but did not get quoted:

# (it seems reasonable
# to assume that a VMS VAX system today is "frozen" aka don't
# want to change anything).

I don't think enough of those VMS VAX customers will be
interested in having their VAX change cluster topology
to justify any VMS VAX encryption solution.

> So, considering it a "PR stunt" is
> unfair to such users.

I don't get that.

A company makes something artificial to get some
good PR.

Why would that be unfair to the customers using the
product for something serious?

Did Tesla owners feel unfairly treated when Musk
sent a Tesla into space?

I don't think so.

Arne

[Chris Townley]

That reminds me of the famous bug in the Windows 3.11 calculator.
3.11 - 3.10 = 0

--
Chris

[Johnny Billquist]

On 2023-06-02 14:34, Simon Clubley wrote:
> On 2023-06-01, Johnny Billquist <b...@softjar.se> wrote:
>> On 2023-06-01 14:03, Simon Clubley wrote:
>>> On 2023-05-31, Scott Dorsey <klu...@panix.com> wrote:
>>>> In article <nnd$6f0d1a96$39b9159a@34e78233e2c9d371>,
>>>> MG <em_g...@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!
>>>
>>> "Nothing sucks like a VAX". :-)
>>
>> I wonder if people will ever get that this quote is incorrect.
>>
>> There is a vacuum brand called VAX, but the quoted slogan was from
>> another brand - Electrolux. "Nothing sucks like Electrolux". Which even
>> rhymes properly.
>>
>> Johnny
>>
>
> No, it was used by the VAX vacuum cleaner people as well.
>
> Could not find any direct advertising material references, but did find
> these references:
>
> http://catb.org/jargon/html/V/VAX.html
>
> https://news.ycombinator.com/item?id=14884244

You can't find any direct advertising material because it don't exist.

And do you really think one company would copy the slogan of another
competitor?

It's just another of those urban stories that just goes around, and
reinforce themselves just because everyone else also propagates them.

If you google for "Nothing sucks like an Electrolux" you'll find plenty
of examples of ads with the slogan. Started in the 70s. Just about the
same time the VAX was introduced. And people who didn't like what DEC
was doing, or what the VAX was (read - especially PDP-10 people) just
adopted the advertising slogan to make a joke.

Johnny

[Johnny Billquist]

On 2023-06-02 20:00, Bob Gezelter wrote:
> On Thursday, June 1, 2023 at 6:31:16 PM UTC-4, Johnny Billquist wrote:
>> On 2023-06-01 20:28, Rich Alderson wrote:
>>> MG <em_g...@SPAMxs4all.nl> writes:
>>>
>>>> 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"?
>>>
>>> Umm, RSTS/E springs immediately to mind, followed closely by IAS...
>> I can't remember for sure if DCL was originally for IAS or RSX-11M-PLUS,
>> and everything else came after that.
>>
>> Johnny
> Johnny,
>
> VAX/VMS DCL was present at the initial public handbook point, and highly likely earlier.

No question that DCL was there from day one of VMS. That does not mean
DCL didn't exist before VMS.

Desperately seeking for the source/reference now, but failing at the
moment (I'll find it sooner or later). But thinking about it, I'm fairly
sure DCL originated on IAS.

Ah - found one (it). https://www.john-a-harper.com/ias.html (by one of
the people working on/implementing IAS.)

> RSX-11M-PLUS genesis is later. RSX-11M DCL is well later (I was a field test site for RSX-11M 3.2).

DCL for sure already existed by -11M 3.2, though.

Looking at RSX sources would date that version to 1980.

> IAS I cannot speak to. Also, did not encounter RSTS/E till later.

RSTS/E DCL is way later. But it is maybe the one closest to VMS.

> Somewhere I had a TOPS-20 reference card, but cannot go looking for it.

TOPS-20 EXEC is (as others mentioned) nothing near DCL.

Johnny

[Johnny Billquist]

On 2023-06-02 01:37, Dave Froble wrote:
> On 6/1/2023 6:34 PM, Johnny Billquist wrote:
>> On 2023-06-01 14:06, Simon Clubley wrote:
>>> On 2023-06-01, terry-...@glaver.org <terry-...@glaver.org> wrote:

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

>>> Correct. If you are going to show off VMS clustering then it has to be
>>> secure clustering, which means the VSI changes and which means no VAX.

>>>
>>>>
>>>> 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/
>>>
>>> That will be unencrypted clustering because otherwise VSI would have to
>>> create a clustering compatibillity kit for existing VAX versions, which
>>> they are not allowed to do.
>>

>> Says who?
>>
>> Why would they not be allowed to create any software for VMS for VAX?
>> I strongly
>> suspect that is an incorrect statement.
>>
>> They cannot issue licenses for VMS for VAX without creating a new
>> version of
>> VMS, but that have no bearing on the ability to distribute some other

>> software
>> for VMS on VAX.
>>
>> It would be like saying that noone is allowed to create any new
>> software for VMS
>> on VAX. Which would be an extremely weird thing to claim.
>>

>>   Johnny
>>
>
> You may be correct.  Would be nice.  However, we're discussing something
> tightly coupled with the OS.  A good question for VSI.

I think VSI have made it pretty clear that they don't want to touch any
VAXen with a 20 foot pole, so I suspect the topic is somewhat moot no
matter what. :-)

But maybe if someone were to throw enough money at them...

Johnny

[Dave Froble]

On 6/3/2023 4:11 PM, Johnny Billquist wrote:

> RSTS/E DCL is way later. But it is maybe the one closest to VMS.

That is bacause RSTS ISVs were asking DEC to make VMS look more like RSTS.

One of the DEC people, management I think, asked, "what if we implement DCL on
RSTS?". I was there when the question was asked. Yeah, the opposite of what we
were asking for, but that's how it happened.

This happened maybe around 1980. Definitely before 1982.

[Chris Townley]

It may have been a British thing - The Vax was a wet and dry 'hoover'
and I remember hearing the slogan well after VAX was established

--
Chris

[Chris Townley]

ISTR that DCL came in with RSTOS V9. Many of my colleagues grumbled
about it - then we moved to VAX...

--
Chris

[Robert A. Brooks]

On 6/3/2023 6:46 PM, Chris Townley wrote:

> ISTR that DCL came in with RSTOS V9. Many of my colleagues grumbled about it -
> then we moved to VAX...

Certainly before V9, which I think came out in 1985.

I used RSTS/E in college, graduating in 1984, and definitely
used DCL on RSTS/E then.

At that time, we students didn't understand why the default
keyboard monitor changed from BASIC+ to DCL.

Yes, we knew how to switch back to BASIC+ for our KBM.

--

--- Rob

[Johnny Billquist]

It was done by Elextrolux in Britain, if one is to believe all the
different analysises of the slogan that have been done. And it was
apparently still used into the 90s by Electrolux, even though they
started using it in the 70s.

Just google for it.

And the VAX brand of hoovers still exist as well, I believe.

Johnny

[Johnny Billquist]

On 2023-06-03 23:04, Dave Froble wrote:
> On 6/3/2023 4:11 PM, Johnny Billquist wrote:
>
>> RSTS/E DCL is way later. But it is maybe the one closest to VMS.
>
> That is bacause RSTS ISVs were asking DEC to make VMS look more like RSTS.

Oh that is definitely true. Under the hood, VMS is very much like RSX,
but as a user experience, it certainly is more like RSTS/E.

But this time my reflection really was that RSTS/E also, over time,
became more like VMS.

If you ever used RSTS/E V9 or later, you understand what I mean.
Otherwise, it might be an interesting experience. ;-)

> One of the DEC people, management I think, asked, "what if we implement
> DCL on RSTS?".  I was there when the question was asked.  Yeah, the
> opposite of what we were asking for, but that's how it happened.
>
> This happened maybe around 1980.  Definitely before 1982.

DCL on VMS, in the modern form at least, happened in RSTS/E V9. I'm
pretty sure of that. Which place it close to the end of the 80s.

Can't remember if some form of DCL existed earlier, but if it did, it
was a different beast.

Johnny

[Johnny Billquist]

On 2023-06-04 04:13, Robert A. Brooks wrote:
> On 6/3/2023 6:46 PM, Chris Townley wrote:
>
>> ISTR that DCL came in with RSTOS V9. Many of my colleagues grumbled
>> about it - then we moved to VAX...
>
> Certainly before V9, which I think came out in 1985.

There was a DCL before V9, but it was rather different to what came in V9.

> I used RSTS/E in college, graduating in 1984, and definitely
> used DCL on RSTS/E then.

The DCL that existed before V9 was a rather simple KBM. The one
introduced in V9 was very similar to VMS, and is a language in addition
to being a KBM.

> At that time, we students didn't understand why the default
> keyboard monitor changed from BASIC+ to DCL.
>
> Yes, we knew how to switch back to BASIC+ for our KBM.

I'm fairly sure that still in V8, the default KBM was BASIC+. But that
could of course have been changed by the system administrators...

In V9, the default was changed to be DCL.

Johnny

[Single Stage to Orbit]

On Sun, 2023-06-04 at 11:02 +0200, Johnny Billquist wrote:
>
> And the VAX brand of hoovers still exist as well, I believe.

Yep. I have a battery operated VAX in the cupboard. Sucks pretty well.
:-D
--
Tactical Nuclear Kittens

[MG]

Has this thread been given any consideration, i.e. by anyone at VSI?
I realize that it derailed into various off-topic discussions, as is
common here, but that was out of my hands.

Still curious, at any rate.

- MG

[MG]

On 31-May-2023 22:40, MG wrote:
> Going by "Last new note", there appears to be nothing more 'recent'
> than 18-MAR-2021...

It looks like I was wrong. I 'forcefully' updated my DEC Notes
notebooks and saw more recent messages. Perhaps I'll post my
plea there and perhaps also on the VSI forum (as was suggested
in this thread).

- MG

[Simon Clubley]

Yes. Rob replied, saying that he was interested, but that VSI was in
the middle of moving some equipment again (I can't remember the details
or the date it would be completed by).

[John Reagan]

We are relocating our servers to a different/better facility. Rob has been at the
current location helping consolidate/re-rack/etc machines in preparation for the
move. The schedule is for sometime in July. Fortunately, I'm not involved for this
move but I have spent my fair share of time in machine rooms doing exactly what
he is doing now.