Re: RDi 9.0.1 How to debug UDTF with SEP?

On 1/28/2014 1:45 PM, MichaelQuigley@xxxxxxxxxx wrote:

It's really pretty simple. STRDBG doesn't terminate the debug session
whereas RDi (by default) will end it when the program completes. (As
pointed out, this can be overridden with the 'Terminate debug session when
program completes' setting.)

In the default (where the debug session is terminated), the communication
can't be quick enough while RDi shuts down the debugging, etc. to be ready
to start another debug session when the SEP is hit again. i.e., The
program is called too quickly the second time. There are a whole slew of
things that happen when the debug session ends. If a job is already being
serviced, you can't start servicing it again (STRSRVJOB). The developers
had to choose to either terminate the debug session or leave it active.
They made the good choice of what fits for most cases. But they also were
wise enough and kind enough to give us the control to change that behavior
when we need it. When you uncheck the 'Terminate debug....' setting, the
session remains active so the program will break the next time it is
called.

STRDBG (green screen) you always have to terminate the servicing of the
job. (i.e., You have to enter the ENDSRVJOB command yourself.)

Way too wordy. I've got to get better at it, but I hope that clarifies
the problem.

Not too wordy; a very nice way to think about it. The thought hadn't
occurred to me that 'Terminate debug session' was a sort of blocking
operation. It's a bit ironic, actually, as we've seen that the client
can detect the 'server busy' condition, but the server apparently cannot
detect / buffer the 'client busy' state.

I'm not criticising the developers for something that's probably pretty
rare; I'm very happy to have the option to configure the behaviour the
way I want it!
--buck