ibm mainframe or unix

vincent li

unread,

Apr 11, 2004, 2:29:57 AM4/11/04

to

Dear lister,
We are planning to evaluate which platform(IBM MF or Unix) we should use for our future appl development,I just study one of the xephon report: the dinosaur Mith which says
that mf is cheaper to run than unix or pc.
Does anyone have any hints/tips/advise/presentation which support to use IBM mainframe instead of unix from cost,management,appl development,maintaince,future growth,reliablity,ect point of view ?

Thanks.

---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Bruce Black

unread,

Apr 11, 2004, 12:02:51 PM4/11/04

to

Vincent,

Don't forget that today it is not a choice between Unix and the
Mainframe, because the Mainframe can run Unix (either Linux as a
"stand-alone" system or Unix programs running under z/OS).

So it is really a choice between developing your app on
Unix on a Sun, or Intel, or even an IBM "non-mainframe" server or whatever
Unix on an IBM zSeries server, Linux or z/OS
traditional languages (e.g., COBOL, CICS) on an IBM zSeries

For a new app, it probably make sense to develop it in Unix, so that it
will be more transportable (somewhat platform independant).

for a non-traditional app (no COBOL, etc), IBM gives a great price break
on z/OS.e, a "cut-down" version of z/OS on which you can run Unix apps,
Websphere apps, etc.

You can also run Linux, which is cheap. You can run up to 15
independant Linux systems on LPARs, or using z/VM you can run hundreds
of Linux systems, if that fits your needs.

For all the info on the various flavors of IBM servers, including the
zSeries I am talking about, go to
www.ibm.com/servers

--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing
Little Falls, NJ 07424
973-890-7300
personal: bbl...@fdrinnovation.com
sales info: sa...@fdrinnovation.com
tech support: sup...@fdrinnovation.com
web: www.fdr.innovationdp.com

Craddock, Chris

unread,

Apr 11, 2004, 2:20:50 PM4/11/04

to

> We are planning to evaluate which platform(IBM MF or Unix) we
> should use for our future appl development,I just study one
> of the xephon report: the dinosaur Mith which says that mf is
> cheaper to run than unix or pc. Does anyone have any
> hints/tips/advise/presentation which support to use IBM
> mainframe instead of unix from cost,management,appl
> development,maintaince,future growth,reliablity,ect point of view ?

"It depends"

If you plan to have a transactional application then any of the classic
mainframe database and transactional environments will be substantially more
reliable than anything on UNIX. Even Websphere, which is not really
considered to be a high availability environment in the mainframe context,
will easily outperform and outlast identical work on Linux or UNIX. z/OS is
just a lot better at managing a mix workload than any other operating system
today.

For an excellent comparison of identical applications running on each
platform, see Carl Parris' Websphere benchmarks contrasting Websphere on
z/OS, Linux, SUN and Windows from the last couple of SHARE conferences.

However, other applications are not so clear cut. If you are doing mainly
file and print sharing, basic web serving etc. then there is almost no
chance the mainframe can be cost effective. And for that matter, almost no
chance any commercial UNIX can either. Your choices would boil down to
Windows or Linux.

Chris

Shmuel Metz , Seymour J.

unread,

Apr 12, 2004, 9:12:28 PM4/12/04

to

In <200404110629...@web60603.mail.yahoo.com>, on 04/10/2004

at 11:29 PM, vincent li <vincent...@YAHOO.COM> said:

>We are planning to evaluate which platform(IBM MF or Unix)

The IBM mainframes have run Unix for a decade. I'd advise looking at
all of these options, alone and in combination:

1. z/OS, with a mixture of legacy and Unix code.

2. z/VM, with a mixture of legacy and Unix code.

3. Linux on a zSeries box.

4. Liux on a non-zSeries box

5. AIX

6. non-IBM Unix

7. *bsd

A good rule of thumb is that the m/f will do better on a high I/O load
and that Intel processors will do better on a high CPU load, but
nothing beats running a benchmark based on your actual work load.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

Ted MacNeil

unread,

Apr 13, 2004, 10:01:19 AM4/13/04

to

