[Info-vax] decc$stat() variants on VMS.

[Stephen Hoffman]

On 2016-06-30 02:29:34 +0000, Craig A. Berry said:

> On 6/29/16 2:50 PM, Stephen Hoffman wrote:
>> 
>> Nuke^Wdeprecate the whole mound, replace it with flat 64-bit, and move 
>> on.  You're *never* going to be able to remediate a couple of decades' 
>> accumulated cruft^Wcompatibility.  *Never*.   Not without breaking 
>> something else dependent on the existing bugs^Wbehavior, and not 
>> without further degrading the existing code into yet denser thickets of 
>> cruft^Wconditional compilation.
> 
> Yeah, but you have to try. There are two ways to do it that are 
> definitely wrong. One is to add layer upon layer of backward 
> compatibility without ever deprecating and removing dead code so that 
> you end up with mountains of technical debt (more or less what we have 
> now). The other is to break with the past so abruptly that existing 
> users have no reason to upgrade or even stay with your product.
> ...
> It's far from easy to maintain a predictable sliding window of new 
> features and deprecations, but it's the right way to do it. It's what 
> the competition does.

Ayup.   For most cases, I'd agree.   If you're going to break 
application compatibility — if you're going to wade into any specific 
areas of OpenVMS and really start to fix things and to improve OpenVMS 
— then change enough of the related pieces in that area to get where 
and what you want to have.  Don't dribble out the breakage in any 
single area.  Break it, then dribble out compatible updates and 
compatible enhancements.

In this particular case, the accreted layers of compatibility have 
solidified such that any incremental migration likely won't finish in 
the next decade and probably won't finish in the next quarter-century, 
and that's assuming that VSI adopts modern release cycles and 
schedules.  We'll all be playing Whac-A-Mole with the scale of changes 
involved here.

"We're adopting {most of} {C11 / Fortran 2015 / COBOL 2014 / VSI BASIC 
PLUS 64 / etc}.  Here's why...   Here's how you can, too..."

Implementing source code translation tools is likely too far outside of 
what VSI has funding and staff for, unfortunately.

Leave the old code on the old RTLs and old standards around.   Give'm a 
decade to migrate, or some such.

Precedent: K&R C to ANSI C, FORTRAN to Fortran, etc.  The old bits were 
never expunged, though.

If VSI doesn't or won't or can't change OpenVMS fast enough to become 
competitive, then it'll never get where VSI can change OpenVMS fast 
enough to keep competitive.   Which means new adoptions and new 
partners and wholly new deployments will be limited at best.  Which 
means apps age out.  Which ends badly for those folks that want and 
need OpenVMS, and for VSI.


-- 
Pure Personal Opinion | HoffmanLabs LLC