[Info-vax] DCL Syntax

[Arne Vajhøj]

On 8/30/2018 11:54 AM, Stephen Hoffman wrote:
> 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.

I disagree.

Given the current situation for VMS then I find it very important
for VMS to stay very compatible. VMS does not have too many customers
and we need to keep those. Of course getting 10x more new customers
is better than just keeping old customers. But I would wait
acting on that until all those new customers are actually lined
up.

And even later then I think backwards compatibility is important.
It is about the market VMS will compete in. VMS will not compete
with Windows on desktop, Android on phones etc.. VMS will probably
not focus mass market server like web servers running just Apache.
VMS will probably focus on higher value stuff (note that this
is still a much broader market than the disastrous targets
set in the 90's and 00's). In this market long term support
and backwards compatibility matters. IBM, Microsoft, Redhat etc.
all does it to some extent.

Arne





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