RE: What makes Java so special -- JAVA400-L

>> You and I might think this way, but I don't think that IBM necessarily
>> does: witness ILE.  To use it, you need to re-write your apps...
>
>Um, yes. I am not sure your point? Obviously, if your application was written
>without taking into account advantages of different possible program
>structures (I refer to the borderline object orientation of ILE) then it
>would need to be rewritten to take advantage of those structures. I'm not
>sure how that could be different. 
>
>If I don't write my code OO, then the only thing that will make it OO is
>rewriting it that way, right? Or was there something else about ILE that can
>not be used unless a rewrite is done?

Sorry, I didn't get that across very well.
ILE exists to enable OO designs to be implemented without the performance
penalty of OPM dynamic binding.
Because of this performance penalty, there aren't many OPM apps that
extensively use dynamically bound program calls.  (No flames please,
I know there are a FEW; I'm painting the big picture here...)
Because of this, the app can't simply be converted: it must be re-written.
More than that, it must be re-designed.

I have continued to make the mistake of posting messages with the
inherent assumptions that my shop's conditions are universal.
For that, I apologise.  Let me set the stage for a moment.  My shop is 
doing a huge volume of maintenance tasks on RPGIII code.  We aren't
starting from ground zero, writing new apps from scratch.  We have
to incrementally improve existing code.  

This means that it will be very difficult for us to implement ILE, because
mixing OPM and ILE is bad mojo.  In addition, a single ILE program 
(without CALLB) is worse than useless.  ILE is designed to allow us 
to write little code bits and re-use them over and over (sound familar?)
To convert a monolithic OPM program to ILE without a re-design/re-write
is a waste of time.  IBM knows this, and still positioned ILE as the
new platform we should be using on the AS/400, despite the fact that
it is a break with the traditional "incremental improvement" model
they've used for years.

They could be doing the same thing with Java.

Sure, it's cool, and it's a wonderful paradigm to work within, but is it
a technology that will easily allow me to incrementally improve my
existing legacy code?  I think this is really what will decide if Java
flies on the AS/400 or not.  ILE has not been the resounding success
that, say, the introduction of OPNQRYF was.  

>> Hmmmm...  avoid record locks by serialising the updates!  Back to the
>> future with batch processing!   Just kidding...  
>
>Don't kid! It's quite true. Of course, it wasn't batch processing really, it
>is more event driven processing since the server app sits there awaiting the
>data base request. 

In all seriousness, batch went away because of the time delays inherent
in such an environment.  If we serialise all the updates, then we have the old
batch bottleneck.  If we allow multiple servers (many pgms reading off the DTAQ)
then we're no longer serial.

>It isn't just record locking you avoid, but also problems with data
>integrity. After all, if you allow every client under the sun to access your
>data base, you will get hammered. Even if it's just because someone is using
>an old version. 

God forbid!  Rather than open that can of worms, we'll be going to a
data warehouse type structure: extract the files the end-user needs
and place them in a library they have access to.

>> As for distributing the DB processing, well, this is a design issue, but
>> I think we can agree that the idea of a central DB server is to enhance
>> DB integrity. I'm a bit puzzled by the bit about record locking though...
>> There's no need for the client to ever lock a record if you don't what it to.
>
>The client would lock the record when preparing for update. Change fields,
>and then send update. Now, what if the client crashed during record lock? A
>good Win95 lockup could sit there undetected by the server. I think with the
>quality of desktop OS common in the marketplace this is an question of when.

Ummmm... the client *could* lock the record, but it doesn't *have* to.
Same issue exists with green-screen.

>> Locks and all?  I don't understand this bit...
>> As for detecting an interim record change, this is a problem that is
>> independent of the way you access the DB.  You'd have the exact
>> situation if the server were updating the DB after getting a DQ entry,
>> or a green-screen were updating the record after the user pressed 
>> the UPDATE key.
>
>No, what I meant was a way to detect them in the midst of a change request
>without the client being involved. In other words, send a request to the
>server that says, change this record to read AMOUNT = 100 unless AMOUNT <> 0.
>I don't do much in SQL but that does seem like somethig you can do. I just
>want the determination made at the server.

That's exactly how it works.  The client "sends" the SQL statement to the
server, who processes it there.  The client doesn't get each record sent
to it, where it makes the decision to update or not.  The data stays on
the server at all times; the SQL request is to manipulate it there, not at
the client.

>> Again, of the potentially millions of Java programmers-to-be are going to
>> be able to write to MQseries?  What general Java books describe it's
>> use?  The whole point of my gibberings was to note that if I customise
>> my Java client application to suit one platform then it won't be usable
>> on others.
>
>And my point in bringing up MQseries is that it is available on all
>platforms. 400s, 390s, NT, Unix boxes, etc. Now, there might be some places
>where IBM hasn't ported MQseries, but they are probably pretty obscure.

Oh, sure, but IBM sells all sorts of things that Unix folk will never buy.
It's one more "See: you can't use Java with IBM unless you pay the bucks
to get their proprietary program to talk to their proprietary systems."  I
sure get tired of hearing that from the Unixen...

>> Thanks for the discussion, I hope that someone else on the list besides me 
>> learnt something!
>
>Well, if I count, there are at least two of us!

It does indeed!

Buck Calabro
Commsoft

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "JAVA400-L@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
+---