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

[Simon Clubley]

On 2017-07-11, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> On 2017-07-11 07:00:51 +0000, Simon Clubley said:
>
>> On 2017-07-10, David Froble <davef at tsoft-inc.com> wrote:
>>> 
>>> 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.
>>> 
>> 
>> A single block of data which is directly accessed is too limiting and 
>> will cause massive maintainence problems as structures are changed and 
>> field sizes changed in the future.
>> 
>> This will lead to a different version of the data block for every 
>> change in the future and all these versions would have to be kept 
>> around in the future as well as the code to populate them.
>> 

[snip]

>> 
>>> If I can "include" the data structure in my programs, and then 
>>> reference the  data by name, sure would make things simpler.
>> 
>> And what about when the data block is changed because a field is 
>> expanded (for example) ?
>
> If the block is opaque to the end user ? similar to how BASIC tends to 
> treat descriptors, scaled up to cover the system service data returned 
> by itemlists  ? it'll work very close to what David is considering.   
> Add in the ability to delay accessing the underlying data until its 
> requested by the user and the storage and performance details are far 
> less egregious than fetching everything.
>

Unfortunately, I got the distinct impression that David and others were
looking for something similar to a giant struct to be returned without
any layers of abstraction and for the variables within the struct to be
directly accessible by the application.

> Yes, there's overhead on message-passing designs such as where David is 
> headed here, but there's overhead in writing and processing itemlists 
> too.   Trade-offs can change over time, and the holes in the existing 
> OpenVMS design ? from back when memory was tight and processor 
> performance was lacking ? are quite apparent.
>

I've never seen David advocate for message-passing and OO designs before.
David tends to advocate for a very different style of coding.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world