Re: SQL vs "native" I/O performance -- JAVA400-L




>By 'middleware' I take it that you mean non-Java middleware?

>I agree with you that the road to 'industrial strength' AS/400 Java
>applications goes via industry-standard middleware.

>However, I also feel the AS/400 still has somewhere to go before it can prove
>itself as a serious contender in the distributed systems arena. For example,
>the current implementation of MQSeries is behind the mainstream, CORBA
>support is still a twinkle in IONA's eyes (I never thought I'd pray for a
>company's financial health to improve...), even WebSphere is lagging,  and to
>add insult to injury IBM won't even explain why they have no plans to
>port/develop Component Broker to/for the AS/400. It's a great platform
>alright, but defending it in certain circles is a struggle.

To be honest, I'll accept any middleware that will get a message intact from one
machine to another.  I'm far more interested in content than the delivery
mechanism.  Since I don't necessarily equate "distributed" to mean "object", I'm
perfectly happy to have a simple messaging service.  I've developed fairly
sophisticated client/sever applications using nothing more complicated than
APPC.  Where do you see MQSeries as seriously deficient?


>About your options, maybe the Java/other HLL choice has to do with how much
>re-write you are willing to undertake. For new development, Java should make
>more sense. If leverage of current investment  is paramount, keep current
>code.

That's a good point.  In fact, my entire approach is to slowly move to Java.
First, separate the user interface from the business logic using a client/server
approach.  Next, move the clients to the workstation using Java.  Third,
encapsulate the existing HLL business logic in Java object wrappers.  Finally,
rewrite the busines logic in Java.  This work can be separated by functional
area, and then staged.  Your RPG programmers will still have jobs supporting the
servers until they are all converted to Java, at which point they (the
programmers) will have either learned Java or found other positions.  There is
no wholesale disruption of your IS staff as there would be in the csae of
switching entirely to a new platform and language.  At the risk of repeating
myself, the single most irreplaceable asset any company has is the knowledge of
its business rules, which is to some extent (often a great extent) in the heads
of its legacy programming staff.


>As for the native I/O(meaning DDM?)/SQL choice, there's the nature of
>the access (which you have already been taking Paul Comte up on - you've got
>guts!), but there's also the nature of the database. Some databases of my
>acquaintance wouldn't know 'normalisation' if it ran them over. DDM might be
>more suitable for them.

It's not so much "taking Paul Conte on" as simply relating my past experience.
I was the manager of architecture at SSA, and I saw first-hand what a
non-optimized SQL approach could due to a true transaction-based system (as is
reflected concretely in SSA's current stock price).  A blind move to SQL simply
to support "platform independence" is a gross misuse of the AS/400's capability,
in my opinion.

However, your point on normalization is very well taken.  If the database isn't
structured to support SQL (how many times have we seen arrays of fields in
records?) then SQL is extremely handicapped.


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---