On Oct 14, 2006, at 4:26 AM, Timothy Sipples wrote:
----------------SNIP______________________
This same phenomenon is true for other products. WebSphere Message
Broker
for z/OS, WebSphere Portal for z/OS, and WebSphere Process Server
for z/OS
are some more examples.
In principle a software developer or training provider that wanted to
support/train across a large number of IBM software products could
install
everything in one 3 MSU LPAR and pay much less for a rather long
list of
products than they would if they did the same thing on a single X86
Intel/AMD processor. It's just the way it works: the mainframe has
the
lower entry software license price for much of the cross-platform IBM
software catalog. Wasn't true some time ago, but it's true now.
I've seen another cost study at another capacity (a large one) that
shows
WebSphere Application Server for z/OS is less expensive than other
platforms. Knowing the source, construction, and verification of that
study, I trust it.
I suppose it's possible the 37X study was accurate for another set of
circumstances, at another time, for another customer. For example,
if I
pretend zAAPs don't exist then that can dramatically affect Java
economics.
Or if your unrelated software vendors are going to "tax" you simply
because
you add capacity, even if it's a separate LPAR, that could be
deadly. (Not
IBM's practice. Thank goodness for competition.) Anything is
possible.
It's also true that WebSphere Application Server runs twice on
mainframes:
z/OS (or z/OS.e) and Linux. Each can have different economics
depending on
the circumstances.
Finally, price is one factor. So are qualities of service. It
depends
what you're trying to accomplish. WebSphere Application Server for
z/OS
can deliver the best qualities of service. For many customers, for
many
applications, the price of NOT having these qualities of service
dwarfs
anything else. Sometimes, often, WAS z/OS is less pricey anyway, but
sometimes, often, it doesn't even matter.
- - - - -
Tim,
I am not going to say you are right (or wrong). I would like to
interject here though a thought that should be in everyones mind is
"support". I won't go into the long list of issue with IBM's support
in the area of MF UNIX, other than to chide IBM in the maintenance
for UNIX apps and their less than "good" documentation for unix apps.
IMO IBM has really deserted the end users in this area. Some Messages
that are undocumented and if they are documented they are *NOT* self
explanatory and when you try and apar them (or doc err) you get
laughed at. IBM started out doing this in the UNIX side and now its
carrying over to the MVS side. The cobol compiler is one such example
the (cobol people in IBM) state that a messages and codes manual is
not needed as the messages are self documenting, some are but most
aren't. When you call up to the support center and level 2 calls you
back they practically laugh at you for asking. This is a disturbing
trend at IBM and I would wonder if this is a wave of the future for
the rest of IBM. I for one would never buy an IBM product that goes
under the UNIX umbrella.
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
