[Info-vax] DCL crashing bug update

[clair.grant@vmssoftware.com]

On Wednesday, July 26, 2017 at 7:29:01 PM UTC-4, Simon Clubley wrote:
> On 2017-07-25, dgordonatvsi at gmail.com <dgordonatvsi at gmail.com> wrote:
> > On Tuesday, July 25, 2017 at 4:22:11 PM UTC-4, Simon Clubley wrote:
> >
> > I've looked into the recall buffer code.  I know what the issue is.  I've
> > opened an internal bug report, assigned to me.
> >
> 
> Excellent. :-)
> 
> Are you able to tell HPE about it so they can work on a fix in their own
> version of the code base ?
> 
> If you want me to report it to them directly, can someone associated
> with HPE please tell me the best email address to use to contact HPE
> VMS Engineering directly ?
> 
> It's not a security issue so using the HPE security reporting mechanism
> would be inappropriate.
> 
> Thanks.
> 
> > To this question:
> >
> >> When adding new functionality to VMS, how much work is done to evaluate 
> >> the original design assumptions in light of any new functionality ? 
> >
> > /INPUT and /OUTPUT were added in 1993 - 3 years before I originally joined VMS Engineering.    "New" is relative.
> 
> It was more a general question about how much re-evaluation of any
> original design assumptions is done when a new feature is added.
> 
> Simon.
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

OK, I'll give this a shot. Whenever a code change is proposed, however big or small, bug fix or new feature, we try to evaluate everything that could be affected. Original intent (design) is a factor but the bottom line is how the existing code gets changed. People with relevant expertise review code and discuss. Sounds simplistic but that's what happens, has for years. Obviously, every situation is different but generally that's the way it works. Also, everything is reviewed by the test engineers to see if existing tests or new tests are need to properly exercise the changes.