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

[David Froble]

Simon Clubley wrote:
> On 2017-07-10, David Froble <davef at tsoft-inc.com> wrote:
>> Now, for data layout, if the data structure is included in VMS, and "ALWAYS" 
>> used as-is, and no expectations are made on data size, then after a fresh 
>> compile and link, you got the new sizes, and it's up to you what you do with 
>> them.  VMS can make changes.  If they are incompatible with your code, that's 
>> "your" problem.  Fix it.
>>
> 
> So in your way of doing things, every single program would have to
> be recompiled after every single VMS upgrade before they could be used
> in that new version of VMS. That's a rather "unique" way to handle
> compatibility issues.
> 
>> If you're using Basic and dynamic strings, what's the problem?
>>
>> :-)
> 
> You might want to think about this a little bit more...
> 
> Simon.
> 

The Codis system, which is rather large, can be re-built, on each customer 
system, every night, if required.

It's just the way we approach things.  If you don't have sources, and if you 
cannot re-build them, then you have an application that is doomed to extinction.

I'm not saying that everything must be re-built after a VMS upgrade.  However, 
VSI must have the freedom to implement new features, and if there is a need to 
use these new features, then yes, a simple re-build is a cheap price to pay.

As an example, SYSUAF.DAT.  If there was a library routine, or whatever, to 
return the data in some data structure, then one would not need to read the RMS 
record(s).  A bonus would be that if one of Steve's databases was implemented to 
contain all (or most) OS type of data, it would be transparent to the users. 
You call would still give you the SYSUAF data, and VSI would be free to make the 
password data any size they wished.  Now, if someone mentions writing into a 
SYSUAF record, well, I don't do that, I would never do that, nor do I feel 
anyone else should ever do that.