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



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.

Cheers, Peter





-----Original Message-----
From: Hans Boldt [mailto:boldt@ca.ibm.com]
Sent: Wednesday, September 18, 2002 6:27 AM
To: rpg400-l@midrange.com
Subject: Re: rpgile strings > 65535


Bob Cozzi wrote:
> Couldn't you just use a data structure?
>
> D myDS            DS               Based(pWhatever)
> D Big1                       65535A
> D Big2                       65535A
>
> Then use %SCAN and %SUBST on the MYDS "field".

First, that particular data structure is not valid since it is
bigger that 65535 bytes long.  Sure, you could use %SCAN to locate
the x'00' character, which would then give you an index, which you
would then add to the address of the field to get the location of
the null.  But incrementing a pointer in a DOW loop is a bit simpler
(IMO), and it works for C strings longer than 65535 characters.

Cheers!  Hans



_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.