Too many nested GOSUBS

[Don Coleman]

> -----Original Message-----
> From: Laura Brody [mailto:laura at hvcomputer.com]
> Sent: Wednesday, December 20, 2006 1:02 PM
> To: Don Coleman
> Cc: 'filePro Mailing List'
> Subject: Re: Too many nested GOSUBS
> 
> Quoting Don Coleman <dcoleman at dgcreact.com>:
> 
> > Merry Christmas to all:
> >
> > I have a posting routine which posts data from FILE A to FILE B based on
> a
> > transmitted (posted)(YESNO) flag.  Data is received into FILE A from an
> > alien application via a socket connection.  No problems here.  However,
> I
> > have a *clerk process which posts the data from FILE A to FILE B based
> on
> > the transmitted flag.  Once again, no problem here.  My problem is
> during
> > the posting process one of four subroutines (GOSUBS) occurs based on the
> > type of transaction.  With this one particular transaction code the
> system
> > does not generally create a new record in FILE B but does update certain
> > fields in FILE B.  When complete, the app. goes back (returns) to find
> the
> > next record to be transmitted via the index flag.
> >
> > Occasionally this subroutine will error with a "too many nested gosubs"
> > message and need to be restarted.  Within this primary gosub routine
> there
> > are a maximum of 5 additional gosub routines that are condition
> dependent.
> > Most of the transactions would not meet any of those conditions.  My
> > documentation states there is a maximum of 16 nested gosub routines
> > permitted (fP v5.0.13) (Windows 2000 server & clients).  My question is
> why
> > do I occasionally get this error message?
> 
>   Correction: in v5.0 and later, gosubs could be nested up to
> 64 levels deep.
> 
>   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.
> 
> --
> Laura Brody
> +------------- Hudson Valley Computer Associates, Inc ----------+
> | PO Box 859 120 Sixth Street    http://www.hvcomputer.com      |
> | Verplanck, NY 10596-0859       Voice mail: (914) 739-5004     |
> +------ PC repair locally, filePro programming globally --------+

Laura:

Your suggestion probably holds the answer.  I had checked for this
previously and the only way I could see this happening would be for the
alien application to not have sent a transaction that actually creates the
new record in FILE B (via a goto command) before I update that record with
this particular type of transaction (via a gosub).  Probably poor technique
on my part initially by mixing these.  The programmer of the alien app. says
this should not happen but a user says it does happen.  I should now be able
to resolve it.
Thanks for the suggestion.  Merry Christmas.