[Info-vax] History of DECSET / CMS

[Andrew Shaw]

On Monday, March 30, 2020 at 10:33:21 AM UTC+11, Andrew Shaw wrote:
> Hi folks,
> 
> I need to educate my colleagues behind the history of CMS which is what all our VMS development processes are built around (no surprise there) - because these processes have gradually morphed and matured over a period of some 20+ years, probably a lot longer.
> 
> I am being asked why we are not using git and as part of my answer I would like to provide some factual background about CMS' robust history.
> 
> I am guessing it started back in the VAX days, or was it even earlier than that?
> Was it always part of DECSET?

This is all good feedback guys and I can see points of relevance in what everyone has said to our environment. Personally I have worked with CMS for many many years and I have always found it appropriate for what we have wanted to do in our VMS environments.

The argument about moving from CMS to Git (or SVN or whatever the flavour du jour happens to be) is an interesting one. Where I am now, their source repository weapon of choice for the majority of all their non VMS systems happens to be git, and there are a raft of tools and processes in place to support that. The VMS system I help look after (like most I suspect) has grown steadily over a development period of 30+ years and still forms the core engine behind our central product offering. Over the more recent years a whole raft of supporting apps and systems have grown that do all the nice pretty modern stuff like web pages, containers, Kubernetes, java classes etc - all supporting many layered products with which we in the VMS world are required to interface in an increasingly complex application / system landscape. 

The vast majority of our tech staff really don't understand this "VMS black box thing" and they don't really appreciate why things happen differently. Our dev staff are understandably mostly a generation or two younger than us VMS tragics and consider a lot of what we do "quaint". 

Now I am being asked why my new code isn't in git, and I have no good answer. There is no reason why it can't go there, and that's where I will be putting it. It doesn't need to be tied to the dev processes of our core app. I anticipate that I will get asked soon - "Why don't you guys use git for your core app"? Short answer - we *could*. Longer answer, as a few of you have pointed out today, there would be non trivial work to move not only our code, but more importantly our build processes to a git central world. And to what end? Our build process works today. No, it isn't ideal, in fact its far from ideal, and if I was starting again I would do it completely differently, (but probably still within CMS, just with a differently structured set of libraries and cleverer use of classes etc) but I'm not. What are the risks with having our code in CMS today? No technical risks that I can see.  There is the training / staff development point brought up earlier which is very valid. If we want to move new devs into this team, that is complicated by having to get them across CMS, but at the end of the day our app is a VMS app - we have to get them across VMS too. You can't be a Dev in our world and not have an understanding of the VMS world. I think I'm the only guy there with a genuine love of, and history in, the VMS world, the others tolerate it and have learned how to get stuff done - and that's fine too. Certainly if the code side was in git or SVN or something more modern that would be one less technology to frighten off new hires and there is a plus side to that.

Anyway, I'm digressing !!!!

Thanks for your feedback, it all makes sense. I certainly won't be advocating a wholesale move to git anytime soon, but it is a topic on people's agenda and I don't want to rule it out just because its something new and different. Its a discussion that is definitely worth having. I'm also not a fan of doing things "because that's the way we've always done them" (I had a guy working for me years ago and that was his response whenever I tried to get him to do something different - and it infuriated me no end) I'm quite happy to change processes, but for a good reason, and with the risks and benefits properly understood. "We don't understand how you do it today" isn't a good enough argument as far as I'm concerned.