Too many nested GOSUBS

[Fairlight]

>From inside the gravity well of a singularity, Laura Brody shouted:
> 
>   With this in mind, it sounds like you have a missing "return"
> someplace in your code. If you have a "goto" or "end" rather
> than a "return", the gosub return stack fills up until you max
> it out and generate the error.
> 
> > Could it be that the "internal counter" within fP is not being cleared when
> > one record is finished (written) and the app. goes to get the next record to
> > be posted?
> 
>    Not likely.

I thought I remembered a discussion a while back on the list that discussed
this, so I downloaded all archives from 2004 forward and scanned them for
gosub discussions.  Here's what I found from September 19, 2006:

"
> I guess my question is, since this is a looping process based on a index
> flag (YESNO) where the application checks the file for any transactions
> which have not yet been posted and if it finds any it posts them and
> marks the flag as posted.  Since this app. only ends/exits at either the
> end of the day or if it errors does the limit of 16 nested GOSUBS apply
> to each transaction being posted or until the application has processed
> sufficient transactions to exceed the limit of 16?
" 

The author?  The same Don Coleman having the problem now.  And from what
I'm seeing searching the archives, his question was never answered--I
just looked for one and found none.  That he's dealing with a practically
identically described situation four months later says to me that it was
never resolved for him.

I'll be clear and direct in my question in an attempt to help him get one:

Does the gosub counter get reset at the start of each new record, or is
it continuous throughout the run of *clerk or *report no matter how many
records you switch between?

mark->
-- 
Try our new SPF-0 lotion, SunScream[tm].  Get it while it's hot!