[Info-vax] History of DECSET / CMS

[Dave Froble]

On 3/31/2020 9:47 AM, Arne Vajhøj wrote:
> On 3/30/2020 9:05 PM, Dave Froble wrote:
>> On 3/30/2020 4:28 PM, Andrew Shaw wrote:
>>> On Tuesday, March 31, 2020 at 3:25:57 AM UTC+11, Phillip Helbig
>>> (undress to reply) wrote:
>>>> In article <r5rc5m$9s6$1 at dont-email.me>, "Robert A. Brooks"
>>>> <FIRST.LAST at vmssoftware.com> writes:
>>>>
>>>>> CMS (along with the rest of DECset) is still maintained by VSI,
>>>>> although we are
>>>>> primarily doing bug fixes (and the occassional enhancement).
>>>>>
>>>>> I am the primary DECset maintainer at VSI.
>>>>
>>>> Good to know that it is still being maintained.  If that is the case,
>>>> and the OP is staying on VMS, then there is problem no reason to move.
>>>> If he is not staying on VMS, then he has no choice but to move to
>>>> something else.
>>>
>>> For the time being, at least, we are staying on VMS. There have been
>>> a couple of attempts over the last 20 years to move off it and
>>> on to something more modern, but all have failed.
>>
>> Was there any reasons to move to another environment?
>
> A lot of companies were very concerned about HP(E)'s commitment
> to VMS. Luckily that is fixed by now.

Well yes, it was unfortunate, but a bit of reality.  Still, with VSI 
going forward, if there is a good solution in place, why would anyone 
consider "rocking the boat"?  Doesn't make sense to me, but seeing the 
complacency some are showing to Covid-19, not sure how much sense 
actually exists.

> Some companies may be concerned about finding VMS expertise
> in the future.

My constant mantra.  You train people for what they need to know.  You 
rarely find them.

>>> Now there is a project going on looking at bringing in a 3rd party
>>> package to take over our core engine functionality, but that is
>>> moving extremely slowly too, for a number of reasons. >
>> Is there a reason for doing so?
>
> The movement from custom solution to off-the-shelf / semi-off-the-shelf
> solutions is not new.
>
> When such migrations start it is often believed to be cheaper.

Tell that to the companies who are no more due to SAP ...

> Reality is that a standard solution with customizations often turn
> out to be just as expensive as the in house solution it replaced.

You get what you pay for ...

> But it still has benefits. The standard solution will come with a
> lot of extras - it will usually be more web friendly, more cloud
> and container ready, more database independent, more OS independent
> etc.. And it is less risk - as long as you pay then it is somebody
> elses problem to find the core developers - and often also
> the customization consultants.

Successful companies are successful many times because they do a better 
job of providing whatever they are peddling.  Lose that edge, and 
perhaps success is harder to come by.  Thus, standard solutions may not 
be a good choice.  However, as mentioned, the expertise might be more 
prevalent in organizations that peddle software applications.  The key 
is to understand what part of the app is adequate, and what might need 
some tweeking. I've always felt that before I can design a solution for 
an organization, I first need to know the business well enough that I 
could run it without the computerized apps.  I've been amazed at how 
much I've learned from customers, things I'd never have imagined on my 
own.  Good solutions provide what a customer needs, they do not tell a 
customer how to change their business to meet the capabilities of the app.


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