On Saturday, October 16, 2021 at 6:52:27 AM UTC+13, Simon Clubley wrote:
> On 2021-10-14, Lawrence D?Oliveiro <lawren...@gmail.com> wrote:
>> On Friday, October 15, 2021 at 7:32:33 AM UTC+13, Simon Clubley wrote:
>>> Unlike the Unix shells you are clearly thinking of, DCL provides services
>>> to a program directly while the program is running.
>>
>> The same thing can be done from a separate thread or process.
>
> Not with how DCL is currently implemented.

We don’t have to implement it that way. All I think we need to care about is that existing user-mode code will work, and existing DCL command procedures will work. All the rest can be dumped. So our compatibility layer provides enough of existing DCL behaviour to satisfy these goals, and no more.

On Saturday, October 16, 2021 at 7:01:22 AM UTC+13, Simon Clubley wrote:

> FUSE filesystems come with performance limitations on Linux.

They work well enough for NTFS, for example. Given that Linux already runs on higher-performance hardware than anything VMS can manage, I doubt the penalty will be noticeable. ;)

I keep thinking in terms of reducing the amount of work (and hence time) to get something going. That means foregoing higher-performance, but possibly more difficult, design choices in favour of easier ones. Learn to walk before you can run. ;)

On Saturday, October 16, 2021 at 7:11:35 AM UTC+13, chris wrote:

> On 10/15/21 02:07, Lawrence D’Oliveiro wrote:

>> If you want to look at which is the single biggest company that is contributing to
>> Linux, that would have to be Microsoft.
>
> Well, warning, that may eventually be the kiss of death for Linux.

They already tried that. Remember “Linux is a cancer”? All the patent threats? Remember the infamous “Get The Facts” campaign? Though that kind of fell apart after the London Stock Exchange brouhaha...

I know all about “Embrace, Extend, Extinguish”. Linux has already felt the full force of those “Extinguish” efforts, on multiple fronts, and come out, if anything, stronger than ever.

Heard about WSL? Though in that case, note that the platform that Microsoft is “Embracing” and “Extending” is not Linux, but Windows. So what do you think will happen next?

>> Umm, Netgate dropped from FreeBSD? But they practically *are* FreeBSD. And
>> which “individual”? There are a number of individuals associated with the company,
>> who have done dubious things as reported in the article. Which you did read the
>> whole of, didn’t you?
>>
> Need some documentary evidence for that, not just arm waving.

Funny, you were willing to take the article as exactly this sort of “documentary evidence”, until it was pointed out you didn’t actually understand it...

> I've seen a fair amount of embedded Linux, but none of those versions
> included systemd, nor a lot of the other cruft that current distros
> suffer from.

But weren’t you complaining that Linux _couldn’t_ be de-bloated?

> Linux may be ok for undemanding embedded
> tasks, but still a great risk to select it for hard real time work.

Remember the helicopter that NASA sent to Mars? Guess what OS that’s running...

On Saturday, October 16, 2021 at 6:11:03 AM UTC+13, Arne Vajhøj wrote:
>
> Since then loosely typed languages and type inference
> has become widely used.

Things seem to go round in circles. Python doesn’t have variable declarations at all, yet that has become very popular.

And now they are adding type annotations to the language, though they are leaving it to third-party tools to actually check them ...

On Saturday, October 16, 2021 at 7:44:50 AM UTC+13, Dave Froble wrote:
> ... wonder what it's like to read code in column 382?
While the human reader does best with short text lines (which is why newspapers have so many columns), I find highly-indented program source lines not so hard to read. First of all they’re not that long, once you skip past the initial whitespace.
Also you can take advantage of the two dimensions of the screen/page to make the structure of expressions clearer, e.g.
    if (
            max_linelen != None
        and
                    indent
                +
                    len(tag_name)
                +
                    sum((len(s) + 1) for s in attrs)
                +
                    2
                +
                    int(has_elts)
            >
                max_linelen
    ) :
...

On 10/15/2021 2:35 PM, Simon Clubley wrote:
> On 2021-10-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 10/15/2021 2:25 PM, Simon Clubley wrote:
>>> On 2021-10-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> But type inference is definitely in fashion.
>>>
>>> Unless you are writing software that can kill people if it goes wrong.
>>
>> I suspect languages with type inference are occasionally used for that.
>>
>> C++, Java, C#, Rust etc..
>
> But what do the safety-critical standards say about what you are and
> are not allowed to do in those languages ?

