On 9/2/2012 11:04 AM, John Yeung wrote:
To those pointing out that you can get a very capable i to run lots of
stuff that would otherwise run on multiple commodity servers:

That's all well and good, but in my experience, it is common to have
multiple platforms anyway. Where I work, we have a relatively small i
as well as a host of other machines. Would it be easier to administer
a large i rather than the complex ecosystem we have? Almost
undoubtedly. But the upfront cost would be astronomical for a company
our size. Not just in dollars but in time and headache.

Like many other companies, you have an organically grown infrastructure. Bits and pieces have accreted over time and so now you are every bit as locked in to your current environment as you say IBM midrange customers are locked into theirs. It happens.

Now, I can't say that we are in a position to abandon the i either.
But would it be easier/cheaper to migrate non-i stuff to i, or to
migrate i stuff to non-i? Both of these are painful (and perhaps
impossible for many companies), but it *feels* like moving toward the
i is moving toward lock-in, and moving away from the i is moving
toward greater freedom (interchangeability, scalability, software
choices, etc., etc., etc.).

Migration to an IBM i-centric environment is different for everyone, but migration AWAY from the IBM i is nearly always more painful in the long run. Typically an IBM i system is tightly integrated and highly customized to the business requirements of the company. If you replace this with commodity hardware and software, you lose the business advantages of your applications. If you try to rewrite the code to replace the functionality, you end up spending a ton (both in time and money) on custom development and there goes the price advantage.

I stress that it *feels* like that. Maybe it wouldn't feel like that
if IBM made their case better. There is a strong association not only
of i with green-screen,

That's should be easily countered, since not even IBM pushes the green screen. Twinax is barely supported and they aren't updating their own green screen development tools. Simple education point.

but also of i with OS/400 and its descendants
(sorry I don't know the proper name).

The whole point of getting the IBM midrange is to take advantage of i5/OS (or IBM i OS, whatever the official name is). RPG and DB2 are your core tools. The database is rock solid with powerful SQL capabilities, and RPG acts as assembly language for the database allowing peak performance where required. The operating system itself provides job management, security and auditing features that are unsurpassed, all in a package that is virtually unhackable and virus immune.

If none of that matters to your business, then by all means move to Oracle on Red Hat.

I know at some point there was
a split between Power hardware and the i OS, but this is not well
known and the implications of this are not well understood.
(Especially outside the i community, but even to a large extent within

I'm not sure I understand the question here.

For example, it's not completely clear to me whether you're "supposed"
to run both native i and *nix stuff on the same box. If the answer is
yes, then is the *nix stuff "supposed" to be run on PASE or
"natively"? If PASE, then is there an answer for the porting hassles
and apparently sluggish performance? If "natively" then are there
options other than AIX, and do these perform as well as commodity

You have so many options. First, you can run AIX, Linux and i5/OS partitions all together on the same physical hardware, all linked via shared hardware (including ultrafast virtual ethernet links). So whatever your specific requirements are, you can do it. Additionally, i5/OS allows you to run various levels of compatibility and integration solutions, whether it's QShell, PASE or various flavors of Java VMs.

If the i is somehow "managing" disparate platforms on the same
box, surely there is some kind of performance overhead for this? Is
the benefit just the reduced number of boxes to manage, or is there
some kind of interoperability improvement (like shared storage, or
smehow better communication between a native i program and a native
*nix program on the same box)?

Not really. This isn't running VMWare. These are separate partitions that are managed by a hypervisor. CPU cores are assigned to the partitions and run the OS.

For all I know, there are great answers to these and other questions
that come up whenever people talk about the i. If there are, they
should be pushed out there much, much more vigorously.

This I agree with. To be honest, I've got no business talking about some of this stuff because I'm no expert. I'd prefer to hear this story from IBMers or from people who really know the stuff like DrFranken. But I can tell you from decades of real world experience that the best configuration for any IT infrastructure revolves around centralized business rules processor, with ancillary machines as necessary. Here's my take on it, with roughly three zones:

The IBM i is the premiere business rules repository and occupies the central zone. No duplication of rules, no stale rules, everything in the rest of the infrastructure gets its data from the IBM i. Make rules available via stored procedures and web services.

The second layer consists of systems that still need the highest level of security and uptime. These run either in virtual environment (PASE/QShell) or as partitions on the IBM i hardware. Note that this can even include file servers for business critical data, where you trade off some performance for the ability to have integrated backup and recovery plans.

Other systems, whether they're third party shrink-wrap applications, office automation functions, industry-specific hardware/software solutions (think CAD/CNC), can all run in the outer shell. This can also include web applications outside the DMZ that interface with inner shell functions, although for security you may still want to run WebSphere or Tomcat on an IBM i partition that's in the DMZ.

Anyway, that's my take on it. Every organic system I've seen has numerous issues: duplication of data, redundant (and stale) business rules, and security holes big enough to drive a truck through (through things like hard-coded uid/pwd combinations or the like). Usually they get to a critical mass and then require a complete overhaul to address those issues. And that is nearly always every bit as expensive as doing the IBM i-centric solution from the beginning.


This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page