[TUHS] long lived programs (was Re: RIP John Backus

Paul Winalski paul.winalski at gmail.com
Tue Mar 27 02:19:44 AEST 2018


On 3/26/18, Tim Bradshaw <tfb at tfeb.org> wrote:
> On 23 Mar 2018, at 19:28, Bakul Shah <bakul at bitblocks.com> wrote:
> Retail banks are risk-averse so they like to avoid the risks associated with
> porting the thing to new platforms.  And since there's no development most
> of the developers leave.
>
> And then ten or twenty years later you have this arcane thing which no-one
> understands any more running on a platform which is falling off the end of
> support.
>
After grad school (1978) one of my first job interviews was for a job
as system manager for an insurance company.  Their data center took
the "don't risk porting software" to an extreme.  As new technology
came out they bought it, but only to run new applications.  Existing
applications were never ported and continued to run on their existing
hardware.  Their machine room looked like a computer museum.  They had
two IBM 1400s (one in use; one was cannabilized for parts to keep the
active machine going), two System/360 model 50s, with a drum and a
2321 data cell drive.  Their only modern hardware was a System/370
model 158.

Operating systems seem to have taken one of two policies regarding
legacy programs.  IBM's OS and DEC's VMS emphasized backwards
compatibility--new features mustn't break existing applications.  VMS
software developers called the philosophy of strict backward
compatibility "The Promise" and took it very seriously.  Unix, on the
other hand, has always struck me as being less concerned with backward
compatibility and more about innovation and experimentation.  I think
the assumption with Unix is that you have the sources for your
programs, so you can recompile or modify them to keep up with
incompatible changes.  This is fine for research and HPTC
environments, but it doesn't fly in corporate data centers, where even
a simple recompile means that the new version of the application has
to undergo expensive qualification testing before it can be put into
production.  Which philosophy regarding backwards compatibility is
better?  It depends on your target audience.

-Paul W.



More information about the TUHS mailing list