I don't know.

Anybody that know whether Misra C++ permits auto?

Arne

On Saturday, October 16, 2021 at 1:46:02 PM UTC+13, Arne Vajhøj wrote:
> Anybody that know whether Misra C++ permits auto?

As I recall, C++ was specifically banned.

On 10/15/2021 9:35 PM, Lawrence D’Oliveiro wrote:
> On Saturday, October 16, 2021 at 1:46:02 PM UTC+13, Arne Vajhøj wrote:
>> Anybody that know whether Misra C++ permits auto?
>
> As I recall, C++ was specifically banned.

Banning C++ in a C++ guide would be a bit weird.

https://www.misra.org.uk/misra-c-plus-plus/

Arne

On Saturday, October 16, 2021 at 10:03:36 AM UTC+13, Stephen Hoffman wrote:
> Linux shimulation is not going to speed the delivery of the OpenVMS
> x86-64 semi-production and production versions, nor the availability of
> native compilers.

If VMS compatibility for user-mode code just takes the form of a library to link against, then VMS-specific compilers shouldn’t be necessary. You could use the existing GNU and LLVM compilers, and just implement wrappers that understand the VMS-specific options.

In article <1ae749de-d462-4c18-af01-4c077cb97ea2n@googlegroups.com>,
lawrencedo99@gmail.com (Lawrence D_Oliveiro) wrote:

> On Saturday, October 16, 2021 at 7:01:22 AM UTC+13, Simon Clubley
> wrote:
> > FUSE filesystems come with performance limitations on Linux.
>
> They work well enough for NTFS, for example. Given that Linux
> already runs on higher-performance hardware than anything VMS can
> manage, I doubt the penalty will be noticeable. ;)

Do people use FUSE NTFS on Linux for serious work, on which their
organisations' finances depend? It does not seem like a great idea to me,
after painful experiences with the reverse situation, running an NFS
server on Windows NT.

> I keep thinking in terms of reducing the amount of work (and hence
> time) to get something going. That means foregoing
> higher-performance, but possibly more difficult, design choices in
> favour of easier ones. Learn to walk before you can run. ;)

The situation for VMS is different from the history of Linux, although
that may be obscured by the presence of VMS hobby usage.

