RE: Boise Idaho User Group? -- MIDRANGE-L

> From: Don
>
> Al's got a very good point, and I'll go futher.
>
(...)
>
> Clearly, if you have the best stuff on the market, but nobody knows about
> it,doesn't learn about it in school as part of their normative cirriculum,
> doesn't hear about it in the trade rags with enough frequency and
> magnetude to keep thier interest, then, it's not going to gain any
> marketshare....

I usually avoid this topic, because it's usually the same song being played
over and over.  "Woe is me, IBM isn't marketing my beloved OS/400!"  Well, I
don't know about you, but I don't remember IBM marketing the S/3, the
Series/1, the S/34, the S/38, or the S/36, either.  The fact that we (the
OS/400 community) have at least been included in the eServer community is
actually more attention than we've EVER gotten.

I agree that we could use better marketing.  I sincerely wish one of those
stupid basketball jerseys in the commercial would have "iSeries" or "OS/400"
on it.  But when all is said and done, it's not marketing that ultimately
sells computers.  Go ask Apple.  It's killer apps.  Windows won because
Windows was, ultimately, the killer app.  Some incredibly (insert your
adjective from "astute" to "illegal" here) business practices on Microsoft's
part certainly helped, but it wouldn't have done a damned thing if Windows
didn't fulfill a market need.

And that's the problem.  The IBM midrange fulfilled a very important need in
the 80's and 90's: that of business application processing.  RPG and COBOL
were used to build millions of business programs that did things no Excel
spreadsheet could accomplish.  And that's still the case today - RPG
programmers can develop business logic faster than any other developer.

However, we've been blinded by science, so to speak.  Two coincidental (and
cross-pollinating) trends have caused a change in the landscape.  Faster PCs
and their correspondingly better graphics have combined with the concept of
pushbutton programming to create a new generation of people who write
"software" without having a clue as to what basic programming is all about.
Read the questions in the forums over the last five or ten years and you'll
see how they've gone from "How do I use this API" to "tell me how to send
email on my AS/400".

People are writing more and more code without really understanding what
they're doing.  This is creating a "magic box" syndrome wherein nobody
really cares what happens as long as the job gets done.  I'm not making a
value judgement here because people need to get their jobs done.  But the
fact is that we've all begun to fall prey to this.  We ask IBM for tools
that will write our entire application for us, just by pointing and clicking
on a screen.  We want "wizards" to generate "data access beans" which we can
then "drag and drop" onto or "visual editor" to create "business
applications".

Oh pshaw.  That ain't codin'.  That's simply delegating the work to someone
else's hands, because we can't or won't take the time to develop the
necessary skills.  We're going to accept whatever code the wizards generate,
which may be fine for GUI but I'm relatively sure is going to be absolutely
subpar for business logic.  Just because we don't have the skills.

And what are those skills?  What skills are we lacking?  What skills haven't
we learned over the years?  It's not database design.  It's not application
logic.  It's not business logic.  It's not transaction processing.  We've
got all those down COLD.  Basically, it's just GUI, be it thick client or
browser.  In a character-based environment, put an RPG programmer with
OS/400 and SEU up against a programmer in any other language, and I
guarantee you'll get a better UI, better business logic and a more thorough
design from the RPG programmer.  Java and Python be damned, they just ain't
business languages.

So what do we do?  Well, we could huff and puff and insist that IBM provide
a GUI for us.  I think that's a waste of OS/400 cycles.  We all know that
IBM charges a hefty premium on OS/400 cycles - just imagine what it could
cost if it were managing all those megapixels as well.  Insanity.

We could tell IBM to make "application development tools" that will generate
entire applications for us.  This is in effect what we're doing, but guess
what?  Do you think it's in IBM's interest to develop tools that take
advantage of the iSeries, or to develop tools that span their product line?
If they can generate one set of specifications that run on all platforms,
but that aren't optimized for the iSeries, do you think that'll be good
enough for IBM?  Of course it will be.  And if your code isn't designed to
run on the iSeries, with it's relatively high cost per CPU cycle, then the
iSeries is going to lose out in a pure price performance comparison.  So by
definition anything from IBM is likely not going to give the iSeries any
competitive advantage.

So it's down to us.  The user community.  We need to develop the killer apps
that will allow our platform to not only survive, but thrive.  I think I've
delivered something close with PSC/400.  With PSC/400, you can have
good-performing browser-based applications with no HTML knowledge
whatsoever.  RPG programs directly to the web, with no additional tools.
It's enough to allow us to use our legacy programs AND LEGACY PROGRAMMERS,
with their decades of programming expertise, with a browser interface.  But
that's not enough.

We also need to start developing a next-generation architecture that will
take advantage of OS/400's unique strengths while allowing it to work and
play with other applications.  Not as an expensive SQL engine, but as a
business transaction server.  And it can be done!  If someone were to extend
the new Eclipse platform to allow the creation of client/server
applications, perhaps using a simple XML communication medium, then we'd be
home free.

RPG programmers could design business logic, UI designers could design UIs,
and the two could live in harmony.  It would require an active separation of
UI and business logic.  But as long as we insist on using all-in-one tools
that do cradle-to-grave development, generating some obscure "data bean"
rather than just a simple message, then we abdicate our role as business
application developers.

Anyway, I'm ranting as I often do.

Gotta go do some work.

Joe