× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Check out this article I wrote for iSeriesNetwork Club Tech Tips titled
"Return SQL Result Set from RPG to Java" which shows how to consume an SQL
result set created in RPG from Java.

http://iseriesnetwork.com/artarchive/index.cfm?fuseaction=ListArticlesByAuth
or&ID=984

HTH, 
Aaron Bartell


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Steve Richter
Sent: Thursday, December 29, 2005 8:43 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: User Space extent

On 12/28/05, albartell <albartell@xxxxxxxxx> wrote:
> >better for whom?  It is easier for the programmer to work with 
> >complex and
> large data structures when they are a single addressable object rather 
> than a collection of segments.
>
> Let me better explain where I am coming from.
>
> It has been my experience that too much data/functionality is shoved 
> into an xml document when it should in fact be separated out.  For 
> example let's say an interface to a CRM package like salesforce.com 
> was being built and you wanted the data on your iSeries to be in sync 
> with your salesforce.com data (i.e. customer info, order history, 
> etc). In this scenario you could choose to create any number of xml 
> documents to send/receive documents between the two machines (say 
> software packages) and here-in lies the initially difficult part of 
> authoring xml web services - how much data do I put in my xml 
> transaction? When a prospect turns into a customer through a cold call 
> you would want that information sent from the CRM app to your iSeries app,
but what does that xml document contain?
>
> One could put every single piece of information about that 
> prospect/customer into a single xml document/transaction (name, 
> addresses, contacts, interests, etc), but it has been my experience 
> that this creates problems when validating information on the 
> receiving end (i.e. address three has an invalid zip code but the rest 
> were ok).  A better way to do it would be to model it similar to 
> regular RPG program calls (emphasis on similar). To do this you would
create multiple xml documents/transactions (i.e.
> createCustomer, addAddress, addContact, removeCustomer, removeAddress, 
> removeContact, etc) with each having a set of expected/documented 
> responses (i.e. SUCCESS, DUPLICATE FOUND, INVALID ZIP CODE, NOT FOUND, 
> etc) and then program around those specifications.
>
> >more the reason to build the document as a string because appending 
> >to a
> string is much faster than writing to a stream file.
>
> I am not sure that I agree with having 16MB + strings being passed around.
> How well is that going to scale in the end? What happens when you need 
> to start passing that XML around to different RPG sub 
> procedures/programs? Are you going to start passing pointers? Are you 
> going to always make sure to pass by reference so the xml is not 
> doubled/tripled/etc?  There are just a lot of bad things that can 
> happen when that much memory is allocated to any one particular job.  
> Sure every programmer loves to operate in memory without having to 
> worry about consuming too many resources, but I just don't think that is a
reality.

true.  Limiting the use of large string objects to ones based on extendable
user spaces in qtemp would get around some of the problems you describe.
The new memory models of Java and .NET are the answer to dealing with large
objects in programs.

>
> Also note that once you get into the web service world you will want a 
> "paper trail" of events that occurred (i.e. the raw xml as it was sent 
> in and what your service sent out) and you will not get that unless 
> you move the xml to more permanent storage (i.e. IFS files). Sure you 
> may lose a little bit of processing time because you aren't operating 
> in memory, but the benefits far outweigh in this case.
>
> Great conversation!  Let's see if we can come to a "best practices" by 
> the end of this thread.  If you could state exactly what you are 
> trying to do we could come up with a great solution, but without that I am
just fishin'
> around for what you are trying to accomplish:-) (restated: could you 
> give us your business scenario?)

for the business programming I am doing now I need the as400 to provide much
more than large strings!  for example, I am converting an rpg program that
reads from 3 sql tables to get the same data from a stored procedure that
returns 3 result sets.  I would like to make this change with a minimal of
change to the code of the rpg program. 
I am using sql cli to access the result sets and copy the result set rows to
multiple occurance RPG data structures.  With the data structures filled, I
am not sure how to mimic the existing code of the RPG program I am
converting which uses 3 SQL cursors.  Just an example of how cumbersome
things can be when the OS only provides a few ways of ding things.

-Steve

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.