RE: Communicating between java & rpg?

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: java400-l-admin@midrange.com
> [mailto:java400-l-admin@midrange.com]On Behalf Of Tanveer, Mohammad
> Sent: Thursday, August 30, 2001 4:22 PM
> To: 'java400-l@midrange.com'
> Subject: RE: Communicating between java & rpg?
>
>
> My orginal question was
>
> Data Ques/MQ Series vs Stored Procedures not
> HLL vs SQL
>
> Yes I use HLL for stored procedures thats why they are so fast, To me data
> que is good for passing only one limited message.  But not for
> large amount
> of data.

So the discussion is data queues vs. result sets.  How would you do the
following:

1. Retrieve a nested bill of materials - each parent item can have one or
more children, and each child can itself have one or more children.

2. After modifying the bill in several places, update it.

I do it this way:

1. Send a request to the bill of materials server
2. Read the records
3. Process the data
4. Send an update request with all the modified records
5. Read the result code

Let's try something different.  How would you do the following:

1. Read a set of customer orders, which consist of data in four different
files (order header, order detail, shipping history and notes).

2. After modifying the orders, update them.

I do it this way:

1. Send a request to the order server
2. Read the records
3. Process the data
4. Send an update request with all the modified records
5. Read the result code


> How do you bring 1000 records back to your java program?  I hope you don't
> loop your code to do that or try to retrieve an unlimitted amount of data
> using one parameter :-) (You have to call AS/400 1000 times).

What's wrong with calling a program 1000 times?  The AS/400 is optimized to
allow fast program-to-program calls.  What do you think a program stack is?
Every database I/O you do calls a program - in fact, it calls several
programs.  When you call your stored procedure and it in turn calls the
database I/O programs, you're calling a program over and over again.

Even so, how often do you return 1000 records for a single transaction?
Result sets are good for queries, not for transactions.  There's a huge
difference.


> Comparing to
> one call using Stored Procedure. (performance). If you do how do you parse
> the retrieved data from data que?  2200 bytes? Just wondering whats in it.
> Stored procedure returns you the data in much simpler and better way.
> Building one SQL statement for result set is much more cleaner and easy to
> maintain comparing to data structure and reading data in a loop, parsing
> data and, going back and forth to AS/400 to read more data.

Stored procedures are fine for queries.  Unfortunately, very few
applications are query-only.  I deal with actual application development,
which means databases get updated.  With a stored procedure, as far as I
know you have to do one stored procedure call for each record to be updated.
I can send my entire transaction at once.  Mine will be faster, I think.


> Just wondering why you mentioned bidrectional. Sored Procedure are not
> bidirectional?.  Actually they are much better you know what you
> are sending
> and what you are receiving?

Answer my previous question on retrieving and updating a bill of materials
and a multi-level customer order.  For simple queries and single-record
updates, the SQL paradigm is sufficient (barely sufficient for an UPDATE),
but not for anything of any non-trivial level of complexity.  In fact, for
an update, do you do an UPDATE ... WHERE EQUALS, or an UPDATE ... WHERE
CURRENT?  If it's WHERE EQUALS, I can guarantee my solution will outperform
yours, whereas if it's update WHERE CURRENT, how do you keep your cursor
position between calls?

Or have you even implemented an update using a stored procedure?


> Again I am trying to see a difference b/w Data Ques, MQSeries and Stored
> Procedures.  Not HLL or SQL

No, I think you're trying to defend stored procedures vs. data queues.  Me,
I admit that stored procedures may be very good for simple queries and even
simple updates, but that data queues are much better for more sophisticated
transaction requirements.  I've stated why.  I'd be interested to see your
response.

Also, my servers are simpler, because they do not need to parse SQL
statements or build result sets; they can pass data using simple data
structures.  Personally, I like my servers as lean as possible, because
they're usually the bottleneck, while in my client I can encapsulate any
complexity inside of a class.