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

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



-- 
Pure Personal Opinion | HoffmanLabs LLC