JBASE Internal GOSUB stack FULL

[cape...@gmail.com]

Hello all ,
We are running a test migration creating some AZ.ACCOUNT , some
contracts generate the following error during upload:
** Error [ STACK_FULL ] **
Internal GOSUB stack FULL , Line 165 , Source AZ.BUILD.CYCLE.DATES
How can this problem be resolved , is there a way to increase the size
of this "STACK" ? if so How ?
Thanks for your assistance

System information :
jdiag
jdiag - jBASE diagnostic '$Revision: 1.15 $'

System Information
==================

System : AIX iklwadrp 3.5 00C6A4A24C00
OS Release : 5.3.0.0
UNIX User : iklmig (uid 223, euid 223)
Tty name : /dev/pts/9
Time : Tue Dec 8 12:51:07 2009

Environment
===========

JBCPORTNO : Not Set
JBCRELEASEDIR : '/usr/jbc5'
JBCGLOBALDIR : '/usr/jbc5'
JBCDATADIR : '../bnk.data'
HOME : '/data/mig/bnk/bnk.run'
JEDIFILENAME_MD : '/data/mig/bnk/bnk.run/VOC'
JEDIFILENAME_SYSTEM : '/usr/jbc5/src/SYSTEM'
RELEASE Information : Major 5.0 , Minor 19 , Patch 0354
(Change 83368)
Spooler dir (JBCSPOOLERDIR) : '/usr/jbc5/jspooler'
JBCEMULATE : 'prime'
WARNING: Cannot access Executable path '/data/mig/bnk/bnk.run/
oracle_2.0.10.7/bin', error 2
WARNING: Cannot access Executable path '/usr/lpp/mmfs/bin', error 2
WARNING: Cannot access Executable path '/oracle10/product/10.2/crs/
bin', error 2
WARNING: Cannot access Library path '/data/mig/bnk/bnk.run/
oracle_2.0.10.7', error 2
Object path (JBCOBJECTLIST) : '/data/mig/bnk/bnk.run/globuspatchlib:/
data/mig/bnk/bnk.run/locallib:/data/mig/bnk/bnk.run/lib:/data/mig/bnk/
bnk.run/glo
buslib:/data/mig/bnk/bnk.run/oradriver/lib:/data/mig/bnk/bnk.run/
GR0800005lib:/data/mig/bnk/bnk.run/GR0800004lib:/data/mig/bnk/bnk.run/
radlib'
WARNING: Cannot access Object path '/data/mig/bnk/bnk.run/
globuspatchlib', error 2
WARNING: Cannot access Object path '/data/mig/bnk/bnk.run/radlib',
error 2
jBASE Compiler Run-time : '/usr/jbc5/config/system.properties'
Program dir (JBCDEV_BIN) : '/data/mig/bnk/bnk.run/localbin'
Subroutine dir (JBCDEV_LIB) : '/data/mig/bnk/bnk.run/locallib'
Max open files : 65534

[Jim Idle]

Tony,

Thanks for including all the information you could. It makes posts much easier to deal with.

The GOSUB stack is just what it says, in that when at runtime a program executes the GOSUB statement, it must create a small record of where it is GOSUBing from in order that when it hits a RETURN statement it knows where to RETURN to. It is presized at something like 2000 entries and so generally if you see this, it is a programming error (usually caused by foolishly using GOTO statements).

You can test if the stack size has changed by just running this program:
I=0
5000 I++
CRT I
GOSUB 5000

Which will stop with the error below when the stack is filled. If there is little or no change then it is likely that the GOSUB in question is the subject of some condition that is not correctly working on your migrated version. Given the name of the source code in question, I suspect that this is some kind of recursive subroutine that is called to manipulate some array or dynamic array. The stack size could have changed and you are unlucky to hit it, but it is more likely that the check for terminating the recursion is not terminating because of some data problem, algorithmic problem or similar.

I think that there is a hack to increase the stack size, but generally this is only needed for unusually long recursions and hence it isn't a good idea to increase it without knowing why you are increasing it.

http://markmail.org/message/3c3kpdp3lansed6u

Remember to use the search facilities.

Jim

> --
> Please read the posting guidelines at:
> http://groups.google.com/group/jBASE/web/Posting%20Guidelines
>
> IMPORTANT: Type T24: at the start of the subject line for questions
> specific to Globus/T24
>
> To post, send email to jB...@googlegroups.com
> To unsubscribe, send email to jBASE-un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/jBASE?hl=en

[TONY CAPE]

Thanks Jim for clear explanation

We have contacted temenos about this issues ,

[Phil Knight]

This problem occurs in a core program so Temenos Helpdesk should deal
with it. Temenos customers shouldn't have to resort to a jBase forum
for advice on problems like this because of poor support.

Phil

> >http://groups.google.com/group/jBASE?hl=en- Hide quoted text -
>
> - Show quoted text -

[Jim Idle]

> -----Original Message-----
> From: jb...@googlegroups.com [mailto:jb...@googlegroups.com] On Behalf
> Of Phil Knight
> Sent: Friday, December 11, 2009 1:42 AM
> To: jBASE
> Subject: Re: JBASE Internal GOSUB stack FULL
>
> This problem occurs in a core program so Temenos Helpdesk should deal
> with it.

Yes, and that was my advice.

> Temenos customers shouldn't have to resort to a jBase forum
> for advice on problems like this because of poor support.

However, in some cases you will be able to help the help desk people resolve your issue if you can supply more lucid information than otherwise you might due to lack of knowledge. Generally my advice is that you contact TEMENOS help desk and if it seems like there is information lacking in your report, then it seems perfectly reasonable to ask for some advice here that you can then pass on.

Jim