For those of you mailing payments or packages to VSI, they have posted
a new mailing address:

6 Liberty Square
PMB # 294
Boston, MA 02109

That's a FedEx ShipCenter in downtown Boston.

--
Pure Personal Opinion | HoffmanLabs LLC

On 10/5/2022 5:41 PM, Stephen Hoffman wrote:
> For those of you mailing payments or packages to VSI, they have posted a
> new mailing address:
>
> 6 Liberty Square
> PMB # 294
> Boston, MA 02109
>
> That's a FedEx ShipCenter in downtown Boston.

That probably relates to this announcement:

https://vmssoftware.com/about/news/2022-10-05-vms-software-moves-to-boston/

Arne

On 2022-10-05, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 10/5/2022 5:41 PM, Stephen Hoffman wrote:
>> For those of you mailing payments or packages to VSI, they have posted a
>> new mailing address:
>>
>> 6 Liberty Square
>> PMB # 294
>> Boston, MA 02109
>>
>> That's a FedEx ShipCenter in downtown Boston.
>
> That probably relates to this announcement:
>
> https://vmssoftware.com/about/news/2022-10-05-vms-software-moves-to-boston/
>

Interesting. On the one hand, that's good news, but on the other hand,
a job title that includes "Revenue Enablement" ?

I wonder what that translates to in "normal" English ? :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <thmj7k$3c8u4$1@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> a job title that includes "Revenue Enablement" ?
>
> I wonder what that translates to in "normal" English ? :-)

So that's "Vice President of GTM Strategy & Revenue Enablement" which
expands to "Vice President of Go To Market Strategy & Revenue
Enablement".

I think that's "Vice President for Sales" in old-fashioned language.

I have dealt with an IBM department of "Software Enablement", which was
actually about getting ISVs to port their products to AIX.

John

In article <thmj7k$3c8u4$1@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2022-10-05, Arne Vajhøj <arne@vajhoej.dk> wrote:
> > On 10/5/2022 5:41 PM, Stephen Hoffman wrote:
> >> For those of you mailing payments or packages to VSI, they have posted a
> >> new mailing address:
> >>
> >> 6 Liberty Square
> >> PMB # 294
> >> Boston, MA 02109
> >>
> >> That's a FedEx ShipCenter in downtown Boston.
> >
> > That probably relates to this announcement:
> >
> > https://vmssoftware.com/about/news/2022-10-05-vms-software-moves-to-boston/
> >
>
> Interesting. On the one hand, that's good news, but on the other hand,
> a job title that includes "Revenue Enablement" ?
>
> I wonder what that translates to in "normal" English ? :-)

Sales?

On 2022-10-06, John Dallman <jgd@cix.co.uk> wrote:
> In article <thmj7k$3c8u4$1@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>
>> a job title that includes "Revenue Enablement" ?
>>
>> I wonder what that translates to in "normal" English ? :-)
>
> So that's "Vice President of GTM Strategy & Revenue Enablement" which
> expands to "Vice President of Go To Market Strategy & Revenue
> Enablement".
>
> I think that's "Vice President for Sales" in old-fashioned language.
>

Yeah. :-) I saw that and I thought, oh, they mean he's a salesperson
with an office. :-)

Why can't people use normal job titles for this stuff...

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <thn3aa$3e49o$1@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> Why can't people use normal job titles for this stuff...

Fashion.

Being "VP of Sales" is dreadfully 1980s. New job titles give things an
air of being up-to-date. A lot of "Business Decision Makers" have no way
to chose between options on technical or financial grounds, and can be
influenced by a thin tissue of new business jargon.

John

On 10/6/2022 1:29 PM, Simon Clubley wrote:
> On 2022-10-06, John Dallman <jgd@cix.co.uk> wrote:
>> In article <thmj7k$3c8u4$1@dont-email.me>,
>> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>>
>>> a job title that includes "Revenue Enablement" ?
>>>
>>> I wonder what that translates to in "normal" English ? :-)
>>
>> So that's "Vice President of GTM Strategy & Revenue Enablement" which
>> expands to "Vice President of Go To Market Strategy & Revenue
>> Enablement".
>>
>> I think that's "Vice President for Sales" in old-fashioned language.
>>
>
> Yeah. :-) I saw that and I thought, oh, they mean he's a salesperson
> with an office. :-)
>
> Why can't people use normal job titles for this stuff...
>
> Simon.
>