Currently, VSI have significant income from VMS support work, and that
comes from organisations running VMS for work that isn't easy to move to
some other OS (or they'd have done it already). However, those
organisations have a ticking clock as their Itanium hardware gets older.
They need to be able to transition to a commercial-grade VMS on x86-64
before they're forced to drop VMS and thus stop paying VSI. So VSI need
to take the route from here-and-now that produces a commercial product
most rapidly.

They have been engaged in porting the existing VMS codebase for just over
seven years, and have it working fairly well. The time to consider
producing an OS based on a different kernel was in 2013-14; switching to
that strategy now would require considerable time to get caught up to the
current position. Some things after that would definitely be easier, but
the delivery of a commercial-grade OS would end up being later.

John

In article <44512ead-b6e0-4735-b63b-0db699f8b978n@googlegroups.com>,
lawrencedo99@gmail.com (Lawrence D_Oliveiro) wrote:
> On Saturday, October 16, 2021 at 10:03:36 AM UTC+13, Stephen
> Hoffman wrote:
> > Linux shimulation is not going to speed the delivery of the
> > OpenVMS x86-64 semi-production and production versions, nor the
> > availability of native compilers.
>
> If VMS compatibility for user-mode code just takes the form of a
> library to link against, then VMS-specific compilers shouldn_t be
> necessary. You could use the existing GNU and LLVM compilers, and
> just implement wrappers that understand the VMS-specific options.

Won't work without ludicrous amounts of effort. There are subtle, but
pervasive, differences in the process model, the i/o model, the error
handling, and many other aspects of programming for the two operating
systems. That's why the Unix-emulation products for VMS have failed, and
why there are still VMS customers - it's been too hard for them to move
applications to other platforms, for a variety of reasons. The ones that
were easy to move have largely been done. What's left is the ones that
are difficult.

The reasons for wanting to use the DEC compiler front-ends is that DEC
languages weren't terribly standards-conformant: once upon a time, the
DEC market was big enough that the company didn't worry too much about
those things. It isn't just additional command-line options, it's
differences in the languages and libraries. Providing Clang for C++ and
standard-conformant C is an addition: the DEC C will still be needed for
historical code.

John

On 10/16/21 02:35, Lawrence D’Oliveiro wrote:
> On Saturday, October 16, 2021 at 1:46:02 PM UTC+13, Arne Vajhøj wrote:
>> Anybody that know whether Misra C++ permits auto?
>
> As I recall, C++ was specifically banned.

In the past, most safety critical system design precluded things
like dynamic memory allocation, garbage collection or any part
of the system that could not be shown to be fully deterministic.
Traditional memory allocation schemes can result in fragmentation
and denial of requests. C++ creation of objects / destruction and
garbage collection relies heavily on dynamic memory allocation
schemes.

In practice, the way that such systems got around the memory allocation
problem was to size the requirements at design time + a safety factor,
then implement that as fixed sized lists of one or more sized blocks.
in effect, write their own memory management.

Years since I looked at Misra, but most of it seemed like common sense
to at the time. Perhaps things have changed by now, with a stripped
down C++ considered acceptable...

Chris

On 10/16/21 00:50, Lawrence D’Oliveiro wrote:
> On Saturday, October 16, 2021 at 7:11:35 AM UTC+13, chris wrote:
>
>> On 10/15/21 02:07, Lawrence D’Oliveiro wrote:
>
>>> If you want to look at which is the single biggest company that is contributing to
>>> Linux, that would have to be Microsoft.
>>
>> Well, warning, that may eventually be the kiss of death for Linux.
>
> They already tried that. Remember “Linux is a cancer”? All the patent threats? Remember the infamous “Get The Facts” campaign? Though that kind of fell apart after the London Stock Exchange brouhaha...
>
> I know all about “Embrace, Extend, Extinguish”. Linux has already felt the full force of those “Extinguish” efforts, on multiple fronts, and come out, if anything, stronger than ever.
>
> Heard about WSL? Though in that case, note that the platform that Microsoft is “Embracing” and “Extending” is not Linux, but Windows. So what do you think will happen next?
>
>>> Umm, Netgate dropped from FreeBSD? But they practically *are* FreeBSD. And
>>> which “individual”? There are a number of individuals associated with the company,
>>> who have done dubious things as reported in the article. Which you did read the
>>> whole of, didn’t you?
>>>
>> Need some documentary evidence for that, not just arm waving.
>
> Funny, you were willing to take the article as exactly this sort of

“documentary evidence”, until it was pointed out you didn’t actually
understand it...

Opinion, but you are still ignoring the request for evidence.

>
>> I've seen a fair amount of embedded Linux, but none of those versions
>> included systemd, nor a lot of the other cruft that current distros
>> suffer from.
>
> But weren’t you complaining that Linux _couldn’t_ be de-bloated?
>
>> Linux may be ok for undemanding embedded
>> tasks, but still a great risk to select it for hard real time work.
>
> Remember the helicopter that NASA sent to Mars? Guess what OS that’s running...

Not at all. Try reading the whole article, rather than cherry
picking :-). Had you done so, you would realise that the company
and individual concerned have been dropped from the project.

I'm sure Linux is very popular, and there are claimed real time
variants, but bet none of those have systemd inside. Just not
needed for stripped down embedded work. Trad Linux would have
mS or worse response times, or just indeterminate, whereas real
time needs tick accurate uS.

Vax and VMS were real time capable decades ago. RtVax, from memory...

Chris

On 10/15/2021 10:45 PM, Lawrence D’Oliveiro wrote:
> On Saturday, October 16, 2021 at 10:03:36 AM UTC+13, Stephen Hoffman
> wrote:
>> Linux shimulation is not going to speed the delivery of the
>> OpenVMS x86-64 semi-production and production versions, nor the
>> availability of native compilers.
>
> If VMS compatibility for user-mode code just takes the form of a
> library to link against, then VMS-specific compilers shouldn’t be
> necessary. You could use the existing GNU and LLVM compilers, and
> just implement wrappers that understand the VMS-specific options.

