[Info-vax] Access to _all_ VMS system services and library functions from DCL ?

[Jan-Erik Soderholm]

Den 2017-07-12 kl. 16:04, skrev Stephen Hoffman:
> On 2017-07-11 02:34:27 +0000, Arne Vajhj said:
> 
>> On 7/10/2017 12:21 PM, Stephen Hoffman wrote:
>>> On 2017-07-10 08:26:00 +0000, mcleanjoh at gmail.com said:
>>>> I'm sure we've been around this block on other occasions but given how 
>>>> memory has expanded enormously since VMS v1.0, why not simply return 
>>>> ALL the relavent data in one large data structure and let the users 
>>>> deal with whatever fields they want to use?
>>>> I'm sure there's some smarts in the processing of what might be 
>>>> multiple item codes but simply copying all the relevant data into a 
>>>> single data structure for the user has to surely be the simplest.
>>>
>>> Ayup.  Traditional DCL is not the path forward.   Sure, access to system 
>>> services is nice, but that's just not competitive.   Easier access to 
>>> system services looks wonderful in comparison to where we are now, 
>>> certainly.
>>>
>>> But then we start looking at dealing with modern text encodings, with 
>>> the minutia of the system service APIs, and the rest of the knock-off 
>>> effects — well, why not integrate and use Python.   Maybe Lua or some 
>>> other choice, if there's some problem perceived with Python or some 
>>> benefit to offering an alternative.
>>>
>>> This whole approach — accessing system services — utterly stinks of 
>>> decades-old thinking, decades-old designs, decades-old processing. Which 
>>> works great if you're (only) solving the sorts of problems that OpenVMS 
>>> has always dealt with, but DCL and the system service abstractions are a 
>>> huge code slog, and code slogs are expensive and tedious and lots of 
>>> user-written code to debug and maintain.
>>>
>>> If VSI decides to fund more than some nibble around the edges of the 
>>> existing command interface, and to overhaul the text handling and 
>>> traditional APIs. then a shell that's more competitive PowerShell is a 
>>> much better target than an increasingly-encumbered DCL shell.  Passing 
>>> around entire (opaque) objects, and not atoms of data and fields 
>>> embedded in fixed-format seas of characters.  Much nicer abstractions, 
>>> and easier for VSI to adjust and extend going forward.   We've long ago 
>>> found better ways of dealing with password fields than fixed-format 
>>> records and fixed-length system service itemcodes for the password 
>>> hashes, for instance.   Give folks a reason to move forward.  Leave DCL 
>>> to do what it has always done, and to slowly and further fade from 
>>> relevance.
>>
>>> We can either get DCL dragged forward kicking and screaming into the 
>>> early part of this millennium and with a near-inevitable morass of UTF-8 
>>> hackery and the requisite technical debt inevitable with 
>>> upward-compatibility, or we can get something better aimed at what we're 
>>> going to be doing in 2027, and leaving DCL to quietly graze out in some 
>>> code-pasture out behind BoltonHQ.   Well, that for those of us that 
>>> aren't already or aren't planning to retire in place, and with apps that 
>>> are similarly retired.
>>
>> Yes but no.
>>
>> Yes - I agree that VMS needs a new scripting language and VMS needs new 
>> API's.
>>
>> No - I don't think having the new scripting language only support the new 
>> API's will work. Some interoperability is needed for a transition period 
>> of 1-2 decades.
> 
> So your suggestion is to drag DCL forward, adding more complexity and more 
> hackery and more cruft to the design, all in the effort of providing 
> something that DCL itself has never done?   This in addition to a 
> replacement?   This is the path for getting DCL further entrenched, and to 
> delay work and development of the new design, and to make the new 
> environment less interesting.  That's not the path toward a pleasant 
> retirement for the DCL environment, continuing to do what it's always done.
> 
>>> TL;DR: DCL and traditional system services APIs just aren't going to be 
>>> interesting for folks looking for platforms for new apps.
>>
>> Not directly. But I guess they prefer a few people that understand 
>> something on the new VMS instead of zero people.
> 
> Any new idea or new solution initially has zero people.   Then the 
> designers and implementation and documentation folks.   Then the partners 
> and the end-users.   If the new design or API or interface makes it easier 
> or faster or simpler or whatever the design is being optimized for, it'll 
> attract attention and usage.   DCL, not so much. Some sort of OO DCL with 
> UTF-8 support would be a sea of compatibility issues and some really ugly 
> code, too, because just as soon as it's called "DCL" there's going to be a 
> demand that it still run the existing code with minimal or no changes.  
> This'll have knock-off effects around text encoding, among other details.
> 
> I'd rather see any new CLI design be able to decently deal with what DCL 
> does now, as well as with 2027.
> 
> For general scripting, integrating Python and Perl into the base distro 
> would plug some holes, and allow a few projects to remove dependency checks 
> and prerequisites, too.   But VSI somehow can't get around an 
> administrative blockage presently preventing Perl and Python in the base 
> distro, and I have to wonder what the strategy or the constraints leading 
> to that decision might be.
> 
> It's been decades since OpenVMS has had gotta-have-it features that really 
> get masses of folks to upgrade.   On the VSI development schedule, the 
> x86-64 port and its accoutrements look like the first one of those on the 
> roadmap.   Then... what?
> 

I do not see it as DCL *or* something else. More DCL *and* something else.

I do not see the issue with having a DCL routines that does:

$ DEFINE ...
$ COPY ...
$ and other classical DCL constructs
$ python
import rdb
import something-else
do whatever Python is good at...
$
$ continue with the DCL scripting...


Or of course:

$ DEFINE ...
$ COPY ...
$! and other classical DCL constructs...
$!
$ python myscript.py
$!
$ continue with the DCL scripting...

Could be perl or someting else of course and
it would work much like extensions to DCL.

This is more flexible then to trying to modernize DCL itself.