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

[Stephen Hoffman]

On 2016-06-29 20:20:13 +0000, John Reagan said:

> But it isn't just breaking a few programs, I think it is breaking most 
> programs.

Yes.  Leave those folks on the old RTL.

> As I mentioned the other day, you can get the current CRTL to be very 
> UNIXy with DECC$UNIX_LEVEL set to 90.  It "fixes" the basename() issue 
> for example by flat-out disallowing VMS filespecs.  Sound good, eh?  
> Nope.

It'd seem a whole lot better if there were some easier-to-inline 
filename conversion routines, and not the wonderfully-named and 
artfully-arcane decc$to_vms and decc$from_vms calls.

> I do want to toss lots of stuff.  We just have to be smart about it.  
> And I have to still worry about users of __VMS_VER and 
> __VMS_VER_OVERRIDE who want to have the current headers behave like 
> they used to behave (I could solve that with dual sets of headers but 
> that has its own set of nightmares).

Leave those folks on the old RTL.   Maybe even hint at plans for its 
eventual deprecation, just to light a fire under some few posteriors.  
Preferably with a shorter expiry for existing code using VAX C RTL.

> Besides the headers, there is also the years of stuff in the compiler. 
> I've pointed out /STANDARD=VAXC before as something people need to stop 
> using. Other standard values like MS and MIA are on the chopping block 
> as well.  Several of the /ASSUME options don't have value.  Who uses 
> /ASSUME=NOTRIGRAPHS for example? /PRECISION? /EXTERN=VAXC?  
> globalref/globaldef/globalvalue?  Other /EXTERN models besides strict 
> refdef? Heck, we've even talked about removing VAX floating support?  
> Any takers on that one?  Some of these features make the headers/RTL 
> more complicated.

There are no easy choices here.  Never have been.

There's never enough in the budget, either.

VSI can do what was done before.  Or can try some new approaches.

VSI can continue with the strategy that has failed existing OpenVMS 
users over the long term — yes, even failing those same users that 
repeatedly requested and demanded this compatibility — or VSI can start 
to re-think the core tenets, and start to haul those same customers 
forward, and can make OpenVMS much more interesting to new customers.   
So long as VSI changes stay sufficiently below the effort of an 
application port off of OpenVMS — and deliver benefits, and can start 
to deliver on the "OpenVMS is secure" message VSI marketing keeps 
using, for instance — VSI has some room to work, particularly if the 
new system and application code is fundamentally better and more 
capable.

OpenVMS started out far closer to the forward edge of computing and 
capabilities and user interfaces and consistency, and a better solution 
for IBM network connections than even IBM itself, with well-integrated 
features including security and networking, with greater ease of 
programming, and a number of other positives.    It's this legacy that 
most folks here remember, too.  Now?  The future of OpenVMS itself — 
and those same customers currently using it, as well as VSI — is 
utterly subservient to folks that never want to change their code, even 
for good and valid reasons.   OpenVMS fundamentally trails other 
platforms in many ways — C standard support being one of many such 
areas — making it a poor choice for green-field development.

Keep doing what OpenVMS development has always done before, and we 
_all_ know where that will end.

Where does this go?  Your call.



-- 
Pure Personal Opinion | HoffmanLabs LLC