-nb Issue.

[karikalanr]

Dear all,

I had an issue by getting this error "nb exceeded. Automatically increasing from <old value> to <new value>. (5407)" - (This warning is causing in during runtime and development as well)

According to my business logic I can not reduce/use recursive calls to minimize nested blocks. Could you please any one tell me how to fix this issue?

Thanks,
Karikalan R

 

[karikalanr]

Just adding as a note, I have tried to fix this by increasing -nb startup parameter value in Openedge architect development environment project properties. But still in runtime I am getting the same error. Specifically, If I am closing that problematic screen its causes this issue. Please help.

 

[TomBascom]

Technically recursion can always be converted to repetition. So you could alter your algorithm.

But it is more likely that your recursive procedure is simply misbehaving. The usual problem is that the terminal condition isn't being recognized and thus the procedure is infinitely calling itself. Like this:

/* recursive.p */

define input parameter i as integer no-undo.

if i >= 0 then
  run recursive.p ( input i + 1 ).
 else
  return.

(Yes, it's a dumb example...)

 

[tamhas]

So, if you have considered the algorithm and it seems to meet your business needs and you can avoid getting the message in your development argument by increasing the -nb parameter ... which is what it seems you are saying ... why don't you just increase the parameter in the production environment and be done with it. This message *can* mean runaway recursion, which obviously is something that needs to be fixed, but it can also mean that -nb is simply set too low. It is rather like -L. Blowing it consistently means you have a locking problem, but in some business environments there is a valid need for a high number and in those contexts it is simply the right thing to set it accordingly.

 

[TomBascom]

Hmmmm... it's bit unclear to me if increasing -nb works or not. We're told that it was tried in development (and not actually told if that worked) and then we're told that it is still a problem at "runtime" (presumably meaning "production") but not if it was actually tried in production (or runtime).

If increasing it does work then I agree that it might be the right thing to do.

However, even if it does work it might not be such a great idea if the needed depth is related to something that is highly variable and hard to control -- like the number of items in an order or some such thing. In cases like that it is usually better to go with an iterative approach.

 

[karikalanr]

Hi Tom,

Thanks for your suggestions, actually it was a cause because of unconditional iterations. As the code was so lengthy it took some more time to trace it out.

Many thanks,
Karikalan