limits on called program's variable and/or array space?

[Jose Lerebours]

AFAIK, arrays, unless global, are cleared each time "end" is 
encountered, you would need clear only if processing in a loop.

I frankly do not know how fp allocates memory to an array that has been 
"defined" and "before" it is populated but, given that it uses a "fixed" 
declaration, I would venture say that memory is allocated for said variable.

I normally rely on -t in lieu of global environment variables; just to 
make sure that if a cat changes config file, things like this do not break.

Also, it would help to know if you get an error of sort and/or if 
anything is logged in event logs that may reveal root cause.

I have heard of cases where processes fail time and again at the very 
same point, often due to bad record/index or need to rebuild chain (not 
even sure if this a factor these days).

I personally have had experience where using a variable (not defined any 
where else) causes processing to crash and simply changing the variable 
name form aa to ab fixes the problem.

Have you tried running the process using both dreport and rreport?  If 
so, same results?  Have you determined if it always stops at the same 
record?  Rebuild your indexes.

If you are updating records and in these updates an index key is 
changed, make sure you are locking your lookups; in fact, always lock 
before updating.

One always think that the reason is the added code, but it could be 
something that has been sitting there waiting to blow up - hence, time 
bomb!  What if you reverse the code out, does it work?



On 07/02/2018 05:58 PM, Richard Veith via Filepro-list wrote:
> We have a database of about 20 million records, where each record is just over 2200 characters.  As part of our processing, we run an output process table on the entire database, and this process calls another output process table.  The calling process is about 1500 lines, and the called process is about 300 lines.
>
> Up until a recent change, this all worked fine.  The change was to add a subroutine to the called process, and this subroutine included a few more variables (declared with sizes, as were the previous variables) as well as two arrays.  One of the arrays is 700 elements consisting of 4 digit integers, and the other array is 700 elements consisting of 20 character strings.  The arrays are not mapped to any existing fields.
>
> The puzzling thing is that if the called program, with the new subroutine, is run by itself as a standalone program against the entire database, it works fine.  But when being called from within the calling program, it aborts about  85% of the way through the database.
>
> Since the calling program/called program arrangement worked fine before the new subroutine was added, and the called program works fine on its own, our suspicion is that there is some limit on the memory allocated for called program variables and arrays, and we exceeded that.  Or those arrays are not being treated as dummy variables and instead, as each record is processed, a new version of each array is created and all prior ones are still hanging around.
>
> Do you think it is a memory issue?  Is there a way to specify more memory for the called program (we have PFFORMTOKSIZE set to 200000 on the assumption it might be relevant since the documentation for CALL says "the called processing table uses the token area reserved for printing a form from Inquire, Update, Add")?  Is there a way to remove the arrays as processing finishes one record and moves to the next record? (We are using "clear" on the arrays but that probably does not change the space already allocated.)    Are there other things we should be looking at?
>
> Our environment is FilePro 5.7.00D9 on a standalone Windows 7 PC with a 64-bit OS and 16 GB of RAM.
>
> Thanks for any suggestions.
>
> Rich
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20180702/d7549a78/attachment.html>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list