Re: What makes Java so special? -- JAVA400-L

** Reply to note from Buck Calabro <mcalabro@commsoft.net> Mon, 24 Nov 1997 
09:54:54 -0500

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

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

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. 

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

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

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

> Do you have sample Java code that talks to data queues (that you'd like
> to share, of course! <g>)?  Not having partaken myself, I'm sure I could
> benefit from seeing an example...

No, unfortunately, I don't! I am working in ILE these days. But, I'll beg the
chance to play at the office and see what they will let me do.

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

> Buck Calabro
 

Chris Rehm
Mr.AS400@ibm.net

How often can you afford to be unexpectedly out of business?
Get an AS/400.
+---
| 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
+---