Re: what was the single mgmt decision made in mid-1990s. period

Mark,

Meet the new IBM. In prior generations they "made up the revenue" by restricting the CPU, placing a governor on interactive workloads, and exacting a heavy surcharge for "interactive features". IBM had a hard time explaining it. Folks had a hard time understanding it.

Even folks who relate better with the old IBM had an aha moment when they merged "i" and "p" divisions and introduced price / performance parity across product lines. The AS/400 was gone. The organizational divisions were merged. No more funny money. No more slight of hand. IBM is not really known for transparency, but this was a step in the right direction.

But it was more than hardware consolidation. There was a java virtual machine, web application middleware, developer tools, and database consistency that homogenized the platforms.

What you're asking for is a big deal. It would be new and completely unique to "i". It would compete against their AIX and Linux platforms. It would compete against RDI-SOA. And that goes against the grain.




----- Original Message ----
From: M. Lazarus <mlazarus@xxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, February 18, 2009 2:36:57 PM
Subject: Re: what was the single mgmt decision made in mid-1990s. period

Nathan,

At 2/18/09 02:49 PM, you wrote:

From: M. Lazarus
1) Cheaper development costs.

IBM may not openly debate that, but they are promoting RDI-SOA as an
alternative to a native GUI. They expressly position it as a
programmer productivity tool. What you're asking for would compete
against their own product - disrupt their own ecosystem.

That's part of the problem. They are charging for something that
should be included, in order to promote the system. I do realize
that there are development costs to create these tools. Based on my
observations talking to customers, prospective customers and
colleagues in IT, this decision is costing them far more than they
are making. When it comes time to make a decision to spend money,
anyone that can afford to jump to other, cheaper, prettier platforms
are attempting to do that.

IBM should find a way to make up the revenue in other areas and, of
course, in increased sales.

2) We can claim that "it's in there"

When I consider the breadth and scope of Web technologies that
exist, I have a hard time understanding what "it's in there"
means. Just consider the AJAX frameworks, alone.

OK, so I oversimplified the process. The "it's in there" comment
means that there would a simple hook (similar to the EXFMT opcode) to
generate and read the HTML page. Or maybe even make CGIDEV2 an
official supported extension.

3) We don't have extra 3rd party layers to deal with for a necessary,
very integrated function.

Again, when you're dealing with distributed, client-server
technology like Web interfaces, you really can't characterize them
as "integrated" with the server - at least not at the same level as
the 5250 interface.

My reference to "integrated" refers to the ability to RPG's
integrated I/O. As I previously mentioned, there are definitely
considerations that are different when implementing a browser I/O
data stream vs. a 5250 data stream. But I would like to have
something along those lines.

The overall benefit is that the people promoting the system in the
field would be able to sell it without the usual "isn't this that
really old system?

Sorry, but I have more disconnect there. IBM already provides HATS
and Webfacing, as a mask over 5250. Are you suggesting that they
rewrite every native command as a new Web application?

My main concern is user applications, not the system menus. HATS
would probably work well enough for the system menus. My users
rarely see a system menu, so it's a low priority for me.

-mark