Re: What makes Java so special?

[snip]

>> >But this is not quite the same as platform dependance (it's just close)...
>> >The application you are writing will not need to run on an AS/400, it will
>> >just need one around to talk to. 
>> >
>> >What you are given is a way to talk to an AS/400 in a native fashion. If
>> >you have an AS/400 and you want to write to it's data queues, you can do
>> >that with Java. But you don't have to. What would be a big mistake is for
>> >IBM to NOT have a way to talk to AS/400s via data queues, as this is the
>> >fastest way to converse with your AS/400. 
>> >
>>   
>> Chris,
>>      This is more than a mere semantic difference.  This means that
>> I cannot transport my Java client to other platforms without re-work.  This
>> utterly defeats the much-touted "portability" gain.  
>
>I'm sorry Buck, but it certainly does NOT mean that. What I am trying to
>point out is that the client is every bit as portable as if it were not
>talking via a data queue. 
>
>The client is 100% Java. It goes where there is a JVM. 

I guess I'm dense.
This is an example... I have 2 database servers: an NT machine in 
engineering, and my AS/400 over in corporate. I have a Java program 
that uses data queues to talk to my AS/400 (for performance reasons),
to get customer information, and I also need the same type of customer
information from my NT box, are you saying I can use the same client
without re-work to talk to NT?  Remember, the holy grail of portability
is that I only have to test and debug once.

>Now, if you write a Java client that open's a URL, that Java client is
>dependant on that URL. It doesn't matter if the URL is an HTML page or a
>bowling ball. 

I think this emphasizes my point...  I can write a Java client and have it
talk to any URL, no matter what platform serves that URL.  I can be sure
of this because the only ways to talk to a URL are standard across all
URL servers, right?  But I can talk to the AS/400 in a NON standard way:
data queues.

>If you think that someday the host you want to talk to won't be an AS/400,
>don't implement data queues on your AS/400. It isn't required. They are
>simply an advantage on the AS/400. You can also connect with the AS/400s
>data base and send and receive messages using MQseries. 

I'm not thinking about moving off the AS/400 so much as talking to
multiple platforms with the same client; AS/400, NT, etc. 

>The point of native data queue access for an AS/400 is this:
>
>Data queues are the preferred method for accessing AS/400s. They are
>implemented on AS/400s as the interface between client applications (both
>on the AS/400 and off) and server applications (both on the AS/400 and
>off)..

This is the trap.
If I "optimise" my Java code so it has acceptable performance on an
AS/400, then I can't have the same tested and debugged app talk to
another platform.  If I write my Java code using JDBC (or whatever
acceptable standard to talk to all the other databases on the planet)
then it doesn't run well on my AS/400.

>If Java clients could not access data queues on the AS/400, they would be
>worthless for Java client development in an AS/400 environment. They would
>require that the server side application, which is the one that is least
>likely to require rewrite, be rewritten to use a slower and perhaps less
>reliable method of communication. What would be the point in that?

If the AS/400 supplied industry-acceptable performance from the
standard interfaces (ODBC, etc.) then this would be a moot question.
As it is, who would risk writing custom code for a limited market?

[snip]

>> Why should a development house write a killer Java app twice?  Once 
>> for all the PC platforms and then again for the AS/400.  Clearly, the
>> PC market is way bigger than the AS/400 market for such software.  
>> Remember, we're not talking about Java for the AS/400, we're talking
>> about Java that runs on my Win95 PC.  If it uses DTAQ's to talk to the
>> AS/400, I'm not going to be able to pick it up and re-use it to talk to my 
>> Engineering division's Unix box unless I re-write the C/S 
>> communications over.  Did I overlook something?
>
>I think you are looking at it backwards, Buck. After all, you care calling
>the client unportable because the Unix box doesn't have data queues. I
>don't think you would be saying, "Gosh, I want to say something to my Unix
>machine, too bad this client talks to data queues!" 
>
>If you don't have the server side for that client running on the Unix box,
>why are you trying to use the client there? That client talks to the other
>half of the application. 
>
>If what you want is to implement AS/400 side applications without data
>queues, go ahead! They will port to Unix..

That's the idea...  Design the client once, test it once, debug it once
and use it against what ever server my company owns.  

I'm going through all this because midrangers have spent untold
hours debating the relative performance merits of Z-ADD vs SUB.
Midrangers who write "standard" portable Java that talks to their
AS/400 will not sit idly by when the performance of the application
is... less than optimal.  They will certainly optimise for speed,
and when that happens, their code will no longer be able to talk to
any other servers.

This may not be important to some people, who will only develop
Java clients to talk exclusively to an AS/400 server, but it's a
show stopper for those developers who want to actually use Java
across multiple platforms (and have acceptable performance.)

Thanks! 
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 MAJORDOMO@midrange.com
|    and specify 'unsubscribe JAVA400-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---