RE: Optimizing an automatic storage error

["Peter Connell" <Peter.Connell@xxxxxxxxxxxxxxxxxxxx>]

Jon,
Thanks. The code here relates to a process is essentially a wrapper for an xml 
parsing process.

The application has an xml string from which it must extract a value by passing 
the string (up to 65K) and the element name (up to 500 bytes) to a service pgm 
procedure. The element name may be passed either as a literal or a variable 
that has previously been assigned from a literal. The service procedure in 
essence hides the code that resolves the value (up to 65K) associated with the 
element name which it must return to the application. 

The application was originally written without knowledge of what the best 
practice might be for declaring the interface to the service procedure. Calls 
to this procedure may be coded in several hundred places within an application. 
Redesigning the application (using an event based approach for instance) is now 
too large a task.

Initially the element value was returned to the application as a return value 
of 65K varying. Thus, any application variable declared as character could be 
directly assigned to the procedure eg. var = procA(..). Where an application 
has a few hundred such procedure calls it was found to sometimes throw the 
automatic storage overflow exception. This appeared to occur most often 
immediately after a runtime exception was encountered (handled or not). It 
seemed that handling (or not handling) an exception was enough to cause 
automatic storage to blow which appears to leave the activation in a most 
precarious state and cause the most peculiar errors to arise on subsequent 
requests to the application.

The problem was resolved by eliminating the use of a return value altogether by 
running a utility that replaced all assignments var=procA(..) with 2 lines 
callP procB(..); var = rtnVar; 
procB simply makes a call to procA and exports the value as a data item rtnVar 
that the calling application imports.


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.

Cheers, Peter

  
-----Original Message-----
From: Jon Paris [mailto:Jon.Paris@xxxxxxxxxxxxxx]
Sent: Wednesday, July 02, 2003 3:41 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Optimizing an automatic storage error


 >> Since one of the procedure parms if declared as a 65K const varying I'm
wondering if this is what is causing the optimizer to generate code that
gives us the runtime error again.

Almost certainly, yes.  Although I would have expected the run-time to clear
up and re-use such allocations anyway.  Have you raised this as an APAR with
IBM?

Anyway - since you are passing varying length fields, one option would be to
add the keyword OPTIONS(*VARSIZE) which will allow a varying field of < 65K
to be passed as-is with no copying.  A copy will still be made of any
"ordinary" (i.e. non-varying) character field, but at least the varying
fields will not require it.

I have to wonder if you _really_ need to bring back this large a piece of
data.  The fact that you are using CONST implies that smaller fields will be
used.  %Len in the called procedure can be used to determine the current
size of the field, but that only helps if the original parm was non-varying
or the varying field had its length set to max (%Len(varfld) =
%Size(Varfield) - 2 ) before the call.  But because the compiler space fills
(sadly) fields under these circumstances, there might be significant
overhead in doing this.

Without knowing more about what you are doing it is difficult to suggest
alternatives.  For example I assume that you are returning a value in this
field since it appears to be replacing a return value, but are you ever
passing fixed length fields or only varying?

Jon Paris
Partner400
www.Partner400.com


_______________________________________________
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