The most important word in that sentence is "If".

Because that assumption is not valid at all.

VMS C and C++ has some VMS specific language extensions.

VMS Fortran and Cobol has a lot of VMS specific language extensions.

VMS Pascal and Basic are very different from those languages on
other platforms.

And both GCC and LLVM only have good support for C, C++ and Fortran
anyway.

And then there is Macro-32 and Bliss-32 ...

Arne

On 10/16/21 10:25 AM, Arne Vajhøj wrote:
> On 10/15/2021 10:45 PM, Lawrence D’Oliveiro wrote:
>> On Saturday, October 16, 2021 at 10:03:36 AM UTC+13, Stephen Hoffman
>> wrote:
>>> Linux shimulation is not going to speed the delivery of the
>>> OpenVMS x86-64 semi-production and production versions, nor the
>>> availability of native compilers.
>>
>> If VMS compatibility for user-mode code just takes the form of a
>> library to link against, then VMS-specific compilers shouldn’t be
>> necessary. You could use the existing GNU and LLVM compilers, and
>> just implement wrappers that understand the VMS-specific options.
>
> The most important word in that sentence is "If".
>
> Because that assumption is not valid at all.
>
> VMS C and C++ has some VMS specific language extensions.
>
> VMS Fortran and Cobol has a lot of VMS specific language extensions.

As a very strong advocate of the continued use of COBOL (I fought
to keep it in academia just as hard as I fought to keep VMS there!)
I find this interesting. Does anyone have a relatively large VMS
COBOL program that has these extensions in it that they can and
would be willing to share? I would love to take a look at just
how hard it would be to get it to compile under the current COBOL
standard.

bill

On 10/16/2021 10:33 AM, Bill Gunshannon wrote:
> On 10/16/21 10:25 AM, Arne Vajhøj wrote:
>> VMS Fortran and Cobol has a lot of VMS specific language extensions.
>
> As a very strong advocate of the continued use of COBOL (I fought
> to keep it in academia just as hard as I fought to keep VMS there!)
> I find this interesting.  Does anyone have a relatively large VMS
> COBOL program that has these extensions in it that they can and
> would be willing to share?  I would love to take a look at just
> how hard it would be to get it to compile under the current COBOL
> standard.

Well - I don't code in Cobol and I don't have any real work Cobol code.

There are actually two issues to consider:
- language extensions
- external stuff

Re language extensions then a quick scan of the reference manual finds:
* special registers with RMS stuff
* PROGRAM-ID ... WITH IDENT ...
* some stuff in FILE CONTROL SELECT ASSIGN
* RECORD DELIMITER
* POINTER-64 and BINARY-* UNSIGNED data types
* CALL ... BY DESCRIPTOR
* ARGCOUNT builtin
* a ton of CDD stuff
* something called "Hierarchical Repository" that I don't
know what is

(note that there may be more when comparing with standard Cobol - the
above is what is in VMS Cobol compared to Tru64 Cobol)

But then there is the external stuff:
* opening files with filenames in VMS filename syntax
* calling LIB$ and SYS$ routines
* relying on Rdb (Rdb specific SQL or SQL module
or just having an embedded SQL precompiler)
* use of Macro-32 stuff

I don't know how much this stuff is used in real world
VMS Cobol programs.

Given that when a VMS Cobol program was started back in
the 80's or 90's then:
* most likely nobody was thinking about moving off VMS in the future
* portability was not a big concern in general
* it was "Cobol programmers" not "VMS programmers"
* Cobol had the features needed for what Cobol was used for
* if some code was to do a lot of VMS calls (LIB$, SYS$ etc.) then
it would likely be written in another language than Cobol
then my expectation are that:
* very few VMS Cobol programs will just compile on let us say
GNU Cobol with zero changes
* many VMS Cobol programs could be ported to GNU Cobol with
trivial effort

But I could be wrong!

Arne

