> > -----Original Message-----
> > From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Hall, Ken (ECSS)
> > Sent: Friday, April 19, 2002 12:13 PM
> > To: [EMAIL PROTECTED]
> > Subject: LinuxWorld Article series
> >
> >
> > Anyone seen this?
> >
> > Aside from some (fairly glaring) technical inaccuracies, I can't
> > see much I'm qualified to dispute.
> >
> > http://www.linuxworld.com/site-stories/2002/0416.mainframelinux.html
>
> But the "glaring technical inaccuracies" lead me to question his conclusions
> about Linux on S/390. I suspect that
> while he knows a great deal about the Unix environment and the typical Unix
> user mindset, his grasp of the "mainframe"
> world is limited, to say the least. He seems to fixate on the mainframe a
> "batch-oriented" and Unix as interactive, and
> that "interactive" doesn't work well on mainframes. He obviously has never
> used CMS on VM (or CP/VM as he calls it...);
> it's as interactive and responsive as any Linux system I've used. And his
> statement that TSO and CMS "load as batch jobs" is just pure nonsense......
Actually, one relative I spoke (in depth) about Unix waaaayyyy back
over 20 years ago (working at Western Electric) indicated that Unix
is very good at character oriented stuff since files had a "character"
granularity and the was no "innate" record-ness therein, which the
Mainframe systems at the time were oriented around (LRECL, RECFM,
BLKSIZE, remember there?) so, for some workloads, a Unix-based system
was at a disadvantage- and remains so. FBA comes naturally to Unix
since it evolved on non-IBM hardware; The Xerox Sigma series (5, 7,
9) disk drives that I worked with were FBA'd versions of the 3330 made
by CDC, as were the disk drives for the UNIVAC 1100 and the smaller
minicomputers all used hard-sectored disk drives too. IBM was the
only purveyor I know of with CKD drive architectures (which is, really,
soft-sectoring). (The RCA Spectra-70 which was reborn as the UNIVAC
System-80 may have been CKD-ish but I didn't know much about it,
despite playing with TSOS on a -70/46.)
One of the other items I found annoying was ignoring the whole
issue of RAS (as explained in Appendix A's comparison between the
Intel x86 architecture and the s/390 CP architecture) which explains
that speed isn't as important as being able to rely on the results
with an ability to service portions of the systems while the rest
of it is still operating (the way memory is handled, for instance).
Totally ignored was the basic compromise implicit in going to a
mainframe: the ability to trust ALL of the hardware.
The problem is that there are many disconnects here; While my
understanding of virtualizing the hardware is limited (though Melinda
Varian's paper was extremely educational and put a lot into context
for me) even I could see some gaps in the logic.
Mind you, I've a fairly eclectic background, and most of the article
didn't _smell_ quite right to me. There were all kinds of tangents
it seemed to go off on.
Personally, I want to see Linux be successful on the s/390 architecture
because it's neat, but I'd also have to agree that we can't do this
blindly.
And while a set of benchmarks are ludicrous for a virtual instance
(and, I suspect even an LPAR) some kind of metrics for the bare metal
would not hurt (though nobody can afford to turn over a whole piece
of BFI like an z800 or z900 to run such tests since it's such expensive
hardware). I suspect nobody at IBM can get enough bare metal set aside
long enough to run these tests anyway.
> Overall this article appears to be not so much concerned with Linux running
> on a S/390 environment, but a diatribe against
> mainframes in general and the overall superiority of SUN boxes. That seems
> to be the whole thrust of the paragarphs on
> "mutually contingent evolution." (whatever that is.....).
There are some things a mainframe is good for:
1) Maximum single-thread performance
2) Maximum I/O Bandwidth
3) Maximum I/O Connectivity
You need single thread performance for many tasks in business- like
balancing a binary tree structure (which means the I/O can't be
sluggish either) or performing the merge phase of a sortation job.
You won't be running SETI@Home on these things, y'know. It ain't for
scientific number crunching and other compute-bound workloads will
likely not be suitable for virtualization- but there are plenty of
other workloads that ARE suitable for this, leaving the big clusters
of Alphas, MIPS and PPC processors available for workloads that have
good parallel characteristics.
> I suspect that Paul Murphy is a shill for SUN.
That's the problem- the article seemed too well suited for inclusion
in the "bigbluesmoke" site- though it mentioned PC architecture
machines instead of Suns.
So, am I whining again?
--
John R. Campbell Speaker to Machines [EMAIL PROTECTED]
- As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!
Disclaimer: All opinions expressed above are those of John R. Campbell
alone and are seriously unlikely to reflect the opinions of
his employer(s) or lackeys thereof. Anyone who says
differently is itching for a fight!
