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

[snip about ways to use data queues for AS/400 applications]

>Then along comes Java, and IBM starts telling us at this phone company that
>this is the wave of the future and we should switch all our programming
>efforts over to that environment. Now, if IBM says we have to scrap
>everything and start over, I think we say, "No." But if IBM says it works
>just fine within the environment we have created and we can do incremental
>implementation, then we look to see if there is an advantage and if so we
>prepare for the move..
 
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...

>> For us, the problem is not "So now we want to replace the AS/400
>> client," but it is "So now we want to have a GUI front end on our
>> software."  With this definition of the problem, would you agree that
>> straight JDBC to the database makes sense, rather than write<!>
>> /400 server code that uses data queues?
>
>Well, that would depend..
>
>Although PC front ends are more dependable than they used to be, and
>although the JVM on the Java workstation is supposed to be wonderful and
>reliable and all that, I am still pretty much a coward at heart. 
>
>I don't like to distribute any processing that my data base might depend on
>for integrity. If I give the client the right to lock a record in my data
>base, I could be screwing myself to a wall. 

Hmmmm...  avoid record locks by serialising the updates!  Back to the
future with batch processing!   Just kidding...  
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.

>Of course, SQL update requests come in from the client and are executed
>(locks and all) at the sever, so I could do that, but that means the client
>didn't know whether or not the data had changed..
>
>Well, I guess there is a little preference there. I'd like to see it on the
>server. But, I can see that I could write the client to issue an SQL
>request that could very well be safe. Part of that would be the ability to
>detect a record change during the update request and I don't know how to do
>that with SQL..

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.

>> 1. One client, multiple server platform: compatible communication method..
>> 2. Upgrading legacy code vs. writing client/server from scratch..
>> 3. Business rule validation: who does this? The client, or the server?
>>     If the client, then how do we protect the database from "other" updates;
>>     i.e. some user who uses Access and ODBC to update our database....
>
>How so very true. Possibly, these considerations are a reason why MQseries
>has been so popular with those who adopted it. This gives you the
>opportunity to impose server based control on the data base with multiple
>platform support. After all, I would feel a little more secure knowing that
>I only granted read authority to those Access using guys and all updates
>were going through integrity checking. 

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.

>I advocate the use of data queues because I have been so succesful with
>them and I don't see any reason to move any host applications to machines
>without data queues. But I certainly understand people developing a new
>application shying away from their use if they don't know what future they
>have. 

Makes sense from that perspective.

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

I'll go off and tinker a bit and let you know how it goes.

Thanks for the discussion, I hope that someone else on the list besides me 
learnt something!

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