[Info-vax] History of DECSET / CMS

[Dave Froble]

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?

> 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 bottom line is that I really don't see a serious move away from
VMS for us in the immediate future. I am watching very keenly what the
good folks at VSI are doing as once the x86 solution becomes viable then
virtualization becomes a very real option for us. I'm not sure if we
will virtualise or not, we have some extremely sensitive performance
requirements that previous emulator solutions have never been able to
come close to, but this is a different world now. Anyway, that's a
decision for down the track.

That is one concern with VMs.  Timing can make or break an app.

> Our dev env is quite straightforward from a technology point of
> view.
Very flat CMS structure involving hundreds of separate libraries with
nested search paths, which takes a while to get your head around. We
don't use MMS, which surprises me. There are a handful of home grown
build scripts, but they reall are just wrappers for the different
compilers. C, RATFOR and Macro-32 are the main languages. Python
starting to come in for more generic file i/o and scripting type tasks.
We have the GNU stack installed and most devs use a variant of vi as
their editor of choice. I'm old school and am far more fluent in EVE. My
current work though I just use Notepad++ pointing to a SAMBA share with
the code - the syntax highlighting is nice - and I never got very good
at LSE !! I stay away from the gnu utilities, although they have also
asked me to look at moving the build process to make, but I haven't got
far with that. I initially found some restrictions that came from being
forced to use bash that I wasn't comfortable with, but I may not have
explored that deeply enough either.
>
> So from a technology point of view, there isn't much that would stop
us moving away from VMS and on to something else. It will come down to
where does the priority of that work sit with the business? Right now
they are happy to leave it alone, because it works and works very well.

If it is working well, then what possible business reason would there be 
to spend money on at best a lateral move, and possibly a worse solution?

Yeah, there is the pointy haired managers that wail "we want WEENDOZE".


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