STACK error

[Mahesh]

I'm trying to call a para within the program recursively and I get this
error. Any ideas on how to overcome this? Any jbase level settings to
be changed??

** Error [ STACK_FULL ] **
Internal GOSUB stack FULL , Line 88 , Source XXXXXXX
Trap from an error message, error message name = STACK_FULL
Source changed to .........................

[Simon Verona]

Sounds like lots of calls/gosubs without a return..

Can you post a code sample?

Simon

[Mahesh]

yes...it is a recursive call... the stack grows till 28th iteration and
fails...but the requirements is atleast for 50 iterations....any luck
for me??

[Daniel Klein]

Why don't you post the code as Simon requested?

What jBASE version and platform are you on?

On 4.1 you should be able to recurse 512 levels (tested on Windows). This
code demonstrates (excuse the GOTO, it was the quickest/easiest/clearest way
to illustrate):

cnt = 0
1 GOSUB 100
100 cnt++
CRT cnt
GOTO 1

When this code runs I get :

1
2
3
.
.
.
509
510
511
512
** Error [ STACK_FULL ] **
Internal GOSUB stack FULL , Line 2 , Source gosubtest.b

Trap from an error message, error message name = STACK_FULL

Source changed to C:\home\bp\gosubtest.b
0002 1 GOSUB 100
jBASE debugger->

If you get the same results then the logical conclusion is (as Simon Verona
mentioned) your code is making lots of GOSUBs without a RETURN.

Dan

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of
Mahesh

[Mahesh]

Got it....the main program was was rectified to avoid unnecessary
recursive iteration....now works fine...

And Daniel was right...it goes upto 512 levels....

[Simon Verona]

I'm just wondering if it's only me that has this problem.

We have a standard "INPUT" subroutine which uses a GET statement to do an
input with a timeout eg :

GET Char,1 FROM SYSTEM(18) WAITING TimeOut ELSE Char=''

TimeOut is read from a file and is always the same.

We get calls from customers from time to time (2 or 3 a month) where they
report the system "locking up".

We identifiy this at jBASE suddenly ignoring the "TimeOut" clause and
slipping straight through the GET command causing all the users processes to
"spin" and processor % to rise to 100%.

We suspect this, because in our menus, we have a "screensaver" which after
10 loops through the GET commands starts to draw the word "DMS" letter by
letter at random points on the screen at a reasonably slow pace(stupid idea
I know but it does it nonetheless!). For uses that are at the menus, this
races along filling the screen suggesting the the timeout is instantaneous.

Curiously, the problem seems to last about 15-20 minutes whereby all users
report that the system is unusable, and then clears itself!

This is on jBASE 3.4.x (various versions at different sites) on both Windows
2000 and Windows 2003 servers.

Anybody any thoughts as to the cause? Or solution?

Thanks
Simon

[Mahesh]

Hi Simon

Has it got something to do with the "termchar"? May be you can try
forcing the termintating char to a CR or something else.

cheers
mahesh

[Lucian]

Simon,

GET Char,1 FROM SYSTEM(18) WAITING TimeOut ELSE Char=''

requires a file handle created by OPENSER or OPENSEQ.
Yes, it works if you put SYSTEM(18) but I don't think that a number is
equivalent to a file handle.
If, in some particular instance, GET requires more than a number, GET
will fail instantly and will fall through the ELSE branch.
Instead of GET I would use IN.
The equivalent of your GET statement is:

IN Char FOR TimeOut THEN Char=CHAR(Char) ELSE Char=''

Lucian

[Simon Verona]

Lucian,

I'll give the "IN" command a try in place of the "GET" and see what
happens... It will probably take a few months to know that it's worked
though! (The problem is not reproduceable at will and it will take a month
or two to roll out to all customers).

Thanks
Simon

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of

[Charlie Noah]

Simon,

Why not use Jbase' CommandNext subroutine and get all its benefits?
It has a timeout as well. Additionally, it can identify function,
cursor and edit keys.

Regards,
Charlie Noah
Inland Truck Parts

[Simon Verona]

Interesting...

I don't need the features of commandnext, though they look interesting!
I'm guessing though that commandnext makes use of the databasic "IN" command
in any case?

Regards

[Clif Bristol]

