Re: Re[2]: What makes Java so special?

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

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

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. 

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. 

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

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 you are writing a new application, and you want to plan for the possible
future of not implementing on the AS/400, us MQseries. 

If you have a working AS/400 server side application that requires
input/output via data queue, voila! You have a solution. Build your new
client and move it to whatever front end machine you want. 

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

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