× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hello Xuan,
In WDSCi we noticed that service entry points would sometimes break and sometimes the program would execute to completion without the debugger 'kicking in'. We were never able to understand why but we lost confidence in service entry points as a viable debug method. In RDp we have noticed similar behavior although now if the job ends while the debugger is still active, we have seen the RDp debugger become unstable and unresponsive. Subsequent attempts to debug will not work. After upgrading to 8.0.0.2 the debugger crashed again. I have not attempted to use it again but next time I do, if I run into the same problems I will attempt to retrieve the QB5SERVER job log for you.
Thanks,
Lorne.

"Xuan Chen" wrote in message news:mailman.41204.1304098670.2702.wdsci-l@xxxxxxxxxxxx...

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.