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