[Info-vax] VMS Software: New US Mailing Address

[Bill Gunshannon]

On 10/12/22 13:36, Dave Froble wrote:
> On 10/12/2022 12:22 PM, Bill Gunshannon wrote:
>> On 10/12/22 10:03, Dave Froble wrote:
>>> On 10/12/2022 5:03 AM, Marc Van Dyck wrote:
>>>> on 11/10/2022, Arne Vajhøj supposed :
>>>>> On 10/11/2022 11:27 AM, Dave Froble wrote:
>>>>>> On 10/11/2022 9:00 AM, Simon Clubley wrote:
>>>>>>> On 2022-10-11, Marc Van Dyck <marc.gr.vandyck at invalid.skynet.be> 
>>>>>>> wrote:
>>>>>>>> The lack of attention to third party software editors is in my 
>>>>>>>> opinion
>>>>>>>> even worse than that.
>>>>>>> If so, I am surprised at that. I thought VSI were in 
>>>>>>> communication with
>>>>>>> the various third-party software developers. Are you saying that 
>>>>>>> is not
>>>>>>> happening ?
>>>>>>
>>>>>> Not sure what Marc is looking for.  I've gotten ISV stuff from 
>>>>>> VSI.  No
>>>>>> problem.  However if Marc is looking for VSI to get involved in 
>>>>>> any way with
>>>>>> marketing and sales of 3rd party software, I'm thinking VSI is 
>>>>>> fully tasked
>>>>>> with their own issues.  Can't do everything.
>>>>>
>>>>> I agree.
>>>>>
>>>>> VSI got a good ISV program.
>>>>>
>>>>> I have no reason to doubt that VSI is working with major
>>>>> third party software vendors.
>>>>>
>>>>> Oracle DB (Oracle Classic) client kit was obviously a
>>>>> disappointment, but VSI can't force Oracle to do anything.
>>>>>
>>>>> VSI does not have resources to offer engineering
>>>>> support to the smaller third party software vendors.
>>>>>
>>>>> Given the industry landscape and VSI's size, then I think
>>>>> they are doing what they can.
>>>>>
>>>>> Arne
>>>>
>>>> Most of the software packages that we are using today won't be ported
>>>> to X86. That includes, but is not limited to, Oracle Classic client,
>>>> the old Polycenter products (now owned by Broadcom), the $Universe
>>>> multi-platform scheduler, Axway Transfer CFT, etc. We're going to have
>>>> to find replacements for all that, and review all our home grown apps
>>>> to use them. So for us, no the VSI ISV program is not particularly 
>>>> good.
>>>> And I do not see any reason why we should consider ourselves as an
>>>> exception.
>>>>
>>>
>>> It would seem to me that the current owners of the mentioned software 
>>> would be
>>> responsible for porting their software, not VSI.
>>
>> I don't see where they have any responsibility to port it one way or the
>> other.  Of course, neither does VSI.
>>
>>>
>>> Have you asked these entities to provide their software on x86 VMS?  
>>> Selling
>>> their products and services is what they are about, isn't it?  If 
>>> not, then I
>>> for one do not understand what they consider their business.  If they 
>>> would
>>> desire to port their software, the ISV program would provide them 
>>> with the
>>> capability.
>>
>> And if they see the cost as far too much more than the expected ROI?
>>
>>>
>>> If the owners of the mentioned software products decline to port them 
>>> to x86
>>> VMS, then that perhaps is business opportunities for other vendors.
>>>
>>> I fail to understand why you might consider this a problem with the 
>>> VSI ISV
>>> program.
>>>
>>
>> Yeah, I see that, too.  But I also see it as yet another nail in
>> the VMS coffin as more and more people decide moving forward is
>> not really worth their effort.
>>
>> Question Dave.  If VSI had decided not to port or continue support
>> for VMS BASIC would you have ported to another language or OS in
>> order to keep your customers running?  Would you see taking on such
>> a task as your responsibility?
> 
> That would raise several questions.  But to first answer your question, 
> who else would or could port the apps to another environment?  It would 
> be the software owner's responsibility.

You keep saying "responsibility".  But what I am saying is beyond what
current versions that have been licensed/purchased they actually have
no responsibility at all.  And that was my point.

> 
> As to whether is would be advisable to port to another language and 
> environment, it would depend on the economics of the question.  Would 
> the customers be willing to finance the work?  Would the vendor be able 
> to perform the work?  I may have mentioned before, Erik: 80, Dave: 76, 
> Bill: 72, ...

And the same applies to the products that we just learned are not
moving forward to x86-64 VMS.

> 
> However the last bit is rather specific, and the general question 
> isn't.  It is a needs and economic issue.  Can something else do the 
> job?  Does the job need to be done?

Sadly, that falls on Marc's shoulders with, I imagine, very little
he can do about  it.

> 
> You like to refer to nails and coffins.  VSI is providing the means to 
> continue to use VMS.  That's all they can do.  What others do is their 
> own business, and could affect the viability of VSI.

As has been stated before (even recently in this thread) no one
buys an OS for the OS.  They buy it for the applications.  If the
applications disappear,  how long will the OS survive?

> 
> I have to wonder if the general entitlement mentality that seems to be 
> so widespread isn't happening with such issues as raised by the OP.  
> Back in the day, if one needed something, one found or produced it.  
> When a software vendor noticed a business opportunity they sought to 
> pursue that opportunity.  Seems now some want everything handed to 
> them.  Seems some software vendors want customers to use what they 
> offer, not to produce what the customer asks for.

Depends on which side of the fence your standing.

As a side note, although that ship has sailed and I don't see any
way back, this was a very strong argument for the days when businesses
wrote their own applications and didn't rely on people with no vested
interest in your survival.

bill