On Sunday, October 17, 2021 at 12:35:09 AM UTC+13, John Dallman wrote:
> In article <1ae749de-d462-4c18...@googlegroups.com>,
> lawren...@gmail.com (Lawrence D_Oliveiro) wrote:
>
>> On Saturday, October 16, 2021 at 7:01:22 AM UTC+13, Simon Clubley
>> wrote:
>>> FUSE filesystems come with performance limitations on Linux.
>>
>> They work well enough for NTFS, for example. Given that Linux
>> already runs on higher-performance hardware than anything VMS can
>> manage, I doubt the penalty will be noticeable. ;)
>
> Do people use FUSE NTFS on Linux for serious work, on which their
> organisations' finances depend?

I would imagine yes, at least during the transition away from Windows servers. Would you entrust mission-critical business functions to an OS that can only handle 26 drive letters?

> It does not seem like a great idea to me,
> after painful experiences with the reverse situation, running an NFS
> server on Windows NT.

Microsoft have never been good at coexisting with standards it did not invent ...

> They need to be able to transition to a commercial-grade VMS on x86-64
> before they're forced to drop VMS and thus stop paying VSI. So VSI need
> to take the route from here-and-now that produces a commercial product
> most rapidly.

Precisely my point.

> They have been engaged in porting the existing VMS codebase for just over
> seven years, and have it working fairly well. The time to consider
> producing an OS based on a different kernel was in 2013-14; switching to
> that strategy now would require considerable time to get caught up to the
> current position.

There is a saying, that the best time to start doing something is always ten years ago. The second-best time is now.

On Sunday, October 17, 2021 at 2:02:50 AM UTC+13, chris wrote:
> I'm sure Linux is very popular, and there are claimed real time
> variants, but bet none of those have systemd inside. Just not
> needed for stripped down embedded work.

Which you said you had no time to do.

> Trad Linux would have
> mS or worse response times, or just indeterminate, whereas real
> time needs tick accurate uS.

Linux has long had real-time capabilities <https://www.linuxfoundation.org/blog/intro-to-real-time-linux-for-embedded-developers/>.

On Sunday, October 17, 2021 at 3:26:11 AM UTC+13, Arne Vajhøj wrote:
> On 10/15/2021 10:45 PM, Lawrence D’Oliveiro wrote:
>
>> If VMS compatibility for user-mode code just takes the form of a
>> library to link against ...
>
> The most important word in that sentence is "If".
>
> Because that assumption is not valid at all.

Sure it can be done. Once you strip out everything that isn’t user-mode code, what’s left of VMS (as it appears to the app) could be implemented in a compatibility library. Call it “libstarlet”.. It would implement the calls for QIO and RMS, and whatever else we need. It would not be entirely self-contained: many services (e.g. logical-name translations, DECnet) would require connections to other service processes.

> VMS C and C++ has some VMS specific language extensions.
>
> VMS Fortran and Cobol has a lot of VMS specific language extensions.

I thought COBOL was supposed to be a standard language that needed almost no special extensions at all?

> VMS Pascal and Basic are very different from those languages on
> other platforms.
>
> And both GCC and LLVM only have good support for C, C++ and Fortran
> anyway.

Actually, both have been used as the basis for quite a number of languages.

<https://en.wikipedia.org/wiki/LLVM> mentions a whole lot of language implementations built on top of LLVM. For a similar list for GCC, try

    apt-cache rdepends gcc

> And then there is Macro-32 and Bliss-32 ...

If they could make the move to Alpha, they can be moved anywhere...

On Sunday, October 17, 2021 at 12:35:10 AM UTC+13, John Dallman wrote:
> In article <44512ead-b6e0-4735...@googlegroups.com>,
> lawren...@gmail.com (Lawrence D_Oliveiro) wrote:
>
>> If VMS compatibility for user-mode code just takes the form of a
>> library to link against, then VMS-specific compilers shouldn_t be
>> necessary. You could use the existing GNU and LLVM compilers, and
>> just implement wrappers that understand the VMS-specific options.
>
> Won't work without ludicrous amounts of effort.

The question is whether that effort is more or less than that of porting the whole of VMS, with its deeply-embedded hardware assumptions dating back to VAX days, to new hardware. I suspect it’s a lot less.

> There are subtle, but pervasive, differences in the process model, the i/o model,
> the error handling, and many other aspects of programming for the two operating
> systems. That's why the Unix-emulation products for VMS have failed ...

That was the other way round. Here we are trying to emulate (core parts of) a more ancient system on a more versatile one.

