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

[JohnF]

Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> On 2014-02-04 16:55:05 +0000, JohnF said:
> 
>> Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>>> On 2014-02-04 14:48:20 +0000, JohnF said:
>>>> Thanks. P.S. Got any free ones?
>>> haha that's just so cute.
>> 
>> Why? There are quite a few enormous projects available for free.   Of 
>> course, the demand for a "vms api" is probably insufficient to attract 
>> any serious gpl development effort.
> 
> Why?
Why what???
You yourself say below, "Demand for that [openvms] is low..."
So why would you ask "why" about what we both said?

> Have at, then.
I already pointed out in earlier post that I did
port a few old programs, but haven't written
a call-compatible migration library.

> Most folks getting into this area of development are seeking to recoup 
> the costs of the effort.
> 
> Sure, there are some ginormous free packages around, but those usually 
> "scratch an itch" that more than a few folks share.
> 
> For OpenVMS?   Demand for that is low, the effort involved in even a 
> small emulation is high ? we're right back to discussing and dealing 
> with some fraction of the 25+ million lines of code present in OpenVMS 
> that's involved in any rewrite-port project that's been discussed, and 
> that's before the layered products are in play, and the API code 
> coverage (overlap) and the OS-dependencies among different and disjoint 
> applications is low.  Then toss in dealing with dependencies on Oracle 
> Rdb or some other third-party product.  For somebody that's doing this 
> sort of compatibility stuff locally and privately, it's also becomes 
> the choice of just rolling the changes directly into the source code, 
> as compared with trying to keep the source code API-compatible with the 
> OpenVMS API designs.
> 
> I do know of some folks that do source-to-source translations using 
> their own tools, but AFAIK they don't handle RTL or system service 
> calls or related VMS baggage.

So exactly what do they handle? Got to be something that's
vms-specific, doesn't it?
   Besides, like I suggested in earlier post, some vms stuff
should be pretty straightforward, e.g., event flags/clusters,
global sections, mailboxes, logical names. Much of the rtl
stuff, like most of the str$ stuff (excepting the fao stuff),
is also pretty straightforward, or even already available.
   And the idea would be to start an open source library
that's an extensible framework. You add what you additionally
need for your own ports to what's already there. Then it builds
up over time. Maybe, or maybe not, some "calling standard"
would be useful.

> Or put another way, if there were a cheap or free way to migrate, HP 
> would be pointing folks at it.   If you find a freebie with more than a 
> little coverage, post it.   Or if you want to invest in creating 
> something of the scale of one of these platform emulations and then 
> give it away, well, maybe have a look at helping the FreeVMS folks?  
> But expecting to find free porting tools?  Um, OK.  Good luck with that.

-- 
John Forkosh  ( mailto:  j at f.com  where j=john and f=forkosh )