Benchmarking is getting way too expensive, and it's getting harder and
harder to get performance guarantees out of any vendor

>>>nothing beats running a benchmark based on your actual work load.

I'm finding that lately it is 'benchmarketting'

Ted.M...@Ca.IBM.COM
IBM Global Services, CANADA
(We need to put the 'GEE' back into technology!!)

ibm-main

unread,

Apr 13, 2004, 10:25:53 AM4/13/04

to

On Wed, 2004-04-14 at 00:00, Ted MacNeil wrote:
> Benchmarking is getting way too expensive, and it's getting harder and
> harder to get performance guarantees out of any vendor
>
> >>>nothing beats running a benchmark based on your actual work load.
>
> I'm finding that lately it is 'benchmarketting'
>

Probably always been the case.
I did some benchmarking for Amdahl. On one occasion flew out from Aus,
and had the test labs for 1 shift per (week)day for better than 2 weeks.
Pacbasin had to pay headquarters for that, in addition to my costs.
Had a copy of the customers system plus data, and we had to ship them
all the SMF data for their analysis to verify our performance claims.
I know that the same opportunity was accepted by IBM and NAS - o.k., so
it wasn't recently :)

Was *bloody* expensive, but it was a name account Amdahl wasn't (at that
time) prepared to lose.

--
Shane ...

... always be an individual - just like everyone else.

Phil Payne

unread,

Apr 13, 2004, 10:39:55 AM4/13/04

to

> Benchmarking is getting way too expensive, and it's getting harder and
> harder to get performance guarantees out of any vendor

Especially IBM, it would appear. Back when the z990 was announced several analysts queried
the odd shape of the MIPS curve. This was obviously GA1 - a maximum of 16 processors - so the
odd shape of the graph above 16 engines was of marginal interest.

But GA2 has come and gone, and GA3 is announced and approaching. The software charging MSUs
as published on the software web site are identical to the old performance MSUs minus 10% -
and these seem to have been LSPR-derived.

In my view, however, z990 LSPR from the 17-way onwards defies the laws of physics. I fail to
see why the 17th processor should add so much more power than the 16th, and the 18th/19th more
still. When the biggest system you could buy was a B16 this didn't matter - but the LSPR
numbers are now not
only the basis of sales statements but also the basis of software charging.

My (simplistic) calculations suggest that if the MP factor effect published for the 1 to 16
ways (301 to 316) were extrapolated, it would produce a 146 MSUs shortfall at the 24-way
point. This has been relevant in a hardware sales sense since GA2 and will be relevant in a
16*-way z/OS LPAR from GA3 onwards.

Unless there is some performance quirk in the z990 that I have failed to understand - and that
possibility must be admitted - LSPR is making questionable statements about the z990 17 to
32-way systems, and the MSU values derived from these statements are equally questionable.

The z990 LSPR information is stated to be current at 7 April 2004.

I look forward to being proven wrong. My analysis will be found at
http://www.isham-research.com/mips_z990.html - the spreadsheet is at
http://www.isham-research.com/z990_lspr.xls and is also linked from the web page. I know it's
a piece of crude and nasty work.

--
Phil Payne
http://www.isham-research.com
+44 7785 302 803

Ted MacNeil

unread,

Apr 13, 2004, 10:38:47 AM4/13/04

to

One of the first tasks I did, as a capacity analyst was to write a
synthetic benchmark (in COBOL with assembler timing routines), and run
multiple concurrent copies on an Amdahl Box we were replacing with a 308x
(gawdd, I feel old).
We did it to prove/disprove the performance claims of IBM.

This ended up being a short technical exercise and a long political
excercise.
And, I already knew (with my degree in stats and comp-sci) that we weren't
going to prove/disprove anything, since the sample was so small.
But, I had to suck it up, since I was still the wet behind the ears analyst
out of university for only six months.

(So, guess who had to come in on weekends, before and after the upgrade, to
run yet another 'tweaked' set of programmes on the 308x, that eventually
did not look like the original suite that ran on the old 470?)

Ted.M...@Ca.IBM.COM
IBM Global Services, CANADA
(We need to put the 'GEE' back into technology!!)

