Mainframe replacement: PID/PWD systems
Mike Hammock
PartnerWorld for Developers, asked me to post this to the
P370 list for him. I thought it was of general interest and
that some of the people on this list might be interested in his
comments also. He makes an excellent summary and analysis
of the comments in the PWD meeting.
C. M. (Mike) Hammock
IntelliWare Systems, Inc.
An IBM Premier Business Partner
We Mean e-Business
Phone: (770) 330-3289
FAX: (770) 953-3258
mham...@intelliware.com
-----Original Message-----
From: Dr. H. Pat Artis [mailto:dr...@perfassoc.com]
Sent: Friday, March 02, 2001 7:38 AM
To: P37...@pucc.Princeton.EDU
Subject: RE: MP3000 replacement for PWD members
Hi:
Since I have already seen a few prior posts related to the expectation of
what would be said at yesterday's meeting or what was actually said, I
thought that I would cast my thoughts into the wind too!
Performance Associates has been a PID since the beginning of the program. We
picked up a Server 500/P390 at initial availability and then an IS/390 in
the spring of '99. While weathered, the P390 now has three full bays of 18
and 36GB SCSI drives and has been running 24x7 for more than 5 years. While
the IS/390 is faster, it had just a one year warranty and an 18GB SSA drives
still costs more than $3,000! Over the past several months, we have been
looking at a MP3000 just like the rest of you. Unfortuantely, its size
presents us with some software licensing issues and it has the same service
and storage costs that we enjoy with the IS/390.
While everyone has been talking about price, little has been said about the
preface of yesterday's meeting. Specifically, Len Diegel outlined the
direction of the z/Series processors and why IBM decided not to make a
low-end MP3000 available. Here are some points:
1) 99% of existing VM/VSE clients are on platforms less than 100 MIPS,
2) while IBM could have delivered a further knee-capped MP3000 at a HIGHER
per unit loss, it still would have been
dead on arrival. Like Moses, the MP3000 is not going to the 64-bit
promised land,
3) the P/390, IS/390, and the PID version of the MP3000 were all I/O
constrained, and there was no good way to fix
the problem, and
4) the z/Series is leaving the sub 100 MIPS space.
Hence, IBM is architecting the new NUMA-Q and Netfinity based emulation
based offerings as REAL SYSTEMs that meet both the future needs of the
tens-of-thousands of real VS/VSE installations as well as the tiny PID
space. These systems, at saturation, will be CPU limited rather than I/O
strangled.
In another session, it was stated that V2R10 would be supported until
sometime in 2003. After than, the P/390, IS/390, MP3000, and a lot of other
great machines will be joining the PC Junior and Jimmy Hoffa somewhere in
the great unknown.
While I realize that it is easy to view the new offering as just a $3,000 PC
with some software in it, the Server 500 was just a sub $5,000 PC with a
MCA-390 card in it. However, both of the platforms include a bunch of other
optional goodies, e.g., tape. Bottom line, the whole package is going to
cost in excess of $20,000....... get over it!
>From my perspective, the key to this whole process is that it has a GROWTH
PATH. Since the PID program will be joining the VM/VSE users on a common
future hardware platform, our development platform is now a CONSTITUENCY
rather than a CAUSE within IBM. There is a real business case to keep
building platforms for the whole constituency. The plan is:
32-bit OS/390 on 32-bit Intel today,
64-bit z/OS on 32-bit Intel by year end,
64-bit z/OS on 64-bit Intel in 2002.
To be honest, it is not clear the PID community will ever need the MIPS
offered by the native 64-bit. The key is that we can continue to employ our
current business model and support our clients as they enter the 64-bit
world.
One last note, with the exception of the Fundamental Systems, Inc. emulator,
IBM seems to have a very dim view of the other emulators.
Dr. Pat
*****************************
Dr. H. Pat Artis
Performance Associates, Inc.
P.O. Box 5080
Pagosa Springs, CO 81147-5080
970-731-3273 x 105 Voice
970-731-1024 Fax
*****************************
Ben Moyle
He seems to have bought into the notion that hardware price is of major
concern, to users and to developers ('partners'). I submit that IBM
doesn't lose money by limiting performance of an MP3000 'further'. It may
indeed lose revenue, but it is for the same reason they make money by
selling more MIPS than users need - it forces the software license costs
up; capping the machine would 'cause' lower software groups to be
applicable. For many users they could give away the MP 3000 for free, it
would still be a bad deal. A free z/Series would be worse.
Similarly, the assertion that developer/vendor/partners are concerned about
the hardware cost of a NUMA-Q or Netfinity or MP 3000, or perhaps even
low-end z/box
seems misplaced. Vendors get the operating system software free (on
'loan', with some strings attached). We do get a deal on the hardware,
but that's not the main value in the program, especially for those who have
any involvement with MVS. (Actually, the current MP 3000 discounted
hardware price is essentially the same as that in the used marketplace, and
the 'developer discount' machine is tainted with a unique model number that
could affect its resale or support later.) MVS software licenses just
don't scale down to anything that is more attractive than using a service
bureau, despite the fact that the latter involves lots of significant
inconveniences.
I don't understand the reference to size-related 'software licensing
issues' re MP 3000. In the PWD program there aren't any. Is he talking
about some other developer program?
He says 99% of existing VM/VSE users are sub-100 MIPS, and z/Series is or
is going out of that range. No argument. Somehow that, and the fact that
MP 3000 isn't going to 64-bit sustains an argument for NUMA-Q and
Netfinity? Non sequitor. Users who can't keep a 100 MIP machine busy
aren't losing sleep over 64-bit support either. (I'm not really sure who
did ask for that, seems like a solution looking for a problem, but given
existence someone will fire it up, just takes one and vendors will need to
support it as if everyone has it.)
OS/390 will be supported until 2003? Which means what, it will stop
working then? Not at all. The limiting factor will likely be when
something else, e.g., perhaps a new feature in CICS or TSO comes out that
someone wants bad, but it is tied to a 64-bit hardware-required only
release. But that's not the point anyway. The problem with OS/390 (2.10)
is not that it will die, from a vendor's perspective it is already dead.
Offering a machine, emulated or not, that will support z/OS in 64-bit mode
in some distant quarter, with 64-bit z/OS hitting customers before that,
really misses a major point of a developer program.
If this were a political campaign, we'd be writing on the blackboard "It's
The Software, Stupid" (not calling Dr. Pat or anyone else stupid - my
point is we need to keep the focus on the software licensing implications,
at every step, for both users and developers).
Ben Moyle
BIM
Mike Hammock
with him, perhaps I can explain/clarify what I believe he meant.
Whether we think IBM should/could make a profit on a smaller MP3000
really doesn't matter. I have heard the message loud and clear multiple
times that IBM says/thinks that they cannot make a profit, so they are
staying out of that market place. Remember, if a 20MIPS MP3000 did
exist, it would be the same machine, and cost the same to make, as a 120 MIPS
MP3000. Perhaps they would lose money, I don't know, but I do know that
IBM has left the "hardware based under 60 MIPS" marketplace and will not
be back. Whether PID Members/Vendors 'should' be concerned about the cost
of the hardware is questionable, but the fact is that there are a number of
such developers who ARE very concerned. The cost of a MP3000 (and maintenance
over a 3 year period) is significant, and the FLEX-ES based alternatives offer
a significant cost savings. Normal users (non-developers) are even more
concerned about both Hardware and IBM software, and the NUMA-Q and
Netfinity FLEX-ES based solutions offer some real attractive alternatives
for them also.
As to the 'size related software licensing issues'... I believe Pat was
referring to the non-IBM software that is frequently necessary on development
systems. For example, I know he uses SAS, and the license for SAS on a MP3000
is significantly more than for a P/390. For that matter Ben, do you provide
BIM products free to developers? If other software vendors fillow IBM's
pricing leads, then the license cost for a FLEX-ES based system can be
about 1/3 of the cost on a MP3000. That can be significant.
As for concern about the 64 bit world... while most VM & VSE users are not
concerned about 64 Bit, developers, especially OS/390 (z/OS) developers are
very concerned about being able to develop on a 64 bit system. You are
absolutely
correct that a 64 bit developers system should have been available before now,
but IBM did not do that. The MP3000 is not 64 bit capable; it's follow-on will
not be available for some time (12 months?) and will be expensive, and the z900
is out of reach, so the FLEX-ES systems are the only reasonable alternative.
Of course developers would like to have (need) 64 bit capability before the
4th quarter, but it appears that 4Q01 is much better than the alternatives.
Unfortunately, saying how the developers program 'should' work and what IBM
'should' do, does not accomplish much (other than perhaps even more ulcers).
We have to live with what we have, and I think this new option os using
NUMA-Qs and Netfinities with specially priced FLEX-ES offers significant
benefits over what we had before. Certainly not ideal, but better.
Mike
Tom Rae , WFF
relevant points worth extended discussion in both. Please accept my
apologies if you have a low-speed internet connection...)
My interests here are Ben's affirmation of the statement that most VM/VSE
users are sub-100 MIPs, and Mike's assertation that most VM/VSE users are
not concerned about developments in the 64-bit arena. We run a 412 MIP
(depending on your scale of choice) 9672-RD6 with six production VSE/ESA
guests (limited by the V=R/F ceiling in VM), four development guests,
assorted Tech and user education VSE guests, a substantial VM application
and OV/VM workload, and a number of Linux/390 SVM's. Every cost analysis
we've run over the past decade has indicated that alternative platforms
(including MVS and its brethren, *nix, and assorted distributed platforms)
will increase our costs substantially.
We are very interested in z/VM and 64-bit engines as they will allow us to
allocate substantially more storage to our VSE guests without completely
trashing the VM DPA. This could be accomplished via LPAR's, but we are
unwilling to lose the interconnection and control advantages afforded by
giving VM control over the entire machine. While not applicable at present,
I can see the need for a 64-bit z/VSE a few years down the road if external
pressures don't force us off this platform.
How many of you in the VM/VSE world are, in fact, running in +100 MIP
environments or would like to be ?? How many of you are interested in z/VM
and a possible z/VSE ?? I have a feeling that the answers to both will not
be in complete accordance with the opinions expressed below...
Later,
Tom Rae
Director, Technical Services
Kelly Douglas / Westfair Foods / LCL West
(403) 291-6330 fax (403) 291-6585
Martin
4th quarter, but it appears that 4Q01 is much better than the
alternatives <<
What about the HERCULES system? It has Z/900 POPS already (even TRAP+RP
feature).
I have no idea how HERCULES compares to the other systems running on a
UNIX-box stability wise, but even if it is not rocksolid yet, It sure
beats any no-box or big-buck solution.
--
Martin Truebner
mail: Mar...@pi-sysprog.de homepage: www.pi-sysprog.de
PUN2IPT & PUN4IPT to utilise dataspaces for SYSPCH/SYSIPT
TRAPPER - The CICS-debugger for S/390 with VSE or OS/390
Ben Moyle
Generally, if it is pertinent to an product-to-product interface scenario.
I believe IBM's motivation is partly that, and partly to stimulate overall
mainframe usage by encouraging product availability. We aren't in a
position for the latter to be relevant. But BIM products are not CPU-tier
priced, excepting those we acquired with that structure in place, and even
then we don't charge upgrade fees or increase the ongoing maintenance price
when the CPU ramps up.
But it's a good point about some vendors needing to license others'
products as normal users, and those being affected by excess CPU sizing.
DAVE LEWIS
>environments or would like to be ?? How many of you are interested in z/VM
>and a possible z/VSE ?? I have a feeling that the answers to both will not
>be in complete accordance with the opinions expressed below...
Currently we are on a 9672-R26 (219 MIPS) soon to be an X17 (178 MIPS)...
David Lewis
Systems Programmer
Dave....@NAMC.com
Mike Moore
----- Original Message -----
From: "DAVE LEWIS" <DAVE....@namc.com>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
sd...@propappr.marion.fl.us
I'm currently at 30 MIP but can clearly see that from 17 MIPS 2 years ago
that 100 is in my near future.
Z/VSE is not likely for me but unless CICS exploits it even OS is going to
have a hard sell. I really don't see Linux needing 64 bit in the VM
environment. It's more likely that VM folks will run an application on
another virtual Linux machine before it will approach 1 GB let alone 2.
It's just more easily managed. Getting right down to it database,
paging/memory management will be the likely winners for z/VM and OS.
Applications aren't really the issue. So if your running multiple
production (underline that!) environments in numbers exceeding 2GB of real
storage then z anything is going to help the operating system cope. I don't
see VSE being left behind here. I would be interested in seeing how many
shops that are running a single image of anything that are storage
constrained. I currently run a 1GB virtual VSE with 12 CICS systems
producing 100,000 transactions daily and it's paging at about 10/pps with
64MB supporting it. One has to be doing 1,000,000 CICS transactions a day
to even double this memory requirement. VSE is a long way from needing z
anything.
Vernassa
Lpar.
Lpar active only when I test a new version of VSE with little little resource.
>
> >How many of you in the VM/VSE world are, in fact, running in +100 MIP
> >environments or would like to be ?? How many of you are interested in z/VM
> >and a possible z/VSE ?? I have a feeling that the answers to both will not
> >be in complete accordance with the opinions expressed below...
>
> Currently we are on a 9672-R26 (219 MIPS) soon to be an X17 (178 MIPS)...
>
> David Lewis
> Systems Programmer
> Dave....@NAMC.com
--
Best regards.
Vernassa Adriano vern...@tin.it a.ver...@asf-tesi.it
System programmer
TESI Srl Via Mendicita' 24 12042 Bra Cn
Voice 0172.439331 Fax 0172.439851/ Cellular 0348.2558921
You can lead a person to knowledge, but you can't make them think.