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

[David Froble]

Stephen Hoffman wrote:
> 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

"C" (fixed it for you)

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

Rather scary ...

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

The more you point out, the more I agree with your intense dislike of using 
logical names to affect V language behavior.

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