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

[John Reagan]

On Monday, July 10, 2017 at 3:46:22 PM UTC-4, David Froble wrote:
> Stephen Hoffman wrote:
> > On 2017-07-10 08:26:00 +0000,  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.

Some of that data is expensive to obtain.  I don't think you want SYS$GETJPI to collect all possible data just so you can check the account name or CPU time consumed.  And the layout then gets fixed for all time so the OS would have an even harder time to expand the username beyond 12 chars for example.