Re: Setting Service Entry Points (SEP)

Thanks for the explanation, Don. That is exactly the point. SEP is not
a global breakpoint, otherwise, it will block all the jobs that running
the application.

Just to want to point it out here that "runner" user profile does not need
to be the same as the "setter" user profile. You could modify the SEP
(right click, and choose Modify) so that its User id (which means runner
user id) to point to a different user profile. But the "setter" profile
needs to have *USE authority to "runner"'s profile.

Thanks,

Xuan Chen, Problem Determination Tools for iSeries
(905) 413-3769 T/L 313-3769
xuanchen@xxxxxxxxxx





"dnitke" <dnitke@xxxxxxxxxxxxxxx>
Sent by: wdsci-l-bounces@xxxxxxxxxxxx
02/21/2008 10:02 AM
Please respond to
Websphere Development Studio Client for iSeries <wdsci-l@xxxxxxxxxxxx>


To
<wdsci-l@xxxxxxxxxxxx>
cc

Subject
[WDSCI-L] Setting Service Entry Points (SEP)






Hey All,

I have been reading all the feedback on the problems with SEP and was very
interested because they too have been driving me crazy. I ran some tests
and because of a reference in one of the emails tried this out and now SEP
works fine for me. The big thing with SEP is the object user and SEP
setter have to be the same user profile, at first this didnt make sense
but during my testing it became apparent. I have a eclipse plugin I wrote
for my company which is Java of course using a stored procedure on the
iSeries that is written in RPGIV. It has settiings in the Eclipse
preferences as well as there is a web application which both use a set
signon for convenience of getting the proper library list. When I usually
use WDSCi its with a programmer signon which of course isnt the same as
the plugin so it never caught but then I would run it interactively using
STE a tool we have for testing Stored Procedures and that was with my
programmer profile what a surpise it suddenly worked.
Once I discovered this I used the plugin profile and tested the eclipse
plugin and hey it works now but here is the funny part and probably why
the profiles running the object and setting the SEP have to be the same.
If you dont think it out and use the production (for the lack of a better
word) profile the SEP will bottle neck all users with that signon and keep
opening new debug isntances in WDSCi. Im sure thats why SEP is setup to be
same so you dont bottle neck all the users by SEPing the object. A good
plan would be to copy that profile and use it for testing on both the
Application and WDSCi signon setting of the SEP barring any authority
issues. Anyway I know this is way to much writing but remember:

SEP requires same profiles for Setting the SEP and running the process
using the object.

Thanks and hope this helps any other poor souls who didnt realize that
Don N.