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

[Stephen Hoffman]

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.
> 
> There is a strong argument for an easier than currently exists method 
> to get at this data, but there still needs to be some level of 
> abstraction in order to be able to handle these issues.
> 
> Oh, and for something like this, if it was done anyway, there's no way 
> you should pass in the memory to be used. For a structure this complex, 
> VMS would need to control the memory it was writing to for safety 
> reasons and that means it allocates the memory and returns a pointer to 
> it.
> 
>> 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.

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 just don't see some of the VAX-era designs and compromises being 
particularly beneficial to folks.    But then experience with Xcode and 
Objective C changed how I view a number of areas of development, too.


-- 
Pure Personal Opinion | HoffmanLabs LLC