[Info-vax] links and deleting directory trees (Re: Some questions on software for VMS 7.3 VAX)

[Stephen Hoffman]

On 2016-01-22 19:11:20 +0000, Craig A. Berry said:

> On 1/22/16 9:28 AM, Stephen Hoffman wrote:
>> 
>> This is another example of a command or a routine that can do different 
>> things based on some compatibility setting(s) located elsewhere.
> 
> Yes, and even more to the point considering how the discussion got here 
> is whether PCSI REMOVE, DELETE/TREE, and/or DFU DELETE/TREE have 
> explicit designs around whether to follow links and what kind of links, 
> or whether what you get is just the random intersection of the evolving 
> behaviors of the lower layers.

Ayup.   Try defining a few DECC$ logical names, and watch other random 
hunks of code go deep into the weeds with odd errors.

Except through utter isolation of the applications and careful 
management of the upgrades, the current programming environment is 
neither stable, reliable, predictable, nor easily understandable by 
anyone not steeped in the OpenVMS origin and history, and the API 
complexity is only getting worse.

When hauling around software among various systems, anything from a 
system parameter change to a logical name to some random disk setting 
can derail the application code.

That's without discussing the subtle and pernicious effects of actual 
system configuration errors — I'm increasingly checking process quotas 
and system parameters and some of the logical name knobs at application 
startup.

There's no clear list of this stuff anymore (if there ever was?), and 
the the mechanisms and controls and knobs used to ensure that old code 
still works — at the expense of new code — are all over the place.

Application porting among OpenVMS systems — a subset of app stacking — 
is just one system-wide DECC$ logical name away from run-time chaos.

Usual solution for compatibility?   Add knobs and APIs and run-time 
checks, and throw it all over the wall and let somebody else figure it 
out when — when, not if — it breaks.

Design abdication.

> I would expect a tool designed to delete a directory tree to remove 
> links but not follow them, at least by default, and in the case of PCSI 
> I would expect it to only remove whatever it installed, whether that's 
> both the link and the target or only the link.

Ayup.   But then the GNV kit added features such as source savesets 
that are optionally unpack manually — which means those files are 
understandably and completely and arguably entirely correctly out of 
scope during GNV product removal, but that's very likely not what the 
user intends or expects here, either.   PCSI doesn't have a particular 
way to add files or dependencies after installation, and OpenVMS 
doesn't have a way to package applications for easy removal.

I really do like what OpenVMS was, but it's not at all what OpenVMS is 
now, and nobody (outside of VSI, maybe) has any idea of where OpenVMS 
is going.


-- 
Pure Personal Opinion | HoffmanLabs LLC