And seriously, I don't think you need threads in i5/OS, just dedicated
jobs. You start the job when the user authenticates and end it when the
user logs off or times out.
So how does that architecture work for an Internet app where there are going
to be thousands of users? I guess that is where I was going with the idea
of doing threads on the RPG side. Don't know if those would all reside in a
single job or not. Nor do I know how much performance is gained/saved by
going the thread vs. job route. In the end I would guess that the main
savings is in the startup of a thread vs. a job, and after that the same
amount of resources would be consumed (i.e. ODP's, program storage, static
variable storage, etc).
Would be an interesting test to run: Start 10,000 jobs and time it. Start
10,000 threads and time it.
BTW, I agree that with the IWS it is very appealing to just install a thin
J2EE layer that communicates with the RPG. Especially given the significant
performance enhancements to Java in V6R1 with the Power6 chips. In your
mind are you still consuming the resulting data from RPG by manually typing
out JSP code? Or do you have an "engine" of sorts that takes the data (with
additional markup for names and coordinates) and have the JSP/Servlet
dynamically display the results? I know this is usually where we disagree,
but if you had the latter, then the RPG programmer wouldn't have to know a
lick of Java/JSP/JSF/EGL/Servlet/etc. They would simply have to know how to
send and receive messages from the relaying mechanism (i.e. data queues).
On a slightly separate note, do you see an advantage for server initiated
communication to the client? This would be more of a true async model and
removing polling from the browser using AJAX.
Aaron Bartell
http://mowyourlawn.com
midrange.com
