[Info-vax] New CEO of VMS Software

[Arne Vajhøj]

On 1/5/2024 1:20 PM, bill wrote:
> On 1/5/2024 1:17 PM, Arne Vajhøj wrote:
>> On 1/5/2024 1:01 PM, bill wrote:
>>> On 1/5/2024 9:08 AM, Arne Vajhøj wrote:
>>>> On 1/4/2024 11:44 PM, Lawrence D'Oliveiro wrote:
>>>>> On Fri, 5 Jan 2024 03:09:37 -0000 (UTC), Dan Cross wrote:
>>>>>> I think, again, you are talking at cross-purposes: my suspicion is 
>>>>>> that
>>>>>> Arne is referring to a VMS compatibility layer built on top of Linux,
>>>>>> not the effort of porting VMS to x86_64.
>>>>>
>>>>> I thought I made it pretty clear early on that I was only talking 
>>>>> about
>>>>> porting across userland executables and DCL command 
>>>>> procedures--just the
>>>>> parts of VMS that users care about, nothing more.
>>>>
>>>> If the goal is 90% compatibility, then it is reasonable easy and
>>>> low cost. But no customer demand.
>>>>
>>>> If the goal is 100% compatibility, then it becomes tricky and 
>>>> expensive.
>>>>
>>>> There will be both some hard problems and a gazillion trivial problems
>>>> to deal with.
>>>>
>>>> Let me be specific. It is not difficult creating functions named
>>>> LIB$GETJPI and SYS$GETJPIW accepting certain argument. But what are
>>>> they going to return when asked for an item that does not exist
>>>> on Linux?
>>>>
>>>
>>> What would they return if asked for an item that does not exist on VMS?
>>
>> SS$_BADPARAM I believe.
>>
>> But returning that for items codes working on VMS could
>> easily break code.
> 
> Times change.  Sometimes code needs to as well.  :-)

Yes.

But the point is that most companies don't want to
migrate from VMS to a VMS emulation environment and
still have to modify the code because the emulation
is only 90% - they stay at VMS or modify the code
to run natively at another platform.

Arne