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



Perhaps I should have rechecked the issue before mentioning.
I just checked.
Calling the same program compiled in late 2002 on V5R1M0 still causes
MCH4429 (Automatic storage overflow)
But recompiling the same source today on V5R4M0 is fine.
It seems that I can't make it happen now no matter what I do to that
program.

My apologies, looks like the compiler is cool with this now.




-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, 27 November 2008 2:01 p.m.
To: RPG programming on the AS400 / iSeries
Subject: Re: Calling C from RPG: what am I doing wrong?

Hello,

This was a few years back and only to do with return values, large
varchars as parameters were fine. I think the storage overflow problem

only arose when large return values(65K) were assigned to many
different variables ( the context was in mapping the elements of an
xml document to rpg variables ).

There can be, at most 16776704 bytes (approx 16mb) of automatic storage.

Sounds like you were doing something that caused it to exceed the
number of bytes of automatic storage.

Do you remember if it was MCH4429 or MCH4216 or something else?

If you want to see what I mean, try something like this:

H DFTACTGRP(*NO)

D proc1 pr 10i 0

c callp proc1
c eval *inlr = *on

P proc1 b
D proc1 pi 10i 0
D foo s 65535a dim(200)
D foo2 s 65535a dim(56)
c return 0
P E

On my system, the above program won't even compile.. the compiler logs
errors and ends :) But, if I change the value of the 2nd dim to 55, it

compiles and runs without error, because the size of the automatic
storage it's using is less than 16776704

By contrast, try this:

H DFTACTGRP(*NO)

D proc1 pr 10i 0
D proc2 pr 65535a

c callp proc1
c eval *inlr = *on

P proc1 b
D proc1 pi 10i 0
D foo s 65535a dim(254)
c eval foo(1) = proc2()
c return 0
P E

P proc2 b
D proc2 pi 65535a
c return *all'x'
P E

Even though my DIM() is 254 (less than 255!) the compile fails it has
exceeded automatic storage limits. that's because the return value from
proc2() requires an additional 65535 of automatic storage... indeed, I
think it uses it not once, but more than once, since I have to cut my
DIM back to 252 for this version to work...


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.