RE: Optimizing an automatic storage error

Hans, (and Jon)
Thankyou for your input.
Your explanation again confirms your response when I originally raised the 
issue on this list concerning exceeding automatic storage. It is clear that 
there are difficulties that one can create when dealing with 65K strings via a 
procedure call that may not necessarily manifest during the development phase.

Since the issue regarding the use of a return value was resolved by not using a 
return value then our current plan is to proceed by not optimizing the 
applications concerned since that is what exposes the weakness here.

Previous testing has indeed revealed that the storage problem did not appear 
when the value was returned via an output parameter even if declared as 65K 
varying. The present use of an exported 65K data item meant that there was less 
risk in writing a utility that modified all source code with confidence. We 
will in future always use an output parameter.

I shall be trying the effect of passing the 65K input parameter without CONST 
etc to see if that can be optimized without problem.

The 65K limit has obviously scalabilty problems. This has been addressed by 
passing a document reference on input in such cases instead of an xml string 
since the subsequent parsing process will accept either a byte stream or a file 
path.

Cheers, Peter    





 

-----Original Message-----
From: Hans Boldt [mailto:boldt@xxxxxxxxxx]
Sent: Thursday, July 03, 2003 2:47 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Optimizing an automatic storage error


Jon Paris wrote:
>  >> However, procB still passes the xml string as input via a 65K const
> varying which may now have become the culprit when we optimize the
> application. Your advice on the best coding practice for declaring the
> procedure interface would be appreciated.
> 
> I'm not sure there is a "best" practice for this kind of scenario <grin>.
> If indeed the allocation of temporary storage is the problem, I'd be going
> after IBM to fix it - or at least explain it!  Hopefully now that they are
> back from celebrating Canada Day, Hans or Barbara will be able to comment on
> this.
> 
> In part the various work-arounds depend on the requirements for the input
> parm.  If only fixed length fields are passed, I would tend to use
> Options(*VarSize) without the varying or const keywords and either pass in
> the length of the field using %Size or use descriptors to determine it.  If
> varying fields are required, then you could use the technique that you have
> applied to the return value on the input side as well (i.e. eval parm =
> input) but it is not terribly efficient.  There are various other options I
> can think of but they are pretty obscure.
> 
> I think IBM need to tell you _why_ it doesn't work as is and then armed with
> that knowledge you can craft a solution (or wait for the PTF!)

Well, I (for one) am back from the Canadadaday holiday. It was a 
very nice day in TO yesterday, which probably explained why Thomson 
Park was so crowded. It took 25 minutes just to get into the full 
overflow parking lot. We gave up standing in line on hot pavement at 
one of the way too few food vendors and ended up just eating the 
snacks we brought. Later, it took about 15 minutes to leave the 
parking lot. Oh well, at least Tammy had fun grabbing at the grass 
and seeing the animals at the petting zoo.

Regarding the storage taken up by the return value of procedure 
calls, what happens is that the translator generates pessimistic 
code and allocates a piece of storage for the return value on each 
and every procedure call. If you return a 65535A value from a 
procedure, you can easily run out of storage if you call that 
procedure a lot. I know, that really puts a damper on using 
procedures to implement string operations.

First, if indeed you need to handle up to 64K, you probably also run 
the risk of having to handle even bigger chunks, in which case, the 
64K limit is no good to you.

Second, defining a return value of 65535A VARYING is inefficient 
since the return copyies 65537 bytes of data, even if your string is 
only a few characters long, which is might possibly have some 
performance implications. And so it's important to understand the 
absolute maximum size of data you need to deal with to minimize the 
size of the return value.

If you are reasonably sure that you'll never exceed that limit,  but 
you still need to go up to 64K, you're probably better off returning 
the result in a reference parameter. Alternatively, allocate storage 
for a return value dynamically and return a pointer instead of a 64K 
long string.

That said, I've already sent a note off to someone in Rochester to 
see if there are things we can do in the RPG compiler to improve the 
situation with respect to procedure calls. But don't expect a PTF. 
If anything happens, it would be in a new release.

Cheers! Hans


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

This correspondence is for the named person's use only.  It may contain 
confidential or legally privileged information, or both. No confidentiality or 
privilege is waived or lost by any mistransmission. If you receive this 
correspondence in error, please immediately delete it from your system and 
notify the sender. You must not disclose, copy or rely on any part of this 
correspondence if you are not the intended recipient. Any views expressed in 
this message are those of the individual sender, except where the sender 
expressly, and with authority, states them to be the views of Baycorp 
Advantage.If you need assistance, please contact Baycorp Advantage on either :- 
        Australia 133124 or New Zealand +64 9 356 5800