[Info-vax] Reimplementing VMS, was: Re: HP adds OpenVMS Mature Product Support beyond the end of Standard Support

[David Froble]

Simon Clubley wrote:
> On 2014-01-31, Craig A. Berry <craigberry at nospam.mac.com> wrote:
>> On 1/30/14, 3:44 PM, Keith Parris wrote:
>>> The OpenVMS doc. set is insulted by being compared to man pages. :-)
>>> Take a look for yourself, at http://h71000.www7.hp.com/doc/os84_index.html
>>>
>>> It provides a detailed description of all the APIs -- both system
>>> services and run-time libraries. There is enough detail that you know
>>> exactly how VMS is supposed to act, and enough that you wouldn't have to
>>> know how VMS itself does it in order to replicate the same behavior.
>> The VMS docs are great, but even with VMS the reference implementation
>> is the only authority for how things actually work. Just the other day I
>> got a return value of SS$_INVFILFOROP from SYS$CHECK_ACCESS, which is
>> not one of the documented return values for that service. Surely there
>> are dozens or hundreds of corner cases like that such that a
>> reimplementation from the docs would have lots and lots of subtle
>> differences that would make bringing over to NewVMS an application of
>> any complexity difficult and risky.
>>
> 
> I'm not seeing the problem here.
> 
> If NewVMS only returns the status values published in the public VMS
> documentation, then code written to the public documentation specification
> will work ok. At worse you would have redundant code in the user
> application to handle a extra status value not returned by NewVMS.
> 
> OTOH, if the user application was using the unpublished status value
> instead of the published one then you could have a problem, but that's
> the kind of application which could break on a VMS upgrade if they
> relied on undocumented features.
> 
>> This assuming that the gigabucks and/or scores of well-qualified
>> volunteers with lots of time on their hands suddenly materialize.
> 
> You also need to either find people who have not been contaminated by
> access to the VMS source code or to be able to demonstrate a development
> methodology by which none of that contaminated information was used
> in NewVMS.
> 
> I keep going on about this contaminated information concept because it's
> _very_ _very_ important in a project of this nature and needs to be
> handled as part of the project management.
> 
> Simon.
> 

I see where you're going with "contaminated".  I'm not sure how much of 
an issue it may be.

I'd guess that if such issues arise, the fight would occur in the USA. 
At such a time, it might depend more on politics than law.  Sure, if 
there is specific documents that an individual signed (contract), then 
it might be simple.  Otherwise, things become more tangled.

On of the flaws of the US justice system is, you don't have to have a 
valid case in order to file a law suit, and if the defendent doesn't 
contest it, you can get a default judgement.  Yeah, it's that screwed up.

Probably most of the time, the law will defend an individual's right to 
work at a job.  Unless it violates some specific contracts.

Otherwise, I'd guess (not that that means much) that any burden would 
rest with the party bringing the suit, and and such burden might be 
rather heavy.

So yeah, if there are specific contracts, though most have time limits, 
there could be issues, but otherwise, I doubt there would be any way, in 
the USA, of stopping an individual from obtaining work using his past 
skills.  Other than spending a bunch of money on harassment.  Somehow, I 
don't see HP spending any money on VMS.