Re: Multithreading: was Java Vs RPG on iSeries

On Friday 20 September 2002 14:59, you wrote:
> 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,
thats the main diffrence, I need in this case. The parallel processes have to
communicate with each other: when they are finished and wich transaction is
handled by wich process. If you don't have shared memory to communicate, you
need the markers you mentioned in your previous posting, or you need DTAQs.
Further on, its very expensive starting thousands of processes, for each
transaction maybe one.

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

you don't need Multithreading for parallelism, but you need shared memory for
easy communication, its just more comfortable. How to get back the calculated
amount from a diffrent process??

>
> > 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?

Because only one server job handles all open cursors on the same connection,
there can't be parallelism. In a java environment you can have as many open
cursors you need and all can read from or write to the database at the very
same time, running in diffrent serverjobs on diffrent CPUs. (just another
example: loading a subfile in the background, while the user is editing a
record is impossible in rpg and very easy using java).

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

I did never say, that this is the main benefit of java - and that you need it
for this. The reason to start this discussion was the statement, that
performance of java is too worse to compete with rpg or COBOL or C ... at any
time. And Batch jobs are just the example everybody uses to proof this
sentence and the discussion was just an exercise for the brain, that this
sentence sometimes might be false.
One remark: I've used parallelism for speeding up batch processes using pure
CL and RPG technics more than once; especially speeding up save jobs or
recovery times dramatically; and it saved my custumors quite a lot of money,
four rather inexpensive tape drives might be faster than one expensive. But I
had to write the communication of this processes by hand. If I would have
quite a lot of processes, I would absolutely prefer java.

The idea behind this is essential for understanding the further evolution of
java performance. Interpreting, late binding, no optimization at compile time
is bad for performance today, but it might be better for parallelism
tomorrow. And this is an as400 issue today.

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

Feel free to send an eMail to my adress when this situation is coming, maybe
we can share some code (even CL or RPG)
>
> Thanks for all your comments so far!
>
> Joe
>
> _______________________________________________
> This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
> mailing list To post a message email: JAVA400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
> or email: JAVA400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.

--
mfG

Dieter Bender


DV-Beratung Dieter Bender
Wetzlarerstr. 25
35435 Wettenberg
Tel. +49 641 9805855
Fax +49 641 9805856
www.bender-dv.de