I have been collecting old unix systems recently, and just before the
winter break I was looking for more simh software, when I came across
the Hercules project and MVS 3.8J, an old (circa 1978) version of the
mainframe MVS operating system that is free and comes with source. So,
I spent some fun time at the airports doing a sysgen of MVS on my
laptop.
Recently, someone asked on bblisa what other people were doing for batch
services, with scant reply. The old nqs might still work on Unix, but
MVS was (and still is) the ultimate batch system. Nothing really beats
jes2/jes3 for batch services. There are many reasons for that, but one
reason in particular stands out: Programs written for MVS 3.8J still run
on current versions of IBM zOS. Many programs (binaries) written for
zOS will run on MVS 3.8J. (and vice versa!) IBM claims to have customers
running unmodified IMS programs umodified since the 1960s. 50+ years of
continuity surely says something. But what exactly does it say?
I mean, consider linux from a mere 15 years ago. Would an application
binary still run on modern linux? Most likely not (glibc changes).
Would source code compile? Perhaps, after some minor changes. What
about a 1978 version of Unix? (those unix versions are available, and
can be run on simh on several processor simulations) The answer: Not
very likely at all. Some few small programs would still compile, but I
think most wouldn't.
Unix has a very powerful metaphor at its heart that everything is a
file. But this has an equally powerful downside rarely mentioned: The OS
has no idea of the record size of the file. So the unix buffer cache
gets the next 1k block of data, but almost never gets the entire record
the application will need next. By contrast, MVS always gets that size
right, since the record size and blocking factor are known to the OS in
the file definition data.
Programs that were written in the 1960s & 1970s for MVS still work and
are still useful. Cobol is probably still the most prolific progamming
language in terms of lines of code running (though new cobol development
has probably slowed down a lot, and so I expect this will change
someday--maybe it has already) And that also says something about the
cost of software development and software maintenance. Those old
programs are more than paid for and are deep into pure profit for the
owners & users. Mainframes have become physically smaller and more
economical, too. I understand that the densest linux systems (systems
per unit volume) are still mainframe vm's.
Anyway, as we speed along with new technology, new scripting languages
du jour: erlang, ajax, iphone apps, etc, etc, I wonder if we have lost
sight of some things. For example, years ago, I wrote some software for
the newton, to inventory computer systems for IT with a barcode pen. How
many people even know now what a newton was? It worked great until the
newton died, and then it was just too time-consuming to re-develop on a
new platform. And so it may be with some of the hot platforms now.
What's the cost and benefit of developing apps for a platform that has a
3 to 5 year lifetime? (Well, the iphone is running a version of Mach,
an OS developed in the 1980's, largely abandoned in the mid 1990s, so
perhaps even the new are really still rooted in the old)
I don't mean to say people should move to mainframes or shun new
technology by any stretch; big corporate IT standing in the way of new
technology is a old problem. But I think it may be worthwhile to once
in while stop and consider what the underlying IT costs/benefits are and
how we can improve that ratio. Systems architected to last for a long
time are surely better than those expected to last only a few years.
Especially when we expect the problems to be essentially the same in the
far future (eg. accounting, banking, inventory control, etc)
Thoughts?
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 256 5494
_______________________________________________
bblisa mailing list
[email protected]
http://www.bblisa.org/mailman/listinfo/bblisa