CommandNext? I haven't seen any documentation on that. Is it a new 4.1 feature?

[Simon Verona]

Looking at the knowledgebase it looks like a 3.0 feature..

I suspect that it's simply a databasic subroutine.

Regards

[Charlie Noah]

CommandNext is on 3.4.x, and I can't picture them taking it out of
4.x. See

http://www.jbase.com/knowledgebase/manuals/3.0/30manpages/man/sup12_KEYBOARD_INDEPENDENCE.htm

for docs on it. I doubt it uses IN - it's probably a C routine using
curses or ncurses. I have a Windows version of Jbase at home, and it
seems to work well there as well. If your terminfo is set up correctly,
it is very reliable in identifying multi-character keystrokes, relieving
us of the drudgery of parsing and handling them.

Hey, it's already there, and it's free. Why not put it to work for you?

Charlie

[Lucian]

Simon,

Be aware that CommandNext is using the un-named common, therefore you
may have a potential conflict with other aplications.

Lucian

[Simon Verona]

Lucian,

Glad you told me that! I use an unnamed common in my application.

Regards
Simon

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of
Lucian
Sent: 22 June 2006 18:53
To: jBASE
Subject: Re: GET Waiting not waiting....

[Jim Idle]

As likely as not this is one of:

An error condition is raised on the Wait and is not detected, causing it to
spin trying to timeout again;
A Windows bug;
One of the above but caused because someone did a jkill/LOGOFF/something
similar on the process or it's parent.

Jim

[Jim Idle]

No it is a bit more sophisticated than that and was written to provided
keyboard independence after we found that lots of applications had something
similar embedded and many of the implementations were big performance
problems. This is mostly C code driven from the terminfo definition and
caters for this like ESC vs ESC [ ...

If you have a need for this kind of thing, you should definitely use it over
your own BASIC routines. Even for fairly simple things that don't need the
full monty.

Jim

[Simon Verona]

Jim

I suspect that it's something in the OS layer possibly, for when it does
happen it doesn't just affect a single process, it occurs for every user on
the machine.

Presuming that it is something at the OS level, then I presume that
switching to "IN" (or anything else that uses a timeout) will suffer the
same problem?

It is of course possible that the catalyst is due to a process closing
abnormally - this normally happens by users closing a telnet session or
rebooting a client PC without logging out of the application first.

What I'm interested in is that nobody else seems to have seen the problem,
which suggests that it's something unique to our environment. As it
happens at random across all of our customer base I doubt it's down to an
individual configuration issue on a single server.

Overall, I'm after some inspiration for tracking down and either working
round or fixing the issue - it is very annoying for our customers when it
does happen as it pretty much a "system down" as the application is
unusable!!

Regards
Simon

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of
Jim Idle
Sent: 20 June 2006 13:18
To: jB...@googlegroups.com
Subject: Re: GET Waiting not waiting....

[Charlie Noah]

Jim,

I agree with your statements about CommandNext. It works very well for us
and takes the load of translating keystrokes off. Whoever wrote it did a
fantastic job.

Maybe you could tell me how to keep ^d from waiting for a second keystroke,
no matter wht changes I make to .jedrc? After the second keystroke, it
properly translates whatever I define ^d to be in .jedrc, but it always waits
and passes back both keystrokes. I know it's trying to do the vi line delete
thing, but there's got to be a way to trick it.

Regards,
Charlie Noah
Inland Truck Parts

[Jim Idle]

From your description I would strongly suspect the network, starting at:

1) The network card driver;
2) the network card;
3) Something on the router/switch that it is plugged in to;
4) and so on.

These things can be very difficult to trace. I would start by making sure
the drivers are bang up to date, then trying a different network card.

Jim

[Jim Idle]

It is likely to be something in the terminfo definition of your terminal.
Post an infocmp and I'll take a look.

Jim

PS: Greg wrote the CommandNext stuff by the way, in the main for our own
utilities such as jsh and jed, but if it is good then it must have been my
idea ;-)

[Charlie Noah]

Jim,

Term type is xterm (telnet from RH Linux), AIX/Jbase infocmp is:

