While I agree with you that it's silly to put a cap on the processing power of the iSeries, it is neither immoral nor inethical.
On the side of stopping this sort of thing, yes, I believe that the iSeries would be a more attractive buy. IBM is putting up barriers to purchase on the machine. They're encouraging me to use some other company's servers.
On the other side, those running IBM have a duty to maximize the shareholders' profit. If they beleive that one legal action over another will do that, then that's how they need to go. They let you know the rules before you buy the machine, so there's nothing evil about what they're doing.
Overall, I'd like to see the limits gone. IBM, if you're listening, at one customer of mine, instead of putting everything on two 400s, they put it on one 400 and 3 PC racks, purely because of this silly limit.
The interactive feature cost is appropriate and reasonable, and it probably should have been in place earlier than it was.
People seem to have forgotten what the system costs were like before IBM changed the pricing model. IMO, the only problem is that IBM introduced the new pricing as tiers of <b>rising</b> costs rather than tiers of <b>falling</b> costs. IBM might have priced base systems with full interactive and allowed feature codes that gave discounts for lowered interactive levels.
Interactive support has costs that must be paid by customers. The amazing internal transformation that brought telnet devices into the whole "device description" scheme without disrupting existing device elements and requiring new commands and security configurations, along with inventing tn5250 and tn5250e, and making them publicly available standards to allow free replacements for IBM's terminal emulation software (which drastically affects revenue) wouldn't have been possible otherwise. By complaining about paying for it, there's an implication that we should be using telnet emulators that have capabilities on the level of the Windows telnet client.
IBM has supplied numerous ways to reduce the costs, yet no one wants to make any effort to do so. It doesn't cost much to run interactive sessions; what costs is the use of CPU resources while in interactive sessions. But who's made any serious effort at using those features? Route heavy-use program calls to batch and don't use interactive cycles. It's not that hard to do. IBM publishes specs on it.
And complaints centered on the "speed" of green-screen data entry are pointless since GUI interfaces are used to present "green-screens". iSeries Access terminal emulation is a GUI app after all. Just because the presentation pane uses characters is not a rational reason to use it as an anti-GUI example. What it is is a counter example to the baseless assertions that "GUI is slow for data entry". It's only slow if you code it to be slow.
Nobody complains that MS SQL Server can't access DB2 on System i. Why not? Because IBM does what database vendors are supposed to do and provides a free ODBC driver that runs on Windows. But everybody complains that DB2 on i can't access MS SQL Server. And the complaint isn't that Microsoft ignores their responsibility as the database vendor and won't provide an ODBC driver; the complaint is that IBM doesn't do it for Microsoft. Or complaints are that IBM doesn't support Microsoft non-standards for e-mail. Or complaints are that IBM doesn't support Microsoft non-standards for .Net.
IBM publishes public specs for all of their external server interfaces. But nobody wants to take advantage of them. Instead, the expressed opinion is that IBM should reduce prices and provide everything.
Even many developers refuse to use WDSC or RAD. Far more can be done with them (and they don't take interactive cycles), but it takes a little effort. Of course, IBM receives complaints because they don't fully run on Linux or Mac OS -- for free... or 'make those users pay for that capability' (but not pay for interactive).