OPENMPE Archives

October 2002

OPENMPE@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jerry Fochtman <[log in to unmask]>
Reply To:
Jerry Fochtman <[log in to unmask]>
Date:
Fri, 4 Oct 2002 09:06:34 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (49 lines)
At 08:25 PM 10/3/02 -0500, Chuck Ryan wrote:
>Um Jeff, you do know that some of us are actually programmers that do have
>some small idea of what is involved in maintaining and enhancing old code?

Certainly!  However, do keep in mind that working in systems-level code,
hardware/driver, etc. at kernal level can be a bit more complex than
managing a COBOL/COGNOS application.  I stand by my earlier statement that
there are at best, only a small handful of folks outside of HP that
have the skill and breath of knowledge to handle many areas in the OS.
This is not to say that others can't learn those skills given enough
time and experience.  Only that today's pool of skilled resources can
probably be counted on 2 hands...maybe only 1 hand....  And clearly it
would require collaboration among them, as no one individual can keep
up to date on everything.

Certainly there is a wider pool of resources when it comes to things
such as EDITOR, FCOPY and similar tools.



>The repeated statements made by you and others at CSY have led me to expect
>a mass of undocumented hacks and quick fixes that will be no small challenge
>to work with. Which is why I think rolling back to a version before the
>large number of appeasement changes might provide the most stable code base.

What makes you think that rolling back to some prior version would be any
different?  And if doing that causes you to lose the re-designs of things
needed in say storage mgmt, hardware drivers, etc. that are dependent on
changes that one deems as quick fixes, how does this loss of newer hardware
tied to these changes benefit those moving forward on MPE?

Given 7.5 will probably be the last platform release, coupled with the
next 3-4 years of support/patches for problems that arise, I would
think that by HP's EOL stability should not be a problem.  There simply
is no comparison of this against the loss of functionality, size, hardware,
etc. by taking some fairly large step backwards.  And because of the
inter-dependency in the code, unwinding some changes have very broad
impact.  For example, if you wanted to back-out large files (128Gb) for
stability, you'd also impact >3Gb memory because all of virtual storage
mgmt was re-designed as a part of making it to large files.  This would
downsize the number of current processes/users, and on and on.  And
at the same time the I/O architecture was changed to support PCI, so
moving prior to large files results in possibly losing this and some of
the hardware items.  Loss of them would mean people would have to go
back to some older hardware which is no longer manufactured.

Nope, I would oppose going backwards, it would be way too painful and
have tremendous impact in MPE.

ATOM RSS1 RSS2