Thanks Joe. Man! I hope you are feeling better. The "crud" has been bringing down house around here too. Thanks for taking the time, under the circumstances.

OK, OK. I get it. I am asking too much! I don't (and don't want to) know any of the technical implementation minutia. My summarized point is then "If IBM could build an integrated text-based, multi-user integrated environment 40 years ago, why can't they do it today with a GUI, multi-user, integrated environment". Your answer is (and I hope I paraphrase you correctly). "Technically it is not practical and it isn't a good use of the System i hardware". I am OK with that answer. That explains it for me.

Just a quick thought (when you feel better, respond if you like):

You'll have to show me how I can step from debugging my RPG code into my JSP running that code into my local Javascript or vise a versa. Didn't know that was possible. I have to switch debuggers. But, I use MyEclipse for most of my web development so maybe I am doing myself a disservice by not using WDSC for that area of development.

And, you'll get no argument from me about the System i's advantages. They are well known to me and I always lead with the System i as the recommended platform, for all of the reasons you cite.

Get well.

Pete

Joe Pluta wrote:
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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.