Re: What makes Java so special?

>What is the part you can't grasp here? 
>        1. What kind of host interface has no bearing on the 
>           portability of the client.
>        2. The platform the client is running on has no bearing
>           what kind of host can be contacted.
>
>If you create two different host interfaces, you will create two different
>client access methods. If you write these into your client, then the client
>can go anywhere and talk to both hosts.

Right.  I don't get #1.  
#2 seems self-evident (even to me! <ear-grin-ear>)

I *thought* you were telling me that if I write data queue
code in the client that I could use it to talk to NT, too.
Did I mis-read you?  Sorry if I did.  I thought that ODBC/JDBC 
was the "server independent" interface.  

I wasn't slamming Java-DTAQ code for being non-server-portable;
I realise that *any* client using DTAQ code would be 
non-server-portable.

I mention Java specifically here in the context of 
including data queue code because it is Java that has 
the promise of allowing a fresh start, without the
baggage of vendor-specific C++ classes, etc.

When we're sooooooo close to being able to write truly,
completely portable code (client runs on any platform, 
talks to any server platform) it seems such a shame to
limit the Java client to a single server by using server-
specific interfaces (like data queues) when "generic"
alternatives (JDBC) already exist.  

>> I only wonder how many people are actually running Client-Server code
>> where the client and server communicate via data queues.   I've got
>> a huge number of "old style" applications, and a mere handful of
>> client-server ones...
>
>Perhaps you conceptualize client-server as something it isn't. For instance,
>our application uses a server application for processing all printed
>documents which are printed by events (because the people who are keying
>those events might not feel like waiting for some other task to occur). So,
>when an even occurs, the event program issues a notice in a data queue. 
>
>We have a server application that monitors and processes entries in that
>queue. This is client-server processing although all the apps are green
>screen host based programs. If we decided to rewrite a couple of these apps
>as PC based and we wanted them to be able to issue event notification it is
>likely we would choose to have them place notification in the data queues,
>since there really isn't any reason to rewrite the print server side. 
>
>I think this is more common that seems on the surface.

Oh, we do the same thing for, say, credit checking.
Pretty easy to do, especially with data queues, but:

>> We have literally tons of legacy code that were written before
>> the client server model became fashionable.  Even now, there are
>> thousands of AS/400 shops that are using the older model to write
>> applications.  These folks *are* starting from scratch when it comes
>> to GUI/Client Server code (which is what I meant...)
>
>No they aren't, Buck. None of them is in a position where they are looking
>to just throw everything away and start fresh. 
>
>Rather, there may be many of them want to change a client front end, but are
>interested in keeping the current reliability as well as continue to use
>existing batch processors, report printers, etc.
>
>That's why whatever tool they choose will need to be able to deal with the
>components they still have.

That's what I was trying to say.  We can't chuck all the 
legacy code and start anew.  

The "But..." is that we have very little Client-Server 
code in those legacy apps.  Because of this, virtually 
*all* the GUI efforts are starting from scratch.  We
can't increment up to GUI client replacing Green Screen
client, because the Green Screen stuff is not written
as Client-Server.

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