# Reconstructed via infocmp from file: /usr/share/lib/terminfo/x/xterm
xterm|xterm terminal emulator,
am, km, msgr, xenl,
cols#80, it#8, lines#25,
acsc=lqkxjmwuvtn, bel=^G, bold=\E[1m, civis=\E[?25l,
clear=\E[H\E[2J, cnorm=\E[?25h, cr=\r,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=\b,
cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
cvvis=\E[?25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
dl1=\E[M, ed=\E[J, el=\E[K, home=\E[H, ht=\t, hts=\EH,
ind=\n, kCAN=\t, kbs=\b, kcbt=f1md, kcub1=\E[D,
kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kdch1=\E[3~,
kend=\E[F, kent=\E(B, kext=\E(0, kf1=\EOP,
kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf2=\EOQ,
kf3=\EOR, kf4=\EOS, kf5=\E[15~, kf6=\E[17~,
kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, khome=\E[H,
kich1=\E[2~, knp=\E[6~, kpp=\E[5~, krfr=\r, mc4=\E[4i,
mc5=\E[5i, nel=\n, pln=f1, rc=\E8, rev=\E[7m,
rf=/usr/share/lib/tabset/vt100, ri=\EM, rmcup=\E[?7h,
rmkx=\E>, rmp=lqkxjmwuvtn, rmso=\E[m, rmul=\E[m$<2>,
rs1=\E>\E[1;3;4;5;6l\E[?7h\E[m\E[r\E[2J\E[H, sc=\E7,
sgr0=\E[m\E(B, smcup=\E[?7h\E[?1l\E(B\E=, smkx=\E=,
smso=\E[7m, smul=\E[4m$<2>, tbc=\E[3g,

Thanks,
Charlie

[T.Turkington]

Jim, I don't know if you caught the statement here that "As it happens at

random across all of our customer base I doubt it's down to an individual

configuration issue on a single server", but that would make me think it's
something else.

Tom

[T.Turkington]

I find it curious that this uses unnamed common. We also use unnamed common
which means this subroutine won't work for us. Was there some reason why
unnamed common was necessary?

Tom

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of

Simon Verona
Sent: Thursday, June 22, 2006 11:12 AM
To: jB...@googlegroups.com
Subject: RE: GET Waiting not waiting....

[Simon Verona]

I would concur with Tom, as it occurs randomly across our whole user base,
it is unlikely to be hardware or network related - the make/model of the
servers in question is varied, as is the network card and network
infrastructure.

I would go more with something within Windows.

At the moment, I'm changing the Input routine from a "GET" command (which
I'm reliably informed can't work even though it does for 99.999% of the
time!) to an "IN" command to see if that solves the problem.

Regards
Simon

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of

T.Turkington
Sent: 26 June 2006 15:54
To: jB...@googlegroups.com
Subject: RE: GET Waiting not waiting....

Jim, I don't know if you caught the statement here that "As it happens at
random across all of our customer base I doubt it's down to an individual
configuration issue on a single server", but that would make me think it's
something else.

Tom

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of
Jim Idle
Sent: Monday, June 26, 2006 5:44 AM
To: jB...@googlegroups.com
Subject: Re: GET Waiting not waiting....

Fromyour description I would strongly suspect the network, starting at:

[Jim Idle]

I didn't see that phrase actually, I read it as being that it was one single
server! In that case I would switch to the comandnext stuff and see if it
goes away - it would be easy enough to switch I think. It could also be
something in the telnet server I suppose.

However, do you (Simon) ship the users with some pre-configured equipment
such as the network switch and so on?

Jim

[Simon Verona]

Jim

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of
Jim Idle
Sent: 27 June 2006 08:51
To: jB...@googlegroups.com
Subject: Re: GET Waiting not waiting....

I didn't see that phrase actually, I read it as being that it was one single
server! In that case I would switch to the comandnext stuff and see if it
goes away - it would be easy enough to switch I think. It could also be
something in the telnet server I suppose.

[ Simon Verona] I'll try the "IN" command first, as I think commandnext will
mess up our use of "Common".

However, do you (Simon) ship the users with some pre-configured equipment
such as the network switch and so on?

[ Simon Verona] We normally supply the server which our application runs -
but we've used various brands and models over the years to the extent that
they are all different! We don't normally configure the clients network,
so I would expect a variety of brands and types of configuration for our
users.