[Info-vax] DCL Syntax

[Stephen Hoffman]

On 2018-08-30 01:54:44 +0000, Craig A. Berry said:

> On 8/29/18 5:46 PM, Arne Vajhøj wrote:
>> On 8/29/2018 2:45 PM, Bill Gunshannon wrote:
>>> On 08/29/2018 02:33 PM, Stephen Hoffman wrote:
>>>> On 2018-08-28 18:54:54 +0000, John Reagan said:
>>>>> You need the /TREE qualifier for DELETE to match the behavior. 
>>>>> (Personally, it should have been /RECURSIVE and not /TREE but nobody 
>>>>> asked me)
>>>> 
>>>> The use of /TREE was likely related to one of the more common tools 
>>>> used for this purpose: DELTREE.
>>>> 
>>>> And yes, /RECURSIVE would likely have been a better and more obvious 
>>>> choice here.
>>>> 
>>>> You and the other folks at VSI are also in a position to do something 
>>>> about that and about other DCL syntax, too.
>>> 
>>> Yes, but considering the potential impact on existing already written 
>>> procedures is it worth making little cosmetic changes like this when 
>>> everyone (even me) understood the old meaning?
>> 
>> Add /RECURSIVE, document /RECURSIVE, remove /TREE from documentation 
>> but keep /TREE working.

There's no particular reason to go after this or any other isolated 
qualifier qualifier right now.  Not without some other associated 
updates and improvements.

That written, rote compatibility is a very poor reason for keeping bad 
or limited or outdated designs and implementations around.  That path 
only leads to clutter and confusion and constraints.  Which is what we 
have, in a number of areas not the least of which is 64-bit virtual 
addressing.  And certificate authentication, CDSA removal, and data and 
application run-time security and app and data isolation in general.   
But these and other changes cannot be made arbitrarily nor 
capriciously.  When overhauling areas of the operating system, there 
needs to be obvious and beneficial and preferably customer-desirable 
reasons to make up for any incompatible changes that might be required. 
  Reasons for folks to upgrade, not the least of which will be x86-64 
support.

Just because we current users and current developers had to go through 
a multi-year and on-going effort to learn what can be a poor or limited 
API, or where we all used what are now insecure designs, or what is an 
increasingly absurd and complex pile of glue code to get our 
development work done?  That does not mean that new ISVs and new 
developers are going to want to do that.  It does not mean that we 
ourselves want to continue to use those old APIs and tools with that 
code which we are maintaining, and the new code we're writing.

And if we're at an organization that is not actively maintaining our 
source code, then we're also decreasingly likely to be upgrading our 
operating system versions.

In this particular DCL case and as has been mentioned, /TREE can easily 
be aliased.  But I'd think VSI has other and much higher-priority work 
already present in what can only be a prodigious backlog.  And the 
occasional technical surprise.  Such as Japanese timekeeping, for 
instance.  
https://blogs.msdn.microsoft.com/shawnste/2018/04/12/the-japanese-calendars-y2k-moment/ 
  Or the ongoing efforts involved with hauling pieces and parts forward 
to TLSv1.3 support.

> No one with any sense would use anything except MCR DFU DELETE/TREE for 
> this purpose; it's massively faster than the DELETE/TREE implemented by 
> HPE.

Ayup.  OpenVMS I/O needs a complete overhaul, beyond the now-postponed 
work on VAFS and 64-bit sector addresses and 4 KB sector sizes.  
There've been earlier newsgroup discussions of hardware-related work 
including (hypothetically) adding NVMe I/O and byte-addressable 
storage, too.  The sheer scale of a modern, feature-competitive server 
operating system is not to be underestimated.

Just because any of us were willing to learn a particular API — and 
many of us have spent decades learning OpenVMS and its incantations and 
its glue code, often piecemeal — does not that mean that other folks 
will be nearly as willing to make that same investment of focus and 
time.  Nor does it mean that any of us won't have to learn new 
approaches.  Change and churn is part of IT.   In the tech.  And in the 
expectations.

self: ponders how the OpenVMS port of rm and the rm -rf command might 
compare to DELETE /TREE.



-- 
Pure Personal Opinion | HoffmanLabs LLC