[Info-vax] DCL Syntax

[Arne Vajhøj]

On 8/30/2018 3:58 PM, Stephen Hoffman wrote:
> On 2018-08-30 17:47:09 +0000, Arne Vajhj said:
> 
>> On 8/30/2018 11:54 AM, Stephen Hoffman wrote:
>>>
>>> There's no particular reason to go after this or any other isolated 
>>> qualifier qualifier right now.  Not without some other associated 
>>> updates and improvements.
>>>
>>> That written, rote compatibility is a very poor reason for keeping 
>>> bad or limited or outdated designs and implementations around.  That 
>>> path only leads to clutter and confusion and constraints.
>>
>> I disagree.
>>
>> Given the current situation for VMS then I find it very important for 
>> VMS to stay very compatible
> 
> For not the first time, that approach is what got OpenVMS where it is 
> now.

I don't think so.

I think VMS is where it is now due to lack of investment in new features
(and lack of marketing).

 > In retrospect, causing OpenVMS users to expect complete upward
 > compatibility was one of the worst decisions that DEC OpenVMS
 > development ever made.

I think most of VMS'es problems came from outside of development.

:-)

>                                           That way ends nowhere else.
>                                This fixation with complete and utter 
> upward compatibility is poison.  Utter, unmitigated, untenable poison.

Many other successful systems to have no problems keeping old bagage
and still evolve. From IBM mainframe to Unix to Windows.

> There are and will be areas that absolutely have to be broken to move 
> the platform forward.  To secure the platform.  To provide the features 
> needed to be competitive.
> 
> There are other areas of OpenVMS that really need to be broken and fixed 
> and won't be, at least for the foreseeable future.

> Fixing some of these current messes is absolutely and fundamentally 
> incompatable with upward-compatibility and API stability, no matter how 
> hard y'all wish it to be otherwise.
> 
> Is VSI going to want to break very much?  Of course not.  But — for not 
> the first time — there are areas of OpenVMS which can only move forward 
> by breaking APIs.

There may be some areas where they may need to break some things.

But I believe that the vast majority of changes can and should be
done without breaking (user mode) backwards compatibility.

If we look at the list I just replied to DF with:

#* bunch of new system services and RTL functions for what
#  is needed today (we recently discussed LIB$HTTP(S)_*)

Should not imppct old functions.

#* better 64 bit handling

This may require some smart thinking to do and still allow
old stuff to run, but I think it can be done.

#* new file system that:
#  - removes current limits
#  - improves performance
#  - are more *nix/Windows compatible

New file system should not break old ones.

#* new user authentication model:
#  - more secure password storage
#  - better integration with external user management systems

Again this may require some smart thinking, but again I think it can
be done.

#* command language with more features including loops and arrays

Adding a new command language and keeping DCL or extending
DCL are both possible.

#* GUI management tools for all system administration

WIll not break the old command line ways.

#* C, C++ and Fortran compilers uptodate with current language standards

Keeping old compiler or have a /OLD (I think /STANDARD=version is the
usual way to do it) are both possible.

Arne