For example, you know how on VMS the life of a subprocess is inextricably tied to its parent process? That if the parent process should die, the subprocess is killed also? In traditional Unix/POSIX, the subprocess would simply be reparented to PID 1.

Well, Linux has prctl(2) <https://manpages.debian.org/bullseye/manpages-dev/prctl.2.en.html>, which among its myriad of options, lets you specify a signal to be sent to the child process when the parent dies (PDEATHSIG). If you set this signal to SIGKILL, then the child has no choice but to die--no ifs or buts.

> ... and why there are still VMS customers - it's been too hard for them to move
> applications to other platforms, for a variety of reasons. The ones that
> were easy to move have largely been done. What's left is the ones that
> are difficult.

I suspect even they are finding a way, as time inexorably drags on; as the way forward seems to be taking longer and longer to appear, the only way left is out.

> The reasons for wanting to use the DEC compiler front-ends is that DEC
> languages weren't terribly standards-conformant: once upon a time, the
> DEC market was big enough that the company didn't worry too much about
> those things. It isn't just additional command-line options, it's
> differences in the languages and libraries. Providing Clang for C++ and
> standard-conformant C is an addition: the DEC C will still be needed for
> historical code.

You have the source for those GCC and LLVM compilers, that you can adapt as necessary. Plus you have the source for DEC’s own proprietary compilers, that can also be adapted as necessary.

On 10/16/2021 5:36 PM, Lawrence D’Oliveiro wrote:
> On Sunday, October 17, 2021 at 12:35:10 AM UTC+13, John Dallman wrote:
>> In article <44512ead-b6e0-4735...@googlegroups.com>,
>> lawren...@gmail.com (Lawrence D_Oliveiro) wrote:
>>
>>> If VMS compatibility for user-mode code just takes the form of a
>>> library to link against, then VMS-specific compilers shouldn_t be
>>> necessary. You could use the existing GNU and LLVM compilers, and
>>> just implement wrappers that understand the VMS-specific options.
>>
>> Won't work without ludicrous amounts of effort.
>
> The question is whether that effort is more or less than that of
> porting the whole of VMS, with its deeply-embedded hardware
> assumptions dating back to VAX days, to new hardware. I suspect it’s
> a lot less.
Yes. But everybody else including those doing the actual think
otherwise.

>> The reasons for wanting to use the DEC compiler front-ends is that DEC
>> languages weren't terribly standards-conformant: once upon a time, the
>> DEC market was big enough that the company didn't worry too much about
>> those things. It isn't just additional command-line options, it's
>> differences in the languages and libraries. Providing Clang for C++ and
>> standard-conformant C is an addition: the DEC C will still be needed for
>> historical code.
>
> You have the source for those GCC and LLVM compilers, that you can
> adapt as necessary. Plus you have the source for DEC’s own
> proprietary compilers, that can also be adapted as necessary.

GCC is a no go due to GPL.

They are doing that with LLVM. Existing frontend, some existing
layers in the middle and LLVM at the backend. Because the customers
need the extensions.

Arne

In article <2e2e70e9-4e82-46b8-b7e8-74c3d08c9c73n@googlegroups.com>,
lawrencedo99@gmail.com (Lawrence D_Oliveiro) wrote:

> > Do people use FUSE NTFS on Linux for serious work, on which their
> > organisations' finances depend?
>
> I would imagine yes, at least during the transition away from
> Windows servers. Would you entrust mission-critical business
> functions to an OS that can only handle 26 drive letters?

Ah, sir is not aware that Windows has grown some useful capabilities over
the last 25 years. The Distributed File System looks a little odd, but
it's actually equivalent to an auto-mounter that needs less configuration
and it works well.

> > They need to be able to transition to a commercial-grade VMS on
> > x86-64 before they're forced to drop VMS and thus stop paying
> > VSI. So VSI need to take the route from here-and-now that
> > produces a commercial product most rapidly.
>
> Precisely my point.

So you're claiming all the VMS APIs and services can be implemented on
top of Linux, with a reasonable level of effort, by this time next year?
May I suggest you start a project to demonstrate this?

John

