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



Peter Connell wrote:
Hans,
I am investigating a problem where a developer has a program that can blow the limit for automatic storage (MCH4429), which is very strange. Code like the following has been used for a generic string extraction procedure.

GetXml          PR         65535    varying
  In_Xml                   65535    Const varying
  In_Tag                     500    Const varying

D #SPOACTSTR      S           5500
D SPFNAM          s             40

.... retrieve value of #SPOACTSTR to be passed to generic string extraction procedure
C                   Eval      SPFNAM=GetXML(#SPOACTStr:'first_name')

Am I correct in thinking that the following might be occurring:

The compiler needs to populate SPFNAM from a string returned by the extraction procedure.
Because the returned generic string has been defined as VARYING then the complier generates code to place the result in an intermediate variable that has a fixed length of 65535.
Consequently, every time the compiler encounters a statement like the above, it will reserve another 64K of automatic storage.

It can be demonstrated that a simple program that contains the above statement repeated 200 times can cause storage to blow.
However, the weird thing is that this occurs (MCH4429) only when the program encounters some other statement that raises an exception (any exception). If you code the very first statement in the above program as one that you know will cause a %subst exception, for instance, then MCH4429 will be raised.

Unfortunately, when MCH4429 occurs when the program is run on the HTTP server, then the job invocation stack stays out of wack so that all subsequent requests that attempt to call the program always result in a recursive call error.
While it is possible to fix the code that caused the initial exception, I would like to avoid the storage problem.
My suggestion would be to have the procedure use a character pointer and a parameter for length similar to the IBM procedure for QtmhGetEnv.

I am open to suggestions for a best practice solution.
Peter:  I think you've got a good handle on what's happening.
Actually, I believe it's not the compiler that's allocating all the
storage needed, but the translator.  Same effect, though.

Unfortunately, you've found the biggest weak point of varying length
character type.  Although in most places, RPG just handles the real
varying length of the string, on procedure return, the entire length
of the character value is copied back, including the garbage bytes
beyond the real end of the string.  Basically, in returning varying
length character strings from procedures, you need to strike some
balance in the length of the string.  You need to determine some
practical limit to the size returned by your procedures.

Cheers!  Hans





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.