[Info-vax] Problem with VMS732_DEBUG-v2 patch

[John Wallace]

On Oct 7, 12:06 pm, Simon Clubley <clubley at remove_me.eisner.decus.org-
Earth.UFP> wrote:
> On 2009-10-07, R.A.Omond <Roy.Om... at BlueBubble.UK.Com> wrote:
>
>
>
>
>
> > Yep, I checked the PCSI kit - it wasn't tested at all.
>
> > See if you can spot the error in the PCSI_POSTINSTALL.COM file:
>
> > $ if file_rename .eqs. "NO"
> > $   then
> > $ define sys$output nl:
> > $ define sys$error nl:
> > $ delete/nolog/nocon SYS$COMMON:[SYSLIB]DBG$HA_KERNEL.EXE_OLD;
> > $ delete/nolog/nocon SYS$COMMON:[SYSLIB]DBG$HA_MAIN.EXE_OLD;
> > $ delete/nolog/nocon SYS$COMMON:[SYSLIB]DEBUG.EXE_OLD;
> > $ delete/nolog/nocon SYS$COMMON:[SYSLIB]DEBUGSHR.EXE_OLD;
> > $ delete/nolog/nocon SYS$COMMON:[SYSLIB]DEBUGSHR.EXE_OLD;
> > $ delete/nolog/nocon SYS$COMMON:[SYSLIB]DEBUGSRVSHR.EXE_OLD;
> > $ delete/nolog/nocon SYS$COMMON:[SYSLIB]DEBUGUISHR.EXE_OLD;
> > $ delete/nolog/nocon SYS$COMMON:[SYSEXE]DBGHK$HOST_KERNEL.EXE
> > $ delete/nolog/nocon SYS$COMMON:[SYSEXE]DBGHK$PRCDUMP_KERNEL.EXE
> > $ delete/nolog/nocon SYS$COMMON:[SYSEXE]DBGHK$SYSDUMP_KERNEL.EXE
> > $ delete/nolog/nocon SYS$COMMON:[SYSMSG]DBGTBKMSG.EXE
> > $ delete/nolog/nocon SYS$COMMON:[SYSLIB]TRACE.EXE
> > $ deassign sys$error
> > $ endif
>
> Well at least we now know if outsourcing VMS is going to affect it's
> quality. :-(
>
> Given that the major customers are running the same patches as the
> rest of us, I would have thought that HP would at least be able to
> maintain the patch quality.
>
> Simon.
>
> --
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980's technology to a 21st century world

In addition to the visible problem with that command file, there are
(at least) three other problems, non-technical ones, which only show
when you think about how this situation arose:

1) An engineer made a mistake. That happens, but competent engineers
check stuff before shipping, which should generally catch simple
mistakes like this one.
2) Whatever engineering quality management process/procedure was
(supposed to be) in place appears to have been ineffective. Mistakes
do happen, but the chances of multiple mistakes letting out a basic
error like this should be almost vanishingly small in a properly
managed operation with competent staff.
3) Whatever transfer of "tribal knowledge", "product ethics", call it
what you will, was supposed to have happened appears to have not been
100% successful. It's often said in connection with motivating
individuals, teams, etc, that "you get what you measure", so there
need to be some questions asked about metrics and motivations.