× 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.



I understand your concerns, and of course those same concerns pertain to any stateful connections. But here's the thing (and Robert alluded to it already): the i is designed for handling stateful connections. Basically, every 5250 session is a stateful connection. When you move your architecture from 5250 to the web, you can either go stateless or stateful. If you go stateful (which is my preference), then basically the persistent web connection replaces the interactive 5250 session, just without the interactive bit! My PSC technology does exactly that - I just replace the 5250 with a JSP.

I have absolutely no issues running hundreds of users through stateful connections. The only thing you need to do is make sure you assign (and dedicate) enough memory to the JVM. Stick 500MB in its own subsystem and run your JVM there. As your needs grow, you add some more memory to that subsystem. But really you don't need a lot; that subsystem is just a thin layer over your RPG business logic. The RPG then runs using normal IBM i memory management which is tuned to support thousands of users.

It's really the best of both worlds - web UI with 5250-like speed. No, it's not as fast as pure green screen, but it's easy to get speeds measured in pages per second (as in 10 pages per second).

Joe

Joe

I have always steered clear of persistent CGI because of a fear that it will not scale as well as a standard stateless environment. Is this fear justified? I have never had the opportunity to put it to the test.

Kevin

On 31 Dec 2010, at 16:05, "Joe Pluta"<joepluta@xxxxxxxxxxxxxxxxx> wrote:

There is nothing particularly special about stateful connections. In
traditional CGI processing this is known as persistent CGI, and has been
around since about 1998. Not only that, it's a built-in capability of
the IBM i that has been around for nearly as long on the IBM Apache
server. As far as I know, it goes back to V5R1 or V5R2, maybe further.
That's a decade or so. And with IBM, you control it by session, not by
server, so you can have persistent or non-persistent sessions on the
same server.

Also, this is a fundamental capability of WebSphere. Via the Java
toolkit you can have both persistent and non-persistent connections and
in fact, if you needed to you could have both persistent and
non-persistent connections in the same session! EGL supports this
capability out of the box; when you define a program (RPG, COBOL,
whatever) to be called you define whether it is stateful or stateless.
So you can have both stateful and stateless connections in the same
session! Stateful connections each have a persistent job, with
overrides and ODPs and a QTEMP - the job is named QZRCSRVS and runs in
QUSRWRK.

So, it's nice that IceBreak has this, but it's really not unique to the
tool.

Happy New Year!

Joe

P.S. For debugging, you might want to look into Service Entry Points.
It makes debugging web programs a breeze, even in non-persistent CGI!



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.