Re: Re[2]: What makes Java so special? -- JAVA400-L

** Reply to note from Buck Calabro <mcalabro@commsoft.net> Wed, 19 Nov 1997 
13:31:00 -0500 
> You're right!  The client talks to data queues, and so does the server,  
> therefore you'd have to re-write the server to match the client's 
>expectations. 
> I understand all that.  The answer is that I DON'T want to talk to data 
>queues; 
> you do...   Here's a quote: 

Well, you don't have to tell me about whether or not I want to write to
a data queue, I know I do! So, I will insure that I have an AS/400 around
to talk to. I'll develop server side apps to run on it. The clients I use
will run on any Java workstation. 

But you were trying to take my opinion and turn it into a development
crisis? If I didn't want an AS/400 involved, I wouldn't use data queues
(and I would probably have a different email address). Crisis solved!

> Again, this is new stuff to me...  I would argue that the answer is no. 
> I say this because any Java book on the market will explain how to 
> talk to a standard URL, but none mention data queues. 

What is a URL? Is it some finite object? A URL is an address. A Universal
Resource Locator. You open this URL. That creates a connection between your
application and some other application/object. You do not know what it is
simply by virtue of opening it. You should know what it is before you open
it to give you some idea of what you are going to do with it. 

So, what is "a standard URL"? What is a standard universal resource? 

> Data queues are an IBM platform specific extension to Java that exist 
> to improve performance (see your quote above.)  Because data queues 
> are not an industry standard, using them means extra work, which makes 
> no sense (see your last sentence above.) 

No, no, no! Data queues are not a Java item! Data queues are an existing
interface on AS/400s. People use them all the time to talk between RPG
programs, CL programs, PC programs, or any mix of the above. I get it! If
you thought that Data Queues were just written for Java as a speed
improvement then you might question why have them!

No, data queues are a fast way of any two programs talking to each other on
an AS/400. The idea being that you might want some form of server
application (say, a program that does file updates) and a bunch of clients
that issue requests to it. The fastest way for them to talk to each other
is via data queues.

So, now you want to replace an AS/400 client. The server is fine but you
want to give a GUI to the client side making the requests. Well, either
your Java app supports data queues or you rewrite the server.

But, if you want to start development on a new project you can make a
choice between data queues and other communication methods. 

Does that help?

> I was going by your repeated references to performance. 
> Remember, I am not experienced in this stuff:  I'm reading and trying 
> to learn as much as possible before jumping in... 

Okay, I did mention that data queues are the fastest method of talking
between two programs. That is because data queues are faster than message
queues. However, nothing that I have said made any mention that JDBC for
the AS/400 was sub standard or anything.

> How will Java talk to, say, a Unix application?  They don't have message 
> queues or data queues... 

Unix applications DO have message queues, via IBM's MQseries. Certainly
there must be other event driven processing functions on Unix boxes! I am
not familiar with them, but I can't imagine this would not be true.

> Actually, I'm intimately familiar with data queues, and use them daily. 
> As for performance, I was using your quotes as a point of reference. 

Then where did your reference to sub standard performance come from? I
never said JDBC was slow, only that data queues are the fastest. How did
that make AS/400 JDBC slower than other JDBC in the industry?

> As far as an alternative to JDBC, if I understand the terminology 
> properly, JDBC lets Java read/write to the server's database.  I think 
> that I can put the data validation in a Java front-end by using JDBC 
> to read (validate against) the /400 database.  Likewise, I think I can 
> use JDBC to write my (now validated) data directly into my /400  
> application's database files.  Add DB2 triggers and RI and I can 
> make my database reasonably solid.  This leans more into the 
> "where should I implement my business rules" area, which needs 
> to be addressed no matter what client we choose to work with. 
>    
> That sounds like an alternative to using data queues to me...   
> How *good* an alternative may well be the topic of another thread!  <grin> 

But I don't see how you compare the two. JDBC is in effect an SQL call to
your data base. Data queues are for inter-process communication. They
serve different purposes. 

What's better, a boat or a car? Doesn't it depend on what you are doing?

I am pretty tired right now, so I'll end here (a few more emails to read).

Have a good night!

> Buck "the greenhorn" 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
+---