On Sunday, October 17, 2021 at 1:00:38 PM UTC+13, John Dallman wrote:
>> Would you entrust mission-critical business
>> functions to an OS that can only handle 26 drive letters?
> Ah, sir is not aware that Windows has grown some useful capabilities over
> the last 25 years.

“Sir” is aware that Microsoft has _tried_ to grow some useful capabilities onto Windows NT over the last 25 years. But has managed to compromise the underlying foundations in the process (look at how badly the multiuser protections were compromised in Windows XP, and the attempts to retrofit UAC to fix the mess in Vista and later). This is what happens when OS development is driven by a marketing department, as opposed to the needs of the user community.

> The Distributed File System looks a little odd, but
> it's actually equivalent to an auto-mounter that needs less configuration
> and it works well.

Samba does everything that SMB/CIFS supports, and does it on Linux, with greater configurability.

>>> They need to be able to transition to a commercial-grade VMS on
>>> x86-64 before they're forced to drop VMS and thus stop paying
>>> VSI. So VSI need to take the route from here-and-now that
>>> produces a commercial product most rapidly.
>>
>> Precisely my point.

> So you're claiming all the VMS APIs and services can be implemented on
> top of Linux, with a reasonable level of effort, by this time next year?

The sooner it is started, the sooner it is done. A year to implement the most important core user-mode APIs, as well as a DCL interpreter? May be doable, with a team of maybe half a dozen or less. If you can find the right half-dozen.

> May I suggest you start a project to demonstrate this?

You want to do a pilot? Offer an example app that you think will cause trouble, and we can go over it step by step.

On 2021-10-15, Dave Froble <davef@tsoft-inc.com> wrote:
> On 10/15/2021 2:17 PM, Simon Clubley wrote:
>> On 2021-10-14, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 10/14/2021 2:06 PM, Simon Clubley wrote:
>>
>> In addition to what I have already said, Arne's control blocks feature
>> indented code, while all your code is at the same indentation level.
>
> We must not be looking at the same code. Did you miss the "If Then Else End If"
> indentations? I guess some people can go a bit wild on such, wonder what it's
> like to read code in column 382?
>

No, but that little bit doesn't really help you with understanding the code.

>>>> BTW, Basic really does like spewing its special characters onto the
>>>> end of variable references. :-)
>
> Do you say that as a complaint, or just a comment. I find such to be helpful,
> not having to go back to check any variable declarations.
>

Comment only, as to my eyes it makes the code look a little more ugly.

But it could easily turn into a complaint if I had to type them all the time.

>>>
>>> Got to ask, just what do you think a NEXT, WHILE_END, and such statements do?
>>> Sure looks like another form of GoTo to me.
>>>
>>
>> Is code within these blocks written at an extra indentation level in
>> DEC Basic ?
>
> I do that when I feel it is appropriate. Usually in small pieces of code.
> You do that in the program mainline, and it soon becomes very hard to read.
> I'm aware of that because someone here liked to write such code, and after
> a dozen indentations, it gets rather tiresome.
>
>> It is in other languages with their control structures and it makes
>> the code much easier to read.
>
> Sometimes it is just a particular person's practice, and yours being good
> for you doesn't mean mine isn't good for me.
>

Have you ever read Dijkstra's paper on the subject of goto statements ?

https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf

Simon.

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

On 2021-10-15, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2021-10-15 17:52:25 +0000, Simon Clubley said:
>
>> On 2021-10-14, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
>>>
>>> Scrap that current design, then.
>>
>> If you had been reading comp.os.vms for the last few years Lawrence,
>> you would know that I have made multiple suggestions in exactly this
>> area. I suspect I've annoyed multiple VSI employees with my rather firm
>> negative opinions on this part of VMS.
>
> I'm somehow reminded of jwz's CADT here, too.
>
> https://www.jwz.org/doc/cadt.html
>
> DCL absolutely needs work.
>

Yes.

> So too does OpenVMS.
>

Yes.

> Linux shimulation is not going to speed the delivery of the OpenVMS
> x86-64 semi-production and production versions, nor the availability of
> native compilers.
>

Absolutely agree. Also, what Lawrence is suggesting is already being
offered elsewhere by long-established players. The fact that VSI
proceeded with a port to x86-64 VMS in the face of those alternatives
existing tells you that there was still a market for "real" VMS
when the port started.

Simon.

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