> > I'm finding that lately it is 'benchmarketting'
> >
> Probably always been the case.
> I did some benchmarking for Amdahl. On one occasion flew out from Aus,
> and had the test labs for 1 shift per (week)day for better than 2 weeks.
> Pacbasin had to pay headquarters for that, in addition to my costs.
> Had a copy of the customers system plus data, and we had to ship them
> all the SMF data for their analysis to verify our performance claims.
> I know that the same opportunity was accepted by IBM and NAS - o.k., so
> it wasn't recently :)
>
> Was *bloody* expensive, but it was a name account Amdahl wasn't (at that
> time) prepared to lose.

----------------------------------------------------------------------

Charles Mills

unread,

Apr 13, 2004, 12:11:15 PM4/13/04

to

I don't remember the *exact* original question, but aren't these answers
way too "techie"? "How fast the programs run" is at best one of a menu
of questions that management should be considering, such as how much
sysprog-ing will be required, availability of the relevant skills in the
marketplace, availability of third-party packages, etc.

BTW, I mean what I said literally and no more. It is not meant to be a
subtle damning or praising of either mainframes or *ix.

Charles

Shmuel Metz , Seymour J.

unread,

Apr 14, 2004, 9:16:55 AM4/14/04

to

In
<OFE023ED2C.AB699A7E-ON85256E...@ca.ibm.com>,
on 04/13/2004

at 10:00 AM, Ted MacNeil <ted.m...@CA.IBM.COM> said:

>I'm finding that lately it is 'benchmarketting'

That's why you need to run your own if you want meaningful data. It
were ever thus.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

ISO position

We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------

Ted MacNeil

unread,

Apr 14, 2004, 11:49:13 AM4/14/04

to

Unfortunately, that gets out of date and expensive, quickly!!

I use the week (or two) before and after an upgrade from PRIME-TIME data
for my big workloads.
I use the old methodology, from Joe Major, of IOs/CPUBusy
I have come within 5% of the LSPR average number, most times.

Of course, I can also skew it up to +40% of LSPR or down to -50% of LSPR,
depending on the assumptions

