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

[Richard Veith]

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>