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

[Arne Vajhøj]

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.

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

Arne