× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



A couple things.

With all the yuck yuck about HTML and such, have others looked into Xforms?
http://www.w3schools.com/xforms/xforms_intro.asp


I do this with my PSC product. I web-enable subfiles and even over
a WAN we
get sub-second response time.


That I would really like to see - especially with some rather complex
screens that require updating based upon processing of entered data.

I have seen it. Joe came in-house to my previous employer and built some
thin JSP to thick RPG applications for us; which I am assuming is similar to
what his PSC product does out of the box. Very fast. The only time we had
slow responses, from what I recall, was when WAS had hiccups. We should
have tried Tomcat and that app would have been even faster!

Joe, do you have some example applications that I can load on my box for
people to test? I have a hole punched through my firewall to my iSeries. I
haven't loaded Tomcat yet though (maybe a 1 hour process at most). Note
that I won't be able to do it for about 1 month, but thought I would get the
ball rolling anyway.


Aaron Bartell
http://mowyourlawn.com


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Paul Raulerson
Sent: Monday, April 16, 2007 8:35 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: What do I use?


On Apr 15, 2007, at 10:18 AM, Joe Pluta wrote:

From: Paul Raulerson

The comparison in terms of "thick" client is something on the order
of Visual Age Developer, which isn't something most RPG programmers
are going to come in contact with. This is pretty much were EGL
descended from. It can generate a full fledged application, including
all the UI interfaces, and runs through CICS. It's getting a bit long
in the tooth, and Rational is now grafted on to it with an Eclipse
front end. I used VA/GEN pretty much in the late 90's and very early
part of this decade.

Uh... you haven't kept up with the tool at all. It's now a fully
functional Java-based generation tool. It is actually the focus of a
significant portion of IBM's development strategy, and the
enhancements you'll see over the next few years will be quite
impressive.

One thing: to call EGL long in the tooth and then promote Citrix,
which was created back around 1989 or 1990, is pretty funny :).


It doesn't even exist anymore Joe - it is now part of the Rational Suite. It
has *always* generated Java or COBOL code, even back in the days when it was
knows as CSP. ;)

Heck, I don't complain about anything just because it is old - I program in
Assembler on a regular basis, as well as RPG and COBOL and C. But IBM often
will get on the train for the "latest and greatest"
technology, and then abandon it not too many years down the road.
Rather they will for this kind of technology.

Citrix, or the other application servers that replace it are really
*really* good at what they do now.


It doesn't take much, if any, longer to get someone able to do the
same with VARPG, or indeed, even with Visual Basic or any of the
other applications languages out there.

There's a huge difference between page-oriented and event-driven
screens.
It's very difficult to teach someone the way to properly design a
multi-panel, widget-rich environment. You can teach someone how to do
thick-client 5250 panels, but to teach them to build the rich,
interactive
graphic applications you're talking about takes a long, long, long
time.


A standalone GUI app is far closer to event driven than it is to a
green screen of course, while web screens are much closer to green
screens. The fact that they use shadow pages and JSP technology (and
AJAX and all the real new stuff too) to make web applications more
like a standard GUI application is also telling.

You are stating that it takes someone a "long, long, longm time" to
learn to build a proper GUI application - and stating it like a fact
graven in stone. It is nothing of the sort.

Sit someone down and you can teach them to write a standalone Visual
Basic application to do something useful in about a day. It takes a
day to just to cover the multiple technologies needed to write a web
application, much less get anyone started writing one. The VB
application can be written on a standalone PC, and deployed from the
same PC with a high level of confidence that users will be able to
install and use it.

A web application requires a pretty extensive infrastructure be in
place and setup before you can successfully deploy.

There are toolkits and languages similar to Visual Basic on Macintosh
and UNIX platforms as well. All at approximately the same level of
difficulty as teaching Visual Basic on a Windows machines.

And deployment using an application server is a snap too- generally
not much more than installing the program. Yes, it requires some
infrastructure setup and maintenance, even in a tiny deployment, but
you can do tiny deployments too.

Few programmers of ANY ilk (and I consider RPG programmers to be
some of the
strongest programmers around) find it easy to create intuitive user
interfaces of the level of Microsoft desktop applications. That's why
there's really only one major Open Source competitor.


Huh - the same is true of web applications by the way.

I disagree with your reason why there is no successful challenge to
Office by the way; the level of difficulty is not the reason - it is
the lack of market that keeps it from happening. If it is worth
doing, it is worth getting paid for, and MS has that market locked
up. The products are good. The interface - well - the interface is
not all that good, especially in the 2007 versions.


The real alternative is application servers - like Citrix or NX.
Deployment takes even less time than the typical deployment time for
a WebSphere application, and screen display is far less dependent
upon network and local processing resources.

Nah. I don't see X-Windows style interfaces flourishing. Too low-
level.
You're going to need a standardized widget presentation language
patterned
after HTML (something lie XUL) so that the presentation side can
format the
stream as it needs.


Ah - you have it already, in things like TCL, Ruby, and other
applications. And the idea of widgets came from X11 in the first
place. ;) But seriously, HTML is too clunky. A Visual Basic like
interface for the web will be what eventually wins. Rational Web Dev
is close, very close, but way too overloaded with complexity and
piggy performance. It is also too darn expensive to put on a million
desktops or so, though IBM would be glad to provide a deep discount
there.

Yes, I am aware of the Microsoft web development tools - ASP has
problems just like the IBM Java based equivalents.

They will get there eventually, but I really expect what we will see
is a thin client Visual Basic at that point. Probably running on top
of X or Aqua. :)

And as far as I can tell, the licensing for Citrix is horrendous.
How in
the world are you going to support 10,000 users for Citrix? Does
everyone
get a CAL? Or do you just run out of CALs during your peak
business times?


Yep - Citrix licensing is a PITA, second only to Microsoft licensing.

So use 2X, or Linux, or NX, or some combination. All of those can be
obtained for free if you want to support yourself, or at a very
reasonable cost from SuSE or Redhat or other places.


It has everything to do with sluggish from our perspective. Can you
send me some links or additional detail on web apps that fast offline
please? (P a u l [at] Raulersons dot com)
We typically cannot even get a browser or Java application to refresh
a display that quickly. That kind of speed would be a big factor in
our evaluations. And that is using the internal gigabit network - lag
and queuing delay over the WAN make it miserable for complex screens.

What's so hard? Write a simple servlet that updates a counter and
outputs
it to a JSP. Have the JSP show the counter and a button. When the
button
is hit, go back to the servlet.


I rather thought you were talking about a real application, the kinds
that have to hit a backend datasource, perform significant edits on
the data, and redisplay screens fairly quickly. Hopefully doing
things like telling the user what went wrong. You can get subsecond
response out of a Palm M100 with the kind of application you describe.

I have not seen a real heavy duty transaction processing application
on the web with the kinds of response time you indicate you get -
especially on applications distributed over the WAN to multiple
remote geographic locations.

I would be quite willing to look at one if you know where one is.


Create a JavaScript function to check for the page down key. When
it senses
the page down key, it presses the button. Start the application,
hold down
the page down key. Unless you have some serious latency issues,
that page
should update the counter many times a second.

I do this with my PSC product. I web-enable subfiles and even over
a WAN we
get sub-second response time.


That I would really like to see - especially with some rather complex
screens that require updating based upon processing of entered data.

Yours,
-Paul


Joe


--
This is the RPG programming on the AS400 / iSeries (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




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.