Re: Optimizing an automatic storage error -- RPG400-L

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