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

[David Froble]

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.

Well, not just for DCL.  Have defined blocks of data for each system service. 
Either I allocate the memory, (probably best) or have the system service 
allocate the memory.  Then jam it full of all data provided by that system 
service.  Sure would do away with item lists, at least to some extent.

If I can "include" the data structure in my programs, and then reference the 
data by name, sure would make things simpler.