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



We had similar problems related to exceeding storage but they occurred at 
runtime (disastrously).
They also relate to large length return variables.
I believe IBM regard the accomodation of many large length return variables as 
a "weaker" area that does not have a simple solution.
It appears to be an issue only in certain situations when there are many 
repeated calls.
As suggested, the solution lies in adopting programming practice that avoids 
using large length variables as return values in favour of returning the value 
as large length parameter which works well no matter how many repetitions occur.

Peter


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Mel Rothman
Sent: Tuesday, February 24, 2004 10:55 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: FW: Have you seen this?


I was able to reproduce this problem on a V5R2 system.

It appears that the mainline is calling subprocedure ZhbGetVar 508 times and 
this is causing the compilation to fail with MCH3216.  This could be either a 
system limitation (possibly a maximum of 16 MB for values returned by 
subprocedures) or a bug (that is, the limitation should not exist).

ZhbGetVar returns a 32767 varying field, which is 32769 bytes including its 
byte 
length.  32769 times 508 comes very close to 16 MB.

You may want to contact IBM service about this problem to see if it can be 
fixed 
or whether it is, in fact, a limitation.

In the meantime, you can get around the problem by writing your own 
subprocedure 
that calls ZhbGetVar and returns the answer in one of its own parameters 
instead 
of as a return value.  Instead of calling ZhgGetVar, you will call your 
subprocedure.  Then, you will assign that value obtained by your subprocedure 
to 
the target variable.

Below is sample code (not a complete program; just relevant pieces).  You would 
need this only in programs that make hundreds of calls to ZhbGetVar and/or 
other 
subprocedures that return a value with a long length.

A variable for the value:
D v32K            s          32767    varying

The subprocedure's prototype
D MyGetVar        pr
D  varname                      50          const varying options(*varsize)
D  varvalue                  32767          varying
D  occurrence                   10i 0       const options(*nopass)

The subprocedure's implementation
P MyGetVar        b
D MyGetVar        pi
D  varname                      50          const varying options(*varsize)
D  varvalue                  32767          varying
D  occurrence                   10i 0       const options(*nopass) 

C                   if        %parms < 3
C                   eval      varvalue = ZhbGetVar(varname:1)
C                   else
C                   eval      varvalue = ZhbGetVar(varname:occurrence)
C                   endif
P MyGetVar        e

Sample use:
C                   callp     mygetvar('custname':v32k)
C                   eval      custname = v32k

Mel Rothman, CGIDEV2 Author
Mel Rothman, Inc.


_______________________________________________
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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.