Hi Lorne,
Just to let you know we are working with Kenneth to look more into the
problem he encountered.
I am wondering if you can give me some more information about this
debugger problem. Did it start to occur when you move to a new release of
RDp (or moving from RDi to RDp, etc), or moving to a new OS400, or after
applying some system PTFs to your IBM i system?
If possible, could you try the RDp debugger again to see if you run into
the same problem.
If yes, please try to find if there is any job name QB5SERVER running
under your user profile. If yes, collect the job log. If no, try to see
if any spool file with the same name, and collect the contents of that
spool file.
Thanks,
Xuan Chen, Problem Determination Tools for IBM i
(905) 413-3769 T/L 313-3769
xuanchen@xxxxxxxxxx
"Lorne Sturgeoff" <lorne.sturgeoff@xxxxxxxxxxx>
Sent by: wdsci-l-bounces@xxxxxxxxxxxx
28/04/2011 01:12 PM
Please respond to
Rational Developer for IBM i / Websphere Development Studio Client for
System i & iSeries <wdsci-l@xxxxxxxxxxxx>
To
wdsci-l@xxxxxxxxxxxx
cc
Subject
Re: [WDSCI-L] RDP V8.0 Debug loses connection intermittently
We have had similar problems here with the RDP debugger to the point where
nobody here trusts it anymore. We generally use the System Debug Manager
graphical debugger which is much more stable and provides most of the
functionality of the RDP debugger without the problems.
Cheers,
Lorne.
"Tarr, Kenneth" wrote in message
news:mailman.40456.1303827138.2702.wdsci-l@xxxxxxxxxxxx...
I've had this situation happen on rare occasion in the past, but now that
I
am on RDP V8.0 (8.0.0.2) and was using it extensively yesterday to debug
an
application and experienced this issue several times, I wanted to post
this
to the group. It will hopefully shed some light on either a problem known
to others in the community, or isolate it as a local issue on our end. Or
the likely issue I am doing something wrong.
Here are the scenarios.
1) When you attempt to connect to a job that is running, most of the time
it successfully connects and stops the program on the line it is
executing.
There are other times however the debugger returns a message something
similar to "connection with the debug server was lost". (My theory is
that,
if the actual program being debugged is running it will connect, but if
another program in the stack is running that was called by the program
being
debugged, it can't connect. I theorize this because whenever I have the
job
on hold and try to connect with debug, it can't on the same premise that
the
program isn't moving forward -- see #3 below.)
2) When in debug, if I veer away from the debug application to another
Windows application (like a Client Access session), on occasion it comes
back with a "continue waiting for debug server to respond" message. At
that
point I click OK, but never can resume my debugging. After awhile, RDP
just
gets hung up, so my only recourse is to abruptly end the application,
which
releases the debugged job and allows it to continue running (it is no
longer
at an EVTW state). This happens about 10% or less of the time, but
yesterday it was happening a lot more.
3) When you attempt to connect to a job that was placed on hold, in the
past the predecessor WDSC was able to release that job and in turn stop it
at the next debuggable line. Now when I try doing this in RDP, I get a
message (something like "error trying to connect" message). The job
remains
on hold fortunately, but the only way to get the debugger to connect is to
release the job.
Any ideas? Thanks in advance for your input.
This e-mail and attachment(s) may contain information that is privileged,
confidential, and/or exempt from disclosure under applicable law. If the
reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution, or copy of this message is
strictly prohibited. If received in error, please notify the sender
immediately and delete/destroy the message and any copies thereof.
Although
Associated Banc-Corp and/or its affiliates (collectively "Associated")
attempt to prevent the passage of viruses via e-mail and attachments
thereto, Associated does not guarantee that either are virus-free, and
accepts no liability for any damage sustained as a result of any such
viruses. Any federal tax advice contained in this communication (including
any attachments) is not intended or written to be used or referred to in
the
promoting, marketing, or recommending of any entity, investment plan or
agreement, nor is such advice intended or written to be used, and cannot
be
used, by a taxpayer for the purpose of avoiding penalties under the
Internal
Revenue Tax Code
midrange.com
