RE: Multithreading: was Java Vs RPG on iSeries

Dieter, I agree with you every step of the way until the very end, where you
talk about implementation:

> From: Dieter Bender
>
> To use this technique, you have two requirements:
> 1. Multithreading, to split a workload in parallel transactions

You don't need multi-threading for this, just multi-tasking.  This is a key
issue: multi-threading is specifically about multiple lightweight processes
sharing the same memory space, and that's absolutely not requiid for the
application level multiprocessing that you're talking about.  Multi-tasking
will do fine here, and RPG (in fact, any AS/400 language) just fine.

> 2. Application Server:
> Multiple connections to one database possible for java, impossible for
> embedded SQL in COBOL or RPG, SQL CLI I don't know; I didn't do that up to
> now.

I'm not sure what you mean by this.  You can easily have multiple cursors
open in RPG, why is that not enough?

> In Java you can use EJBs and it depends on the container, wether it can
> spread it over multiple JVMs. Maybe that using WebSphere needs
> the enterprise
> edition, not available for AS400 (<flame>WebSphere is no
> strategical product
> for as400 - as long as the full version of Websphere is not supported!
> </flame>)
> In a traditional environment CORBA could be a solution (<flame>AS400 is no
> strategical product for ibm - as long as CORBA is not allowed to run on
> as400</flame>). Another approach there is MQ Series, but MQ
> series compared
> to EJBs, I suppose that EJBs will be faster and they will be
> faster in near
> future definitely.

This is the only place where I might see any benefits of J2EE.  When you
start building your systems from the ground up to use J2EE in a massively
parallel environment, EJBs might help, because they might be able to
distribute the workload transparently to the programmer.

Notice that I say "might be able to".  That's because I have no great faith
that these techniques can be applied to traditional business applications,
nor that it will actually help businesses in the long run.  This entire
discussion revolves around reducing batch processing time, and I'm just not
certain that the particular problem yet needs a solution, ir at least not
one of the magnitude you're presenting.

But in any event, you clearly are more comfortable discussing this portion
of the technology than I am, so I will defer to your knowledge.  And as I
begin to run into situations where parallel processing makes sense, I'll
certainly remember this particular discussion.

Thanks for all your comments so far!

Joe