Remember, there are lies, d**n lies, and statistics (I used to have an old
copy of that book "Lying with Statistics".

Ted.M...@Ca.IBM.COM
IBM Global Services, CANADA
(We need to put the 'GEE' back into technology!!)

IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU> wrote on 13/04/2004 04
05 03 p:

> In
> <OFE023ED2C.AB699A7E-ON85256E...@ca.ibm.com>,
> on 04/13/2004
> at 10:00 AM, Ted MacNeil <ted.m...@CA.IBM.COM> said:
>
> >I'm finding that lately it is 'benchmarketting'
>
> That's why you need to run your own if you want meaningful data. It
> were ever thus.

----------------------------------------------------------------------

Cheryl Watson Walker

unread,

Apr 14, 2004, 1:44:25 PM4/14/04

to

Ted,

I agree that writing your own benchmark programs can be both expensive and
unreliable. We implemented Joe Major's technique of finding stable job
steps based on CPU per I/O in our benchmarking product called BoxScore
(http://www.watsonwalker.com/boxscore.html). Because we look at all jobs,
not just a set of pre-determined jobs, we've been able to find strange
effects like the COBOL subscripts on 9672s and the cache problem (seen in
SAS and others) on the z900. Whether you use a product like our BoxScore or
write your own, I think that Joe's technique is the ONLY way to go!

Cheryl

----- Original Message -----
From: "Ted MacNeil" <ted.m...@ibm-main.lst>
Newsgroups: bit.listserv.ibm-main
To: <IBM-...@BAMA.UA.EDU>
Sent: Wednesday, April 14, 2004 11:48 AM
Subject: Re: ibm mainframe or unix

> Unfortunately, that gets out of date and expensive, quickly!!
>
> I use the week (or two) before and after an upgrade from PRIME-TIME data
> for my big workloads.
> I use the old methodology, from Joe Major, of IOs/CPUBusy
> I have come within 5% of the LSPR average number, most times.
>

----------------------------------------------------------------------

Ted MacNeil

unread,

Apr 14, 2004, 2:13:23 PM4/14/04

to

I took the second ever course Joe taught in May 1982. And, I have been
using that methodology since then.
Reading raw RMF/SMF records, then upgrading to MXG, then moving to MICS
when I changed companies in 1984.

I have also tried IBM's approach of tcbtime/txpersecond, but the only place
I got consistency was TSO.
IMS fastpath/CONNEX/CICS never gave straight answers (it was more of an it
depends).

But, to get on a soapbox, all that being said, I still hate the 1 number
approach. Even, former technicians in management
want a simple MIPS (Marketting Indicator or Processor Speed) rating for
each box. And, they cannot understand, why
one doing IMS fastpath is getting better numbers than one doing simple CICS
or IMS fullfunction. I prefer to compare
a processor to itself, and use relative ratings when it is time to move
workloads around or upgrade.

We had a problem once when IBM first announced the original z/900 boxes.
Through an error in LSPR, the 101 was
rated at 250 instead of 235. It didn't seem like much until it propogated
through the bigger boxes. This made the
difference between a 1C4 and a 1C5, in an upgrade. Plus, the number got
stuck in the billing process. IBM made
the correction but, the "Keeper of the MIPS" missed the correction. 18
months of billing and tracking had to be
re-worked. Plus, a team plugging for an upgrade had to go back and ask for
more money, the difference between
a 1C4 and a 1C5. This was also at a time when the USD was worth $1.65+ CDN.
Made for a very expensive year!

IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU> wrote on 14/04/2004 01
44 08 p:

> Ted,
>
> I agree that writing your own benchmark programs can be both expensive
and
> unreliable. We implemented Joe Major's technique of finding stable job
> steps based on CPU per I/O in our benchmarking product called BoxScore
> (http://www.watsonwalker.com/boxscore.html). Because we look at all
jobs,
> not just a set of pre-determined jobs, we've been able to find strange
> effects like the COBOL subscripts on 9672s and the cache problem (seen in
> SAS and others) on the z900. Whether you use a product like our BoxScore
or
> write your own, I think that Joe's technique is the ONLY way to go!
>
> Cheryl
>

Ted.M...@Ca.IBM.COM

IBM Global Services, CANADA
(We need to put the 'GEE' back into technology!!)

----------------------------------------------------------------------

Phil Payne

unread,

Apr 14, 2004, 4:57:14 PM4/14/04

to

> But, to get on a soapbox, all that being said, I still hate the 1 number
> approach.

I must confess I find IBM just a little hypocritical here.

You only have to do a Kiviat-style graph of LSPR workload ratios across two different CPU
designs to realise that their performances are completely different "shapes" and that one
number CANNOT describe the relationship. But IBM itself insists on such a number - it's
called a "charging MSU".

The "charging MSU" is on its way to becoming a replacement for MIPS. Messing around with them
lately, I've come to dislike them just as much. Twice this week I've had the question: "How
many MIPS in a charging MSU?"

--
Phil Payne
http://www.isham-research.com
+44 7785 302 803

----------------------------------------------------------------------

Anne & Lynn Wheeler

unread,

Apr 22, 2004, 12:40:42 AM4/22/04

to

bbl...@ibm-main.lst (Bruce Black) writes:
> Vincent,
>
> Don't forget that today it is not a choice between Unix and the
> Mainframe, because the Mainframe can run Unix (either Linux as a
> "stand-alone" system or Unix programs running under z/OS).

don't forget that Au was available thru most of the 80s and 90s ...
originally code-name gold. lots of places ran it.

aix/370 was available in the late '80s.

the aixv2 was a derivative of (AT&T) system 5 ... and aixv3 was
derivative of aixv2.

aix/370 (and its companion aix/ps2) was created from a ucla locus
base.

the palo alto group had original started on BSD port to 370 ... but
that effort got retargeted to PC/RT ... providing "AOS" (bsd port) on
the PC/RT as an altnerative to AIX/V2. The group then came back to
doing a 370 offering ... but this time using UCLA's Locus as a base
(rather than UCB BSD).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/