Blame Microsoft, they are the people who just had to rename everything ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Simon Clubley wrote:

>
> Interesting. On the one hand, that's good news, but on the other hand,
> a job title that includes "Revenue Enablement" ?
>

will there also be a job titled "Revenue *Dis*ablement"?

On 2022-10-08, Michael Kraemer @ home <M.Kraemer@gsi.de> wrote:
> Simon Clubley wrote:
>
>>
>> Interesting. On the one hand, that's good news, but on the other hand,
>> a job title that includes "Revenue Enablement" ?
>>
>
> will there also be a job titled "Revenue *Dis*ablement"?

That job title has already been given to the person who came up with
the idea of time-limited production licences. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Simon Clubley explained :
> On 2022-10-08, Michael Kraemer @ home <M.Kraemer@gsi.de> wrote:
>> Simon Clubley wrote:
>>
>>>
>>> Interesting. On the one hand, that's good news, but on the other hand,
>>> a job title that includes "Revenue Enablement" ?
>>>
>>
>> will there also be a job titled "Revenue *Dis*ablement"?
>
> That job title has already been given to the person who came up with
> the idea of time-limited production licences. :-)
>
> Simon.

The lack of attention to third party software editors is in my opinion
even worse than that.

--
Marc Van Dyck

On 2022-10-11, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
> Simon Clubley explained :
>> On 2022-10-08, Michael Kraemer @ home <M.Kraemer@gsi.de> wrote:
>>>
>>> will there also be a job titled "Revenue *Dis*ablement"?
>>
>> That job title has already been given to the person who came up with
>> the idea of time-limited production licences. :-)
>>
>
> The lack of attention to third party software editors is in my opinion
> even worse than that.
>

The use of the word "editors" above is a bit confusing to me. Did you
mean "producers" ?

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 ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 10/11/2022 9:00 AM, Simon Clubley wrote:
> On 2022-10-11, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
>> Simon Clubley explained :
>>> On 2022-10-08, Michael Kraemer @ home <M.Kraemer@gsi.de> wrote:
>>>>
>>>> will there also be a job titled "Revenue *Dis*ablement"?
>>>
>>> That job title has already been given to the person who came up with
>>> the idea of time-limited production licences. :-)
>>>
>>
>> The lack of attention to third party software editors is in my opinion
>> even worse than that.
>>
>
> The use of the word "editors" above is a bit confusing to me. Did you
> mean "producers" ?

Yeah, I wondered about that also. To me, EDT is an editor. An entity that
develops software is a vendor/developer/whatever.

> 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.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Den 2022-10-11 kl. 15:00, skrev Simon Clubley:
> On 2022-10-11, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
>> Simon Clubley explained :
>>> On 2022-10-08, Michael Kraemer @ home <M.Kraemer@gsi.de> wrote:
>>>>
>>>> will there also be a job titled "Revenue *Dis*ablement"?
>>>
>>> That job title has already been given to the person who came up with
>>> the idea of time-limited production licences. :-)
>>>
>>
>> The lack of attention to third party software editors is in my opinion
>> even worse than that.
>>
>
> The use of the word "editors" above is a bit confusing to me. Did you
> mean "producers" ?
>
> 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 ?
>
> Simon.
>

The two, IMHO, most likely to have been referred to are:
Mark Daniel, for the WASD web server, and:
JFP, for the Python kit for VMS (homepage now shut down due to lack of
support and interest from VSI).

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@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

On 10/11/2022 3:06 PM, Jan-Erik Söderholm wrote:
> Den 2022-10-11 kl. 15:00, skrev Simon Clubley:
>> On 2022-10-11, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
>>> The lack of attention to third party software editors is in my opinion
>>> even worse than that.
>>
>> The use of the word "editors" above is a bit confusing to me. Did you
>> mean "producers" ?
>>
>> 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 ?
>
> The two, IMHO, most likely to have been referred to are:
> Mark Daniel, for the WASD web server, and:
> JFP, for the Python kit for VMS (homepage now shut down due to lack of
> support and interest from VSI).

VSI is doing a lot with open source.

Including supporting support OpenSSL, Apache and Python 3.

I am sure they could do more, if they had let us call
it "DEC like" resources, but they don't, so they prioritize
like most other businesses.

Arne

