Re: Stored procedures

David

When you compile, you have the option to replace the program. That will put a copy into library QRPLOBJ, if it's being referenced by any job. So the debug server might have picked up such a reference, or whatever.

I would not get too upset - it's a feature to keep your jobs running when you replace things.

I find I always have to be careful to check for debug and running jobs - had that happen at a customer today with some custom code - a long-running job was sending messages that looked like my code from 2 days ago - had to clear things out of QRPLOBJ and bounce this job.

And do check the user, as another post said - SEPs are not triggered for all users, just one - if it's an HTTP CGI server job you want to debug, you have to change the SEP to point at user QTMHHTP1, probably.

HTH
Vern

On 12/2/2010 8:43 AM, David FOXWELL wrote:

I think it was one of "those" problems with sep. I had already tried refreshing the sep. Then, I recompiled the program and forgot about the debugger. When I called the procedure from strsql, it seemed to lock - it was the rdp debugger taking control! How is that possible? When I refreshed the sep, it didn't catch the call. If I recompile, I should be obliged to refresh the sep! N'est-ce pas!!

-----Message d'origine-----
De : wdsci-l-bounces@xxxxxxxxxxxx
[mailto:wdsci-l-bounces@xxxxxxxxxxxx] De la part de
Rick.Chevalier@xxxxxxxxxxxxxxx
Envoyé : jeudi 2 décembre 2010 14:55
À : wdsci-l@xxxxxxxxxxxx
Objet : Re: [WDSCI-L] Stored procedures

David,

Check the user ID the SEP was set up to use and the user ID
you are running the SQL under. If they don't match I think
the SEP is ignored.

Rick