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

Tue Jul 3 10:03:30 PDT 2018

Bruce,

Checked my filePro plus 4.0 new Release features,

PFTOKSIZE-nnnn Note that this is 1 digit less 9999. Same as in release 4.5

I just checked the PDF of the "New Features of 4.8" and, I hate to say this, it shows PFFORMTOKSIZE=nnn.

So, this begs the question is the value a 3,45 or 6  digit number?  Anecdotally, I think you are correct the value can be a 6 digit number.  But can it be as high 999,999?

Only someone from FP tech can answer that question.

Richard

PS: I will send you a copy of the 4.8 PDF off list.

> -----Original Message-----
> From: Filepro-list [mailto:filepro-list-
> bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Bruce Easton via
> Filepro-list
> Sent: Tuesday, July 3, 2018 11:55 AM
> To: 'filepro-list at lists.celestial.com' <filepro-list at lists.celestial.com>
> Subject: Re: limits on called program's variable and/or array space?
> 
> If that's what was printed there, Richard, I suspect it's a typo, and it should have
> read 999999.  I don't ever remember reading about such a limit in any of the
> printed manuals, but I may have missed it. I do believe I've had to use values well
> above 100,000 to get past issues before.
> 
> Note that in filepro 5.6 and later the default is 100000 for PFAUTOTOKSIZE,
> PFTOKSIZE, and PFFORMTOKSIZE. (From online manual at
> fptech.com.)
> 
> Bruce
> 
> 
> On 7/3/18 11:31 AM, Richard Kreiss wrote:
> >
> >
> > For the PFFORMTOKSIZE-nnnnn  - default is 15,000 bytes PFTOKSIZE =
> > nnnnn - default is 20,000 bytes
> >
> > PFAUTOTOKSIZE - nnnnn - default is 15,00 bytes
> >
> > Referring to filePro Developers reference fourth edition
> >
> > It appears that the maximum value would be 99999.  I have used values higher
> than this, for debugging purposes, but don’t know how effective in adding
> additional memory space these high values were.  I tended to increase the
> values by 25,000 until I reached a value that didn't give me an error.
> >
> > It may be useful to have a blank call table. This might release memory being
> used by the original called table which stays in memory until the next call is
> made.
> >
> > Call "foobar"; Call "Blank"
> >
> >
> > Richard Kreiss
> > GCC Consulting
> >
> >
> >
> >
> >
> > , I'm not sure if there that these can be
> >> set to.  I have used values of 900,000 frequently.
> >>
> >> On 7/3/18 8:34 AM, Richard Veith via Filepro-list wrote:
> >>> Thanks to those who replied.  Before responding to some of the
> >>> individual
> >> questions, there is a little more I could add to the story.   First, it takes about
> 6
> >> hrs of processing before the abort, so testing various things takes time.  If we
> >> use smaller sets of data, it does not abort.   And second, there is also a Sort
> >> involved for the calling program, maintained in the program's "out"
> >> file.  It is a 3- field sort with a total of 41 chars per record, for all 22 million
> records.
> >>> Here are some of the questions from the people who responded:
> >>>
> >>>>    it would help to know if you get an error of sort and/or if
> >>>> anything is logged in event logs
> >>> When the abort happens, Windows puts up a message "dreport.exe has
> >> stopped working".  And the FilePro screen behind it shows the number
> >> of records selected, and the number for "generating output".  The
> >> latter number is never the same but always seems to be within 20,000
> >> or 30,000 of the previous abort points (and sometimes a smaller gap
> >> of just 5 or 6 records).  If there is some "event log" we can look at
> >> (either Windows or FilePro), please point us in the right direction.
> >>>> Have you tried  a much higher PFFORMTOKSIZE and PFTOKSIZE?
> >>> How high can we go?
> >>>
> >>>> Are you using an auto table?
> >>> No.
> >>>
> >>>> Have you considered adding this as a sub routine rather the a called
> program?
> >>> Yes, but there are one or two other points in our entire procedure
> >>> where the
> >> called program's functionality is needed, and the intent was to use
> >> the same called program in the various places.  Also wanted to keep
> >> the variables separate between the calling program and the called program.
> >>>>    If you are updating records and in these updates an index key is
> >>>> changed,
> >> make sure you are locking your lookups.
> >>> This is a standalone PC doing only one thing at a time, and nobody
> >>> else is doing
> >> any updating.  Both the calling program and the called program do
> >> update records but nothing that would change an index.  And the two
> >> indexes involved are demand indexes.
> >>>> Have you tried running the process using both dreport and rreport?
> >>> Have not tried rreport.  Anything in particular to look for?
> >>>
> >>> I will let you all know how this gets resolved, but as I said, it
> >>> takes 6 hours or
> >> so before hitting the abort, so it is a slow testing process.  And I
> >> will be away for the 4th and the rest of the week.
> >>> Thanks again for any insights.
> >>> Rich
> >>>
> >>> -----Original Message-----
> >>> From: Richard Kreiss [mailto:rkreiss at verizon.net]
> >>> Sent: Monday, July 02, 2018 6:43 PM
> >>> To: Richard Veith <richard.veith at smrresearch.com>
> >>> Subject: Re: limits on called program's variable and/or array space?
> >>>
> >>> Have you considered adding this as a sub routine rather the a called
> program?
> >>>
> >>> Richard
> >>> Sent from my iPhone
> >>>
> >>>> On Jul 2, 2018, at 5:58 PM, Richard Veith via Filepro-list
> >>>> <filepro-
> >> list at lists.celestial.com> 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/20
> >>>> 18
> >>>> 0
> >>>> 702/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
> >>> _______________________________________________
> >>> Filepro-list mailing list
> >>> Filepro-list at lists.celestial.com
> >>> Subscribe/Unsubscribe/Subscription Changes
> >>> http://mailman.celestial.com/mailman/listinfo/filepro-list
> >>>
> >>
> >>
> >> ---
> >> This email has been checked for viruses by Avast antivirus software.
> >> https://www.avast.com/antivirus
> >>
> >> _______________________________________________
> >> Filepro-list mailing list
> >> Filepro-list at lists.celestial.com
> >> Subscribe/Unsubscribe/Subscription Changes
> >> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> 
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list