RE: Saving the System i: Fight Rather Than Switch -- MIDRANGE-L

From: Pete Helgren


There are too many pieces here that I disagree with fundamentally, and I'm
right now very under the weather, so I'm going to just try to do a little
level setting

I can't say I am an expert on the technical aspects of *how* to
implement System i native GUI.  I guess, based on what you are both
saying, it is nigh near impossible.  Bummer!


It's impossible to create a good-looking GUI using the block-mode interface
of the 5250.  You CAN create key-by-key applications (Office Vision was
one), but it's far more difficult than the standard 5250 interface you're
talking about.  It's your comparison of an event-driven, keystroke oriented
user interface with the block mode architecture of 5250 that is flawed at
the very lowest level.

Moving on...

1.  Run a PC based application to design your UI with language "X".
2.  Deploy it to a "server", so you can see what it looks like and do
some rudimentary testing.
3.  Write your business logic on the "midrange" box in RPG remembering
that it is separate but callable from the "server" application. Good
news! The DB IS integrated!
4.  Debug your application with perhaps three debuggers: One to debug
the "script" that manipulates some of the client-based code, one that
debugs the UI server code and one that debugs the business logic.
5.  Deploy the completed application in two or three parts, each running
in a different "execution" environment.
6.  Hope it all works.
7.  "Rinse and repeat" with the 300 other applications that you are
developing.


With WDSC, you design, develop and test all tiers of your multi-tiered
application (including debugging of all the tiers, from RPG to JavaScript)
right inside of the workbench.  When done, you export a WAR or EAR file (a
single step process), import it into your web application server (another
single step) and you're done.

I don't know how that integration was achieved.  Tom, you seem to know
that and seem to know that it can't be done in the GUI environment.  I
wonder if someone at IBM said the same about text based, multi-user
computing in the 60's.  Obviously, whatever the technical challenge was,
however apparently impossible it might have seemed, they did it.


It's far less technologically demanding to create a block mode interface,
especially if you have complete control over the client computer (make no
mistake, the 5250 was a pretty powerful microcomputer in its own right at
the time).

Yes Joe!  Getting the System i into that space where no one else has had
success, the integration of a "native" GUI into the OS and development
environment, is EXACTLY what I am talking about.  Without that, my point
is that the System i is just another computing platform.  A darn good
one. A very stable, manageable and scalable one.  But still, in the GUI
world, *just* another platform.


The IBM midrange is the most stable, most secure, most reliable, most open,
most interoperable server on the market today.  It is the ONLY system that
boasts an integrated database, the ONLY system with a native indexed access
method, the ONLY system with RPG, the ONLY system with built-in work
management... the list goes on and on.  What the machine is, is only the
best business rules processor on the planet.  It makes tremendous use of its
cycles and to waste those cycles on plotting pixel positions for 1000
screens is a bad idea.

And, yes, I have programmed Windows apps in C, in C++, in VB, in
Smalltalk, in Java.  Yep, it is pretty dang difficult to do it right
(easier in some languages than others). But that is in an environment
where you may need to consider deploying the resulting application to
multiple OS's and multiple versions within OS's.  Seems to me that IBM
could have gotten GUI applications right for development and deployment
on the System i */exclusively./* That is what they did with 5250
applications and it worked very well (better than DOS but looked *just*
like it!). Doing the same with a GUI seems like a way to leverage those
same System i benefits and assets in the same way a text UI worked in
the past.


Again, you're talking about fundamentally different paradigms.  Block mode
interfaces came from CICS, not from DOS.  They don't look or act just like
DOS; DOS applications work on a keystroke-by-keystroke basis.  About the
closest you get to that block mode idea is JSP Model II, which the iSeries
does very well, thank you.

Anyway, enough here.  I'm literally sick and tired.

Joe