on 11/10/2022, Simon Clubley supposed :
> On 2022-10-11, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
>> Simon Clubley explained :
>>> On 2022-10-08, Michael Kraemer @ home <M.Kraemer@gsi.de> wrote:
>>>>
>>>> will there also be a job titled "Revenue *Dis*ablement"?
>>>
>>> That job title has already been given to the person who came up with
>>> the idea of time-limited production licences. :-)
>>>
>>
>> The lack of attention to third party software editors is in my opinion
>> even worse than that.
>>
>
> The use of the word "editors" above is a bit confusing to me. Did you
> mean "producers" ?
>
> 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 ?
>
> Simon.

Yes I mean producers. "Editeur" is the common term for such companies
in
french, which is my mother language, so I wrongly assumed that this was
the correct term in English too.

--
Marc Van Dyck

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@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.

--
Marc Van Dyck

In article <mn.5a487e6a5c7f665c.104627@invalid.skynet.be>,
marc.gr.vandyck@invalid.skynet.be (Marc Van Dyck) wrote:

> The lack of attention to third party software [producers] is in my
> opinion even worse than that.

What are VSI not doing, which you feel they should?

John

After serious thinking John Dallman wrote :
> In article <mn.5a487e6a5c7f665c.104627@invalid.skynet.be>,
> marc.gr.vandyck@invalid.skynet.be (Marc Van Dyck) wrote:
>
>> The lack of attention to third party software [producers] is in my
>> opinion even worse than that.
>
> What are VSI not doing, which you feel they should?
>
> John

See my other reply above. I'm just a lonesome system engineer, so I
could't say how VSI should have done that, but for me at least, the
success of their ISV program is quite limited. The only products that
we are using which I received positive news for about the X86 port
are Cockpit and System Detective. All the others we will have to
replace.

--
Marc Van Dyck

On 2022-10-12, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
>
> 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.
>

Unfortunately, when architectures are changed not all packages make it
across to the new architecture.

For example, VAXELN was abandoned when the move to Alpha occurred and
it looks like there will be no Ada compiler for x86-64 VMS.

The question is, just how major are the packages that are being lost ?
Oracle Classic is a major example of something that has been lost, but
that's tied to VMS in general, not just x86-64 VMS.

There's been no negative comments about Rdb recently, so I assume that
is still on course for release on x86-64 VMS. Of course, if Rdb wasn't
released for x86-64 VMS then that would be a very serious blow to VSI's
plans.

So the question is, of the other packages Marc uses, how many of them
are in general use within the VMS user base as a whole ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

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@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.

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.

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.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 10/12/22 09:05, Simon Clubley wrote:
>
>
> Unfortunately, when architectures are changed not all packages make it
> across to the new architecture.

And the result is the loss of even more customers. How many can VMS
afford to loose?
>
> For example, VAXELN was abandoned when the move to Alpha occurred and
> it looks like there will be no Ada compiler for x86-64 VMS.

That's just silly. VAXELN was tied to the VAX architecture it would
have been abandoned no matter what architecture VMS moved to.

>
> The question is, just how major are the packages that are being lost ?

How major they are is dependent on the user, none of them are really
major to VSI.

> Oracle Classic is a major example of something that has been lost, but
> that's tied to VMS in general, not just x86-64 VMS.
>
> There's been no negative comments about Rdb recently, so I assume that
> is still on course for release on x86-64 VMS. Of course, if Rdb wasn't
> released for x86-64 VMS then that would be a very serious blow to VSI's
> plans.

A database is the least serious of these problems. VSI could easily
(well, maybe not easily) decide that Postgres was going to be the VMS
database just like RDB was, at one time, a DEC product. It is easily
a suitable replacement for either Oracle or RDB. Just suffers from NIH
syndrome.

>
> So the question is, of the other packages Marc uses, how many of them
> are in general use within the VMS user base as a whole ?

Doesn't really matter if the loss of these means they can't or won't
move forward on VMS.

bill

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@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?

bill

On 2022-10-12, Dave Froble <davef@tsoft-inc.com> wrote:
>
> It would seem to me that the current owners of the mentioned software would be
> responsible for porting their software, not VSI.
>

That's a very, very, short-sighted view David.

Operating systems exist to run applications. Without those applications,
the operating system means nothing.

DEC understood this, which is why you used to have the old Software handbooks.

It is very strongly in VSI's interest to help vendors port their applications
to x86-64 VMS.

Unfortunately, VSI's limited resources means they can't help as many
people as it would be beneficial to help. However, if there's a big
vendor that VSI don't know about, it's important to get VSI talking
to them and for VSI to help persuade the vendor to port to x86-64 VMS.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.