|
Hi Xuan - Thanks for the information. I'm sure that what happened. Since there's only one procedure (the main procedure) in this program, and I'm not encountering the first executable statement again, it was hitting the SEP. That's why it worked when I stopped/restarted the server program. - Michael On 11/2/06, Xuan Chen <xuanchen@xxxxxxxxxx> wrote:
midrange.com
Michael,
In the situation like yours (the server program has already running), it
really depends on your program execution path for if you could use SEP to
invoke a debug session.
When you set a SEP on a program level, it really means a SEP is set on the
first executable line of every procedure in every module of the program.
(So if you want to set SEP on specific module, it is more efficient to
expand to procedure level, and set SEP there).
So if you set your SEP on a running program, and then your execution of
your program actually invoke a procedure call, the SEP should be
encountered, and a debug session should be invoked.
For example, this is the structure of your program:
myProgram --> myModule --> procedure1
--> procedure2
Currently, your procedure1 is on top of the call stack, and waiting for a
IO input from user.
You set a SEP on myProgram in RSE, which underneath, set SEP on first
executable line of procedure1 and procedure2.
User did some input operation, so the input is gather. Depending on the
input, procedure2 is called. Since there is SEP set on first executable
line of procedure2, this SEP will be encountered, and a debug session be
invoked with myProgram under debug.
But if procedure1 continue executing after user input is gathered, since
no
SEP is set in other lines in procedure1, no SEP will be encountered. So
no
debug session will be invoked.
Thanks,
Xuan Chen, Problem Determination Tools for iSeries
(905) 413-3769 T/L 969-3769
xuanchen@xxxxxxxxxx
"Michael Ryan"
<michaelrtr@gmail
.com> To
Sent by: "Websphere Development Studio
wdsci-l-bounces@m Client for iSeries"
idrange.com <wdsci-l@xxxxxxxxxxxx>
cc
11/02/2006 10:41 Subject
AM Re: [WDSCI-L] SEP - Server Program
Please respond to
Websphere
Development
Studio Client for
iSeries
<wdsci-l@midrange
.com>
Thanks for the info Rick. It's not working for me - I must be doing
something wrong.
On 11/2/06, Rick DuVall <R_C_DuVall@xxxxxxxxxx> wrote:
>
> Hi List,
>
> Actually, I don't think that is true, I am almost certain I have
> captured a running batch job with the sep debug functions in Lpex. In
> fact,
> I just did it..
>
> 1. get a list of program objects in the RSE including the one you want
to
> debug.
> 2. strdbgsvr on the iSeries command line (there are other ways to do
this)
> 3. right click chosen program object and choose (Debug (Service Entry
> Point)
> And Set Sep.
> 4. if you are not the actual user running the batch job look in the
> iSeries
> Service Entry Points list at the bottom and Highlight and modify the sep
> to
> have the correct user id.
> 5. wait for the rse to change to debug mode and display the source...
>
> Ymmv - have fun...
>
> Regards,
> Rick DuVall
> Systems Manager
> Dealer's Auto Auction of Okc
> 1028 S. Portland
> Oklahoma City, OK 73108
> (405) 947-2886
> rick@xxxxxxxxxx
> http://www.nothingisreal.com/dfki/no-word
>
>
>
> -----Original Message-----
> From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx]
> On
> Behalf Of AGlauser@xxxxxxxxxxxx
> Sent: Thursday, November 02, 2006 8:56 AM
> To: Websphere Development Studio Client for iSeries
> Subject: Re: [WDSCI-L] SEP - Server Program
>
> Michael Ryan wrote on 02/11/2006 09:38:26 AM:
>
> > Is there a way I can set a Service Entry Point and debug a currently
> running
> > server program? If so, how do I find the right job?
>
> I'm pretty sure that SEPs only work if you set them before a job is
> started.
> I think you have to use the 'old fashioned' way of connecting to a job
to
> debug it if it is already running. I'm not sure of the exact process
for
> doing this - sorry I can't be of more help.
>
> Adam
>
> --
> This is the Websphere Development Studio Client for iSeries (WDSCI-L)
> mailing list
> To post a message email: WDSCI-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
> or email: WDSCI-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/wdsci-l.
>
--
This is the Websphere Development Studio Client for iSeries (WDSCI-L)
mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.
--
This is the Websphere Development Studio Client for iSeries (WDSCI-L)
mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.
As an Amazon Associate we earn from qualifying purchases.
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.
