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

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Wed Jul 12 10:32:45 EDT 2017


On 2017-07-12 02:11:08 +0000, David Froble said:

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

That's a fairly classic approach.   More than a few places build 
continuously, and use bots or scripts to test the results for 
regressions.

> 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.

It's fairly common to see some systems require rebuilds on each 
upgrade.   Less popular with some folks, though workable for targeted 
and embedded configurations.   Downside is that you need everything 
ready before you can perform the upgrade.

> 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.

That's what I've been referring to as abstraction, obviously.   I 
really don't care about details such as which databases are used for 
credential storage, or how long a username is, etc.   OO gets 
developers around having to deal with the next level up of abstraction 
from that provided by the existing OpenVMS storage and the existing 
OpenVMS APIs such as $setuai and $getuai and $hash_password; of details 
such as the limits that itemlists provide around the username length 
limits or the password hash size fields.  It's a blob of data, but a 
blob that requires developers to use access routines (methods) to proxy 
access to that data.   Those proxy routines also mean that the data 
doesn't necessarily even have to be retrieved from storage into the 
blob until needed, that the application source code doesn't need to be 
rebuilt, and that it can be possible to rework or extend those routines 
to provide additional or application-specific processing.


-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list