RE: FW: Java Vs RPG on iSeries

>. . . MRP as programmed by people who understand it
>from a business standpoint.  You may be right that you could apply some
>wonderful parallel processing techniques to MRP to speed it up.  But
that's
>supposition, and takes for granted the rather sophisticated programming
>expertise required to develop truly parallel systems - expertise not
>generally available in ANY market, much less the iSeries market.

Joe, I must disagree or at least suggest it shouldn't be so.

My credentials here are simple:  I designed and wrote the original page
fault supervisor for S/38.  Moreover, what goes on in what we now call
Licensed Internal Code is very analogous to Java threading in a great many
respects.  Moreover, I hold some hardware patents related to this kind of
stuff on the one hand and have had discussions with Sun architects on this
very topic on the other.  I think I can speak knowledgably on the topic of
program parallelism at any level.

I say, if people aren't applying wonderful parallel processing techniques
to MRP, using Java technology, they are missing a bet.  A lot more people
_should be_ doing what you suggest is rare.  It is little short of
metaphysical certainty that on other platforms, they already are doing
this.

Java has done something very significant here -- Java has deskilled the
process of writing multi-threaded apps compared to any other programming
language I know of.  Multi-threading is not as sophisticated a task in
Java, in other words, as it is in other languages.

These features are not generally understood in their fullness even by most
standard texts teaching Java.  There is, however, a very good general
multi-threaded programming strategy built deep into Java.  It goes way
beyond the synchronize verb or the mere existence of a Thread object to
concepts like immutable objects and other key idioms readily and easily
expressed in Java.  More importantly, it is not just theory -- key items in
java.lang.* and so on actually _are_ expressed in multi-threaded terms,
giving an enormous practical head start on a realistic implementation of a
threaded application.  If you want multi-threading, it is not an unnatural
act with alternate versions of every major interface as it is in, say, C.
Instead, you mostly use the same old stuff you always did and without a lot
of new restrictions, at least for many critical and core constructs.  This
is not true of everything (it is not, for instance, true of GUI), but it is
true of enough stuff to really help.

Any one looking for a short course on this should study java.lang.String
and java.lang.StringBuffer and look around for explanations of "immutable
object" in the literature.

Just as RPG made DB programming much easier, so these Java constructs will
de-skill the process of multi-threading, opening it up to many more
programmers.

Also, without making this a very long treatise, I will state that:  ". .
.expertise not generally available in ANY market" would be disagreed with
by those in various Unix or NT markets, including people who write code for
banks and like businesses.  Plenty of programmers have used far inferior
tools from C to do this multi-threading stuff and have for a long time now.
Where do you think the incentive came from for the Java designers to invent
all this?  Not everyone does their locking in the data base.

Whether it is possible to teach Java multi-threading to existing iSeries
Java programmers is, I suppose, an open question.  But, I'm optimistic
because I already have concluded it will open up this technology to more
programmers in other markets.  I can't believe we can't exploit this, too.



Larry W. Loen  -   Senior Linux, Java, and iSeries Performance Analyst
                          Dept HP4, Rochester MN